Martin wrote:

when dividing two integers, the result is a float, which means we
> immediately lose precision. This is not good if you want to use code which
> supports higher precision.


I am of course in favour of keeping precision, if there is no cost. But
here there is a cost. Arbitrary precision arithmetic (and roots) uses more
memory and takes longer. Therefore, the system must allow the programmer to
choice what's wanted (either explicitly or implicitly).

Python has been set up to make 1/3 evaluate to a float (an implicit
choice), and have Fraction(1, 3) be a fraction (an explicit choice).

I don't think it fair to say that this decision is "not good". Rather, it's
good for some use cases and not so good for others. On balance, I'm happy
with that decision.

That said, as a pure mathematician who does integer calculations, I'd like
numpy to have better capabilities for integer linear algebra.

I hope Martin that you agree with me, that this change would not be an
improvement for everyone.

-- 
Jonathan
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HJXX2MYDP32PYJGJMTCPYLHL47ZF35BV/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to