Hacker News Reader

Comment by dec0dedab0de | Hacker News Reader

I just wish python would switch float and Decimal.

Most of the time float is just an implementation detail when you really want a decimal. I think the literals should be a decimal, and you could explicitly cast float when you actually need to do floating point math, or as an optimization. But I know it's too late for that.

View on HN

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.

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.

That works well in Haskell, which turns literals into rationals (pairs of big integers) and calls an overloaded function fromRational on them implicitly. But Python can't do this kind of inference to give you a nice syntax, so I think this "sensible default behavior" would be a huge pain for users.

(Also, "correctness" seems like the wrong word: making rationals the default type would give you perfectly precise literals, but you'd immediately lose that once you perform almost any operation on them.)

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

> 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.

Correctness is relative to expectations though. It might be worse for bug count to have some languages use decimals and others use floats. People might make even more mistakes.

Particularly when Python is reliant on C extensions for any sort of performance...

I prefer compiler warnings when a float/double literal is not representable. Not perfect for interpreted runtimes, though.

I think "sensible" is highly context dependent.

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

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.

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

> 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.

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-4...

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.

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.

In data science, this can be an issue.

I mean they switched from strings being bytes of UTF-8 to unicode, never say never for Python 4! It would be a downright Pythonic move.

In CPython 2, a `str` was bytes period; no encoding was enforced, these bytes were not necessarily valid UTF-8, and a `unicode` had either UTF-16 or UTF-32 in-memory representation (decided at compilation time). In CPython 3, a `bytes` is bytes and a `str` has ASCII/UTF-16/UTF-32 in-memory representation (decided at runtime). So CPython 2 strings were not “bytes of UTF-8”, and that is why strings `'\xfc\xf7\xe9'` worked fine, they even printed fine in the proper environments.

> In CPython 2, a `str` was bytes -- like old C language, a str is really bytes, no encoding is enforced.

My understanding is that even decimals still do rounding, so it doesn't give users accurate arbitrary-precision numbers.

A default number format that is much slower than built-in floating point but still subject to unexpected deviation from real arithmetic numbers doesn't seem like a win for users.

It gives users rounding that they're used to, from calculators etc. Floats defy common expectations. The fact that we still have to talk about this stuff is exactly the point.

It is impossible to represent all real arithmetic numbers, so it would not be that big a loss.

So much of computing practice is based on the idea that floats aren't quite real numbers, they're like fuzzy analog voltages almost.

Almost nobody thinks about float rounding, they just use something precise enough that it doesn't matter, or use integers.

Why break that standard? Everyone expects computer numbers to be just a bit off. If we didn't we would do a lot of stuff differently in incompatible ways.

Seems like it would hurt the Python ecosystem if people wrote stuff that assumed floats were perfect decimals, and encouraged code that depends on that.

You'd get stuff like serializing to JSON, and reading in some other language with a JSON parser that doesn't know the numbers need to be precise.

Plus, it's just faster.

That would suit me too, but not sure of the wider implications.

Reply on news.ycombinator.com