toList set sometimes switches the order of elements

[Irena Swanson]

Here is a curiosity: toList set {3,5} returns {5,3}, but toList set {1,2} returns {1,2}. 

There are other inversions and non-inversions as well and it seems to be the same output each time on the same input, so it can't be some random-order set membership.  What is the reason for this?

(I first used M2 version 1.23, and I just installed 1.24.05, and same thing happens.)

Irena

[Doug Torrance]

Under the hood, sets are hash tables (the elements of the sets are keys and the values are all 1).  The order of keys of hash tables is deterministic, but doesn't necessarily agree with the order that we might expect.  Integers serve as their own hash codes, but we mod them out by the length of the underlying array used by hash table.

For this particular example, we have a very small hash table, so we start with an array with the default length of 4.  Since 1 and 2 are less than 4, they end up in expected positions in the array.  But for 3 and 5, 3 ends up in the expected  position and we mod out 5 by 4 and put it in the 1st position.

You can see this using the unexported "buckets" function:

i1 : debug Core

i2 : buckets set {1, 2}

o2 = {{}, {(1, 1)}, {(2, 1)}, {}}

o2 : List

i3 : buckets set {3, 5}

o3 = {{}, {(5, 1)}, {}, {(3, 1)}}

o3 : List

[Irena Swanson]

Thank you, Doug, for this explanation.  As long as the conversions are consistent, it is fine for my calculations.  (But I would do the reordering from small to large for any resulting paper.)

Irena

--
You received this message because you are subscribed to the Google Groups "Macaulay2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to macaulay2+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/macaulay2/51fc7c4a-ee3a-4301-ba90-f7c31db19810n%40googlegroups.com.