Let's vote for suggestions and bugs

12282017, 12:34 PM
Post: #41




RE: Let's vote for suggestions and bugs
The DM42 has a great way of implementing the help file. It's a standard html file that is updated independently of the firmware. This way changes can be made as problems in the help file are found, clarifications can be added or the user can replace the help file with one of his/her own for custom applications. Would it be possible to give the Prime the same facility?
Tom L Cui bono? 

12282017, 01:23 PM
Post: #42




RE: Let's vote for suggestions and bugs
(12282017 12:34 PM)toml_12953 Wrote: The DM42 has a great way of implementing the help file. It's a standard html file that is updated independently of the firmware. This way changes can be made as problems in the help file are found, clarifications can be added or the user can replace the help file with one of his/her own for custom applications. Would it be possible to give the Prime the same facility? we need another App in the Prime: a browser it would be nice to have both the present Help System and an html also, why not? Salvo ∫aL√0mic (IT9CLU) :: HP Prime 50g 41CX 71b 42s 39s 35s 12C 15C  DM42, DM41X  WP34s Prime Soft. Lib 

06162018, 07:41 AM
Post: #43




RE: Let's vote for suggestions and bugs
Is this still actual? It is a really nice idea and setup.
Wikis are great, Contribute :) 

08292018, 10:38 PM
Post: #44




RE: Let's vote for suggestions and bugs
When trying to use the simplify function in the CAS workspace for "COS(x)/SIN(x)*COT(x)". This should, of course, return COT(x)^2, but instead returned something enormous. For example, part of the numerator of the returned fraction "16*COS(RE(x))^4*(e^(IM(x)))^4+16*COS(RE(x))^2..." Does someone know why this happened? Is there a way to fix this or get around it?
Thanks to everyone who helps me out with my new HP Prime Drake (PSCalculator in Radians and running latest firmware) 

08312018, 01:33 PM
Post: #45




RE: Let's vote for suggestions and bugs
(08292018 10:38 PM)drake200120xx Wrote: When trying to use the simplify function in the CAS workspace for "COS(x)/SIN(x)*COT(x)". This should, of course, return COT(x)^2, but instead returned something enormous. For example, part of the numerator of the returned fraction "16*COS(RE(x))^4*(e^(IM(x)))^4+16*COS(RE(x))^2..." Does someone know why this happened? Is there a way to fix this or get around it? You need to ask that in the main section of the forum this topic is just stuff related with the first post My website: erwin.ried.cl 

09182018, 10:15 PM
Post: #46




RE: Let's vote for suggestions and bugs
I usually use the HOME view instead of CAS view because of the RPN. But I found a wrong answer in the HOME view for a 2x2 inverse matrix and couldn't figure out why, maybe it's a bug. The matrix is:
270510 510 510 2710 inverse matrix at HOME: (That's a wrong answer) 3.69803308307E6 0 0 3.69134660258E4 inverse matrix at CAS: (That's a correct answer) 3,69803308307E6 6.95939805301E7 6.95939805301E7 3.69134660258E4 This difference lead me to a wrong answer in a Electric Circuit analysis. 

09192018, 02:24 PM
Post: #47




RE: Let's vote for suggestions and bugs
You should use inv(Matrix),, that does not round and gives correct results, ^(1) uses, when I remember correctly, another algorithm.
Arno 

09192018, 04:21 PM
Post: #48




RE: Let's vote for suggestions and bugs
(09192018 02:24 PM)Arno K Wrote: You should use inv(Matrix),, that does not round and gives correct results, ^(1) uses, when I remember correctly, another algorithm. Hi Arno, thanks for the answer. I agree with you about the inv(Matrix) algorithm. But does not have the same behavior as HP48, HP50 and HP Prime in CAS view... When resolving a linear system based on matrixes you can divide a Matrix A by a Matrix B and expect that the calculator internally calculates the inverse Matrix B and multiply it by Matrix A... You can do that in HP48, HP50 and even in Prime CAS, but not always in Prime HOME (You can do that but the answer is not reliable). As a matter of fact, I divided one matrix by another in my commented analysis, never made that step of inverse matrix, so, I can't even see that the algorithm is rounding some results before doing the last operation. When I was trying to understand where was the error, I found it to be in the inverse matrix result, only in HOME view. My point is, I expect the same behavior from one calculator to another and between HOME and CAS of HP Prime. 

09192018, 04:29 PM
Post: #49




RE: Let's vote for suggestions and bugs
(09182018 10:15 PM)ammonteir Wrote: I usually use the HOME view instead of CAS view because of the RPN. But I found a wrong answer in the HOME view for a 2x2 inverse matrix and couldn't figure out why, maybe it's a bug. The matrix is: The correct exact answer using CAS inv is  271 17    73282200 24427400  17 9017    24427400 24427400 VPN 

09192018, 05:28 PM
(This post was last modified: 09192018 05:30 PM by grsbanks.)
Post: #50




RE: Let's vote for suggestions and bugs
I'd really like to see post/preincrementation and decrementation in HPPPL (as in many other languages). It makes for more concise code and I bet it would run faster too.
So, instead of something like this: Code: variable := variable + 1; You'd have: Code: variable++; This makes a lot of sense in loops as well. For example: Code: EXPORT whatever() would become: Code: EXPORT whatever() 

09192018, 05:38 PM
Post: #51




RE: Let's vote for suggestions and bugs
(09192018 05:28 PM)grsbanks Wrote: I'd really like to see post/preincrementation and decrementation in HPPPL (as in many other languages). It makes for more concise code and I bet it would run faster too. Disagree Just learn the new language There are far more important issues to deal with AND I'm generally against the idea anyway. sorry... besides you have the FOR loop for that already 

09192018, 06:26 PM
Post: #52




RE: Let's vote for suggestions and bugs  
09192018, 07:00 PM
Post: #53




RE: Let's vote for suggestions and bugs  
09202018, 11:30 PM
Post: #54




RE: Let's vote for suggestions and bugs
grsbanks asks for HP PPL to support "x++" and "x" notation. It already does, but it only works in CAS programs, as can be seen in my "dec" program here: http://www.hpmuseum.org/forum/thread3571.html
<0ɸ0> Joe 

09202018, 11:47 PM
Post: #55




RE: Let's vote for suggestions and bugs
(09202018 11:30 PM)Joe Horn Wrote: grsbanks asks for HP PPL to support "x++" and "x" notation. It already does, but it only works in CAS programs, as can be seen in my "dec" program here: http://www.hpmuseum.org/forum/thread3571.html What in the world?! Example in CAS: dec(pi) > "3.1415926535897824578569270670413970947265625" not correct VPN PS: you should all learn all the digits of pi 

09212018, 09:52 AM
Post: #56




RE: Let's vote for suggestions and bugs
(09202018 11:30 PM)Joe Horn Wrote: grsbanks asks for HP PPL to support "x++" and "x" notation. It already does, but it only works in CAS programs, as can be seen in my "dec" program here: http://www.hpmuseum.org/forum/thread3571.html Thanks Joe I hardly ever do anything with CAS. Maybe I should investigate further... I like the presence of the {operator}= style as well (e.g. x *= 3; as a shorthand for x = x * 3;, for those who don't know the notation). 

09222018, 04:12 AM
Post: #57




RE: Let's vote for suggestions and bugs
(09202018 11:47 PM)CyberAngel Wrote:(09202018 11:30 PM)Joe Horn Wrote: grsbanks asks for HP PPL to support "x++" and "x" notation. It already does, but it only works in CAS programs, as can be seen in my "dec" program here: http://www.hpmuseum.org/forum/thread3571.html No, it's EXACTLY correct, all 44 glorious digits. The decimal number you showed above is EXACTLY what Prime's finitestate approximation of pi in CAS is equal to. That's what the 'dec' program's purpose is, to reveal the exact INTERNAL value of a floatingpoint number in Prime's CAS (as explained in the posting linked above). <0ɸ0> Joe 

09222018, 10:05 AM
(This post was last modified: 09222018 10:11 AM by sasa.)
Post: #58




RE: Let's vote for suggestions and bugs
(09222018 04:12 AM)Joe Horn Wrote: No, it's EXACTLY correct, all 44 glorious digits. The decimal number you showed above is EXACTLY what Prime's finitestate approximation of pi in CAS is equal to. Indeed, there is something wrong here. The 44 digits of PI are: 3.1415926535897932384626433832795028841971693 3.1415926535897824578569270670413970947265625 ? The last quoted result is acceptable only for 48bits of mantissa... Perhaps the 'dec' program mix CAS and HOME specific functions? 

09222018, 10:10 AM
Post: #59




RE: Let's vote for suggestions and bugs
(09222018 04:12 AM)Joe Horn Wrote:(09202018 11:47 PM)CyberAngel Wrote: What in the world?! In that sense, yes, but I was referring to the pi itself. And the digits. Approximation... rounded to 14 digits it's correct. Okay. The digits after the 897 are incorrect pi decimals Every Real Nerd™ shouly immediately spot it. Approximation... yes, indeed... 

09232018, 01:24 AM
Post: #60




RE: Let's vote for suggestions and bugs
(09222018 10:05 AM)sasa Wrote:(09222018 04:12 AM)Joe Horn Wrote: No, it's EXACTLY correct, all 44 glorious digits. The decimal number you showed above is EXACTLY what Prime's finitestate approximation of pi in CAS is equal to. 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"). No, it has nothing to do with mixing CAS and Home. It's purely CAS. <0ɸ0> Joe 

« Next Oldest  Next Newest »

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