newRPL: Number formatting on screen

[Claudio L.]

The basic number format needs as input:
* Mode:
Standard: 123400000
SCI: 1.234E8

* Number of digits to display: For standard mode, this number is the number of figures after decimal dot. For all others this is the total number of significant figures to display.

* Configurable characters based on locale for: decimal dot, thousand separator, fractional part separator, and exponent letter (e or E?)

* A few true/false flags for:
a) Add thousand separator: 1,000,000.0 (as example, using comma for separator)
b) Fractional part separator: 0.123 456 789 (as example, using space as separator)
c) Show trailing zeros (FIX): 123.0000 instead of 123
d) Adjust exponent to multiple of 3 (ENG)

Question: Can these simplified options cover all cases? am I missing some other formatting options?

For example, the number 123456789:
Standard, 6 digits: 123456789
Standard, 6 digits, trailing zeros: 123456789.000000
Standard 6 digits, trailing zeros, thousand and frac. separator: 123,456,789.000 000
Sci, 6 digits: 1.23457E8
Sci, 12 digits: 1.23456789E8
Sci, 12 digits, trailing zeros: 1.23456789000E8
Sci, 12 digits, trailing zeros, frac. separator: 1.234 567 890 00E8
Sci, adjust exponent ENG, 12 digits: 123.456789E6

Notice there's some flexibility here not present in the 50g. In Sci mode, the 50g always shows the same number of digits. Here you have the option to display or not any trailing zeros. So the number 2.5 in SCI notation can be 2.5E0 even if you select 6 digits. If you like the trailing zeros, then activate the flag and it will become 2.50000E0.
In standard notation, the trailing zeros acts like the FIX mode. For example, with 6 digits selected (at 36 digit precision), doing 2 3 / will display 0.666667, but 2 4 / will only show 0.5 unless trailing zeros is selected.

I also have the idea of having 3 different and independent formats (each selected as above) active all the time:
* Big numbers
* Mid-range
* Small numbers

There should be a user configurable cut-off between these ranges. For example, I personally like numbers above 10 million to be in SCI notation, numbers smaller than 0.0001 also in SCI notation, but everything in between in standard notation.
So my preferred configuration would be something like:
Big number cut-off: 10000000
Big number format: Sci, 12 digit
Small number cut-off: 0.0001
Small number format: Sci, 6 digit
Other numbers: Standard, 6 digit

The 50g has fixed cut-off limits when in standard mode. Numbers 1e12 and above are forced into SCI notation, numbers 1E-13 and below are forced into SCI notation.

Is this useful or an unnecessary overkill?

For the command line, formatting options will be respected as much as possible during edit, except that:
* All digits must be edited, so the number can be fully recompiled to its previous value. Therefore, display digit count is ignored if the number has more digits than requested.
* Thousand and fraction separators are not included when editing a number.
* Trailing zeros are included only if the number has less than the requested number of digits.

Any other options needed?

[Sylvain Cote]

Leading zeros ?
Nice for formatting and binary numbers.
As an example, FIX could be defined as matissa.fractions
Sylvain

[Claudio L.]

(07-08-2015 01:42 PM)Sylvain Cote Wrote:  Leading zeros ?
Nice for formatting and binary numbers.
As an example, FIX could be defined as matissa.fractions
Sylvain

Interesting, how would we define the number of leading zeros? By the total number of integer part digits?
The fraction part digits are a hard limit: if you have more digits, they get rounded and truncated. How do we handle the case when the number if integer digits > requested digits?
I remember some BASICs used to put a hard limit, and either truncate the number or change it to #####. This was OK to keep tables properly formatted, but not OK if you cared what the value of the number was!
In C's printf(), this is not a hard limit, so if you have more digits then so be it, but it defeats the purpose of formatting, as it only "sometimes" formats properly.

Since you mentioned binary numbers, how do we define the leading zeros for numbers with base different than 10?
If we select 3 digits, then #010d, #010h, #010o and #010b would have 3 digits, except each digit means something different in each base.
Perhaps leading zeros should be given by the selected word size? this way if you select 8 bits, then it will show 8 zeros in binary, and only 2 digits in hexa.

[Nigel (UK)]

Being able to set different formats for different sized numbers is an excellent idea.

I personally like being able to limit the number of significant figures displayed without forcing use of scientific notation. So, for example:

pi is shown as 3.142;
100 000 * pi is shown as 314 200.

I don't think that your proposal currently allows this; might you consider it? (It's implemented on the WP-34S as SF mode, if you have the correct firmware version.)

Nigel (UK)

[Paul Dale]

Some countries group their digits in clusters of size other than three. Two and four definitely are used but it would be best to leave the number open (within reason):

Code:

123 456
12 34 56
12 3456

I'm not aware of different grouping each side of the decimal.


It might be worthwhile reviewing the discussions about display modes that took place for the 34S. There were quite a few good ideas presented and we implemented some of these.


- Pauli

[Claudio L.]

(07-09-2015 09:14 PM)Nigel (UK) Wrote:  Being able to set different formats for different sized numbers is an excellent idea.

I personally like being able to limit the number of significant figures displayed without forcing use of scientific notation. So, for example:

pi is shown as 3.142;
100 000 * pi is shown as 314 200.

I don't think that your proposal currently allows this; might you consider it? (It's implemented on the WP-34S as SF mode, if you have the correct firmware version.)

Nigel (UK)

This is perfectly doable. I'd have to add a flag for "Use total significant figures for standard mode", so the number of digits will mean that, instead of figures after decimal dot.

Thanks for the feedback.

[Claudio L.]

(07-09-2015 10:41 PM)Paul Dale Wrote:  Some countries group their digits in clusters of size other than three. Two and four definitely are used but it would be best to leave the number open (within reason):

Code:

123 456
12 34 56
12 3456

I'm not aware of different grouping each side of the decimal.


It might be worthwhile reviewing the discussions about display modes that took place for the 34S. There were quite a few good ideas presented and we implemented some of these.


- Pauli

I didn't know that. I hardcoded 3 spaces and called it "thousand separator", but it's easy to change. The formatting routine is ready, (except for the suggestions made today), and also is the new arbitrary precision library to replace mpdecimal. I got a negligible edge in speed (like 5%) on my tests on the PC (where mpdecimal is quite well optimized), so I expect to widen the gap on ARM.

For some reason all I found were some discussions happening in Feb 2015, but nothing regarding the original discussions. I did see people complaining about the automatic switch from standard to SCI, so I got that covered with the custom cut-off limits.

[Didier Lachieze]

(07-09-2015 09:14 PM)Nigel (UK) Wrote:  I personally like being able to limit the number of significant figures displayed without forcing use of scientific notation. So, for example:

pi is shown as 3.142;
100 000 * pi is shown as 314 200.

I find this behaviour misleading: it's one thing to limit the number of digit displayed (what you don't see, you don't know what it is) and it's another thing to display '0' instead of a valid digit: when you see 314200 on the display, the value of the two '0' digits may or may not be the value inside the machine. And nothing tells you which digits are real and which ones are not.

[Claudio L.]

(07-10-2015 03:33 PM)Didier Lachieze Wrote:  

(07-09-2015 09:14 PM)Nigel (UK) Wrote:  I personally like being able to limit the number of significant figures displayed without forcing use of scientific notation. So, for example:

pi is shown as 3.142;
100 000 * pi is shown as 314 200.

I find this behaviour misleading: it's one thing to limit the number of digit displayed (what you don't see, you don't know what it is) and it's another thing to display '0' instead of a valid digit: when you see 314200 on the display, the value of the two '0' digits may or may not be the value inside the machine. And nothing tells you which digits are real and which ones are not.

I specifically dislike the fact that 314200 * 2 = 628300, because the other digits are there, despite being displayed as zero. In that regards, 3.142e5 * 2 looks better to my eyes, so I know that the last digit is rounded.
However, while I personally agree with you, at this stage it's all about giving each user the choice of configuring his calculator any way he pleases, so if a number of people think it's a good display mode... why not, right?

[Claudio L.]

(07-08-2015 01:25 PM)Claudio L. Wrote:  So the number 2.5 in SCI notation can be 2.5E0 even if you select 6 digits.

One more idea: in SCI mode, would it be a good idea to offer the option (a flag) to omit the exponent when the exponent is zero?
Instead of 2.5E0 we could show 2.5, while 25 would be 2.5E1
I think in ENG mode this could be nice, since numbers 0-999 would be shown without exponent.

[Nigel (UK)]

(07-10-2015 07:10 PM)Claudio L. Wrote:  

(07-10-2015 03:33 PM)Didier Lachieze Wrote:  I find this behaviour misleading: it's one thing to limit the number of digit displayed (what you don't see, you don't know what it is) and it's another thing to display '0' instead of a valid digit: when you see 314200 on the display, the value of the two '0' digits may or may not be the value inside the machine. And nothing tells you which digits are real and which ones are not.

I specifically dislike the fact that 314200 * 2 = 628300, because the other digits are there, despite being displayed as zero. In that regards, 3.142e5 * 2 looks better to my eyes, so I know that the last digit is rounded.
However, while I personally agree with you, at this stage it's all about giving each user the choice of configuring his calculator any way he pleases, so if a number of people think it's a good display mode... why not, right?

Both of these are valid reasons not to use such a mode, but I still like it. It is always the user's responsibility to interpret a displayed number in the context of the chosen display mode. In previous discussions on a WP34S thread there weren't many other people who liked this mode, but I use it regularly without any problems. If it's a choice that can be offered without unreasonably complicating the code, then as Claudio says: why not?

Nigel (UK)

[Paul Dale]

(07-10-2015 03:33 PM)Didier Lachieze Wrote:  I find this behaviour misleading: it's one thing to limit the number of digit displayed (what you don't see, you don't know what it is) and it's another thing to display '0' instead of a valid digit...

What about a second visually distinguishable zero character for the non-significant digits for this mode? A smaller zero perhaps?

The display would be: 314200.
Maybe even superscript or subscript the smaller digits.


- Pauli

[Nigel (UK)]

(07-10-2015 10:32 PM)Paul Dale Wrote:  

(07-10-2015 03:33 PM)Didier Lachieze Wrote:  I find this behaviour misleading: it's one thing to limit the number of digit displayed (what you don't see, you don't know what it is) and it's another thing to display '0' instead of a valid digit...

What about a second visually distinguishable zero character for the non-significant digits for this mode? A smaller zero perhaps?

The display would be: 314200.
Maybe even superscript or subscript the smaller digits.


- Pauli

These are good ideas. Or maybe underline the significant digits?

Nigel (UK)

[Claudio L.]

(07-10-2015 10:32 PM)Paul Dale Wrote:  What about a second visually distinguishable zero character for the non-significant digits for this mode? A smaller zero perhaps?

The display would be: 314200.
Maybe even superscript or subscript the smaller digits.


- Pauli

Not so sure about that: using weird Unicode characters will look great if you only use for display, but I'd prefer if the same formatting routine could be used to generate a string that you can use in a program. Yes, strings will be fully Unicode compliant, but if you output that to a text file on the SD card and try to import in Excel or parse in any other program, good luck with the special characters.
That would force me to write 2 routines: one to convert to text, and a different one for display.
I was hoping for the same routine to be used for display, for text conversion and to decompile reals for the command line.

[Helix]

(07-08-2015 01:25 PM)Claudio L. Wrote:  * Number of digits to display: For standard mode, this number is the number of figures after decimal dot. For all others this is the total number of significant figures to display.

To be consistent with the 50g behavior, for the "SCI" and "ENG" modes, this should be the total number of significant figures minus 1.

For example, 10.12345 with 3 digits:
Standard mode (FIX): 10.123
SCI mode: 1.012E1 (4 significant figures)
ENG mode: 10.12E0 (4 significant figures)

It's not very important, however.

Otherwise, I like very much your formatting proposal.

(07-10-2015 07:29 PM)Claudio L. Wrote:  

(07-08-2015 01:25 PM)Claudio L. Wrote:  So the number 2.5 in SCI notation can be 2.5E0 even if you select 6 digits.

One more idea: in SCI mode, would it be a good idea to offer the option (a flag) to omit the exponent when the exponent is zero?
Instead of 2.5E0 we could show 2.5, while 25 would be 2.5E1
I think in ENG mode this could be nice, since numbers 0-999 would be shown without exponent.

I think it's not necessary, because we could get the same display with the following settings:
big number cut-off: 1000
big number format: ENG
small number cut-off: 1
small number format: ENG
mid-range number format: standard

(07-10-2015 03:33 PM)Didier Lachieze Wrote:  

(07-09-2015 09:14 PM)Nigel (UK) Wrote:  I personally like being able to limit the number of significant figures displayed without forcing use of scientific notation. So, for example:

pi is shown as 3.142;
100 000 * pi is shown as 314 200.

I find this behaviour misleading: it's one thing to limit the number of digit displayed (what you don't see, you don't know what it is) and it's another thing to display '0' instead of a valid digit: when you see 314200 on the display, the value of the two '0' digits may or may not be the value inside the machine. And nothing tells you which digits are real and which ones are not.

It's my opinion too. But as long as there is a flag to control this feature, there is no reason to complain about it, if this is useful for some people.

(07-10-2015 10:32 PM)Paul Dale Wrote:  What about a second visually distinguishable zero character for the non-significant digits for this mode? A smaller zero perhaps?

The display would be: 314200.
Maybe even superscript or subscript the smaller digits.


- Pauli

Another solution would be the presence of an indicator always visible in the display, to remember the number of digits.
One minor problem I see without the trailing zeros, is that in some cases there will be no evidence of what the number of significant digits is exactly. In the 50g, the trailing zeros are always visible, so we easily know the FIX, SCI or ENG settings.
Personnally, I like trailing zeros...

[Claudio L.]

(07-12-2015 01:16 AM)Helix Wrote:  To be consistent with the 50g behavior, for the "SCI" and "ENG" modes, this should be the total number of significant figures minus 1.

For example, 10.12345 with 3 digits:
Standard mode (FIX): 10.123
SCI mode: 1.012E1 (4 significant figures)
ENG mode: 10.12E0 (4 significant figures)

It's not very important, however.

I had to go and check it on the calculator to believe it. I never paid any attention to it, but you are right, if you select 4 it shows 5 significant figures. I guess it makes sense for SCI, since you get the same number of figures after the decimal dot as in standard mode, but in ENG...
anyway, it's easy to implement, so I don't have a problem showing one extra digit.

(07-12-2015 01:16 AM)Helix Wrote:  I think it's not necessary, because we could get the same display with the following settings:
big number cut-off: 1000
big number format: ENG
small number cut-off: 1
small number format: ENG
mid-range number format: standard

You are right again, but I implemented it today before reading your post... now it will take me extra work to remove it, so I guess that option will stay there.

I have a generic question about total significant figures:
If I have a number, let's say 99.9999, and I want to display only 4 total significant figures, so 99.99 rounded goes to 100, but what is more correct: 100.0 or 100.00?
I'm inclined to think 100.00, since the "real" digits you are using are 99.99, the fact that there's a virtual extra digit coming from the rounding doesn't change that your 4 digits are nn.nn, so 1mm.mm seems more appropriate for 4 digits, but is it?
100.0 has 4 significant figures, but does that "virtual" 1 count as "significant" or not? I think not simply because it's not real, but I have no way of knowing if I'm right or wrong about it.
Any thoughts?

[Helix]

Yes, I would prefer the same number of figures after the decimal separator in SCI and standard modes (and ENG mode as in the HP50g).

For the generic question about significant figures, I can see perhaps one disadvantage with your suggestion:
99.999 will give 100.00 on the stack
but 100 will give 100.0 on the stack.
This would generate inconsistent formats for such numbers.