Float Trait does not accept numpy.float32?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Float Trait does not accept numpy.float32?

Michael Aye
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
Reply | Threaded
Open this post in threaded view
|

Re: Float Trait does not accept numpy.float32?

Pietro Berkes
Hi Michael,

in this case, Range tests strictly that the input is an instance of float, instead of the more general numpy.floating:

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
Reply | Threaded
Open this post in threaded view
|

Re: Float Trait does not accept numpy.float32?

Michael Aye
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
Reply | Threaded
Open this post in threaded view
|

Re: Float Trait does not accept numpy.float32?

Robert Kern
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
Reply | Threaded
Open this post in threaded view
|

Re: Float Trait does not accept numpy.float32?

Michael Aye
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
Reply | Threaded
Open this post in threaded view
|

Re: Float Trait does not accept numpy.float32?

Robert Kern
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
Reply | Threaded
Open this post in threaded view
|

Re: Float Trait does not accept numpy.float32?

Michael Aye
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
Reply | Threaded
Open this post in threaded view
|

Re: Float Trait does not accept numpy.float32?

Stephen Waterbury-2
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