David Cournapeau wrote: > Robert Kern wrote: >> David Cournapeau wrote: >>> Robert Kern wrote: >>>> David Cournapeau wrote: >>>> >>>>> 2: the old implementation does not upcast the input array. If the >>>>> input is int32, and min/max are float32, the function fails; if input is >>>>> float32, and min/max float64, the output is still float32. Again, this >>>>> seems against the expected numpy behaviour ? >>>> The latter is expected. As discussed previously here, >>> Could you tell me where this was discussed, I think I missed it. >> http://projects.scipy.org/pipermail/numpy-discussion/2006-November/024402.html > Ok, thank you. >>> Thanks for the precision. Is this the expected behaviour for endianness, >>> too ? >> What endianness behaviour? > This (assuming your machine is little endian): > > In [1]: import numpy > > In [2]: a = numpy.random.randn(3, 2) > > In [3]: b = a.astype(a.dtype.newbyteorder('>')) > > In [4]: a.clip(0., 1.).dtype.isnative > Out[4]: True > > In [5]: b.clip(0., 1.).dtype.isnative > Out[5]: False > > In [6]: b.clip(numpy.zeros(b.shape), 1.).dtype.isnative > Out[6]: True > > If input is byteswapped, the output is also byteswapped for scalar > min/max, but native if a native array is given as a min/max argument.
Yes, that seems to fit in with the rule. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
