▼
Posts: 349
Threads: 66
Joined: Apr 2007
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
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
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.
Posts: 349
Threads: 66
Joined: Apr 2007
Quote:
Any specific application you want it for?
I was actually looking into some multipleprecision 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 multipleprecision (or perhaps only a verylargeinteger) 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 floatingpoint and integer "worlds" on the 34S. Since 64bit math is available with integers, that would at least permit integers at least 19 digits long, and with doubleword 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
Posts: 653
Threads: 26
Joined: Aug 2010
Your MANT implementations uses LOG and 10^{x} 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 E1
At least the 12th digit should not get rounded.
Dieter
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Your MANT implementations uses LOG and 10^{x} 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[sub1][sub0]
FLOOR
RTN
LBL'MAN'
STO I
XEQ'EXP'
10[^x]
STO/ I
x[<>] I
RTN
Franz
Posts: 3,283
Threads: 104
Joined: Jul 2005
Quote:
BTW  I still think the SHOW command needs an improvement.
The latest SVN releases should have an improved SHOW. Just try it!
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 653
Threads: 26
Joined: Aug 2010
I looked at http://sourceforge.net/projects/wp34s/files/ and found a zipfile dated 20110803, 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^x1 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 xth 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
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
I looked at http://sourceforge.net/projects/wp34s/files/ and found a zipfile dated 20110803, 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^x1 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
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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 20110803. 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^x1 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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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 uptodate, 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
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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 16digit result?
Dieter
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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 16digit result?
Ask Marcus :)
▼
Posts: 653
Threads: 26
Joined: Aug 2010
Of course both digit groups should be leftjustified. 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
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
Of course both digit groups should be leftjustified. 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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
I second Walter's opinion. 4+12 sounds reasonable.
Posts: 3,283
Threads: 104
Joined: Jul 2005
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 16digit 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 .
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Hmmmm 4 + 12 looks ugly in the console version :(
I've built and committed it  see what you think.
 Pauli
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Looks fine for me :) except the many trailing zeroes :/ but I can live with them.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 429
Threads: 31
Joined: Jul 2011
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 429
Threads: 31
Joined: Jul 2011
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.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Please not! Why should we make simple things complicated?
▼
Posts: 429
Threads: 31
Joined: Jul 2011
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.
Posts: 653
Threads: 26
Joined: Aug 2010
What if the first (!) 12 digits were displayed in the second line and the last four on top, rightadjusted. This way the second line would show the unrounded 12digit 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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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.
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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 spacesaving is essential IMHO. YMMV
Posts: 239
Threads: 9
Joined: Dec 2010
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.
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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 limitedprecision calculator. On a 16digit machine, all that can be done is providing the best possible exponent, thus calculating
7th root of x = x^{1/7} ~= x^{0,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 E16 * ln 4782969
= 6,592 E16
or
abs. error = rel. error * exact result
= 6,592 E16 * 9
= 5,93 E15
Which is exactly what we get in the example:
4782969^{0,1428 5714 2857 1429} = 9,000 0000 0000 0005 93...
which finally is rounded to ...006.
The result for a 12digit 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,98E11 or 2 ULP.
The above calculation can be used to find out how many digits are required to ensure a full 16digit result for the nth root of x. <8)
Dieter
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
The 50g sounds like a "reasonable" calculator to me...
That's RP L, not RP N :)
Posts: 3,229
Threads: 42
Joined: Jul 2006
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^x1 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.
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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^x1 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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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^x1 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
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
I'm tempted by a few others ...
And bring us not into temptation, but deliver us from the evil feature creep.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Which is why they aren't implemented yet...
 Pauli
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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 leftshift means n digits rightshift. Or is this already implemented in a newer version I do not know of yet ?)
Dieter
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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 opcodes to store a sign.
 Pauli
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 3,229
Threads: 42
Joined: Jul 2006
PS: look a the latest emulator :)
Specifically, MANT and EXPT. Only ten times larger than the user code :( And not guaranteed to remain.
 Pauli
