Comment on PEP-0238

[Tim Peters]

[Tim]
> BTW, state-of-the-art rational support also requires context,  to
determine
> whether results should be reduced to lowest terms (some  programs run
1000s
> of times faster if you don't, others 1000s of times faster if you do, and
only the
> algorithm author can know which is better).

[Marcin 'Qrczak'  Kowalczyk]
> If such context affects only performance, then maybe it's acceptable,
> but if it affects essential semantics,

For most people, whether they get results back in their lifetimes is
important despite being "only performance".

> I'm worried that it's a bad idea to introduce global state where it
doesn't exist in
> the problem domain.

In finite arithmetic, precision is part of the problem domain, like it or
not.  Ditto rounding and exception policies, and that "one default size fits
all" policies don't work.

> The more global settings affect the meaning of a piece of code, the
> harder is to use independent modules together and to understand code
> in isolation.

So it goes.  You can write wrappers that require explicitly passing all
context info to every arithmetic operation, and explicitly collects the
outputs too; but most people will prefer implicit state so they can continue
writing

    x = y + z

instead of

    x, non_fatal_conditions = add(y, z, precision, rounding_mode,
exception_masks)

Even if you reduce that to

    x, context = add(y, z, context)

it's still a PITA.  Note that your HW 754 fp is already swimming in global
(really thread-local, if the OS and libraries aren't insane) state; you
usually don't notice it (unless you're a serious numeric programmer) simply
because no name-brand language has yet bothered to expose it in a portable
way (C99 is the first big stab at this).

finite-numerics-can't-be-understood-"in-isolation"-ly y'rs  - tim