ANN: Experimental Number Types (Integer, Rational, Floats)

[Delaney, Timothy]

>     [snip]
> > 12+2/3 - not ambiguous and valid if the above is valid (integer +
> rational),
> > I would probably want the compiler to start rolling 
> literals together at
> > this point... otherwise there would be 2 runtime 
> calculations going on
> > (division to form rational, then addition of integer).
> 
> There are two runtime calculations in many "complex literals" (because
> there's actually no complex literal...:-) today, e.g 
> -2.3+4.5j (because
> sign is also not part of the numeric literal...).

Agreed. I was actually expressing my feeling that with rationals introduced
into the mix as a standard feature, using the proposed syntax, that there
would now be sufficient justification to perform compile-time computation of
constant expressions at it would now affect everybody a lot of the time.
Plus division is generally a slower operation than addition (and subtraction
is just negative addition).

I'm not dissing complex numbers - they would definitely benefit from this as
well. With *two* things where there will be common constant calculations
which can be done at compile-time, I think there would now be a good enough
reason to put in the effort. Currently there aren't many instances where it
would be useful to most people as it's rare to have calculations which can
be done at compile-time in python (no const statement) except in trivial
programs ... no one writes

	a = 123.43 + 5

in a non-trivial case. If one of those is a magic number then it will have
been previously assigned to a reference and the reference will be used -
which means in python it can't be calculated at compile time.

However, with rationals we would likely now have the above expressed as

	a = 128 + 43/100

or

	a = 12843/100

which would both benefit greatly from compile-time calculation.

The common case today is of course with negative numbers - again, a
compile-time calculation would benefit many applications.

Cheers.

Tim Delaney