You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently <<=>=> operators all compare pairs and points in their sort order:
>> 0x1 < 1x0
== true
Comparison is well-defined, but almost useless in practice. I can only imagine iterating over a discrete 2D field and checking if some (pair!) index has already been iterated upon or not, by comparing it with current index. But this is purely speculative, never needed. For points I can't even imagine a use case, provided their sorting is covered by more general #147.
There's another kind of comparison, with distributive semantic: a < b <=> (a/1 < b/1) and (a/2 < b/2).
Such a < b is equivalent to b > a, and automatically satisfies a <= b and b >= a, but there are points/pairs that are neither <= nor >= than one another. Look at it from quadrants point of view:
Q3 | Q4
----0----
Q2 | Q1
a < b means that point a is in quadrant Q3 from b, and that b is in quadrant Q1 from a. <=/>= include into comparison the cross formed by x = a/x and y = a/y` lines respectively.
Other quadrants can be tested by negating one axis in both operands, but I don't remember needing it.
With this comparison, instead of the abominable within? function for which it's nigh impossible to logically infer the order of arguments and their meaning without help, one can just write all [offset <= xy xy < (offset + size)] or xy: xy - offset all [0x0 <= xy xy < size]. This expression is also explicit in that offset is included but size isn't.
Some other real-world use cases from my codebase:
(0,0) <= size - typical validity check to ensure nonnegativity of a 2D value
1x1 <= span - validity check for a discrete 2D quantity that cannot be zero
size < (1.#inf,1.#inf) - validity check that no size dimension is infinite
all [-1x-1 <= align align <= 1x1] - here, valid alignment values are nine pairs
sizes comparison size1 <= size2 to check if one box fits into another
box overlap check:
boxes-overlap?: function [
"Check if boxes A1-A2 and B1-B2 intersect"
A1 A2 B1 B2
][
(0,0) < subtract min A2 B2 max A1 B1
]
The text was updated successfully, but these errors were encountered:
Currently
<
<=
>=
>
operators all compare pairs and points in their sort order:Comparison is well-defined, but almost useless in practice. I can only imagine iterating over a discrete 2D field and checking if some (pair!) index has already been iterated upon or not, by comparing it with current index. But this is purely speculative, never needed. For points I can't even imagine a use case, provided their sorting is covered by more general #147.
There's another kind of comparison, with distributive semantic:
a < b
<=>(a/1 < b/1) and (a/2 < b/2)
.Such
a < b
is equivalent tob > a
, and automatically satisfiesa <= b
andb >= a
, but there are points/pairs that are neither<=
nor>=
than one another. Look at it from quadrants point of view:a < b
means that pointa
is in quadrant Q3 fromb
, and thatb
is in quadrant Q1 froma
.<=
/>=
include into comparison the cross formed byx = a/x
and y = a/y` lines respectively.Other quadrants can be tested by negating one axis in both operands, but I don't remember needing it.
With this comparison, instead of the abominable
within?
function for which it's nigh impossible to logically infer the order of arguments and their meaning withouthelp
, one can just writeall [offset <= xy xy < (offset + size)]
orxy: xy - offset all [0x0 <= xy xy < size]
. This expression is also explicit in that offset is included but size isn't.Some other real-world use cases from my codebase:
(0,0) <= size
- typical validity check to ensure nonnegativity of a 2D value1x1 <= span
- validity check for a discrete 2D quantity that cannot be zerosize < (1.#inf,1.#inf)
- validity check that no size dimension is infiniteall [-1x-1 <= align align <= 1x1]
- here, valid alignment values are nine pairssize1 <= size2
to check if one box fits into anotherThe text was updated successfully, but these errors were encountered: