An "Open" letter to "DIY" and "Repurposed" calculator projects

[Ethan Conner]

All puns intended. :) Just my two cents here feel free to chime in. As a potential customer for these projects some things i like or don't like about what is out there so far. First i would be willing to layout a couple hundred dollars for a low production custom calc. Second it has to exist in a completed physical form. Not interested in pictures of potential products. It also must have a base scientific configuration for the keyboard and firmware. I don't want to have to buy a new faceplate, stickers or overlays every six weeks. Also don't want to have to reflash it that often either. Third i don't want a "minivan" that's been turned into a "sports car". It's an impressive feat but it's still just a hopped up "minivan". Not to mention that even the brainiacs in this group have trouble with it which doesn't bode well for an average joe like me. Nail down your physical form and firmware and put it up for sale. These are all impressive efforts and i wish everyone of you the best.

[Manolo Sobrino]

I miss a calculator that could interact with the calculations in your computer seamlessly. For instance, copy/paste data/formulae, and some sort of session sharing, kind of mathematica notebook idea. An easy cross-compiling procedure in C would come in handy too.

The point of calculators is specificity for the task and keyboard convenience (used to be mobility, but smartphones and tablets are here to stay). There are much more powerful (and sometimes even cheaper) platforms for scientific computing. It makes little sense to dedicate a lot of work just to improve the things that something else will do better, ignoring the real strengths. Unless it's just for fun...

[Marcus von Cube, Germany]

Pun intended? I get the message. :-)

A 30b with custom WP 34S faceplate and keys is on my wish list but who will produce it for us? Frequent re-flashing is just a consequence of our inability to fix all bugs once and for all. And as long we find some more flash space we will add features. ;-)

[Oliver Unter Ecker]

A calc written in an interpreted language, can be updated without re-flashing. If it has WiFi (or Bluetooth) this can even be done over the air, and it can be a matter of pressing one button.

Edited: 20 Oct 2011, 6:58 p.m.

[Marcus von Cube, Germany]

The 20b/30b platform lacks the necessary resources. :-(

[David Hayden]

Quote:

---

A calc written in an interpreted language, can be updated without re-flashing.

---

Are you sure? It seems to me that if you need to change the calculator software, you need to reflash it, regardless of the language that the software is written in.

If I'm missing something, can you explain how this would work?

Dave

[Oliver Unter Ecker]

Quote:

---

If I'm missing something, can you explain how this would work?

---

Certainly.

The only calc I know that implements what I'm referring to is my own, so forgive me for illustrating the point with an ND1 example:

Say ND1 had no "SINH" function, or there would be an error in its implementation.

At run-time, a user can type this code

calculator.functions["SINH"] = function(x) { return (Math.exp(x)-Math.exp(-x))/2; };

in an "Injection" text editor and save it. Subsequently, the calculator will have a system-wide "SINH" function. It will be available in normal RPN operation and in RPL programming, and it will be indistinguishable from a built-in function.

This works because (most) interpreted languages allow you to evaluate code written in their own language. It's as if C could compile C code and dynamically bind to the compiled result.

Sometimes this is used with another language feature called "introspection" that let's you discover what properties are presently associated with an object.

Besides this enabling cool things such as updating your calc (entirely, or partially) by simply re-evaluating some code, it's really simple and elegant to code. No object IDs, method IDs, RTTI stuff as in statically compiled languages.

You can find more info about how this works in ND1 here. The same general idea would work and be supported by pretty much any interpreted language.

If you think interpreted performance sucks, know that modern implementations use JIT compilers and can achieve pretty high speeds. For JavaScript, it's currently a factor ~10x slower than C. The gap is shrinking and one could argue that performance isn't of paramount importance in a calculator.

It's not slow. I'm getting a factor 10x-100x faster RPL performance on ND1 in comparison to a 50g. And ~20x as much speed on top of that for code written in JavaScript, which, as "run-time environment", becomes the rough equivalent of SysRPL.

See the Benchmarks section at the end of this, which also lists a few HPGCC results.

[EDIT: Forgot to mention: ND1 has a "Restore Calculator" button that will fetch key definitions and any injection code from a server and re-create the calculator. This can be used to deliver a full update, fixes, new functionality, new key definitions, new menus. The process takes a second or two.]

Edited: 21 Oct 2011, 10:41 a.m.

[uhmgawa]

Quote:

---

[EDIT: Forgot to mention: ND1 has a "Restore Calculator" button that will fetch key definitions and any injection code from a server and re-create the calculator. This can be used to deliver a full update, fixes, new functionality, new key definitions, new menus. The process takes a second or two.]

---

Which is functionally equivalent to "reflashing" irrespective
of the interconnect method or whether the downloaded bits are
persistent.

Upon further thought, having a pocket calculator of necessity
tethered to a server wouldn't be my first choice. I'd agree
the feature is no doubt convenient in some scenarios but in my
usage I fundamentally expect an autonomous device.

[Oliver Unter Ecker]

Hmm. Not sure why you say that. The equivalent to reflashing would be an ordinary software update, which re-installs the binary and all resources.

The mentioned method provides a dynamic "overwrite" over unchanged code. It's not the in-place replacement that "flashing" is.

The point is, it's relatively painless to do as the binary remains the same. To fix one function you just need to communicate the source code for that function. There's no compiling, linking.
It takes one second to do versus fiddling with cables and computer connections, download of code to said computer, rebooting of the device, etc.

Of course, the calculator doesn't need to be "tethered to a server".
The calc is stand-alone. If you want an update, you wander to a WiFi net and push that button.

Not mentioned before but probably obvious: networking allows you store your data and download shared data as well. Someone wrote a new set of Special functions, click on their shared folder and have it installed in your calculator a second later.

Want to work on code on both your computer and your calc? Or need that big matrix transferred from your computer? Click a button, or use an "overloaded" VISIT key that connects to your computer, retrieves the code, stores it in a local variable, and displays it in your device's editor.

Or just use your calc stand-alone and backup your data from time to time.

I think lack of networking was one of the main reasons that made people turn away from island high-end calcs.

Edited: 21 Oct 2011, 11:39 a.m.

[uhmgawa]

Quote:

---

Hmm. Not sure why you say that. The equivalent to reflashing would be an ordinary software update, which re-installs the binary and all resources.

---

Not necessarily but that's certainly been the traditional
connotation. It is possible to update persistent device storage
on a per-byte basis if needed. The choice of whether doing so
replaces the entire application image or merely
adds/modifies/deletes
function entries in a dictionary of primitive operations, is
essentially an implementation detail.

Quote:

---

I think lack of networking was one of the main reasons that made people turn away from island high-end calcs.

---

I agree any calculator of the capability being discussed
here should never be conceived without a
bidirectional, user accessible interconnect between it and
the outside world.

[Paul Dale]

Just thought I'd note that (e^x - e^-x) / 2 is not a good implementation of SINH. Think about what happens as x approaches 0.

- Pauli

[Oliver Unter Ecker]

Thanks for your note, Pauli.

Are you suggesting to use (e^x - 1/e^x)/2 instead, for higher accuracy?

If so, I'm actually getting slightly lower accuracy from that (tried x=0.00001). I must be missing something. Can you enlighten me?

[Paul Dale]

Nope, that has the same problems for x almost equal to 0.

There are a number of alternative encodings for this function. Most use the EXPM1 function (i.e. e^x-1).

e.g. the HP-41 maths module uses:

	( (ex-1) / ex + (ex-1) ) / 2

The 34S uses something a bit more complicated:

if (|x| < 0.5)

	t = ex-1

	sinh = t / 2 / (t+1) * (t+2) 

else

	sinh = (ex - e-x) / 2

- Pauli

[Oliver Unter Ecker]

Nice.

Thanks, Pauli! I shall consider which to adopt.

[Paul Dale]

Be very very careful implementing numeric functions.
The obvious formulas are often poor. I'd suggest looking up pretty much any of William Kahan's writings on numerical analysis.

Also don't implement e^x-1 the obvious way, it will produce very poor results for x close to zero and the whole purpose of this function is to produce good results there. This is the way the 34S does it:

        u = ex

        if (u == 1)

            expm1 = x

        else if ( (u-1) == -1 )

            expm1 = -1

        else

            expm1 = (u-1) * x / ln(u)

Also beware of aggressive optimising compilers and compilers that produce code that uses varying lengths of reals. Both are very bad for numeric computations.

- Pauli

[Marcus von Cube, Germany]

Pauli, wouldn't it be easier to compute e^x-1 by summing up the series for e^x without the constant term?

[Paul Dale]

Possibly -- I suspect that unless you sum the series backwards, you'll encounter rounding issues in the low digit or three. Also, the Maclaurin series expansion converges very slowly for |x| large.

We've already got e^x as part of the decNumber library & it doesn't appear to be summing this series at all.

I see no point including a second function of similar size needlessly, especially when I can produce accurate results for e^x-1 from e^x quite easily.

- Pauli

[Marcus von Cube, Germany]

Pauli, I didn't know we are using EXP from the library. But it might still be easier to modify this code to subtract the 1 early in the process. Using LN seems to be expensive.

[Paul Dale]

Yes, Ln is expensive. Always better expensive than wrong.

The decNumber exp() function actually does do the Maclaurin series expansion on a range reduced argument so this approach might be possible. It wouldn't be trivial, this function is quite complex and the accuracy guarantees it assumes won't hold if we make this change.

Definitely more thought will be required before jumping into this change.

- Pauli

[Oliver Unter Ecker]

Oh, I love that one, thank you, Pauli!

I got the point of this function, but hadn't quickly turned up an implementation, so did it the obvious way and kept the bad feeling of knowing this was defeating the point. So, thanks for the relief!

Got the LNP1 code up?

I appreciate your comments about numerical analysis in general and will dig into the oft-cited pointer you gave. My focus has been on features and completeness before best numerical performance, which simply isn't my thing. This sure could use someone else's oversight.

A few days ago, I discovered the hard way that

3600 * (x - y)

loses accuracy in comparison to

3600 * x - 3600 * y

C'mon, IEEE 754! ;-)

Edited: 22 Oct 2011, 6:14 a.m.

[Paul Dale]

Quote:

---

Got the LNP1 code up?

---

Try sourceforge -- all the 34S sources are there :) This one needs special attention to get correct -- the 34S implementation relies on the compiler not rearranging the order of expressions. Specifically the (x+1)-1 equal to zero test must not be optimised to just test x equal to zero.

Quote:

---

I appreciate your comments about numerical analysis in general and will dig into the oft-cited pointer you gave. My focus has been on features and completeness before best numerical performance, which simply isn't my thing.

---

For a calculator, the numerical accuracy and stability have to be paramount. Getting the wrong answer isn't at all helpful. This has been my goal for the 34S -- while I cannot guarantee correctly rounded for all function results since that simply isn't possible with finite precision arithmetic, I would like all functions to be accurate to plus or minus one in the final digit. At present I'm not aware of any cases when an incorrectly rounded result is produced but I'm sure some exist.

Quote:

---

A few days ago, I discovered the hard way that

3600 * (x - y)

loses accuracy in comparison to

3600 * x - 3600 * y

---

This doesn't make sense, at least at first glance (although more than that is often required in this area of mathematics). Floating point multiplication isn't associative with addition but I wouldn't expect there to be a large difference especially when multiplying by 3600 which is a fairly small integer all things considered. For x & y normalised reals, x-y can be represented exactly -- this is the entire purpose of subnormal numbers. So there shouldn't be a large difference between the two -- rounding can & will introduce a difference but it shouldn't be large for doubles.

Given the 3600 looks like a time based calculation, I suspect you're being tripped up by binary floating point numbers not being able to exactly represent what are otherwise simple decimals. Just a guess though and no real basis for it. However, if this is true you'll have to manually introduce rounding to fix the results up. The 34S code base won't help here since it uses decimal arithmetic which avoids some of these problems. The Free 42 code has addressed this I believe.

- Pauli

[Oliver Unter Ecker]

Thanks, Pauli. I have another reason to look at your surely excellent code base. Wish time was more abundant.

Quote:

---

For a calculator, the numerical accuracy and stability have to be paramount.

---

While I do agree in principle, for my calculator user programmability and writing larger programs was a goal, where better numerical results than those commonly obtained from regular programming languages would be a nice-to-have, but not a must. Specifically, if speed were to suffer a lot, I'd stick to what a standard lib spits out. (I'm still special-casing periods of half pi in sin(), etc.)

Being within one ULP is nice but, as you know, breaks down anyway when errors from multiple computations accumulate.

I sometimes wish I had decNumber, but most of the time IEEE-754 and the regular math lib beat the accuracy out of a 50g, which has been my threshold target to not underperform.

Quote:

---

I suspect you're being tripped up by binary floating point numbers not being able to exactly represent...

---

It's the difference of two correctly represented numbers not being correctly represented in IEEE-754:

2.2-2 = 0.20000000000000018

Hence the greater error when multiplying this.

I'm probably not expressing myself correctly when I say the accuracy is lessened. I should probably say it's stochastically lessened, as for cases where the difference is correctly represented, the result is the same.

At any rate, the fix was to manually round, as you suggest.

Again, decNumber would be nice but I want speed, too.
I'm planning to provide a BCD data type at some point in the future, and give users the choice over which tradeoff to make.

Edited: 22 Oct 2011, 7:41 a.m.

[Paul Dale]

Quote:

---

It's the difference of two correctly represented numbers not being correctly represented in IEEE-754:

2.2-2 = 0.20000000000000018

---

That's what I thought. You'll likely find that the two different expressions 3600 (x-y) vs 3600 x - 3600 y will both seem better at times depending on the input values.

I also shouldn't have written exactly for the result of the difference of two normalised numbers. Correctly is better, digit loss is always possible and thus exact isn't true.

Quote:

---

Again, decNumber would be nice but I want speed, too.
I'm planning to provide a BCD data type at some point in the future, and give users the choice over which tradeoff to make.

---

IEEE 754 supports decimal arithmetic now -- convince your language provider to support it too :-)

- Pauli

[Paul Dale]

For those interested in learning more about this kind of thing and who have digested all of Kahan's documents which I referenced above. The following books are good sleection:

• The Algebraic Eigenvalue Problem by J. H. Wilkinson -- very in-depth and a great introduction to error analysis from when it was being invented.

• Elementary Functions by Jean-Michel Muller -- a good reference on how to implement functions in many different ways. This one covers many/all of the standard algorithms -- CORDIC, series expansions, partial fractions, polynomial approximations.

• Accuracy and Stability of Numerical Algorithms by Nicholas J. Higgam -- another great book on error anlysis.

• Matrix Computations by Gene H. Golub and Charles F. Van Loan -- pretty much what it says but one of the canonical texts in numerical analysis.

• Handbook of Mathematical Functions by Abramowitz & Stegun -- A&S is the bible for mathematical and physical functions.

• NIST Handbook of Mathematical Functions -- an updated version of A&S although the overlap is deliberately kept low.

• An Atlas of Functions by Oldham, Myland & Spanier -- lots of functions and their properties. Not really essential if you have A&S but easier reading.

• Numerical Recipes by Press, Teukolsky, Vetterling and Flannery -- doesn't get good comments from numerical analysis circles but it is easy to read and contains code that can be used with sufficient care and attention to detail.
  

Be prepared to pay anything from $500 - $1k for these. And yes, I've bought hard copies of all of these and more since starting the 34S project.

- Pauli

Edit: Fixed the author's name on the first book as mentioned below.

Edited: 27 Oct 2011, 6:54 a.m. after one or more responses were posted

[Oliver Unter Ecker]

Very impressive.

Have you guys thought of making an app, charge a few dollars, and at least recoup some of what you put into this project?

I'm willing to share with you my experience in the app store.

[Paul Dale]

Quote:

---

Have you guys thought of making an app, charge a few dollars, and at least recoup some of what you put into this project?

---

We hadn't that I'm aware of.

Given the far less tight resources of such an app, we'd implement a lot of things quite differently.

- Pauli

Edited: 22 Oct 2011, 6:59 a.m.

[Oliver Unter Ecker]

Quote:

---

Given the far less tight resources of such an app, we'd implement a lot of things quite differently.

---

Sure, and maybe that would make things even more fun.

I trust WP34S, as is, would shine already.

There's an intimidating number of RPN apps out there, but only a handful comparable ones, I think.

You would be reaching a far greater number of users. (Though the average user will be far less engaged/supportive than the crowd here.) Esp. if you make it free.

[Rodger Rosenbaum]

Quote:

---

For those interested in learning more about this kind of thing and who have digested all of Kahan's documents which I referenced above. The following books are good sleection:

The Algebraic Eigenvalue Problem by W. H. Wilkinson -- very indepth and a great introduction to error analysis from when it was being invented.

- Pauli

---

It's J. H. Wilkinson, not W. H. Wilkinson. :-(

I would recommend buying and reading:

Rounding Errors in Algebraic Processes by J. H. Wilkinson

before wading into The Algebraic Eigenvalue Problem

That way your brain gets used to deep water a little at a time. :-)

[Paul Dale]

Sorry about that. I was typing in semi-dark from the pile of books in front of me.

Sink or swim -- jump into the the The Algebraic Eigenvalue Problem :-) Actually, don't. It is very heavy going.

- Pauli

[Patrice]

Wait for the final release of the 34S, wait a year after last bug fix, and can flash it only once, and have only one keyboard layout.

The down thing is that you will start to play with it in 3-4 years :)

Patrice

[uhmgawa]

Quote:

---

I don't want to have to buy a new faceplate, stickers or overlays every six weeks. Also don't want to have to reflash it that often either.

---

Simple solution. Obtain a calculator supported by a less
responsive, proactive, and enthusiastic development team.

[Ethan Conner]

I'm not throwing my money at a moving target no matter how well it is supported. It is a very impressive effort and those involved should be proud of what has and will be accomplished. I'm dearly hoping that one of these projects will be internally and externally polished.

[Paul Dale]

Each to their own of course.

Without people willing to jump in and use the device and report issues and problems, the device will never be polished.

- Pauli

[Walter B]

C2H6,

Quote:

---

I'm not throwing my money at a moving target

---

Nobody forces you to do so. Just stay firm, watch the news passing by, and wait until there are no news anymore. Then put your money wherever you prefer if it will be available still ;-) MMV

[Ethan Conner]

Don't worry i'm not sweatin' it. :) I watched a video of DIY from HHC that looks pretty good and the open guy has enthusiasm for a complete product. And if none of them mature there's still the hp50g. :)

[Jake Schwartz]

Quote:

---

Don't worry i'm not sweatin' it. :)

---

/<rant on>
This whole thread has me scratching my head, as I'm not sure its purpose. Looking back at HP calculators all the way to the HP35 in 1972, no matter how long the R&D people sweat over a product, I don't think they could ever produce a completely bug-free item. If you are waiting for one, you might as well keep waiting for the "train that will never arrive". If there is no respect for those who "put it out there" for the community to enthusiastically exercise so issues may be reported and they may be repaired in a timely fashion, then what's the point? It is obvious that we ALL would love to purchase completely finished, polished, clean, bug-free boxes which suit our every need and fit nicely in our budgets, but that is a pipe dream. Instead of us all complaining that what's out there isn't good enough for us, the community is pitching in to help improve things.
/<rant off>

Jake

[Ethan Conner]

Sorry if i wasn't entirely clear. My point was exactly that at some time you have to nail the whole thing down and say it is what it is. I have an R&D background in aviation and have seen a few good projects die because they suffered from "terminal developement-itis". This is why companies hire non-tech managers and accountants. Somebody has to step in and enforce a goal of product capability and time deadline. It has been my experience that a project with no deadline never matures or reaches a completion point because things happen so fast in technology these days that there is always some new material,code etcetera than what you just incotporated 6 months ago into the design. I have seen multi-million dollar contracts cancelled because the customer wouldn't let up on the feature creap. Please let me say as i have said before i think all three of the efforts are admirable and the people involved should be proud of what they have accomplished. :) I just don't want a calculator that i have to put stickers on and overlays or sleeves because it never achieves a base configuration on the interface. (case and keys and display) If none of these projects ever gets completed i'm ok with that, there are still big companies who make high end calculators. I'm just a potential customer stating what i desire. A finished non patched up calculator.

[Marcus von Cube, Germany]

Ethan, shop here! :-)

[Ethan Conner]

ROFL!!! Actually i love engineers more than bean counters. :)

[uhmgawa]

Quote:

---

Sorry if i wasn't entirely clear. My point was exactly that at some time you have to nail the whole thing down and say it is what it is.. Somebody has to step in and enforce a goal of product capability and time deadline.

---

All very true in a commercial context. But IME the primary
motivation here is really not that of commercial revenue, at
least I'd hazard that's the case for most folks.

Rather it is the compelling engineering challenge of leveraging
available technology to produce something superior to
commercial counterparts catering to the bottom of the pyramid
in their respective markets.
Here "superior" will be defined by whoever has picked up the
development gauntlet and is doing the measurement.
While no one likely would be opposed to achieving commercial
success, it isn't the actual driving force.
A loose corollary might be most involved in such projects
would not have the same degree of commitment and passion if this
work was actually their 40h/wk job, simply due to the concessions
needed in commercializing the associated technology you've
cited above.

So IMHO attempting to push open collaborative efforts into a
commercial model, a model which by its existence fosters the
existence of open development counterparts, may well work
to extinguish them.

My experience and subjective views. I'm certain you'll find
others who fall elsewhere in the spectrum.

[Ethan Conner]

Yes if the goal is unlimited development then so be it. Truly there is nothing wrong with that. However there have been in the past decade some other highly developed projects that have succeeded in a constant state of flux while providing a stable hardware platform and code which to work with. The parallax basic stamp and arduino being a couple of examples. I certainly would not want anyone in the repurposed side feel slighted. It would just be a desire of mine to have anyone or all to be successful. Look how everyone frothed at the mouth over the 15c le. It is a perfect example of what this community is willing to go for when presented with an oppurtinity to open their wallets for a stable platform.