<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 8, 2018 at 6:51 AM Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.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">Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</a>> writes:<br>
<br>
> Mats, what ever happened to:<br>
><br>
> <a href="https://github.com/libgeos/geos/pull/40" rel="noreferrer" target="_blank">https://github.com/libgeos/geos/pull/40</a><br>
><br>
> I'm just coming up against some stuff in the JTS commit log that expects<br>
> double double and I see you've done this work already some years ago, but<br>
> it's not committed that I can see. JTS changed over some code to use DD<br>
> exclusively about a year ago, so this is a case where porting has caught up<br>
> to need.<br>
><br>
> Were there any substantial problems w/ your PR? If not I'm "just" going to<br>
> try and rebase it and use it as the basis for going ahead.<br>
><br>
> (It seems like the state-of-the-art would eventually be to use the "long<br>
> double" type, which has an implementation in GCC, but does not yet have one<br>
> in clang, in hopes that by being close to the metal we'd eventually also<br>
> start to reap performance gains as the silicon adds instructions to improve<br>
> long double calculations. ???)<br>
<br>
I don't follow this last paragraph.<br>
<br>
As I understand it, long double is a type defined by C that can be more<br>
precise than double, but doesn't have to be, and on x86 is typically 80<br>
bits.  double double is a technique to use two doubles to get roughly<br>
twice the precision.   I would expect that on many CPUs, long double is<br>
the same as double.<br></blockquote><div><br></div><div>Windows defines long double to be the same as double. Java doesn't even have long double, so JTS has no choice for intermediate storage.</div><div><br></div><div>Redefining some intermediate variables as long double short term is a cheap gain.</div><div>Double double gives a bigger gain but is more painful.</div><div><br></div><div>It is not enough to be robust in all cases also though - here are Shewchuk's proved-robust predicates that have to use up to four doubles to manage long arithmetic:</div><div><br></div><div><a href="https://www.cs.cmu.edu/~quake/robust.html">https://www.cs.cmu.edu/~quake/robust.html</a><br></div><div><br></div><div><a href="https://www.cs.cmu.edu/afs/cs/project/quake/public/code/predicates.c">https://www.cs.cmu.edu/afs/cs/project/quake/public/code/predicates.c</a></div><div><br></div><div>If you find 512-bit float somewhere you may get away with it directly though, but I don't think they are available on consumer non-DSP CPUs.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So double double is far more precise than long double always.<br>
<br>
<a href="https://en.wikipedia.org/wiki/Long_double" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Long_double</a><br>
<a href="https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Double-double_arithmetic" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Double-double_arithmetic</a><br>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geos-devel</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div>Darafei Praliaskouski</div><div>Support me: <a href="http://patreon.com/komzpa" target="_blank">http://patreon.com/komzpa</a></div></div></div></div></div></div></div></div>