Christopher Barker wrote: > static int > @fn...@_fromstr(char *str, @type@ *ip, char **endptr, PyArray_Descr > *NPY_UNUSED(ignore)) > { > double result; > result = NumPyOS_ascii_strtod(str, endptr); > *ip = (@type@) result; > return 0; > }
OK, I've done the diagnostics, but not all of the fix. Here's the issue: numpyos.c: NumPyOS_ascii_strtod() Was incrementing the input pointer to strip out whitespace before passing it on to PyOS_ascii_strtod(). So the **endptr getting passed back to @fn...@_fromstr didn't match. I've fixed that -- so now it should be possible to check if str and *endptr are the same after the call, to see if a double was actually read -- I"m not suite sure what to do in that case, but a return code is a good start. However, I also took a look at integers. For example: In [39]: np.fromstring("4.5, 3", sep=',', dtype=np.int) Out[39]: array([4]) clearly wrong -- it may be OK to read "4.5" as 4, but then it stops, I guess because there is a ".5" before the next sep. Anyway, not the best solution. However, in this case, the function is here: @fn...@_fromstr(char *str, @type@ *ip, char **endptr, PyArray_Descr *NPY_UNUSED(ignore)) { @btype@ result; result = pyos_st...@func@(str, endptr, 10); *ip = (@type@) result; printf("In int fromstr - result: %i\n", result ); printf("In int fromstr - str: '%s', %p %p\n", str, str, *endptr); return 0; } so it's calling PyOS_strtol(), which when called on "4.5" returns 4 -- which explains the abive behaviou -- but how to know that that wasn't a proper reading? This really is a mess! Since there was just some talk about a 1.4.1 -- I'd like to get some of this fixed before then -Chris -- 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.bar...@noaa.gov _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion