Changes to bools under Numexpr

[Colin J. Williams]

Ivan Vilata i Balaguer wrote:
> En/na Colin J. Williams ha escrit:
>
>   
>> Ivan Vilata i Balaguer wrote:
>>     
>>> Hi all.  The attached diff makes some changes to Numexpr support for
>>> booleans.  The changes and their rationale are below.
>>>
>>> 1. New ``True`` and ``False`` boolean constants.  This is so that 1 and
>>>    0 are always proper integer constants.  It is also for completeness,
>>>    but I don't envision any usage for them that couldn't be expressed
>>>    without the constants.
>>>   
>>>       
>> I'm puzzled.
>> Python already has constants True and False of the bool type.  bool is a 
>> subclass of the int type.
>> Any instance of the bool type can be converted to the int type.
>>  >>> a=1==0
>>  >>> type(a)
>> <type 'bool'>
>>  >>> int(a)
>> 0
>>  >>> a
>> False
>>  >>>
>>
>> Colin W.
>>
>>     
>>> 2. The only comparisons supported with booleans are ``==`` and ``!=``,
>>>    so that you can compare boolean variables.  Just as NumPy supports
>>>    complex order comparisons and Numexpr doesn't, so goes for bools.
>>>    Being relatively new, I think there is no need to keep
>>>    integer-boolean compatibility in Numexpr.  What was the meaning of
>>>    ``True > False`` or ``2 > True`` anyway?
>>>       
>
> Well, the ``True`` and ``False`` constants where not previously
> supported in Numexpr because they had to be defined somewhere.  Now they
> are.
>
> Regarding the Python int and bool types and their relationships, it is a
> very elegant solution introduced in Python 2.3 since previous versions
> didn't have a proper boolean type, so the 0 and 1 ints where used for
> that.  What I'm proposing here is, since Numexpr has a recent story and
> most probably there isn't much code affected by the change, why not
> define the boolean type as a purely logical one and leave its numeric
> compatibility issues out?  By the way, it simplifies Numexpr's virtual
> machine (less casting opcodes).
>
> I admit again this looks a little baffling, of course, but I don't think
> it would mean many noticeable changes to the user.
>
> Regards,
>   
>
Ivan,

I'm afraid I'm still baffled.  Are you saying that your proposal is 
necessary
to preserve compatibility with Python versions before 2.3? Otherwise, it 
appears
to introduce clutter with no clear benefit.

I don't find Numexpr in NumPy, are you referring to a scipy module?

Colin W.



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642