"Digit Grouping" is messed up

[Roland]

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

[Didier Lachieze]

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)

[Wes Loewer]

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?

[Roland]

Quote:Is anyone aware of any other programming languages that allow this?

Java (;-)

[Roland]

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

[Wes Loewer]

(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?

[Roland]

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

[Wes Loewer]

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?

[ijabbott]

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.)

[Roland]

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 (;-)

[Roland]

(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

[Thomas_Sch]

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.

[IHarwell]

(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.