Re: [Bug 1899553] Re: gcvt and qgcvt do not always provide requested precsion

2021-02-02 Thread Robert Gilmour
Hi,

On Wed, Feb 3, 2021 at 3:46 AM Balint Reczey <1899...@bugs.launchpad.net>
wrote:

> The first result is slightly less, the second one is slightly more
> accurate representation of 0.1 compared to the exected value thanks to
> the rounding.
>
> IMO it makes sense to omit the digits that are below the accuracy limit
> and the man page does not suggest the opposite.
>

I disagree with that.
The man page says:
"It produces ndigit significant digits in either printf(3) F format or E
format"

If the intention was to limit the value of "ndigit" to no more than 17,
then  I believe that documentation should have (and, indeed, would have)
specified that limit.

Every double (apart from infs and nans) encapsulates a precise base 2
value. I see nothing unreasonable in wanting to see that precise base 2
value expressed exactly in base 10.
That is what the "%.*g" formatting of sprintf provides - which is,
of course, the workaround I use.

gcvt's commitment to a string containing only "significant digits" implies
that no more than 768 digits will ever be output for any double.
That is, the precise value of  every finite double can be expressed exactly
in 768 (or fewer) decimal digits.


> If you deeply believe that glibc needs to be fixed in this aspect please
> report the issue upstream, because this is not a deliberate change in
> the Ubuntu packaging.
>
>
I do believe that gcvt and qcvt are not behaving in accordance with their
documented (nor expected) behaviours.
However, the man also says:
" Marked  as LEGACY in POSIX.1-2001.  POSIX.1-2008 removes the
specification of gcvt(), recommending the  use  of  sprintf(3)  instead
 (though  snprintf(3) may be preferable)."

Therein lie the only excuses I can see for *not* fixing it.

I think I would at least like "upstream" to be made aware of this issue.
And the best way to achieve this would be to file a bug report.
Can you provide me with a link to the correct location for doing this ?

Thanks for responding. I appreciate the time you've taken in doing this.

Cheers,
Rob

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1899553

Title:
  gcvt and qgcvt do not always provide requested precsion

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1899553/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1899553] Re: gcvt and qgcvt do not always provide requested precsion

2021-02-02 Thread Balint Reczey
The first result is slightly less, the second one is slightly more
accurate representation of 0.1 compared to the exected value thanks to
the rounding.

IMO it makes sense to omit the digits that are below the accuracy limit
and the man page does not suggest the opposite.

If you deeply believe that glibc needs to be fixed in this aspect please
report the issue upstream, because this is not a deliberate change in
the Ubuntu packaging.

Out of curiosity I've checked the results on Fedora and they are the
same:

 [root@fedora ~]# cat > test.c
#include 
#include 

int main(void) {
 char ebuf[80];

 gcvt(0.1, 55, ebuf);
 printf("%s\n", ebuf);

 qgcvt(0.1L, 67, ebuf);
 printf("%s\n", ebuf);

 return 0;
}
[root@fedora ~]# gcc test.c 
[root@fedora ~]# ./a.out 
0.10001
0.10001


** Changed in: glibc (Ubuntu)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1899553

Title:
  gcvt and qgcvt do not always provide requested precsion

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1899553/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs