On Tue, 21 May 2024 at 14:01, Paul King wrote:
> On Tue, May 21, 2024 at 3:13 PM M.v.Gulik wrote:
> >
> > After fixing my local bug I rechecked the "*.sort{ a, b -> a.y == b.y ?
> -a.y <=> -b.y : a.x <=> b.x }" variant.
> > Same result/conclusion.
>
> In terms of referencing the properties, you'
On Tue, May 21, 2024 at 3:13 PM M.v.Gulik wrote:
>
> After fixing my local bug I rechecked the "*.sort{ a, b -> a.y == b.y ? -a.y
> <=> -b.y : a.x <=> b.x }" variant.
> Same result/conclusion.
In terms of referencing the properties, you'd want to swap the order
you have above, i.e. you'd not wan
Indeed OC, your version is shorter and easier to read (in my eyes too).
Whether it is more performant depends on whether the respective
compareTo method isn't too slow compared to the equals method.
On Tue, May 21, 2024 at 2:22 AM o...@ocs.cz wrote:
>
> Paul,
>
> side question, completely irrele
In general, this is not a safe approach, unless you are sure that the sorting
algorithm is stable (never reordering items regarded „same“).
I regret to say I do not know whether Groovy sort is documented to be always
stable or not.
All the best,
OC
> On 21. 5. 2024, at 7:12, M.v.Gulik wrote:
After fixing my local bug I rechecked the "*.sort{ a, b -> a.y == b.y ?
-a.y <=> -b.y : a.x <=> b.x }" variant.
Same result/conclusion.
However, on a hunch, I split in into two separate consecutive sorts.
"*.sort{ a, b -> a.x <=> b.x }.sort{ a, b -> -a.y <=> -b.y }"
So far this seems to do the job
On Mon, 20 May 2024 at 17:02, Paul King wrote:
> This might even be more obvious:
>
> println ([[x:1, y:100], [x:2, y:1], [x: 2, y:500]].sort{[it.x,
> it.y]}) // broken: [[x:2, y:1], [x:1, y:100], [x:2, y:500]]
> println ([[x:1, y:100], [x:2, y:1], [x: 2, y:500]].sort{ a, b -> a.x
> == b.x ? a.
Hi Paul,
1. I don't use Python and what you guys are saying is of course
technically correct for Groovy, but I must admit I have run into the
same mistake in the past, intuitively assuming that a list would be
component-wise-comparable to another list in Groovy
1. (At least if teh li
Paul,
side question, completely irrelevant to the original problem, just occurred to
me when I read this...
> On 20. 5. 2024, at 17:02, Paul King wrote:
> println ([[x:1, y:100], [x:2, y:1], [x: 2, y:500]].sort{ a, b -> a.x == b.x
> ? a.y <=> b.y : a.x <=> b.x }) // works
Wouldn't sort { a,b
This might even be more obvious:
println ([[x:1, y:100], [x:2, y:1], [x: 2, y:500]].sort{[it.x,
it.y]}) // broken: [[x:2, y:1], [x:1, y:100], [x:2, y:500]]
println ([[x:1, y:100], [x:2, y:1], [x: 2, y:500]].sort{ a, b -> a.x
== b.x ? a.y <=> b.y : a.x <=> b.x }) // works
On Tue, May 21, 2024 at
If you have only two dimensions, you'll get away with your solution
for small integer coordinate values. Here is a counter example with
integers:
println ([[x: 1, y: 69273666], [x: 69273666, y: 1]].sort{[it.x,
it.y]}) // broken
println ([[x: 1, y: 69273666], [x: 69273666, y: 1]].sort{ a, b ->
But when you sort on the value that is an ArrayList ([it.y, it.x]) you rely
on the *hashCode()* of that ArrayList not the values inside.
So it is a coincidence that it works for others than Float/Double. The
right syntax in Groovy is as described by Paul King.
Den man. 20. maj 2024 kl. 15.25 skrev
On Mon, 20 May 2024 at 15:40, Paul King wrote:
> What sort result are you trying to achieve? There should be no need to
> perform any recursion.
>
Main target was reordering some set of randomly ordered x,y coordinates
into (*for example**) a *x,y*(*left to right, top to bottom*) order (**:where
What sort result are you trying to achieve? There should be no need to
perform any recursion.
On Mon, May 20, 2024 at 11:36 PM M.v.Gulik wrote:
>
> Tried "*.sort{ a, b -> a.x == b.x ? a.y <=> b.y : a.x <=> b.x }" in the
> actual source code so see its effect
> And it turns out its not doing the
The one argument closure variant of sort is expecting the closure to
return a comparable. The values of any two items are sorted according
to that comparable.
ArrayLists aren't comparable. In that case the hashCode is used as a
fallback for the comparison value. The hashCode for a Java array list
Tried "**.sort{ a, b -> a.x == b.x ? a.y <=> b.y : a.x <=> b.x }*" in the
actual source code so see its effect
And it turns out its not doing the same job as "**.sort{[it.y, it.x]}*" (*not
unless, I guess, its run recursively until the list-order stopped changing
... which I'm ofc not going to do*)
Verified that "**.sort{ a, b -> a.x == b.x ? -a.y <=> **-**b.y : **-**a.x
<=> **-**b.x }*" actually behaves ok when using Double or Float values (ie:
same ordered output as with Integer or BigDecimal values).
Why "**.sort{[ -it.x, -it.y]}*" behaved differently when using Double or
Float values in
I'm after information so I might better understand why "**.sort{[ -it.x,
-it.y]}*" (*vs "*.sort{[ it.x, it.y]}"*) has no effect on Double and Float
values in this particular case (*both sorts return identical ordered list*.
Not so when using Integer or BigDecimal values).
Mainly working with Pytho
I am not 100% sure what you are after. If you are wanting sort by x
and then y, you just want something like this:
sorttest.sort{ a, b -> a.x == b.x ? a.y <=> b.y : a.x <=> b.x }
sorttest.sort{ a, b -> a.x == b.x ? b.y <=> a.y : b.x <=> a.x } //
reverse of above
On Mon, May 20, 2024 at 6:43 AM M.
Hmm. Same deal with Float values.
(Guess I'm down to enforce BigDecimal values in case of sorting with
Float or Double values.)
19 matches
Mail list logo
