Compare multiarray objects: where()
Status: Beta
Brought to you by:
lemire
Menu
▾
▴
Logged In: YES
user_id=73205
Since this is assigned to "none", could you provide
more info? I'm assigning to you... ;-)
Logged In: YES
user_id=73205
Please specify how "where()" is lacking. I get it that the
feature is implemented, but not functional... that would
indeed be a bug under "missing feature"... even
though "bug/missing feature" can be confused easily
with "feature requests". I think, however, that it is
reasonable to say that if something is partially
implemented, but not fully functional somehow
because not fully implemented, then it would go
under "bug/missing feature".
(I'm referring here at the difference between "data
type" and "category". If something is in "bugs", then it
must be a bug.)
Logged In: YES
user_id=401428
Daniel,
The problem with where() is subtle. And, as I have played with
it some more, I wonder it it's really a problem with where(), or
more with the parser.
Basically, something like this works fine: z = where
(greater_equal(z, 2.5), z, 0) - it gives you back a vector whose
contents are the same as z where z >= 2.5, and 0 otherwise.
But, this does *not* work: z = where(z>=2.5, z, 0). It should
do the same thing (it does in CNumeric), but in Jython it
doesn't work. The same is true for several of the other
operators: ==, >, <, >=, <=. The function-based version
works fine (and that's what I use in my code now for
compatibility), but the symbol-based version doesn't work.
You can check out examples in the test file for this function:
tests/test_select.py. I'm not familiar with the Jython API to
know where the parsing takes place, so I don't quite know
where to look for the solution to this problem. If you have any
ideas, please let me know.
-Frank
Logged In: YES
user_id=73205
Thanks for the update. I think I understand the problem better now. I
agree that it has probably to do with the parsing. Now that you've
narrowed it down, it should be relatively easy to track it down.