hold on there partner. i said c# has a decimal variable type. i did not say that c#'s float and double variable type will work. i said Visual Basic's float and variable type will work. so it looks like you don't need to rewrite anything. just change the variables to decimal type and and bada bing bada boom it works! http://msdn.microsoft.com/en-us/library/364x0z75(VS.80).aspx
My mistake, I didn't know about that C# decimal type when I originally started the project, it was kind of a pilot project to evaluate C# so I probably didn't use it to its fullest. But anyway I have implemented a C++ decimal class using __int64 storage, everything seems to work just dandy.
If you require precision, you should not use floating point math. You should consider using fixed point arithmetic which is integral.
Use rational numbers... if you are using C++ the boost library rational classes may be a good point to start. If you are basing your calculations on discrete prices (i.e. 0, 0.5, 1.0, 1.5, 2.0, 2.5, 3.0, ...) then maybe you should consider storing the price in ticks i.e (0 -> 0.0, 1 -> 0.5, 2 -> 1.0, 3 -> 1.5) and also performing calculations whilst in an integer form. Simple ^2 operations can be performed via bit shift operators on the integer (i.e. << 1 -> *2, << 2 -> *4, etc), divide ^2 by >>. Remember though, the conversion from the float form to the integer form can be time consuming (in relative terms) and also you have to be careful to convert to the correct integer (within an error margin). Put simply, the only way to avoid precision errors is not to use the floating point types. Also, consider the performance of some of the more exotic types which claim to solve the problem.
Technically speaking if you require an EXACT price it is wrong. Say for example a result of 1.99999999(etc) causes a bid price to be rounded down on a contract with a tick size of 0.01 (thus quoting 1.99 in the market), this may well result in a loss rather than a profit. In a high-frequency trading system this could make a BIG difference. In circumstances where the quant code models a continous price series the rounding does not matter so much, as long as you are aware of the cumulative effect of the errors throughout processing. If you are modelling a discrete process - you probably want some form of exact number processing. It is amazing how this issue is rarely investigated by either quants or programmers. There is a surprising amount of 'wrong' code out there!
CC I am very well aware of rounding issues in numerical analysis. My point was re the comment about the C++ issue.
Say you have a software S/L @ 1.2560, if you store this as a double C++ may end up with something like 1.25599999999 internally (for example), when the price gets to 1.2560 the S/L is not detected because 1.2560 is not equal to 1.25599999999. Of course you could implement the above with tolerance sizes instead of using equality, but that is hardly rigorous.
Why not use 4 decimal places and round up or down? I think I also read somewhere that decimals stored as binary can also cause problems during the conversion back to decimals