131–140 of 151 posts
Earlier quoted context omitted.
Why would the value get truncated?
FTA: JavaScript's built-in JSON implementation is limited to the range and precision of a double. Obviously, not all int64 values are representable in float64 (double).
Earlier quoted context omitted.
Until you want faster joins, in which case, comparisons of integers tend to be much faster on hardware I am aware of than string comparisons.
UUIDs are great for this. It’s really just a random 128-bit integer, which makes comparisons about as fast as variable-length integers on modern hardware. And they decode to strings which means no application code or API end-user code is going to assume it’s a number.
Earlier quoted context omitted.
When I say dangerously naive, I mean in a way that people can go to jail¹ for "loosing" or "inventing" cents. Which your software will do if you use floats. ¹IANAL. But this was told when legal people looked at our architecture.
Your software will still "lose" cents if you use integers, for operations such as dividing a bill (e.g. divide by 3), or applying 3% APR in monthly increments. The goal is not to avoid rounding errors (which would be quite difficult when the true account value can be an irrational number, as with 3% APR compounding monthly), but to have the exact same rounding errors that are prescribed by the accounting practices. W…
Which is why passing around ints is not the solution. And why I specifically mention Domain Models and/or Value Object.
A domain model would throw an exeption or otherwise dissalow certain divisions for example. What I often do, is something like `expense.amount.divide_over(3, leftover_to_last)` or `savings.balance_at(today).percentage_of(3.1337)`.
Sometimes, in simpler setups and when the language allows, I'll re-implement operators like *, / and even + and -. But when actual business logic is needed, I'll avoid these and implement actual domain methods that use the language the business uses.
But never, ever, do I allow just math-ing over the inner values.
So, I disagree: Both decimal floating point and integers are just as "bad". Maybe for the inner values in the domain model or value object, they are fine, but often there integers are a slightly better starting point because they make rounding and leftovers very explicit.
Earlier quoted context omitted.
I was attempting to solve this very problem in the Rust BigDecimal crate this weekend. Is it better to just let it crash with an out of memory error, or have a compile-time constant limit (I was thinking ~8 billion digits) and panic if any operation would exceed that limit with a more specific error-message (does that mean it's no longer arbitrary-precision?). Or keep some kind of overflow-state/nan, but then the com…
If I understand the situation correctly, in Haskell an unbounded number is the default that you get if you do something similar to JSON.parse(mystr). That means you can have issues basically anywhere. Whereas in Rust with Serde you would only get an unbounded number if you explicitly ask for one. That's a pretty major difference. Only a small number of places will explicitly ask for BigDecimal, and in those cases the…
Earlier quoted context omitted.
What happens if you’re sure that four decimal places is the smallest, then suddenly a partner system starts sending you 6 decimal places?
Precision should be part of the spec for integrations. With the integer multiple of minimal unit, that makes it clear in the API what it is. e.g. it doesn't make sense to support billing in sub-currency unit amounts just by allowing it in your API definition, as you're going to need to batch that until you get a billable amount which is larger than the fee for issuing a bill. Even for something like $100,000.1234, th…
https://en.wikipedia.org/wiki/ISO_4217
Or choose a different standard, I don’t know what else is out there, but you probably should choose an existing one.
Long story short: don't use JSON numbers to represent money or monetary rates. Always use decimals encoded as string. It's surprising how many APIs fall short of this basic bar.
No. Use integers to store the smallest money decimal, and store the currency name alongside.
Earlier quoted context omitted.
No. Use integers to store the smallest money decimal, and store the currency name alongside.
You store it as an integer, but as we just saw in the OP, for general interop with any system that parses JSON you have to assume that it will be parsed as a double. So to avoid precision loss you are going to have to store it as a string anyway. At that point it's upto you whether you want to reinvent the wheel and implement all the required arithmetic operations for your new fixed-point type. Or you could just use…
Earlier quoted context omitted.
FTA: JavaScript's built-in JSON implementation is limited to the range and precision of a double. Obviously, not all int64 values are representable in float64 (double).
We have ample computing power today to be rid of floats altogether and use integers, fractions and natural numbers.
But the resulting type is still going to have its own limitations and sharp edges. Floats are not the right tool for every job but they are quite good at the jobs they are right for. Learning how they work is more useful than lamenting their existence.
Earlier quoted context omitted.
We have ample computing power today to be rid of floats altogether and use integers, fractions and natural numbers.
With 10 times the memory usage and 100 times the compute power, maybe you could replace floats with something that behaves more like real numbers and covers mostly the same range. But the resulting type is still going to have its own limitations and sharp edges. Floats are not the right tool for every job but they are quite good at the jobs they are right for. Learning how they work is more useful than lamenting thei…
But floats are not the right representation for values that need to exactly match, like an ID, to be sure.
If I’m off by half a cent it’s annoying. If I’m off by half a row I get nothing.
The thing is that almost all of the problems we had in my initial story came from choosing system defaults. All except the PK algorithm.
Earlier quoted context omitted.
If I understand the situation correctly, in Haskell an unbounded number is the default that you get if you do something similar to JSON.parse(mystr). That means you can have issues basically anywhere. Whereas in Rust with Serde you would only get an unbounded number if you explicitly ask for one. That's a pretty major difference. Only a small number of places will explicitly ask for BigDecimal, and in those cases the…
Nope you didn't understand the situation correctly. First, almost nobody directly parses from a string to JSON AST: people almost always parse into a custom type using either Template Haskell or generics. Second, parsing isn't the issue; doing arithmetic on the number is the issue.