Post Reply 
Let's vote for suggestions and bugs
12-28-2017, 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?
Find all posts by this user
Quote this message in a reply
12-28-2017, 01:23 PM
Post: #42
RE: Let's vote for suggestions and bugs
(12-28-2017 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 Smile
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
Visit this user's website Find all posts by this user
Quote this message in a reply
06-16-2018, 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 :)
Find all posts by this user
Quote this message in a reply
08-29-2018, 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 Smile

-Drake

(PS-Calculator in Radians and running latest firmware)
Find all posts by this user
Quote this message in a reply
08-31-2018, 01:33 PM
Post: #45
RE: Let's vote for suggestions and bugs
(08-29-2018 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?

Thanks to everyone who helps me out with my new HP Prime Smile

-Drake

(PS-Calculator in Radians and running latest firmware)

You need to ask that in the main section of the forum Smile this topic is just stuff related with the first post

My website: ried.cl
Visit this user's website Find all posts by this user
Quote this message in a reply
09-18-2018, 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.69803308307E-6 0|
|0 -3.69134660258E-4|

inverse matrix at CAS: (That's a correct answer)

|-3,69803308307E-6 -6.95939805301E-7|
|-6.95939805301E-7 -3.69134660258E-4|

This difference lead me to a wrong answer in a Electric Circuit analysis.
Find all posts by this user
Quote this message in a reply
09-19-2018, 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
Find all posts by this user
Quote this message in a reply
09-19-2018, 04:21 PM
Post: #48
RE: Let's vote for suggestions and bugs
(09-19-2018 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.
Arno

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.
Find all posts by this user
Quote this message in a reply
09-19-2018, 04:29 PM
Post: #49
RE: Let's vote for suggestions and bugs
(09-18-2018 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:

|-270510 510|
|510 -2710|

inverse matrix at HOME: (That's a wrong answer)

|-3.69803308307E-6 0|
|0 -3.69134660258E-4|

inverse matrix at CAS: (That's a correct answer)

|-3,69803308307E-6 -6.95939805301E-7|
|-6.95939805301E-7 -3.69134660258E-4|

This difference lead me to a wrong answer in a Electric Circuit analysis.

The correct exact answer using CAS inv is

| -271 -17 |
|------------- ------------|
|73282200 24427400|

| -17 -9017 |
|------------- ------------|
|24427400 24427400|

VPN
Find all posts by this user
Quote this message in a reply
09-19-2018, 05:28 PM (This post was last modified: 09-19-2018 05:30 PM by grsbanks.)
Post: #50
RE: Let's vote for suggestions and bugs
I'd really like to see post/pre-incrementation and decrementation in HP-PPL (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;

  -- or --

variable := variable - 1;

You'd have:

Code:
variable++;

  -- or --

variable--;

This makes a lot of sense in loops as well. For example:

Code:
EXPORT whatever()
BEGIN
  LOCAL n := 10;
  WHILE n > 1 DO
    n := n - 1;
    DoSomethingWith(n);
  END;
END;

would become:

Code:
EXPORT whatever()
BEGIN
  LOCAL n := 10;
  WHILE --n DO DoSomethingWith(n); END;
END;
Find all posts by this user
Quote this message in a reply
09-19-2018, 05:38 PM
Post: #51
RE: Let's vote for suggestions and bugs
(09-19-2018 05:28 PM)grsbanks Wrote:  I'd really like to see post/pre-incrementation and decrementation in HP-PPL (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;

  -- or --

variable := variable - 1;

You'd have:

Code:
variable++;

  -- or --

variable--;

This makes a lot of sense in loops as well. For example:

Code:
EXPORT whatever()
BEGIN
  LOCAL n := 10;
  WHILE n > 1 DO
    n := n - 1;
    DoSomethingWith(n);
  END;
END;

would become:

Code:
EXPORT whatever()
BEGIN
  LOCAL n := 10;
  WHILE --n DO DoSomethingWith(n); END;
END;

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
Find all posts by this user
Quote this message in a reply
09-19-2018, 06:26 PM
Post: #52
RE: Let's vote for suggestions and bugs
(09-19-2018 05:38 PM)CyberAngel Wrote:  I'm generally against the idea anyway. sorry...

Well, you don't have to use it Smile

If it was available I definitely would use it.
Find all posts by this user
Quote this message in a reply
09-19-2018, 07:00 PM
Post: #53
RE: Let's vote for suggestions and bugs
(09-19-2018 06:26 PM)grsbanks Wrote:  
(09-19-2018 05:38 PM)CyberAngel Wrote:  I'm generally against the idea anyway. sorry...

Well, you don't have to use it Smile

If it was available I definitely would use it.

You mean: let the user choose!
Find all posts by this user
Quote this message in a reply
09-20-2018, 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/thread-3571.html

<0|ɸ|0>
-Joe-
Visit this user's website Find all posts by this user
Quote this message in a reply
09-20-2018, 11:47 PM
Post: #55
RE: Let's vote for suggestions and bugs
(09-20-2018 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/thread-3571.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
Find all posts by this user
Quote this message in a reply
09-21-2018, 09:52 AM
Post: #56
RE: Let's vote for suggestions and bugs
(09-20-2018 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/thread-3571.html

Thanks Joe Smile

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).
Find all posts by this user
Quote this message in a reply
09-22-2018, 04:12 AM
Post: #57
RE: Let's vote for suggestions and bugs
(09-20-2018 11:47 PM)CyberAngel Wrote:  
(09-20-2018 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/thread-3571.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

No, it's EXACTLY correct, all 44 glorious digits. The decimal number you showed above is EXACTLY what Prime's finite-state 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 floating-point number in Prime's CAS (as explained in the posting linked above).

<0|ɸ|0>
-Joe-
Visit this user's website Find all posts by this user
Quote this message in a reply
09-22-2018, 10:05 AM (This post was last modified: 09-22-2018 10:11 AM by sasa.)
Post: #58
RE: Let's vote for suggestions and bugs
(09-22-2018 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 finite-state 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 48-bits of mantissa...
Perhaps the 'dec' program mix CAS and HOME specific functions?
Find all posts by this user
Quote this message in a reply
09-22-2018, 10:10 AM
Post: #59
RE: Let's vote for suggestions and bugs
(09-22-2018 04:12 AM)Joe Horn Wrote:  
(09-20-2018 11:47 PM)CyberAngel Wrote:  What in the world?!

Example in CAS: dec(pi) --> "3.1415926535897824578569270670413970947265625"

not correct
VPN
PS: you should all learn all the digits of pi

No, it's EXACTLY correct, all 44 glorious digits. The decimal number you showed above is EXACTLY what Prime's finite-state 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 floating-point number in Prime's CAS (as explained in the posting linked above).

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...
Find all posts by this user
Quote this message in a reply
09-23-2018, 01:24 AM
Post: #60
RE: Let's vote for suggestions and bugs
(09-22-2018 10:05 AM)sasa Wrote:  
(09-22-2018 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 finite-state 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 48-bits of mantissa...
Perhaps the 'dec' program mix CAS and HOME specific functions?

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").

No, it has nothing to do with mixing CAS and Home. It's purely CAS.

<0|ɸ|0>
-Joe-
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 




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