Closed antipisa closed 4 years ago
There are two "natural" choices: map python < and > to q < and > or map them to lexicographical compare so that K([a, ...]) > K([b, ...])
is the same as [a, ...] > [b, ...]
. So far we have followed the Zen of Python: "In the face of ambiguity, refuse the temptation to guess."
Given that ==
is mapped to ~
rather than =
by a deliberate decision, mapping < and > to vector operation would make pyq equally confusing to python and to q programmers.
How useful is lexicographical comparison?
What's the reason you chose to do it this way, rather than following the same semantic as both q and numpy? Python lists are terribly difficult to work with, and without the basic vector comparison operators, manipulating K vectors in python is very painful. If the goal was to give python the full power of q, i think it’s crucial to supporting vector comparison.
Also, vector arithmetic seems to work just fine, when they’re also not supported by python lists. i.e.
>>> K([True,False,True]) | K([False,True,False])
k('111b’)
>>> [True,False,True] | [False,True,False]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for |: 'list' and ‘list'
>>> q.til(3)+q.til(3)
k('0 2 4’)
>>> [0,1,2]+[0,1,2]
[0, 1, 2, 0, 1, 2]
Not that I'm complaining (please don’t break it). It seems very inconsistent to support arithmetic operators, but but not the comparison operators.
Stale issue message
Could we allow for inequality operations from the python side?
This works:
But: