On Thursday 29 March 2007 14:40:35 Bryce Hendrix wrote:
> Yup, we've decided to write custom concatenate & where methods. Thanks
> for all the help.
Don't mention it, my pleasure.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projec
Yup, we've decided to write custom concatenate & where methods. Thanks
for all the help.
Bryce
Pierre GM wrote:
On Thursday 29 March 2007 14:09:38 Bryce Hendrix wrote:
I really should widen my tests before proclaiming success... If you
change the default units to "feet", the result of conc
On Thursday 29 March 2007 14:09:38 Bryce Hendrix wrote:
> I really should widen my tests before proclaiming success... If you
> change the default units to "feet", the result of concatenating two
> UnitArrays instances with "meters" units is a UnitArray with "feet".
Not a surprise at all, and I sh
Yeah, I think we may need to write some custom wrapper functions for the
functions we use which don't call __new__. I don't really see another
way around it since by the time __array_finalize__ gets called there are
no units and the problems with mixed units.
bryce
Pierre GM wrote:
On Thursd
I really should widen my tests before proclaiming success... If you
change the default units to "feet", the result of concatenating two
UnitArrays instances with "meters" units is a UnitArray with "feet".
Bryce
Pierre GM wrote:
On Thursday 29 March 2007 12:04:51 Bryce Hendrix wrote:
I spo
On Thursday 29 March 2007 13:47:48 Bryce Hendrix wrote:
> doh! I followed the example on the Wiki which does not define the class
> attribute in the class scope, but in __new__. Adding the declaration to
> the class scope seems to work.
Yeah, sorry about that, I really should update this wiki page
doh! I followed the example on the Wiki which does not define the class
attribute in the class scope, but in __new__. Adding the declaration to
the class scope seems to work.
Thanks,
Bryce
Pierre GM wrote:
On Thursday 29 March 2007 12:04:51 Bryce Hendrix wrote:
I spoke too soon, this code
On Thursday 29 March 2007 12:04:51 Bryce Hendrix wrote:
> I spoke too soon, this code fails with the example you gave:
mmh, I tried to use the class you linked to last time: the only modifications
I gave are listed below
class UnitArray(numpy.ndarray):
__array_priority__ = 10.0
default_u
I spoke too soon, this code fails with the example you gave:
def test_concatenate(self):
unit_ary_1 = UnitArray(numpy.array((1,2,3)), units=meters)
unit_ary_2 = UnitArray(numpy.array((1,2,3)), units=meters)
# create another instance with different units. This instance
# is never used, but ca
On Wednesday 28 March 2007 12:42:52 Bryce Hendrix wrote:
> Thanks Pierre, works like a charm. One question though, how is defining
> a class attribute in __new__ any more thread-safe?
It's not, of course, and that's why it shouldn't be used. However, it's quite
convenient and easier to use, and d
Thanks Pierre, works like a charm. One question though, how is defining
a class attribute in __new__ any more thread-safe?
Bryce
Pierre GM wrote:
On Tuesday 27 March 2007 20:08:04 Bryce Hendrix wrote:
We have a class which is a subclass of ndarray which defines
__array_finalize__ to add an
On Tuesday 27 March 2007 20:08:04 Bryce Hendrix wrote:
> We have a class which is a subclass of ndarray which defines
> __array_finalize__ to add an attribute. The class looks something like
> this:
Ahah, we ran into this problem a few months ago:
You should not initialize your "units" attribute i
We have a class which is a subclass of ndarray which defines
__array_finalize__ to add an attribute. The class looks something like
this:
class UnitArray(ndarray):
# ...
def __new__(cls, data, dtype=None, copy=True, units=None):
# ...
arr = array(data, dtype=dtype, copy=copy)
res = nd
13 matches
Mail list logo
