How to represent the infinite ?

Huaiyu Zhu huaiyu at gauss.almadan.ibm.com
Fri Jun 21 21:50:14 EDT 2002


Each time we are having this conversation we go around the same circle once
or twice.  Let's see if we can find a way out.  I would like to divide the
issue into three (still somewhat arbitrary) sub-issues, and see if any one
of them can be resolved in easier/simpler/clearer ways:

1. How much 754 support is provided by the underlying platforms.
2. How do such support vary across the platforms.
3. What are the Python designers' wishes.

Tim Peters <tim.one at comcast.net> wrote:
>
>It has nothing to do with Windows specifically; Python's 754 behavior "is
>random" on all platforms, in platform-specific ways, because Python is
>implemented in C, platform C 754 behavior "is (still) random", and the only
>code ever contributed to address this sorry state of affairs is the fpectl
>module (whose purpose is in a direction opposite the one you favor).

I think you are talking about sub-issue 2 here.  Is there some place we can
find out what these variations are, and how severe they are?

I can certainly contribute "the patch to enable inf and nan in Python" :-)
(attached), but I'm sure that's not the reason you are against it.

In any case I'd like to see what problems people report on different
platforms.


>> Since it could be made to work on Linux, I simply commented out
>> the checking in pyport.h.  Voila, instant ieee compliance!
>
>You happened to get one particular 754 behavior you like; full IEEE
>compliance is a large and difficult task; subset compliance is worse than
>none (if we're to believe Kahan's virulent rants about Java <wink>).

I think you are talking about sub-issue 1 here.  Do you actually believe
that subset-compliance is worse than none?  I'd think that would depend on
what subset we are talking about.  Certainly "can't provide full support"
does not imply "avoid as much as possible".  There must be some concrete
criteria that are omitted here.


>> Your example appears to show that Windows can also live with nan and inf.
>
>Virtually all platforms can, given enough platform-specific support code,
>almost none of which Python has.
>
>> So my question is, are there any significant platforms out there
>> that still really need such checkings which make nan and inf almost
>> useless?
>
>If Python were 100% 754-conforming, Guido and I would still favor enabling
>exceptions on overflow, divide-by-zero, and invalid operation, by default.
>As things are, you've got no choice at all, unless you want such exceptions
>enabled and are on a platform where the fpectl module happens to work.

I think you are talking about sub-issue 3 here.  Could you provide a
rationale in the context of numerical computation?

I can offer an example in support of the opposite side.  Suppose x is a
vector containing elements that might be arbitrarily large, then

	   exp(-x**2)

might involve inf at certain elements, yet the result is perfectly regular,
containing only floats between 0 and 1.  How can this be done by vectorized
computation if individual elements may throw exceptions?


Certainly you and Guido have the final say on sub-issue 3.  On the other two
issues, however, I suspect that

1. Most platforms these days support 754 to a remarkably good degree, far
   better than that is allowed in today's Python.

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.

3. The variations across major platforms are minor.


I'd like to hear people confirm or deny these suspicions.  If answering
these questions is easier than answering the "should or shouldn't" question,
then the state of affairs could be advanced a little bit by considering
these questions first.


Huaiyu


PS. Here's the patch:


This patch removes the code that generate an OverflowError for 1e200**2.
It is generated  with:
diff -rcN Python-2.2.1 Python-2.2.1.ieee > python-2.1.1-ieee-fpu.patch

It can be applied as
patch -p1 -d Python-2.2.1 < python-2.1.1-ieee-fpu.patch

Afterwards, it is still necesary to modify Makefile to add -lieee to LIBS.
This itself can be changed by using autoconf, but I've forgotten how to do
it.  The second part of the patch does that.


diff -rcN Python-2.2.1/Include/pyport.h Python-2.2.1.ieee/Include/pyport.h
*** Python-2.2.1/Include/pyport.h	Mon Mar 11 02:16:23 2002
--- Python-2.2.1.ieee/Include/pyport.h	Wed May  8 15:20:30 2002
***************
*** 301,311 ****
   */
  #define Py_ADJUST_ERANGE1(X)						\
  	do {								\
! 		if (errno == 0) {					\
  			if ((X) == Py_HUGE_VAL || (X) == -Py_HUGE_VAL)	\
  				errno = ERANGE;				\
  		}							\
! 		else if (errno == ERANGE && (X) == 0.0)			\
  			errno = 0;					\
  	} while(0)
  
--- 301,311 ----
   */
  #define Py_ADJUST_ERANGE1(X)						\
  	do {								\
! 		/*if (errno == 0) {					\
  			if ((X) == Py_HUGE_VAL || (X) == -Py_HUGE_VAL)	\
  				errno = ERANGE;				\
  		}							\
! 		else */ if (errno == ERANGE && (X) == 0.0)			\
  			errno = 0;					\
  	} while(0)
  
***************
*** 313,320 ****
  	do {								\
  		if ((X) == Py_HUGE_VAL || (X) == -Py_HUGE_VAL ||	\
  		    (Y) == Py_HUGE_VAL || (Y) == -Py_HUGE_VAL) {	\
! 				if (errno == 0)				\
! 					errno = ERANGE;			\
  		}							\
  		else if (errno == ERANGE)				\
  			errno = 0;					\
--- 313,320 ----
  	do {								\
  		if ((X) == Py_HUGE_VAL || (X) == -Py_HUGE_VAL ||	\
  		    (Y) == Py_HUGE_VAL || (Y) == -Py_HUGE_VAL) {	\
! 			/*	if (errno == 0)				\
! 				errno = ERANGE; */			\
  		}							\
  		else if (errno == ERANGE)				\
  			errno = 0;					\
diff -rcN Python-2.2.1/configure.in Python-2.2.1.ieee/configure.in
*** Python-2.2.1/configure.in	Mon Mar 11 02:14:23 2002
--- Python-2.2.1.ieee/configure.in	Wed May  8 15:47:07 2002
***************
*** 1777,1786 ****
  # (none yet)
  
  # Linux requires this for correct f.p. operations
! AC_CHECK_FUNC(__fpu_control,
!   [],
!   [AC_CHECK_LIB(ieee, __fpu_control)
! ])
  
  # Check for --with-fpectl
  AC_MSG_CHECKING(for --with-fpectl)
--- 1777,1787 ----
  # (none yet)
  
  # Linux requires this for correct f.p. operations
! #AC_CHECK_FUNC(__fpu_control,
! #  [],
! #  [AC_CHECK_LIB(ieee, __fpu_control)
! #])
! AC_CHECK_LIB(ieee, __fpu_control)
  
  # Check for --with-fpectl
  AC_MSG_CHECKING(for --with-fpectl)
diff -rcN Python-2.2.1/pyconfig.h.in Python-2.2.1.ieee/pyconfig.h.in
*** Python-2.2.1/pyconfig.h.in	Wed Oct 24 10:10:49 2001
--- Python-2.2.1.ieee/pyconfig.h.in	Wed May  8 15:53:51 2002
***************
*** 748,754 ****
  #undef HAVE_LIBDLD
  
  /* Define if you have the ieee library (-lieee).  */
! #undef HAVE_LIBIEEE
  
  #ifdef __CYGWIN__
  #ifdef USE_DL_IMPORT
--- 748,754 ----
  #undef HAVE_LIBDLD
  
  /* Define if you have the ieee library (-lieee).  */
! #define HAVE_LIBIEEE
  
  #ifdef __CYGWIN__
  #ifdef USE_DL_IMPORT



More information about the Python-list mailing list