Reading code is like reading a page of English - it can look messy with poor style and obfusicated meaning, or it can be written well with few errors.
I did a couple of things:
1) Identified that options 1 - 4 are very similar (really only one line is different per option), so restructured them so that they could share the same code as much as possible, removing repetion and also cutting down the code size
2) Variables are declared in the scope that they are required rather than global to the function (cf. num, num2 and choice - see how their declarations are in a different place in my code)
3) I think while(true) is more readable than for (;

- just my opinion, at the end of the day for is syntactic sugar for while anyway.
I did not bother to include all the option 6 and 7 crap - easy enough to add in. Could have cut the code down further by combining many of the couts onto one line (e.g. the menu), I would have taken his approach but it would make it slightly less clear for learning purposes.
Bear in mind, on average, 70% of effort spend creating software is in the maintenance phase. Whenever you write code, it really is essential that it is written clearly. I am currently working on porting and interfacing to, a 50000 line parallel simulation package written in C, thankfully for us it is written quite well and the code is clear(ish), but some of the less good coding styles adopted have caused real problems for us.
Nick