▼
Posts: 653
Threads: 26
Joined: Aug 2010
It looks like the 34s project sooner or later will come to an end, so I would like to suggest a simple extension of its function set that I consider useful. If I'm not too late, that is.
We all know the INC and DEC commands that increment resp. decrement any register by one without disturbing the stack. The is no doubt these are two extremely handy commands that can be found in many user programs. I would suggest two similiar commands that multiply resp. divide a register with/by 2. The are countless applications where this would be useful.
Sure, doubling X can be done by STO+X or RCL+X, but there is no shortcut for other registers. Even more important, there is no way to provide X/2 (or Y/2, R01/2, ...) without disturbing the stack, and a sequence like 2 STO/ 01 DROP even takes three steps and loses T. All you can do is prestore 0.5 in a data register and then use RCLx nn.
That's why I would like to suggest these two commands. These and maybe one tiny little additional value in the constants catalogue: 1/2 or 0.5. Thank you. :-)
Dieter
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Assume yo're aware of ASR, SR, and SL, but want something alike in real mode?
▼
Posts: 653
Threads: 26
Joined: Aug 2010
Well, yes, since I do virtually all my calculations with reals, this is what I am looking for.
I also like SDL and SDR very much - two nice and handy functions that do something similar (but limited to X) with powers of ten. Together with the integer constants #000...#255 they are also useful for generating short reals - a feature that I use quite often.
The two new functions should behave just as INC and DEC, so that any register can be altered without disturbing the stack. Including X, of course. 8-)
Example: assuming the command is named HALF, here's how to get the Normal integral from 0 to x with best accuracy, using the regularized incomplete Gamma function. Please also note the constant #0.5... ;-)
X^2
HALF X
#0.5
IGammap
HALF X
Dieter
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
but I really like this idea myself.
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote:
X^2
HALF X
#0.5
IGammap
HALF X
Using existing commands:
x^2
.
5
STO[times] Y
IGammap
RCL[times] L
So one extra step. If the half constant were available, the lengths would be the same.
- Pauli
▼
Posts: 653
Threads: 26
Joined: Aug 2010
Ok, ok - in this case it can be done with existing commands as well. Yet not quite as elegant. ;-)
This example was taken from my current implementation of the Normal quantile (oops, there it is again ;-)). Here the constant 0.5 is required so often that I even sacrificed an extra register just for this value.
BTW... this solution seems to return 33 or 34 valid digits, it has no problems with p close to 0.5 and requires just two iterations (or even less). The current version (including two additional tests for even faster execution) requires 100 steps of user code, including the code for the initial estimate. Would you be interested, maybe to use this for an XROM routine?
Dieter
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Yes, I'd be interested.
The current in rom normal should be nice and fast and accurate but at quite some space cost.
- Pauli
▼
Posts: 653
Threads: 26
Joined: Aug 2010
Yes, I know the 34s is a "moving target" (and it's moving fast), but I have to admit I'm a bit confused now.
I thought the Normal quantile had moved to XROM?! So it is back to ROM now? Coded in C with 39-digit precision? Great to hear this. In this case it just requires a few minor improvements.
I currently use version 3.1 3208 with the emulator. There are some issues if you leave SP mode and switch to DP. Here, accuracy may drop down to 18 digits and calculating the quantile for p close to (but less than) 0.5 may take very long. On the other hand, p > 0.5 seems to work fine. I suspect the distribution's symmetry is not used, which would also explain why, for example, p = 1E-20 and 1 - 1E-20 do not return the same result (except the sign).
Anyway - I will post my current solution in 34s user code. Maybe you can make use of the one or other idea in it. Especially this symmetry thing. ;-)
Dieter
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
I put back the cdf_helper code and went back to the older xrom code in revision 3210.
The QF is still xrom, but it is using a faster converging method but the pdf and cdf are (almost) internal precision again.
The down side is this cost half a kilobyte of flash.
You keystroke implementation seems like a better alternative so things might change once again.
- Pauli
▼
Posts: 653
Threads: 26
Joined: Aug 2010
Fine. As long as the two IGamma functions can be used, the two cdf helper functions are obsolete. Well, almost. But with user code / keystroke programming in DP mode it will not get better than 33-34 digits anyway.
If you once choose to implement the posted solution in a regular internal function (using 39 digit precision) you may include another (fourth) term in the correction so that a result close to full precision will be possible (I guess something like 37 digits - with sufficient working precision 39-40 digits would be possible).
You say you have put back the cdf helper functions, so I guess this also applies to the series resp. continued fraction expansion. In the latter case the number of required CF loops can be evaluated quite exactly in advance. For 34+ digit precision, please use n = ceiling(1700/z^2) + 20 loops. In this case the max. error is approx. 1 unit in the 35th digit. For an internal function use 2100/z^2 + 21 loops. In both cases z >= 2.
However, if 33 digits are fine, the proposed method can be an option. Use the same algorithm with 39 digit precision, and you should get all 34 DP digits right.
Dieter
Posts: 3,229
Threads: 42
Joined: Jul 2006
I did contemplate commands to add, subtract, multiply or divide X by a small integer constant.
A half and double command would be easy enough to add of course. The constant 0.5 is in the image already but not exposed to the user.
We'll discuss I suspect.
- Pauli
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
We'll discuss I suspect.
What about MUL2 and DIV2 ?
BTW, some time ago I wondered if there's really no integer division command (e.g. DIV or QUOT or \ ) in the WP34s.
Of course / and IP could be used, but almost every computer language (and many calculators) have this command - and we also have the 2 functions MOD and RMDR, so such a 'IntDiv' would be a nice completion.
Franz
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
IDIV is in now. MUL2 and DIV2 won't come.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
MUL2 and DIV2 won't come.
Well, these functions were not my idea (I just made a suggestion for possible names), so I don't really miss them. ;-)
Franz
▼
Posts: 31
Threads: 2
Joined: Jun 2007
Oh happines Franz is your name :)))
Damir
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Oh happines Franz is your name :)))
LOL, I'm indeed quite happy with the current WP34s status.
But what would make me absolutely happy would be longer names for self-defined functions. With only 3 characters you just can't find any meaningful abbreviation for any function or program you write.
Is there really no way to allow at least 6 (or even 8) characters?
Franz
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
I'm afraid I can't imagine you'll ever get more than 6 characters for that since the limit for internal function names is 6 characters as well. And now you want to have 6 character labels, don't you? That sounds like blowing our function code space [:-( but Pauli shall know exactly.
Edited: 3 Aug 2012, 8:48 a.m.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
And now you want to have 6 character labels, don't you?
Well, 6 would be ok and definitely much better than the current 3.
I know lots of mathematical functions with combined names and with 2x3 characters you could give them useful names (e.g. INVMOD, EXTGCD, LINPRO, TRIGON, MODSYS etc. just to name a few).
And then think about writing a package for a special purpose - e.g. I've started with a polynomial package: now if you would want names like P.xxx (as M.xxx for matrix functions), then you've just left one single character after 'P.' which doesn't allow any useful names.
With 6 letters everything would just be much easier and better to understand, and I won't care at all if such a 6-letter label would need 4 (or even more) bytes instead of 2.
Franz
Edited: 3 Aug 2012, 9:56 a.m.
Posts: 3,229
Threads: 42
Joined: Jul 2006
The three character limit is due to the way we store op-codes for commands.
- Pauli
Posts: 3,229
Threads: 42
Joined: Jul 2006
The reason these two aren't in is purely space. INC and DEC were freebies to implement. MUL2 and DIV2 aren't.
- Pauli
▼
Posts: 653
Threads: 26
Joined: Aug 2010
Hmmm... I just had an idea where I don't know whether it's simply brilliant or plain stupid. #-)
Do you think there is a way to use RCL-arithmetics with the built-in constants? A well-known equation might then look liks this:
before after
-------------------------
x^2 x^2
# g RCLx #g
x RCLx #1/2
2
/
And now imagine what you could do with RCL+ #002, RCL- #005, RCLx #pi etc.
Would you consider this useful - and possible to implement without too much effort? Or does this require as much space as a special x2 resp. /2 command?
Dieter
Edited: 3 Aug 2012, 6:51 p.m.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
At one stage, I did propose four operations that added, subtracted, multiplied and divided X by a constant argument. This suggestion didn't make it. I doubt the same thing using the built in constants would either.
Space wise, I don't think they would be much difference between this and the multiply and divide by two commands.
BTW, there is a difference between the built in constants and the small integer constants -- completely different commands in fact. They just look similar on screen and are input from the same catalogue.
- Pauli
Posts: 653
Threads: 26
Joined: Aug 2010
I agree that a command for integer division is useful. But there is an even more useful way to provide such a function. Have you ever done some programming in x86 assembler? The standard division command returns both the integer part of the quotient and the remainder. I always considered this a nice and handy feature since often both values are required. So this would be a kind of DIVMOD command that returns both y DIV x and y MOD x.
Just an idea. :-)
Dieter
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
That sounds like viable at little cost. Pauli?
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
DIV and MOD or DIV and RMDR?
Integer, real and complex?
This operation makes most sense in integer mode to my mind at least.
However, it is easily defined in real and complex modes.
Real is short, simple and easy.
Integer less so.
Complex will be larger again.
- Pauli
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
In integer mode, what should carry and overflow be set to?
Not quite as simple as it seems.
- Pauli
Posts: 4,587
Threads: 105
Joined: Jul 2005
DIV and RMDR in real to serve customer request :-) Would be fine in integer as well but wasn't requested AFAIK. Who needs complex? ;-)
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
The DIVMOD instruction in question is for integers only I thought. It doesn't make as much sense for reals.
We support almost every function over the reals, integers and complex domains so yes, complex support isn't insignificant.
- Pauli
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Wrapping it up:
Dieter wrote:
Quote:
I agree that a command for integer division is useful.
That's for real, since for integers this is covered by /. He continued later:
Quote:
The standard division command [in x86 assembler] returns both the integer part of the quotient and the remainder. I always considered this a nice and handy feature since often both values are required.
So that's meant for real as well. Then Pauli responded:
Quote:
This operation makes most sense in integer mode ... However, it is easily defined in real and complex modes. -
Real is short, simple and easy. Integer less so. Complex will be larger again.
So let us have DIVRMD in real and integer modes at least. We could drop IDIV then. Just my 20m€ - YMMV.
▼
Posts: 653
Threads: 26
Joined: Aug 2010
Sorry if I my intention was not clear. The assembler command I originally referred to is the DIV command for integers, returning both the quotient and the remainder. But of course I would like to see such a command included for both integers and reals (which is the data type most of us will use 99% of the time).
Complex for me is nice, but optional. ;-)
Dieter
Posts: 3,229
Threads: 42
Joined: Jul 2006
INC and DEC are there because they are essentially free since they can share code with ISZ and DSZ -- just no skip on zero.
- Pauli
|