Nf() issue with decimal point

Processing Coding Questions
1

Hi,

The following prints 1,2 (with comma) instead of 1.2:

float f = 1.23;
String s = nf(f, 0, 1);
println(s);  // Prints "1,2"

That behaviour was already reported in April 2016, yet contiues to contradict the description of nf().

With only one parameter, it works fine, but then str() would also work:

float f = 1.23;
String s = str(f);
println(s);  // Prints "1.23"

nfc() is even less perfect:

float f = 42525.34343; 
String s = nfc(f, 2);
println(s);  // Prints "42 525,34 instead of 42,525.34"

Thanks

1 Like
2

Are you using a system that is set to use UK English? That is how they do decimals over there. As the link you have mentioned points out, you can correct this by tacking on:
.replace(',', '.').replace(' ', ',');

1 Like
3

My system uses a decimal point and a space as a digit grouping symbol. Just tried changing the latter to a comma, but nfc() didn’t care.
Thank you

4

@TfGuy44 It is common for commas and decimals to be switched in many European countries or to have spaces instead of commas (in comparison with english-speaking countries).

https://docs.oracle.com/cd/E19455-01/806-0169/overview-9/index.html

1 Like
5

Yes, thank you for restating what I already said back to me. Here is a lemon for you. :lemon:

1 Like
6

Oh, right, I misunderstood you. :stuck_out_tongue:
Lemon accepted.

7

Actually, didn’t you state this is how it’s done in UK English? Which isn’t true and the exact opposite of what @TheWizardBear said!

1 Like
8

@gyula –

Some forum members suspect that this relates to the language / region settings of your machine. Can you share something about whether your computer keyboard, OS, or user profile are configured to a particular country or language? The more information we have the more likely it is that someone can suggest a workaround or that fixes can eventually be incorporated.

You may wish to search for an existing issue here:

and if there is not one, report it.

9

More the JVM. Can you try running -

import java.util.Locale;

float f = 1.23;
String s = nf(f, 0, 1);
println(s);  // Prints "1,2"
println(Locale.getDefault().getLanguage());
println(Locale.getDefault().getCountry());

Also, find where the preferences file is (it’s location is at the bottom of the preferences window at File | Preferences. Edit this file when Processing is not running and try changing the run.options line to

run.options=-Duser.language=en -Duser.country=US

Then re-run Processing and the sketch above.

1 Like
10

@neilcsmith As you suggested, I ran this code,

import java.util.Locale;

float f = 1.23;
String s = nf(f, 0, 1);
println(s);  // Prints "1,2"
println(Locale.getDefault().getLanguage());
println(Locale.getDefault().getCountry());

which printed:

1,2
en
US

Then I quit Processing, in the preferences.txt file changed the line from
run.options=
to
run.options=-Duser.language=en -Duser.country=US

Re-ran Processing and your code, and surprise, surprise I got back my decimal point:

1.2
en
US

I tried my original nfc() code, and now it also worked properly:

float f = 42525.34343; 
String s = nfc(f, 2);
println(s);  // Prints correctly "42,525.34"

Thanks for the tip!
Do other people also need to change the run.options= line in the preferences file to get nf() produce the correct delimiters?

1 Like
11

Did you really get the output en / US before making the change?! :face_with_monocle: That’s really strange if so.

What I suggested is just a workaround to force the locale settings - I’d report a bug on this, although whether the documentation or code should be updated is another question.

12

you see that too?

float f = 654321.23;
println(" nf "+nf(f, 0, 1));                  // Prints " nf 654321.2"
println(" nfc "+nfc(f, 2));                   // Prints " nfc 654,321.25"

the last decimale “5” looks wrong?

13

I did, despite my Win7 system settings:

image
image477Ă—583 44.4 KB

14

I’m not sure how much the Windows settings affect the JDK Locale configuration. However, I’m really surprised that setting the locale language and country to what they claim to be before changes anything! I was expecting the output to be something else.

15

One more script you could try with your old / clean settings (which hopefully might show something unexpected) -

import java.util.Locale;

float f = 1.23;
String s = nf(f, 0, 1);
println(s);  // Prints "1,2"
println(Locale.getDefault());
println(Locale.getDefault(Locale.Category.DISPLAY));
println(Locale.getDefault(Locale.Category.FORMAT));

It is the value of the last line that should be affecting the output.

2 Likes
16

I ran your code with my old Processing preferences, that is without this line:
run.options=-Duser.language=en -Duser.country=US

I got:

1,2
en_US
en_US
hu_HU
1 Like
17

OK, that makes more sense. So your system is somehow registering that it should use Hungarian for formatting things like numbers, dates, etc. That might be related to a setting in Windows somewhere, but I’ve no idea where! Or why they’re different.

It might be worth opening a GitHub issue on this. Firstly to work out whether the docs are wrong or not - is the intention to use the locale settings for format. And, secondly, to document where those settings are read from / whether Processing should use something other than the default mechanism for finding them. Seems all related to changes in https://docs.oracle.com/javase/8/docs/technotes/guides/intl/enhancements.8.html

2 Likes
18

Try this without nf() or nfc():

float f = 654321.23;
println(f);   // Prints "654321.25" instead of "654321.23"

Single-precision floating-point numbers are usually not accurate above 6 significant digits:
Online converter for IEEE 754 numbers with single precision

1 Like
19

Strangely, println() is not so picky with my old Processing preferences:

float f = 654321.23;
println(f);  // Prints "654321.23"

String s = nf(f, 0, 2);
println(s);  // Prints "654321,23"

Anyway, thanks a lot!

20

Why’s that strange? It’s bypassing the formatting for your locale, which the other functions are documented to do.