[Numpy-discussion] can_cast with structured array output - bug?
Tue Feb 14 22:53:00 CST 2012
On Tue, Feb 14, 2012 at 7:19 PM, Matthew Brett <email@example.com>wrote:
> On Mon, Feb 13, 2012 at 7:02 PM, Mark Wiebe <firstname.lastname@example.org> wrote:
> > I took a look into the code to see what is causing this, and the reason
> > that nothing has ever been implemented to deal with the fields. This
> > it falls back to treating all struct dtypes as if they were a plain
> > 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
> > '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
> > 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
> See you,
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion