A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-March/021660.html below:

[Python-Dev] 2.2.1c1 platform reports.

[Python-Dev] 2.2.1c1 platform reports.Tim Peters tim.one@comcast.net
Fri, 22 Mar 2002 18:57:43 -0500
[Martin]
> Is that the final text? My copy says
>
>        On a domain error, the function returns an
>        implementation-defined value; if the integer expression
>        math_errhandling & MATH_ERRNO is nonzero, the integer
>        expression errno acquires the value EDOM; if the integer
>        expression math_errhandling & MATH_ERREXCEPT is nonzero, the
>        ``invalid'' floating-point exception is raised.
>
> but it comes from a draft only (99-04).

Mine also comes from a draft, dated 2000-08-07.  Jeremy bought the final
std, but good luck hassling him to look stuff up for us <wink>.

> If this is what C99 says, you actually can tell, in C, whether checking
> errno will help indicating the error.

And when it doesn't, we're back to guessing.  We already take advantage of
sqrt(-1) setting EDOM on those platforms where it does.  I don't see any
simplification.

> If the C implementation also implements Annex F, IEEE-754 fans should
> be satisfied, no?

Python doesn't know anything about Annex F now -- those facilities may as
well not exist given our current code.  Python's users are in two very
different camps too:  some want sqrt(-1) to blow up, and others want to get
back a NaN without exception.  Similarly for overflow and divide-by-zero,
etc.  C99 + Annex F is, from Python's current POV, just another unique
platform Python knows nothing about.




RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4