Improving FIX mode

[c3d]

In DB48X, I decided to implement the FIX mode a bit differently than traditional HP calculators do. The idea is to avoid displaying non-significant zeroes. The difference is that DB48X switches to engineering mode as soon as it cannot display non-zero significant digits, whereas HP calculators traditionally will display leading zeroes in that case.

Here is a comparison in FIX 4 for 1/2, 1/20, 1/200, 1/2000, ... and 1/3, 1/30, ...

The HP48 displays
0.5000, 0.0500, 0.0050, 0.0005, 0.0001, 5.0000E-6,
0.3333, 0.0333, 0.0033, 0.0003, 3.3333E-5, 3.3333E-6

DB48X displays
0.5000, 0.0500, 0.0050, 0.0005, 5.0000E-5, 5.0000E-6
3.3333E-1, 3.3333E-2, 3.3333E-3, 3.3333E-4, 3.3333E-5, 3.3333E-6

I personally prefer that, so I want to be able to keep my preferred display. However, someone already contacted me to report that this was unexpected. So I am considering adding an option.

I see two ways to recover the HP behaviour:

- One option would be to add yet another display mode (DB48X already has FIX, SCI, ENG and SIG, the latter being inspired by C47 / WP34). It could be called ADFIX (all-digits FIX).

- Another option, which I prefer, would be to have another setting indicating how many non-significant leading zeroes you allow. If 4 or more in FIX4, you would get the HP behaviour. A value of 9 would get you the HP behaviour for all values of FIX.

What do you think?

If at all possible, please copy your thoughts here: https://github.com/c3d/DB48X-on-DM42/issues/412.

[Albert Chan]

I think in FIX mode, we are not supposed to see "E"

Scientific notation switch really signals FIX conversion failed.
(Either overflowed limited display or underflow to 0.000...)

https://github.com/c3d/DB48X-on-DM42/issues/412 Wrote:// Also, since DB48X can compute on 34 digits, and counting zeroes
// can be annoying, there is a separate setting for when to switch
// to scientific notation.

To count zeroes, I found that normalized mode is better: 0.1 ≤ |mantissa| < 1
see IEEE Standard for Floating Point Numbers, by V Rajaraman

12345000 --> 0.12345e+008 --> 8 digits integer part
0.0012345 --> 0.12345e-002 --> 2 0's after decimal point.

[c3d]

Solving this by adding a new setting, MinimumSignificantDigits.

This selects the minimum number of significant digits before switching to scientific notation in FIX mode.

The default value is 0, which is similar to how HP calculators perform. For example, with 2 FIX, the value 0.055 will display as 0.06, and 0.0055 will display as 0.01.

A higher value will switch to scienfic mode to show at least the given number of digits. For instance, with 2 FIX, if the value is 1, then 0.055 will still display as 0.06 but 0.0055 will display as 5.50E-3. If the value is 2, then 0.055 will display as 5.5E-2.

In other words, setting the value to 0 emulates the behaviour of HP calculators. Setting the value to 34 will switch to scientific notation if not all digits can be displayed

[Pyjam]

I would expect value 0 to disable the switch to SCI completely. So, a true FIX mode.
0.00555 → FIX 2 → 0.01
0.000555 → FIX 2 → 0.00

I find it very strange to go from 0.01, which is very imprecise, to 5.55 E-04 by dividing by 10.

Note that I am not asking for this function. I'm not a DB48 user.

[Albert Chan]

(10-20-2023 08:07 AM)Pyjam Wrote:  I would expect value 0 to disable the switch to SCI completely. So, a true FIX mode.
0.00555 → FIX 2 → 0.01
0.000555 → FIX 2 → 0.00

I agree this is how FIX mode should work.
It is supposed to lose information! 0.00 is OK!

I do not understand how DIG setting work, and posted the question to issue.
Since DIG=0 match HP behavior, this is my guess.
For FIX-02, ULP = 0.01

DIG=0      HP behavior, flip to SCI if below 10^0/2 = 0.5 ULP      (*)
DIG=1      flip to SCI if below 10^1/2 = 5.0 ULP
...

For true FIX mode, DIG setting is negative, flip = 10^DIG/2 = 0.0

(*) Exception, no flip if FIX mode form already matched value.
     Example, any DIG setting, FIX mode of 0. = 0.000...

[Pyjam]

It took me a while to figure it out too.
DIG is the minimum number of significant digits you want to see, otherwise it goes to SCI.
In FIX 3 and DIG 1, it can go down to 0.00n, and in FIX 4 to 0.000n, and so on.
In FIX 3 and DIG 2, it can go down to 0.0nn, and in FIX 4 to 0.00nn, and so on.
In FIX 3 and DIG 3, it can go down to 0.nnn, and in FIX 4 to 0.0nnn, and so on.
I'd find it normal to choose DIG = FIX. But it’s far from being a true FIX mode.

I think the real problem is that some users want a non-SCI display for numbers that aren't too large, because they want to read 12.36 rather than 1.236 E+01. And they want to switch to SCI or ENG for large or really small numbers. It's the SIG mode they really want, as I've described here:
https://www.hpmuseum.org/forum/thread-20...#pid178758

I don't know if this display format exists on DB48.

[Albert Chan]

(10-20-2023 11:17 AM)Pyjam Wrote:  It took me a while to figure it out too.
DIG is the minimum number of significant digits you want to see, otherwise it goes to SCI.
In FIX 3 and DIG 1, it can go down to 0.00n, and in FIX 4 to 0.000n, and so on.

In Fix 3 and Dig 0, it can go down to 0.00n too!

What is 0 significant digit? It is just too confusing.

From https://github.com/c3d/DB48X-on-DM42/iss...1765870801
Fix 4 and Dig 0: 0.000055 --> 0.0001
Fix 4 and Dig 1: 0.000055 --> 5.5000e-5

c3d Wrote:With Dig 1, the number in level 4 [0.000055] changes, because we want
at least one real significant digit to show, and the 1 there is not significant (it’s rounding)

What is real significant digit? Round up from 0 to 1 not real?

https://www.chemteam.info/SigFigs/SigFigRules.html Wrote:Rule#1: Non-zero digits are always significant.

Even without rounding up, 0 is a significant digit.

https://speleotrove.com/decimal/decifaq2.html Wrote:The number zero is a special case; because it requires one digit
to indicate its presence it is usually considered to have a precision of 1.

[Pyjam]

It’s even worse than what we imagined:
FIX 2
.0050 ENTER → 0.01
.0049 ENTER → 4.90 E−03
I did this test with a HP-15C CE.

[agarza]

(10-20-2023 02:25 PM)Pyjam Wrote:  It’s even worse than what we imagined:
FIX 2
.0050 ENTER → 0.01
.0049 ENTER → 4.90 E−03
I did this test with a HP-15C CE.

And even worse if on SCI or ENG with digits > 7 positions. The rounding won't be applied.

For example in SCI 6
enter: 9.0000005
screen displays:
9.000001 00. (this is rounded correctly)

Switching to SCI 7, 8 or 9
will not round, and show:
9.000000 00 (no rounding applied)


Tested on HP15C and HP41CX

[Pyjam]

(10-20-2023 02:56 PM)agarza Wrote:  Switching to SCI 7, 8 or 9
will not round, and show:
9.000000 00 (no rounding applied)

It’s not a bug, it’s a feature!
Owner’s Handbook, top of page 59.

SCI mode is in practice limited to 6 positions on the machines, I guess.

[agarza]

(10-20-2023 03:38 PM)Pyjam Wrote:  

(10-20-2023 02:56 PM)agarza Wrote:  Switching to SCI 7, 8 or 9
will not round, and show:
9.000000 00 (no rounding applied)

It’s not a bug, it’s a feature!
Owner’s Handbook, top of page 59.

SCI mode is in practice limited to 6 positions on the machines, I guess.

But I don't like that "feature"!
I know it is rounding, but since the display in SCI or ENG only shows 7 digits + EEX, the rounding is done off the screen and not shown.
Doing the same example with FIX, the screen rounding works fine.

[c3d]

(10-20-2023 08:07 AM)Pyjam Wrote:  I would expect value 0 to disable the switch to SCI completely. So, a true FIX mode.
0.00555 → FIX 2 → 0.01
0.000555 → FIX 2 → 0.00

I find it very strange to go from 0.01, which is very imprecise, to 5.55 E-04 by dividing by 10.

Note that I am not asking for this function. I'm not a DB48 user.

That's an interesting variation, but as far as I know, this one does not exist anywhere. Not hard to implement, though. I'll give it some thought.

[c3d]

(10-20-2023 10:59 AM)Albert Chan Wrote:  

(10-20-2023 08:07 AM)Pyjam Wrote:  I would expect value 0 to disable the switch to SCI completely. So, a true FIX mode.
0.00555 → FIX 2 → 0.01
0.000555 → FIX 2 → 0.00

I agree this is how FIX mode should work.
It is supposed to lose information! 0.00 is OK!

It depends on your goal. I think this is an acceptable and even useful output, but it definitely does not match what any HP calculator does that I know of. At the moment, I'm first trying to be close to what people are used to, and second only trying to offer useful improvements.

Quote:I do not understand how DIG setting work, and posted the question to issue.
Since DIG=0 match HP behavior, this is my guess.
For FIX-02, ULP = 0.01

DIG=0      HP behavior, flip to SCI if below 10^0/2 = 0.5 ULP      (*)
DIG=1      flip to SCI if below 10^1/2 = 5.0 ULP
...

Interestingly, I just noticed that the HP Prime corresponds to the DIG 1 setting, not DIG 0. It does not display 0.01 but 5.50E-3. In other words, there is not one HP behavior but at least two, which DB48X now both supports.

Quote:For true FIX mode, DIG setting is negative, flip = 10^DIG/2 = 0.0

Today, DIG setting cannot be negative. But getting what you call "true" FIX mode does seem somewhat consistent with the idea of a negative DIG value.

I would not call it a "true" FIX mode in the sense that to me, "true" means "HP-like" in that instance.

Quote:(*) Exception, no flip if FIX mode form already matched value.
     Example, any DIG setting, FIX mode of 0. = 0.000...

[Pyjam]

It depends on the field of application, but for example, if a notary splits $0.01 between 3 heirs, that's not $3.33 E-03 for each, but $0.00 for each (and the rest for him).

By the way, this is how it works on HP-12C:
FIX 2
0.0055 ENTER → 0.01
10 ÷ → 0.001
10 ÷ → 0.0001
…
10 ÷ → 0.000000001 (reach the limit of the screen)
10 ÷ → 5.500000 – 11

FIX 2
0.049 ENTER → 0.05
10 ÷ → 0.005
10 ÷ → 0.0005
…
10 ÷ → 0.000000005 (reach the limit of the screen)
10 ÷ → 4.900000 – 10

[c3d]

(10-20-2023 08:07 AM)Pyjam Wrote:  I would expect value 0 to disable the switch to SCI completely. So, a true FIX mode.
0.00555 → FIX 2 → 0.01
0.000555 → FIX 2 → 0.00

I find it very strange to go from 0.01, which is very imprecise, to 5.55 E-04 by dividing by 10.

Note that I am not asking for this function. I'm not a DB48 user.

I don't know of any calculator that does that.

I just noticed that the HP Prime actually corresponds to have value 1, i.e. it does not display 0.01 like the HP48 but 5.50E-3. Interesting.

[c3d]

(10-20-2023 11:17 AM)Pyjam Wrote:  It took me a while to figure it out too.
DIG is the minimum number of significant digits you want to see, otherwise it goes to SCI.
In FIX 3 and DIG 1, it can go down to 0.00n, and in FIX 4 to 0.000n, and so on.
In FIX 3 and DIG 2, it can go down to 0.0nn, and in FIX 4 to 0.00nn, and so on.
In FIX 3 and DIG 3, it can go down to 0.nnn, and in FIX 4 to 0.0nnn, and so on.
I'd find it normal to choose DIG = FIX. But it’s far from being a true FIX mode.

Actually, having DIG > FIX works too. So on DB48X, I'd say there are four really useful settings:

1/ DIG 0: Like historical HP calculators, i.e. 0.55 in FIX 2 divided by 10 repeatedly gives 0.55 0.06 0.01 5.50E-4

2/ DIG 1: Like HP Prime, i.e. do not accept the last digit to be solely a result of rounding: 0.55 0.06 5.50E-3 5.50E-4

3/ DIG 34: Switch to SCI as soon as you loose digits: 0.55 5.50E-2 5.50E-3 5.50E-4

4/ DIG -1: Never switch to SCI on negative exponents: 0.55 0.06 0.01 0.00.

I just implemented that, so this will be a new possible options for whoever is so inclined.

Quote:I think the real problem is that some users want a non-SCI display for numbers that aren't too large, because they want to read 12.36 rather than 1.236 E+01. And they want to switch to SCI or ENG for large or really small numbers. It's the SIG mode they really want, as I've described here:
https://www.hpmuseum.org/forum/thread-20...#pid178758
e
I don't know if this display format exists on DB48.

I've been thinking about what you are asking. Based on the responses, it seems like you'd like to have a FIX/SCI/ENG version of it, which suggests that it is yet another orthogonal setting. I don't have a good design for that yet.

[Pyjam]

(10-21-2023 08:53 AM)c3d Wrote:  I've been thinking about what you are asking. Based on the responses, it seems like you'd like to have a FIX/SCI/ENG version of it, which suggests that it is yet another orthogonal setting. I don't have a good design for that yet.

If it's worth clarifying again, I'm not asking for anything because I'm not a DB48 user. I'm just making some general remarks about number formats.

If you don't know, on C47, the SIG mode takes into account another parameter that indicates whether the changeover is to SCI or ENG mode. I hadn't thought about it before, but I guess this parameter is only relevant if the basic mode chosen is FIX or SIG.

[c3d]

(10-21-2023 10:24 AM)Pyjam Wrote:  

(10-21-2023 08:53 AM)c3d Wrote:  I've been thinking about what you are asking. Based on the responses, it seems like you'd like to have a FIX/SCI/ENG version of it, which suggests that it is yet another orthogonal setting. I don't have a good design for that yet.

If it's worth clarifying again, I'm not asking for anything because I'm not a DB48 user. I'm just making some general remarks about number formats.

Understood. You are not a DB48X user. Yet ;-D

Quote:If you don't know, on C47, the SIG mode takes into account another parameter that indicates whether the changeover is to SCI or ENG mode. I hadn't thought about it before, but I guess this parameter is only relevant if the basic mode chosen is FIX or SIG.

That's one way to do it.