a b/c unexpected function

[celltx]

I bumped into something strange on my Prime G1:

Suppose I'd like to convert 1e-6 number into a fraction form
I press "a b/c" button, and get 1/1000 000 result, everything is correct

Then, if I press "a b/c" button again, the calculator displays a fraction 1/909 091
What is this strange number?

[StephenG1CMZ]

I get similar behaviour on the Android version, except its 1/999 991.

[Joe Horn]

A similar question was recently posted on HP's Calculator Forum. For your convenience, my reply there is copied below:

Joe Horn Wrote:When [a b/c] is pressed in Home view in Standard display mode, here's what is calculated:

First press = QPI(input, 10)
Second press = PDQ(input, 11)

QPI is a built-in function. See its Help screen for details of how it works. It tries to identify "recognizable" numbers, but its result should never be believed blindly. For example, it says that pi^2 is 208071/21082. That's only an approximation, not an exact result.

PDQ is the algorithm used by the second (and sometimes third) press. Its accuracy is controlled by the current display mode. For example, try Fixed 6 mode and see 0.000001 displayed as 1/500001 which seems absurd until you realize that reducing the display setting controls PDQ's accuracy. PDQ is only available via the [a b/c] key, but if you want to learn how it works and use it as a stand-alone program with user-settable accuracy, it is available HERE.

Disclaimer: Although HP incorporated my PDQ algorithm into the Prime's [a b/c] key, I do not work for HP. I'm just another happy HP calculator enthusiast.

In other words, the second press of [a b/c] in Home view is intended to give you the simplest fraction which falls in the interval of the displayed number plus or minus the accuracy of the current display mode. ("Simplest fraction" here means the ratio of two integers which are as small as possible.) It's important to know that both presses of [a b/c] return approximations, just using different algorithms which answer different questions.

[celltx]

Thank you, Joe. Very interesting.

When you implemented your PDQ function, why did you limit it by the display accuracy setting? Why not use the full internal accuracy all the time?

[Joe Horn]

(09-03-2020 07:01 PM)celltx Wrote:  Thank you, Joe. Very interesting.

When you implemented your PDQ function, why did you limit it by the display accuracy setting? Why not use the full internal accuracy all the time?

Please note that I did not implement PDQ into Prime. HP did that. I do not work for HP.

The purpose of PDQ is to answer questions like, "What is the simplest fraction which is equal to pi, plus or minus 1/1000?" If you press pi in Home, set the display mode to Fixed 3, and press [a b/c] twice, you'll see the answer: 201/64. QPI cannot answer this question, and if "full internal accuracy" were always used, PDQ couldn't answer it either.

PDQ always requires two inputs: The target number, and the desired accuracy tolerance. "Full internal accuracy" in Home mode means 12 significant digits, which for inputs between 1 and 10 means 11 digits after the decimal point, so that's the accuracy that PDQ assumes is intended by "Standard" Number Format (Home Settings). If you want further control of the accuracy, use other display modes (viz. Fixed, Scientific, Engineering, Floating, or Rounded), each of which handles the "decimal places to display" setting differently.

If you REALLY want to push PDQ to its limit, you have two options:

(1) Type HDigits:=12 in CAS. Since the valid range for HDigits is 0 through 11, that command should cause an error, but due to a long-standing bug, it actually does set HDigits to 12, which in turn causes PDQ to use 12 as its second argument (except in Standard display mode, which always uses 11 no matter what HDigits is set to). Don't tell HP... they might remove that bug, which would be a shame.

(2) Use the PDQ program which gives you complete control over both arguments.

[celltx]

Wow! I see there is a lot of thought behind that simple button press. Actually, it all started from the point that I wanted to find a simple way to figure out the number of leading zeroes in small number s. Like, if I have 0.000002, I'd like to count the number of leading zeroes in a quick way. But not resorting to the global scientific notation for that.

Initially, I thought the [a b/c] button could be somewhat helpful, but it seems to have a completely different function.

Thank you for the explanation, Joe!

[Albert Chan]

(09-03-2020 06:21 PM)Joe Horn Wrote:  PDQ is the algorithm used by the second (and sometimes third) press. Its accuracy is controlled by the current display mode. For example, try Fixed 6 mode and see 0.000001 displayed as 1/500001 ...

What happens if mode is FIX 5 ?

For x = 1/10^6, PDQ'd fraction numerator cannot be more than 1

1/den - x < eps       → den > 1/(x + eps)

lua> x = 1/10^6
lua> function min_den(eps) return floor(1/(x + eps)) + 1 end
lua> min_den(1e-7), min_den(1e-6), min_den(1e-5)

909091       500001       90910

Although 1/90910 - x < 1e-5, we also have x - 0 < 1e-5

Does it meant PDQ'd 1e-6, FIX 5, should return the "simpler" 0/1 instead ?

[Joe Horn]

(09-03-2020 08:30 PM)Albert Chan Wrote:  What happens if mode is FIX 5 ?
...
Does it meant PDQ'd 1e-6, FIX 5, should return the "simpler" 0/1 instead ?

Yes. PDQ(1E-6,1E-5) asks the question "What is the simplest fraction in the interval [-9E-6, 1.1E-5]?" The simplest fraction of ANY interval that includes 0 is 0/1. This is similar to PDQ(5.1, 0.2) which asks "What is the simplest fraction between 4.9 and 5.3 inclusive?" ... to which the answer is obviously 5/1.

[ijabbott]

(09-03-2020 08:13 PM)celltx Wrote:  Wow! I see there is a lot of thought behind that simple button press. Actually, it all started from the point that I wanted to find a simple way to figure out the number of leading zeroes in small number s. Like, if I have 0.000002, I'd like to count the number of leading zeroes in a quick way. But not resorting to the global scientific notation for that.

Initially, I thought the [a b/c] button could be somewhat helpful, but it seems to have a completely different function.

Thank you for the explanation, Joe!

You could use the LOG function for the number of leading zeros:
-IP(LOG(0.000002)) = 5

It doesn't work for numbers such as 0.1, 0.01, 0.001, but those would have a fractional part after the LOG() function that could be tested for.

[Albert Chan]

(09-04-2020 07:48 AM)ijabbott Wrote:  You could use the LOG function for the number of leading zeros:
-IP(LOG(0.000002)) = 5

It doesn't work for numbers such as 0.1, 0.01, 0.001, but those would have a fractional part after the LOG() function that could be tested for.

It also doesn't work for (0.1, 0.01, 0.001, ...) + 1 ULP

log10(1+ε) = ln(1+ε) / ln(10) ≈ ε / 2.3026 ≈ 0.4343 ε

For k ≥ 1, log10(x = (1+ULP)/10^k) ≈ 0.4343 ULP - k, which rounded back down to -k
However, x has k-1 leading zeroes, after decimal point.

The problem grow worse when k is big. Example, with 12-digits precision, k=11:

log10((1 + 11 ULP)/10^11) = log10(1.00000000011e-11) ≈ 0.4343*11e-11 - 11 = -11 (rounded-down)

---

Instead of scientific notation (or engineering notation), I like normalized notation.
0.1 ≤ mantissa < 1, see IEEE Standard for Floating Point Numbers, by V Rajaraman, page 12.

1.00000000011e-11 = 0.100000000011e-10 → 10 leading zeroes, after decimal point
1234500000 = 0.12345e+10                        → 10 digits number, before decimal point

[celltx]

Another nice option would be scientific, engineering, and other quick format conversions on the soft keys. Anyway, they are grossly under-utilized in the Home screen.

[Joe Horn]

Instead of using LOG to determine the number of zeros after the decimal point, how about using the XPON function? It seems to handle the boundary cases neatly.

-XPON(.00001)+1 --> 4
-XPON(9.99999999999E-5)+1 --> 4