(03-02-2019 05:22 PM)Dieter Wrote: [ -> ]I do not have a 12C Platinum or an emulator, so I cannot check this, but on a TI calculator with AOS I'd simply type
[÷] [x²] [√x] [=]
Does this also work on the 12CP ?
Dieter
But... if the input is zero, you get an error instead of zero output.
This doesn't work for \(\left | x \right |\leqslant 10^{-50}\) or \(\left | x \right | \geqslant 10^{50}\) due to under- or overflow.
Obviously it works for numbers like -113 or 47.
But what happens with a number that uses all the 10 digits like 12.78974364?
When we square this number we get 163.5775424 which is rounded to 10 digits.
The exact value is 163.5775423769204496.
Taking the square root of the rounded value 163.5775424, why can we be sure that we get the original number?
If we received something off by 1 in the last digit, such as 12.78974363 or 12.78974365, we'd end up with 1.000000001 or 0.999999999 instead.
Any thoughts why this can't happen?
The reverse isn't true as we know: taking the square root of 3 gives 1.732050808.
But the square of this number is rounded to 3.000000001.
The exact value is 3.000000001493452864.
I'm not sure if TI Calculator with AOS got the [LSTx] function.
Of course not. But that's not my question. The point is that on a TI you don't need all this. There is no need to use LstX or a dummy multiplication. I just want to know whether the proposed key sequence (without 1 x multipliation and without LstX) also works on the 12CP or not.
(03-03-2019 08:17 AM)Thomas Klemm Wrote: [ -> ]But what happens with a number that uses all the 10 digits like 12.78974364?
When we square this number we get 163.5775424 which is rounded to 10 digits ...
Taking the square root of the rounded value 163.5775424, why can we be sure that we get the original number?
If a number x had an uncertainty factor 1+ε, (x·(1+ε))² = x²·(1+2ε+ε²) ≈ x²·(1+2ε)
So, for squaring, uncertainly doubled (with at most ±½ ulp error).
Square root is just a reverse operation, uncertainly cut in half.
We would expect squaring, then square root, round-trip back to original number.
(03-03-2019 02:39 PM)Gamo Wrote: [ -> ]Program this in ALG mode for 12CP
[÷] [x²] [√x] [=]
123 [R/S] display 123 123 [CHS] [R/S] display 123
Above routine look like ABS function.
Gamo
No, the above program returns -1.00 on a 12CP, as Dieter suspected.
SICNR, I had to try my first algebriac mode program on a 12CP...
Interesting UPDATE:
On the initial 12CP (before the (), Undo and Backspace were added) the above program returns -1.00, but on later models (including the Android emulator) returns 123 as Gamo reported.
Clearly a bug, I need to explore past bug reports. Intuitively, the initial behavior is correct and the later is not, though it seems unlikely such a bug has never been noticed and fixed...
(03-03-2019 03:34 PM)rprosperi Wrote: [ -> ]On the initial 12CP (before the (), Undo and Backspace were added) the above program returns -1.00, but on later models (including the Android emulator) returns 123 as Gamo reported.
That's really weird. #-)
I wonder what happens in similar cases like
2 [+] [√x] [=]
or
5 [x] [LN] [x²] [=]
I'd expect 3,41 and 12,95 but obviously you never know...
(03-03-2019 05:51 PM)Dieter Wrote: [ -> ]I wonder what happens in similar cases like
2 [+] [√x] [=]
or
5 [x] [LN] [x²] [=]
I'd expect 3,41 and 12,95 but obviously you never know...
That’s what I get on my TI 57, but on my 12c Prestige (and on the latest Platinums, I presume), arguments on the display cannot be reused after an operator. Thus, in order to get what you want the following sequences should be used:
2 [+] 2 [√x] [=] -> 3.414213562
5 [x] 5 [LN] [x²] [=] -> 12.95145197
IMHO, this is a feature, not a bug. Although the old behavior is apparently more convenient in some situations, I prefer this new one (or at least I would if I chose ALG, which I never will).
(03-03-2019 04:59 PM)Thomas Klemm Wrote: [ -> ]There's no "uncertainty" when it comes to rounding numbers.
Though this may be related it doesn't explain what's going on.
Turns out, there is nothing to explain. I found a counter-example ...
My post on square, following by square-root round-trip is wrong
(03-03-2019 05:51 PM)Dieter Wrote: [ -> ]I wonder what happens in similar cases like
2 [+] [√x] [=]
or
5 [x] [LN] [x²] [=]
I'd expect 3,41 and 12,95 but obviously you never know...
Your expectations are correct, IMHO.
Original 12CP: 3,41 & 12,95
Later 12CP: 1,41 & 2,59
I've not researched yet, but Gerson's summary "...arguments on the display cannot be reused after an operator..." seems a concise summary of the 'fixed' or at least updated, behavior. Denying re-use of the original argument may have been necessary (or at least easier) as a result of adding the UNDO feature in the 2nd and all later series of 12CP models.
One could argue either way which is 'right', since algebraic notation is notoriously ambiguous, though I must admit that this is a more interesting than normal situation.
@Gerson - of course the RPN solution works; they're always unambiguous.
(03-03-2019 07:49 PM)Albert Chan Wrote: [ -> ]Example, on HP-12C, x = Pi + 0.04 = 3.181592654
If we just look at the mantissa it appears that this only happens for values between \(\sqrt{10} \approx 3.16228\) and \(5\).
And within this interval it happens at about 18.37% of the cases.
Which is close to \(\frac{5 - \sqrt{10}}{10} \approx 0.18377\).
Choosing a number at random leads to a wrong result in about 1 of 27 cases.
I don't think that we can neglect that.
Here's a table with some values \(x\) having only 5 digits after the decimal point and \(\sqrt{x^2}\) as it is calculated by the HP-12C:
(03-03-2019 11:27 PM)Thomas Klemm Wrote: [ -> ]If we just look at the mantissa it appears that this only happens for values between \(\sqrt{10} \approx 3.16228\) and \(5\).
This range can be explained by squaring errors: (x·(1+ε))² = x²·(1+2ε+ε²) ≈ x²·(1+2ε)
Assuming numbers in scientific notation, with mantissa = [1, 10), ulp = 1e-9
Max rel error of √(x²) ≈ ½ Max rel error of x² = ½ (½ ulp / mantissa(x²))
Max abs error of √(x²) ≈ ¼ ulp (mantissa(x) / mantissa(x²))
Round-trip errors occurs if √(x²) abs error ≥ ½ ulp
-> mantissa(x) between √10 and 5.0
-> Max abs error between 0.79 and 0.50 ulp
Edit: this also explained why (√x)² may have errors upto 3 ULP
Example: (√9.11)² = 9.110000003
Guass Sum (x² + x) ÷ 2
-------------------------------------
If program this way
[LSTx] [x²] + [LSTx] [÷] 2 [=]
Each [R/S] need to clear register to restart
Clear by pressing [CLx] [CLx]
100 [R/S] display 5050
If not clear 100 [R/S] display 12751300
---------------------------------------------
This routine no need to clear register but
Need the dummy (1 × X<>Y)