I=E2=80=99m new to kdb+, since it=E2=80=99s used mainly by financial people= , and it use IEEE floating point number. Doesn=E2=80=99t the inaccuracy bot= her you, how do you deal with that?
Hi Yi,
Have you reviewed this?
https://code.kx.com/q/cookbook/precision/#float-precision
Can you be more specific about what problems you encounter?
Sometimes, the imprecision can be magnified into something problematic:q)0.1*100000000000000 - (0.3-0.2)*10000000000000000.0015625000000000001On Sun, Mar 10, 2019 at 6:03 PM JW Buitenhuis wrote:>> Hi Yi,>> Have you reviewed this?> https://code.kx.com/q/cookbook/precision/#float-precision>> Can you be more specific about what problems you encounter?>>> On Sat, 9 Mar 2019 at 16:59, yi huang <yi.codeplayer> wrote:>>>> Im new to kdb+, since its used mainly by financial people, and it use IEEE floating point number. Doesnt the inaccuracy bother you, how do you deal with that?>>>> –>>
Submitted via Google Groups</yi.codeplayer>
This is nothing new in kdb+. All systems based on the IEEE standard will have similar problems. That’s why this is a must-read for everybody: https://docs.oracle.com/cd/E19957-01/806-3568/ncg\_goldberg.html
It’s worth to mention that standard approach to this is not use floating points numbers for price like data and use some fixed precision type like: https://docs.oracle.com/cd/E17952\_01/mysql-5.0-en/precision-math-decimal-characteristics.html Unfortunatelly there isn’t anything like this in Kdb, so you have basically tradeoff between more intuitive approcach using floats and deal with possible issues depending on use case or use some integer based approach - storing price in tick for example or using some multiplier. This can be confusing though if there are users using data directly (otherwise you would can use some translation in api layer..)
Thing to watch out for (in my experience) is grouping by price levels (especially when calculating some of them) because ~ is using comp tolerance, while grouping (incl. by) obviously doesn’t.
Cheers,
Oleg