C Module's '1.#INF' changes to 'inf' at Python

[CELEN Erman]

Hi All,

 

My problem is that I've noticed a strange behavior in Python while handling FPEs on Windows after switching compilers (msvc8 to msvc9) and I am trying to find out how Python handles INF values to figure out where the problem might be. 

 

The problem appeared when we noticed that behavior of Numeric (older version of NumPy) library has changed when dealing with Floating-Point Exceptions. We are building our own slightly modified version of Python in-house (including Numeric/NumPy) and when we switched from the msvc8 to msvc9 compiler, Numeric started to return '-inf' as a result of 'Numeric.log10(0.0)' instead of rasing an OverflowError. I know that Numeric is using umath instead of the math library and since math.log10(0.0) is still raising an Error (which is ValueError in 2.6 and OverflowError in 2.4, but still an error) I thought that it might have something to do with how umath or Numeric handles the input or return values of log functions.

 

Before hunting blindly I wanted to see how Python interprets INF results. I built a simple module with only one function that causes an FPE with log10(0.0) using C's math library and prints the results with printf. Then I imported that module from python, called the function and printed the result in python too to see if there are any differences between two values (which I found out that there are)

 

Here is the that part of the code from my C Python module:

 

static PyObject *badNum(PyObject *self, PyObject *args)

{

    int sts = 0; //Not used, just dummy

 

    double a = 0.0;

    double c = 0.0;

    

    if (!PyArg_ParseTuple(args, "i", &sts)) //Dummy check, no use

        return NULL;

    

    disableFPEs();

    c = log10(a); //Since FPEs disabled, should return '-1.#INF'

    enableFPEs();

 

    printf("C-Val: %f\n", c);

    

    return Py_BuildValue("d", c);

}

 

After I build the module and imported it into Python, I called the function and printed the return value in Python. The output was different in two versions of Python:

 

Output1 (Module was built with msvc8 and run by python24)

C-Val: -1.#INF

Py-Val: -1.#INF

 

Output2 (Module was built with msvc9 and run by python26)

C-Val: -1.#INF

Py-Val: -inf

 

I now know that compiler change didn't cause any change in return value of log10(0.0) at C level (both compilations resulted in '-1.#INF') so I am thinking that somehow at somewhere in Python core the value is translated into '-inf' and that might be the reason why Numeric/NumPy is missing the problem and having issues raising OverflowError like it's supposed to.

 

I started debugging Python.exe (with my module loaded) in Visual Studio. While tracing what's happening after the line "return Py_BuildValue("d", c);" I went down to the "floatobject.c " file (which I thought is highly relevant to floating-point value conversions) and in particular "format_float()" function but since I am not that familiar with Python internals, I am having trouble pinpointing the issue and the code where the "conversion" is happening and I can't even be sure if I am looking at the right place.

 

I would appreciate if someone could help me out or at least could point me to the right direction so that I can figure out the rest.

 

Thanks,

 

Best Regards,

 

Ali Erman CELEN

Platform Specialists / Porting

Dassault Systèmes I www.3ds.com <http://www.3ds.com/> 



This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.  If you are not one of the named recipients or have received this email in error, (i) you should not read, disclose, or copy it, (ii) please notify sender of your receipt by reply email and delete this email and all attachments, (iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.For other languages, go to http://www.3ds.com/terms/email-disclaimer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100108/af757be5/attachment.html>