Let's vote for suggestions and bugs

[toml_12953]

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?

[salvomic]

(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
it would be nice to have both the present Help System and an html also, why not?

Salvo

[pier4r]

Is this still actual? It is a really nice idea and setup.

[drake200120xx]

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

(PS-Calculator in Radians and running latest firmware)

[eried]

(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

-Drake

(PS-Calculator in Radians and running latest firmware)

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

[ammonteir]

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.

[Arno K]

You should use inv(Matrix),, that does not round and gives correct results, ^(-1) uses, when I remember correctly, another algorithm.
Arno

[ammonteir]

(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.

[CyberAngel]

(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

[grsbanks]

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;

[CyberAngel]

(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

[grsbanks]

(09-19-2018 05:38 PM)CyberAngel Wrote:  I'm generally against the idea anyway. sorry...

Well, you don't have to use it

If it was available I definitely would use it.

[CyberAngel]

(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

If it was available I definitely would use it.

You mean: let the user choose!

[Joe Horn]

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

[CyberAngel]

(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

[grsbanks]

(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

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

[Joe Horn]

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

[sasa]

(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?

[CyberAngel]

(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...

[Joe Horn]

(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.