For interests sake here's a little program that shows the difference between std::fixed and the default aka std::defaultfloat. Note that defaultfloat (which sort of does "what we want" from a trailing zero point of view), also does sigfigs when restricted to a particular precision and scientific notation.
I think if changes are to be made, I like the idea of doing - default, take the C++ defaults, don't apply anything. this is a change to current behaviour, which applies a default precision - if precision is specified, try to do a trimmed, fixed number of decimals output, which is kind of what my PR does P.
test.cc
Description: Binary data
> On Jan 6, 2021, at 7:54 AM, Martin Davis <mtncl...@gmail.com> wrote:
>
> Well, yes. The current default behaviour seems really unpleasant:
>
> POINT (-0.4225977 46.3406448). ==>. POINT (-0.4225977000000000
> 46.3406447999999997)
>
> bin/geosop -a "Point (-0.4225977 46.3406448)" -f wkt reducePrecision 100
> POINT (-0.4200000000000000 46.3400000000000034)
>
> I agree with Andrew Bell - there is no way GEOS should be trying to outsmart
> the C++ language. And add to that, that setting output precision is a
> perilous hack, since rounding/truncating data pointwise can result in invalid
> topology.
>
> Not saying get rid of the setRoundingPrecision, since it's the user's
> decision. But the default should be to just output "full" precision (as
> decided by the standard floating-point output routines, which know about
> weird things like IEEE-754 guard digits). And forget about trimming, since
> the standard output seems to do that just fine.
>
>
>
>
>
> On Wed, Jan 6, 2021 at 7:43 AM Paul Ramsey <pram...@cleverelephant.ca> wrote:
> For all these reasons and the fact that the current behaviour has existed for
> a long time and is now baked into downstream (those tests in GeoSwift!!) I'm
> inclined to just do nothing.
>
> Any objections?
>
> P
>
> > On Jan 6, 2021, at 7:41 AM, Andrew Bell <andrew.bell...@gmail.com> wrote:
> >
> >
> > 1) This fight really can't be won without implementing all the various
> > things already provided for by a language like C and allowing users to make
> > these choices for themselves. GDAL, for example, has its own strange logic
> > to do this kind of thing. It's ugly and it's not obvious to a user what's
> > going to happen as it's not well-defined by any documentation. Some users
> > may want the full precision, and spending a bunch of time figuring out if
> > .999997 is significant or not isn't really the role of a library like GEOS,
> > IMO. And for some values, scientific notation is what you need. This is
> > why %g exists for printf in C.
> >
> > 2) If you're using a text file for your output, you really don't care about
> > size, even if you say you do. Seems like time could be better spent
> > elsewhere unless someone is paying for this functionality. Someone could
> > certainly reprocess any WKT file to remove digits if they so chose.
> >
> > On Wed, Jan 6, 2021 at 10:25 AM Martin Davis <mtncl...@gmail.com> wrote:
> > Is it possible the problem is the use of std:fixed ? (Which is invoked if
> > the trim option = FALSE, which is the default).
> >
> > Currently in WKTWriter.writeNumber there is this code (and the defaults
> > invoke fixed precision):
> >
> > if(! trim) {
> > ss << std::fixed;
> > }
> > ss << std::setprecision(decimalPlaces >= 0 ? decimalPlaces : 0) << d;
> >
> > This results in the following (as noted on the GeoSwift issue)
> >
> > POINT (-0.4225977 46.3406448). ==>. POINT (-0.4225977000000000
> > 46.3406447999999997)
> >
> > This carries too much precision, obviously. I think it might be exposing
> > the IEEE-754 guard digits unnecessarily. FP output is notoriously tricky,
> > and I suspect it's better to let C++ just do the right thing.
> >
> > Also, running reducePrecision causes problems, again I suspect due to to
> > imprecise FP representation:
> >
> > bin/geosop -a "Point (-0.4225977 46.3406448)" -f wkt reducePrecision 100
> > POINT (-0.4200000000000000 46.3400000000000034)
> >
> > If the std::fixed setting is dropped, the output looks more reasonable:
> >
> > POINT (-0.4225977 46.3406448). ==>. POINT (-0.4225977234 46.3406448)
> >
> > Check that all input sig digits are shown:
> >
> > POINT (-0.4225977234 46.3406448) ==> POINT (-0.4225977234 46.3406448)
> >
> > Reduced precision displays as expected:
> > bin/geosop -a "Point (-0.4225977 46.3406448)" -f wkt reducePrecision 100
> > POINT (-0.42 46.34)
> >
> >
> > Is the "trim" option needed at all?
> >
> > On Tue, Jan 5, 2021 at 3:41 PM Paul Ramsey <pram...@cleverelephant.ca>
> > wrote:
> >
> > What do people think is the best practice for outputing WKT precision?
> > _______________________________________________
> > geos-devel mailing list
> > geos-devel@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/geos-devel
> >
> >
> > --
> > Andrew Bell
> > andrew.bell...@gmail.com
> > _______________________________________________
> > geos-devel mailing list
> > geos-devel@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/geos-devel
>
> _______________________________________________
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
> _______________________________________________
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
_______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
