proposed language change to int/int==float (was: PEP0238 lament)

David C. Ullrich ullrich at math.okstate.edu
Mon Jul 30 10:12:30 EDT 2001


On Mon, 30 Jul 2001 01:37:44 GMT, bokr at accessone.com (Bengt Richter)
wrote:

>On Sat, 28 Jul 2001 14:13:42 GMT, ullrich at math.okstate.edu (David C. Ullrich) wrote:
>[...]
>>
>>(Hmm. Thinking about it, what seems worth it to me would
>>surely not be worth it to almost anyone else: A complex
>>should have alternate real-imag and modulus-arg representations,
>>ie representations in rectangular or polar coordinates, and
>>we should be able to say that _either_ is exact. Because the
>>calculations with "exact complexes" that interest me in
>>particular are with complexes where the polar coordinate
>>representation involves _exact_ rationals, although real
>>and imag are inexact. For example, if z is a complex with
>> |z| = 1 and arg(z) = pi/3 then z**6 should be 1, exactly.
>>If there were an exact complex like that that would be
>>convenient.
>>
>>Come to think of it, it's arg/pi that should be allowed
>>to be an exact rational for this reason, not arg.
>>
>>And no, this is _not_ an actual suggestion or a request;
>>actually doing this in a general-purpose programming
>>language seems silly. But if you decide to write several
>>thousand versions to keep everyone happy this is a feature
>>that goes in my version...)
>>
>Why don't you write a class that does what you want ;-)

Because it seems easier to wait until "they" give in and
decide to give everyone everything they want - then I
just specify what I want in my version of Python and
voila, I'm set.

>(But google first. It's amazing how 99% of everything I think of
>magically appears before I've even mentioned it on line ;-)
>
>BTW, in some systems it is convenient to represent angles as
>two's complement integers of n bits, where the least
>significan bit is worth 2pi/2^n.  It gives you a lot
>of easily and exactly representable angles, effectively
>rationals with 2^n denominator.

Well, the 'angles' you want to represent exactly in a
Fourier transform are not going to be included here,
except for 2^n data points (which is the most typical
thing for an FFT, but far from the only possibility.)

Although come to think of it that's sort of bogus since
the FT is not going to come out exact anyway. So I
guess what I really want is actual literally infinite-
precision reals. I guess I may have to wait.

(Got off on a slight tangent there. Seriously, I don't
see why complexes should be necessarily inexact, just
because I don't see why they should be required to
use floats any more than vectors or matrices should
be restricted to floating-point entries.)

David C. Ullrich



More information about the Python-list mailing list