https://kotlinlang.org logo
Join SlackCommunities
Powered by
is set.toList() deterministic?
# announcements
b
is set.toList() deterministic?
l
what do you mean with deterministic?
a
As in order? I'm guessing not Or perhaps it guarantuees same order as iterating over the set.
b
ordering
d
That depends on what set you are using. If you are using a 
HashSet
there is no defined ordering, so the ordering in the list is not deterministic.
👍🏼 1
d
If 
set
is a 
HashSet<...>
then not really.
d
A 
LinkedHashSet
on the other hand will preserve insertion order.
And a 
SortedSet
will preserve a specified ordering.
p
That depends on what set you are using. If you are using a 
HashSet
there is no defined ordering, so the ordering in the list is not deterministic.
When will the ordering be different in the list copy after using 
hashSetOf(1, 2, 3).toList()
?
ir the original structure, yes the ordering is not defined but in the copy it will always be deterministic?
d
It can be different even between different JVM runs. It might not be different at all. But it is not defined.
You cannot rely on it being in any certain order when using HashSet.
It might even be different from one iteration to the next.
p
When will this code be false?
Copy code
val a = hashSetOf(1, 2 ,3)
assertEquals(a.toList(), a.toList())
d
It might be at any point. It is not defined.
p
can you give me a snippet when it happens?
d
No
I don't think you understand what "not defined" means.
It probably does not happen now, but you cannot rely on it. The JDK might change it's implementation.
p
Then it's deterministic 🙂
👎 1
d
No.
It might just so happen to be deterministic for that specific JDK you are running on right now.
p
So how can it change at runtime?
d
A future JDK might change it to be different every time because that allows for a more compact / fast internal representation
d
How do you know it doesn't change at runtime?
p
If it does not change at runtime it's deterministic because i can rely that my test will return the same result on the same circumstances. I'm not sure how can it change at runtime so that's why i'm curious to see the example.
d
It's all about contracts. The HashSet class offers a certain set of guarantees. Iteration order is not one of them. It might happen to have stable iteration, but you cannot rely on it in your code, because even a small minor version update in the JDK might change this behavior.
👍 2
d
Such an example is non-trivial. It probably won't happen on the same (unmutated) object but you shouldn't rely on it.
p
Then you can't rely on anything because you can't predict the future 🙂
s
In what world is Oracle going to do that ? So far the API has changed if there was a mismatch between usage and docs
d
That's why we have contracts.
d
Then you can't rely on anything because you can't predict the future 🙂
Yes, you can rely on the documented behavior of a class. 
LinkedHashSet
for example specifies that it will keep the insertion order. That is not going to change.
👍 3
p
So if you have any double in your software it is non-deterministic?
l
double calculations is deterministic as it's always the same, even if imprecise
hashset isn't guaranteed to be the same every time
t
@Paulius Ruminas put this way. as of today, you can "safely" do what you wrote
Copy code
val a = hashSetOf(1, 2, 3)
a.toList() == a.toList() //always true
however, that can change in future implementation.
otoh,
Copy code
val a = linkedHashSetOf(1,2,3)
a.toList() == a.toList() //always true
will hold in future implementations too
(not even sure kotlin has 
linkedHashSetOf
helper, consider the above as pseudo-code)
p
double calculations is deterministic as it's always the same, even if imprecise
Double is platform specific so why do you say it is deterministic? If I move my code between platforms it will yield different results.
I agree that HashSet has undefined ordering what I do not agree with is that you consider
Copy code
val a = hashSetOf(1,2,3)
a.toList() == a.toList()
a non-deterministic operation.
s
undefined deterministic Pick one
d
Nahh, at this point, I think we're all saying the same thing but with different words. Might as well just argue word definitions from here on.
g
@Paulius Ruminas the concept of "undefined" was explained to you like 10 messages ago, what exactly is left unclear in your opinion? Yes, I've seen production code blowing up because of hashmap order changed on Android when they moved to JDK 7. So yeah, at least you're not alone in your delusion that it's "deterministic"...
t
https://kotlinlang.slack.com/archives/C0922A726/p1557150625148800?thread_ts=1557147449.131800&amp;cid=C0922A726 I see I wasn't clear. 
always true
today, might not be true with future jvms anymore. and I am not talking bugs, I am talking expected behaviour
p
Thank you for you answers. I was looking at this more from a mathematical point of view that the algorithm is deterministic. If the result changed the algorithm probably did too. I agree with you that this should be avoided to be compatible with future releases of Java 🙂
2 Views
Open in Slack
PreviousNext
Powered by