3 ms·

If Bitcoin has x point precision and I multiply every amount by 1e^x. Won't that in essence gives me correct integer value to work with. Provided I haven't over

by negamax 13y ago

If Bitcoin has x point precision and I multiply every amount by 1e^x. Won't that in essence gives me correct integer value to work with. Provided I haven't overflowed the integer max?

viraptor 13y ago
Sure, you can prove that, then verify your language complies over the whole range, then add validation that your values never go over the range provided and no input outside of the range can be accepted and then figure out a way to guarantee none of that will change in the future. (even controlling inputs/outputs is not enough, since internally they sometimes split the values into 40%/60% for transfers) Or you just stick to ints (or whatever type has unlimited integer range in a given language). Simple solution here is safer than the clever one. Especially if you're sometimes confused about the types and write `round(mt_rand($amount 0.4, $amount 0.6))` even though mt_rand returns ints.
- bennyg 13y ago
  So if one of us were to create something dealing with BTC we should just store the data as the smallest discrete amount (satoshis) and then run calculations on that to display info to the user?
  - viraptor 13y ago
    Sure - is there a reason not to? That's similar to what you should be doing with dates too - store as UTC at the highest precision you'll need and present in local timezone/format.
    - bennyg 13y ago
      Only one I can think of is 32 bit architectures, but those are phasing out pretty fast. I wasn't being incendiary at all with my comment - just a general question from a novice software engineer.
      - viraptor 13y ago
        32 architecture limits your pointer size, not the values you can store. There's nothing that prevents you from using 64-bit long integers there, it will only take a bit longer than native size on arithmetical operations. (since they will be a series of ops on 32b chunks)
jimktrains2 13y ago
As a side note: 1e^x reads as the natural log base to the x power all times 1. 1ex or 10^x is what you probably want. Why e was chosen to represent that may be due to 7-segment-only displays on (some) (early) calculators. I still think it was a bad choice because of this very issue.

by negamax 13y ago

If Bitcoin has x point precision and I multiply every amount by 1e^x. Won't that in essence gives me correct integer value to work with. Provided I haven't overflowed the integer max?

viraptor 13y ago

Sure, you can prove that, then verify your language complies over the whole range, then add validation that your values never go over the range provided and no input outside of the range can be accepted and then figure out a way to guarantee none of that will change in the future. (even controlling inputs/outputs is not enough, since internally they sometimes split the values into 40%/60% for transfers) Or you just stick to ints (or whatever type has unlimited integer range in a given language). Simple solution here is safer than the clever one. Especially if you're sometimes confused about the types and write `round(mt_rand($amount 0.4, $amount 0.6))` even though mt_rand returns ints.

bennyg 13y ago
So if one of us were to create something dealing with BTC we should just store the data as the smallest discrete amount (satoshis) and then run calculations on that to display info to the user?
- viraptor 13y ago
  Sure - is there a reason not to? That's similar to what you should be doing with dates too - store as UTC at the highest precision you'll need and present in local timezone/format.
  - bennyg 13y ago
    Only one I can think of is 32 bit architectures, but those are phasing out pretty fast. I wasn't being incendiary at all with my comment - just a general question from a novice software engineer.
    - viraptor 13y ago
      32 architecture limits your pointer size, not the values you can store. There's nothing that prevents you from using 64-bit long integers there, it will only take a bit longer than native size on arithmetical operations. (since they will be a series of ops on 32b chunks)

jimktrains2 13y ago

As a side note: 1e^x reads as the natural log base to the x power all times 1. 1ex or 10^x is what you probably want. Why e was chosen to represent that may be due to 7-segment-only displays on (some) (early) calculators. I still think it was a bad choice because of this very issue.