5 ms·

Why do you say that "most of the time... you really want a decimal"? I can't think of any situation where I'd prefer a decimal.Decimal over an ordinary float, e

by creata 5y ago

Why do you say that "most of the time... you really want a decimal"? I can't think of any situation where I'd prefer a decimal.Decimal over an ordinary float, except for the textbook example of dollars and cents. In most situations, I'm pretty sure decimal.Decimals would be unacceptably slower.

tomrod 5y ago
In data science, this can be an issue.
samwillis 5y ago
Even with currency now it seems more common to just use ints of the currency’s lowest denomination/subunit (cents, pence etc)
- tadfisher 5y ago
  You might as well use a Decimal at that point, which usually combines an integer mantissa with some inverse exponent of 10. Otherwise you're applying that exponent everywhere you use the value, whether you display it or use it in a mathematical expression.
  - samwillis 5y ago
    I think the advantage of ints over Decimal is interoperability of systems. Anything with a REST api or JSON doesn’t have native support for Decimals, so to use them you have to represent them in component form as an object or as a string. Ints just make that easer at the slight cost at display time. Stripe is a good example of this. > Otherwise you're applying that exponent everywhere you use the value, whether you display it or use it in a mathematical expression. Slightly disagree, I think it’s only when displaying you have to convert to a “human readable” decimal form. They don’t need converting to Decimal for processing. It’s also worth noting there are actually two none decimal currency’s still in use: “Today, only two countries have non-decimal currencies: Mauritania, where 1 ouguiya = 5 khoums, and Madagascar, where 1 ariary = 5 iraimbilanja.” https://en.m.wikipedia.org/wiki/Non-decimal_currency https://en.m.wikipedia.org/wiki/Non-decimal_currency
    - creata 5y ago
      > Anything with a REST api or JSON doesn’t have native support for Decimals This is a very slight nitpick (that might be wrong) but I think it's perfectly in line with the JSON specification to interpret JSON numbers as decimals.
      - samwillis 5y ago
        You are right, both the ECMA. standard and RFC leave the implementation of numbers open to the parser and language: "JSON is agnostic about the semantics of numbers. In any programming language, there can be a variety of number types of various capacities and complements, fixed or floating, binary or decimal. That can make interchange between different programming languages difficult. JSON instead offers only the representation of numbers that humans use: a sequence of digits. All programming languages know how to make sense of digit sequences even if they disagree on internal representations. That is enough to allow interchange." https://www.ecma-international.org/wp-content/uploads/ECMA-404_2nd_edition_december_2017.pdf https://www.ecma-international.org/wp-content/uploads/ECMA-4... https://datatracker.ietf.org/doc/html/rfc7159 https://datatracker.ietf.org/doc/html/rfc7159 And most JSON parsers allow you to extend and change how types are handled. I think however from a developer point of view by standardising on ints you reduce the risk of making a mistake in your implementation. I think the point is though that as long as your system doesn't need to handle fractions of a cent/pence/etc then using them as the base representation and only doing integer math makes the system simpler. It moves the complexity of currency to the display layer away from the business layer. Obviously there are times when you need to be able to handle smaller units and a decimal type would be correct there.
dragonwriter 5y ago
If you write a decimal literal, the sensible default behavior is to preserve precision rather than throwing it out for speed optomization. Sure, there is a long history of programming languages mostly choosing the reverse default, but it's a bad choice for correctness.
- FastMonkey 5y ago
  I think "sensible" is highly context dependent.
- tadfisher 5y ago
  I prefer compiler warnings when a float/double literal is not representable. Not perfect for interpreted runtimes, though.
- Someone 5y ago
  If you write literals such as 0xa.bp-3, 1/3 or 22/7, why would those be allowed to throw out precision for speed? (That hex literal is valid C++17; the fractions aren’t literal in the standards, but IMO are literals in human heads) ⇒ If you think the “sensible default behavior is to preserve precision“ I think you would have to call for (at least) rational as the default non-integer integral type. (If you think of √2 as a literal, it gets more complicated. In the end, you might have to use a representation that’s similar to that used in computer algebra systems) Edit: you could also require constants that do have an exact representation in your floating point format. That would be annoying, too, though, but maybe not too annoying if you had a way to specify “the number closest to this one”, say by requiring one to write ~2.1~ instead of 2.1
  - lmm 5y ago
    > If you write literals such as 0xa.bp-3, 1/3 or 22/7, why would those be allowed to throw out precision for speed? (That hex literal is valid C++17; the fractions aren’t literal in the standards, but IMO are literals in human heads) IMO decimal rounding of those fractions, while not ideal, is a lot more understandable to a typical person. If 1/3 * 3 = 0.99999999999999999 that's annoying, but not crazy in the same way that the floating-point equivalent is.
dec0dedab0de 5y ago
you're right that they would be slower, but if I'm using a high level language I already have made the decision to have things be slower, so that I can focus on my logic instead of how the hardware works. I think maybe what I really want is a number type that abstracts away ints, floats, fractions, and maybe others. Then once I have it working I can optimize it to use specific types if it's not running fast enough.

by creata 5y ago

tomrod 5y ago

In data science, this can be an issue.

samwillis 5y ago

Even with currency now it seems more common to just use ints of the currency’s lowest denomination/subunit (cents, pence etc)

tadfisher 5y ago
You might as well use a Decimal at that point, which usually combines an integer mantissa with some inverse exponent of 10. Otherwise you're applying that exponent everywhere you use the value, whether you display it or use it in a mathematical expression.
- samwillis 5y ago
  I think the advantage of ints over Decimal is interoperability of systems. Anything with a REST api or JSON doesn’t have native support for Decimals, so to use them you have to represent them in component form as an object or as a string. Ints just make that easer at the slight cost at display time. Stripe is a good example of this. > Otherwise you're applying that exponent everywhere you use the value, whether you display it or use it in a mathematical expression. Slightly disagree, I think it’s only when displaying you have to convert to a “human readable” decimal form. They don’t need converting to Decimal for processing. It’s also worth noting there are actually two none decimal currency’s still in use: “Today, only two countries have non-decimal currencies: Mauritania, where 1 ouguiya = 5 khoums, and Madagascar, where 1 ariary = 5 iraimbilanja.” https://en.m.wikipedia.org/wiki/Non-decimal_currency https://en.m.wikipedia.org/wiki/Non-decimal_currency
  - creata 5y ago
    > Anything with a REST api or JSON doesn’t have native support for Decimals This is a very slight nitpick (that might be wrong) but I think it's perfectly in line with the JSON specification to interpret JSON numbers as decimals.
    - samwillis 5y ago
      You are right, both the ECMA. standard and RFC leave the implementation of numbers open to the parser and language: "JSON is agnostic about the semantics of numbers. In any programming language, there can be a variety of number types of various capacities and complements, fixed or floating, binary or decimal. That can make interchange between different programming languages difficult. JSON instead offers only the representation of numbers that humans use: a sequence of digits. All programming languages know how to make sense of digit sequences even if they disagree on internal representations. That is enough to allow interchange." https://www.ecma-international.org/wp-content/uploads/ECMA-404_2nd_edition_december_2017.pdf https://www.ecma-international.org/wp-content/uploads/ECMA-4... https://datatracker.ietf.org/doc/html/rfc7159 https://datatracker.ietf.org/doc/html/rfc7159 And most JSON parsers allow you to extend and change how types are handled. I think however from a developer point of view by standardising on ints you reduce the risk of making a mistake in your implementation. I think the point is though that as long as your system doesn't need to handle fractions of a cent/pence/etc then using them as the base representation and only doing integer math makes the system simpler. It moves the complexity of currency to the display layer away from the business layer. Obviously there are times when you need to be able to handle smaller units and a decimal type would be correct there.

dragonwriter 5y ago

If you write a decimal literal, the sensible default behavior is to preserve precision rather than throwing it out for speed optomization. Sure, there is a long history of programming languages mostly choosing the reverse default, but it's a bad choice for correctness.

FastMonkey 5y ago
I think "sensible" is highly context dependent.
tadfisher 5y ago
I prefer compiler warnings when a float/double literal is not representable. Not perfect for interpreted runtimes, though.
Someone 5y ago
If you write literals such as 0xa.bp-3, 1/3 or 22/7, why would those be allowed to throw out precision for speed? (That hex literal is valid C++17; the fractions aren’t literal in the standards, but IMO are literals in human heads) ⇒ If you think the “sensible default behavior is to preserve precision“ I think you would have to call for (at least) rational as the default non-integer integral type. (If you think of √2 as a literal, it gets more complicated. In the end, you might have to use a representation that’s similar to that used in computer algebra systems) Edit: you could also require constants that do have an exact representation in your floating point format. That would be annoying, too, though, but maybe not too annoying if you had a way to specify “the number closest to this one”, say by requiring one to write ~2.1~ instead of 2.1
- lmm 5y ago
  > If you write literals such as 0xa.bp-3, 1/3 or 22/7, why would those be allowed to throw out precision for speed? (That hex literal is valid C++17; the fractions aren’t literal in the standards, but IMO are literals in human heads) IMO decimal rounding of those fractions, while not ideal, is a lot more understandable to a typical person. If 1/3 * 3 = 0.99999999999999999 that's annoying, but not crazy in the same way that the floating-point equivalent is.

dec0dedab0de 5y ago

you're right that they would be slower, but if I'm using a high level language I already have made the decision to have things be slower, so that I can focus on my logic instead of how the hardware works. I think maybe what I really want is a number type that abstracts away ints, floats, fractions, and maybe others. Then once I have it working I can optimize it to use specific types if it's not running fast enough.