Going to the 0.3 example. exactly as a 64bit double because it is impossible, so you didn't have it in the first place.<div><br></div><div>Ryu works over IEEE 754 floating point numbers, so neither of those will work. Going back to the same example as the other day:</div><div><br></div><div><b style="font-family:Calibri;font-size:small;text-align:-webkit-center">2.99999999999999988897769753748E-1</b> could be represented as 29999.../ 10000... but ryu will always output "0.3" because that's the sortest representation for that double value.<br></div><div><br></div><div>Maybe I'm not undertanding you correctly but no system (ryu or otherwise) can give you any precision that you don't already have. What this does do, is guarantee (as long as you don't force dropping digits via precision) that you get the same ieee754 64bit number that you had, exactly as WKB does.</div><div><br></div><div>Related to this, one bad thing about the current (3.0) approach is that is only uses scientific notation for big numbers, so something like 12345678e-8 is output as 0.000000012345678 which is longer and the default precision might drop significant digits pretty frequently. I plan to do some tests and suggest using scientic notation when that is clearly shorter (both really small and big numbers).</div><div><br></div><div><br>On Monday, April 20, 2020, Martin Davis <<a href="mailto:mtnclimb@gmail.com" target="_blank">mtnclimb@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><div dir="ltr">It does seem like binary fractions can be represented exactly as decimal numbers.  The converse is not true, however.  So does that mean that even if a binary FP number is output "exactly" as decimal, it might not read back in the same way?  Does ryu support this?  (And even if Ryu does, other systems might not).<div><br></div><div>This in indeed the rationale for WKB - it removes all these kinds of finicky questions about round-tripping.</div><div><br></div><div>For the record, I'm not concerned about round-tripping, just about getting the behavior of limited-precision output correct.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 20, 2020 at 9:18 AM <<a href="mailto:rmrodriguez@carto.com" target="_blank">rmrodriguez@carto.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">On Mon, Apr 20, 2020 at 6:10 PM Sandro Santilli <<a href="mailto:strk@kbt.io" target="_blank">strk@kbt.io</a>> wrote:<br>
<br>
> Any decimal representation of a floating point number<br>
> will have this problem, as not all numbers that can be<br>
> represented by a floating point number can fit on a<br>
> screen.<br>
<br>
It has been demonstrated that you can guarantee round-trip conversion<br>
with 17 significant digits. It's true that with decimal notation it<br>
will require more characters, but with Postgis constraints this seems<br>
to require at most 33 characters, which is way less than what a screen<br>
fits.<br>
<br>
I'd be more than happy to add examples of those big numbers to add<br>
them to our unit tests and confirm round trip works for them.<br>
<br>
<br>
-- <br>
Raúl Marín Rodríguez<br>
<a href="http://carto.com" rel="noreferrer" target="_blank">carto.com</a><br>
______________________________<wbr>_________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/postgis-devel</a></blockquote></div></div>
</blockquote>
</div>
<br><br>-- <br>Raúl Marín Rodríguez<br><a href="http://carto.com" target="_blank">carto.com</a><br>