Two tiny, simple, yet useful functions that I miss on the 34s


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



Assume yo're aware of ASR, SR, and SL, but want something alike in real mode?


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




but I really like this idea myself.



Using existing commands:

STO[times] Y
RCL[times] L

So one extra step. If the half constant were available, the lengths would be the same.

- Pauli


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?



Yes, I'd be interested.

The current in rom normal should be nice and fast and accurate but at quite some space cost.

- Pauli


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



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


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.



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


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.



IDIV is in now. MUL2 and DIV2 won't come.


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



Oh happines Franz is your name :)))



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?



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.


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


Edited: 3 Aug 2012, 9:56 a.m.


The three character limit is due to the way we store op-codes for commands.

- Pauli


The reason these two aren't in is purely space. INC and DEC were freebies to implement. MUL2 and DIV2 aren't.

- Pauli


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


Edited: 3 Aug 2012, 6:51 p.m.


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


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



That sounds like viable at little cost. Pauli?


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


In integer mode, what should carry and overflow be set to?

Not quite as simple as it seems.

- Pauli


DIV and RMDR in real to serve customer request :-) Would be fine in integer as well but wasn't requested AFAIK. Who needs complex? ;-)


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


Wrapping it up:
Dieter wrote:

I agree that a command for integer division is useful.

That's for real, since for integers this is covered by /. He continued later:
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:
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.


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



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

Possibly Related Threads...
Thread Author Replies Views Last Post
  Simple Tetris. free for you to improve on cyrille de Brébisson 3 959 11-20-2013, 05:43 PM
Last Post: Erwin Ried
  [41CL] New Extra Functions version Monte Dalrymple 0 566 11-08-2013, 04:32 PM
Last Post: Monte Dalrymple
  [HP-Prime] Simple Game (Bugs) CompSystems 1 673 11-01-2013, 10:18 AM
Last Post: Han
  HP Prime: in need of help with defining functions Alberto Candel 14 2,098 10-27-2013, 10:48 AM
Last Post: Alberto Candel
  HP Prime spreadsheet functions SanS 0 1,120 10-04-2013, 04:23 AM
Last Post: SanS
  Stats functions on the HP34S Nicholas van Stigt 5 1,016 09-24-2013, 02:45 AM
Last Post: Nick_S
  Trig Functions Howard Owen 11 1,724 09-16-2013, 02:53 PM
Last Post: Fred Lusk
  50g piecewise functions Kurt Fankhauser 6 1,138 09-15-2013, 08:01 PM
Last Post: Kurt Fankhauser
  Missing functions on the HP Prime!!!??? :-( Namir 6 1,071 08-22-2013, 08:40 AM
Last Post: Gilles Carpentier
  Simple Math Question Namir 2 707 08-09-2013, 06:13 PM
Last Post: Eddie W. Shore

Forum Jump: