On Tue, Feb 14, 2012 at 7:19 PM, Matthew Brett <matthew.br...@gmail.com>wrote:
> 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
