Highlighted
pschlie Top Student
Top Student
5 0 0
Message 1 of 7
219
Flag Post
HP Recommended

HP Prime logb() bug in RPN calc mode, requiring entry of logb(2) when # stack inputs not variable?

HP Prime
Other

As when in RPN calc mode, it's requiring the entry of logb(2) indicating the use of the top 2 stack arguments, although always requiring 2, no more, no less, as its not a variable input argument function.  It should simply use the two top stack arguments and return the answer on the stack in RPN mode; just like X^Y, not max(X, Y, ...).  I suspect other fixed number of argument functions may exhibit a similar bug in RPN mode, but haven't attempted to test them all?

 

 

6 REPLIES
PhD Student PhD Student
PhD Student
667 106 147
Message 2 of 7
204
Flag Post
HP Recommended

HP Prime logb() bug in RPN calc mode, requiring entry of logb(2) when # stack inputs not variable?

The issue is that logb is a CAS command and actually can take an essentially unlimeted number of inputs in different forms. The normal and expected use is 2 of course, but like any other command it can function with many more inputs. That is just part of the way the CAS is designed at a low level and we cannot really change that.

 

Besides, in RPN you just type 10 LN 2 LN / and get the same thing in less steps and time. :)

TW

Although I work for the HP calculator group as a head developer of the HP Prime, the views and opinions I post here are my own.
Reply
0 Kudos
pschlie Top Student
Top Student
5 0 0
Message 3 of 7
195
Flag Post
HP Recommended

HP Prime logb() bug in RPN calc mode, requiring entry of logb(2) when # stack inputs not variable?

However when operating in RPN calc mode, it appears to only accepts 2; and thereby having to specify such an arguent is unnessisaritly redundant.  (Yes one could compute an inexact result using the ratio of logarithems, but as one of the purposes of such a dedicated function is to make life easer, it corespondingly should not require an unnessisary redundancy for its use; in merely my opinion.)

 

(Maybe if the two modes of operation were more unfifed, I could see an argument; but as they're largely distinct, I don't.)

 

Thanks for your consideration & best regards.

 

Reply
0 Kudos
pschlie Top Student
Top Student
5 0 0
Message 4 of 7
163
Flag Post
HP Recommended

HP Prime logb() bug in RPN calc mode, requiring entry of logb(2) when # stack inputs not variable?

Upon further logb(X,Y), always requires 2 arguments,  computing ln(X)/ln(Y), with the first argment being optionally an explicitly specifed vector/list in any/every mode; thereby arguably a bug to require it's number of arguments to be specfied in RPN mode.

 

However, LOG(X[,Y]...) is a varable argment function, which either accepts:

- a single argment which may optinoally be an explict vector/list, computing logb(X,10), 

- two argments where the first may be an explict vector/list, computing logb(X,Y).

- three or more arguments, accepting an variable number of arguments as an implicit vector/list, computing logb(X,10).

As is log(X1[X2] ...), treating more than one argument as a vector/list, computing logb([X1...],e).

 

Best regards.

Reply
0 Kudos
pschlie Top Student
Top Student
5 0 0
Message 5 of 7
140
Flag Post
HP Recommended

HP Prime logb() bug in RPN calc mode, requiring entry of logb(2) when # stack inputs not variable?

In conclusion, If it helps understand why I cared, I tried redefining the logb(X,Y) function to the "LOG" key (as I find log with a flexible base to be more generally useful, as a natural complement to X^Y), and expected the top two stack locations to be used as its repective arguments, only to dicover it resulted in an argument error, which surprised me, as it always requires 2 arguments.

 

Reply
0 Kudos
Distinguished Professor
Distinguished Professor
3185 144 449
Message 6 of 7
126
Flag Post
HP Recommended

HP Prime logb() bug in RPN calc mode, requiring entry of logb(2) when # stack inputs not variable?

Hi!, Pschlie :

The argument in RPN CAS, of logb, is equal, this example, to ln(5)/ln(2), of page 482 from User Guide ... http://h10032.www1.hp.com/ctg/Manual/c05939731, of ... https://support.hp.com/us-en/product/hp-prime-graphing-calculator/5367459/manuals ...

Logb.JPG


You're Welcome !.
Best wishes and regards.
@Maké (Voluntary and "ad honorem").
Click the White thumb to say thanks.
Please, mark Accept As Solution if it solves your problem.
Reply
0 Kudos
pschlie Top Student
Top Student
5 0 0
Message 7 of 7
118
Flag Post
HP Recommended

HP Prime logb() bug in RPN calc mode, requiring entry of logb(2) when # stack inputs not variable?

All I'm seeking to accomplish, is to extend the HP Prime, to replace the LOG (i.e. logb( x, 10)) key functionality in RPM calc (i.e. home) mode, such that it behaves like the inverse of x^y, being xLy (i..e. logb(x, y)), where x is the 2nd stack argument, and Y is the top, as would be traditional for true RPN calculations.  Although I can accomplish this using algebraic templates, it's not my goal; as I personally find true RPN calculations more interactively useful, than text-book formatted equivalents.

 

Thanks again, all.   (But ideally I personally prefer x^y,  xLy, pi, e, and i to be primary keys, replacing all other exponential/logarithmic function keys, as these 2 functions and 3 constants can easily be used to specify any combination of them, symbolically and/or otherwise.)

 

Reply
0 Kudos
† The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation