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

Bengt Richter bokr at accessone.com
Sun Jul 29 21:37:44 EDT 2001


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 ;-)
(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.

The sign bit gives a nice unambiguous -pi in preference
to +pi, and angles get modulo 2pi for free. We did
transcendental functions in software and rescaled the
series coefficients so we could pass angle arguments
in that form (IIRC -- this was in a time frame where we
were happy to get our software floating point ops executing
in under a millisecond ;-). Shaft angle encoders commonly
wind up giving you this kind of representation of angles,
(or gray code that you can convert if the device didn't).

If you have n bits to represent an angle, ISTM that
format gets the most out of them.



More information about the Python-list mailing list