- HP Community
- >
- Tablets
- >
- Calculators
- >
- HP Prime logb() bug in RPN calc mode, requiring entry of log...

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Flag Post

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

12-06-2018 07:28 PM

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?

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Flag Post

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

12-06-2018 07:51 PM - edited 12-06-2018 07:52 PM

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

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.

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Flag Post

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

12-06-2018 08:11 PM

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.

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Flag Post

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

12-07-2018 08:50 AM

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.

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Flag Post

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

12-07-2018 04:21 PM

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.

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Flag Post

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

12-07-2018 06:14 PM

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

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.

PD : The experience is a comb that you are given, when you have become bald.

- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Flag Post

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

12-07-2018 07:21 PM

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