[Numpy-discussion] fromfile() -- aarrgg!

Christopher Barker Chris.Barker@noaa....
Mon Jan 11 18:11:26 CST 2010


Pauli Virtanen wrote:
> Thu, 07 Jan 2010 17:21:34 -0800, Christopher Barker wrote:
> [clip]
>> It does pass on that return value, but, from ctors.c:
>>
>> fromfile_next_element(FILE **fp, void *dptr, PyArray_Descr *dtype,
>>                        void *NPY_UNUSED(stream_data))
>> {
>>      /* the NULL argument is for backwards-compatibility */ return
>>      dtype->f->scanfunc(*fp, dptr, NULL, dtype);
>> }
> 
> This functions is IMHO where the fix should go; I believe it should do 
> something like
> 
> 	return (ret == 0 || ret == EOF) ? -1 : ret;

OK, more digging (and printf debugging -- I really need to learn to 
debug C extensions properly). I've found the deeper issue:

NumPyOS_ascii_strtod returns a 0.0 when given invalid input, such as " 
,". That's why fromstring is putting in a 0.0 for empty (and invalid) 
fields.

Diggin into NumPyOS_ascii_strtod(), it looks like it is simply a wrapper 
around PyOS_ascii_strtod(), that checks for NaN and Inf first (and 
somethign with teh decimal point, I dont' quite get). But anyway, if it 
is a regular old number, it gets passed of to PyOS_ascii_strtod(), which 
isn't outragiously well documented (no, I havne't gone to the source, 
yet), but is similar to the C stdlib srtod(), which says:

"If no conversion is performed, zero is returned and the value of nptr 
is stored in the location referenced by endptr."

off do do some more testing, but I guess that means that those pointers 
need to be checked after the call, to see if a conversion was generated.

Am I right?

-Chris

PS: Boy, this is a pain!






-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


More information about the NumPy-Discussion mailing list