Swissmicros DM42 Calculator
 

We have talked about calculators here. I finally did it and ordered a Swissmicros DM42 which is a modernized HP42S. I’ll post when it arrives - shipping from Switzerland (!).

There is a WP43S project, intended to create an emulator for the ultimate RPN calculator with loads of math, stat and engineering fx. The plan is to sell this as a physical calculator, manufactured by Swissmicros. I figured I should see what the quality of these Swissmicros calculator is like, on this DM42, before getting ready to plunk down $ for the DM43 or whatever it will be called.

Oddly, I have no use at all for any advanced math, stat or engineering functions. I just like calculators. If I can find time to fumble through it, I’ll probably write some financial programs for my DM42.

https://forums.pelicanparts.com/off-topic-discussions/1063611-hp-rpn-geeks-what-do-we-think.html

I expect a full review - am still thinking about buying one...

Very cool. Can't wait to hear what you think.

The calculator looks and feels good. It is solid and surprisingly heavy. On the back and upper side there are IR transmitter, micro USB, and reset button.


http://forums.pelicanparts.com/uploa...1601659082.jpg

The screen is reasonably high resolution and decent contrast.

http://forums.pelicanparts.com/uploa...1601659102.jpg

The buttons are fine, though not as good as the old school HP calculator buttons. The printing is ditto.

http://forums.pelicanparts.com/uploa...1601659361.jpg

I forgot to attach this image to the previous post.

I haven’t started playing with it yet.

Looks like the HP my first wife (passed away many years ago) got me when I started school and we were getting serious. It was a lot of money back then for two young(ish) broke people.

I'm not cleverer or knowledgeable enough to contribute so here's a re-post just because it was so funny :D

$230 on Amazon - and I think I paid a little less than that for my HP 42CV back in 1980 as a EE major at GaTech. Impressive 34 decimal digits of precision - I think that 5 or 6 would be plenty unless you're designing nuclear reactors or something....

My wife just put batteries in her HP 15C for the first time in decades. I've never got the reverse-logic HP programming but she was very happy. To each their own I guess.

http://forums.pelicanparts.com/uploa...1601661271.jpg

I kinda want one! 230$ hurts

nice - I'd like a modern hp97 (I had a 67 which was better for skiing it up a mtn. to run heat exchange models...)

I'm super bummed that my old College HP 32S II died. I think one of the batteries leaked and the screen was trashed. It was probably at least 25 years old.

I've got RPN on my PC and phone, so I don't see a reason to buy another. If I did, I'd probably try to get an HP 35S. If I couldn't get that, then I'd probably go with the Swissmicros, and then I'd go for the big daddy HP 50 at $499. Again, no reason to get one. (But I really do miss my old one).

So right off the bat, I need to learn to write and store programs, because this thing has no financial functions built in.

Lawdy, the HP42S manual is over 200 pages long. Then there’s the programming guide and the supplemental Swissmicros manual. I just want to compute yield to worst! Waaah!

Oh, I figured out why it is heavier than I expected. The case is stainless steel with a PVD coating. Cool.

Very cool. If I remember correctly, the programming portion isn't too difficult (though I haven't written one in years). I have a couple of the 42S programming books; will look to see if I have any good examples of the financial functions.

Do the keys "click" or have otherwise satisfying tactile feedback when you push them?

What's it use for batteries?

I would think you could find a program for just about anything you needed/wanted online someplace. I'm sure there's a forum or something for HP RPN geeks.

There isn’t that much of what I want. RPN/HP geeks are mathy and sciency, seldom interested in finance. There’s some basic amortization etc programs. Unless I’m missing it.

What I think I need to write.
1. Value of bond at given discount rate.
2. Yield to maturity of bond (use #1 as subroutine, recursively)
3. Yield to call and to put of bond (use #1 as sub)
4. Yield to worst (use #2 and #3)
5. Value, greeks of option
6. Value, greeks of combination of options and underlying stock (use #5)
7. Implied volatility of stock at given option value (use #5 as sub, recursive)
8. Value of convertible bond (use #1, 5)
9. Option position to hedge given stock position to desired greek (use #6)
10. Value of equity given growth, margins, capital structure, discount rate, multiple
11. Implied growth or margins at given equity value (use #11)
12. Basic loan amortization, present values
13. Basic IRR (this could be sub for #2)

This will be just for fun, I don’t see actually using most of this stuff, and certainly not on a calculator.

A lot of this is backing into a number, so I see doing a lot of it recursively, unless I can use Solver. I tend to think that way - does X make sense, what would that imply for Y and Z?

The DM42 has expanded DATE functions that the HP42S didn’t, which will make this easier. It also has far more memory and a far faster processor. You can develop the programs using the Free42 emulator on your PC or Mac, then upload to the calculator. I feel like I need to plan all this out ahead of time as I’d like the various programs to use the same set of variables and registers.

They don’t audibly click though I think there is a beep you can enable, there is a tactile click so it isnt mushy, but it isn’t as distinct a tactile click or as tall a key as, say, an HP12C or other older HP. I’d say the keys are okay but not the pleasuresome experience of a vintage HP calculator.

Internal, rechargeable battery, charged using USB [edit - not sure about that, USB powers the calc but unclear if it charges it], I read it is supposed to last a very long time between charges.

If you find financial programs, I’d love to see them. I just realized I should look for HP41CX financial programs too.

If you primarily intend to back into a number then I do recommend using the solver. It's generally easier to setup than an executable program. Let me know if you need some solver examples.

I did find my 42s supplemental programming books this morning; it's all ME and EE stuff. Thought I had a financial book in the stack but was incorrect.

Kinda disappointed about the feel of the keys - that is, oddly enough, one of my primary reasons for wanting a calculator again - the nostalgic process of working through problems by hand. I still do that when it's important. Math is a tool to gain insight to the problem - it's not just about the numbers...

13 is not a lucky number...

but which of the 13 is the easiest to pgm in RPN? do that one first

The 42CV rules.

I remember so little about calculator programming. But seems I should start with the most basic building block. For bond stuff, it would be present value of an arbitrary set of future cash flows (PV of CF), each cash flow defined by $ and # days from now, with discount rate r. Then you can calculate yield to maturity by generating cash flows and trying different r until PV CF = price. And yield to call/put and yield to worst similarly. By iterating PV CF you can also calculate duration and convexity. So seems like write a PV CF subroutine and a recursive goal seek subroutine, and use those over and over.

Just think about the stack - you push something onto it and everything else moves up a notch (until it falls off into a nihilistic death at #5)

then you enter an operator on the last 2 things in the stack

above is based on my long ago memories which ended with a 41C

I think some calculators have an adjustable stack size. But yes, I think that sounds right.

4x5+8x6=

4 <enter>
5x (stack1) I think on my old calc, they'd call stack 1 and 2 (or was that really 3 and 4) x and y. Because there were buttons to do things to/with x and/or y including swapping them.
8 <enter>
6x (stack1 and 20 moves to stack2)
+ (adds stack 1 and stack 2)

It really clicked to me. It seemed genious and so much better than standard notation.

This is going to work. I read about how to call Solver as a subroutine, which is what I’d want.

I also figured out, I think, that the program to be Solved doesn’t have to be a predetermined formula. It can be a process that leads to a number, and Solver can repeat that process until the number is zero.

For the bond thing, I’ll need to enter as menu variables (MVARs): current date (DATE), maturity date (MAT), call date (CALL), face (FACE, or just default to 1000), coupon (CPN), coupons/yr (C/YR), price (PRIC). Write one program to get value if held to MAT and have Solver use that to find yield to maturity (YTM), another to get value if held to CALL and have Solver use that to find yield to call (YTC). Hopefully I won’t have to reenter the MVARs for each yield solution. I think I’m not going to fuss with variations on basis, just use 30/360. Just thinking out loud...

The Free42 emulator allows simply typing the program in a text document on the computer, then copy/paste into the emulator to test. When its working, upload to the DM42 using USB. This should be faster than poking at the keys for dozens of lines.

My recollection is that MVAR's are retained in memory just like any other variable between solver runs.

You don't have to call the solver from another program. You might write a simple program (a^2 + b^2 = c^2) for trial and practice with the solver directly.

Yeah, I just think using the program would be more convenient if it calls Solver internally.

The other cool thing about the DM42 is that it has a largish screen. One could potentially graph stuff. I don’t plan to but it’d be cool if I could figure out how to save an image that has instructions on how to use each program and is called by a HELP menu - not sure that’s doable but maybe.

I think you should get one. They’re not particularly expensive. The keys are okay.

I just might. I would use it mostly at work. I still have my HP42s (just don't take it to work anymore...)

It is interesting programming this thing. The first thing I need to do involves dates. Take a bond maturing 7/15/2027 with semi-annual coupons, today’s date is 10/7/2020, what’s the next coupon date? How to get 1/15/2021? Well, it stores dates as MM.DDYYYY. So you have to decompose 07.152027 to 7, 0.15, and 0.002027, and 10.072020 to 10, .07, and 0.002020. Then create 07.152020 and test if 07.152020 is greater or less than 10.072020. If less, add six months. Which means add 06 to 07 = 13, test if > 12, if yes then subtract 06 from 07 = 01 and add 0.000001 to 0.002020 = 0.002021, create 01.152021 and test if that date is before or after 10.072020, and so on and so on. And also need to be able to handle quarterly or annual coupons, or zero coupons. The HP42S had no real date functions as far as I know. The DM42 has added a few date (and time) functions, but still kinda limited. https://thomasokken.com/free42/#doc I guess HP figured engineers don’t need to work with dates much?

You’re right about “ Math is a tool to gain insight to the problem - it's not just about the numbers...” and this is forcing me to actually learn the subject. I’m used to simply reading a number from a screen and even if I know what that number means, I don’t know - or have long since forgotten - how that number is determined.

As an ME, I never really ever had need to have a real-time clock or calc dates on my HP42s. Component life always got calc'd in number of stress reversals and then figure how many hours/days/years of service life from that. 365.25 days in a standard year...

I looked at the Free42 doc. I see that there is a mode to report time in YYYY.MMDD and I would think that easier to deal with (just how my head works). I would attempt to write logic in which you've entered either a start date or an end date, compute number of days to the event of interest, and then calc forward/back with the DDAYS and DATE+ functions.

I wasn't aware those functions existed (but have now found them on Free42 that I run on my Android tablet).

Those Free42 functions will do most of what I need, I just need the equivalent of EDATE in Excel (add or subtract a given number of months, but keep the same day of the month) to deal with the Gregorian calendar in which from 04.142030 to 04.142020 isn’t actually 10*365 days, and going forward “6 months” from 10.022020 is 04.022020 not 03.312020 so 10.022020 180 DATE+ won’t work. That is needed to determine when the coupon dates are. Once that is known, DDAYS will work fine to get number of days to compound interest.

Interestingly, DOW will tell you the day of the week for any date, which suggests there must some calendar logic behind that function? It is supposedly based on the Time module of the HP41 but I don’t know how that worked.

Oh wait, here is a possible process: https://artofmemory.com/blog/how-to-calculate-the-day-of-the-week-4203.html

And https://en.m.wikipedia.org/wiki/Determination_of_the_day_of_the_week

Pricey
 

In 1973 or 74 my boss at the surveying company where I worked bought an HP calculator with scientific notation and one memory. Cost him about $325! Now, that was pricey! On a couple of occasions he let me use it to work on an engineering design project (college class) over the weekend.

Here's one way to figure out the same date of the month six months from now. Remember that the "date" value is just a regular decimal number within the calculator. This uses the IP (integral part) and FP (fractional part) functions from the original 42s instruction set. I'm also going to use the YYYY.MMDD date format (makes the calcs easier). This also assumes your date of the month is between ~6 and 28 (prevents rollover in February or getting into the previous month accidentally).

Store your starting date in reg 01 (or wherever) - I'm going to use 2020.1009 for the starting example.

RCL 01 (2020.1009)
100
X (now you have 202010.09)
FP (drops the stuff left of the decimal point yielding 0.09)
100
X (now you have 9.)
STO 02 (your day of the month is stored in reg 02)

RCL 01 (your original date again - 2020.1009)
180
DATE+ (now yields 2021.0407)
100
X (now you have 202104.07)
IP (drops the fractional part and gives you 202104.)
100
X (now have 20210400.)
RCL+ 02 (brings the day of the week back and adds to the stack and you have 20210409.)
10000
/ (divide and get 2021.0409)
STO 03 (and you've put the date in register 03)

(You're welcome.)

A more robust method would be to extract the month, add 6, test the result to see if it exceeds 12, add one to the year and adjust the month if it does, and then recompile the date code value. The native 42s instruction set has all kinds of "flag" functions for logical tests and can get messy. Another thought is to build yourself a matrix array of date data for your program and manipulate the years / months / days individually within the matrix stack. (Envision a matrix of 3 columns and x rows - assign each row a specific function/meaning - extract and manipulate individual elements of the matrix.)

Looked at a couple of videos last night of the DM42. I don't NEED one (I have a real 42s and a real 41CX and I have Free42 on my tablet and PC) but I'm beginning to want one...

I decided I need a general program to add or subtract any number of months from any date, and am trying to do it with as few tests as possible, seems more efficient. Turns out that by using IP FP and MOD, you can minimize the number of tests.

I need to get better at using tests and the stack. Like if and only if [number in X register] is negative, I want to add 0.000001 to variable “YR2”. It feels like I need to pre-load 0.000001 in register Z and 0 in register Y, then have

X<0?
R down arrow
R down arrow
RCL+ “YR2”

So if X<0, the stack rolls twice and 0.00001 is in the X register for the RCL+ command, but if X>=0, the stack only rolls once and 0 is in the X register for the RCL+ command.

Is that a good way? Seems cumbersome!

The examples in the manual all seem to resort to branching or subroutines after a test. It seems silly to do all that for such a teeny step.

To clarify for others (just in case), the program will only execute the one line immediately following the logic test if the logic test is true and will ignore it otherwise. That's why you see all the branching and subroutines in the program examples.

I'm not sure it that's a good way or not; in the past I always tried to minimize stack height and usually relied on manipulating registers to achieve something like that. It made it easier to control and I didn't have to worry about what was in the stack to start.

Math modules.

Are there implications of speed or memory usage, from different approaches (stack manipulation, register store/retrieve, branching/subroutines?

Maybe it doesn’t matter with the DM42 (or the HP42S). Back in the day I remember having to worry about resources. Of course, that was in the late 70s / early 80s and calculators were a lot slower.

My opinion - I'm guessing there are no serious implications regarding processing speed on a DM42 or within Free42. There were a couple tricks from "back in the day" on a real 42s that did affect memory and execution speed:

- Using the number registers didn't involve extra memory (those are fixed in memory whereas a custom named variable consumes additional memory). Probably not a problem with the DM42. My HP42s had "only" 7200 bytes of memory for programs/data storage. I usually used the upper range of numbered registers as scratch/temporary/working variables and transferred results to the custom-named variables at the end of the program.

- Programs that use local labels and goto's run faster than branching to a subroutine or a label stored in another program. Keep the local label close to where you use it; it will search down from the point of the call looking for that label before it moves to the top. The 42s searches for global labels from the bottom of the program memory and moves up.

Memory is a funny thing - I had forgotten about most of this stuff until this thread...

Thanks!

Man, I am feeling old and stupid. I just have a hard time keeping the stack and other registers straight in my head. I’ve actually built an Excel sheet that has columns for each stack level and each register, and rows for each line of code. As I type each line of code, I simulate the effect in the spreadsheet. This makes it fast to test the code and see what isn’t working. For no good reason I am still trying to do things by rolling the stack, LASTX, and so on. Anyway the date manipulation code is mostly working now. I can’t decide if I want to complicate it to deal with leap years and so on. Failing to do so will mean I’m potentially compounding a day or two more or less than the correct compounding period, which actually could be problematic.