Re: [Numpy-discussion] Changes to bools under Numexpr
Ivan Vilata i Balaguer wrote: > En/na Colin J. Williams ha escrit:: > > >> 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? >> > > From http://www.scipy.org/SciPyPackages/NumExpr: > > The scipy.sandbox.numexpr package supplies routines for the fast > evaluation of array expressions elementwise by using a vector-based > virtual machine. It's comparable to scipy.weave.blitz (in Weave), > but doesn't require a separate compile step of C or C++ code. > > If your SciPy package doesn't include it, you can get a checkout from > the repository:: > > $ svn co http://svn.scipy.org/svn/scipy/trunk/Lib/sandbox/numexpr > > Numexpr is not usable under Python <= 2.4 since it uses decorators (and > maybe for other reasons), so my proposal clearly hasn't the intention on > Python 2.3 compatibility. Instead, it is a simplification of Numexpr's > type system by stricter boolean types. > > I suggest that you try Numexpr. It is a great piece of software. Cheers, > > :: > > Ivan Vilata i Balaguer >qo< http://www.carabos.com/ > Cárabos Coop. V. V V Enjoy Data > > Ivan, Many thanks for this. It's a long time since I looked at SciPy, though I will look at Numexpr. Currently, I'm focusing on Numpy. 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 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Changes to bools under Numexpr
En/na Colin J. Williams ha escrit:: > 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? From http://www.scipy.org/SciPyPackages/NumExpr: The scipy.sandbox.numexpr package supplies routines for the fast evaluation of array expressions elementwise by using a vector-based virtual machine. It's comparable to scipy.weave.blitz (in Weave), but doesn't require a separate compile step of C or C++ code. If your SciPy package doesn't include it, you can get a checkout from the repository:: $ svn co http://svn.scipy.org/svn/scipy/trunk/Lib/sandbox/numexpr Numexpr is not usable under Python <= 2.4 since it uses decorators (and maybe for other reasons), so my proposal clearly hasn't the intention on Python 2.3 compatibility. Instead, it is a simplification of Numexpr's type system by stricter boolean types. I suggest that you try Numexpr. It is a great piece of software. Cheers, :: Ivan Vilata i Balaguer >qo< http://www.carabos.com/ Cárabos Coop. V. V V Enjoy Data "" signature.asc Description: OpenPGP digital signature - 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___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Changes to bools under Numexpr
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) >> >> >>> 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 ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Changes to bools under Numexpr
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) > > >>> 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 Vilata i Balaguer >qo< http://www.carabos.com/ Cárabos Coop. V. V V Enjoy Data "" signature.asc Description: OpenPGP digital signature - 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___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Changes to bools under Numexpr
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) >>> 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? > > 3. This is also why casting booleans to normal numbers is not allowed, >so ``prod()`` and ``sum()`` on booleans aren't either. What is the >meaning of boolean addition anyway? > > To make it short, this patch is kind of a strengthening of boolean > values. I expect some people to disagree with the changes, and that's > why I would really like to hear your opinions on it. > > Regards, > > :: > > Ivan Vilata i Balaguer >qo< http://www.carabos.com/ > Cárabos Coop. V. V V Enjoy Data > "" > > > > Index: interp_body.c > === > --- interp_body.c (revisión: 2299) > +++ interp_body.c (copia de trabajo) > @@ -130,21 +130,22 @@ >ci_dest = c1i); > > case OP_INVERT_BB: VEC_ARG1(b_dest = !b1); > +case OP_AND_BBB: VEC_ARG2(b_dest = (b1 && b2)); > +case OP_OR_BBB: VEC_ARG2(b_dest = (b1 || b2)); > > -case OP_AND_BBB: VEC_ARG2(b_dest = b1 && b2); > -case OP_OR_BBB: VEC_ARG2(b_dest = b1 || b2); > +case OP_EQ_BBB: VEC_ARG2(b_dest = (b1 == b2)); > +case OP_NE_BBB: VEC_ARG2(b_dest = (b1 != b2)); > > -case OP_GT_BII: VEC_ARG2(b_dest = (i1 > i2) ? 1 : 0); > -case OP_GE_BII: VEC_ARG2(b_dest = (i1 >= i2) ? 1 : 0); > -case OP_EQ_BII: VEC_ARG2(b_dest = (i1 == i2) ? 1 : 0); > -case OP_NE_BII: VEC_ARG2(b_dest = (i1 != i2) ? 1 : 0); > +case OP_GT_BII: VEC_ARG2(b_dest = (i1 > i2)); > +case OP_GE_BII: VEC_ARG2(b_dest = (i1 >= i2)); > +case OP_EQ_BII: VEC_ARG2(b_dest = (i1 == i2)); > +case OP_NE_BII: VEC_ARG2(b_dest = (i1 != i2)); > > -case OP_GT_BFF: VEC_ARG2(b_dest = (f1 > f2) ? 1 : 0); > -case OP_GE_BFF: VEC_ARG2(b_dest = (f1 >= f2) ? 1 : 0); > -case OP_EQ_BFF: VEC_ARG2(b_dest = (f1 == f2) ? 1 : 0); > -case OP_NE_BFF: VEC_ARG2(b_dest = (f1 != f2) ? 1 : 0); > +case OP_GT_BFF: VEC_ARG2(b_dest = (f1 > f2)); > +case OP_GE_BFF: VEC_ARG2(b_dest = (f1 >= f2)); > +case OP_EQ_BFF: VEC_ARG2(b_dest = (f1 == f2)); > +case OP_NE_BFF: VEC_ARG2(b_dest = (f1 != f2)); > > -case OP_CAST_IB: VEC_ARG1(i_dest = (long)b1); > case OP_ONES_LIKE_II: VEC_ARG1(i_dest = 1); > case OP_NEG_II: VEC_ARG1(i_dest = -i1); > > @@ -157,7 +158,6 @@ > > case OP_WHERE_IFII: VEC_ARG3(i_dest = f1 ? i2 : i3); > > -case OP_CAST_FB: VEC_ARG1(f_dest = (long)b1); > case OP_CAST_FI: VEC_ARG1(f_dest = (double)(i1)); > case OP_ONES_LIKE_FF: VEC_ARG1(f_dest = 1.0); > case OP_NEG_FF: VEC_ARG1(f_dest = -f1); > @@ -180,8 +180,6 @@ > case OP_FUNC_FF: VEC_ARG1(f_dest = functions_f[arg2](f1)); > case OP_FUNC_FFF: VEC_ARG2(f_dest = functions_ff[arg3](f1, f2)); > > -case OP_CAST_CB: VEC_ARG1(cr_dest = (double)b1; > - ci_dest = 0); > case OP_CAST_CI: VEC_ARG1(cr_dest = (double)(i1); >ci_dest = 0); > case OP_CAST_CF: VEC_ARG1(cr_dest = f1; > @@ -203,8 +201,8 @@ >ci_dest = (c1i*c2r - c1r*c2i) / fa; >cr_dest = fb); > > -case OP_EQ_BCC: VEC_ARG2(b_dest = (c1r == c2r && c1i == c2i) ? 1 : > 0); > -case OP_NE_BCC: VEC_ARG2(b_dest = (c1r != c2r || c1i != c2i) ? 1 : > 0); > +case OP_EQ_BCC: VEC_ARG2(b_dest = (c1r == c2r && c1i == c2i)); > +case OP_NE_BCC: VEC_ARG2(b_dest = (c1r != c2r || c1i != c2i)); > > case OP_WHERE_CFCC: VEC_ARG3(cr_dest = f1 ? c2r : c3r; > ci_dest = f1 ? c2i : c3i); > Index: compiler.py > === > --- co
