What's the actual problem you are solving with this complex, complicated
proposal? In other words, what is the motivation? You mentioned symbolic
maths in the previous thread.
Python is never going to look good for symbolic maths, because symbolic
maths is a two-dimensional layout and Python (like most programming
languages) is line-oriented in a way that does not lend itself to
complex mathematical notation.
What is so special about constant expressions like `1/3`? Why shouldn't
non-constant expressions like `one/three` work?
How about expressions like `(1-3**-2)*7`?
If you care about making symbolic maths look good, don't you need a way
for expressions like √2 and sin π/3 to give you an exact symbolic result
too?
How do you respond to the argument that this will add lots of complexity
to the mental model of numbers in Python, without actually making Python
a symbolic maths language?
You suggest:
> only when we start calculating with them, the receiving function will
> pick whatever it prefers.
In concrete terms, how do I write a function to do that?
Once I have a ratiofloat and do arithmetic to it, what happens?
x = 1/3 # this is a ratiofloat
# what are these?
x + 1
x**2
x**0.5
You say:
> All of this does not only work for integers, but also for float
> literals
and give 0.1 as an example. Okay, I will grant you that *most* people
will expect that 0.1 is 1/10, rather than
3602879701896397/36028797018963968 but what about less obvious examples?
If I write 0.6666666666666666 will I get 2/3? What if I write it as
0.6666666666666667 instead? (They are different floats.) How about
0.666666666667, copied from my calculator?
How about 0.66667? Is that close enough to get 2/3? Its obvious that in
real life anyone writing 0.66667 is thinking "2/3".
What's the size of your ratiofloats?
>>> sys.getsizeof(2.5)
24
Including any associated data stored in attributes (like the numerator
and denominator).
You say:
> All this is only interesting once you teach some classes about it.
What is involved in teaching classes about this? For example, how much
work did it take for you to get this result?
>>> Decimal(0.1)
Decimal('0.1')
> How would we go forward about this? The good news is that all that I
> described happens at compile time, so we can use a good ole' "from
> __future__ import" approach. So my suggestion is: implement it for
> 3.11, but activate it only with a future import or an interpreter
> option for the command line. This gives libraries time to adopt to
> this new style.
I can see that, maybe, sympy would be interested in this. Aside from
sympy, what benefit do you think other libraries will get from this?
Especially libraries like numpy and scipy which pretty much do all their
work in pure floating point.
--
Steve
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/S7HMZ3Y7D5ALPG5E3LN75DG6DILD4BUI/
Code of Conduct: http://python.org/psf/codeofconduct/
