When I was doing topo sort, it was for a sort tree that did one
comparison per node. You were asking about comparisons that are more
complex than simple numeric comparison.
For the topo sort, the comparison was essentially the sign of the volume
of a pyramid after a 3D rotation.
For pruning, you are comparing two game positions to decide which one
should be first analyzed further. The comparison may be quite involved.
Henry Rich
On 12/22/2023 12:47 AM, Elijah Stone wrote:
For toposort, though, you'd presumably want a cleverer strategy than
just sorting the nodes, doing a full graph traversal on each comparison.
Alpha-beta pruning I don't know about.
On Thu, 21 Dec 2023, Henry Rich wrote:
Topological sorting was a big topic in graphics back in the day.
I can imagine that during alpha -beta pruning you might run into some
ordering requirements that require more than simple keys.
Henry Rich
On Thu, Dec 21, 2023, 9:56 PM Elijah Stone <elro...@elronnd.net> wrote:
> The problem it has is that if elements compare equal but don't match
then
> it'll never get down to an array where ~.y has length 1.
Right, of course. Shame on me for being lazy and not bothering to
write
out
*./2 u/\y.
> Modern quicksort hybrids ... always use one bit at a time.
I am curious what applications there are that really need a
user-specified
comparison function (rather than just a sort key, like dyadic /:
takes).
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
