How to represent the infinite ?
huaiyu at gauss.almadan.ibm.com
Tue Jun 25 04:24:30 CEST 2002
Tim Peters <tim.one at comcast.net> wrote:
>> 1. Most platforms these days support 754 to a remarkably good degree, far
>> better than that is allowed in today's Python.
>The support code required at the C level is platform-specific, and needs a
>phalanx of cooperative platform experts to contribute it. Slash and burn
>will not lead to a good and maintainable result.
OK, so I infer that
- each platform may well support 754 to a good degree
- there is probably a common subset that is good enough and large enough
- but they are not invoked the same way, so that a simple approach may only
support a small set of features and being incorrect on other features in
This is quite discouraging to hear. Maybe someone knowledgeable enough can
compile a list of major features on major platforms. Maybe for suitably
defined set of major features and major platforms, the cost is not high
enough to overwhelm the benefit. Once there is a start it might become
easier to enlarge the subset.
>> 2. Most number crunchers would be more concerned that it works as well as
>> possible on the platforms available to them, rather than whether it
>> also works on other platforms.
>As I said above, that's why the NumPy community has to agree first. The
>overwhelming majority of plain-core Python users are not number crunchers,
>and don't know a NaN from an umlaut. Giving them either 1j or a NaN from
>sqrt(-1) is a Bad Idea. I would often like 1j or a NaN in my own apps --
>but I often want the ValueError Python tries to deliver in that case too.
I realize that there are (at least) two types of numerical calculations,
those where the calculation determines the error bounds, and those where the
error bounds are calculated separately. The former is likely to occur in
traditional engineering with quite deterministic data, and the latter is
likely to occur in data mining and statistical applications with lots of
uncertainties. So I can see the point that a proper implementation would
have to have a choice whether overflow generates an exception.
Before that happens (and I understand that is going to be a long time), I'd
like to see overflow exception raised only once for each vector, with proper
information in the exception denoting which element encountered it first.
This is not likely to upset those who want to see the exceptions, while
making it much easier to ignore the exceptions if one wants. I'm not sure
whether this is a core Python issue or NumPy issue, though.
More information about the Python-list