[postgis-devel] Inconsistencies in text output

Martin Davis mtnclimb at gmail.com
Fri Apr 17 10:22:54 PDT 2020


On Fri, Apr 17, 2020 at 10:04 AM <rmrodriguez at carto.com> wrote:

>
> On Fri, Apr 17, 2020 at 6:53 PM Martin Davis <mtnclimb at gmail.com> wrote:
> > So if you specify say 20 decimal digits, you aren't getting them?  It
> seems like this at least should be made to work.  It doesn't sound like a
> bad thing, as long as it doesn't cause *unspecified* precision output to
> get a lot longer.
>
> No, I wasn't getting them. The problem, as I mentioned in Github, is
> that we don't have a way to distinguish "give me 15 decimal digits" to
> "I used the default, which is give me 15 decimal digits", so fixing it
> produced many new unexpected digits.
>

Right, we do need a way to distinguish these two cases.  As I mentioned in
PR 554 [1], a way to do this is to change the default value to a sentry
value (say -999).  Then the routine can tell if the precision argument was
omitted, and use the default behaviour (which for simplicity and backwards
compatibility can be the behaviour we have now).  The doc should change to
say that this is the default behaviour.

[1] https://github.com/postgis/postgis/pull/554#issuecomment-615344280

>
> On Fri, Apr 17, 2020 at 6:58 PM Martin Davis <mtnclimb at gmail.com> wrote:
> > That's assuming that the C FP output works in the correct way. If not, I
> guess we could implement that Burger's algorithm mentioned - which is what
> Python does, apparently.  Although is it really worth the complexity?
>
> For 3.1 I replaced the C FP with ryu printf
> (https://github.com/ulfjack/ryu) so that's already there. No need to
> do anything extra, just remove the differences between functions and
> maybe tweak some defaults if necessary.
>

Ok, that's good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20200417/6499b7f9/attachment.html>


More information about the postgis-devel mailing list