Why Both?

By sheer happenstance, I purchased a SwissMicros DM32 mere months prior to the public release of the R47 hardware. Had I known availability of the R47 was this close, it is possible that I would have waited, limiting myself to purchasing one really expensive boutique calculator, but since I now have two, it is natural to compare-and-contrast.

While I am not advocating that others follow this path, I can already see that there may be reasons why another might choose to have both, without needing a similar failure of foresight to retroactively justify that decision.

Others might read this document to find out which single machine to buy. I can tell you this much already: although the R47 covers 100% of the functionality of the DM32, there is value in the latter’s relative simplicity.

Establishing the Landscape

Although the SwissMicros DM32 is intended to behave much like the Hewlett-Packard HP-32SII, it is largely a first-party design. This modern hardware creation does have the same buttons in the same arrangement as the 32SII, with the same labels, giving the same broad effects, but everything else differs. The SwissMicros hardware platform is generations past what HP had at hand in 1991 when they released the 32SII, and the firmware behind it is a complete reimplementation, not a copy of HP’s old firmware running inside a Saturn CPU simulator. All this shows in the calculator’s user-facing behavior, giving the modern device a distinctive “SwissMicros” feel. To call it a mere clone would miss the target by a mile.

My understanding is that this is the same base hardware platform used for the DM42n and the R47. The entirety of the physical difference is down to the text printed on the faceplate and buttons, plus minor details like where the colorful shift keys are placed. Everything else is a matter of which firmware you happen to have loaded.

Availability of this semi-open flexible platform permitted the creation of the C47’s ancestor projects, resulting in the R47 production version. Because I have no experience with the earlier DM42 conversion efforts, I will refer solely to the R47 from here on, being the device I have at hand.

Speaking of conversion efforts, I do believe it possible in principle for the R47 team to port their code to the DM32 platform, but that would require a near-complete remapping of the buttons, plus a new bezel design. I completely understand a wish to restrict expenditure of finite volunteer efforts to a single base platform.

Broad Impressions

Different minds = different results. Although these multiple teams have been developing atop the same hardware platform, their efforts have yielded two very different experiences in the DM32 and R47.

An excellent place to start exploring these differences is the six soft menu selection buttons, which the DM32 keyboard adds above those giving access to the HP-32SII functionality.

But first we must to dig back to its predecessor, the HP-32S. This was not Hewlett-Packard’s first menu-driven calculator,¹ but there is a strong distinction to be made relative to the HP-32S’s direct-line predecessors in the Voyager series, where the closest you got to menu-driven behavior was the HP-15C’s TEST button. HP perpetrated that botch because the functions they wanted to stuff into the 15C over the earlier 11C crowded all but two of the numeric tests off the main user interface. While the x?0 and x?y menus on the DM32 are vaguely similar, they show all of the hard-coded test type options right there on the display, to be picked with the top row of function buttons. Calling one of the ten tests hidden away in the 15C’s TEST menu required identifying it with a 0-9 keypress from a list printed on the back of the calculator and in the manual.

The two-line display in the HP-32S shows a much better way to handle this crowding: explicit front-side visible menus. The main oddity remaining here is that HP chose to repurpose the calculator’s top row of buttons so that with the MODES menu up, pressing the √𝑥 button selects the DG item, putting the calculator into “degrees” mode. While this is somewhat obscure, it is a straightforward enough hack that one may guess at how to handle the ⬇︎ indicators on the HP-32S display’s bottom line without needing to read the manual to learn the secret.

As we will see, the DM32 resolves this obscurity, but for now let us observe that the HP-32SII then took that idea and ran with it by adding a second shift button to the lone 🟧 shift sported by the HP-32S, then packed its menu-driven functionality more tightly. Whereas the HP-32S had sixteen 🟧-shifted buttons that pulled up menus, averaging 3.25 functions per, the HP-32SII pared that back to fourteen menus but increased function density to an average of 4.4 per.

The DM32 clones that behavior, but it then adds a row of doubly-unlabeled soft keys above this, having the same effect within one of the emulated menus. Other HP calculators label these F1-F6, a convention I will mimic here for lack of any other way of referring to them other than ordinally.

This brings us to one of the few design errors in the DM32. In every other device I have used with soft menu keys, they are paired with on-screen labels to show what pressing each button will do, but on the DM32, this occurs only in places where it is emulating HP-32SII menus. The thing is, these soft keys have other functions in the DM32, and these extended functions are never labeled on-screen. You have to read the manual and memorize what you can, or discover by accident what these buttons do in these situations.

While there is hope that this will be fixed in a future firmware release, the point I wish to make here is that the R47 takes the opposite tack, in spades, with bells and stars on. Many menus fit within the generous 18-item layout, but other places offer so many functions that one must either scroll the view or page through a ring of related menus.

This, then, is why I want a proper user manual for the R47 badly enough to begin writing my own. The present function indices allow a knowledgeable user to back-trace menu paths, but only when you can find out what your desired feature is called to begin with. Within a day of unboxing my R47, I found myself already unable to count the number of times I tried and failed to find a function with my first few searches of the reference PDF collection.

And yet, not once have I completely failed to find a given function. It’s always been there, somewhere.

This brings me to my first broad conclusion: the R47 is the type of tool that a professional uses with the certain foreknowledge that any limitation encountered in using it is more likely to be in the imagination or skill of the user than in the scope of capability offered by the tool. The calculator’s programmability will cover most rare exceptions, and where that runs out of steam, you have the option to modify the firmware’s source code and build what you need.

The DM32, by contrast, is a generalist’s tool: it is “enough calculator” for a good many professional use cases, but a more inherently limited one. What we gain in exchange is a tool that that is fully documented yet simultaneously straightforward in operation to the point that an experienced user will not often need to resort to that manual. This is a valuable tradeoff. If your needs fit within the DM32’s scope and are likely to remain so, it becomes difficult to recommend the R47.

Menus, Menus, Menus

And yet, the DM32 is not without flaws. I covered one biggie above, but another is that the labels on its faceplate do not call out which functions pull up a menu and which take direct effect. On the classic HP machines, these had a darker or lighter background, depending on the generation. I’ve always considered that somewhat ugly as compared to the cleaner design of the HP-20S, a lower-spec family-mate of the 32S, but I do have to concede that these shaded boxes are helpful.

The R47 solves this in a more aesthetically pleasing manner while managing to be even clearer: a gray border surrounds labels where a shifted key combo will pull up a menu.

According to the catalog, there are 140 menus defined in the current R47 firmware, giving access to roughly 1000 functions. Presuming that puts me in the right ballpark, there are ~10× as many menus averaging nearly twice the function density as on the DM32. Merely finding all that functionality is a challenge, especially given the current state of the documentation. Realize, however, that this will continue even in an indefinite future where we have ideal documentation. As a wise general once said…

Quantity is a quality all on its own.

This is one of the reasons I admired and stuck to the HP-20S for so many years, despite knowing about RPN and admiring it also: there is value in having every function of the calculator exposed on the front panel. More functionality is great, but only if you can first find it, then access it quickly enough to be worth having.

My experience of the R47 menus on this front has been mixed, so far. In several cases I have been able to puzzle out the location of an item merely by scanning faceplate labels and making educated guesses. In others, the eventual place I found a function has been a surprise, sometimes of the WTF order. An excellent example of this is the calculator’s system menu, because it hides behind the obscure acronym DMCP, after the SDK referenced above. This in turn is the first unshifted function on the first page of the 🟧 PREF menu. Only some of the items on the resulting DM Calculator Platform menu are preferences; others show information about the calculator, leading us to misremember this menu’s location as under 🟦 INFO. Others have neither to do with user preferences nor passive displays of information, and it is these which have the best reason to be on a “DMCP” menu, but then where should it be if not under PREF or INFO?

I ask rhetorically, to show the problem, not to solicit a post facto explanation.

Contrast the DM32, where essentially the same stuff is on 🟧 SETUP, a pure extension to the HP-32SII keyboard layout. This label makes sufficiently reasonable sense that one is not surprised by most of the menu’s contents. More, it’s labeled right there in bright orange, ready to be discovered.

Workarounds for the 18-Item Limit

As I understand it, the original intent going back to the WP43S forebear of the R47 was to have a 3-level menu system where the unlabeled softkeys provided by the SwissMicros hardware would pick from six menu items, much like on the HP-32S. But then atop this, the idea was that you could precede one of these presses with an 🟧 or 🟦 shift button press to select from up to twelve more functions on the two menu rows above this.

User menus on the R47 retain this 18-item limit. If you need subsequent pages, the recommended workaround is to define another menu and then chain them together by dedicating spots in the menu to related ones, ideally forming a ring.

There are places where the R47 does this with built-in menus. An excellent example is the P.FN menu on F6 in the PRGM menu, which chains to P.FN1 → P.FN2 → P.FN3 and then back around to P.FN via that same F6 keypress. While this works well, it is a notable UX departure, leading us to ask, “Why not follow the established design here?” My guess is that it is a legacy of earlier designs which may later be revisited, but I concede it might also be an intentional left-turn design for this specific use case.

The prevalent design elsewhere in the R47 is that the user can page through menus with more than 3 rows via the dedicated ⬆︎/⬇︎ buttons, allowing unlimited numbers of items.

Yet, ⬆︎/⬇︎ does not always page up/down! In a small number of menus — primarily those comprising the catalog — pressing an arrow moves the menu by a single row. What makes this even stranger is that these exceptions are the largest menus, where paging might seem most useful. My guess is that this is an intentional tradeoff made by the designers, who wanted to be able to scroll a given row to the bottom of the view to avoid the need for using the 🟧/🟦 shift buttons to select the item. These same menus are alphabetized, and pressing one of the alpha-labeled keys scrolls to that portion of the item list, offsetting the consequences of line-by-line scrolling.

State Files

Above, I made the case that the DM32 firmware is a first-party SwissMicros design. One of the better ways to demonstrate that is to show that it is not a strict emulation of the HP-32SII, prime among these being its ability to save calculator state to a file on the internal USB storage volume, then later, load it back up on demand. This supports high-level concepts like “virtual calculators,” with each statefile reconfiguring the DM32 for a specific purpose. By transferring a statefile to another DM32, you can share programs without retyping them, as the HP originals required. One may have as many statefiles as fit in the calculator’s flash space, and you can have as many loaded at once as fits into available RAM.

The R47 also has a state file concept, and it is possible that the DM32 developers got the idea from one of the R47’s ancestors, but SwissMicros improved on the concept in significant ways. An *.s47 file is technically text, but it’s an ASCII-coded binary format that is human-readable only in the most rudimentary fashion. They are meant to be read by another program, not by the human directly, and they are certainly not intended to be hand-crafted by said human.

That is not the case with a DM32 *.d32 file. The documentation does not tell how to write these by hand, and if you ask SwissMicros whether they support hand-crafting DM32 statefiles they will deny it, yet there is enough clarity in the format to allow it, without a prerequisite of exceptional brilliance. (I mean, I figured it out; QED! 🤓)

One practical benefit is that it is not difficult to load a DM32 statefile into a text editor and carve it down to include just the elements one wishes to share. When loaded, the calculator overwrites its storage with just the parts given, effectively merging the change set in atop the existing configuration. This allows one to share a single program — Example — or just a register set, or… With the R47, it’s pretty much all-or-nothing.

Another benefit is that in the DM32, the XEQ operation can take more than a label, but also the name of a statefile in which to find that label. This allows for program chaining and shared libraries, and it relaxes one of the major historical HP-32S limitations on programmability, being that LBL targets are a single letter. Does GTO P refer to the Perimeter calculation routine or to the result Printer? This remote execution capability allows you to have as many P routines as you need, each in a separate statefile, prefixed by the name of that file, allowing one to distinguish the output:P routine which Prints results from the algo:P routine which calculates Perimeters.

On one level, this merely approaches the improved LBL handling in the R47, where multi-character alpha labels allow a single program to have a LBL ‘Print’ and a LBL ‘Perim’ subroutine. At the same time, the DM32 scheme allows collecting common subroutines in a “library“ statefile that you then call into from others. One library becomes several, and now you’re approaching a modern programming system. The closest the HP-42S family comes to this is that one routine can call the global entrypoint of another to reuse it; the distinction is that they all have to be loaded into the calculator’s continuous memory for that to work. DM32 statefiles work more like shared libraries on modern OSes.

Programmability

Setting the DM32’s remote XEQ and multiple active statefile features aside, the R47 is vastly more programmable:

• Multi-character alpha labels lift the 26 subroutine limit in the HP-32S and 32SII. The DM32’s remote XEQ capability partially solves this in a different manner, but it remains true that single-letter subroutine labels reduce expressiveness.

• The HP-32S offers the same 8 hard-coded tests from its direct predecessor, the HP-11C: x<0, x>0, x≠0, x=0, x≤y, x>y, x≠y, x=y. The HP-32SII then generalized this to two sets of six, allowing comparison of x to either 0 or the y register using the basic mathematical relation operators: <, ≤, =, ≠, ≥, >. The DM32 implements this same set of 12 hard-coded tests via the same 2-menu scheme.

  The R47 takes that same general scheme and extends it further. A program can test the X register against:

  • the constants 1, 0, +0, and -0²
  • the Y, Z, or T registers
  • any predefined variable³

  These tests can use the same set of six exact relation operators as in the DM32, plus the inexact ≈.

  Setting aside the open-ended case of comparing against arbitrary variables and the useless X?X option,⁴ that comes to 37 test combinations,⁵ 25 more in the R47 than in the DM32. The added ability to compare against Z or T is helpful in practice as it avoids the need for stack shuffling to get values into Y.

  The R47 adds a further 69 special-purpose tests not involving the relation operators, if I am counting properly.⁶

• The R47 offers every HP-42S built-in operation, which was in turn a superset of the legendary HP-41 series from a programming standpoint. It then adds a pile more. The count is on the order of 1000 program-callable operations in the R47, and about a quarter that in the DM32.

• In the DM32, every LBL is globally-visible, whereas in the R47 only alpha-labeled subroutines are, allowing internal subroutines that do not pollute the global namespace. (The local label rules are complex.)

• The DM32 program editor is a vast improvement over the Voyager series: four-line display, live instruction decoding, LBL-relative line numbering… It is far easier to maintain a mental picture of the overall program through a DM32’s editor window than even the improved 2-line display of a DM15L starting from the landmark V33 firmware, much less the wholly-numeric single-line display of the true Voyagers.

  At the same time, DM32 program listings remain a flat series of instructions, without any of the visual structure the R47 editor applies. The DM32 uses the same large font as the stack display when editing programs, whereas the R47 shifts to a smaller yet readable font size, giving the programmer more context to work with. The R47 adds niceties like automatic indenting of subroutine instructions under a global label.

  Another improvement in the R47 relative to the DM32 is the EDIT function for changing an instruction in place. Replacing an instruction wholesale is less consequential on the DM32 since every program-callable function is either visible on the keyboard or can be picked from a flat set of menus with six items each, max. On the R47, you might have had to dig a given function out of a nested menu by scrolling an 18-item viewing window into a potentially much larger list of functions. The option to avoid repeating all that digging is a most welcome affordance.

I am only getting started with the R47 — and indeed with the HP-41/42 family — but I’ve been programming other machines for over 40 years, allowing me to anticipate far vaster possibilities in the R47.

Trigonometry

One of the things making me wish I had been involved at a time early enough to influence the direction of the C47 is the TRG menu. It is my belief that this has never been done better than on the HP-28S, where for one thing they found space to spell it out, TRIG. I get why the project members collectively chose to dedicate six shifted button functions the main trig functions, but if it had been me in charge, I would have followed the 28S example and put them all into a TRIG menu,⁷ arranged more along these lines:

But lo! Is that not my ideal in action? It is! By grace of the R47’s powerful custom menu system, I can have it my way.

If you agree that this is an improvement, you may install that into your own calculator:

1. Download this statefile
2. Copy it to the STATE subdirectory of the R47 while in USB drive mode (🟧 PREF ActUSB)
3. Eject the drive
4. 🟦 I/O LOADST
5. Choose wy-trig.s47
6. Put the calculator into 🟧 USER mode
7. Try it with 🟦 TRG, to which my custom TRIG menu is now bound

If you don’t like my version, you might be happier with the TRG… built-in menu, which among other things surfaces the hyperbolic trig functions. If you ASN it to the 🟦 TRG function as I have done, they end up in an easier-to-recall location than the present shortest path: 🟧 EXP.

Navigation

There’s a wry old observation that ran around Silicon Valley before the PC police stamped it out:

You can always tell the pioneers; they’re the ones with all the arrows in their backs.

In our present comparison, the Pioneers are the ones with all the arrows on the front, ha ha!

The R47 does navigation right, for the most part.⁸ It dedicates two of its precious top-level keys to up/down arrows, and it uses the six soft menu buttons to cover the horizontal dimension. Add to this the two shift keys, and you can access its many menus with reasonable ease.

Now let us observe the mess that is the DM32’s navigation scheme, where three prior designs were thrown together into a mishmash:

1. HP-32SII: This historical forebear to the DM32 offered a single method, 🟧 7/8, where HP in its wisdom tucked the down/up arrows away.

2. DMCP: Because HP’s questionable design decision requires a lot of shifts in tasks like program editing, SwissMicros programmed two of their soft buttons to give the same function without the shifts (F5/F6) but only while in PRGM mode or inside the SETUP menu. Elsewhere, these buttons change to do other things, and because they are doubly-unlabeled, one may well be uncertain what they will do instead!

3. HP-32S: In an apparent bid to merge in the historical 32S behavior, where the arrows were on a dedicated button, pressing the 🟧 key on a DM32 sometimes moves a selection point down. HP moved these arrows above the 7 and 8 keys per item #1 above, then bumped the 🟧 shift up into the space that made available, allowing the prior space to be taken over by the new 🟦 shift key.

   The DM32 creators appear to have thought, “Right, what is now the 🟧 shift used to be the arrows, and pressing this button unshifted gave the ‘down’ function, so let’s do that, merging both behaviors!” The problem that then raised is, does pressing 🟦-🟧 result in an upward movement of the selection, as 🟧 ▼ would have on an HP-32S? That breaks the historical HP behavior that pressing one shift cancels the other. What they chose instead is to make the complementary command the XEQ key, which has no faceplate label to indicate this surprising behavior.

4. Help: The DMCP help system has a further surprise: it repurposes the four basic operator keys as page up/down and line up/down, in that order, top-to-bottom. These also work in DMCP menus, but not elsewhere since they are needed to provide the labeled arithmetic functions.

This leads to poor habit-building. The user may be in the middle of editing a program, using the F5/F6 combo to avoid the hassle of the 32SII’s shifted arrow design, but then go into the Help to look something up, where F5/F6 now means something else, which is not labeled on-screen. They may become irritated enough by this to seek out another way which they can safely build a habit on and find the 32SII arrows, but on pressing 🟧 to employ them, they find the cursor immediately goes down even though this historical 32S behavior is not marked anywhere on the faceplate. 🤬

Being based on the same DMCP5 platform as the DM32, the R47 inherits the +/- behavior in the DMCP menus. There appears to be no on-board Help at this time, so I have observed no repurposing of ÷/× as page up/down. Everywhere else, the two dedicated arrow buttons rule the day. This is a significant day-to-day improvement. It is placement one can build solid muscle memory on, and when habits fail, it is immediately rediscoverable.

Diagnostics

The list of known DM32 messages is notable for being terse. Rather than make use of that 400×240 dot-matrix screen to offer more detail, they have cloned the HP-32SII messages documented in its manual’s Appendix E.

With the following wisdom in mind…

“The best way to understand a program is to look at how it fails.” — Gerald Weinberg

…I have decided to attempt triggering several of these in the R47 to get a sense of how different it is:

DM32/HP-32SII Error	R47 Behavior Under the Same Condition
DIVIDE BY 0	It answers “∞” rather than complain.
DUPLICAT. LBL	Limitation lifted9
INVALID DATA ①	Pyx complains “Out of range” when given Y=1 and X=210
INVALID DATA ②	tan(90°) yields “NaN”11
INVALID DATA ③	sin⁻¹(2) ≅ π/2 - 1.31ⅈ
INVALID DATA ④	artanh(1) = ∞; X > 1 gives a complex number
INVALID DATA ⑤	arcosh(-2) ≅ -1.317+πⅈ
INVALID x!	Complains “An argument exceeds the function domain;” vague, yet it better guides the user.
INVALID yˣ ①	Ditto when asking for 0⁰
INVALID yˣ ②	Raising a negative number to a non-integer power succeeds
INVALID yˣ ③	Raising a complex number to a number with a negative real part yields a complex number.
LOG(0)	It answers “-∞” rather than complain.12
LOG/SQRT(NEG)	It gives a complex number for an answer.
STAT ERROR ①	The n=0 case more helpfully reports “No statistic data present”
STAT ERROR ②	Asking for 🟦 PLOT 🟦 REGR x̂ with n=1 reports “Too few data points for this statistic”
STAT ERROR ③	Asking for 🟦 PLOT 🟦 REGR x̂ with n>1 but all Y=0 answers “∞” rather than complain.
STAT ERROR ④	Asking for 🟦 PLOT 🟦 REGR x̂ with n>1 but all X equal answers “NaN” rather than complain.
TOO BIG	R47 tops out at unsigned 64-bit words.13 22! in HEX mode complains “Out of range” instead.

Note especially the handling of the numbered cases. While it is impressive that the R47 disagrees that these are all a priori “invalid” or “error” cases — instead showing that most have known accepted answers — one willing to accept these cases as design limitations should at least concede that distinct errors for each case would be more helpful than tossing them all into a few oversized buckets.

The R47 runs on identical underlying hardware to the DM32, differing solely in firmware, the text printed on the outside, and the placement of the colorful shift keys. Both are based on 128-bit decimal floating-point software libraries — albeit different ones — yet the R47 shows that it is possible to lift these limitations on this hardware. Some stem from DM32 feature scope choices, most notably the treatment of complex numbers as a bolted-on side-car feature rather than being accepted everywhere as input and generated as output wherever needed. Yet, we cannot help but note that the DM32 did raise the range of values it can handle over the HP-32SII; reporting infinities rather than errors would be no more of a departure from historical design limitations than changing from 15-digit BCD to 34-digit decimal FP.

This demonstrates the value of striking out in a new direction versus cloning a preexisting design right down to its limitations.

Future Directions

I intend to give deeper examples comparing and contrasting the operation of these two calculators here, but for now, I bid you adeiu.

(You may now wish to return to my R47 article index.)

License

This work is © 2025 by Warren Young and is licensed under CC BY-NC-SA 4.0

---

1. ^{^} I believe that honor goes to the HP-18C, off on a parallel development track.
2. ^{^} One nearly always wants the generic 0 in tests. The signed zero values are for special-case handling of the underlying computer math.
3. ^{^} This is primarily a matter of convenience, but it can be of practical import as it avoids burning a stack slot on a RCL to pull a variable’s value into X and then use one of the DM32’s hard-coded x?y comparisons against the former X now up in Y.
4. ^{^} I can see no good use for a test like X≠X, but the R47 allows it, presumably for completeness, not utility.
5. ^{^} Seven relation operators times five predefined referents not counting X itself, plus the ±0 special cases.
6. ^{^} grep -F '?"' ~/src/c47/src/c47/items.c | wc -l to get a raw count of functions ending in a question mark, then repeat without the | wc -l bit and subtract false matches and those previously counted.
7. ^{^} …and then fixed some of the other problems noted in this review by making use of the space freed up. First task, bring back the DM32/DM42 SETUP function!
8. ^{^} There appear to be remnants of historical designs in the firmware I have running here, 0.109.02.07b12. See for instance the 🟦 P.FN menu, where repeatedly hitting F6 cycles through all three pages of the menu. This is inconsistent with the rest of the menu design, where you would need to use the up/down arrows instead, and further menu pages would be indicated by wee arrows above the upper left corner of the third menu row.
9. ^{^} The historical HP behavior for this condition — as in the HP-11C — was that duplicates were allowed, and a GTO/XEQ simply searched forward (with wraparound) until it found the first match. It is not considered good style to rely on this, but why break old programs?
10. ^{^} This uses only about ¼ the screen width, making us wish for a more detailed diagnostic while acknowledging that what we do get is at least somewhat less generic.
11. ^{^} Contrast tan(π/2) where the inexact parameter results in a very large negative number on the order of e-33 with both machines.
12. ^{^} This DM32 diagnostic is especially notable since the input expression is given as explanation for its failure to report an answer, implying that the error is in the asking, when it is in fact reflecting a design limitation. A more honest diagnostic would be, “Sorry boss, I can’t do that.”
13. ^{^} The DM32 limit for non-decimal bases is fixed at 2’s complement signed 36-bit. Why not 32-bit? Because the Saturn CPU underlying the HP-32SII is a nibble-based architecture, and there is no feature for controlling signedness. Therefore, to cover the common unsigned 32-bit case while interpreting everything as signed otherwise, HP had to step up to the next nibble. It is worth noting that 36 is conveniently three times the 12-digit display limitation, allowing a left-center-right arrangement in its “windowed” display for large binary values.