Does wp34S Have A "MANT" Function?
#1

Hi,

The other day I was searching for a MANTISSA function on the 34S and couldn't find one. I understand that if it had been a BCD machine, MANT would be fairly straightforward; and that it can always be computed with something like:

LBL A

LOG10

FP

x<0?

INC X

10^x

RTN

....but I just wondered if I had missed something while scanning through the manual.

Thanks, Jake

#2

Jake,

You're right: we don't feature a MANT function in the WP 34S so far. We'll talk about it in due course. Any specific application you want it for?

Walter

#3

Eh, you never quite know. Number manipulation tools are always good to have in the arsenal. SHOW exists which shows the mantissa, but depending on how much space it takes, a MANT function would be helpful to go along with IP and FP. Just provide the value without an exponent.

#4

Quote:
Any specific application you want it for?

I was actually looking into some multiple-precision arithmetic and how it was being done by users as published in old PPC Journals for the HP67 and HP41. Some required entering portions of the number, each with all digits to the right of the decimal point. In giving thought to how to implement a multiple-precision (or perhaps only a very-large-integer) arithmetic scheme this time around, I found myself envisioning a possible need to extract the mantissa of a number separate from its exponent. It was then that I realized that it would be trivial with a BCD math "engine" under the hood, but much less so otherwise.

Currently, I've been looking into possibly utilizing the fact that numbers may be passed back and forth between the floating-point and integer "worlds" on the 34S. Since 64-bit math is available with integers, that would at least permit integers at least 19 digits long, and with double-word math, perhaps as high as 38 digits. There is an ultimate goal in mind, but first a set of arithmetic (plus remainder) functions for large numbers would have to be in place.

Jake

#5

Your MANT implementations uses LOG and 10x so that roundoff errors may occur. I think this is a better implementation:

  LBL A
ENTER
LOG10
FLOOR
10^x
/
RTN
Works for the same domain (x>0) and requires no test since FLOOR returns the smallest integer less than or exqual to x, even for x<0.

If SDL and SDR would accept negative values there even was a much more elegant "true 34s style" method. ;-)

Anyway, I would like to second your suggestion of a MANT function. It can be implemented easily (simply clear the exponent), and of course we also need its counterpart EXP, which returns x / mant(X).

BTW - I still think the SHOW command needs an improvement. It simply does not work "as advertised": The manual says "Shows the full mantissa until the next key is pressed", but it doesn't. It only shows the first 12 digits of the mantissa, and even this display is rounded. Yes, I know there are only 12 digits in the display, but I am shure this forum's ingeniuity will find a way to overcome this limit. Maybe the display can be scrolled. But everything is better than a mantissa rounded to 12 digits.

Also, unlike all other HPs I know of, the command does not show trailing zeroes. In other words, things look like this:

Value in X     SHOW should display         SHOW actually displays
(IMHO)
3 3000000000000000 3,
Pi 3141592653589793 3,14159265359
2/3 6666666666666667 6,66666666667 E-1
At least the 12th digit should not get rounded.

Dieter

#6

Quote:
Your MANT implementations uses LOG and 10x so that roundoff errors may occur. I think this is a better implementation:
  LBL A
ENTER
LOG10
FLOOR
10^x
/
RTN

Yes, and with a small change it even works also for x<=0 and doesn't move the stack: :-)
LBL'EXP'
ABS
x[!=]0?
LOG[sub-1][sub-0]
FLOOR
RTN

LBL'MAN'
STO I
XEQ'EXP'
10[^x]
STO/ I
x[<->] I
RTN

Franz
#7

Quote:
BTW - I still think the SHOW command needs an improvement.

The latest SVN releases should have an improved SHOW. Just try it!
#8

You are using older firmware. SHOW shows all sixteen digits now.

Implementing a MANT function would be straightforward. What exactly should it do? Return x.xxxxxxxxx or xxxxxxxxx??

It is replacing five - seven program steps so it is unlikely to be a good space trade. Defining this as a built in functions will take something like sixty bytes for even a little more.


- Pauli

#9

I looked at http://sourceforge.net/projects/wp34s/files/ and found a zip-file dated 2011-08-03, i.e. the version I am using right now. All I got is the emulator. Which files have to be replaced and where do I find them?

If a MANT function is implemented it should return a value between 1 and 10. Regarding space: well, there are several functions whose main purpose is making programs more elegant, but not significantly shorter. For instance, SIGN can be replaced by ABS X<>0? RCL/L, so it saves just two steps. The vast number of tests could be halved by simply adding one dummy test instruction that always tests false, thus inverting any other test.

If space is an issue these valuable bytes could be used for something more useful. I've got this very conservative opinion that a calculator should provide results as precise as possible. Currently ln1+x and e^x-1 are useful instructions that really help doing so. But there are others. In another math package I recently found a function that returns sqrt(1+x)-1. I think that's a great idea.

Or think of the x-th root of y. Some time ago CUBERT was implemented. I really appreciate this because it avoids significant errors when using the workaround 1/x y^x. Try the cuberoot of 512 that way - should be trivial but you'll get 7,999...998 (which on the other hand is fine since it's the correct result for x^0,333...333). So, CUBERT is nice and was a step in the right direction. But why don't we have a universal XROOT command? This is a standard command on many other calculators, including HP's.

As I think about it, I am sure there are some more useful commands that can help to get more precise results. ;-)

Dieter

#10

Quote:
I looked at http://sourceforge.net/projects/wp34s/files/ and found a zip-file dated 2011-08-03, i.e. the version I am using right now. All I got is the emulator. Which files have to be replaced and where do I find them?

If you want to flash a 20b or 30b, you shall use calc.bin. If you are looking for the newest emulator, search for wp34sgui.exe. Watch out since the latest build(s) may contain severe bugs, while the zipped package collects more stable material.
Quote:
I've got this very conservative opinion that a calculator should provide results as precise as possible. Currently ln1+x and e^x-1 are useful instructions that really help doing so. But there are others. In another math package I recently found a function that returns sqrt(1+x)-1. I think that's a great idea.

I've got this very conservative opinion that a man shouldn't forget what he learned. Remember good old Taylor series? IMHO these are very well suited to this kind of "problems". For my generation, there were some important pages in Bronstein, Semendjajev ;-)
Quote:
But why don't we have a universal XROOT command? This is a standard command on many other calculators, including HP's.

IIRC there was never a reasonable HP RPN calculator containing XROOT, but "Wenn's der Wahrheitsfindung dient ..." :-/ Anyway, that statement is easy for me but more difficult for Pauli, so I leave the decision to him :-)

Walter

#11

Quote:
If you want to flash a 20b or 30b, you shall use calc.bin.

Yes, I know, but as I said before, I only have the emulator.
Quote:
If you are looking for the newest emulator, search for wp34sgui.exe. Watch out since the latest build(s) may contain severe bugs, while the zipped package collects more stable material.

So the last stable material is the version dated 2011-08-03. That's what I already got - without the improved MANT command. Is wp34sgui.exe really the only file that needs to be replaced to get the latest version of the emulator? In other words, does this file contain the complete firmware with the latest changes?
Quote:
I've got this very conservative opinion that a man shouldn't forget what he learned. Remember good old Taylor series?

I don't know the English term for "Totschlagargument", but if this is what you think about useful instructions that help getting better results, ln1+x and e^x-1 should get deleted immediately - these cases can be handled by simple series expansions as well.

BTW that's how I code them in VBA. It doesn't even take a Bronstein/Semendjajew for this - my good old Schülke from more than 30 years ago will do just as well. 8-)

Quote:
IIRC there was never a reasonable HP RPN calculator containing XROOT, ...

What? No reasonable calculator? Hard to believe. Anyway - in that case the 34s would be the first one.
Quote:
...but "Wenn's der Wahrheitsfindung dient ..." :-/

Yes, it does. It helps finding the mathematical truth. Example: try the 7th root of 4782969. Should be trivial since that's 9^7. But instead, requiring the [1/x] [y^x] workaround, the 34s returns 9,000000000000006. That's six (!) ULP off! #-\ The 35s returns the result with an error of -2 ULP. But here we can do better: the result returned by the XROOT command offered by this device of course is exactly 9. Great, isn't it?

Dieter

Edited: 20 Aug 2011, 8:58 a.m. after one or more responses were posted

#12

Quote:
Is wp34sgui.exe really the only file that needs to be replaced to get the latest version of the emulator? In other words, does this file contain the complete firmware with the latest changes?

Dieter, if you always want to be up-to-date, then bookmark this link:

http://wp34s.svn.sourceforge.net/viewvc/wp34s/

'Directory revision:' at the top shows you the latest version, and clicking on this number gives you a list of the changed files.

For the emulator you need wp34sgui.exe and emulator.dll (only when it has been changed).

Franz

#13

Quote:
Quote:
IIRC there was never a reasonable HP RPN calculator containing XROOT, ...

What? No reasonable calculator? Hard to believe. Anyway - in that case the 34s would be the first one.


The 50g sounds like a "reasonable" calculator to me...

Quote:
But here we can do better: the result returned by the XROOT command offered by this device of course is exactly 9. Great, isn't it?

Yes, it is. I'm convinced and thank you for the info. The next update of ND1 will have the XROOT function, though I don't yet know how to implement it.
I tried 4782969, enter, 1/7, enter, ^ in ND1 which displays as "9" but really is "8.999999999999999998" (two ULPs off).
An alternative interface to XROOT will be exponentiation with a fraction.

If you ever feel like "austoben" yourself with numerical accuracy improvements in a (leading) RPN app, please get in touch with me. I admire your mathematical mind and stance toward accuracy.

#14

Ah, thank you. I first got nothing but command window popping up and closing immediately. But it eventually worked after I replaced three files: wp34sgui.exe, wp34s.exe and emulator.dll

I see the "design team" chose the obvious way for the MANT display and used the three digits of the exponent. However, the sixteenth digit had to move to the alpha line. I wonder if this looked ..."cleaner" if the complete four last digits were displayed in that line.

Dieter

Edited: 20 Aug 2011, 9:43 a.m.

#15

Quote:
I'm convinced and thank you for the info. The next update of ND1 will have the XROOT function, though I don't yet know how to implement it. I tried 4782969, enter, 1/7, enter, ^ in ND1 which displays as "9" but really is "8.999999999999999998" (two ULPs off). An alternative interface to XROOT will be exponentiation with a fraction.

The advantage of the XROOT command is its higher precision due to the internal guard digits. Usually there are three digits more than you see, on the 34s it's even 39 digits internal precision while only 16 are returned to the user. This additional precision avoids the following error. The example assumes 16 significant digits.

The 7th root of x is x^(1/7). But we connot provide the exact value for 1/7 on any limited-precision calculator. On a 16-digit machine, all that can be done is providing the best possible exponent, thus calculating

   7th root of x  =  x1/7  ~=  x0,1428 5714 2857 1429
On a perfect calculator the exponent is off by at most 0,5 ULP. In this case it's 0,43 ULP. If we call this deviation dx, with a bit of calculus it can be shown that, in the final result, this causes a possible relative error of
  rel. error = dx * ln x
= 0,42857 E-16 * ln 4782969
= 6,592 E-16
or
abs. error = rel. error * exact result
= 6,592 E-16 * 9
= 5,93 E-15
Which is exactly what we get in the example:
  47829690,1428 5714 2857 1429  =  9,000 0000 0000 0005 93...
which finally is rounded to ...006.

The result for a 12-digit calculator is better since here the rounded value for 1/7 is only 0,14 ULP off, so that the absolute error is "only" 1,98E-11 or 2 ULP.

The above calculation can be used to find out how many digits are required to ensure a full 16-digit result for the n-th root of x. <8)

Dieter

#16

I share your view about the distribution of the sixteen digits of the full mantissa. BTW, it's the first digit being shown top left. As you suggest, displaying the first four digits up there may be the better alternative. Since the mantissa will disappear with the next keystroke, overlap with status indicators up there should not be an obstacle.

Walter

#17

Yes, in the meantime I realized it's the first digit that is shown in the first line. #-)

Concerning the distribution of the digits, what about this: First 8 digits on the first line, last 8 digits on the lower line. Even the exponent can be displayed without loss of information. The display for e^99 would look like this:

   98890303
19346947 42
By the way: I just notice that "copy number" on the emulator only copies the rounded 12 digit value, as displayed. Why doesn't it copy the the full precision 16-digit result?

Dieter

#18

Quote:
The 50g sounds like a "reasonable" calculator to me...

That's RPL, not RPN :-)
#19

Well, the distribution 8 / 8 plus exponent won't look as nice as you wrote it:

Quote:
I just notice that "copy number" on the emulator only copies the rounded 12 digit value, as displayed. Why doesn't it copy the the full precision 16-digit result?

Ask Marcus :-)
#20

Of course both digit groups should be left-justified. Also the exponent may be at the right end of the second line. But I am not sure if this looks better or is more useful than the current solution using the three smaller exponent digits.

Dieter

#21

Quote:
Of course both digit groups should be left-justified. Also the exponent may be at the right end of the second line.

Now you're asking a bit too much, I fear :-/
After all, it's just for SHOW :-)

I vote for four digits top left and twelve in the bottom - with or without the exponent, but at its regular position.

Walter

#22

Quote:
I just notice that "copy number" on the emulator only copies the rounded 12 digit value, as displayed. Why doesn't it copy the the full precision 16-digit result?

The copy command uses the same routine that formats the display. This routine is limited to the 12 digits. We may change this in a future release .

#23

I second Walter's opinion. 4+12 sounds reasonable.

#24

This is a work in progress. I quickly threw together the show display and we'd already had different viewpoints raised about what to display and where.

I figured we should work out what we want and just do that...
Then the discussions got redirected as they oft do.

4+12 sounds reasonable to me as well. I'd prefer to not do the exponent as well since we're running a different code path here and that will mean more bytes for little or no gain. Likewise, the decimal and thousands separators aren't being shown.


- Pauli

#25

Hmmmm 4 + 12 looks ugly in the console version :-(

I've built and committed it -- see what you think.


- Pauli

#26

Quote:
  LBL A
ENTER
LOG10
FLOOR
10^x
/
RTN

Under most circumstances the "10^x /" could be replaced with "x<>y SDR->Y" which is the same number of steps but faster.


- Pauli

#27

Quote:
Anyway, that statement is easy for me but more difficult for Pauli, so I leave the decision to him :-)

Since this has been asked for several times by several different people, it seems worthwhile enough. I've added the XROOT command. it appears in the X.FCN catalogues. It works in integer, real and complex modes. Integer was a right annoyance to get right.

Consider this in temporarily at the moment. It will depend on the number of bugs I've also included, the amount of flash consumed and our current flash head room.


- Pauli

#28

Quote:
I don't know the English term for "Totschlagargument", but if this is what you think about useful instructions that help getting better results, ln1+x and e^x-1 should get deleted immediately - these cases can be handled by simple series expansions as well.

No way are those two going away ever. They are far too useful internally.

Series expansions aren't the best way to calculate many of these BTW.

- Pauli

Edited: 20 Aug 2011, 10:23 p.m.

#29

Looks fine for me :-) except the many trailing zeroes :-/ but I can live with them.

#30

SHOW shows all sixteen digits. You get the trailing zeros. If you are using SHOW for its intended purpose, you care.

I still think it is ugly :-)


- Pauli

#31

What about displaying the mantissa just in the lower row. Eight digits at a time - waiting for a few seconds or a keystroke - and then the second eight digits? Or by scrolling them from right to left? The mantissa could even be longer than 16 digits if done this way.

#32

Our numbers are only sixteen digits in length so going longer is pointless.

I also detest scrolling displays. The 34S has none and it is going to stay that way ;-)


- Pauli

#33

Both your arguments convince me (I already was convinced regarding the scrolling display). But what about two step displaying, changing from first to second part by arrow up and down as often as one needs?

Edited: 21 Aug 2011, 6:17 a.m.

#34

Please not! Why should we make simple things complicated?

#35

Right - that was exactly the solution I had in mind when I wrote

Quote:
If SDL and SDR would accept negative values there even was a much more elegant "true 34s style" method. ;-)

But since SDL and SDR don't seem to work with negative arguments this is not a solution here. Consider numbers less than one where floor(log10(x)) gets negative.

This leads to the question why no negative arguments are allowed. If they were, one of the commands could be omitted: n digits left-shift means -n digits right-shift. Or is this already implemented in a newer version I do not know of yet ?-)

Dieter

#36

The command processing code doesn't handle negatives.

Making it do so would require a fair amount of effort and the result is a few commands merged.


Not to mention the display issues due to the extra character in the command name and the lack of space in the op-codes to store a sign.

- Pauli

#37

PS: look a the latest emulator :-)

Specifically, MANT and EXPT. Only ten times larger than the user code :-( And not guaranteed to remain.


- Pauli

#38

The (very minor) minus in simplicity brings a (huge) plus in aesthetics, don't you think? :)

And it could be a consistent way to display even longer numbers - should someone strive to calculate pi or whatever to the gazillionth digit.

#39

What if the first (!) 12 digits were displayed in the second line and the last four on top, right-adjusted. This way the second line would show the unrounded 12-digit value and the alpha line displayed the four guard digits. Maybe even with three leading dots to make it as clear as possible, like this:

    ...9793
314159265358

Dieter

#40

Aren't you interested in the final digits if you use SHOW for this?
They should be in the lower line. First leading digits are easy to see normally.

I'm happy to add some dots after the digits on the top line...

3141...
592653589793

Or a space and a down arrow. Or something similar.

My main objection to the 4/12 split is the top line isn't nicely spaced and doesn't look as good (to me) as the earlier 1/12/3 split. Still, I can live with either.

- Pauli

Edited: 21 Aug 2011, 7:20 a.m.

#41

Quote:
No way are those two going away ever. They are far too useful internally.

Let alone externally where all we have is 16 digits. ;-)

So, ln1+x and e^x-1 now have a sister, helping to get the best possible results. Now come on, Walter, let's give XROOT a warm welcome. :-D

Dieter

Edited: 21 Aug 2011, 7:34 a.m.

#42

Quote:
The command processing code doesn't handle negatives.

I see that this is not possible for direct input, like SDL -3 or so. But it may work with an indirect call like SDL -> Y.
Quote:
Making it do so would require a fair amount of effort and the result is a few commands merged.

Using my very limited insight in the 34s' internal structures I imagine that it could be handled by a simple test: if the argument in SDL is negative, use its absolute value and jump to SDR (and vice versa). But I'm sure it's not that trivial, is it?

Dieter

#43

We could do it that way but, for consistency, we'd also have to include all the other shifts, rotates, masks and any other commands for which a negative argument would be possible. Flash space.

The indirection code path checks the argument to ensure that it matches the range allowed for user input (which always starts from 0). We'd need to either relax this code and allow much evil (i.e. the user can break things) or extend the checking so that every argument command has extra range information. Flash space again.


So yes, it would be possible but it is unlikely to happen anytime soon.


- Pauli

#44

Quote:
Let alone externally where all we have is 16 digits. ;-)

I have had time to do precious little programming in this highly restricted environment :-( These functions matter with the 39 digits held internally and are every bit as important if not more so in the sixteen digit setting.


Quote:
So, ln1+x and e^x-1 now have a sister, helping to get the best possible results. Now come on, Walter, let's give XROOT a warm welcome. :-D

Let us hope I got XROOT correct :-)
I'm not too confident about the many integer cases :-(


I'm tempted by a few others (in the name of accuracy and stability):

  • versine(x) = 1 - cos(x)
  • sqrt(1 + x) - 1
  • 1 - sqrt(1 - x)

And their inverses which are also unstable when calculated naïvely.


Sigh, flash is full.


- Pauli

#45

Quote:
Aren't you interested in the final digits if you use SHOW for this?

Sure, that's why I think it's nice to display these otherwise invisible digits separately.

So the display would switch this way:
                     [h]            ...9793
3,14159265359 [SHOW] 314159265358
In other words, SHOW would simply add the last digits that were invisible before.

But the current implementation is fine by me either.

You say it still looks ugly. This might be because of the proportional font used for the dot matrix line. In most cases that's fine and helps to make the most of the limited space, but there is one exception: I think that at least the digits 0 to 9 should have the same width. Just like the Arial font (this way providing properly aligned numbers for instance in Excel where it is set as the default font). But something deep inside me tells me that Walter will not change this in a million years. :-)))

Dieter

#46

Quote:
I'm tempted by a few others ...

And bring us not into temptation, but deliver us from the evil feature creep.
#47

Quote:
I think that at least the digits 0 to 9 should have the same width. ... But something deep inside me tells me that Walter will not change this in a million years.

How do you know? Feel free to change the fonts from the year 2525 on ;-)

Seriously, we don't support tables here (in 1.5 rows :-/ ). Instead, we have to live with 43 pixels HP allows us, so space-saving is essential IMHO. YMMV
#48

Which is why they aren't implemented yet...

- Pauli



Possibly Related Threads…
Thread Author Replies Views Last Post
  HP50g: Writing a function that returns a function Chris de Castro 2 2,063 12-10-2013, 06:49 PM
Last Post: Han
  [WP34s] RSD function Dieter 11 3,201 01-29-2013, 08:58 AM
Last Post: Walter B
  [WP34s] Parallel function Dieter 25 5,758 11-05-2012, 04:04 PM
Last Post: Marcus von Cube, Germany
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 1,176 10-04-2012, 04:59 PM
Last Post: Paul Dale
  wp34s INC s function Jeff O. 18 4,403 10-03-2012, 02:20 AM
Last Post: Paul Dale
  WP34S Fibonacci function wildpig 3 1,288 09-02-2012, 02:25 AM
Last Post: Walter B
  [WP34S] LocRm allocation function missing? Chris Tvergard 10 3,125 05-14-2012, 10:14 AM
Last Post: Chris Tvergard
  [WP34S] Curious Bug in Inverse Normal Function Les Wright 61 12,103 05-01-2012, 02:44 AM
Last Post: Paul Dale
  [wp34s] Incomplete Gamma on the wp34s Les Wright 18 4,970 12-06-2011, 11:07 AM
Last Post: Namir
  [wp34s] Romberg Integration on the wp34s Les Wright 2 1,447 12-04-2011, 10:49 PM
Last Post: Les Wright

Forum Jump: