PEP239 (Rational Numbers) Reference Implementation and new issues

[Bengt Richter]

On Thu, 03 Oct 2002 06:35:55 -0700, "James J. Besemer" <jb at cascade-sys.com> wrote:

>
>Fran=E7ois Pinard wrote:
>
>>On the other hand, [...]
>>On average, most programs will not use matrices of rational numbers,
>>nor play with series.  Moreover, most programs do not use so many differ=
>ent
>>numeric variables anyway, nor perform long computations involving them.
>>Many programs do not go beyond adding or subtracting one, once in a whil=
>e!
>>
>I think this is an excellent point.  The prospective active user base=20
>for rationals, at least initially, is a small subset of the user base. =20
>
>Most people who propose to do much numerical computation often encounter=20
>performance issues and in any case are quickly referred to Numerics=20
>rather than Python intrinsics.  Most courses in "Numerical Analysis"=20
>assume floating point arithmetic and include chapters on minimizing loss=20
>of precision.
>
>However more "accurate" Rationals may be in a mathematical sense they=20
>really are a novelty to the majority of computer users and programming=20
>environments.   While I support their addition to the language I don't=20
>see that they'd be something I or the majority of users would use on a=20
>routine basis.  Like Complex numbers, rationals just don't apply to a=20
>large portion of programming applications.
>
>I certainly think it would be much more confusing for Newbies to find=20
>rational objects showing up and possibly slowing their computation when=20
>they least expect it.
>
>Guido is right that rationals should be off to the side a bit and not=20
>show up in any computations unless expressly introduced by the user. =20
>
Why not a way to introduce special rules for a limited scope? E.g., if there
were a 'scope' keyword that would introduce in indented block where the rules
would apply, and a dictionary defining rules and hooks. Then you could write

    scope rational_rules:
        a = b/c         # the '/' operator coerces to rational, let's say
        blah()          # blah's internal rules would not be affected
    d = a		# would have to act according to enclosing scope

rational_rules might be {'enter_scope':__enter_rational__,
                         'leave_scope':__leave_rational__,
                         'exception_hook': __rational_exception__, ...}

More than one set of rules is conceivable, as a sequence of dictionaries.
This would allow calling some C magic for messing with internal state as needed for
efficient implementation of standardly available scope rules, or doing
stuff in Python. This is just OTTOMH this moment, but I thought it might be interesting
to post before I forget it ;-)

You could import stuff (e.g., from __future__) or whatever. The scope keyword would
generate compiler code to call the hooks from the mandatory rules dictionary
(or expression evaluating to a dictionary) following. I threw in something for escaping
exception handling, in case some processing  was needed/desired

>I think complex numbers are a good model -- naive users can pretty much=20
>ignore their presence altogether and not get into trouble.
>
>>So it might be more
>>worth accepting as a community to warn programmers who are more prone to
>>numerical algorithms of the intrinsic dangers of integer division in Pyt=
>hon.
>>
>
>I personally think the "dangers" of integer division have been vastly=20
>exaggerated.  Integer division is older than computers and it's really a=20
>trivial concept.  The answer cannot be represented accurately so instead=20
>you get an approximation.  Furthermore, integer division and integer=20
>modulo together DO produce a complete and exact answer -- a whole number=20
>quotient and a remainder.  In my experience, when dealing with integers,=20
>the original integer division result (and the modulo) is more useful in=20
>practice than the "more accurate" floating point result. =20
>
You'd probably like

    scope classic_division:
        assert 3/4==0
        ...

for some stuff ?

>That decision is water over the bridge.  But substituting a rational for=20
>the present floating point result would only be more confusing.

Unless, perhaps, it could be limited explicitly to a particular scope.
I'm sure there's a lot of sneaky issues involving state created within
a special scope being referenced from a different (maybe differently special
or ordinary) scope, but that's further along the discussion. The first part
is would it be a natural-feeling way to express coding intent. The rest would
be a SMIP ("simple" matter of implementation ;-)

Regards,
Bengt Richter