Re: [Numpy-discussion] can_cast with structured array output - bug?
Hi, On Mon, Feb 13, 2012 at 7:02 PM, Mark Wiebe mwwi...@gmail.com wrote: I took a look into the code to see what is causing this, and the reason is that nothing has ever been implemented to deal with the fields. This means it falls back to treating all struct dtypes as if they were a plain void dtype, which allows anything to be cast to it. While I was redoing the casting subsystem for 1.6, I did think on this issue, and decided that it wasn't worth tackling it at the time because the 'safe'/'same_kind'/'unsafe' don't seem sufficient to handle what might be desired. I tried to leave this alone as much as possible. Some random thoughts about this are: * Casting a scalar to a struct dtype: should it be safe if the scalar can be safely cast to each member of the struct dtype? This is the NumPy broadcasting rule applied to dtypes as if the struct dtype is another dimension. * Casting one struct dtype to another: If the fields of the source are a subset of the target, and the types can safely convert, should that be a safe cast? If the fields of the source are not a subset of the target, should that still be a same_kind cast? Should a second enum which complements the safe/same_kind/unsafe one, but is specific for how adding/removing struct fields be added? This is closely related to adding ufunc support for struct dtypes, and the choices here should probably be decided at the same time as designing how the ufuncs should work. Thanks for the discussion - that's very helpful. How about, at a first pass, returning True for conversion of void types only if input dtype == output dtype, then adding more sophisticated rules later? See you, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] can_cast with structured array output - bug?
On Tue, Feb 14, 2012 at 7:19 PM, Matthew Brett matthew.br...@gmail.comwrote: Hi, On Mon, Feb 13, 2012 at 7:02 PM, Mark Wiebe mwwi...@gmail.com wrote: I took a look into the code to see what is causing this, and the reason is that nothing has ever been implemented to deal with the fields. This means it falls back to treating all struct dtypes as if they were a plain void dtype, which allows anything to be cast to it. While I was redoing the casting subsystem for 1.6, I did think on this issue, and decided that it wasn't worth tackling it at the time because the 'safe'/'same_kind'/'unsafe' don't seem sufficient to handle what might be desired. I tried to leave this alone as much as possible. Some random thoughts about this are: * Casting a scalar to a struct dtype: should it be safe if the scalar can be safely cast to each member of the struct dtype? This is the NumPy broadcasting rule applied to dtypes as if the struct dtype is another dimension. * Casting one struct dtype to another: If the fields of the source are a subset of the target, and the types can safely convert, should that be a safe cast? If the fields of the source are not a subset of the target, should that still be a same_kind cast? Should a second enum which complements the safe/same_kind/unsafe one, but is specific for how adding/removing struct fields be added? This is closely related to adding ufunc support for struct dtypes, and the choices here should probably be decided at the same time as designing how the ufuncs should work. Thanks for the discussion - that's very helpful. How about, at a first pass, returning True for conversion of void types only if input dtype == output dtype, then adding more sophisticated rules later? That's a very good approach, thanks. I've created a ticket in the bug tracker so this doesn't get lost, and can be triaged alongside the other issues. http://projects.scipy.org/numpy/ticket/2055 Cheers, Mark See you, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] can_cast with structured array output - bug?
Hi,
I've also just noticed this oddity:
In [17]: np.can_cast('c', 'u1')
Out[17]: False
OK so far, but...
In [18]: np.can_cast('c', [('f1', 'u1')])
Out[18]: True
In [19]: np.can_cast('c', [('f1', 'u1')], 'safe')
Out[19]: True
In [20]: np.can_cast(np.ones(10, dtype='c'), [('f1', 'u1')])
Out[20]: True
I think this must be a bug.
In the other direction, it makes more sense to me:
In [24]: np.can_cast([('f1', 'u1')], 'c')
Out[24]: False
In [25]: np.can_cast([('f1', 'u1')], [('f1', 'u1')])
Out[25]: True
Best,
Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] can_cast with structured array output - bug?
I took a look into the code to see what is causing this, and the reason is
that nothing has ever been implemented to deal with the fields. This means
it falls back to treating all struct dtypes as if they were a plain void
dtype, which allows anything to be cast to it.
While I was redoing the casting subsystem for 1.6, I did think on this
issue, and decided that it wasn't worth tackling it at the time because the
'safe'/'same_kind'/'unsafe' don't seem sufficient to handle what might be
desired. I tried to leave this alone as much as possible.
Some random thoughts about this are:
* Casting a scalar to a struct dtype: should it be safe if the scalar can
be safely cast to each member of the struct dtype? This is the NumPy
broadcasting rule applied to dtypes as if the struct dtype is another
dimension.
* Casting one struct dtype to another: If the fields of the source are a
subset of the target, and the types can safely convert, should that be a
safe cast? If the fields of the source are not a subset of the target,
should that still be a same_kind cast? Should a second enum which
complements the safe/same_kind/unsafe one, but is specific for how
adding/removing struct fields be added?
This is closely related to adding ufunc support for struct dtypes, and the
choices here should probably be decided at the same time as designing how
the ufuncs should work.
-Mark
On Mon, Feb 13, 2012 at 5:20 PM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
I've also just noticed this oddity:
In [17]: np.can_cast('c', 'u1')
Out[17]: False
OK so far, but...
In [18]: np.can_cast('c', [('f1', 'u1')])
Out[18]: True
In [19]: np.can_cast('c', [('f1', 'u1')], 'safe')
Out[19]: True
In [20]: np.can_cast(np.ones(10, dtype='c'), [('f1', 'u1')])
Out[20]: True
I think this must be a bug.
In the other direction, it makes more sense to me:
In [24]: np.can_cast([('f1', 'u1')], 'c')
Out[24]: False
In [25]: np.can_cast([('f1', 'u1')], [('f1', 'u1')])
Out[25]: True
Best,
Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
