Re: printf issue with thousands separator
Hi Christian,
thanks for the info. The problem is, though, that calling
setlocale()
in GNU APL is problematic since I cannot possibly know beforehand
what the locale of the user will be. And I cannot know all
peculiarities
of all possible locales. In our case the thousands separator comes
after every 3 digits, but rumour has it that, for example, China
has
a different scheme where the grouping size varies along the
number.
For these and other reasons (serious portability concerns on
different
platforms) I removed support for locales in GNU APL 1.2 (around
2014).
Since then GNU APL relies on the C standard which says that the
default
locale for all C programs is "C" and, as a consequence, GNU APL
runs
under the C locale.
Unfortunately the C locale has no thousands separator:
#include
#include
int
main(int argc, char *argv[])
{
setlocale (LC_NUMERIC, "C.UTF-8");
printf("%'f\n", 55.66);
}
which prints:
55.66
I believe that using the C locale is arguably better than e.g.
reading
the environment variables related to locales because it makes the
behaviour of GNU APL more predictable across different platforms.
I find it somewhat inconsistent if a programmer can explicitly
request
the output of the thousands separators with the ' flag and that
glibc
may then not follow suit because of the locale.
Best Regards,
Jürgen
On 7/6/22 1:33 AM, Christian Robert
wrote:
Jürgen,
#include
#include
int
main(int argc, char *argv[])
{
setlocale (LC_NUMERIC, "en_US.utf8");
printf("%'f\n", 55.66);
}
print:
555,555.66
my 2 cents...
Xtian.
On 2022-07-05 12:40, Dr. Jürgen Sauermann wrote:
Hi Martin,
I believe I understood your problem now. As far as *⎕FIO* is
concerned it should be fixed
in *SVN 1579*:
* "%'.2f" ⎕FIO.sprintf 1234567.89**
**1,234,567.89**
*
There could be a misunderstanding as to how 'Format by example'
works (and that misunderstanding
might also be caused by my testcases). What the APL2 calls a
left or right "decorator" is not intended
as an arbitrary string in the printf() fashion, but something
that is directly attached (and possibly
suppressed) to a number. In most cases the left decorator is
either the minus sign or the overbar and
the right decorator is not used. The rare exceptions where the
right decorator is used are:
1. negative numbers printed in parentheses instead of a minus
sign. Sometimes used in bookkeeping.
2. output of negative numbers in a different color (typically
red) using VT100 escape sequences as
left and right decorators.
In the examples that you apparently tried there were 2 left
decorators (one being the $
and the other being the minus sign) and Format by example simply
does not allow that.
The problem with ⎕FIO was actually caused by glibc which
apparently ignores the ' flag even
if the locale tells otherwise, On my machine (and in plain C):
*int
main(int argc, char *argv[])
{
printf("%'f\n", 55.66);
}
*
prints:
*55.66*
I did already pass the ' flag to *sprintf() *in glibc but glibc
then simply ignored it.
Best Regards,
Jürgen
On 7/5/22 10:08 AM, Martin Michel wrote:
Hi Jürgen,
thanks for your quick reply.
I will look into adding support for
the thousands separator (but not supporting the
locales nonsense). That is, the thousands separator will
always be comma and not
e.g. full-stop like in some countries and comma in others.
That would be great and I fully agree, locales support would
be too much
of a requirement.
BTW format by example should have done
the job (see the APL2 language
reference page 140):
"5,555.50" ⍕ 1234.56
1,234.56
Well, I tried this but it only works for the simpler cases. I
could
Re: printf issue with thousands separator
On Wed, Jul 6, 2022 at 7:07 AM Dr. Jürgen Sauermann < mail@jürgen-sauermann.de> wrote: > [...] > The problem is, though, that calling setlocale() > in GNU APL is problematic since I cannot possibly know beforehand > what the locale of the user will be. > Can't this be set in ~/.gnu-apl/preferences ? Blake McBride
Re: printf issue with thousands separator
Hi Blake, in theory: yes. The problem is that the behaviour of locales can be quite unpredictable and therefore allowing to change it means that the underlying glibc may produce results that are no easy to foresee. The current problem (the thousands' separator) is a good example for this. For most locales (and also for APL) we have: 1. the thousands' separator is inserted after every 3 digits, and 2. the thousands separator is a single character If we would care for locales defined by the user, e.g. in preferences or via locale-related environment variables, then there would most likely be a mismatch between ⎕FC (which controls the thousands' separator in APL) and the locale (which normally controls the thousands' separator in ⎕FIO.sprintf). IMHO this could make matters a lot more complicated without any real advantages for the user. The current solution is more locale-agnostic and ⎕FIO.sprintf uses ⎕FC instead of the locale to determine the thousands' separator. Best Regards, Jürgen On 7/6/22 4:32 PM, Blake McBride wrote: On Wed, Jul 6, 2022 at 7:07 AM Dr. Jürgen Sauermann mailto:mail@j%C3%BCrgen-sauermann.de>> wrote: [...] The problem is, though, that calling setlocale() in GNU APL is problematic since I cannot possibly know beforehand what the locale of the user will be. Can't this be set in ~/.gnu-apl/preferences ? Blake McBride
Re: printf issue with thousands separator
Hi Jürgen, I see. Perhaps controlling this programmatically, as I believe you described, does make more sense. Thanks! Blake On Wed, Jul 6, 2022 at 11:29 AM Dr. Jürgen Sauermann < mail@jürgen-sauermann.de> wrote: > Hi Blake, > > in theory: yes. The problem is that the behaviour of locales can be quite > unpredictable and therefore allowing to change it means that the underlying > glibc may produce results that are no easy to foresee. The current problem > (the thousands' separator) is a good example for this. > > For most locales (and also for APL) we have: > > 1. the thousands' separator is inserted after every 3 digits, and > 2. the thousands separator is a single character > > If we would care for locales defined by the user, e.g. in preferences > or via locale-related environment variables, then there would most likely > be a mismatch between ⎕FC (which controls the thousands' separator > in APL) and the locale (which normally controls the thousands' separator > in ⎕FIO.sprintf). IMHO this could make matters a lot more complicated > without any real advantages for the user. > > The current solution is more locale-agnostic and ⎕FIO.sprintf uses > ⎕FC instead of the locale to determine the thousands' separator. > > Best Regards, > Jürgen > > > On 7/6/22 4:32 PM, Blake McBride wrote: > > On Wed, Jul 6, 2022 at 7:07 AM Dr. Jürgen Sauermann > > mailto:mail@j%C3%BCrgen-sauermann.de>> wrote: > > > > [...] > > The problem is, though, that calling setlocale() > > in GNU APL is problematic since I cannot possibly know beforehand > > what the locale of the user will be. > > > > > > Can't this be set in ~/.gnu-apl/preferences ? > > > > Blake McBride > > > >
