How about adding rational fraction to Python?

[Lie]

On Mar 2, 11:36 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> Lie <Lie.1... at gmail.com> writes:
> > You hit the right note, but what I meant is the numeric type
> > unification would make it _appear_ to consist of a single numeric type
> > (yeah, I know it isn't actually, but what appears from outside isn't
> > always what's inside).
>
> That is clearly not intended; floats and decimals and integers are
> really different from each other and Python has to treat them distinctly.

In certain operations it would, such as:
a = Decimal('32.324')
b = 90.3453
c = 43
d = a + b + c   <<< this should work without manual type casting

This behavior is what is intended in numeric type unification, floats
and decimals and integers should work together flawlessly without the
need for manual type casting. This gives the _impression_ of a single
numeric type (although programmers should still be aware that the
underlying type still exists). It's true Python have to treat them
differently, but programmers would be able to treat them all the same
(at least in most parts)

> > > Try with a=7, b=25
>
> > They should still compare true, but they don't. The reason why they
> > don't is because of float's finite precision, which is not exactly
> > what we're talking here since it doesn't change the fact that
> > multiplication and division are inverse of each other.
>
> What?  Obviously they are not exact inverses for floats, as that test
> shows.  They would be inverses for mathematical reals or rationals,
> but Python does not have those.

When I said multiplication and division are inverse, I was pointing
out the fact that even though float's inexactness make them imperfect
inverse, mult & div are still inverse of each other. In-practice, the
inversing behavior is impossible unless we have a way to represent
real number (which we don't), and the *workaround* to make them work
is to do epsilon comparison.

When I'm talking about things I usually talk in purely theoretical
condition first and considers practical implementations that doesn't
work that way as making up a workaround inside their limitations. In
this case, the theoretical condition is that multiplication and
division is inverse of each other. The practical consideration is
float is inexact and reals is impossible, and thus epsilon comparison
is necessary to walk around float's limitations so multiplication and
division could still be inverses.

Aside: Python would have rationals

> > One way to handle this situation is to do an epsilon aware
> > comparison (as should be done with any comparison involving floats),
> > but I don't do it cause my intention is to clarify the real problem
> > that multiplication is indeed inverse of division and I want to
> > avoid obscuring that with the epsilon comparison.
>
> I think you are a bit confused.  That epsilon aware comparison thing
> acknowledges that floats only approximate the behavior of mathematical
> reals.  

Yes, I realized that floats aren't the same as reals.

> When we do float arithmetic, we accept that "equal" often
> really only means "approximately equal".  But when we do integer
> arithmetic, we do not expect or accept equality as being approximate.
> Integer equality means equal, not approximately equal.  That is why
> int and float arithmetic cannot work the same way.

No, no, they don't work the same way, but they should appear to work
the same way as reals in pure mathematics do. Again, I'm talking in
theory first: ints and floats should work the same way, but since
practical considerations make them impossible, then they should at
least appear to work the same way (or they would have become
completely different things, remember duck typing?).