HP Forums

From the look of the tracking info, my 15c LE will be showing up this afternoon. I noticed from staring at photos of a 15c keyboard, that it's lacking Mod, nCr, and nPr functions, which I do use on a fair basis on my 48SX. Are there any good implementations of these functions for a 15c? I'd like something that will produce results without overflowing during an intermediate step if one of the inputs is relatively large (the 48SX will compute COMB(3000, 4) with ease, for example, and that won't fly with a naive implementation). Speed won't be an issue with the LE model, I presume. :)

The 15c has them. Cy,x Py,x. "+" key.

Ah, excellent. Can't believe I missed that.

It appears I'm still in need of a Mod function, however.

Here is a small 15C MOD routine that works if both arguments have the same sign.

/ LSTx x<>y FRAC *

It was verified against 48GX results. If the signs of both arguments do not match, it does not return the correct result. If you are like me, and only use arguments of the sign sign, it will be fine. I suspect that a proper algorithm uses the Floor function, or something similar that is also not natively available on the 15C.

HP-15C has INT(IP) and FRAC(FP). So, X MOD Y could be X-Y*IP(X/Y) (depending on modulo function definition).

Yes.

Only missing the MOD function which may be easy to program.

# --------------------------------------------

# Tcl/Tk HEWLETT·PACKARD 15C Simulator program

# Created with version 1.2.13

# A Simulator written in Tcl/Tk

# COPYRIGHT © 1997-2010, Torsten Manz

# --------------------------------------------

   000 {             } 

   001 {    42 21 11 } f LBL A

   002 {          10 } ÷

   003 {       43 36 } g LSTx

   004 {          34 } x<->y

   005 {       42 44 } f FRAC

   006 {          20 } ×

   007 {       43 32 } g RTN

# --------------------------------------------

# This is only a suggested programm for MOD

# Only accurate due to display rounding.

#

# USAGE :  Enter y and x in 

# -----    respective stack position and press [ f ][ A ]

#          to get y MOD x display.

#

# Note: accuracy is only a result of display rounding process !

#       another code might be used to get a true (& right) integer

#       result.

Thank you to Torsten for pointing me out to his HP-15C emulator (it makes easy to copy-paste program listing).

Please note that this code use no register and leave the contents of t and z register intact in the stack (only moved down one step).

Edited: 15 Sept 2011, 2:30 p.m.

Just found the Mod routine I made for the 32s/32sii (and had forgotten about). It's got the interesting quality that it preserves stack contents, and only needs one storage register. It's also a little more impervious to precision issues than the implementations that use FRAC *. This ought to work with only minimal conversion effort.

M01	LBL M

M02	x<>y	

M03	STO T	

M04	x<>y	

M05	/	

M06	LASTx	

M07	x<>y	

M08	IP	

M09	*	

M10	RCL- T	

M11	+/-	

M12	RTN

Anybody want to take a stab at making it better?

You'll need to FIX 0 first, e.g. 10 3 MOD is not 1, its .9999999999.

Quote:

---

# Note: accuracy is only a result of display rounding process !

#       another code might be used to get a true (& right) integer

#       result.

---

001 LBL B

002 x<>y

003 ENTER

004 Rv

005 x<>y

006 /

007 g LSTx

008 x<>y

009 g INT

010 *

011 x<>y

012 Rv

013 CHS

014 g x<=y

015 +

016 g TEST 7

017 +

018 g RTN

This needs some simplification and stack preserving, but you've got the idea.

LBL 0

-

LSTx

x<=y

GTO 0

Rv

RTN

Edited: 15 Sept 2011, 2:54 p.m.

Very impressive demonstration of the beauty of RPN (and your knowledge of it).

Quote:

---

You'll need to FIX 0 first, e.g. 10 3 MOD is not 1, its .9999999999.

---

You are right, but FIX 4 may give in most cases the right integer result. Only FIX 9 may encounter a wrong result in rare occasions (like the one you give in your exemple).

Since there is no STD display format, most FIX n may be OK with n less than 9.

I came up with this one on the 32sii a long while back, it's not so obvious but is short and sweet and doesn't need more than the stack.

for y mod x:

0

enter

CMPLX+

/

IP

*

-

-Katie

Edited: 15 Sept 2011, 3:30 p.m.

Hi,

Yes, you are right, the first version of my code return an approximate y MOD x since it is not (or in rare situation) an integer, as expected.

So, I propose a second version which returns the correct integer result as long as both arguments are both positives. My new version use one register to store a the small value eps = 5× 10^-7 used to correctly round-up results. This eps constant have to be adjusted for larger result than 10000.

# --------------------------------------------

   000 {             } 

   001 {    42 21 11 } f LBL A

   002 {          10 } ÷

   003 {       43 36 } g LSTx

   004 {          34 } x<->y

   005 {       42 44 } f FRAC

   006 {          20 } ×

   007 {    45 40  0 } RCL + 0

   008 {       43 44 } g INT

   009 {       43 32 } g RTN

# --------------------------------------------

Edited: 15 Sept 2011, 4:07 p.m.

Quote:

---

This will just subtract off until it cannot. Slow, but short, no registers, probably very fast on 15LE. y > x.

---

Really nice, thank you, much better thant the one I proposed !
Of course, this way may be a bit slow on original HP-15c , especially with large intergers.

# --------------------------------------------

   000 {             } 

   001 {    42 21 11 } f LBL A

   002 {          30 } -

   003 {       43 36 } g LSTx

   004 {       43 10 } g x<=y?

   005 {       22 11 } GTO A

   006 {          33 } R_dwn

   007 {       43 32 } g RTN

# --------------------------------------------

But, don't try 789456123 MOD 9 on an original HP-15c, it's so loooooong for a really expected result !

Edited: 15 Sept 2011, 4:06 p.m.

Quote:

---

I came up with this one on the 32sii a long while back, it's not so obvious but is short and sweet and doesn't need more than the stack.

---

RCL Y

RCL/ Y

INT

*

-

Quote:

---

I hope the 32s has RCL Y and RCL/ Y, I don't know this calculator. ;-)

---

I wish it did, but no it doesn't have those operations.

Quote:

---

I wish it did, but no it doesn't have those operations.

---

But your Y is stack Y. Dave's T is regular register T (of A-Z).

Quote:

---

But your Y is stack Y. Dave's T is regular register T (of A-Z).

---

Better use INT instead of FRAC, no need to round.

Wow this is an unnecessarily confusing discussion.

Let's call x,y,z,t the stack and the non-stack registers A, B, C, .... X, Y, Z.

The routine I wrote uses the x,y,z,t stack registers only. The routine that Dave wrote uses the stack resisters plus register T. Although it preserves the stack registers, while mine does not.

On the 32s/ii there are no STO/RCL functions that allow you directly address x,y,z,t like there are in the 42s, for example.

Does that clear things up?

Quote:

---

for y mod x:

0

enter

CMPLX+

/

IP

*

-

---

Katie, can you be king enough to just explain a bit more your code. I only know a few about HP-32sii and I am unable to understand your trick with CMPLX+.
As the HP-15c also have complex calculation capability,perhaps may your way lead to a feasible solution on HP-15c ?

Quote:

---

Katie, can you be king enough...

---

Well, maybe "queen" enough would be more appropriate!

Sorry: could not resist. :)
Massimo

If I understand it correctly, 0 ENTER pushes a complex zero to X,Y and the arguments for mod to Z,T. The COMPLX+ just adds 0 to Z and 0 to T, placing the "sum" in X, Y without dropping Z and T. So the result of the operation is that you have the arguments twice on the stack. In RPL you would do DUP2 instead.

Exactly how I think of it: 0, ENTER, CMPLX+ is the DUP2 operation, a function in RPL and often defined in Forth. I wish it would have been an RPN function too, I'd certainly use it more than roll-up.

It is there on the 34S :-)

- Pauli

001 LBL A

002 x<>y

003 ENTER

004 Rv

005 x<>y

006 /

007 x<>y

008 Rv

009 g LSTx

010 x<>y

011 g INT

012 g LSTx

013 f FRAC

014 g TEST 2

015 f HYP COS

016 g INT

017 -

018 *

019 -

020 g RTN

MOD(y,x) = x - y * Floor(x/y)

Perhaps someone might want to do some optimization.

Edited: 15 Sept 2011, 8:55 p.m.

Quote:

---

I suspect that a proper algorithm uses the Floor function, or something similar that is also not natively available on the 15C.

---

You are right. Some Floor function implementations for the HP-32SII here. They might work on the HP-15C as well.

Simply use ^CENTER on the WP 34S. And yes, it's RPN :-)

Thanks for that guys! But I did say

Quote:

---

would have been an RPN function

---

I really needed this for the past 39 years, every since I had my HP-35.

Quote:

---

I really needed this for the past 39 years, every since I had my HP-35.

---

No problem! Set up a loop with the 34S AT (alter time) function. Decrement the current date until you reach the desired time, leave off a 34S (not the one you are using!) for your former self, and execute BTF (back to future.)

There's very little RPN isn't capable of. :)

Apologize I didn't have the knowledge then already d:-)

No need for loops - the counterpart of BTF is ATP (Advance To Past, please see page -17 of the well known manual) :-)

Edit: Almost forgot - there's also a command Stay At Present time ;-)

Edited: 16 Sept 2011, 2:28 a.m.

Quote:

---

Almost forgot - there's also a command Stay At Present time ;-)

---

How does that differ from the 41C stop time (STOPT) x function?

AFAIK you cannot compare SAP with anything else ...

Thank you Katie and Marcus.

It’s now clear for me, and I realize that there is no chance that complex-calculus capabilities of the HP-15c will help there.

Katie’s code translate to RPL will be same sort of :

« DUP2 / IP * -»

Here follow illustration of the various clever stack moves induce by RPN and RPL code:

At first consider the clever stack manipulation from Katie’s contribution:

[ 0 ][ Enter ][Cmplx][ + ][ / ][ IP ][ * ][ - ]

Suppose we have y = x.q + r,
where integer q is the multiplicand and integer r the modulus of interest.
We have r= y MOD x. And I also need posing f = (y/x) – INT(y/x) = FRAC( y/x ).

I like the clever way of managing the RPN stack:

t:    ~   |   ~   |   y   |   y   |   y   |   y   |   y   |   y   |

z:    ~   |   y   |   x   |   x   |   y   |   y   |   y   |   y   |

y:    y   |   x   |   0   |  y+0  |   x   |   x   |   y   |   y   |

x:    x   |   0   |   0   |  x+0  |  y/x  |   q   |  x.q  |y MOD x| 

        [0]   [ENTER] [Cplx+]   [/]    [IP]     [*]     [-]

It’s really close to what may be done in RPL (without the built-in MOD function.

4:        |   y   |       |       |       |       |

3:        |   x   |   y   |   y   |       |       |

2:    y   |   y   |   x   |   x   |   y   |       |

1:    x   |   x   |  y/x  |   q   |  x.q  |y MOD x|

«      [DUP2]   [/]    [IP]     [*]     [-]      »

The version proposed by flsh, which look really close to a HP-41C style with stack register manipulation.It spare one step through memory recall and operation combine in one [ RCL/ IND Y ] instruction.

t:    ~~~   |    ~    |    ~    |    ~    |   ~     |    ~    |

z:     ~    |    y    |    y    |    y    |   ~     |    ~    |

y:     y    |    x    |    x    |    x    |   y     |    ~    |

x:     x    |    y    |   y/x   |    q    |  x.q    | y MOD x |

  [RCl ST Y][RCL/ ST Y]       [IP]      [*]       [-]

But as RPL devices, the HP-41C (and HP-42S) calculator has built-in MOD function.

Here a version for the great WP-34S which have no built-in MOD function (or I am missing something?):

t:     ~    |    y    |    y    |    y    |   y     |    y    |

z:     ~    |    x    |    y    |    y    |   y     |    y    |

y:     y    |    y    |    x    |    x    |   y     |    y    |

x:     x    |    x    |   y/x   |    q    |  x.q    | y MOD x |

     [CENTER]     [ / ]   [FLOOR]       [*]       [-]

How to produce with short code the same stack manipulations on the HP-15C is another storie.

Here is for comparison the way proposed by Gerson:

l:  ~  |  ~  |  ~  |  ~  |  ~  |  x  |  x  |  x  |  x  |  x  | y/x | y/x | y/x | 

t:  ~  |  ~  |  ~  |  y  |  y  |  y  |  y  |  ~  |  y  |  y  |  y  |  y  |  y  | 

z:  ~  |  ~  |  x  |  ~  |  ~  |  y  |  y  |  y  |  y  |  y  |  y  |  y  |  y  | 

y:  y  |  x  |  y  |  x  |  y  |  ~  | y/x |  y  | y/x |  x  |  x  |  y  |  y  | 

x:  x  |  y  |  y  |  y  |  x  | y/x |  ~  | y/x |  x  | y/x |  q  | q.x |  r  | 

    x<>y ENTER  Rdwn  x<>y     /  x<>y  Rdwn LASTx  x<>y   INT     *     -  

Obviously HP-15C lacks same stack manipulation command. But that’s what makes the charm of this old-style true RPN calculator. In daily use of it, did this lack of complex stack manipulations miss any users?

A way to mimic the DUP2 stack manipulation style will be to use statistic function. But, even if this is short, this solution will clear (and use) registers R2 to R7. Perhaps it is not a convenient way ?

R2:    ~   |    0    |    0   |    0   |    1   |   1    |  1  |  1  |  1  |  1  |  1  |

R3:    ~   |    0    |    0   |    0   |    x   |   x    |  x  |  x  |  x  |  x  |  x  |

R4:    ~   |    0    |    0   |    0   |   x.x  |  x.x   | x.x | x.x | x.x | x.x | x.x |

R5:    ~   |    0    |    0   |    0   |    y   |   y    |  y  |  y  |  y  |  y  |  y  |

R6:    ~   |    0    |    0   |    0   |   y.y  |  y.y   | y.y | y.y | y.y | y.y | y.y |

R7:    ~   |    0    |    0   |    0   |   x.y  |  x.y   | x.y | x.y | x.y | x.y | x.y |

t :    ~   |    0    |    0   |    0   |    0   |    0   |  y  |  y  |  y  |  y  |  y  |

z :    ~   |    0    |    0   |    0   |    0   |    y   |  x  |  y  |  y  |  y  |  y  |

y :    ~   |    0    |    y   |    y   |    y   |    y   |  y  |  x  |  x  |  y  |  y  |

x :    ~   |    O    |    y   |    x   |    1   |    x   |  x  | y/x |  q  | q.x |  r  | 

[CLEAR Sig]  y [ENTER]        x   [Sig+][RCL Sig][RCL Sig]   [/]  [IP]   [*]   [-]

Since this last solution use so much memory register and clearing statistic also clear the stack, it is not a valid code.
I would prefer a simple one normaly using only one register and making the job straighforward.

I greatly prefer not to try to manipulate stack on an HP-15c, and using an approximative MOD function, only valid for y and x both positive :

l:      ~   |   x   |   x   |   x   | y/x | y/x |

t:      ~   |   ~   |   ~   |   ~   |  ~  |  ~  |

z:      ~   |   ~   |   ~   |   ~   |  ~  |  ~  |

y:      y   |   ~   |  y/x  |   x   |  x  |  ~  |

x:      x   |  y/x  |   x   |  y/x  |  f  |  r  | 

[FIX 0] [ ÷ ] [LASTx]  [x<>y]  [FRAC] [ × ]

Edited: 16 Sept 2011, 4:51 p.m. after one or more responses were posted

For the 34S:

cmplx ENTER

/

FLOOR

*

-

Which is a direct copy of the 32sii version changing IP for FLOOR (the 34S having both).

The 34S has a remainder function that is the same as MOD for positive arguments but slightly different for negative.

- Pauli

Some incarnations of the 34S software have a bug that make cENTER unreachable from the keyboard. It's fixed in both the zip and SVN now.

Thank you.

I just revised my previous post incorporating the WP34S version.
After I have re-read manual, since I still not fill confortable with this new calculator.

The 34S RMDR operation (h-shift divide) behaves the same as C's MOD operator (for both integer and real modes). For example:

 7  3 RMDR =  1

 7 -3 RMDR =  1

-7  3 RMDR = -1

-7 -3 RMDR = -1

There was mention a while ago of this not being the correct behaviour for MOD. I don't remember the exact details though. What should the values be here?

- Pauli

Edited: 16 Sept 2011, 6:13 a.m.

Quote:

---

 7  3 RMDR =  1

 7 -3 RMDR =  1

-7  3 RMDR = -1 

-7 -3 RMDR = -1

---

Hepp!
That what I missed; the "remainder" fonction of 34S, 42S and 16C tools !

 7  3 RMDR =  1     RMDR is MOD correct since   7 =  2 ×  3  +  1   and  0 < 1 < 3                                7   3 MOD =  1

 7 -3 RMDR =  1     RMDR isn't MOD despite of   7 =(-2)×(-3) +  1 due to 1 being greater than (-3).

             In this case we have to consider   7 =(-3)×(-3) +(-2) where remainder (-2) is between (-3) and 0. So  7 -3 MOD = -2

-7  3 RMDR = -1     RMDR isn't MOD despite of (-7)=(-2)×  3  +(-1) due to (-2) being out of range.

             In this cas we have to consider  (-7)=(-3)×  3  +  2 so that 2 is between 0 and 3 :  0 < 2 < 3    So -7  3 MOD =  2

-7 -3 RMDR = -1    RMDR is MOD correct since  (-7)=  2 ×(-3) +(-1) where -3 < -1 < 0                              -7 -3 MOD = -1    

Sametime I wonder myself, why and how simple idea became so complicated in the mathematic world ?

My (outdated) wp34s manual says:

RMDR   Equals MOD on HP-42S and RMD on HP-16C.

However, on the HP-42S we have:

 7  3 MOD =  1

 7 -3 MOD = -2

-7  3 MOD =  2

-7 -3 MOD = -1

Gerson.

Isn't the code above doing the remainder instead of MOD then?

-7 mod 3 is -1 according to the code above:

[RCl ST Y][RCL/ ST Y]  [IP]      [*]       [-]

(changing the INT  to IP and the IND to ST).

You need FLOOR instead of IP or INT to get a MOD don't you?

- Pauli

The manual is incorrect. It is the same as RMD on the 16C. It honours the sign of the numerator. To get MOD, add the denominator to the result if the signs of the two numbers are different.

Maybe I should just implement MOD as well although it will eat up a bit of space to do so. RMDR works with integers, reals and complex numbers and double precision integers -- MOD should also.

- Pauli

Quote:

---

0

enter

CMPLX+

/

IP

*

-

-Katie

---

Katie's code kind of 'ported' to the 15C:

001 LBL A

002 f I

003 ENTER

004 ENTER

005 ENTER

006 f Re<>Im

007 R down

008 R down

009 f Re<>Im

010 g CF 8

011 /

012 g INT

013 *

014 -

015 RTN

A bit longer but an implementation of the same idea... ;)

Edited: 16 Sept 2011, 9:19 a.m. after one or more responses were posted

This is the remainder of the integer division, however, not the modulus function. MOD can be defined as

MOD(x,y) = x - y * Floor(x/y)

where

Floor(x) = INT(x) + INT(FRAC(x) + 1) - 1

IP, FP: same as INT and FRAC, on the HP-15C

As I wrote, my code was just an implementation of Katie's very elegant 32s-idea ported to the 15c, whether it yields modulo or remainder - I didn't investigate. After I read the modulo article on wikipedia I'm not sure if I still know the difference between modulo and remainder... ;)
.

Yes, there is some confusion. On the HP-33s, for instance, they have implemented the modulus function, and yet they name it Rmdr. When the signs of the arguments are the same, they are equivalent:

 7  3 RMDR =  1

 7 -3 RMDR =  1

-7  3 RMDR = -1

-7 -3 RMDR = -1

 7  3 MOD =  1

 7 -3 MOD = -2

-7  3 MOD =  2

-7 -3 MOD = -1

Of course there must be no RCL IND Y commands in any of these routines. This would recall the register whose address is in y.

The correct sequence, as stated by Franz "fhub", actually is

  RCL Y

  RCL/ Y

  INT

   *

   -

  RCL Y

  RCL Y

   /

  INT

   *

   -

  ENTER^

  ENTER^

  CLX

   +

  RDN

   /

  INT

  R^

   *

   -

  REGY-REGX*IDIV(REGY,REGX)

Well...

Quote:

---

You need FLOOR instead of IP or INT to get a MOD don't you?

---

...the 35s has them both: IP and INTG. And RMDR, of course. ;-)

REGY-REGX*IP(REGY/REGX)

REGY-REGX*INTG(REGY/REGX)

Dieter

Thank you for your attentive reading and pointing out the “IND” error.

Of course, there’s no indirect access there. My intention was to make HP-41C "STO Y - where Y is in stack " notation not confused with HP-32 alphabetic name f register (where "STO Y" means store in register named Y). Using reserved keyword IND is my own mistake.

I have to correct this in my post.

I like your code using a dump zero addition " Clx + " to realize the DUP2 style algorithm on classic. It is a triky way.

t:    ~   |   ~   |   y   |   y   |   y   |   x   |   x   |   x   |   x   |   x   |   x   |

z:    ~   |   y   |   x   |   x   |   y   |   y   |   x   |   x   |   y   |   x   |   x   |

y:    y   |   x   |   x   |   x   |   x   |   y   |   y   |   y   |   q   |   y   |   x   |

x:    x   |   x   |   x   |   0   |   x   |   x   |  y/x  |   q   |   x   |  x.q  |   r   | 

   [ENTER^][ENTER^]   [Clx]   [ + ] [R dwn]   [ ÷ ]   [INT]  [R up]   [ × ]   [ - ]

Nice shot ! Achievable on all the classic !

Edited: 16 Sept 2011, 4:24 p.m.

By the way...

Quote:

---

Well...

Quote:

---

You need FLOOR instead of IP or INT to get a MOD don't you?

---

...the 35s has them both: IP and INTG. And RMDR, of course. ;-)

---

But there is a way - for instance on the '41:

  ENTER^

  ENTER^

   1

  MOD

   -

Dieter

Edited: 16 Sept 2011, 5:01 p.m.

Let make a table to check which fonction for which result :

  y  x : y MOD x   y RMDR x : y-x.INT(y/x)   y-x.FLOOR(y/x)   y-x.CEIL(y/x)

                               y-x.IP(y/x)    

  7  3 :       1          1 :            1                1              -2

  7 -3 :      -2          1 :            1               -2               1

 -7  3 :       2         -1 :           -1                2              -1

 -7 -3 :      -1         -1 :           -1               -1               2

I think it's important to say which MOD or RMDR you refer to. For instance, the results of MOD on the 41 and RMDR on the 35s are exactly the same.

Regarding CEIL: usually this is an easy one as CEIL(x) = -FLOOR(-x).

On a '41 this can be accomplished by

  ENTER^

  ENTER^

  -1

  MOD

   -

Dieter

Edited: 18 Sept 2011, 6:54 a.m.

C.Ret wrote:

Quote:

---

Of course, there’s no indirect access there. My intention was to make HP-41C "STO Y - where Y is in stack " notation not confused with HP-32 alphabetic name f register (where "STO Y" means store in register named Y).

---

Recall variable (data register) "Y":

RCL Y

RCL ST Y

BTW, the 34s does it in a very special way: the content of the stack registers is stored in registers with the same letter. So RCL Y means both "recall variable Y" and "recall stack register Y". ;-)

Dieter

Edited: 18 Sept 2011, 7:21 a.m.