"Jim Jewett" <[EMAIL PROTECTED]> wrote:
>
> > The conventional interpretation was that any operation that
> > was not mathematically continuous in an open region including its
> > argument values (in the relevant domain) was an error, and that all
> > such errors should be flagged. That is what I am talking about.
>
> Not a bad goal, but not worth sweating over, since it isn't
> sufficient. It still allows functions whose continuity does not
> extend to the next possible floating point approximation, or functions
> whose value, while continuous, changes "too much" in that region.
Oh, yes, quite. But I wasn't describing something that needed effort;
I was merely describing the criterion that was traditionally used (and
still is, see below). There is also the Principle of Least Surprise:
the behaviour of a language should be at least explicable to mere
mortals (a.k.a. ordinary programmers) - one that says "whatever the
designing committee thought good at the time" is a software engineering
disaster.
> For some uses, it is more important to be consistent with established
> practice than to be as correct as possible. If the issues are still
> problems, and can't be solved in languages like java, then ... the
> people who want "correct" behavior will be a tiny minority, and it
> makes sense to have them use a 3rd-party extension.
I don't think that you understand the situation.
I was and am describing established practice, as used by the numeric
programmers who care about getting reliable answers - most of those
still use Fortran, for good and sufficient reasons. There are two
other established practices:
Floating-point is figment of your imagination - don't support it.
Yeah. Right. Whatever. It's only approximate, so who gives a
damn what it does?
Mine is the approach taken by the Fortran, C and C++ standards
and many Fortran implementations, but the established practice in
highly optimised Fortran and most C is the last. Now, Java (to
some extent) and C99 introduced something that attempts to eliminate
errors by defining what they do (more-or-less arbitrarily); much as
if Python said that, if a list or dictionary entry wasn't found, it
would create one and return None. But that is definitely NOT
established practice, despite the fact that its proponents claim it
is. Even IEEE 754 (as specified) has never reached established
practice at the language level.
The very first C99 Annex F implementation that I came across appeared
in 2005 (Sun One Studio 9 under Solaris 10 - BOTH are needed); I have
heard rumours that HP-UX may have one, but neither AIX nor Linux does
(even now). I have heard rumours that the latest Intel compiler may be
C99 Annex F, but don't use it myself, and I haven't heard anything
reliable either way for Microsoft. What is more, many of the tender
documents for systems bought for numeric programming in 2005 said
explicitly that they wanted C89, not C99 - none asked for C99 Annex F
that I saw. No, C99 Annex F is NOT established practice and, God
willing, never will be.
> > For example, consider conversion between float
> > and long - which class should control the semantics?
>
> The current python approach with binary fp is to inherit from C
> (consistency with established practice). The current python approach
> for Decimal (or custom classes) is to refuse to guess in the first
> place; people need to make an explicit conversion. How is this a
> problem?
See above re C extablished practice.
The above is not my point. I am talking about the generic problem
where class A says that overflow should raise an exception, class B
says that it should return infinity and class C says nothing. What
should C = A*B do on overflow?
> [ Threading and interrupts ]
No, that is a functionality issue, but the details are too horrible
to go into here. Python can do next to nothing about them, except
to distrust them - just as it already does.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: [EMAIL PROTECTED]
Tel.: +44 1223 334761 Fax: +44 1223 334679
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
