So, we ran into some issues with GEOS 3.8 on a Power architecture, and based on what tests failed, I suspect the issue is with our use of ttmath.
In particular, this comment says to me (and just eyeballing what's going on) that there is some in-baked assumptions about endianness. https://github.com/libgeos/geos/blob/master/include/geos/algorithm/ttmath/ttmathbig.h#L2607-L2609 The only reason we're using ttmath is because Mateusz happened to choose it for his initial experiments on supporting the higher precision code in JTS. Turns out there's no reason we cannot use exactly the same routines as JTS does, though, and they have NO ENDIAN assumptions in them, so they'll be portable. The port of the JTS code is here: https://github.com/libgeos/geos/pull/303 Amazingly, all the regression tests still pass. Also, just based on running the full test suite, the DD code seems 5-10% faster than ttmath. This isn't entirely surprising, since ttmath is an arbitrary precision system, while doubledouble uses nothing but standard double math and the assumption that all double representations and operations are to IEEE spec. I'm going to port the JTS unit tests so we have a little more foundation under this work, but then I'd like to rip out ttmath in 3.9. I'm a little worried that we cannot support big-endian machines in 3.8, so I think we might consider back-porting this work to 3.8 and switch over to it for big-endian architectures. Paul _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
