I have a Range Trait defined like this:
tilt = Range(low=0.0, high = 90.0) When I try to assign values of a GDAL.ReadAsArray to it, which comes with a dtype='float32' it is rejected: ====== In [65]: slope.data.dtype Out[65]: dtype('float32') In [66]: val = slope.data[1,1] In [67]: val Out[67]: 10.044398 In [68]: val.dtype Out[68]: dtype('float32') In [69]: mspice.tilt = val --------------------------------------------------------------------------- TraitError Traceback (most recent call last) <ipython-input-69-d0f06854ae1f> in <module>() ----> 1 mspice.tilt = val /Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/traits/trait_handlers.py in error(self, object, name, value) 168 """ 169 raise TraitError( object, name, self.full_info( object, name, value ), --> 170 value ) 171 172 def arg_error ( self, method, arg_num, object, name, value ): TraitError: The 'tilt' trait of a MarsSpicer instance must be 0.0 <= a floating point number <= 90.0, but a value of 10.044398 <type 'numpy.float32'> was specified. ======== When I convert to a float64, it works fine. Regards, Michael _______________________________________________ Enthought-Dev mailing list [hidden email] https://mail.enthought.com/mailman/listinfo/enthought-dev |
Hi Michael, in this case, Range tests strictly that the input is an instance of float, instead of the more general numpy.floating: I'm afraid you'll need to explicitly cast the number to a float, or else use a CFloat trait to specify the low and high limits:
although this might be a bit overkill. Best, Pietro
On Thu, Apr 18, 2013 at 11:06 PM, K.-Michael Aye <[hidden email]> wrote: I have a Range Trait defined like this: Pietro Berkes Scientific software developer Enthought UK _______________________________________________ Enthought-Dev mailing list [hidden email] https://mail.enthought.com/mailman/listinfo/enthought-dev |
On 2013-04-19 08:44:35 +0000, Pietro Berkes said:
> Hi Michael, > > in this case, Range tests strictly that the input is an instance of > float, instead of the more general numpy.floating: If I understand this correctly, that would mean that numpy.float64 should also be rejected, but it's not: In [162]: slope.data.dtype Out[162]: dtype('float64') In [163]: mspice.tilt = slope.data[1,1] In [164]: So, is this at least inconsistent behaviour? Michael > > import numpy > isinstance(numpy.float32(3), float) # False > isinstance(numpy.float32(3), numpy.floating) # True > > I'm afraid you'll need to explicitly cast the number to a float, or > else use a CFloat trait to specify the low and high limits: > > class A(HasTraits): > r = Range(low='low', high='high') > low = CFloat(1.0) > high = CFloat(2.3) > > although this might be a bit overkill. > > Best, > Pietro > > > > On Thu, Apr 18, 2013 at 11:06 PM, K.-Michael Aye > <[hidden email]> wrote: > I have a Range Trait defined like this: > > tilt = Range(low=0.0, high = 90.0) > > When I try to assign values of a GDAL.ReadAsArray to it, which comes > with a dtype='float32' it is rejected: > > > ====== > > In [65]: slope.data.dtype > Out[65]: dtype('float32') > > In [66]: val = slope.data[1,1] > > In [67]: val > Out[67]: 10.044398 > > In [68]: val.dtype > Out[68]: dtype('float32') > > In [69]: mspice.tilt = val > --------------------------------------------------------------------------- > TraitError Traceback (most recent call last) > <ipython-input-69-d0f06854ae1f> in <module>() > ----> 1 mspice.tilt = val > > /Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/traits/trait_handlers.py > > in error(self, object, name, value) > 168 """ > 169 raise TraitError( object, name, self.full_info( object, > name, value ), > --> 170 value ) > 171 > 172 def arg_error ( self, method, arg_num, object, name, value ): > > TraitError: The 'tilt' trait of a MarsSpicer instance must be 0.0 <= a > floating point number <= 90.0, but a value of 10.044398 <type > 'numpy.float32'> was specified. > > > ======== > > When I convert to a float64, it works fine. > > Regards, > Michael > > > > > _______________________________________________ > Enthought-Dev mailing list > [hidden email] > https://mail.enthought.com/mailman/listinfo/enthought-dev > > > > -- > Pietro Berkes > Scientific software developer > Enthought UK > > _______________________________________________ > Enthought-Dev mailing list > [hidden email] > https://mail.enthought.com/mailman/listinfo/enthought-dev _______________________________________________ Enthought-Dev mailing list [hidden email] https://mail.enthought.com/mailman/listinfo/enthought-dev |
On Fri, Apr 19, 2013 at 11:36 PM, K.-Michael Aye <[hidden email]> wrote:
> On 2013-04-19 08:44:35 +0000, Pietro Berkes said: > >> Hi Michael, >> >> in this case, Range tests strictly that the input is an instance of >> float, instead of the more general numpy.floating: > > If I understand this correctly, that would mean that numpy.float64 > should also be rejected, but it's not: > > In [162]: slope.data.dtype > Out[162]: dtype('float64') > > In [163]: mspice.tilt = slope.data[1,1] > > In [164]: > > So, is this at least inconsistent behaviour? No, np.float64 is a subclass of Python's float type. np.float32 is not. -- Robert Kern Enthought _______________________________________________ Enthought-Dev mailing list [hidden email] https://mail.enthought.com/mailman/listinfo/enthought-dev |
On 2013-04-19 18:38:36 +0000, Robert Kern said:
> On Fri, Apr 19, 2013 at 11:36 PM, K.-Michael Aye > <[hidden email]> wrote: >> On 2013-04-19 08:44:35 +0000, Pietro Berkes said: >> >>> Hi Michael, >>> >>> in this case, Range tests strictly that the input is an instance of >>> float, instead of the more general numpy.floating: >> >> If I understand this correctly, that would mean that numpy.float64 >> should also be rejected, but it's not: >> >> In [162]: slope.data.dtype >> Out[162]: dtype('float64') >> >> In [163]: mspice.tilt = slope.data[1,1] >> >> In [164]: >> >> So, is this at least inconsistent behaviour? > > No, np.float64 is a subclass of Python's float type. np.float32 is not. Well, ok, so things make sense in terms of intent, but, if you don't mind me asking, why the difference? _______________________________________________ Enthought-Dev mailing list [hidden email] https://mail.enthought.com/mailman/listinfo/enthought-dev |
On Sat, Apr 20, 2013 at 3:18 AM, K.-Michael Aye <[hidden email]> wrote:
> On 2013-04-19 18:38:36 +0000, Robert Kern said: > >> On Fri, Apr 19, 2013 at 11:36 PM, K.-Michael Aye >> <[hidden email]> wrote: >>> On 2013-04-19 08:44:35 +0000, Pietro Berkes said: >>> >>>> Hi Michael, >>>> >>>> in this case, Range tests strictly that the input is an instance of >>>> float, instead of the more general numpy.floating: >>> >>> If I understand this correctly, that would mean that numpy.float64 >>> should also be rejected, but it's not: >>> >>> In [162]: slope.data.dtype >>> Out[162]: dtype('float64') >>> >>> In [163]: mspice.tilt = slope.data[1,1] >>> >>> In [164]: >>> >>> So, is this at least inconsistent behaviour? >> >> No, np.float64 is a subclass of Python's float type. np.float32 is not. > > Well, ok, so things make sense in terms of intent, but, if you don't > mind me asking, why the difference? Why np.float32 does not subclass from the Python float type? C-implemented types are composed of a struct with fields that contain their data. In order to subclass one C-implemented type from another, those structs must be compatible. The subclass can only extend the list of fields and maintain the order of the existing fields from the superclass. A Python float type holds one 64-bit C double, like the np.float64 type. The np.float32 type holds a 32-bit C float instead. Their structs are not compatible and so np.float32 cannot subclass from the Python float type. -- Robert Kern Enthought _______________________________________________ Enthought-Dev mailing list [hidden email] https://mail.enthought.com/mailman/listinfo/enthought-dev |
On 2013-04-20 05:16:55 +0000, Robert Kern said:
> On Sat, Apr 20, 2013 at 3:18 AM, K.-Michael Aye > <[hidden email]> wrote: >> On 2013-04-19 18:38:36 +0000, Robert Kern said: >> >>> On Fri, Apr 19, 2013 at 11:36 PM, K.-Michael Aye >>> <[hidden email]> wrote: >>>> On 2013-04-19 08:44:35 +0000, Pietro Berkes said: >>>> >>>>> Hi Michael, >>>>> >>>>> in this case, Range tests strictly that the input is an instance of >>>>> float, instead of the more general numpy.floating: >>>> >>>> If I understand this correctly, that would mean that numpy.float64 >>>> should also be rejected, but it's not: >>>> >>>> In [162]: slope.data.dtype >>>> Out[162]: dtype('float64') >>>> >>>> In [163]: mspice.tilt = slope.data[1,1] >>>> >>>> In [164]: >>>> >>>> So, is this at least inconsistent behaviour? >>> >>> No, np.float64 is a subclass of Python's float type. np.float32 is not. >> >> Well, ok, so things make sense in terms of intent, but, if you don't >> mind me asking, why the difference? > > Why np.float32 does not subclass from the Python float type? > C-implemented types are composed of a struct with fields that contain > their data. In order to subclass one C-implemented type from another, > those structs must be compatible. The subclass can only extend the > list of fields and maintain the order of the existing fields from the > superclass. A Python float type holds one 64-bit C double, like the > np.float64 type. The np.float32 type holds a 32-bit C float instead. > Their structs are not compatible and so np.float32 cannot subclass > from the Python float type. Thank you! Michael _______________________________________________ Enthought-Dev mailing list [hidden email] https://mail.enthought.com/mailman/listinfo/enthought-dev |
On 04/20/2013 05:12 PM, K.-Michael Aye wrote:
> On 2013-04-20 05:16:55 +0000, Robert Kern said: > >> On Sat, Apr 20, 2013 at 3:18 AM, K.-Michael Aye >> <[hidden email]> wrote: >>> On 2013-04-19 18:38:36 +0000, Robert Kern said: >>> >>>> On Fri, Apr 19, 2013 at 11:36 PM, K.-Michael Aye >>>> <[hidden email]> wrote: >>>>> On 2013-04-19 08:44:35 +0000, Pietro Berkes said: >>>>> >>>>>> Hi Michael, >>>>>> >>>>>> in this case, Range tests strictly that the input is an instance of >>>>>> float, instead of the more general numpy.floating: >>>>> >>>>> If I understand this correctly, that would mean that numpy.float64 >>>>> should also be rejected, but it's not: >>>>> >>>>> In [162]: slope.data.dtype >>>>> Out[162]: dtype('float64') >>>>> >>>>> In [163]: mspice.tilt = slope.data[1,1] >>>>> >>>>> In [164]: >>>>> >>>>> So, is this at least inconsistent behaviour? >>>> >>>> No, np.float64 is a subclass of Python's float type. np.float32 is not. >>> >>> Well, ok, so things make sense in terms of intent, but, if you don't >>> mind me asking, why the difference? >> >> Why np.float32 does not subclass from the Python float type? >> C-implemented types are composed of a struct with fields that contain >> their data. In order to subclass one C-implemented type from another, >> those structs must be compatible. The subclass can only extend the >> list of fields and maintain the order of the existing fields from the >> superclass. A Python float type holds one 64-bit C double, like the >> np.float64 type. The np.float32 type holds a 32-bit C float instead. >> Their structs are not compatible and so np.float32 cannot subclass >> from the Python float type. > > Thank you! > > Michael A perfect example of the worst type of bottom-posting! ;) Steve _______________________________________________ Enthought-Dev mailing list [hidden email] https://mail.enthought.com/mailman/listinfo/enthought-dev |
Free forum by Nabble | Edit this page |