• kdb+

  Decimal type or representing very big numbers

  Posted by jenthas on June 9, 2023 at 12:00 am

  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.

  jenthas replied 8 months, 2 weeks ago 2 Members · 1 Reply
• 1 Reply

• 

  rocuinneagain

  Member

  June 9, 2023 at 12:00 am

  These previous discussions have good information:

  • https://community.kx.com/t5/kdb-and-q/C-convert-large-decimal-to-KDB/m-p/11049
  • https://community.kx.com/t5/kdb-and-q/Big-Integers-larger-than-long/m-p/228
  • https://github.com/manifoldfinance/qBigInt
  • https://github.com/adotsch/c-extensions-to-q

Log In to Reply