[WP34s] Bug or feature?  Printable Version + HP Forums (https://archived.hpcalc.org/museumforum) + Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum1.html) + Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum2.html) + Thread: [WP34s] Bug or feature? (/thread236597.html) 
[WP34s] Bug or feature?  Dieter  12302012 I just realized that the 34s rounds displayed values in a way that is different from classic HPs (at least the ones I know of). If in FIX mode the value in X is sufficiently low, the display switches to SCI (or ENG) notation. That's fine. But the thresholds are different: FIX 2 DisplayThe 34s switches as soon as the value itself falls below 0,01  while HPs own devices do so as soon as the rounded value passes this limit (i.e. below 0,005). Is this behaviour intentional? At least a subsequent ROUND seems to return the same results in both cases. While we're at it: The way SLV works still does not match the manual. The latter claims the user interface is the same as on the 15C, but it isn't. On the 34s, the display setting affects the results, while on the 15C (and 34C and 35s and...) the function always returns the best possible result. Walter, you recently asked for an example and I posted one, but there was no reaction.
Dieter
Re: [WP34s] Bug or feature?  Walter B  12302012 Dieter, regarding SLV it depends on Pauli: if we want SLV to operate as in the HP15C (as advertized) then apparently the SW has to be adapted. Else we have to specify how it operates ;)
d:)
Re: [WP34s] Bug or feature?  Paul Dale  12302012 The FIX to SCI change over is a troublesome part of probably the hairiest piece of code in the device, I'm not surprised something like this did appear. I've long held a suspicion that HP's display code contained similar quirks that became accepted as normal behaviour. The code in question is lines 945  976 of trunk/display.c The rounding step would have to be performed before the mode switching checks, but it certainly isn't a simple matter of rearranging the code. The question is how important is make a change like this? An awful lot of testing would have to follow  there are many edge and obscure cases the display code must deal with.
Re: [WP34s] Bug or feature?  fhub  12302012 Quote:No, at least not for me. I find it ok that the user is able to determine the solver accuracy with the display setting  it's not always necessary to get a solution with full precision, especially as the solving process may not be the fastest for some complicated expressions.
Franz
Re: [WP34s] Bug or feature?  Dieter  12302012 Add a simple round command as the final step in your user routine, and you're done. Easy as that. But there's a much more important point to this: what exactly are we talking about here? Is it the accuracy of the returned root or is it the tolerance of the function result? In other words: Would FIX 2 in a formatdependent SLV routine return a result with at least two valid decimals, or would this return a root for which the function is approximately zero (when rounded to two decimal places)? That's quite a difference.
Dieter Edited: 30 Dec 2012, 5:27 p.m.
Re: [WP34s] Bug or feature?  fhub  12302012 Quote:It seems you didn't understand. Rounding _after_ solving won't make the solver faster at all. Why should I calculate 12 or 16 digits when I only need 3?
Franz
Re: [WP34s] Bug or feature?  Dieter  12302012 Quote:
Oh, Franz.... #) Determine the root of x^25 where f(x)...Got the idea? This method was already mentioned in the 34C and 15C manual. And believe me, on those machines it really made sense  they were slow. Really slow.
Dieter
Re: [WP34s] Bug or feature?  fhub  12302012 Quote:Ok, ok, I've overlooked your part with the "user routine". ;) But this is something you've mentioned in your previous post: does SLV stop when dx~0 or f(x)~0? Using ROUND in the user routine would influence the accuracy of f(x) (and dx only indirectly), but I guess the WP34s SLV makes its decision (when to terminate) wrt. dxvalue.
Franz
Re: [WP34s] Bug or feature?  Dieter  12302012 Quote:Take a look at the SLV code (in solve.wp34s) and no guessing is required. ;) Actually there are three tests that check if the function result (!) is approximately zero (applies to f(a), f(b) and f(new_estimate). And finally SLV checks whether the two last approximations agree within 5 ULP. So, yes, the current SLV implementation seems to do its displaysettingdependent tests based on f(x). Yes, it also checks if the last two estimates are nearly identical (to all digits except the last), but this is not affected by the display setting. In other words: the rounding done by SLV can just as well be done within the user's function routine. Simply add one of the round commands as the final step. Dieter
Edited: 30 Dec 2012, 7:17 p.m. after one or more responses were posted
Re: [WP34s] Bug or feature?  Paul Dale  12302012 The tests for f(x) being almost zero can be done via a round in the user's code. In fact, they would be better done there because they only do something useful in FIX mode. I'll make this change. The termination code avoids rounded compares due to some problems there which resulted in bad termination conditions. I don't recollect the specifics anymore. That just leaves two rounded comparisons. These are used at the start if a singular guess is given  a search interval needs to be created from such. I suspect any interval creation method would be viable here. Will have a think about what might work nicely.
Re: [WP34s] Bug or feature?  Reth  12302012 Is there a chance after that SLV stops giving pole rather than root as an answer in all cases? I haven't checked it lately (are there any changes to SLV?) but I had couple of examples of doing exactly that. I know ... 'everyone is free to develop their own solver' etc., just asking. I'm not capable of doing it. Re: [WP34s] Bug or feature?  Walter B  12312012 Is there a chance asking more specific? I.e. unvealing your 'couple of examples'? That would support the quest ... TIA
d:)
Re: [WP34s] Bug or feature?  Reth  12312012 Yes, there is, I'll post them here first thing in the New Year which is now less than 6 hours away. I was actually hoping PD would remember so I asked him.
All the best for the new 2013 to all!
Re: [WP34s] Bug or feature?  Paul Dale  12312012 It certainly is possible to make an attempt to detect poles, it just takes time to code and test and a bit of inspiration to escape the influence of the pole.
Re: [WP34s] Bug or feature?  Dieter  12312012 Honestly  if we really wanted the 34s to behave exactly as the 15C, this would require the same code of the Solve function. Many examples presented in the 34C and 15C manual cannot be duplicated on the 34s, simply because it uses a different algorithm. Finding poles or local extrema can be done with HP's original SOLVE implementation, but this will not work with SLV on the 34s. That's why I would suggest to remove the 15C reference from the 34s manual. The only thing both implementations have in common is the stack layout on entry and on exit. And even this is not exactly the same in both cases.
Dieter
Re: [WP34s] Bug or feature?  Dieter  12312012 By the way  there also is a way to make SLV return the root (and not f(x)) with a given accuracy. The idea here is to compare the current estimate with the previous one: 001 LBL AProvide two sufficiently different guesses and store the larger one in R00. 2 [ENTER] 3 [STO] 00Then start SLV as usual. Even with no accuracy limitiations, e.g. in ALL mode, SLV now returns a result within the specified tolerance: [ALL] 03The exact solution is sqrt(5) = 2,236..., so the error in X is less than 0,005  just as specified. Dieter
Edited: 31 Dec 2012, 9:16 a.m.
Re: [WP34s] Bug or feature?  Walter B  12312012
Quote:Done. Will be published in due course.
d:)
Re: [WP34s] Bug or feature?  Dieter  01012013 I think I'll have to add a big CAVEAT here. The method I suggested works well if the solver produces a strictly convergent series of estimates, i.e. the current estimate is as least as accurate as the difference between the last two: x_new  x_exact < x_new  x_oldThis is not (always) true for the 34s solver, and it does not apply to various other algorithms eiher.
Here's an example. Let's consider the following simple function: ln(x)  1 = 0It has a root at x = e. With 2 and 5 as initial guesses The 34s solver produces the following sequence of estimates: estimate abs. errorSo the current solver eventually comes to a solution, but it may take a while (which is fine if on the other hand a solution is reliably found in more complex cases). Line 3...5 show why the proposed method of comparing the current estimate with the previous one does not work here.
Here is the sequence returned with 1 and 5 as initial guesses: estimate abs. errorFinally I tried the same with the 35s and 34C solvers. HP 35s HP34CWhich leads to the question if there are some deeper insights on how HP Solve (resp. a particular implementation) works in detail. I found an interesting discussion here in the forum back in 2003, cf. this thread.
Dieter
Solving methods (SLV)  Walter B  01012013 Hallo Dieter,
Quote:Thanks for making us aware of that old thread. Interesting read.
d:)
Re: Solving methods (SLV)  Dieter  01012013 Yes, the HP solver (here: the version used in the 34C and 15C) is known to produce reliable results, so maybe we can find out more about the way it works and use this for the 34s. Anyway, I always thought the 34s solver used some kind of implementation of Brent's algorithm. But in this case it would not require 30 to 40 iterations (!) for a simple function like ln(x) = 1. As shown in my previous post, the current method changes to bisection very early, so it converges very slowly.
I tried a simple Brentstyle implementation in VBA for Excel, and here's the sequence of approximations I got: Estimate abs. errorThat's 15+ digits after just 9 function calls (including those for the two initial guesses) in a nice convergent series of approximations. So what's going on in the 34s? Why does the current solver converge so slowly?
Dieter
Re: Solving methods (SLV)  Paul Dale  01012013 The 34S solver uses a variety of different methods. It certainly did use Brent at one stage, I'm not how much of that I removed as it evolved. Brent style quadratic interpolation and secant steps are used as is bisection and sometimes Ridder's method (but only after a bisection step). Bisection is used when the root is bracketed and which ever one of the other methods being used appears to produce a divergent x value  this happens quite a lot unfortunately. I'm not overly attached to the current solver and would certainly consider replacing it with something better.
Re: Solving methods (SLV)  Dieter  01012013 As far as I understand there are various methods that make sure that the interval narrows with each iteration step, i.e. the root (if there is one) is found within the interval initially given  provided the two initial guesses bracket the solution. I just tried a modified regula falsi algorithm (with Anderson/Björck adjustment)  it finds a root within the given interval quite fast and since the calculation is simple and straightforward (as opposed to the Brent method) one or two more iterations do not matter much. So I see two major points that should be resolved: first, if the initial guesses do not bracket a root, define a method to find such an interval. Second, find a foolproof way to decide whether a) a solution is found and, more important, b) no solution can be found. I mean, something better than "max_iterations exceeded". ;)
Dieter
Re: Solving methods (SLV)  Paul Dale  01012013 That max iteration message is a reside of the C implementation  I was extremely memory constrained and couldn't afford space to do much else.
 Pauli
Re: [WP34s] Bug or feature?  Paul Dale  01022013 Have any of the 41 machine code gurus figured out how the advantage pack solver works? If the algorithm used there is understood, it shouldn't be too hard to implement in the 34S.
Another interesting read  Dieter  01032013 While the mcode specialists analyze the 41's advantage ROM code, here's an interesting document I found. It mentions two HP journal articles by W. Kahan and P. McClellan on the HP solvers built into the 34C and 18C. The proposed solver sounds very promising to me. The PDF can be found here. What do the experts say?
Dieter
Re: Another interesting read  Paul Dale  01032013 Interesting, I hadn't seen that one.
