[Numpy-discussion] fromfile() -- aarrgg!
Christopher Barker
Chris.Barker at noaa.gov
Mon Jan 11 19:11:26 EST 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 at noaa.gov
More information about the NumPy-Discussion
mailing list