I don't know how Japanese feel about that, but I certainly don't want
to have to use some Germanized form of C or Forth. This kind of
catering for different natural-language programmers has been tried and
has not taken over the world. I guess that's because
1) You need to learn a lot about what "printf" means and how it is
used; remembering the name is only a minor aspect.
2) Having a name common on all the world allows you to read programs
from all over the world, use reference material from all over the
world, etc.
A similar concept was implemented in COBOL, where the designers though
that having to write
ADD A TO B GIVING C
or somesuch makes programming easier than writing
C = A+B
in FORTRAN. ...
That's a common misconception. The point of having COBOL look like
English wasn't to make it easier to program but to make it easier for non-programmers to read. Think of an auditor looking at the program to
see if its business logic matches what the company says it does.
On 5/18/24 12:16 PM, John Levine wrote:
That's a common misconception. The point of having COBOL look likeIt certainly didn't make it easier for people learning to use it.
English wasn't to make it easier to program but to make it easier for
non-programmers to read. Think of an auditor looking at the program to
see if its business logic matches what the company says it does.
I remember way back in my undergrad days, when keypunch was king, that
every semester at some point someone would hang out a shingle: COBOL
Help Desk.
Never saw the equivalent for FORTRAN, etc.
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
I don't know how Japanese feel about that, but I certainly don't want
to have to use some Germanized form of C or Forth. This kind of
catering for different natural-language programmers has been tried and
has not taken over the world. I guess that's because
1) You need to learn a lot about what "printf" means and how it is
used; remembering the name is only a minor aspect.
2) Having a name common on all the world allows you to read programs
from all over the world, use reference material from all over the
world, etc.
A similar concept was implemented in COBOL, where the designers though
that having to write
ADD A TO B GIVING C
or somesuch makes programming easier than writing
C = A+B
in FORTRAN. ...
That's a common misconception. The point of having COBOL look like
English wasn't to make it easier to program but to make it easier for non-programmers to read. Think of an auditor looking at the program to
see if its business logic matches what the company says it does.
Also, I'm with you on localized command languages. Back in the 1980s I
worked on a modelling package called Javelin that had a keystroke
macro language. After going to some effort to provide macro names in
various languages, our foreign customers consistently told us that we
needn't have bothered.
David Schultz wrote:
On 5/18/24 12:16 PM, John Levine wrote:
That's a common misconception. The point of having COBOL look likeIt certainly didn't make it easier for people learning to use it.
English wasn't to make it easier to program but to make it easier for
non-programmers to read. Think of an auditor looking at the program to
see if its business logic matches what the company says it does.
I remember way back in my undergrad days, when keypunch was king, that
every semester at some point someone would hang out a shingle: COBOL
Help Desk.
Never saw the equivalent for FORTRAN, etc.
I, myself, played the Fortran part. But, instead of having a help desk,
I could do almost anything a Fortran programmer wanted over a
telephone.
I was sitting over my soldering bench disassembling a stereo, and
teaching
a person how to do a simple sort program while repairing a stereo
amplifier.
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
A similar concept was implemented in COBOL, where the designers though
that having to write
ADD A TO B GIVING C
or somesuch makes programming easier than writing
C = A+B
in FORTRAN. ...
That's a common misconception. The point of having COBOL look like
English wasn't to make it easier to program but to make it easier for >non-programmers to read. Think of an auditor looking at the program to
see if its business logic matches what the company says it does.
John Levine <johnl@taugh.com> writes:
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
A similar concept was implemented in COBOL, where the designers
though that having to write
ADD A TO B GIVING C
or somesuch makes programming easier than writing
C = A+B
in FORTRAN. ...
That's a common misconception. The point of having COBOL look like
English wasn't to make it easier to program but to make it easier
for non-programmers to read. Think of an auditor looking at the
program to see if its business logic matches what the company says
it does.
That may have been the idea, but I think the idea was wrong.
Hasn't COBOL also included a more
mathematically oriented way of writing computations?
That may have been the idea, but I think the idea was wrong.
I think few would disagree with both parts of that. I certainly
wouldn't. But I give the designers some slack as, in the late 1950s,
there was lettle knowledge about programming languages to go on. Now,
the mistake is obvious.
Yes, the COMPUTE statement. i.e. COMPUTE I = I + 1
According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:
That may have been the idea, but I think the idea was wrong.
I think few would disagree with both parts of that. I certainly
wouldn't. But I give the designers some slack as, in the late 1950s,
there was lettle knowledge about programming languages to go on. Now,
the mistake is obvious.
COBOL is older than Fortran, and back in the day there were plenty of
people who were outraged at I=I+1 which is mathematically absurd for
the
physicicts and mathematicians who were Fortran's early users.
Algol gave us various kinds of := which were supposed to be better.
Yes, the COMPUTE statement. i.e. COMPUTE I = I + 1
You could do that, but I think this is at least as clear:
ADD 1 TO PRODUCT-INDEX.
Don't forget that while COBOL's control structures were quite weak,
its data structures still look pretty good. Everything in a C or C++ structure comes from COBOL by way of PL/I.
According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:
That may have been the idea, but I think the idea was wrong.
I think few would disagree with both parts of that. I certainly
wouldn't. But I give the designers some slack as, in the late
1950s, there was lettle knowledge about programming languages to go
on. Now, the mistake is obvious.
COBOL is older than Fortran, and back in the day there were plenty of
people who were outraged at I=I+1 which is mathematically absurd for
the physicicts and mathematicians who were Fortran's early users.
Algol gave us various kinds of := which were supposed to be better.
Yes, the COMPUTE statement. i.e. COMPUTE I = I + 1
You could do that, but I think this is at least as clear:
ADD 1 TO PRODUCT-INDEX.
Don't forget that while COBOL's control structures were quite weak,
its data structures still look pretty good.
John Levine wrote:
According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:
That may have been the idea, but I think the idea was wrong.
I think few would disagree with both parts of that. I certainly
wouldn't. But I give the designers some slack as, in the late
1950s, there was lettle knowledge about programming languages to go
on. Now, the mistake is obvious.
COBOL is older than Fortran, and back in the day there were plenty of
people who were outraged at I=I+1 which is mathematically absurd for
the physicicts and mathematicians who were Fortran's early users.
Algol gave us various kinds of := which were supposed to be better.
Yes, the COMPUTE statement. i.e. COMPUTE I = I + 1
You could do that, but I think this is at least as clear:
ADD 1 TO PRODUCT-INDEX.
Note that my statement on the COMPUTE statement was in direct answer to Anton's question. I have no problem with your statement, but note that things get messy quickly when doing more complex stuff. For example,
the non-COMPUTE syntax for something like
E = (A*B) + (C*D)
requires three separate statements, and, if you need to keep the
original values of A through D, you must define two additional
variables for the intermediate results.
Don't forget that while COBOL's control structures were quite weak,
its data structures still look pretty good.
Absolutely! The power of a MOVE CORRESPONDING with properly defined
data structures was a joy to behold.
John Levine wrote:
According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:
That may have been the idea, but I think the idea was wrong.
I think few would disagree with both parts of that. I certainly wouldn't. But I give the designers some slack as, in the late
1950s, there was lettle knowledge about programming languages to
go on. Now, the mistake is obvious.
COBOL is older than Fortran, and back in the day there were plenty
of people who were outraged at I=I+1 which is mathematically absurd
for the
physicicts and mathematicians who were Fortran's early users.
Algol gave us various kinds of := which were supposed to be better.
Yes, the COMPUTE statement. i.e. COMPUTE I = I + 1
You could do that, but I think this is at least as clear:
ADD 1 TO PRODUCT-INDEX.
Don't forget that while COBOL's control structures were quite weak,
its data structures still look pretty good. Everything in a C or
C++ structure comes from COBOL by way of PL/I.
Picture data structures ??
Don't forget that while COBOL's control structures were quite weak,
its data structures still look pretty good.
Absolutely! The power of a MOVE CORRESPONDING with properly defined
data structures was a joy to behold.
The power of PL/1s DCL like was similarly a joy to use.
According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:
That may have been the idea, but I think the idea was wrong.
I think few would disagree with both parts of that. I certainly
wouldn't. But I give the designers some slack as, in the late 1950s,
there was lettle knowledge about programming languages to go on.
Now, the mistake is obvious.
COBOL is older than Fortran
Don't forget that while COBOL's control structures were quite weak,
its data structures still look pretty good. Everything in a C or C++ >structure comes from COBOL by way of PL/I.
And I miss some equivalent of picture clauses in C every time I see, >including in this NG, a number consisting of a string of say 8 or 9 or
more digits without the every three digit separator character, which
sure makes reading such numbers easier. :-(
I am not convinced that the locale-specific input is a good idea,
though.
MitchAlsup1 wrote:
And I miss some equivalent of picture clauses in C every time I see, >including in this NG, a number consisting of a string of say 8 or 9 or
more digits without the every three digit separator character, which
sure makes reading such numbers easier. :-(
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
MitchAlsup1 wrote:
And I miss some equivalent of picture clauses in C every time I see, including in this NG, a number consisting of a string of say 8 or 9
or more digits without the every three digit separator character,
which sure makes reading such numbers easier. :-(
printf has supported that capability for decades.
$ LANG=en_US.utf8 printf "%'10.2f\n" $(( 1540.0 * 179.47 + (7928 +
401 - 535) * 67.61 + 2295 * 173.35 + 3230 * 191.00 + 192 * 750.15 +
150 * 509.85 + 254 * 6> 2,505,496.61
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
MitchAlsup1 wrote:
And I miss some equivalent of picture clauses in C every time I see, >including in this NG, a number consisting of a string of say 8 or 9
or more digits without the every three digit separator character,
which sure makes reading such numbers easier. :-(
printf has supported that capability for decades.
$ LANG=en_US.utf8 printf "%'10.2f\n" $(( 1540.0 * 179.47 + (7928 +
401 - 535) * 67.61 + 2295 * 173.35 + 3230 * 191.00 + 192 * 750.15 +
150 * 509.85 + 254 * 6> 2,505,496.61
John Levine <johnl@taugh.com> writes:
According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:
That may have been the idea, but I think the idea was wrong.
I think few would disagree with both parts of that. I certainly wouldn't. But I give the designers some slack as, in the late
1950s, there was lettle knowledge about programming languages to
go on.
Certainly.
Now, the mistake is obvious.
Maybe not so obvious. Certainly, as the start of this discussion
shows, the idea that a programming language should orient itself
towards the native language of a person is not yet universally
considered a mistake.
Anyway, such mistakes are valuable as we now can say that this idea
was tried, and did not catch on.
Scott Lurndal wrote:
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
MitchAlsup1 wrote:
And I miss some equivalent of picture clauses in C every time I
see, including in this NG, a number consisting of a string of say
8 or 9 or more digits without the every three digit separator
character, which sure makes reading such numbers easier. :-(
printf has supported that capability for decades.
$ LANG=en_US.utf8 printf "%'10.2f\n" $(( 1540.0 * 179.47 + (7928 +
401 - 535) * 67.61 + 2295 * 173.35 + 3230 * 191.00 + 192 * 750.15
+ 150 * 509.85 + 254 * 6> 2,505,496.61
If the mechanisms that you and Anton present were so easily available,
why do I see so many instances of "non separated" outputs? Are they
too recent, or are programmers too lazy, or do they believe that users
don't care (i.e. that I am in a minority)?
Scott Lurndal wrote:
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
MitchAlsup1 wrote:
And I miss some equivalent of picture clauses in C every time I see,
including in this NG, a number consisting of a string of say 8 or 9
or more digits without the every three digit separator character,
which sure makes reading such numbers easier. :-(
printf has supported that capability for decades.
$ LANG=en_US.utf8 printf "%'10.2f\n" $(( 1540.0 * 179.47 + (7928 +
401 - 535) * 67.61 + 2295 * 173.35 + 3230 * 191.00 + 192 * 750.15 +
150 * 509.85 + 254 * 6> 2,505,496.61
If the mechanisms that you and Anton present were so easily available,
why do I see so many instances of "non separated" outputs? Are they
too recent, or are programmers too lazy, or do they believe that users
don't care (i.e. that I am in a minority)?
John Levine <johnl@taugh.com> writes:
COBOL is older than Fortran
According to Wikipedia, COBOL was designed in 1959. A draft of the
FORTRAN specification was completed in 1954, a manual appeared in
1956, and the compiler was delivered in 1957. COBOL also looks
syntactically more modern, with something BNF-like already leading to excessive syntax, whereas Fortran's approach to white space makes it
obvious that the modern (i.e., post-FORTRAN) division into scanning an parsing had not been developed yet and had not affected the syntax.
On Mon, 20 May 2024 15:51:34 -0000 (UTC)
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> wrote:
Scott Lurndal wrote:
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
MitchAlsup1 wrote:
And I miss some equivalent of picture clauses in C every time I
see, including in this NG, a number consisting of a string of say
8 or 9 or more digits without the every three digit separator
character, which sure makes reading such numbers easier. :-(
printf has supported that capability for decades.
$ LANG=en_US.utf8 printf "%'10.2f\n" $(( 1540.0 * 179.47 + (7928 +
401 - 535) * 67.61 + 2295 * 173.35 + 3230 * 191.00 + 192 * 750.15
+ 150 * 509.85 + 254 * 6> 2,505,496.61
If the mechanisms that you and Anton present were so easily available,
why do I see so many instances of "non separated" outputs? Are they
too recent, or are programmers too lazy, or do they believe that users
don't care (i.e. that I am in a minority)?
All three and more. It's none-recent, but not universally available >extension.
4th reason - output formatted this way is less
machine-readable which is important downside on comp.arch.
5th reason is that separators are culture-dependent. How many European >countries use comma-separated triads? I think, very few.
Scott Lurndal wrote:
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
MitchAlsup1 wrote:
And I miss some equivalent of picture clauses in C every time I see,
including in this NG, a number consisting of a string of say 8 or 9
or more digits without the every three digit separator character,
which sure makes reading such numbers easier. :-(
printf has supported that capability for decades.
$ LANG=en_US.utf8 printf "%'10.2f\n" $(( 1540.0 * 179.47 + (7928 +
401 - 535) * 67.61 + 2295 * 173.35 + 3230 * 191.00 + 192 * 750.15 +
150 * 509.85 + 254 * 6> 2,505,496.61
If the mechanisms that you and Anton present were so easily available,
why do I see so many instances of "non separated" outputs?
Are they
too recent,
or are programmers too lazy, or do they believe that users
don't care (i.e. that I am in a minority)?
In article <2024May20.145316@mips.complang.tuwien.ac.at>, >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
I am not convinced that the locale-specific input is a good idea,
though.
You look pretty silly if your input function can't read the products of
your output function, and figuring out what separators have been used >automatically is not foolproof.
John Levine <johnl@taugh.com> writes:
According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:
That may have been the idea, but I think the idea was wrong.
I think few would disagree with both parts of that. I certainly >>>wouldn't. But I give the designers some slack as, in the late 1950s, >>>there was lettle knowledge about programming languages to go on.
Certainly.
Now, the mistake is obvious.
Maybe not so obvious. Certainly, as the start of this discussion
shows, the idea that a programming language should orient itself
towards the native language of a person is not yet universally
considered a mistake.
Anyway, such mistakes are valuable as we now can say that this idea
was tried, and did not catch on. Ok, this might be due to programming language designers not liking the idea while it was popular with
programmers, but given that programmers language designers tend to
also be programmers, and many programmers have designed another
programming language if they did not like what they are given, I doubt
that.
COBOL is older than Fortran
According to Wikipedia, COBOL was designed in 1959. A draft of the
FORTRAN specification was completed in 1954, a manual appeared in
1956, and the compiler was delivered in 1957. COBOL also looks
syntactically more modern, with something BNF-like already leading to excessive syntax, whereas Fortran's approach to white space makes it
obvious that the modern (i.e., post-FORTRAN) division into scanning an parsing had not been developed yet and had not affected the syntax.
Don't forget that while COBOL's control structures were quite weak,
its data structures still look pretty good. Everything in a C or C++ >>structure comes from COBOL by way of PL/I.
And Algol 68.
- anton
MitchAlsup1 wrote:
John Levine wrote:
According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:
That may have been the idea, but I think the idea was wrong.
I think few would disagree with both parts of that. I certainly
wouldn't. But I give the designers some slack as, in the late
1950s, there was lettle knowledge about programming languages to
go on. Now, the mistake is obvious.
COBOL is older than Fortran, and back in the day there were plenty
of people who were outraged at I=I+1 which is mathematically absurd
for the
physicicts and mathematicians who were Fortran's early users.
Algol gave us various kinds of := which were supposed to be better.
Yes, the COMPUTE statement. i.e. COMPUTE I = I + 1
You could do that, but I think this is at least as clear:
ADD 1 TO PRODUCT-INDEX.
Don't forget that while COBOL's control structures were quite weak,
its data structures still look pretty good. Everything in a C or
C++ structure comes from COBOL by way of PL/I.
Picture data structures ??
I'm not sure what you are saying here.
While Picture clauses are not
in C nor C++, John never cleamed they were. His clain was that those features that were included came from COBOL. e.g. nested structs,
array of structs, structs of arrays, etc.
And I miss some equivalent of picture clauses in C every time I see, including in this NG, a number consisting of a string of say 8 or 9 or
more digits without the every three digit separator character, which
sure makes reading such numbers easier. :-(
Fortran of old has a context sensitive lex - what constitutes a "token" depends on what else is in the same statement and/or where it is
located in the punch card (even if the "punch card" is a disk file).
E.g.
do x = 1,5
do x = 1.5
When one removes the white space they become dox=1,5 and dox=1.5 so to determine if the first token is "DO", a language token, or "DOX",
an identifier token, it must scan ahead and see the ',' or '.'.
If it sees ',' then it must be a DO loop so 'X' must be an identifier,
but if it sees a '.' then this is an assignment to an identifier "DOX".
And that scan ahead can cross many continuation cards.
There is a set of rules called "Sale's Algorithm" published by someone
named Sale in CACM in the sixties that covers some of this.
Fortran lex/parse gets worse with the DEC Fortran 77 enhancements
as the interpretation of tokens can change depending on declarations
made elsewhere in the program. E.G.
if (a .eq. b) then
(".eq." is the Fortran compare-equal operator)
This could be a compare if "A" equals "B",
or a record named "A" containing a sub-record named "EQ",
containing a logical (boolean) field named "B" to test TRUE/FALSE.
Here the lexer has to consult the symbol table to determine
what kind of token ".eq." is.
jgd@cix.co.uk (John Dallman) writes:
In article <2024May20.145316@mips.complang.tuwien.ac.at>,
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
I am not convinced that the locale-specific input is a good idea,
though.
You look pretty silly if your input function can't read the products of
your output function, and figuring out what separators have been used
automatically is not foolproof.
Yes and yes. Especially given the "," vs. "." roles in various
locales.
But OTOH, not being able to read or, worse, misinterpreting the output produced by someone else just because that output was produced under a different locale is pretty silly, too.
For reserved words and builtin names of programming languages, the
solution has been to make them independent of the locale and ignore
Algol 60 and Algol 68 for programming, which suggested something else.
We already do the same for the decimal separator in the usual output functions (it uses "."), we should introduce thousands separators that
are also locale-independent.
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
Scott Lurndal wrote:
see, >> > including in this NG, a number consisting of a string of"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
MitchAlsup1 wrote:
And I miss some equivalent of picture clauses in C every time I
say 8 or 9 >> > or more digits without the every three digit
separator character, >> > which sure makes reading such numbers
easier. :-( >>
750.15 + >> 150 * 509.85 + 254 * 6> 2,505,496.61printf has supported that capability for decades.
$ LANG=en_US.utf8 printf "%'10.2f\n" $(( 1540.0 * 179.47 + (7928 +
401 - 535) * 67.61 + 2295 * 173.35 + 3230 * 191.00 + 192 *
If the mechanisms that you and Anton present were so easily
available, why do I see so many instances of "non separated"
outputs?
What locale are you using?
Are they
too recent,
SUSv3 is from 2001. But have Windows implementations of printf and
scanf implemented the "'" flag? If so, when?
or are programmers too lazy, or do they believe that users
don't care (i.e. that I am in a minority)?
An alternative explanation is that programmers believe that users care
that the output of the program can be used as input to programs with a minimum of fuss.
There are two difficulties here:
* There are likely programs that do not understand input with
thousands separators. This includes the printf program shown above
at least as supplied with Debian 12. So if a program outputs
thousands separators, there may be difficulties in feeding that to
downstream programs.
* The text representation becomes locale-specific:
[b3:~:105507] LC_NUMERIC=en_US printf "%'10d\n" 505496
505,496
[b3:~:105508] LC_NUMERIC=de_AT printf "%'10d\n" 505496
505.496
Note that the first output would be interpreted as 505496E-3 in the
de_AT locale, and the second would also be interpreted as 505496E-3
in the en_US locale.
Therefore I think that we need some locale-independent thousands (and decimal) separators.
For the decimal separator every programming
language uses ".".
For the thousands separator, Ada, C#, D, Eiffel,
Go, Haskell, Java, Julia, Perl, Python3, Ruby, Rust, and Swift use _.
And Gforth, too.
In C++, there is a conflict of _ with another feature, so they instead
chose '. However, C++ is not used interactively, and in a code
generator that generates C++ code, having to replace _ with ' for
generating C++ code is a minor pain.
- anton
COBOL is older than Fortran,
John Levine <johnl@taugh.com> schrieb:
COBOL is older than Fortran,
Certainly not (unless you mean "Fortran" in the Fortran 90+ sense).
FORTRAN was released 1957, and the first Cobol specification
appears to have been passed in 1960.
It appears that Thomas Koenig <tkoenig@netcologne.de> said:
John Levine <johnl@taugh.com> schrieb:
COBOL is older than Fortran,
Certainly not (unless you mean "Fortran" in the Fortran 90+ sense).
FORTRAN was released 1957, and the first Cobol specification
appears to have been passed in 1960.
I was thinking of Flow-Matic which is arguably older than
Fortran and is where most of COBOL came from. Grace Hopper
was entirely familar with mathematical notation and said that
Univac's business customers didn't like it.
John Levine <johnl@taugh.com> schrieb:
It appears that Thomas Koenig <tkoenig@netcologne.de> said:
John Levine <johnl@taugh.com> schrieb:
COBOL is older than Fortran,
Certainly not (unless you mean "Fortran" in the Fortran 90+ sense). >>>FORTRAN was released 1957, and the first Cobol specification
appears to have been passed in 1960.
I was thinking of Flow-Matic which is arguably older than
Fortran and is where most of COBOL came from. Grace Hopper
was entirely familar with mathematical notation and said that
Univac's business customers didn't like it.
Seems that Flow-Matic became publically available in 1958 and was >"substantially complete" by 1959, so FORTRAN came earlier.
Anton Ertl wrote:
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
If the mechanisms that you and Anton present were so easily
available, why do I see so many instances of "non separated"
outputs?
What locale are you using?
I happen to be in the US, however . . .
When I mentioned "in this NG", I meant posts that present the outputs
of some similation program, reduced trace data, GREP output, etc.
For the decimal separator every programming
language uses ".".
Do they?
I vaguely remember that in COBOL (which was defined before
locale were a thing), if you specified "Decimal is Comma" (I may have
the syntax wrong), then the decimal speparator became the comma.
Perhpa this wasn't brought forward. But then if you use the period for
the three digits separator and the decimal separator, doesn't that
cause confusion?
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
Anton Ertl wrote:
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
If the mechanisms that you and Anton present were so easily
available, why do I see so many instances of "non separated"
outputs?
What locale are you using?
I vaguely remember that in COBOL (which was defined before
locale were a thing), if you specified "Decimal is Comma" (I may have
the syntax wrong), then the decimal speparator became the comma.
In the source code? And was is the default? And how many programs
used this option?
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
Anton Ertl wrote:
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
If the mechanisms that you and Anton present were so easily
available, why do I see so many instances of "non separated"
outputs?
What locale are you using?
I happen to be in the US, however . . .
When I mentioned "in this NG", I meant posts that present the
outputs of some similation program, reduced trace data, GREP
output, etc.
So the question is what locale the posters in this newsgroup use. I typically use the C.utf8 locale, because then ls sorts directories as Thompson intended, but which does not show thousands separator. If I
want to show thousands separators, I usually do it with
LC_NUMERIC=prog <command>
or (on machines where I have not installed the prog locale):
LC_NUMERIC=en_US <command>
Let's see how that works for some programs:
[c8:~:105615] LC_NUMERIC=prog perf stat true
Performance counter stats for 'true':
0.17 msec task-clock # 0.376 CPUs
utilized 0 context-switches # 0.000
K/sec 0 cpu-migrations # 0.000
K/sec 42 page-faults # 0.242
M/sec 470_561 cycles # 2.716 GHz
5_214 stalled-cycles-frontend # 1.11% frontend
cycles idle 28_375 stalled-cycles-backend #
6.03% backend cycles idle 515_987 instructions
# 1.10 insn per cycle
# 0.05 stalled cycles per insn 103_096 branches
# 595.157 M/sec 4_973 branch-misses #
4.82% of all branches
0.000460708 seconds time elapsed
0.000522000 seconds user
0.000000000 seconds sys
I don't know what simulation program you have in mind, or what
reduction method you have in mind for trace data, or a grep option
that produces big numbers, but one thing I often do with grep or other
output is to pipe it to wc. So let's see:
[c8:~:105619] LC_NUMERIC=prog wc -c types.bib
21028 types.bib
So, no luck here; one can use printf to reformat the output, e.g.
LC_NUMERIC=prog printf "%'d %s\\n" `wc -c types.bib`
but I have never done that.
For the decimal separator every programming
language uses ".".
Do they?
In the source code, every one that I have ever encountered, and likely
most that I have not. Sure, there is the Algol 60 and Algol 68
crazyness of making that implementation-defined, but are there any implementations of these languages that do not use "." for the decimal
point?
I vaguely remember that in COBOL (which was defined before
locale were a thing), if you specified "Decimal is Comma" (I may
have the syntax wrong), then the decimal speparator became the
comma.
In the source code?
And was is the default?
And how many programs
used this option?
On Mon, 20 May 2024 15:51:34 -0000 (UTC)
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> wrote:
Scott Lurndal wrote:
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
MitchAlsup1 wrote:
And I miss some equivalent of picture clauses in C every time I
see, including in this NG, a number consisting of a string of say
8 or 9 or more digits without the every three digit separator
character, which sure makes reading such numbers easier. :-(
printf has supported that capability for decades.
$ LANG=en_US.utf8 printf "%'10.2f\n" $(( 1540.0 * 179.47 + (7928 +
401 - 535) * 67.61 + 2295 * 173.35 + 3230 * 191.00 + 192 * 750.15
+ 150 * 509.85 + 254 * 6> 2,505,496.61
If the mechanisms that you and Anton present were so easily available,
why do I see so many instances of "non separated" outputs? Are they
too recent, or are programmers too lazy, or do they believe that users
don't care (i.e. that I am in a minority)?
All three and more. It's none-recent, but not universally available extension.
4th reason - output formatted this way is less
machine-readable which is important downside on comp.arch.
5th reason is that separators are culture-dependent. How many European countries use comma-separated triads? I think, very few.
Anton Ertl wrote:[...]
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
So the question is what locale the posters in this newsgroup use. I
typically use the C.utf8 locale, because then ls sorts directories as
Thompson intended, but which does not show thousands separator. If I
want to show thousands separators, I usually do it with
LC_NUMERIC=prog <command>
or (on machines where I have not installed the prog locale):
LC_NUMERIC=en_US <command>
Let's see how that works for some programs:
[c8:~:105615] LC_NUMERIC=prog perf stat true
Performance counter stats for 'true':
0.17 msec task-clock # 0.376 CPUs
utilized 0 context-switches # 0.000
K/sec 0 cpu-migrations # 0.000
K/sec 42 page-faults # 0.242
M/sec 470_561 cycles # 2.716 GHz
5_214 stalled-cycles-frontend # 1.11% frontend
cycles idle 28_375 stalled-cycles-backend #
6.03% backend cycles idle 515_987 instructions
# 1.10 insn per cycle
# 0.05 stalled cycles per insn 103_096 branches
# 595.157 M/sec 4_973 branch-misses #
4.82% of all branches
0.000460708 seconds time elapsed
0.000522000 seconds user
0.000000000 seconds sys
I would be happier with that (using an underscore for the thousands >separator) than with no separation.
I vaguely remember that in COBOL (which was defined before
locale were a thing), if you specified "Decimal is Comma" (I may
have the syntax wrong), then the decimal speparator became the
comma.
In the source code?
I had tolook this up, as it has been far to long, but yes.
https://www.ibm.com/docs/en/cobol-zos/6.3?topic=section-decimal-point-is-comma-clause
No, if you wanted to use this, you added the "Decimal point is comma" >statement in the configuration section. Note that this is obsolete, as
COBOL now supports some version of locales.
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
Anton Ertl wrote:
[...]"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
I >> typically use the C.utf8 locale, because then ls sortsSo the question is what locale the posters in this newsgroup use.
directories as >> Thompson intended, but which does not show
thousands separator. If I >> want to show thousands separators, I
usually do it with >>
0.000 >> K/sec 0 cpu-migrations #LC_NUMERIC=prog <command>
or (on machines where I have not installed the prog locale):
LC_NUMERIC=en_US <command>
Let's see how that works for some programs:
[c8:~:105615] LC_NUMERIC=prog perf stat true
Performance counter stats for 'true':
0.17 msec task-clock # 0.376 CPUs
utilized 0 context-switches #
0.000 >> K/sec 42 page-faults #
0.242 >> M/sec 470_561 cycles #
2.716 GHz >> 5_214 stalled-cycles-frontend #
1.11% frontend >> cycles idle 28_375
stalled-cycles-backend # >> 6.03% backend cycles idle
515_987 instructions >> # 1.10 insn per cycle
# >> 4.82% of all branches# 0.05 stalled cycles per insn 103_096 branches
# 595.157 M/sec 4_973 branch-misses
0.000460708 seconds time elapsed
0.000522000 seconds user
0.000000000 seconds sys
I would be happier with that (using an underscore for the thousands separator) than with no separation.
The underscore is due to my "prog" locale <https://www.complang.tuwien.ac.at/anton/locale-prog/>. If you use LC_NUMERIC=en_US, you get "," as thousands separator; if you use,
e.g., LC_NUMERIC=de_AT, you get ".". If you use LC_NUMERIC=C, you get nothing. All assuming you have these locales installed.
I vaguely remember that in COBOL (which was defined before
locale were a thing), if you specified "Decimal is Comma" (I may
have the syntax wrong), then the decimal speparator became the
comma.
In the source code?
I had tolook this up, as it has been far to long, but yes.
Interesting. Can be seen as another unneeded feature that later
programming languages did not include.
No, if you wanted to use this, you added the "Decimal point is
comma" statement in the configuration section. Note that this is
obsolete, as COBOL now supports some version of locales.
But that's a different feature: decimal-point-is-comma is for the
source code, while the locale is for the input and output of the
resulting program. If you compile a C program with LC_NUMERIC=de_AT,
the decimal separator in the C code is still ".", not what comes from
the locale. But if you then run a printf or scanf with the "'" in the conversion specifier (and you are on a Unix system), you get the
output according to the locale, and the input is scanned according to
the locale.
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
Anton Ertl wrote:
No, if you wanted to use this, you added the "Decimal point is comma" >>statement in the configuration section. Note that this is obsolete, as >>COBOL now supports some version of locales.
... back in the day there were plenty of
people who were outraged at I=I+1 which is mathematically absurd for the physicicts and mathematicians who were Fortran's early users.
Algol gave us various kinds of := which were supposed to be better.
Don't forget that while COBOL's control structures were quite weak,
its data structures still look pretty good. Everything in a C or C++ structure comes from COBOL by way of PL/I.
The power of PL/1s DCL like was similarly a joy to use.
DO 400 I = 10
Is an assignment statement assigning the variable DO400I the value of 10
5th reason is that separators are culture-dependent.
Anton Ertl wrote:
"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
Anton Ertl wrote:
No, if you wanted to use this, you added the "Decimal point is comma" >>>statement in the configuration section. Note that this is obsolete, as >>>COBOL now supports some version of locales.
Can a LOCALE specify that ' ' is the separator character ?? and that
':' is the decimal point character ??
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 54:57:54 |
| Calls: | 10,397 |
| Calls today: | 5 |
| Files: | 14,067 |
| Messages: | 6,417,420 |
| Posted today: | 1 |