[Numpy-discussion] can_cast with structured array output - bug?

Matthew Brett matthew.brett@gmail....
Tue Feb 14 21:19:00 CST 2012


Hi,

On Mon, Feb 13, 2012 at 7:02 PM, Mark Wiebe <mwwiebe@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


More information about the NumPy-Discussion mailing list