RPN nixie calculator with scientific notation

[newxito]

It still has the same number of nixies as the non-RPN version but an additional horizontal neon for the exponent sign. By keeping the 14 nixies, it was possible to maintain all the clock modes and implement a dynamic exponent range. The keyboard has now 5 additional keys and the functionality was extended from 15 to 33 operations.

Switching to arbitrary-precision arithmetic was a failure. It worked but was too slow for a few special cases of pow and non-integer factorials (gamma approximation). I will give it another try, but for now I’m back to 64-bit floating-point.

[Nick]

Very nice

[Tom Nolan]

That is really excellent work!  HP calculator functionality is the way to go.

Tom

On Mon, Mar 17, 2025 at 6:09 AM newxito <axt...@gmail.com> wrote:

It still has the same number of nixies as the non-RPN version but an additional horizontal neon for the exponent sign. By keeping the 14 nixies, it was possible to maintain all the clock modes and implement a dynamic exponent range. The keyboard has now 5 additional keys and the functionality was extended from 15 to 33 operations.

Switching to arbitrary-precision arithmetic was a failure. It worked but was too slow for a few special cases of pow and non-integer factorials (gamma approximation). I will give it another try, but for now I’m back to 64-bit floating-point.

--
You received this message because you are subscribed to the Google Groups "neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to neonixie-l+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/neonixie-l/1290e008-6759-485a-8b7d-0cf74a8787bdn%40googlegroups.com.

[liam bartosiewicz]

That looks awesome! Any possibility of making it a kit? Would be great to have on a desk at work.

On Mar 17, 2025, at 3:09 AM, newxito <axt...@gmail.com> wrote:

It still has the same number of nixies as the non-RPN version but an additional horizontal neon for the exponent sign. By keeping the 14 nixies, it was possible to maintain all the clock modes and implement a dynamic exponent range. The keyboard has now 5 additional keys and the functionality was extended from 15 to 33 operations.

Switching to arbitrary-precision arithmetic was a failure. It worked but was too slow for a few special cases of pow and non-integer factorials (gamma approximation). I will give it another try, but for now I’m back to 64-bit floating-point.

--
You received this message because you are subscribed to the Google Groups "neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to neonixie-l+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/neonixie-l/1290e008-6759-485a-8b7d-0cf74a8787bdn%40googlegroups.com.

<rpn.jpg>

[Mac Doktor]

On Mar 17, 2025, at 6:09 AM, newxito <axt...@gmail.com> wrote:

It still has the same number of nixies as the non-RPN version but an additional horizontal neon for the exponent sign. By keeping the 14 nixies, it was possible to maintain all the clock modes and implement a dynamic exponent range. The keyboard has now 5 additional keys and the functionality was extended from 15 to 33 operations.

This looks fantastic but I can't afford the tubes. OTOH, if my HP35s dies a replacement will cost a significant chunk of it.

Switching to arbitrary-precision arithmetic was a failure. It worked but was too slow for a few special cases of pow and non-integer factorials (gamma approximation). I will give it another try, but for now I’m back to 64-bit floating-point.

I don't need anything that sophisticated but whatever works.

Terry Bowman, KA4HJH
"The Mac Doctor"

https://www.astarcloseup.com

"Would you like to see the relevant data?"—343 Guilty Spark, Halo 2

[Nicholas Stock]

Terry, that's less than $100 for all those IN-17 tubes, even at current prices.

https://www.ebay.com/itm/267171764109 (not my auction, but I have purchased other things from this seller, can recommend).

--
You received this message because you are subscribed to the Google Groups "neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to neonixie-l+...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/neonixie-l/4BC359C0-2CA3-41E1-AE99-F2663F88D6F4%40gmail.com.

[Mac Doktor]

On Mar 17, 2025, at 4:51 PM, Nicholas Stock <nick...@gmail.com> wrote:

Terry, that's less than $100 for all those IN-17 tubes, even at current prices

I haven't been following the prices so this is good news. People are asking $200 for a new 35s.

Terry Bowman, KA4HJH
"The Mac Doctor"

https://www.astarcloseup.com

"Every kid starts out as a natural-born scientist, and then we beat it out of them. A few trickle through the system with their wonder and enthusiasm for science intact."—Carl Sagan, Psychology Today, 1996

[Dekatron42]

Very nice!

I'd love to see a ZM1200 Pandicon version!

Here's and old one: https://www.sm5cbw.se/sm5cbw/calculator.htm

/Martin

[newxito]

Sorry, no kit but I will upload all the files to github. I'm currrently working on other projects, so I will need some time. 

I also want to rewrite the calc engine because today,  after making some code changes in Microsoft's ratpak, I was able to compile the lib for an ESP32.. The (excellent) Windows 11 calculator is based on ratpak. It's code from the 1990s licensed under the MIT license. Initial tests are very promising. 

You may think that this is overkill but small inaccuracies in the calculations drive me crazy. 

For example:  1.0000000000001 ^ 999 

Using the C/C++ pow function or Excel you will get 1.00000000009982

WolframAlpha and the Windows calculator both return 1.00000000009990

[Grahame Marsh]

In Chapter 2 of his book "Astronomical Algorithms" Jean Meeus looks at computer accuracy.

A quick test of trig functions is to use 4*ATAN(1) which should return PI.

To look at rounding errors he starts with 1/3 or 0.33333... recurring. Using the equation

X = ( 9 * X + 1) * X  - 1

and starting with X = 1 / 3 and then repeatedly calculating the rounding errors accumulate and X diverges from a perfect 1 / 3

On an ESP32 (in C using framework 5.3.1) in double precision floats you see

1. Rounding Errors X = 1/3 then X = (9 * X + 1) * X - 1
        1  0.333333333333
        2  0.333333333333
        3  0.333333333333
        4  0.333333333333
        5  0.333333333333
        6  0.333333333332
        7  0.333333333325
        8  0.333333333272
        9  0.333333332907
        10  0.333333330347
        11  0.333333312426
        12  0.333333186982
        13  0.333332308873
        14  0.333326162117
        15  0.333283135282
        16  0.332981969654
        17  0.330874898687
        18  0.316178685916
        19  0.215899338763
        20  -0.364587940932

Another test he tries is to take 1.0000001 and square it 27 times. This should give 674530.4707 to 10 sig figs. The ESP32 (double precision floats) gives 674530.4755. (My desk TI-60 pocket calculator gives 674530.318).

For your amusement, in ESP32 single precision for these two tests you get

        1  0.333333
        2  0.333334
        3  0.333337
        4  0.333357
        5  0.333500
        6  0.334502
        7  0.341528
        8  0.391304
        9  0.769372
        10  5.096765
        11  237.889893
        12  509561.312500
        13  2336875085824.
        14  49148868497321186346139648.
        15  inf

And 8850397.000

Jean Meeus then looks at some other tests showing how the order that calculations are made can effect the result and other demonstrations of rounding errors leading to completely erroneous results. Ok the book is dated from 1998 and last printed in 2015 and he using, inter alia, an HP85 and QuickBASIC 4.5 to demonstrate, but I find it is still interesting to try his examples.

Grahame

To view this discussion, visit https://groups.google.com/d/msgid/neonixie-l/f2670f05-34e2-4789-8ae8-ed5fec66b3ffn%40googlegroups.com.

[newxito]

Very interesting, Grahame! That confirms that using 64-bit floating point numbers for a calculator is not a good idea and std::float128_t is not implemented for the ESP32. 

I also had a look at CORDIC but I think that now I have the right solution. I had to make some changes but it seems that this Microsoft "rat thing" (rational package) is small and efficient enough to run on a ESP32. It must be used with caution as it is a minefield for memory leaks.

Here is the code for the square test (still learning how to use the lib):

#include <Arduino.h>

#include <iostream>

#include "ratpak.h"

#define RAT_RADIX 10

#define RAT_PRECISION 32

void setup()

{

  Serial.begin(115200);

  ChangeConstants(RAT_RADIX, RAT_PRECISION);

  //std::cout << esp_get_free_heap_size() << std::endl;

  PRAT a, b;

  PNUMBER an;

  std::string_view asw("1.0000001");

  an = StringToNumber(asw, RAT_RADIX, RAT_PRECISION);

  a = numtorat(an, RAT_RADIX);

  b = i32torat(2);

  for (int i = 0; i < 27; i++)

  {

    try

    {

      powrat(&a, b, RAT_RADIX, RAT_PRECISION);

      std::cout << RatToString(a, NumberFormat::Float, RAT_RADIX, RAT_PRECISION) << std::endl;

    }

    catch (uint32_t error)

    {

      std::cout << "Error: " << error << std::endl;

    }

  }

  destroyrat(a);

  destroyrat(b);

  destroynum(an);

}

And that's the output with the expected end result:

1.00000020000001
1.0000004000000600000040000001
1.000000800000280000056000007
1.000001600001200000560000182
1.000003200004960004960003596002
1.0000064000201600416640635376762
1.0000128000812803413770668026457
1.0000256003264027635374793520959
1.0000512013081822390029905871794
1.0001024052379384375785958510379
1.0002048209627096323852068743694
1.0004096838770460300710338611701
1.0008195355949711716087526439342
1.00163974282853376796974474111
1.0032821744136112638614741772487
1.006575121496103892166729172383
1.0131934752148963118187118095542
1.0265610182180387069187488015248
1.0538275241248563979233697036739
1.110552450603124793373875993221
1.2333267455406059342379630169179
1.5210948612657825396950367423048
2.3137295769691702316179381502588
5.3533445553419354350856785986392
28.658297928209144424271866810778
821.2980401419965396255701284542
674530.4707410845593826891780296

[Grahame Marsh]

That's bang on the money!

I've made a note that I need to read up on ratpak when I get back to
astronomical calculations in my next scope clock project.

I found Meeus online

https://auass.com/wp-content/uploads/2021/01/Astronomical-Algorithms.pdf

and chapter 2 is of interest.

Grahame

[newxito]

...compile the lib for an ESP32.. The (excellent) Windows 11 calculator is based...

OK, I take that back, the Windows calculator isn't that great. 

Just type in 45 tan log   

Instead of 0, you'll get a wild result. Another example is √2.25  - 1.5
In addition to these precision and rounding issues, I also had to fix some bugs and memory leaks in ratpak. Each non-integer big factorial calculation consumed about 600 bytes of the ESP32's memory. This might not be important if you deal with gigabytes of RAM on Windows, but with a MC, every kilobyte counts. With the latest firmware, the memory now finally seems to remain stable and 45 [tan] [log] works as expected...

[newxito]

I finally added a WebSocket server to show the internal registers on a smartphone or pc. Pressing [F][ENT] starts and stops an access point and the server. You can then connect to the AP and open the page in a browser. After a calculation, the registers are sent directly to the browser, no polling or browser refresh is needed. I had the idea to also send the operations over the WebSocket to show the history but I will not implement that. This smartphone thing is just a gimmick anyway. The use of the WiFi and ESPAsyncWebServer libraries is very resource intensive, so if you don't use this feature, you can remove them from the code with a #define change.

Additionally, I've implemented result scrolling. By pressing [F][.] all available digits (up to 32) are scrolled on the nixie display.

By the way, the number shown on the picture is the result of

[newxito]

:-) ... result of 

[newxito]

I finally got my ESP32-C5 dev kit. For those of you using ESP32 modules, here is the result of a little performance test limited to a very specific task, but which could still tell something about the speed of the modules.

The test calculates the square root of 9e9999 with a precision of 32 digits with the ratpak lib.

Compiler settings: optimized for performance, assertion level disabled.

ESP32    -> 6450 milliseconds

ESP32-C6 -> 4704 milliseconds

ESP32-S3 -> 4425 milliseconds

ESP32-C5 -> 2840 milliseconds

Since I need the highest single core performance for the calculations, I look forward to adapting my boards for the C5 WROOM once it becomes generally available.

[newxito]

In my defense, it was not my idea. But I had fun building this thing, and I must admit that the red 7-seg LEDs look very nice…