-
Decimal type or representing very big numbers
What would be the most optimal approach for storing cryptocurrency values in kdb/q, considering the limitations posed by insufficient precision when using floats and potential limitations when using integers? Specifically, certain cryptocurrencies like Ethereum have the smallest subunit of 10^-18, resulting in a limited number of Ethereums units that can be stored before reaching 2^64 . One potential solution could involve storing the decimal and integer parts as separate integers, although this would require implementing custom arithmetic operations and to be honest I don’t believe that the language specifically designed for the finances doesn’t have some kind of decimal type. Are there any alternative suggestions or best practices in such scenarios? Thank you in advance for your assistance.
-
1 Reply
Log in to reply.