# HP Forums

Full Version: hp 35s not very impressive
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

Got my hp 35s. so far not very impressive... The quality is decent although i still prefer the 32s built. i am sure the 35s got a lot of goodies, but i am just disappoint that complex number functions are not very good....

welcome to the club

Ditto.

On the other hand, 50g is farly impressive even when compared to TI nspire cx cas. seems like 50g is one of the few calc that will actually handle infinity. 1/0=inf. tan pi/2 = inf.

Any other calc that can handle infinity? hp or non hp?

Edited: 27 Aug 2012, 2:10 a.m.

Does it handle the case for both values of the pole correctly? The value at the nPI/2 pole is +/- inf, depending from which side one approaches the pole.

Hi.

IIRC, the HP71B has a 'defense mechanism' for the infinity occurrence.

Cheers.

Luiz (Brazil)

This is the case for TAN, COT, SEC and COSEC because all of them include a 'divide by' and subsequent reciprocal, which leads to divide by zero (by definition).

But is there any other calc we know of beside 50g that would even handle the value inf?

i don't think 50g really distinguish between + and - inf. maybe that's for the replacement. But that's definitely impressive in my book, even if it's just rudimentary..

i played aroud with my newly acquired nspire cx cas. the active color display is nice, but all that will do is drain battery faster.
I do, however, like ti concept of fitting a curve to a scanned in object.... but nspire doesn't handle inf..

Take the WP 34S and set flag D. Then enter 0 +/- 1/x and you'll get -infinity d:-)

"Does it handle the case for both values of the pole correctly? The value at the nPI/2 pole is +/- inf, depending from which side one approaches the pole. "

Yes, the syntax is

'1/X' 'X=0+0' lim

-> +oo

'1/X' 'X=0-0' lim

-> -oo

'TAN(X)' 'X=PI/2+0' lim
-> -oo

'TAN(X)' 'X=PI/2-0' lim
-> +oo

'TAN(X)' 'X=PI/2' lim
-> oo

(oo infinity)

etc.

I would be very surprised if the TI CAS don't do this !!

Edited: 27 Aug 2012, 8:19 a.m.

Quote:
Got my hp 35s. so far not very impressive...

.
Not very impressive ... as compared to what ?

I got mine as a present and spent about one month trying it out and wrote five full articles about it, one or two were sent to HPCC and published in Datafile ("Storing Lotsa Lotsa Numbers" and "Going back to the roots"), and the remaining ones were not and still remain as PDF files on some backup hard disk of mine.

After writing said articles I then stopped using the HP35s altogether. There was much to like and it certainly was a quality RPN calculator with a nice classic form factor, good keyboard, decent display, lots of memory and functionality and such, but it also had some terrible flaws that seriously detracted from the fun, such as:

• The checksum code was completely broken so there was no decent way to ensure your program was correctly entered and/or remained intact afterwards, with no accidental or unforeseen changes. This made program checking unreliable and a real chore.

• Sometimes the GOTO destinations would change when deleting some lines and also under other seemingly arbitrary or difficult to foresee conditions, which, combined with the unusable checksums made it very difficult to trust the results you got as you couldn't trust the programs themselves to be (and remain) correct in the first place.

• Complex-number and vector-component handling was abysmal, with no easy way to do the most elementary things with the components.

and many other quirks and caveats which would appear when you least expected them and would require lots of attention and awareness of them and their mainly nasty side effects. All in all, this made the calculator quite unreliable and little fun to use, more like an insufferable chore, so I stored it for good.

A real pity if you ask me, as it had so much potential to be a really fine, useable, powerful RPN calc but alas, due to some very sloppy and ill-specified firmware it wasn't to be but was a complete letdown instead.

Best regards from V.

```
```

Complex number handling is abyssmal as you say. It just doesn't have that great feeling to it like say 42s. I suppose for the price point, it has more features than 32s, but i mean i hate to have to even justify something by bringing up price as a point. They definitely could ve handle the feature set better.

Quote:
A real pity if you ask me, as it had so much potential to be a really fine, useable, powerful RPN calc but alas, due to some very sloppy and ill-specified firmware it wasn't to be but was a complete letdown instead.

Valentín, that's exactly my opinion. Also, the worst thing is so far HP has done nothing to fix any of these bugs, despite some of them are known since the very release date. I can't help comparing present day HP to the company that once had this attitude towards a lesser original HP-35 bug:

Quote:
A few bugs got through this process. For example: 2.02 ln ex resulted in 2 rather than 2.02. When the bug was discovered, HP had already sold 25,000 units which was a huge volume for the company. In a meeting, Dave Packard asked what they were going to do about the units already in the field and someone in the crowd said "Don't tell?" At this Packard's pencil snapped and he said: "Who said that? We're going to tell everyone and offer them, a replacement. It would be better to never make a dime of profit than to have a product out there with a problem".

(Quoted from http://www.hpmuseum.org/hp35.htm)

Best regards,

Gerson.

hp35s is crippled by birth, no I/O, no flash, RIP

I don't know if this is meant to be an incindiary comment or not. HP is not at fault for not including those features. Those features are required to be absent in order for the calculator to be approved by NCEES for use on the FE and PE exams. If you have a problem with that, HP should not be the target of your anger, but NCEES. For me, I am just happy that NCEES will allow the use of RPN calculators and that I am not forced to use something that does not come naturally to me.

Quote:
I can't help comparing present day HP to the company that once had this attitude towards a lesser original HP-35 bug...

Would that be the same HP which produced in its next series the most incompetent design in all calculator history? I write, of course, of the Woodstock series with battery charging system that was guaranteed to destroy the calculator if and when conditions developed that were almost certain to occur in the natural use of the machine.

It's a pity that Packard worried about a relatively minor and non-fatal firmware flaw in one machine, yet ignored a gross hardware design fault in every calculator of the very next generation which could destroy the machine.

The 35s was a *major* improvement over the 32SII it relaced (let's forget about the ugly, much less capable and likewise buggy 33s). If it weren't for all those bugs, it could have seperated me from my 32SII when it comes to daily use.

If the fine calculator people at HP were allowed to improve and debug existing calculators instead of getting out new buggy calcs all the time, we would have had quite some fine machines by now.

50G = proper descendent of Bill Wickes' RPL masterpiece, the 48GX. Painstakingly and tirelessly worked on by a skeleton crew (including C. de B. IIRC), the 50G is a true professional tool. A platform not only for User RPL in the classic sense, but SysRPL and even ARM programming. Some have even written C++ code and compiled it (I think).

The 35s was a good idea, but it seems to me that there must have been too much outsourcing. It would be interesting (over coffee with the tape recorder turned off) to get the inside scoop in the 35s.

I love the 20B and now 30B platform. I have barely scratched the surface but when you see that the small but dedicated calculator group has put out a product which not only serves a market niche in the business models, but also a tinkerer's and programmer's niche at the same time--no *that* is a great thing that should all make us *very* happy, regardless of what the upper level of HP is doing (for instance to the laptops we buy).

Edited: 27 Aug 2012, 4:06 p.m.

The 35s shares the exact same completely unacceptable major bugs found in the 33s ... :-(

What you say is true, however as HP has chosen not to fix the product and is certainly not going to WR existing, then it is RIP as far as serious users aer concerned--since you can't repair the damn thing with new firmware.

Yes, that is very true.

I'm stating facts. The calculator is full of bugs and shortcomings and there is no way to be fixed. It should never be released.

For the record the TI-nspire CX CAS does handle +/- infinity.

```limit(1/x,x,0,+) -> +oo
limit(1/x,x,0,-) -> -oo
```
--
Miles

what about inv tan (inf) and tan (pi/2) ?

Quote:
The 35s was a *major* improvement over the 32SII it relaced (let's forget about the ugly, much less capable and likewise buggy 33s). If it weren't for all those bugs, it could have seperated me from my 32SII when it comes to daily use.
[...]

Exactly what I thought after a few weeks playing around. It is now a "shelf" machine, like some oldies. For daily use I went back to the 32SII.

On my TI Voyage 200 (and therefore probably on the TI-89), inv tan (infinity) = pi/2 and tan (pi/2) = "undef". Working out the limit of tan (x) as x tends to pi/2 from below gives +(infinity); as x tends to pi/2 from above gives -(infinity). Nice!

Nigel (UK)

I have to admit I have not been using my 35S lately.

Hi all.

Shouldn't HP be getting these feedback responses and perhaps screenshots so that they can see the shortcomings and issues with the 35S? I think, the more HP hears about and sees these errors and mathematical discrepancies, they would be made aware more concretely of the flaws in the 35S and either issue a newly ROM-revised 35S or an entirely new model to replace the 35S.

Oh yes, that's the idea we were all waiting for :-> Please search the archives ... sometimes ... maybe even before posting ...

The people at HP who actually have expertise and design calculators already know all about it. Obviously there is a management decision above them to leave it alone.

Quote:
I'm stating facts. The calculator is full of bugs and shortcomings and there is no way to be fixed. It should never be released.

Try to remember the time period before the 35s was released. There was a huge thrill of anticipation in this community that the release would coincide with an anniversary of the release of the original 35.

There just simply isn't a large enough market to justify fixing or releasing new RPN scientific models. When this calculator was introduced in 2007, the iPhone had just appeared. After five years, you probably can't convince many people to purchase a separate calculator when their phone does as much and more. Not to mention the only real value of the 33s/35s is that it can be used on NCEES board approved tests.

As stated previously, I think HP's RPN scientific calcs are done. I don't expect a new release. I could be proven wrong, but between capable mobile devices, PCs, laptops, and a company that is losing revenue, it's an unlikely proposition.

Edited: 28 Aug 2012, 5:25 p.m.

Yes yes. I know what you mean. I'm just questioning because I wonder if HP is just shrugging our input off because either just a few of us are alerting HP and that doesn't justify (to HP) issuing a ROM revision or complete 35s redesign since the 95% of 35s owners haven't chimed in about the bugs.

No i don't think you know what he means. Even if every person who bought one complained to HP they still wouldn't change a thing. Like the man said it's all in the archives.

Perhaps not "impressive", especially in the programming and complex world, but I like the 35S as an everyday calculator. I like the form, the keyboard, the constants and conversions (though I wish there was a ft-m rather than in-cm), and the big enter button in the right place. Yes it is too bad that the flaws aren't addressed, but it is nice that there is still a decent RPN scientific calculator out there for sale. IMO, of course.

I remember that time. One more reason to be realized on a flash device. Then hopefully we could get some bug fixes (unlike with the 15c LE)

Unlike the ARM based calculators with flash-able ROM, the 35s is a 6502 clone with mask ROM (i.e. "programmed" in the factory and cannot be updated), and HP probably purchased it by the million.

Also it is directly mounted onto the PCB, so in HP's current economic situation I doubt they want to spend the money to scrap the current stockpile with faulty ROM and spend money on replacements.

Big letdown. I was expecting a little better.... After all, this is supposed to be hp latest rpn attempt.

If i want an everyday calc, could ve just use my smartphone with free42 and emu48.

I expect better when i actually spend almost \$50 on an HP calc. actually, i don't mind spending slightly more for one with better program and complex number support.

Quote:
Actually, i don't mind spending slightly more for one with better program and complex number support.

That would be an HP42S, though "slightly" wouldn't probably apply.

I don't use physical HP calculators anymore but if I had to, I'd probably go for a 42S. It's a fun machine to use and to program, fast and capable. Except for the lack of mass storage, there's not much to limit your creativity and the few actual limits are fun to try and overcome.

Best regards from V.
.

Buenas tardes Valentin,

may I recommend you try a WP 34S? Mathematically, it can do all the HP-42S can do (except some matrix operations) plus a significant bit more. And the project is about to reach its end, so a thorough investigation would be appreciated, especially performed by a math guru as you are.

There was some discussion of removing the guts of the 35s and replacing with new components. Probably harder than it sounded and not worth the effort.

(I still have the dxf files of the PCB if anyone would like to take a crack at it.)

...

Hi, Walter:

Quote:
may I recommend you try a WP 34S? Mathematically, it can do all the HP-42S can do (except some matrix operations) plus a significant bit more. And the project is about to reach its end, so a thorough investigation would be appreciated, especially performed by a math guru as you are.

Thanks a lot for your continued appreciation and kind words, Walter.

I lost most of my formerly considerable interest in calculator-related matters a few years ago after some particularly discouraging events and haven't fully recovered it back yet so I'm not really for allocating always-scarce free time to such matters again but simply content myself with just the occasional post here to somewhat remain in touch with all of you, out of sheer nostalgia.

Nevertheless, I'll contribute a simple sample computation for you to check how well does your beloved WP 34S cope with it:

Numerically find a root of
Sin(x + Cos(x)) = 1
for x in [0, Pi].
You must program precisely that equation (not some variable-change version or trigonometric transformation of it), radians angle mode, and use 0 and/or Pi as initial guess(es).

Of course the exact root is

x = Pi/2 = 1.57079632679489661923132169163975144209858469968755291...

See how many correct digits does your built-in WP 34S Solve functionality provide at various precisions. The same goes for other people reading this and using either the WP 34S or other HP (or whatever brand) models as long as they don't use symbolics.

P.S.: I didn't know the chance fact that the 34S would simply try the arithmetic mean of the two initial guesses (which is Pi/2) and thus stumble upon the exact root by sheer luck, with no decent algorithmic work and smarts involved.

Thus, to make this test results meaningful for this machine, you should use instead as first guesses 1 and 2, which do straddle the exact root and whose arithmetic mean doesn't happen to be the root.

Best regards from V.

```
```

Edited: 30 Aug 2012, 4:28 a.m. after one or more responses were posted

Hello Valentin,

Quote:

Numerically find a root of
Sin(x + Cos(x)) = 1
for x in [0, Pi].

```WP 34S (V3.1 3089)
001 LBL A
002 COS
003 +
004 SIN
005 1
006 -
007 RTN
008 END
0 ENTER h pi f SLV A --> 1.570796326794896619231321691639752 (DBLON)
1.570796326794896 (DPLOFF)
```

Best regards,

Gerson.

Buenas noches Valentin,

Calling SLV in default DECM, FIX 11 returns 1.570 796 326 79(4 896) with the last four digits used internally and only displayed by the equivalent of SHOW.

Calling SLV in FIX 11, DBLON returns

1.570 796 326 79(4 896 619 231 321 691 639 752) with the last 22 digits used internally. That's just one ULP off. Not too bad IMO.

Cordialmente,
Walter

Edit: Gerson was faster than me :-) And my program differs:

```001 LBL A
003 COS
004 RCL L
005 +
006 SIN
007 1
008 -
009 RTN
```

Edited: 29 Aug 2012, 4:05 p.m. after one or more responses were posted

Quote:
See how many correct digits does your built-in WP 34S Solve functionality provide at various precisions.

```001 LBL D
002 ENTER   // may be omitted for SLV
003 COS
004 +
005 SIN
006 1
007 -       // or use DEC X instead
008 RTN
0  [Pi]  [SLV] [D]
=> 1,570796322794896
[DBLON]
0  [Pi]  [SLV] [D]
=> 1,570796322794896619231321691639752
```
BTW, in the world of limited-precision arithmetics there is more that just one single value for which sin(x + cos(x)) equals 1 when rounded to working precision. For instance, for x = 1,57 the result is 1 even when rounded to 20 (!) digits. Simply because x + cos(x) approaches pi/2.

Dieter

Edited: 29 Aug 2012, 4:08 p.m.

I would like to point out once more that IMHO it's not a good idea at all to make the results of SLV dependent from the display setting. This is completely different from the way classic HPs did it - including the 15C and others that the manual refers to. And if really required, the user may limit accuracy manually in other ways.

Edit after Walter's edit: Of course we can do it shorter on the 34s.

```001 LBL A
002 COS
003 RCL+ L
004 SIN
005 DEC X
```
BTW, the final digit 2 is the rounded 34th digit of Pi (3) divided by 2 and rounded up. Simply set RM 2 and you get ...9751. ;-)

Dieter

Edited: 29 Aug 2012, 4:18 p.m.

Valentin, I do wish you would get a 34S. :-)

The solver isn't particularly dependent on the display setting.

The test for equality with zero after each function evaluation is via x[approx]0? which is display setting based but is only different from a standard x=0? conditional if you are in FIX mode.

The initial test for the two estimates being equal is also display dependent but this shouldn't impact most searches -- if your guesses are this close together and bracket a root, you already know it & don't need the solver.

The check if two guesses are close enough together to be considered converged is done using a multiple of ULP which isn't display based. This is what typically terminates searches.

Still, suggestions for solver improvements are always welcome -- preferably with the required code changes included.

- Pauli

Me too. I'd like to see the device stressed to the limit to see what it is really capable of.

- Pauli

I do not want to pour too much water into the wine, but there might be a simple reason why the 34s instantaneously returns a correct result: if its first guess simply is the (arithmetic) mean of the two guesses - that's pi/2 here - and this value solves the equation (i.e. the returned result is zero, which numerically is true for many values near pi/2), the solver may quit and simply return this result.

Now look at this:

```Guesses        result DBLOFF   result DBLON
--------------------------------------------
0  2         -23,5653...      -23,5619...
0  3         -80,1106...      No root found
1  2         -545,06...       No root found
0  3,14159    1,570795        1,570795
0,0001  Pi     1,570846...     No root found
1,57   1,571   1,57            No root found
1,5707 1,5708  1,5707          1,5708
```
The two guesses in line 4 both do not solve the equation, but their arithmetic mean is close enough to return exactly 1 for sin(x + cos(x)), at least to 34 digits. And so...

Then look at the last line. f(1,5707) is about -1,1E-26, which is rounded to zero in single precision and so the solver quits. However, in double precision that's not close enough to zero, whereas f(1,5708) is, so here simply the second guess is returned.

Hmhmhmhmhmhmhmmm...

Dieter

Edited: 29 Aug 2012, 6:23 p.m. after one or more responses were posted

Quote:
...the solver may quit and simply return this result.

Yes it will stop immediately if any function evaluation is zero.

- Pauli

Quote:
The solver isn't particularly dependent on the display setting.

Except in FIX mode. ;-)

As far as I understand, the solver quits as soon as the function result rounds to zero. Which I think is not a good idea. If the user wants to have it this way, he may simply add a ROUND instruction at the end of the function subroutine.

Dieter

Quote:
Hmhmhmhmhmhmhmmm...

Looks like Valentin has laughed last, at last. :-)

Thank you for the concise and detailed explanation. Now that I understand that the chip is directly mounted on the PCB, I can see why a 35S refit would be overwhelming. That helps me understand the situation a lot better.

Quote:
Hello Valentin,

```WP 34S (V3.1 3089)
001 LBL A
002 COS
003 +
004 SIN
005 1
006 -
007 RTN
008 END
0 ENTER h pi f SLV A --> 1.570796326794896619231321691639752 (DBLON)
1.570796326794896 (DPLOFF)
```

Best regards,

Gerson.

Thanks, Gerson. I've edited my original post above to reflect the fact of such chance event occurring and stating that the initial guesses should be 1 and 2 instead, lest the result is rendered meaningless.

Best regards from V.

```
```

Also am I correct that you can only store 26 programs since the initial program labeling can only be one letter from A to Z? if so what a waste of the 30kb of available program memory.

Actually it's 27 as you can have one unlabelled space.

However, you could use the same label for different programs, e.g.
A001 LBL A
A002 (start of pgm 1)
A100 (start of pgm 2)
etc.

Quote:
Also am I correct that you can only store 26 programs since the initial program labeling can only be one letter from A to Z? if so what a waste of the 30kb of available program memory.

No, you are absolutely wrong.
1. HP-35s have no limit on labels.
2.Number of labels in no way limits number of programs. (Hint: how much programs could you store in HP-12C memory?)

26 programs is more than enough for calculator, and 30K is not too much, since every operator consumes 3 bytes and every register 37 bytes.

Hi Jeff,

I guess HP could send it to a facility to have the epoxy blob removed, take out the IC with faulty code, replace with updated IC and re-seal. However although this would salvage the PCB and all other components, I suspect a complete new run would be cheaper. But again, I don't think HP wants to pay for either method.

For the hobbyist:
Assuming U1 is the uP + ROM (SPLB31A/GPLB31A datasheets state 256K ROM is included) and U4 probably RAM. The blob and IC could be removed (I've never done this so I don't know how difficult this would be). I think a piggy-back board would then be required to connect the replacement IC pins to the correct PCB tracks.

No limit on labels? but the initial label at the top only allows one alpha letter entry.

if you can only have 27 programs that means each program needs to use average of a little over 1kb. That's fairly sizeable programs. i don't think most programs use more than 1/4 or 1/2 kb.

Here is a thread with some photos by Jeff of the 35S taken apart: HP35s Internal Investigations

Quote:
Actually it's 27 as you can have one unlabelled space.

However, you could use the same label for different programs, e.g.
A001 LBL A
A002 (start of pgm 1)
A100 (start of pgm 2)
etc.

That is way too confusing, esp when time to debug with multiple subroutines in each program.

Bart, thanks for excavating :-)

@Matt: I hope this explains even to you what I meant when I stated above that some research in the museum archives may often help a lot. Instead of asking the obvious, at least. Please ...

It is manageable. For example the curve fitting programs in chapter 16 of the manual use several labels, I have combined them into 1 label: curve fitting program for the 35s

OK, I plotted the equation y = sin(x + cos(x)) - 1 and found its root at pi/2 is the maximum of this function. So, in an attempt to cure the problem, I modified the equation slightly:

y = sin(x + cos(x)) - 1 + d with d << 1.

I solved it for different values of d (stored in R00). These are the results for DBLON, taking 0 and pi as first guesses and setting the display to ALL 00 (edit: I added the results of a second run with 1 and 2 as first guesses):

```d       x_root(0, pi)                                       x_root(1, 2)
1e-3    2,22036201033                                       2,22036201033
1e-6    1,77490289682                                       1,77490289682
1e-7    1,70980074769                                       1,70980074769
1e-8    1,6654825901                                        1,6654825901
1e-9    1,63530016132                                     -29,7806263746
1e-10   1,61474064464                                       1,52685200895
1e-11   no root found  1,57079703157                 -8840433,65927
1e-12   no root found  1,57079639727                        1,59119295725
1e-15   no root found  1,57079632687                       -4,71883892102
1e-18   no root found  1,57079632679 (= pi/2 + 7e-14)  -10579,2744561
1e-21   no root found  1,57079632679 (= pi/2 + 7e-17)
1e-24   no root found  1,57079632679 (= pi/2 + 7e-20)
1e-27   no root found  1,57079632679 (= pi/2 + 7e-23)
1e-30   no root found  1,57079632679 (= pi/2 + 7e-26)
1e-33   no root found  1,57079632679 (= pi/2 + 7e-29)
```
Just checked the HP15C Owner's Handbook, Appendix D. The function given by Valentin doesn't fulfill the conditions stated on p.221f there. Although that's not explaining why the algorithm seems to fail, it shows at least that other folks may have had problems, too, with such functions.

Let's take a closer look to the last case solved properly and the first case apparently going banana (d = 1e-8 and d = 1e-9 for the initial estimates 1 and 2):

SLV returns for d = 1e-8: x= 1,6654825901, y-x= 9,44475624443e-14, z= 0

and returns for d = 1e-9: x= -29,7806263746, y= 4,22728651914, z= 0.

Despite of the strange result, it's fully correct. The function Valentin gave us is periodic. It has an infinite number of roots. And the neighborhood of each root is extremely ill-conditioned. Close to the roots, the function runs almost horizontally. So any search algorithm working with the tangent to the curve will become unstable, i.e. the next sample point may be far off and another root will be found (remember: there is an infinite number of them).

OK, and what's to be learned? Do not throw anything you don't know in any automatic device :-)

Edited to merge two postings.

Edited: 31 Aug 2012, 6:38 a.m. after one or more responses were posted

Quote:
No limit on labels? but the initial label at the top only allows one alpha letter entry.

if you can only have 27 programs that means each program needs to use average of a little over 1kb. That's fairly sizeable programs. i don't think most programs use more than 1/4 or 1/2 kb.

You have two statements.

1. "initial program labeling can only be one letter from A to Z" - It is true.

2. "you can only store 26 programs" - it is false

Regarding program sizes: my average program on HP-35S is approx 2.5KB, it comprises of about 450 lines and contains approx 30 number constants. Your mileage may vary.

I am sure he is ROFLing all the way. This is a perfect example of "know your maths and know your machine", otherwise GIGO. This function is very flat in the region of the roots. E.g. the 35s will find any solution from approximately 1.55 to 1.59 acceptable due to the 12 digit precision. The guesses have to be reasonably close to the desired root as well (1.4 to 1.9), otherwise the solver could get to a point where it doesn't converge (it gets the same non-zero answer for two values with a small delta) and gives up.

Those are interesting posts that I missed, with PCB photos in that thread. It's interesting that the HP 35S hardware designers used a crystal for the system clock. Perhaps there was some consideration of giving the 35S some clock/calendar functions.

The crytal is not used for the system clock, but for display refresh and keyboard scanning. The processor clock frequency is programmed by R1.

Here is a discussion on it: HP 35s (and 42s) Crystal replacement.

Thanks, Bart. That's another 2008 thread that I missed.

It reports crystal use in the HP 42S as controlling system clock, and crystal use in the HP 35S as you stated. That seems to be yet another quirky thing about the 35S.

Quote:

You have two statements.

1. "initial program labeling can only be one letter from A to Z" - It is true.

2. "you can only store 26 programs" - it is false

Regarding program sizes: my average program on HP-35S is approx 2.5KB, it comprises of about 450 lines and contains approx 30 number constants. Your mileage may vary.

But how can you have multiple independent programs running under each initial label. I guess you can do XEQ A001 or something like that if you have a sublabel LBL under each main label? It definitely get very confusing eventually keeping track of all the different line numbers... for each subroutine.... But I guess most people really never have more than a few programs let along 26 programs..

Quote:
It is manageable. For example the curve fitting programs in chapter 16 of the manual use several labels, I have combined them into 1 label: curve fitting program for the 35s

I looked at your program. I suggest that you should change the sequence of operations so that the data is entered and stored before the type of fit is selected.

Quote:
But how can you have multiple independent programs running under each initial label. I guess you can do XEQ A001 or something like that if you have a sublabel LBL under each main label? It definitely get very confusing eventually keeping track of all the different line numbers... for each subroutine.... But I guess most people really never have more than a few programs let along 26 programs..

What you should do is constrct a menu a the beginning of the master program. Something like this will do for three sub programs AAA, BBB, and CCC.
```Z001 LBL Z
Z002 SF 10
Z003 EQN AAA=1, BBB=2, CCC=3
Z004 CF 10
Z005 1
Z006 x=y?
Z007 GTO Z017 the line number for the start of program AAA
Z008 x<>y
Z009 2
Z010 x=y?
Z011 GTO the line number for the start of of program BBB
Z012 x<>y
Z013 3
Z014 x=y?
Z015 GTO the line number for the start of program CCC
Z016 GTO Z002  to try again if the user didn't enter 1, 2 or 3
Z017
```

Edited: 30 Aug 2012, 10:41 p.m.

That might be fine if these are related subprograms and subroutines, but if they are all completely not related to each other, then we might definitely have a mess on our hands.

Personally, I doubt anybody having 26 completely independent programs. There will always be some classes (possible).

Quote:
But how can you have multiple independent programs running under each initial label. I guess you can do XEQ A001 or something like that if you have a sublabel LBL under each main label? It definitely get very confusing eventually keeping track of all the different line numbers... for each subroutine.... But I guess most people really never have more than a few programs let along 26 programs.

Quote:
That might be fine if these are related subprograms and subroutines, but if they are all completely not related to each other, then we might definitely have a mess on our hands.

I use 15 labels and have used approx 15kB on my 35s. With the 35s I have a piece of paper where I write the label and the program. This is either in the form of "D: Pauli's game" or "Z002: R->P ; Z015: P->R".

Let's say labels can have 2 alpha characters, then it could become: "AD: Pauli's game" or "ZA: R->P ; ZB: P->R". I really don't see any less confusion keeping track of it all. I am going to need to keep notes anyway to remember the now 676 possible program labels.

OK, so I am averaging 1kB per label, so theoretically I could run out of labels before running out of memory. However, the calculator needs free RAM to do it's own calculations (e.g. the manual states the integrate function is particularly memory hungry). Also free RAM is needed to run the programs, particularly if they make use of functions like solve, integration or use indirect addressing.

I am not saying things are ideal on the 35s, but in this case "where there's a will, there's a way", or rather "there is a way, do you have the will?".

Thanks, sounds like a sensible thing to do. I'll look into it when I have some time.

I did some playing around with the function. It's not only flat at the root, it's damn flat: the first 5 derivatives of the function are all zero at the root. No wonder that numerical solver algorithms using the derivative of the function get in trouble. The only scheme I'm aware of that can reliably solve such an equation must use bisection or a similar approach and the first two guesses need to bracket the solution. Even then, any 'solution' which evaluates to (almost) zero in the given accuracy is acceptable

As posted above yesterday d:-)

Quote:
Thanks, sounds like a sensible thing to do. I'll look into it when I have some time.

Consider adding a best fit option by comparing the correlation coefficients. See the HP-48s for an example.

Also consider calculating and displaying the residuals.

Both of these options are easy if you enter the data first.

Quote:
what about inv tan (inf) and tan (pi/2) ?

The CAS CX does handle those cases too.

Just entering tan(pi/2) gives "undef" but the following work:

```tan^-1 +oo -> pi/2
tan^-1 -oo -> -pi/2
limit(tan(x),x,pi/2,+) -> -oo
limit(tan(x),x,pi/2,-) -> +oo
```

cool. should wrk since derive CAS does give correct answer ...