Ticks (Last Traded Price) ... float or double?

[abattia]

I need to store and work with large numbers of ticks (last traded price) in memory. Can I store these ticks as float rather than double?

I can't think of any tick requiring greater than 7 digits of precision. Are there any?

When I use the ticks for calculations I will convert to double precision, but will keep them stored in memory as float. Am I missing anything?

 

[hft_boy]

Quote from abattia:

I need to store and work with large numbers of ticks (last traded price) in memory. Can I store these ticks as float rather than double?

I can't think of any tick requiring greater than 7 digits of precision. Are there any?

When I use the ticks for calculations I will convert to double precision, but will keep them stored in memory as float. Am I missing anything?

Where will the double precision things be kept? (Hint: in memory)

If you're so worried about precision, why don't you use ints? Also check the way that you're storing and laying out the ticks in memory, you can probably cut size down two to three times if you lay them out in a space efficient way.

Or you could just buy more RAM.

 

[PocketChange]

Store and process as INT

 

[abattia]

Thanks!

Quote from hft_boy:
...Also check the way that you're storing and laying out the ticks in memory, you can probably cut size down two to three times if you lay them out in a space efficient way...

How would I go about this? Any hints/pointers on where I could read up about what's required... Am working with C# ...

Many thanks, again.

 

[abattia]

Thanks!

Quote from PocketChange:
Store and process as INT

Would this work as foillows?
a) multiply tick price by the number (100, or 10000, or whatever) that makes the decimal number an integer
b) keep track of that "multiplier" (which will be different across different instruments) to reverse the calculation (and convert back to double/float) wherever need to work with usual currency units ...

 

[Craig66]

Quote from abattia:

Thanks!



Would this work as foillows?
a) multiply tick price by the number (100, or 10000, or whatever) that makes the decimal number an integer
b) keep track of that "multiplier" (which will be different across different instruments) to reverse the calculation (and convert back to double/float) wherever need to work with usual currency units ...

Yep, write a class to wrap it up, but be very, very careful about the conversions to and from the integer, it's very easy get it subtly wrong.

 

[vincegata]

Why to use int instead of float? Both int and float are 4 bytes, at least that's how C++ stores them. Stock prices use 2 digits after decimal point, currencies use 5 digits (except usd/yen which uses 2 digits). Float type with 7 digits can comfortably store those prices. However, when doing calculations they need to be converted to double not to loose precision.

 

[stevegee58]

Quote from abattia:

Thanks!



Would this work as foillows?
a) multiply tick price by the number (100, or 10000, or whatever) that makes the decimal number an integer
b) keep track of that "multiplier" (which will be different across different instruments) to reverse the calculation (and convert back to double/float) wherever need to work with usual currency units ...

What you're describing is fixed point math and it's definitely the best way to go for price data.

There are open source fixed point math packages on the interwebs.

I've run into values that can be easily be expressed fixed point but end up with rounding errors in floating point format. Adding precision doesn't help in that case.

 

[hft_boy]

Quote from abattia:

Thanks!

How would I go about this? Any hints/pointers on where I could read up about what's required... Am working with C# ...

Many thanks, again.

Don't know how C# works. But in C you want to order the struct members from largest to smallest in terms of size to avoid extra padding.

http://stackoverflow.com/questions/2748995/c-struct-memory-layout

 

[hftvol]

that is highly inefficient, given that you trade memory (cheap and available in large enough quantities in terms of system limit) for precious CPU power. The conversion has to be performed each time you want to operate on such variables. If forced to make a compromise I would always free up precious computational power vs memory (this obviously applies to 64bit code bases)

Another, and possibly largest drawback of your suggestion is the sheer amount of places to introduce potentially hard to debug errors.

Quote from abattia:

Thanks!



Would this work as foillows?
a) multiply tick price by the number (100, or 10000, or whatever) that makes the decimal number an integer
b) keep track of that "multiplier" (which will be different across different instruments) to reverse the calculation (and convert back to double/float) wherever need to work with usual currency units ...