▼
Posts: 247
Threads: 26
Joined: Oct 2007
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. :)
▼
Posts: 1,248
Threads: 33
Joined: Aug 2007
The 15c has them. Cy,x Py,x. "+" key.
▼
Posts: 247
Threads: 26
Joined: Oct 2007
Ah, excellent. Can't believe I missed that.
It appears I'm still in need of a Mod function, however.
▼
Posts: 2
Threads: 0
Joined: Sep 2011
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.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
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 HP32SII here. They might work on the HP15C as well.
Posts: 114
Threads: 18
Joined: Jan 2011
HP15C has INT(IP) and FRAC(FP). So, X MOD Y could be XY*IP(X/Y) (depending on modulo function definition).
Posts: 247
Threads: 26
Joined: Oct 2007
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?
▼
Posts: 1,619
Threads: 147
Joined: May 2006
LBL 0

LSTx
x<=y
GTO 0
Rv
RTN
This will just subtract off until it cannot. Slow, but short, no registers, probably very fast on 15LE. y > x.
Edited: 15 Sept 2011, 2:54 p.m.
▼
Posts: 1,089
Threads: 32
Joined: Dec 2005
Very impressive demonstration of the beauty of RPN (and your knowledge of it).
Posts: 260
Threads: 0
Joined: Oct 2008
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 HP15c , 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 HP15c, it's so loooooong for a really expected result !
Edited: 15 Sept 2011, 4:06 p.m.
Posts: 1,477
Threads: 71
Joined: Jan 2005
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.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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.
This is even a bit shorter:
RCL Y
RCL/ Y
INT
*

I hope the 32s has RCL Y and RCL/ Y, I don't know this calculator. ;)
▼
Posts: 1,477
Threads: 71
Joined: Jan 2005
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.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
I wish it did, but no it doesn't have those operations.
That's strange, because in message #6 Dave has used STO T and RCL T in a 32s program, so I couldn't imagine that such commands won't exist for register Y !?
▼
Posts: 1,392
Threads: 142
Joined: Jun 2007
But your Y is stack Y. Dave's T is regular register T (of AZ).
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
But your Y is stack Y. Dave's T is regular register T (of AZ).
Ahhh, now I got it: then this 32s doesn't have the usual 4 register stack XYZT !?
▼
Posts: 1,477
Threads: 71
Joined: Jan 2005
Wow this is an unnecessarily confusing discussion.
Let's call x,y,z,t the stack and the nonstack 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?
Posts: 260
Threads: 0
Joined: Oct 2008
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 HP32sii and I am unable to understand your trick with CMPLX+.
As the HP15c also have complex calculation capability,perhaps may your way lead to a feasible solution on HP15c ?
▼
Posts: 882
Threads: 23
Joined: Jan 2005
Quote:
Katie, can you be king enough...
Well, maybe "queen" enough would be more appropriate!
Sorry: could not resist. :) Massimo
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 1,477
Threads: 71
Joined: Jan 2005
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 rollup.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
It is there on the 34S :)
 Pauli
Posts: 4,587
Threads: 105
Joined: Jul 2005
Simply use ^{C}ENTER on the WP 34S. And yes, it's RPN :)
▼
Posts: 1,477
Threads: 71
Joined: Jan 2005
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 HP35.
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Quote:
I really needed this for the past 39 years, every since I had my HP35.
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. :)
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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.
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Quote:
Almost forgot  there's also a command Stay At Present time ;)
How does that differ from the 41C stop time (STOPT) x function?
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
AFAIK you cannot compare SAP with anything else ...
Posts: 4,587
Threads: 105
Joined: Jul 2005
Apologize I didn't have the knowledge then already d:)
Posts: 260
Threads: 0
Joined: Oct 2008
Thank you Katie and Marcus.
It’s now clear for me, and I realize that there is no chance that complexcalculus capabilities of the HP15c 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 builtin 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 HP41C 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 HP41C (and HP42S) calculator has builtin MOD function.
Here a version for the great WP34S which have no builtin 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 
[^{C}ENTER] [ / ] [FLOOR] [*] []
How to produce with short code the same stack manipulations on the HP15C 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 HP15C lacks same stack manipulation command. But that’s what makes the charm of this oldstyle 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 HP15c, 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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
Posts: 260
Threads: 0
Joined: Oct 2008
Thank you.
I just revised my previous post incorporating the WP34S version.
After I have reread manual, since I still not fill confortable with this new calculator.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
The 34S RMDR operation (hshift 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.
▼
Posts: 260
Threads: 0
Joined: Oct 2008
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 ?
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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. ;)
REGYREGX*IP(REGY/REGX)
resp.
REGYREGX*INTG(REGY/REGX)
will return the one or the other result.
The second version is equivalent to the 35s RMDR function.
Dieter
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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. ;)
FLOOR (or INTG on the 35s) really is a very useful function. However, most devices only offer INT or IP which simply cuts off the decimals.
But there is a way  for instance on the '41:
ENTER^
ENTER^
1
MOD

You can also try this with 1 and see what you get.
Dieter
Edited: 16 Sept 2011, 5:01 p.m.
Posts: 260
Threads: 0
Joined: Oct 2008
Let make a table to check which fonction for which result :
y x : y MOD x y RMDR x : yx.INT(y/x) yx.FLOOR(y/x) yx.CEIL(y/x)
yx.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
Obviously, MOD is obtained from FLOOR and RMDR from IP or INT.
CEIL lead to a third type of modulus.
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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

On a 35s, use RDMR instead. ;) Or simply CHS INTG CHS. That's one of the things I like on the 35s.
Dieter
Edited: 18 Sept 2011, 6:54 a.m.
Posts: 2,761
Threads: 100
Joined: Jul 2005
My (outdated) wp34s manual says:
RMDR Equals MOD on HP42S and RMD on HP16C.
However, on the HP42S we have:
7 3 MOD = 1
7 3 MOD = 2
7 3 MOD = 2
7 3 MOD = 1
Gerson.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 653
Threads: 26
Joined: Aug 2010
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
*

Although not required on a HP41 (MOD is available), a double RCL Y will match the DUP2 of RPL:
RCL Y
RCL Y
/
INT
*

Of course you can also do it on a classic HP machine. The following code is two steps shorter than Gerson's and uses the tduplication on stack drop:
ENTER^
ENTER^
CLX
+
RDN
/
INT
R^
*

The HP35s finally has a RMDR function and can also access the stack registers directly. It features both IP as well as INTG. It even offers a command for integer division, similar to DIV in some programming languages. Very handy in many cases. Using equation mode one could do it this way:
REGYREGX*IDIV(REGY,REGX)
Dieter
▼
Posts: 260
Threads: 0
Joined: Oct 2008
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 HP41C "STO Y  where Y is in stack " notation not confused with HP32 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.
▼
Posts: 653
Threads: 26
Joined: Aug 2010
C.Ret wrote:
Quote:
Of course, there’s no indirect access there. My intention was to make HP41C "STO Y  where Y is in stack " notation not confused with HP32 alphabetic name f register (where "STO Y" means store in register named Y).
There indeed is a special keyword on those calculators that feature both lettered registers and stack access, e.g. the 42s. Here, a simple "ST" distinguishes between stack and variables:
Recall variable (data register) "Y":
RCL Y
Recall stack register y:
RCL ST Y
On other calculators RCL Y is unambiguous since it can have only one meaning: There are no lettered data registers or variables on the 41, so RCL Y refers to the stack. On the 32s, there is no direct stack access, so it's clear that RCL Y refers to the variable (data register) with that name.
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.
Posts: 429
Threads: 31
Joined: Jul 2011
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
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
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 HP15C
▼
Posts: 429
Threads: 31
Joined: Jul 2011
As I wrote, my code was just an implementation of Katie's very elegant 32sidea 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... ;)
.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Yes, there is some confusion. On the HP33s, 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
Posts: 260
Threads: 0
Joined: Oct 2008
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 © 19972010, 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 HP15C emulator (it makes easy to copypaste 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.
▼
Posts: 1,619
Threads: 147
Joined: May 2006
You'll need to FIX 0 first, e.g. 10 3 MOD is not 1, its .9999999999.
▼
Posts: 260
Threads: 0
Joined: Oct 2008
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.
Posts: 2,761
Threads: 100
Joined: Jul 2005
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.
▼
Posts: 260
Threads: 0
Joined: Oct 2008
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 roundup 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
# 
USAGE :
Initiate register R0 with a small positive value (i.e. 5× 10^{7}),
Enter integer y and x into the HP15 LE stack,
Press [ f ][ A ] to run the code.
The integer result y MOD x is return and displayed.
Edited: 15 Sept 2011, 4:07 p.m.
▼
Posts: 114
Threads: 18
Joined: Jan 2011
Better use INT instead of FRAC, no need to round.
Posts: 2,761
Threads: 100
Joined: Jul 2005
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.
