[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