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/
