Let's vote for suggestions and bugs

09232018, 01:33 AM
Post: #61




RE: Let's vote for suggestions and bugs
(09222018 10:10 AM)CyberAngel Wrote: Approximation... rounded to 14 digits it's correct. Yes. Or, more precisely, a binary floatingpoint 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? <0ɸ0> Joe 

09232018, 02:29 AM
Post: #62




RE: Let's vote for suggestions and bugs
(09232018 01:33 AM)Joe Horn Wrote:Yes, I can.(09222018 10:10 AM)CyberAngel Wrote: Approximation... rounded to 14 digits it's correct. 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 

09232018, 05:39 AM
(This post was last modified: 09232018 08:24 AM by sasa.)
Post: #63




RE: Let's vote for suggestions and bugs
(09232018 01:24 AM)Joe Horn Wrote: As its documentation states, the 'dec' program returns the exact DECIMAL equivalent of 48bit CAS reals. So, yes, dec(pi) returns a number which is the closest 48bit 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 48bit mantissa obviously made a confusion... If mantissa is limited to 48bits, 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 48bits mantissa. Simply based on fact: Num. of sign. dig. = [bits of mantissa] * log10(2) In case of 48bits mantissa, that is approx. 14.4 digits. 

09232018, 09:20 AM
Post: #64




RE: Let's vote for suggestions and bugs
(09232018 05:39 AM)sasa Wrote:Emphasis mine.(09232018 01:24 AM)Joe Horn Wrote: As its documentation states, the 'dec' program returns the exact DECIMAL equivalent of 48bit CAS reals. So, yes, dec(pi) returns a number which is the closest 48bit 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"). 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 

09232018, 12:44 PM
Post: #65




RE: Let's vote for suggestions and bugs
(09232018 05:39 AM)sasa Wrote: The claim that program shows 44 exact digits of PI with only available 48bit 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 floatingpoint 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 floatingpoint approximation of pi. Perhaps there is a language barrier here? (09232018 09:20 AM)CyberAngel Wrote: Joe insists that all the dec digits represents the pi approximation exactly. Correct. That is precisely what it does. (09232018 09:20 AM)CyberAngel Wrote: The problem is that that after those 14.4 digits the number is wrong. "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. <0ɸ0> Joe 

09232018, 12:59 PM
(This post was last modified: 09232018 12:59 PM by pier4r.)
Post: #66




RE: Let's vote for suggestions and bugs
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 . Wikis are great, Contribute :) 

09232018, 01:17 PM
(This post was last modified: 09232018 01:20 PM by Albert Chan.)
Post: #67




RE: Let's vote for suggestions and bugs
(09232018 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 

09232018, 01:45 PM
Post: #68




RE: Let's vote for suggestions and bugs
(09232018 01:17 PM)Albert Chan Wrote:Great!(09232018 09:20 AM)CyberAngel Wrote: Joe insists that all the dec digits represents the pi approximation exactly. but... the decimal is still "overaccurate", not rounded to 14.4 decimals. 

09232018, 02:53 PM
Post: #69




RE: Let's vote for suggestions and bugs
(09232018 01:45 PM)CyberAngel Wrote: Great! 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 48bits 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 48bits float = 0x0.c90fdaa22168P+2 However, rounded 48bits is much better, float = 0x0.c90fdaa22169P+2 (more than Pi times closer to Pi) 

09232018, 04:05 PM
(This post was last modified: 09232018 04:23 PM by sasa.)
Post: #70




RE: Let's vote for suggestions and bugs
(09232018 01:17 PM)Albert Chan Wrote:(09232018 09:20 AM)CyberAngel Wrote: Joe insists that all the dec digits represents the pi approximation 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 48bits 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. 

09232018, 06:33 PM
(This post was last modified: 09232018 09:35 PM by Albert Chan.)
Post: #71




RE: Let's vote for suggestions and bugs
(09232018 04:05 PM)sasa Wrote: displaying "3.1415926535897824578569270670413970947265625" for 48bits mantissa float is dec() is designed to show exact conversion, http://www.hpmuseum.org/forum/thread3571.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 roundup value (because CAS drop last 5 bits) For above case, shortest decimals = 3.14159265358979 = original CAS float 

09242018, 04:58 AM
Post: #72




RE: Let's vote for suggestions and bugs
I suggest we stop here and perhaps continue in upper thread, where this discussion belongs. All valid points are already wrote.


09242018, 02:48 PM
Post: #73




RE: Let's vote for suggestions and bugs
"Let's vote for suggestions and bugs"
I vote for suggestions but not bugs. Tom L Cui bono? 

09242018, 07:34 PM
Post: #74




RE: Let's vote for suggestions and bugs
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.30207608396E5 4.41618428486E3 But in Prime (HOME View) you get a wrong answer: 7.13720385033E5 4.4296159231E3 The answer is even worse if you decide to use the Linear Equation Solver app:  0 4.41618428485E3 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... 

11012018, 04:47 PM
Post: #75




RE: Let's vote for suggestions and bugs
Hi.
There is a suggestion for a "UNDO command" in HP Prime, but when will we have a firmware update with it ? 

11022018, 05:48 AM
Post: #76




RE: Let's vote for suggestions and bugs
20181016 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. 

11032018, 12:00 AM
(This post was last modified: 11082018 04:31 AM by compsystems.)
Post: #77




RE: Let's vote for suggestions and bugs
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 

11232018, 12:55 AM
Post: #78




RE: Let's vote for suggestions and bugs  
12092018, 04:06 PM
(This post was last modified: 12092018 04:55 PM by compsystems.)
Post: #79




RE: Let's vote for suggestions and bugs
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 

12142018, 02:11 AM
Post: #80




RE: Let's vote for suggestions and bugs
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 

« Next Oldest  Next Newest »

User(s) browsing this thread: 2 Guest(s)