Silver 17BII+ - General remarks and a solver example



#12

My new 17BII+ has just arrived. To make a long story short: I'm not impressed!

The device looks nice, the display is quite good, better then the 17BII. Keyboard feeling would be OK, if it didn't miss keystrokes! I have to poke beyond the point of tactile feedback to make sure that some keys register. This is a real nuisance! :-(

OK, I thougth, probably a bad sample, let's try to live with it and explore the new thing a little further.

The new calculator has more memory then the original 17BII, 32 KB instead of 8. Without a means of storing solver equations or data on an external device, and given the less then perfect alpha entry method, chances are good that you never want to fill up the additional memory space.

I've implemented the "well known" arc length integration problem as a solver equation:

1.) Create a list "CO" with coefficients 3/4, 9/8 and 9/8.

2.) Equation:
INT=L(H:X/L(M:3*N))*Sigma(I:0:G(M):1:IF(I=0 OR I=G(M):3/8:ITEM(CO:MOD(I:3)+1))*SQRT(1+4*SQ(I*G(H))))

The equation is a numerical integration ("3/8 rule") applied to N subintervals. For N=1, the integrand (in bold) is evaluated at 4 points, generally at 3*N+1 points.

You can now enter N, the right hand side (6 in the original example) and solve for X.

The old 17BII is much faster than the new one: With a starting value of 2.0000 (disp 4), and N=4, solving for X took 45 seconds on the new calculator and just 15 seconds on the old one.

HP what did you do?

Edited: 21 Mar 2008, 8:27 a.m. after one or more responses were posted


#13

Marcus, I have also seen that the original 17bii is much faster than either the 17bii+ "gold" or the new silver one. I think the explanation is that the solvers are different. The solver in the original 17bii was fast and efficient. It iterated only if it needed to. The new solver iterates all the time, even when it really shouldn't. I don't know if this totally explains the speed differential, but it probably has something to do with it.


#14

Don,

During the most recent HHC meeting held in Chicago I gave a presentation for how the Solvers for the different HP calculator models worked. I also compared it with the solver for the TI Voyage 200. The latter seemed to be smarter than the different versions of the HP solver. Cyril commented that the Solver used in the HP calculator is basically not that different from the initial releases (found in the HP-34C and HP-15C). My guess is that since that meeting (and perhaps very recently) HP has opted to change the Solver and use a different algorithm. It seems that the new algorithm used is not as efficient as the older one.

Namir

Edited: 9 Mar 2008, 11:59 a.m.


#15

It's not mainly the solving part, it's the general speed. You can compare it easily by just evaluating (not solving) the integral for different numbers of intervals.

Edited: 9 Mar 2008, 2:24 p.m.

#16

Hi Namir. Marcus says that the solver is not the problem, it's just the general speed of the 17bii+ silver edition as compared to the original 17bii. I can vouch for that. I have run several benchmarks on solver equations on the original 17bii, the 17bii+ gold edition (which I purchased about a year ago), and the latest 17bii+ silver edition. For pure computation speed, the original 17bii wins hands down. I don't know why that is, perhaps Cyril can enlighten us. Some equations that ran fine on the original 17bii won't run at all on the 17bii+ gold or silver editions. For example, the prime factor and gcd/lcm solver equations listed in the Technical Applications Manual for HP-27S and 19B will not run as published without some modifications. I believe these modifications are necessary because the current solver always iterates, which means it evaluates an equation at least twice, and this causes problems if you update menu variables or use variables without initializing them.

When I first brought up the problem of the solver on the 17bii+ gold edition about a year ago, several members suggested the best solution to that problem was to get an original 17bii. I did, and I agree, that was the best solution, because that solver works as a programmer would expect it to. The current solver in both the 17bii+ gold and silver editions does not.


#17

Someone in Kinpo fiddled with the ROM and introduced a bug???

Namir

#18

hello,

some comments:
- the 17BII+ solver is the "same" than the 17BII one, but transcribed in C
- the 17BII used a CPU that was 1: designed to do math, 2: was programmed in assembly (or system RPL) and 3: has full access to all the memory on the device
- the 17BII+ CPU is programmed in C, which is less effective, and in addition that CPU is really not designed to run C code, making for much more inefficient programs. In addition, the CPU can not address all the memory available, therefore all the equations, but also the temporary equation evaluation data is of-loaded in external block access memory requireing 1000's of of-chip memory access and swaps that are devastating for the speed.
- there is a "direct" solver on the 17BII+ just like on the 17BII that allows the solver to return results with no iterations, but the algorythm is slightly different.

regards, cyrille


#19

Hello, Cyrille --

Glad to see your input!

Quote:
... there is a "direct" solver on the 17BII+ just like on the 17BII that allows the solver to return results with no iterations, but the algorithm is slightly different.

Are there substantive differences in the functional description of the solver in the HP-17BII+ and those in earlier HP-17B models?

My main complaint with the solver on the HP-33s and HP-35s is the way that the direct-solve logic was incorporated. The logic was apparently based upon that of the original HP-17B/27S solver.

Each of these calculators will always return the directly-determined solution whenever one can be obtained. Such a solution may not even reside within the range of values specified by the user's two input "guesses" even when a valid solution is within that range, but that is of no consequence to these calculators.

I object to this aspect of the logic or functional description, because the user's "guess" values might explicitly specify the vicinity of the solution of interest and relevance to the problem.

Here's my recommended approach:


1. Determine if the form of the equation will permit a directly-determined solution.

-- 1A. If "YES", proceed to Step 2.

-- 1B. If "NO", proceed to Step 4.

2. Attempt to find the directly-determined ("direct") solution.

-- 2A. If a direct solution was found, proceed to Step 3.

-- 2B. If no direct solution was found, proceed to Step 4.

3. Does the direct solution reside within the range bounded by the two guesses entered by the user?

-- 3A. If "YES", return the direct solution and terminate.

-- 3B. If "NO", store the direct solution and proceed to Step 4.

4. Attempt to find an iteratively-determined ("iterated") solution.

-- 4A. If an iterated solution was found, proceed to Step 5.

-- 4B. If no iterated solution was found, proceed to Step 6.

5. Does the iterated solution reside within the range bounded by the two guesses entered by the user?

-- 5A. If "YES", return the iterated solution and terminate.

-- 5B. If "NO", proceed to Step 6.

6. Was a direct solution found?

-- 6A. If "YES", return whichever solution is closer to one limit of the user's guess range, or the direct solution if only that one was found.

-- 6B. If "NO", return the iterated solution if it was found, or the appropriate error-termination code if none was found.

Here's a table of what would be returned under this procedure.

                       No DS         DS outside range     DS inside range
No IS Error code DS DS*
IS outside range IS "Closer to range" DS*
IS inside range IS IS DS*

(*) = IS will not be attempted


There was a discussion about this a few years back. My functional specification posted back then was incomplete, and I didn't understand that the direct-solution logic originated with the HP-17B/27S:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=62665#62665

Basis of HP-33s SOLVE question:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=61213

Best regards,

-- Karl S.

Edited: 22 Mar 2008, 1:32 a.m.

#20

Cyrille: it's good to hear from you!

Could you comment if the hardware and/or the firmware are the same between the "golden" and "silver" HP 17 B II+ (or what the differences are)?

I, for one, think that the form factor, display, and keyboard of the "silver" are the best in the last 20 years; and hope that similar hardware may contain a scientific model (32 S II+ or 42 S+) in a future... Ah, how nice would have been if the 33S had been developed for such a body... (33 S II?).

By the way, is it really needed to put a large statement in the body of a calculator, stating it is a... "SCIENTIFIC CALCULATOR" or "FINANCIAL CALCULATOR"? Are there any doubts? Certainly they are no cell phones nor TV remotes; and a quick look will tell what kind of functions are there... Just the "B" or "S" is enough, and more elegant in my opinion.

#21

The original 17B and 17BII used a Saturn processor (in the Lewis chip) and were programmed in system RPL. Although the Saturn wasn't terribly fast, RPL was designed to be efficient on it.

It's my understanding that the 17BII+ (both versions) use a SunPlus or GeneralPlus CPU with a 6502 core, and code written in C. Anyone who has done assembly language programming on a 6502 can tell you that while it's fairly good for some things, it's not able to support C code very efficiently, because:

  • Being an accumulator-based architecture, it is register-starved. A compiler will have to generate a lot more load and store instructions than might be necessary on a processor designed for HLL support.
  • The hardware stack is limited to 256 bytes, which typically isn't enough for non-trivial C programs to store function activation records, so the compiler has to generate code to maintain a software stack.
  • The available indexed addressing modes aren't actually very efficient for addressing local variables in a stack frame (whether on the hardware stack or a software stack

The only thing these GeneralPlus microcontrollers really have going for them is that they are incredibly inexpensive. Other than that, a Renesas (formerly Hitachi) H8 or a TI MSP430 would be a much better choice. IIRC, HP did use an H8 in the 10BII. However, apparently in recent times cost is considered a much more important criterion for microcontroller choice than performance.

#22

Just as a side note, my unit came with manuals in German and Italian. If anybody is interested in the Italian manual, just tell me. It will go for free, of course.


Possibly Related Threads...
Thread Author Replies Views Last Post
  hp-prime solver and variable name fabrice48 22 2,763 12-10-2013, 03:25 AM
Last Post: fabrice48
  Solver issue with HP 17BII - different from 19BII Jeff Kearns 13 1,395 11-28-2013, 02:36 AM
Last Post: Don Shepherd
  HP Prime Triangle solver BruceH 29 2,737 11-28-2013, 12:03 AM
Last Post: Dale Reed
  17BII & 17BII+ Discounted Payback Period Revisited Tom Neudorfl 8 1,129 11-25-2013, 10:28 AM
Last Post: Don Shepherd
  Using units in Numeric Solver Harold A Climer 1 418 10-13-2013, 10:44 AM
Last Post: Tim Wessman
  Does Prime Have a Multiple Equation Solver? Norman Dziedzic 2 447 09-20-2013, 09:43 AM
Last Post: Norman Dziedzic
  Just a lazy solver algortihm PGILLET 1 430 06-28-2013, 11:47 PM
Last Post: Namir
  A good general mathematics reference book? Chris Smith 11 1,314 04-29-2013, 09:44 AM
Last Post: Chris Smith
  DM-1x Silver vs. DM-1xCC Aluminum quality? bhtooefr 11 1,166 04-14-2013, 07:08 PM
Last Post: bhtooefr
  [43s] : How the solver will be implemented Miguel Toro 3 606 03-14-2013, 06:09 PM
Last Post: Walter B

Forum Jump: