<div dir="ltr"><div>It should be deterministic for most real data if the inputs are ordered consistently, using the OVER() clause as you suggest. It's possible that there may be a contrived situation involving duplicates in the input where a result would be different (as GEOS STRtree is using std::sort instead of std::stable_sort), but I'm not sure. Also, there are sometimes multiple possible clusterings that satisfy the DBSCAN algorithm, so it is expected that the results may differ from different implementations or different orderings of the same input.</div><div><br></div><div>Dan<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 22, 2021 at 11:47 AM Giuseppe Broccolo <<a href="mailto:g.broccolo.7@gmail.com">g.broccolo.7@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Darafei,</div><div dir="ltr"><br></div><div>Thank you for your answer!<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno ven 22 gen 2021 alle ore 16:26 Darafei "Komяpa" Praliaskouski <<a href="mailto:me@komzpa.net" target="_blank">me@komzpa.net</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hello,<div dir="auto"><br></div><div dir="auto">Cluster functions don't have cross-PostGIS-version stability guarantee. For many production applications that is equal to being non-deterministic.</div><div dir="auto"><br></div><div dir="auto">While debugging KMeans I believe I've seen blinking tests on different compiler flags as some optimizations may mean your distance computation will get different last bits and that may affect clustering, especially on grids. <br></div></div></blockquote><div><br></div><div>I see the problem here. In my company we use the DBSCAN algorithm to cluster some geometries and we are experiencing the not deterministic behaviour, even running on the same datasets. Since the geometries are included on a specific window partition we define in the query, I was curious to know if there was any trick in order to have reproducible results considering exactly the same boundary conditions - same underlying architecture, same PostgreSQL version, of course same input. But I see it's a bit pretentious :)</div><div><br></div><div>Thanks again,</div><div>Giuseppe.<br></div></div></div>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a><br>
</blockquote></div>