The Game Designer's Calculator | Hacker News Reader

The Game Designer's Calculator

dig1000holes.wordpress.com

77 pointsakkartik27 comments

I really wish it went a bit further into why a programmable RPN calculator is better than an iPhone app or whatever.

Explain why RPN is so much better than infix. Explain why the simple, distraction-free BASIC impl is so liberating for certain kinds of tasks. Explain what kinds of tasks this little gizmo enables and why are these tasks better on the gizmo than on a more "modern" alternative. Riff on the weeks of battery-use, the lack of push notifications, the cool retro factor...any of this to convey the coolness that is the gizmo.

Nice little one-off piece, but I'd love to see something similar with more passion and explanation!

To me, not having to hit the home button, swipe, enter pin, find app, tap app, wait for an animation all before I can do anything the app is supposed to do, and then have to do most of that all over again if I don't touch it for a minute, is an excellent reason for a purpose-built device. Also, fucking buttons. I love buttons. Touch screens are awful.

I can't argue against the general purpose utility of a touchscreen, but I find touchscreens and the software we have built for them to be really cumbersome. For one, buttons on a calculator won't move on me at uncertain points during interaction! Doing things on smartphones is rarely succinct either as you illustrated.

But I also find excuses to put switches and dials on things and am the kind of person to think screen based aircraft cockpits are a regression.

I like touchscreen devices for infrequent input interactions. If my screen is already unlocked and the app I need is already open, for consumption based applications like article reading and video watching, it's great. But as soon as I get an on-screen keyboard, I end up frustrated very quickly.

The article links to this explanation of RPN and its benefits. https://www.swissmicros.com/what_is_rpn.php

After reading, I discovered the macOS calculator supports RPN (Cmd+R) and it is about as cool as described. Looks like the iPhone calculator does not but I'm sure there are great apps.

The firmware for the DM42 is based on GPL'd software available for all major operating systems (including iOS.)

http://thomasokken.com/free42/

For iPhone, PCalc [1] is quite good. It's also excellent on iPad. In fact, when my iPad 3 was due for replacement, PCalc almost persuaded me to go with iPad Pro instead of switching to a Surface Pro 4, but the SP4 won for better web browsing, better copy/paste, and OneNote.

The MacOS calculator's RPN mode is annoying. They don't get stack lifting right.

Suppose you want to compute sqrt(12) + pi.

Starting from an empty stack, this will do it on an HP calcualtor, PCalc, both RPN calculators I downloaded from the Windows Store, and, well, pretty much every RPN calculator I've used except from Apple:

  1 2 SQRT Pi +

When you hit the Pi key, it pushes Pi onto the stack, lifting up the sqrt(12) that is already there.

On the MacOS calculator, the Pi overwrites the sqrt(12).

If you do it this way:

  1 2 SQRT 3 . 1 4 1 6 +

then it works the same everywhere.

One other difference to watch out for. On some calculators, this:

  2 ENTER +

will give 4. This includes some HP calculators, such as the HP-15C. On these calculators the ENTER pushes whatever is in X, and leaves a copy in X with a flag set telling it that if you enter more digits they should overwrite X. Number entry goes directly into X, so the "2" goes into X, the ENTER pushes X to Y, so now X = 2 and Y = 2. So "+" works, giving 4.

On others, it will give a missing operand error. This includes the HP-48 family. On these calculators, number entry does not take place in X. It takes place in some sort of input buffer, and ENTER pushes that onto the stack so it ends up in X. So the "2" goes into the input buffer, ENTER signifies you've finished and 2 goes to X. X was empty before so nothing gets pushed to Y. So you've only got one operand and the "+" fails. (On these calculators, operators other than ENTER implicitly insert an ENTER first if the input buffer is not empty).

I'm not sure why HP changed this. The older calculators only had 4 stack positions, no entry buffer, and the display only showed X. By the time of the HP-48 they had many many more stack positions, an entry buffer, and the display could show the bottom 4 stack positions (or the bottom 3 and the entry buffer during digit entry). Perhaps the HP-48 behavior is what they always wanted, but decided it would be too confusing on the older calculators where your visibility was limited.

PCalc and MacOS calculator are like the HP-15C. PCalc has an "HP 48 Style" option on the advanced settings page if you prefer the HP-48 behavior.

[1] http://www.pcalc.com/

From the DM website: Compact size - are small enough to easily fit in any shirt pocket or purse or school backpack Extended battery life - have low power requirements, a single CR2032 will last for many years Full-sized capabilities - have all of the mathematical functions and programming power of full-sized HP calculators Connectivity - have an USB connection to save and load the complete state of the calculator including all programs and registers Firmware update - can be updated to the latest firmware release through the miniUSB connection Nostalgia - give you the feeling you had decades ago

To be fair, for this dev the reason it is better is it makes them happy.

I'm similar. I have my HP 49G sitting on the desk near me. Don't use it much, which makes me sad.

I have several things I like more about RPN. Especially over infix, it is a bit easier for me to decompose what I'm doing. Especially since I can't stand the arrow keys to jump around the bloody equation as I'm entering it. That said, I don't think it is "de facto" superior. I do like it, though.

> Explain why RPN is so much better than infix.

At least in my experience, it allows easier reuse of previous values. This makes RPN based calculators easier to use for exploratory kinds of work.

On my PC desktop I use an RPN calculator, I find it so much more useful than a standard style calculator. I think it's because you can see the stack and visually validate the numbers you are working on.

I use RPN Calculator v1.3 by Bill Menees, I find the interface a lot cleaner that the others I've tried.

I must say I can't see the connection to game design. Nevertheless, DM42 is pretty damn nice looking thingy, so I'm not complaining too much finding it on the front page. Too bad I don't really have any use for it to justify the relatively steep (if understandable) price tag.

I'm pretty sure it's meant for tabletop games, as in a DM/GM would use this in their roleplaying game they're running in a campaign they've designed.

Still seems pretty tenuous. If you're designing a tabletop game, you're probably not rolling dice during the design phase.

As someone who just designed a tabletop dice game...I totally rolled a bunch of dice. Distribution charts are good for a sanity and balance check, but rolling the dice gives you more of a feel for the game, what you can expect to get with any given roll, and give you a feel for how to manipulate the dice (physically), see how fiddly it can be, how much time it takes for turns, etc.

But you can't replicate that bit with a computer program too well.

Ah. Different use of designing a game - I was thinking more like a D&D campaign. I suppose it shows my affiliation: tabletop RPGs instead of board games ;) I can certainly see how that would be useful for your case.

I believe it's talking about table top gaming.

I have an HP 48G in my desk drawer. Back in highschool I spent months playing with it obsessively, writing games and 3D graphing programs and whatnot. Haven't touched it since then, although I'm still fond of it in some theoretical sense. They're a great "pocket computer" for when you don't have access to a "real" computer (ie. one with a programming environment) but I don't think they're actually useful unless you're in some engineering profession where you regularly use complex formulae in the field.

I have a 48SX. I never seriously got into programming it, but I did do one program that I was inordinately pleased with.

I wanted a calendar, and found one online but it was very slow. It was written entirely in the User RPL. So I wrote my own, also entirely in RPL, but managed to get it fast enough that there was no perceptual difference between its speed and the speed of assembly language calendars.

I got the speed by managing to do almost all of the formatting, which was the slow part, using User RPL string functions, which were all internally implemented as highly optimized assembly.

I'd start with these two strings (spaces replaced with _ for clarity):

days = "__1__2__3 ... _29_30_31"

pad = "_____________________" (that's 21 spaces)

Then I'd calculate

s = number of days month is shorter than 31 days, and

d = day of week of 1st day of month (Sunday == 0, Monday == 1, ...).

Shorten the days string by 3 * s, and prepend 3 * d spaces on front of days (which can be obtained by taking an appropriate substring of the pad string). Finally, append the pad string to days.

Display a header line:

"_Su_Mo_Tu_We_Th_Fr_Sa"

Now take the first 21 characters of days and display them on the next line under the header, then the next 21 characters on the next line, and so on for 5 lines, and that's your calendar.

This could probably be improved a bit by starting with a days string that has 18 spaces in front and 12 spaces at the end. Then you just have to possibly replace some numbers with spaces if the month is shorter than 31 days, and then use the day of the 1st to choose where you start taking the 21 character substrings from.

There's a much under-rated rush that comes with your first real optimisation job. Mine was with a program to simplify square roots into surds - we'd had the lesson on them in year 10, then been given a sheet of about 100 different square roots to simplify. It was repetitive grunt work and so I wrote a program to do it. The first version worked, but was too slow (it simply tried number from 0 to N/2, checked if it was square, then checked if it was divisible) so I did the obvious thing and instead only checked square numbers, taking it from O(N) to O(SQRT(N)). Simple enough but it made me happy. :)

I had a similar sort of experience with both a 48SX and a 48GX. They were great little portable computers back in high school, but as soon as I got better access to bigger machines, I lost interest/motivation.

With that said, there are some technical aspects of the 48 series that were particularly gratifying. The unified programming model (RPL all the way down to assembly) and focus on customization made it easy to extend the calculator in interesting ways. (ie: I remember writing a reasonable improvement to the stack display in a couple hundred bytes of user code, etc.)

The USAG command was another fun example. The HP48's programming language was dynamically typed... every user command had a standard type check/dispatch prologue at the beginning of its code that would check the arguments on the stack and dispatch to the right block of code based on types. What USAG did was to take the name of a command, inspect the code to look for what combinations of types it could accept, and then present those in the UI a form of 'online help'. (Editing RPL programs worked similarly... the calculator didn't retain the text of a program you entered, it would reconstitute the text by inspecting the 'compiled' code).

Reading back over those examples, they aren't the kind of thing you'd expect to write about a calculator... which is part of what made the HP48 series so much fun.

Why is it impossible to find a small advanced calculator? I use an hp-35s now but I hate it. I want a calculator with rpn, programmability and an equation solver that is pocket sized. I understand rpn is niche, but relaxing that restriction still only finds you huge graphing calculators.

SwissMicros has a range of credit card sized calculators that are so close to what I want. However they are running hp firmware in emulation and I don't believe that any of the firmware they are using have an equation solver.

We have the technology now to make an advanced pocket sized calculator I'm sure. Why does no one want to release one? The calculator enthusiast community seems content with just emulating 30 year old calculators and everyone else is just selling calculators for people that need to take standardized tests.

Since it took me forever to find this info on swissmicro's page, this is for all the portrait calculators:

DMXXL: Same size and features as HPXXC

DMXX: Credit-card sized HPXXC (but full sized display)

They all appear to take cr2032 batteries.

The 42 can run off of USB power (and will clock higher when doing so). It is unclear if the portrait calculators will as well.

Oh that looks awesome! I've got a real soft spot in my heart for old HP RPN calculators — they're the only way to do figures!

Why this over something like the HP Prime?

The site's wrapping on mobile is cancer

You're being downvoted, but it is pretty bad. Looks like they set word breaks to 'break-all' for those low-width media queries.

Reply on news.ycombinator.com