Let's vote for suggestions and bugs

[Joe Horn]

(09-22-2018 10:10 AM)CyberAngel Wrote:  Approximation... rounded to 14 digits it's correct.

Yes. Or, more precisely, a binary floating-point approximation of pi truncated to 48 bits (which is what reals in CAS are limited to), it's the closest CAS can get to pi, and the 'dec' program reveals exactly what that approximation is equal to.

If you understand the above, you can answer both of these questions:
(1) Why doesn't dec(0.1) return a "clean" decimal result?
(2) Why DOES dec(0.5) return a "clean" decimal result?

[CyberAngel]

(09-23-2018 01:33 AM)Joe Horn Wrote:  

(09-22-2018 10:10 AM)CyberAngel Wrote:  Approximation... rounded to 14 digits it's correct.

Yes. Or, more precisely, a binary floating-point approximation of pi truncated to 48 bits (which is what reals in CAS are limited to), it's the closest CAS can get to pi, and the 'dec' program reveals exactly what that approximation is equal to.

If you understand the above, you can answer both of these questions:
(1) Why doesn't dec(0.1) return a "clean" decimal result?
(2) Why DOES dec(0.5) return a "clean" decimal result?

Yes, I can.
As a nerd I count easily for in
10 ways :
binary and decimal
Division and anything after the binary point
is slightly more difficult,
but repeated subtraction
and memorized previous conversions help.
2^¯¹ or .1 is easy (2)
but (1) requires quite a lot binimals...
I'd rather give you 0.01 or 5²/10²

I wonder if people will follow this easily
since I left out dec and bin tags

[sasa]

(09-23-2018 01:24 AM)Joe Horn Wrote:  As its documentation states, the 'dec' program returns the exact DECIMAL equivalent of 48-bit CAS reals. So, yes, dec(pi) returns a number which is the closest 48-bit approximation less than pi. But that's precisely its stated purpose. There only other way to see exactly what you have is to use the CAS command 'format' to see the number in hex, like this: format(pi,"a12").

The claim that program shows 44 exact digits of PI with only available 48-bit mantissa obviously made a confusion...

If mantissa is limited to 48-bits, it is rather correct to show no more than 15 digits, i.e. 14 significant digits +1, where last extra digit can indicate to user how to correctly round it with desired decimal places. Or more precisely, to automatically correctly round it itself to 14 digits, since other digits are out of interest for exact decimal representation of the number stored with in binary representation limited to 48-bits mantissa.

Simply based on fact: Num. of sign. dig. = [bits of mantissa] * log10(2)
In case of 48-bits mantissa, that is approx. 14.4 digits.

[CyberAngel]

(09-23-2018 05:39 AM)sasa Wrote:  

(09-23-2018 01:24 AM)Joe Horn Wrote:  As its documentation states, the 'dec' program returns the exact DECIMAL equivalent of 48-bit CAS reals. So, yes, dec(pi) returns a number which is the closest 48-bit approximation less than pi. But that's precisely its stated purpose. There only other way to see exactly what you have is to use the CAS command 'format' to see the number in hex, like this: format(pi,"a12").

The claim that program shows 44 exact digits of PI with only available 48-bit mantissa obviously made a confusion...

If mantissa is limited to 48-bits, it is rather correct to show no more than 15 digits, i.e. 14 significant digits +1, where last extra digit can indicate to user how to correctly round it with desired decimal places. Or more precisely, to automatically correctly round it itself to 14 digits, since other digits are out of interest for exact decimal representation of the number stored with in binary representation limited to 48-bits mantissa.

Simply based on fact: Num. of sign. dig. = [bits of mantissa] * log10(2)
In case of 48-bits mantissa, that is approx. 14.4 digits.

Emphasis mine.
Joe insists that all the dec digits represents the pi approximation exactly.
The problem is that that after those 14.4 digits the number is wrong.
No reason whatsoever for 50 digits yet along 1000 digits.
(The algorithm works, though - but it's misused)
<sigh>
VPN

[Joe Horn]

(09-23-2018 05:39 AM)sasa Wrote:  The claim that program shows 44 exact digits of PI with only available 48-bit mantissa obviously made a confusion...

But no such claim is made. The claim is that the 'dec' program always shows ALL the digits (no matter how many there are) of ANY CAS floating-point value. And that's what it does. It neither claims nor attempts to show 44 digits of the actual mathematical constant of pi, which is DIFFERENT from the CAS floating-point approximation of pi. Perhaps there is a language barrier here?

(09-23-2018 09:20 AM)CyberAngel Wrote:  Joe insists that all the dec digits represents the pi approximation exactly.

Correct. That is precisely what it does.

(09-23-2018 09:20 AM)CyberAngel Wrote:  The problem is that that after those 14.4 digits the number is wrong.
No reason whatsoever for 50 digits yet along 1000 digits.

"Wrong" because it differs from the mathematical constant of pi? THAT'S NOT ITS PURPOSE. I'll try one more time to explain this before giving up in frustration. When you type approx(pi) in Home, you get 3.14159265359, and that's EXACTLY the value that's sitting in Ans at that time. Those digits, and no more. But when you type approx(pi) in CAS, it *shows* 3.14159265359 as the result, but that is NOT the value in Ans. The ACTUAL value can be seen by typing format(pi,"a12"), which yields "0x1.921fb54442d0p+1" which is the EXACT hex representation of CAS's approximation of pi. What is the EXACT DECIMAL representation of "0x1.921fb54442d0p+1"? THAT is what dec(pi) returns. EVERY DIGIT in its output is significant and correct, so I don't know why you say that there is no reason to show the digits which differ from the decimal expansion of pi. Showing THOSE digits is the PURPOSE of the 'dec' program.

I hope that's clear. If not, I know no way of explaining it more clearly.

[pier4r]

Joe it is clear and was clear even before.
There are people more vocal than others, that's it.

Oh and thanks for the information .

[Albert Chan]

(09-23-2018 09:20 AM)CyberAngel Wrote:  Joe insists that all the dec digits represents the pi approximation exactly.

To be precise, replace "Pi approximation" to "best double precision value of Pi, truncated to 48 bits mantissa"

Best double precision value of Pi = 0x0.c90fdaa22168c0P+2
Truncated 48 bits mantissa, float = 0x0.c90fdaa22168P+2
Convert to decimal, you get "3.1415926535897824578569270670413970947265625" ... Exactly

[CyberAngel]

(09-23-2018 01:17 PM)Albert Chan Wrote:  

(09-23-2018 09:20 AM)CyberAngel Wrote:  Joe insists that all the dec digits represents the pi approximation exactly.

To be precise, replace "Pi approximation" to "best double precision value of Pi, truncated to 48 bits mantissa"

Best double precision value of Pi = 0x0.c90fdaa22168c0P+2
Truncated 48 bits mantissa, float = 0x0.c90fdaa22168P+2
Convert to decimal, you get "3.1415926535897824578569270670413970947265625" ... Exactly

Great!
but... the decimal is still "over-accurate", not rounded to 14.4 decimals.

[Albert Chan]

(09-23-2018 01:45 PM)CyberAngel Wrote:  Great!
but... the decimal is still "over-accurate", not rounded to 14.4 decimals.

I am sure calculator can do roundings for you ...
Probably not 14.4 decimals, but 14 should be no problem

FYI, you don't really get back 48-bits precision (~ 14.4 decimals).
The last bit may be totally off, if chopped 5 bits are all ones.
In other words, last bit carry little information about precision.

Using Pi as example, truncated 48-bits float = 0x0.c90fdaa22168P+2
However, rounded 48-bits is much better, float = 0x0.c90fdaa22169P+2 (more than Pi times closer to Pi)

[sasa]

(09-23-2018 01:17 PM)Albert Chan Wrote:  

(09-23-2018 09:20 AM)CyberAngel Wrote:  Joe insists that all the dec digits represents the pi approximation exactly.

To be precise, replace "Pi approximation" to "best double precision value of Pi, truncated to 48 bits mantissa"

Best double precision value of Pi = 0x0.c90fdaa22168c0P+2
Truncated 48 bits mantissa, float = 0x0.c90fdaa22168P+2
Convert to decimal, you get "3.1415926535897824578569270670413970947265625" ... Exactly

I believe we all understand each other perfectly. Actually, you will see similar with every programming language displaying any float with format which overestimate its actual precision. Usually, basic display format is regarding its precision. In that case displaying "3.1415926535897824578569270670413970947265625" for 48-bits mantissa float is overestimate, inaccurate, impractical and confusing for people expecting correctly rounded value.

After I have looked at Joe's function, I have noticed it is used basic algorithm without any rounding mechanism and formatting regarding current CAS settings, or user parameters. Perhaps few more tweaks are needed only in order to make it more flexible.

[Albert Chan]

(09-23-2018 04:05 PM)sasa Wrote:  displaying "3.1415926535897824578569270670413970947265625" for 48-bits mantissa float is
overestimate, inaccurate, impractical and confusing for people expecting correctly rounded value.

dec() is designed to show exact conversion, http://www.hpmuseum.org/forum/thread-3571.html

Why call dec() to get exact conversion, and then complain about it, for doing exact conversion ?
When using dec(), user should expect exact result, not rounded value.

BTW, a correctly rounded value meant round-up value (because CAS drop last 5 bits)
For above case, shortest decimals = 3.14159265358979 = original CAS float

[sasa]

I suggest we stop here and perhaps continue in upper thread, where this discussion belongs. All valid points are already wrote.

[toml_12953]

"Let's vote for suggestions and bugs"

I vote for suggestions but not bugs.

[ammonteir]

I'm not a programmer and I just use basic to intermediate of Prime, but I'm still concerned about the previous problem that I posted before, as it is a quite simple operation and I expect to have reliable answers from the calculator. I will describe the same example but with a different perspective.

Matrix A and B are related to a 2x2 linear system to be solved.
A=
| -19.3|
| 12|

B=
|-270510 510|
|510 -2710|

In HP48, HP50 and Prime (CAS View) you can divide A/B (and the calculators understand this single operation as B^(-1) x A) or you can also do it as B^(-1) x A indeed.

The answer you get is the correct one:

| 6.30207608396E-5|
|-4.41618428486E-3|

But in Prime (HOME View) you get a wrong answer:

|7.13720385033E-5|
|-4.4296159231E-3|

The answer is even worse if you decide to use the Linear Equation Solver app:

| 0|
|-4.41618428485E-3|

The problem is due to the algorithm internally and weirdly rounding just part of B^(-1) to zero in the HOME view. I could use inv(B) but I think it is boring and time consuming compared to a simple division. And more important, I think the calculator should have the same behavior as of presenting accurate answers in both views.

My question is how much can I trust in HOME view and Linear Equation Solver App of HP Prime. I personally likes the HOME view because of the RPN system...

[Berg]

Hi.

There is a suggestion for a "UNDO command" in HP Prime, but when will we have a firmware update with it ?

[vaca]

2018-10-16 version .line_p() function still has problem.When each point definition has color parameter in 3D mode,the lines are often just black color.
When you use line_p and triangle_p simultaneously in 3D mode，the shielding effect is very poor.

[compsystems]

Hello, users and developer group of the famous hp prime calculator
Sorry for my technical english.

Bugs report

*1
V1(X,Y) := (X²/3 - Y²/5 = 1); [enter] returns (X,Y)->(((X^2/3)-(Y^2/5))==1) // error
(X,Y)->(((X^2/3)-(Y^2/5))=1) // ok
right(V1) [Enter] returns 0 // (0 synonymous of false), error because although (((X^2/3)-(Y^2/5))==1 is false, this should not be compared, it must be interpreted as equation (X,Y)->(((X^2/3)-(Y^2/5))=1)

I do not use x in lowercase because the internal user variable V1 requires it [SYMB KEY], I also want to perform analytical [CAS], graphical [PLOT KEY] and numeric analyzes [NUM KEY] using the same definition.

*2
The following list of operations of terms, for the case of e*x^0 this closing the simulator, I do not know if this also happens in the physical calculator

e^(2*π*i)*y, √(-4), e*x^0, e*x₁*x₂, a₂*b₂*c₂*x²,-4*pi


*3

[[0,0],[0,1],[1,0],[1,1]] [enter]
evalb(Ans) [enter] returns evalb(Ans) ?
[[false,false],
[false,true],
[true,false],
[true,true]] // ok

*4
[[0 OR 0],
[0 OR 1],
[1 OR 0],
[1 OR 1]]

[enter] returns

[[false],
[true],
[1],
[1]]

sometimes true others 1 ?

*5
[[0 AND 0],
[0 AND 1],
[1 AND 0],
[1 AND 1]]
[enter] returns
[[0],[0],[false],[true]]

Thank you

[mathnovice]

This seems to just make sense. If functions use lowercase x in CAS use lowercase x in F(X) app.

e.g x^2(sto)F1 returns syntax error in app because F(X) app wants uppercase X and default press of (xt(theta)n) in CAS returns lowercase letters

       

[compsystems]

Bug TYPE() cmd

TYPE(set[1,2,3]) ↵ 4
Then, the entry [up] [up] [copy] is replaced set[] by { } which is a different type of data
TYPE({1,2,2}) ↵ 6

[compsystems]

Index acts as a system variable and as a functional command,

For functional command:
Index() returns the first position of an object in a list, a string or a set, if it does not find the object returns an error message.

index(List/String/Set,Object)

LIST:
index:=0:; index([9,8,-1,8,9,8,7],8) [↵] returns 1 // ok
index:=1:; index([9,8,-1,8,9,8,7],8) [↵] returns 2 // ok

SET:
index:=0:; F_ := set[ H_,E_,L_,L_,O_];
F_ => set[ H_,E_,L_,O_]; // the multiplicity of L_ is eliminated // ok
index(F_,O_) [↵] returns 3 // ok
index(F_,L_) [↵] returns 2 // ok

STRING
index:=0:; index("abracadabrant","c") [↵] returns -1 (Bug)// GIAC => 4