3 ms·

Let me see if I have it right. You don't like Python's use of IEEE 754 float64 for its "float" type because it's already so slow that you think Python should u

Let me see if I have it right. You don't like Python's use of IEEE 754 float64 for its "float" type because it's already so slow that you think Python should use a data type which better fits the expectations of primary school math training. Then to demonstrate the timing issue you give an example where you ignore the simplest, fastest, and most accurate Python solution, using a built-in function which would likely be more accurate than what's available in stock Rust. If accuracy is important for the first, why is it not important for the second? Are you aware of the long history of compiled versions of Python (PyPy, numba, and more), plus variants like Cython, where the result has near Rust performance levels? Were the core float be a non-IEEE 754, those compiled versions would either be dog slow (to be compatible with Python's core float) or give results which are different than CPython's. Even if they did not exist, there would be a lot of questions about why a given program in C, Rust, Pascal, or any other float64-based system, gives different answers when translated to Python. FWIW, I, like others, could not reproduce your 20 seconds timing. Python is indeed slow for this sort of task, but even for explicit iteration my code is an order of magnitude faster than you reported.

tialaramex 1y ago
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.

tialaramex 1y ago

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.