HP17bii+ solver vs. HP17bii/HP19bii/HP27S

[M. Joury]

Let me start by saying that I know the solvers of these various machines have been discussed before but searches on HP17bii and CTIME did not come up with anything. I apologize if this is a repeat of something that has gone before.

I was trying to time a summation within the solver to see if it could be done. I ended up with the following formula:

A=L(ST:HRS(CTIME))*0+SIGMA(I:1:1000:1:0)+HMS(HRS(CTIME)-G(ST))

I was experimenting with different operations in the last position of the summation clause '0' vs '1' vs ... The solution result should have been the total run time in H.MS notation.

At any rate this 'code' worked for my HP17bii, my HP19bii, and my HP27S (I still need to try it on my HP95LX). It did not work on the HP17bii+. Trying to narrow down the problem I tried the following two formulas:

1. A=L(ST:CTIME)*0+SIGMA(I:1:1000:1:0)+G(ST) -> Expected result should be the start time in H.MS

and

2. A=SIGMA(I:1:1000:1:0)+CTIME) -> Expected result should be the end time in H.MS

The first was expected to report the start time of the run while the second should have reported the end time. On the 17bii+ formula 1 worked as expected reporting the start time of the run but formula 2 reported a time midway through the run. I realize that in the above formula there is no order implied as to how the calc should solve the problem except that I might expect it to work from left to right and I certainly would not expect it to pull a time from midway through the run. It is almost as if the problem were being executed on a multithreading system and the code had dispatched the two halves of the problem on two separate threads. Now I know that our little toys are powerful but I somehow doubt that this is what is going on :-).

Any ideas as to what is happening here? Am I missing something obvious? Or is the 17bii+ solver implementation doing something weird?

Marwan

[Don Shepherd]

Quote:

---

is the 17bii+ solver implementation doing something weird?

---

The 17bii+ solver behaves differently than the 17b solver and the 17bii solver. The 17bii+ solver actually evaluates your equation twice. The first pass is supposedly for the purpose of pre-calculating values that can be pre-calculated, and the second pass is the real run. This causes problems when you update a menu variable within your equation because it updates the variable during the first pass and then again during the second pass, and sometimes you do not get the result you would expect. This behavior has been discussed many times in this forum, and the general consensus is that if you really want a good solver that behaves as you would expect, use the 17b or 17bii. I concur.

I tried your formula 2 and I do get the ending time of the run, but the time required to loop from 1 to 1000 is not that great (less than a minute). Also, CTIME does not always report the correct time. For instance, in a solver equation it reports the time as 12.30 and if you immediately look at the time on the calculator (after solving the equation) it might be 12.29 and 50 seconds.

Hope this helps.

Edited: 20 May 2011, 12:33 a.m.

[M. Joury]

Hi Don,

That explains what I am seeing. To test this I synchronized the 17bii+ clock with another clock and then ran the second equation. I am seeing results well within the middle of the timespan and not near either the beginning or end. It is interesting that you do see the correct ending time on your unit (I assume that when you say you tried this you meant that you tried it on a 17bii+). Of course the explanation for what I am seeing is the two pass nature of the algorithm used on the 17bii+. I will need to perform a more general search to find the earlier discussions of this subject as I have to wonder what the supposed benefits (if any) are to doing it the 17bii+ way. Perhaps, as your comment on 'good' solvers might suggest, there is NO benefit.

On the issue of accuracy of CTIME: With the display set to FIX 4 the HP17bii reports a completion time within a second of the synchronized clock so I am not seeing the disparity in times that you mention. I do recognize that CTIME is only accurate to a second so if I were doing real timings I would probably make the summation loop much longer (10000?) and divide the resulting time interval by 10 to get the timespan for 1000 iterations (or if I was patient enough I could do 100000 and divide by 100). Furthermore, using the original timing equation on a 17bii I see total times for the run within a second of those obtained by using a handheld stopwatch so, again, I am not seeing the inaccuracies that you mention.

Cheers,

Marwan

[Don Shepherd]

Quote:

---

I assume that when you say you tried this you meant that you tried it on a 17bii+

---

Yes, the 17bii+.

Quote:

---

I will need to perform a more general search to find the earlier discussions of this subject

---

Searching the archives has always been tricky. Here is a post I made back in 2007 regarding the fact that the prime factors algorithm contained in the Technical Applications Manual for the 27S and 19B did not work on the 17bii+, and it contains a workaround I came up with to get it to work.

Quote:

---

there is NO benefit

---

I wouldn't say that. Most users will never run into this particular solver problem, and the 17bii+ will work fine for them. But everyone should be aware of this potential problem.

Quote:

---

I am not seeing the inaccuracies that you mention

---

I think there may have been some changes to the 17bii+ over the years, and this may explain that. I know that some users reported benchmark times on their 17bii+ that were significantly different than the times I obtained.

Don

[M. Joury]

Hi Don,

Thanks for the reference to your earlier posting.

Cheers,

Marwan

[Don Shepherd]

Oh, yeah, CTIME does report the correct time, I was wrong. I was set to FIX 2 so it was rounding the minutes.