Post Reply 
"Digit Grouping" is messed up
12-31-2021, 03:34 PM (This post was last modified: 01-01-2022 01:56 PM by Gene.)
Post: #1
"Digit Grouping" is messed up
Hello and have a nice day,

I have now bought an HP Prime after all. Didn't want to change at first but my HP 50g forgets several key inputs.

The new Prime is by no means comparable to the quality of workmanship of the old HP computers. Well, what do you want to ask for 120 € in Europe.

But one thing immediately struck me negatively. I don't know if that's a bug, or if I just haven't read something in the manual.

I changed the setting for "Digit Grouping" to 123.456,788 in the setup. In the Anglo-American area there is (always?) 123,456.789

But then you can no longer program the HP Prime! Such a crap.

Already in the first line of the program:
EXPORT Test (a, b) you get an error message and it took me a long time to find out that this is due to the above-mentioned setting for "Digit Grouping". If I write here what I think, there will be trouble because of the many swear words.

Still, of course, everyone
a better new 2022
Find all posts by this user
Quote this message in a reply
12-31-2021, 03:51 PM
Post: #2
RE: "Digit Grouping" is bull shit
To cope with the various separator options you need to add as the first line of your program a #pragma statement to specify the separators to be used within the program. The #pragma statement is accessible with the Menu key, item 5 Insert pragma.

Here is an example of a pragma statement I’m using in my programs:
Code:
#pragma mode( separator(.,;) integer(h32)
Find all posts by this user
Quote this message in a reply
12-31-2021, 04:09 PM
Post: #3
RE: "Digit Grouping" is bull shit
First of all, take a deep breath. :-)

Second, use the #pragma as Didier's suggested.

This ability of the PPL language to use different separators is rather unique among programming languages. Is anyone aware of any other programming languages that allow this?
Find all posts by this user
Quote this message in a reply
12-31-2021, 05:32 PM (This post was last modified: 12-31-2021 05:32 PM by Roland.)
Post: #4
RE: "Digit Grouping" is bull shit
Quote:Is anyone aware of any other programming languages that allow this?

Java (;-)
Find all posts by this user
Quote this message in a reply
12-31-2021, 05:34 PM
Post: #5
RE: "Digit Grouping" is bull shit
Thank you very much,

now it runs when I set the Prime to the format setting as usual here in Germany.

However, you must always adjust the pragma instruction when changing the number separator in the setup.

Oh yes, in Java this is even possible depending on the language set in the computer. That can not only PPL.

https://docs.oracle.com/javase/tutorial/...reate.html
Find all posts by this user
Quote this message in a reply
12-31-2021, 08:01 PM
Post: #6
RE: "Digit Grouping" is bull shit
(12-31-2021 05:34 PM)Roland Wrote:  Oh yes, in Java this is even possible depending on the language set in the computer.
https://docs.oracle.com/javase/tutorial/...reate.html

Does the localization mentioned in the link simply change the input/output formats, or does it allow the source code itself to use the localizations?
Find all posts by this user
Quote this message in a reply
01-01-2022, 07:24 AM
Post: #7
RE: "Digit Grouping" is bull shit
Quote:Does the localization mentioned in the link simply change the input/output formats, or does it allow the source code itself to use the localizations?

You ask in the program code in which language your computer is configured and what should then be done depending on the system language actually set. The javac compiler checks in which language your computer is configured. The settings for the number separator are then actually taken into account. The input format itself is then not changed, the program can deal with the format if this format has been made known through localization.

Code:

    double d = 1.2345;
    Locale locde = new Locale("de", "DE");
    Locale locus = new Locale("en", "US");
    System.out.format(locde, "%.3f\n", d); // 1,235
    System.out.format(locus, "%.3f\n", d); // 1.235
Find all posts by this user
Quote this message in a reply
01-01-2022, 06:03 PM
Post: #8
RE: "Digit Grouping" is messed up
So it sounds like you are saying that the Java's output can be localized, but I was asking about the code itself. In other words, can

Code:
    double d = 1.2345;

be localized to accept

Code:
    double d = 1,2345;

like the Prime can?
Find all posts by this user
Quote this message in a reply
01-01-2022, 06:28 PM (This post was last modified: 01-01-2022 06:29 PM by ijabbott.)
Post: #9
RE: "Digit Grouping" is messed up
As a dot radix user, my opinion on the matter is not valid, but it would be interesting to get the opinions from comma radix users about whether carrying over the choice of radix into the programming language was a good idea or not. (And I mean the actual programming language itself, not locale-specific I/O.)

— Ian Abbott
Find all posts by this user
Quote this message in a reply
01-02-2022, 08:55 AM
Post: #10
RE: "Digit Grouping" is messed up
Quote:like the Prime ...

Goes with java. An example: you want to read data in different countries. If the data are numeric then either commas or periods as separators are possible. In the program then you ask which country and / or which BS and then test it out. Then, in fact, double variables can be read and processed as either 1,234 or 1.234.

PS: apart from that, there have always been such #pragma directives in C.

PPS: However, universities have always taught us that such directives should "not" be implemented. Pragmas are often seen as bad style and HP makes it easy to roll out a problem of implementation to programmers.

PPPS: and sorry for my bad English. I can read English texts but I can not write well (;-)
Find all posts by this user
Quote this message in a reply
01-02-2022, 09:07 AM
Post: #11
RE: "Digit Grouping" is messed up
(01-01-2022 06:28 PM)ijabbott Wrote:  As a dot radix user, my opinion on the matter is not valid, but it would be interesting to get the opinions from comma radix users about whether carrying over the choice of radix into the programming language was a good idea or not. (And I mean the actual programming language itself, not locale-specific I/O.)

I myself am also a beginner, but I think that such behavior should be strictly prescribed in a programming language. So a clear "use this" and not a "either or".

For all things, it already starts in EXPORT Test (a, b). In this case, the comma is not used as a separator between number and descendant numbers. Why then does the error message depend on the system setting to the number separator format?

PS: apart from that, the Prime is a fine machine, I would add it to me again. He has almost replaced my HP50 after just one week.

PSS: sorry for my bad English
Find all posts by this user
Quote this message in a reply
01-02-2022, 10:39 AM
Post: #12
RE: "Digit Grouping" is messed up
Regarding #pragma mode.

The help system gives also some hints, seaching the help tree is helpful (sic)

Searching the forum gives this threads (only looking on the thread titles):
https://www.hpmuseum.org/forum/search.ph...order=desc

- It seems to be a good practice to start yours programs always with #pragma mode
- As far as I have understood, there is no need to modify the statement.
Find all posts by this user
Quote this message in a reply
01-16-2022, 12:06 AM (This post was last modified: 01-16-2022 09:24 AM by IHarwell.)
Post: #13
RE: "Digit Grouping" is messed up
(01-01-2022 06:03 PM)Wes Loewer Wrote:  So it sounds like you are saying that the Java's output can be localized, but I was asking about the code itself. In other words, can

Code:
    double d = 1.2345;

be localized to accept

Code:
    double d = 1,2345;

like the Prime can?

Not typically. It creates problems with the language grammar. For instance, consider two functions:

Code:

f(x) { return x^2; }
f(x,y) { return x*y; }

Now, you have a problem if the user calls:
Code:
f(123,456)

Suddenly, your "formatting choice" changes the meaning of that function call unless the language has subtle rules to prevent the issue. Such rules can be done, but it's pretty low on the list of priorities for things I'd like the devs to put their time into.

It doesn't help that "subtle rules" and "scripting language" do not generally go well together from a design standpoint.

I can't help but notice that both function overloading and comma-separators are allowed in PPL. The method they use to address this collision of features is rather heavy-handed, short-sighted, and can really cause issues for sharing programs.

You have to change the second separator to something other than the first, but they allow symbols that are quite confusing for the second separator, such as ".", "&", "\" or even "*".

That last one is a real problem. What should f(123*456) return? Should that ever change based on a "formatting" choice? The number of ways to break programs or introduce subtle bugs using this is really quite staggering.

There are good reasons that programming languages tend to be as strict about their grammar as they are.
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)