3 ms·

I think that a language which (as I understand it) already gives you a big number if you exceed the bounds of its provided integer types, might just as well pro

I think that a language which (as I understand it) already gives you a big number if you exceed the bounds of its provided integer types, might just as well provide rationals as the IEEE floating point types unless those IEEE types are very fast but to me it looks like on the whole they're not. I was not aware of Cython, which sounds like a terrible idea but each to his own nor Numba, though I have worked with PyPy in the past. I'm afraid that the idea that somehow every Python implementation would be compatible caused me to choke. Python doesn't really care about compatibility, behaviour of the sum function you brought up was changed twice since Python 3. This is an old machine, so I can well believe you can do the iteration faster. My initial interest happened because by total coincidence I was writing benchmarks for realistic which try out f32 and f64 vs realistic::Real for various arithmetic operations, and so I wondered well, isn't even Python much faster and (with my naive iteration) it was not. As you are hopefully aware, new programmers are equally likely to run into languages where the default is the 32-bit IEEE floating point and so 1.0 + 2.0 > 3.0 is false for them as they are to encounter a language like Python with 64-bit IEEE floats. I'd expect, as with Python's experience with their hash tables, the kind of people writing Python as their main or even only language would always be pleased to have simpler, less surprising behaviour, and the rationals are much simpler - they're just slower.

eesmith 1y ago
The int/long unification occurred a long time ago. ("long" was Python's name for BigNum.) There is now no such thing as "exceed the bounds of its provided integer types". Guido van Rossum, who started and lead the Python project for many years, previously worked with ABC, which used rational as the default type. In practice this caused problems as it was all to easy to end up with "pathologically large numerators and denominators" (quoting https://docs.raku.org/type/FatRat https://docs.raku.org/type/FatRat). That experience guided him to reject rationals as the default integer type. Pathologically large numerators and denominators make rationals not "just slower" but "a lot slower". > somehow every Python implementation would be compatible It's more of a rough consensus thing than full compatibility. > Python doesn't really care about compatibility Correct, and it causes me pain every years. But do note that historic compatibility is different than cross-implementation compatibility, since there is a strong incentive for other implementations to do a good job of staying CPython compatible. FWIW, the laptop where I did my timings is 5 years old. The new programmers in my field generally have Python as their first language, and don't have experience with float32. I also know that float32 isn't enough to distinguish rationals I need to deal with, since in float32, 2094/4097 == 2117/4142 == 0.511106, while in float64 those ratios are not equal, as 0.5111056870881132 != 0.5111057460164172. (I internally use uint16_t for the ratios, but have to turn them into doubles for use by other tools.)
- tialaramex 1y ago
  > FWIW, the laptop where I did my timings is 5 years old. The PC I tried this is on is about 10 year old, I bought this place in 2014 and the PC was not long after that.
  - eesmith 1y ago
    My desktop CPU came out in 2017, so 8 years old. sum() of a list with 100M floats took 0.65 seconds. The explicit loop took 1.5 seconds on CPython 3.13. But again, yes, Rust performance runs rings around CPython, but that's not enough to justify switching to an alternative numeric type given the many negatives, and Python's performance isn't as dire as you suggest.

eesmith 1y ago

The int/long unification occurred a long time ago. ("long" was Python's name for BigNum.) There is now no such thing as "exceed the bounds of its provided integer types". Guido van Rossum, who started and lead the Python project for many years, previously worked with ABC, which used rational as the default type. In practice this caused problems as it was all to easy to end up with "pathologically large numerators and denominators" (quoting https://docs.raku.org/type/FatRat https://docs.raku.org/type/FatRat). That experience guided him to reject rationals as the default integer type. Pathologically large numerators and denominators make rationals not "just slower" but "a lot slower". > somehow every Python implementation would be compatible It's more of a rough consensus thing than full compatibility. > Python doesn't really care about compatibility Correct, and it causes me pain every years. But do note that historic compatibility is different than cross-implementation compatibility, since there is a strong incentive for other implementations to do a good job of staying CPython compatible. FWIW, the laptop where I did my timings is 5 years old. The new programmers in my field generally have Python as their first language, and don't have experience with float32. I also know that float32 isn't enough to distinguish rationals I need to deal with, since in float32, 2094/4097 == 2117/4142 == 0.511106, while in float64 those ratios are not equal, as 0.5111056870881132 != 0.5111057460164172. (I internally use uint16_t for the ratios, but have to turn them into doubles for use by other tools.)

tialaramex 1y ago
> FWIW, the laptop where I did my timings is 5 years old. The PC I tried this is on is about 10 year old, I bought this place in 2014 and the PC was not long after that.
- eesmith 1y ago
  My desktop CPU came out in 2017, so 8 years old. sum() of a list with 100M floats took 0.65 seconds. The explicit loop took 1.5 seconds on CPython 3.13. But again, yes, Rust performance runs rings around CPython, but that's not enough to justify switching to an alternative numeric type given the many negatives, and Python's performance isn't as dire as you suggest.