Decimal Handling in C++

[bidask]

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

Quote from Craig66:

Thanks for all the answers, I think writing a wrapper class which uses integers as the internal representation sounds like the best idea.

To the person who reckons c# doubles and floats just work, they don't, this is a rewrite of a c# project and it had the same problem. That time it was solved with strings, but was looking for a more elegant answer.

 

[Craig66]

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.

 

[EtfTraderLives]

If you require precision, you should not use floating point math. You should consider using fixed point arithmetic which is integral.

 

[cashcow]

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.

 

[Equalizer]

Quote from bidask:

lol this is why you don't use the C++. you must roll up your sleeves and explain to it slowly and cleary that 1.00 + 1.00 = 2.00!

Umm,, yeah, right. I guess all that C++ quant code must be wrong then.

 

[cashcow]

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!

 

[Equalizer]

CC I am very well aware of rounding issues in numerical analysis.

My point was re the comment about the C++ issue.

 

[Sky123987]

Quote from Craig66:

I'm in the process of writing a ATS and I am starting to run across problems concerning rounding errors with standard C++ types (float, double) etc. I was wondering how other people using C++ are handling fixed decimal point representation problems of the kind which occur when handling financial data.

what type of error happens. I haven't noticed it.

 

[Craig66]

Quote from Sky123987:

what type of error happens. I haven't noticed it.

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.

 

[forex-forex]

Quote from Craig66:

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