[Numpy-discussion] major bug in fromstring, ascii mode
Charles R Harris
Sun Jan 27 14:48:37 CST 2008
On Jan 27, 2008 12:40 PM, Eric Firing <firstname.lastname@example.org> wrote:
> Pauli Virtanen wrote:
> That is it exactly. The code in core/src/arraytypes.inc.src is using
> scanf, and scanf tries hard to recognize integers specified in different
> ways. So, what caught me is a feature, not a bug, and I should have
> recognized it as such right away. The bug was in my expectations, not
> in the code.
> > This is a bit surprising, and whether this is the desired behavior is
> > questionable.
> From a user's standpoint it would be nice to be able to have numbers
> with leading zeros interpreted as base 10 instead of octal, since this
> turns up any time one converts date and time-of-day strings, and can
> occur in many other contexts also. (Outside of computer science octal is
> rare, as far as I know.) It looks like supporting this would require
> quite a bit of change in the code, however. I suspect it would have to
> go in as a kwarg that would be propagated through several layers of C
> function calls. Otherwise, if octal conversion support were simply
> dropped, I suspect someone else's code would break, and equally
> reasonable expectations would be violated.
I don't think the problem is scanf, at least not here. The following code
snippet works fine for me.
int main(int argc, char** argv)
sscanf(argv, "%d :%d :%d", &a, &b, &c);
printf("%d %d %d\n", a, b, c);
$[charris@f8 scratch]$ ./a.out "23:09:01"
23 9 1
Maybe it acts differently for files?
$[charris@f8 scratch]$ echo "23:09:01" > tmp
$[charris@f8 scratch]$ ./a.out
23 9 1
Nope, that works fine also. Numpy is making a type decision somewhere else.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion