Calculator but not HP


Interesting idea.

- Pauli

Edited: 18 Apr 2012, 5:02 a.m. after one or more responses were posted


Thanks for sharing that link. Interesting LCD as well :-)


Interesting indeed. Oh, I think I see something...Yup! The HP-35 carryover, an x^y function key. Perhaps unintentional but very clever.


On Casio calculators, the X and y registers are reverse of RPN: in other words for 2 number functions, you type into the buffer, then hit a function key, which bumps that number into the X register, and then you type the second number (e.g. the exponent) into the buffer which is also the y register (the actual mechanics of parsing etc I don't know how they do that )


This reminds me on our solver which only reliably works with good estimates. ;-)


This reminds me on our solver which only reliably works with good estimates. ;-)

Not only, you even have to check the last 2 estimates (at least when the solver fails). ;-)

Anyone who wants a better solver should feel free to code one as a keystroke program and send it in. Conversion to xrom will be troublesome but I'm willing to undertake that effort if required.

The solver in XROM has a 4 level stack (which can't be resized) and access to any allocated local registers and flags. The user's function is called via a special command but for all your solvers, just use an indirect XEQ.

Remember to check for NaN's and infinities and to get the final return stack & last x correct.

Let the flood gates open...

- Pauli


Anyone who wants a better solver should feel free to code one as a keystroke program and send it in.

I think the current solver is quite good. The only thing I don't understand is, that it returns "No root found" with even such a small function value of 1e-15 (in Z) and 2 identical last guesses in X and Y (as for the example in the other TVM thread).

I doubt that many functions would really return smaller values than 1e-15 (or even exactly zero) when applying the solver.


Edited: 18 Apr 2012, 5:07 a.m.


NT :-)


NT :-)




I'm sure any ribbing about the solver is good natured! I'm also sure that everyone understands the complexities involved in creating a good (great) solver; if not, they will as soon as they try to write their own! ;-)




I actually suspect the know how difficult a general purpose function solver is. I certainly didn't before I had to code one and now I've coded two and the second was no easier.

- Pauli


I'm a number theorist and, unlike some of my colleagues, I have rather limited experience in numerical algorithms, but I'm quite curious nonetheless (I'm a mathematician first, a number theorist second!)

Are the algorithms used by HP calculators SOLVE function publicly disclosed? (Is documentation available?) Are they standard or ad-hoc? Do they vary between different models?

Perhaps more to the point, Pauli. What's WP34s's current solver algorithm based upon? Brent's method perhaps?

I guess I ought to search the forum's history for discussions of issues others have found in the current solve function in the 34s. I am in possession of the 34s's manual, but of course it's not a reference manual on the internal algorithms ;-)


You can look at trunk/decn.c in the SVN tree. The solver code (at least the core of it) is there.


Thanks, Marcus. I'll try that. (I assume the SVN tree is hosted on Sourceforge...?)


Yes, it is.


Hey, we've come almost full circle! (It just gives more digits than a slide rule.)


The inventor of this calculator lives just across the way from me, over in La Jolla! It's actually an amazingly brilliant idea. I am always asking my 11 year old to do estimations, and this reinforces the value of it in learning math skills.

For HHC 2012, if we end up in San Diego, it'd be fun to invite this guy to present at the conference and show it live, don't you think? Or whenever HHC comes back to San Diego.

Thanks for finding this!!




Forum Jump: