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

Mark Wiebe mwwiebe@gmail....
Tue Feb 14 22:53:00 CST 2012


On Tue, Feb 14, 2012 at 7:19 PM, Matthew Brett <matthew.brett@gmail.com>wrote:

> 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?
>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20120214/e59a470f/attachment.html 


More information about the NumPy-Discussion mailing list