[Numpy-discussion] Type of 1st argument in Numexpr where()

Ivan Vilata i Balaguer ivilata at carabos.com
Fri Dec 22 05:27:40 CST 2006

Tim Hochberg (el 2006-12-20 a les 14:29:57 -0700) va dir::

> Let's look at simpler than where, which is a confusing function. How 
> about *sin*.
> [...]

Ok, I think I already get the idea about the need of adding extra
opcodes if ``where()`` only accepted booleans as first arguments.
Thanks for the explanation! :)  ::

> It would be possible to adapt your original idea. We could do the following:
>    1. Add a function boolean() to the numexpr namespace. This would cast
>       it's argument to an array of bools.
>    2. Tweak the compile (actually, probably where_func in
>       expressions.py) to compile where(x,a,b) as where(bool(x),a,b)
>    3. Change where to take bools as the first argument.
> Or, maybe it would be cleaner to instead change the casting rules so 
> that casting to bool happens automagically. Having cycles in the casting 
> rules frightens me a bit, but it could probably be made to work.

I understand that the new ``boolean()`` function and the "downwards"
casting to boolean are functionally equivalent and require the same
number of new opcodes.  However, if cycles in casting rules are frowned
upon (though I don't see any problem at forst sight), I would opt for
the fully explicit ``boolean()`` function.  ::

> So, in summary, I think that the general idea you proposed could be made 
> to work with some more effort. Conceptually, it's cleaner and it could 
> be made more efficient for the common case. On the downside, this would 
> require three new opcodes, as opposed to a single new opcode to do the 
> simple minded fix. So, I'm still a bit up in the air as to whether it's 
> a good idea.

Well, my previous patch works without adding new opcodes; however, one
is no longer able to use ``where(x, a, b)`` with ``x`` being something
other than a boolean array, so one should use ``where(x != 0, a, b)``,
which is more explicit about its meaning.  Nonetheless, I see using
non-booleans as boolean conditions as an idiom, and I don't know how
frequently that feature will be used in numerical computations.

So I'm also in the air about the idea. ;)  Cheers,


	Ivan Vilata i Balaguer   >qo<   http://www.carabos.com/
	       Cárabos Coop. V.  V  V   Enjoy Data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: Digital signature
Url : http://projects.scipy.org/pipermail/numpy-discussion/attachments/20061222/fa35ab12/attachment.bin 

More information about the Numpy-discussion mailing list