Is there anything the 15c can't do compared to the 35s?



#2

I know people here heap scorn on the 35s, but its been a good calculator for me doing maths. Would the 15c replace it for daily usage?

Daniel


#3

AFAIK, the only significant item is matrix math. Otherwise the 35s beats it on memory, two line display and alpha characters. The new 15C LE is probably faster as well. The main difference is keyboard quality IMO. Also the 35s is very buggy, whereas the 15C is totally solid in this regard.

Edited: 1 Sept 2011, 8:04 p.m.


#4

I havnt started doing linear algebra on the 35s yet. What is it missing that the 15C has?

The reason Im asking all this is it takes a while to learn where things are on a new calculator!


#5

Like I said, about the only significant item is matrix math, which includes vectors. The 35s has far more features, and is an extension of the 32s, 32sii line. If you are happy with the 35s, then there is no reason to get a 15c. Most of us are getting it for nostalgia and because it has a unique form factor. Fact is, my 15c spends most of its time in its slip case, while I use my 32sii far more, and just got a nice 32s which I plan to use a lot as well. I don't use my 35s much because of all its annoying issues and lower quality keyboard and display.

#6

Can't think of anything right now, except for base conversions. But then I think my simple base conversion program for the 15C was much easier to use. The HP-35S is the only HP calculator I regretted buying, so much I soon gave it away...

The HP-15C is smaller, yet its performance is way better :-)

http://www.youtube.com/watch?v=devOI5sFDJk&feature=pyv

Edited: 1 Sept 2011, 8:12 p.m.


#7

Quote:
But then I think my simple base conversion for the 15C was much easier to use.

Time to start agitating for an HP-16C LE reissue, I think. ;)

Quote:
http://www.youtube.com/watch?v=devOI5sFDJk&feature=pyv

"This video is not available in your country"? What gives?

Best,

--- Les Bell

[http://www.lesbell.com.au]


#8

I very much doubt you will *EVER* get that--although I would buy one... or two... or three...


#9

Me too!


#10

Is to have the 15c LE sell out very very quickly.

That will speak louder than anything else.


#11

I doubt that will be sufficient. Anyway, for the time in between use the WP 34S :-)

#12

Quote:
"This video is not available in your country"? What gives?

It's a local Fiat Cinquecento ad. A poor short performance by a 6' 3" tall actor is compared against Dustin Hoffman's. I didn't know it was not universally available, sorry!

Gerson.


This might work.


Edited: 1 Sept 2011, 9:38 p.m.

#13

Quote:
Time to start agitating for an HP-16C LE reissue, I think. ;)

From last speaking with Cyrille, it will remain a dream, at least for HP.

Patrice

#14

IMHO the short answer is "yes".

The 35S does have some features (such as binary arithmetic--even if badly implemented) that the 15C does not have. There was a voyager (16C) designed just for this purpose and it would run rings around the 35S's binary math capabilities. The 35S has more memory and possibly a slightly more powerful programming control set and it has replaced key codes with mnemonics (which is very nice). The 35S can be used as an algebraic calculator though most here (myself included) would not consider this an advantage. But in general the 15C can do everything that the 35S can do and with the updated processor it can do it faster.

Just my 2 cents and I am sure others will chime in <g>.

Cheers,

-Marwan

#15

Can the 15C be used in the test environments for which the 35s was specifically designed?


#16

Certainly not on the FE/PE/PS tests. I suppose it is possible that NCEES could add the 15c to their "approved calculator list", but they have not been too responsive to concerns about their policy and seriously doubt that they will care to add another approved calculator. I think they would prefer to get it down to one approved model, to make it super easy on their proctors.

#17

In my opinion, the programming capabilities of the 35s are superior to the 15c. Lots of labels, two index registers, alpha dislay of functions instead of key codes, ability to display alpha prompts, etc. But the 15c will make a fine daily use calculator. Other than entry and display, and ability to directly store and recall complex values, the 15c has better complex number support.

edit - remembered that the 15c cannot directly store and recall complex values.

Edited: 4 Sept 2011, 10:56 a.m. after one or more responses were posted


#18

Quote:
Lots of labels, two index registers, alpha dislay of functions instead of key codes, ability to display alpha prompts, etc.

The scale is unbalanced by
these bugs and features, IMHO. A real pity, most of them could have been easily addressed...


#19

This bug list is only 50% accurate as discussed ad-nauseum previously!


#20

Which items on the 35s bug list aren't correct? I confirmed them before I added them so they all were bugs. If some have subsequently been fixed, I'd like to know so I can update the list.

Since I am not about to purchase a new 35s, I'd prefer a couple of different people run through the list with a recent 35s if possible to avoid typing and interpretation error arising.


- Pauli


#21

I think snaggs is referring to a thread a few weeks ago in which he "debunked" some of the reported bugs.


#22

Yes, bugs has been used to describe "doesn't do it like my old calclator". There are clearly some thing on that list which could have been done better, but theyre not bugs, just mildly inconvenient.

I dont find the arrow keys a "bug", I like them. The keybord is not as good as a Pioneer keyboard, and keys require some more pressure, this is not a "bug", its just not as good.


#23

Are we talking about the same list here? The 35s bug list doesn't mention arrow keys, let alone calling them a problem or a bug. It also doesn't mention keyboard quality.

I will freely admit that there are seven items down the bottom (in a separate list) which are classified as a bit weird or cumbersome rather than as bugs. This is made pretty clear.

The list of nineteen items at the top are definitely bugs however. Unless some of these have been fixed in the meantime.

- Pauli


Edited: 2 Sept 2011, 8:20 a.m.


#24

Yep, heres a link for you

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv020.cgi?read=190102#190102

Ps. I crashed Windows Xp with Matlab last week with a recursive algorithm. The bug was my code, not Matlab.

#25

Certainly the 35s has issues. It was a missed opportunity that was just a ROM roll away from being a very, very good calculator.


#26

Quote:
It was a missed opportunity that was just a ROM roll away from being a very, very good calculator.

Agreed! For a while I hoped a bug-fixed version would appear, but I have quit. Truth is a few unpleased users is not enough for a ROM revision.

#27

Is that what your saying?

Or that it cant display sometihng like "A?" when using an input command as it only has 1 line?

Daniel.


#28

It can't display letters at all. Program lines are key codes. Registers are numbers. No letters anywhere.

Cheers,

-Marwan


#29

You guys must has great memories to remember where all you eqns are and what order the variables are asked for.

I did not get that impression in the forum, i wont be buying 2 then if its just going to be a show pony. I must have very different needs from some people here as I cant see how for me a 15c could replace a 35s.


Edited: 1 Sept 2011, 11:35 p.m.


#30

Quote:
You guys must has great memories to remember where all you eqns are and what order the variables are asked for.

No, they have great memories of using a 15c!
Quote:
I must have very different needs from some people here as I can't see how for me a 15c could replace a 35s.

Yes, whether 15c could replace 35s depends on the user's needs. Two different feature sets:

15c - Ease of use for everyday keyboard calculations, classic RPN programing paradigm for true HP aficionados, bug-free.

35s - Also ease of use for everyday keyboard calculations (with a few quirks), more advanced/capable programing paradigm, lots of bugs.

#31

Quote:
You guys must has great memories to remember where all you eqns are and what order the variables are asked for.

It is more a case of the 15c not having a huge amount of memory.


I don't leave programs on my 15c long. Well I do but I never remember what I last left on it. Then I clear program memory and write another quick and dirty.


- Pauli

#32

Quote:
I must have very different needs from some people here as I cant see how for me a 15c could replace a 35s.

Anyone with qualification in a scientific or engineering discipline would immediately recognize that the 35S has no competent or coherent capability in the complex domain. It's a fool's toy.

That alone disqualifies the 35S as an acceptable calculator for any but the most trivial uses.

The 15C is second (though a distant second) only to the 42S as a complex domain RPN calculator.

Evidence is that there are few knowledgeable people who would choose a 35S over a 15C.

Edited: 2 Sept 2011, 1:55 a.m.


#33

Quote:
The 15C is second (though a distant second) only to the 42S as a complex domain RPN calculator.

What about the 34S???? It is the only one of the three with complex gamma built in e.g. :-)


- Pauli


#34

When I saw that 34s does LambertW and Gamma on complex numbers in the same consistent way as it does them for every function, I was blown away! :)

#35

Can you give me an example of a problem that can be solved on the 15C (or 42s) that can't on the 35s?

I have a 42s emulator until my in-the-flesh 42s arrives. So I can give it a go on both and finally understand what the problem is..

Sorry, but Im not just being contrary, its just that every day I have a good experience with what I can do with the 35s! For example, from a worded problem I was working through for revision 10 minuteds ago I came up with an equation for mortage payments;

P=(1+U/12)^n*A-((1-(1+U/12)^n)/(1-(1+U/12)))*D

where U is the annual interest rate, A the inirial amount, D the payment, and P is the remaining mortage after n months.

I could just pop this into EQN, and solve for N when with P=0.

Im not sure how long that would take on a 15c, could you do it during a exam?


#36

I guess if you want to spend the time programming the 35s, you could do an 8x8 determinant, but you can do that out of the box on the 15c.

Not possible unless you write a long, complicated program on the 35s.

This is probably unfair, but you can't find the cosine of 89.99999 on the 35s in degrees mode, but you can on the 15c. (I know, that's below the belt).


#37

You can, its just not as accurate. Add another 9 or remove one and its fine. It is however more accurate except for those specific values.

I do agree however, that given 30 years have passed in computer science since the 15c, we do have better algorithms out there. We could have had our cake and et it to!

As for the 8x8 determinant, thanks for the example. Ill have a play with that and can now see for myself whats missing.

Daniel


#38

No problem. I do agree that specifically choosing an example where the 35s has a bug is highly unfair, but there are a good number of places where you can run into problems with the 35s, per the list.

Complex number support is better and "more native" on the 15c LE than the 35s.

Matrix work is much better on the 15c LE than the 35s.

Speed is much better on the 15c LE than the 35s.


#39

Thanks for some specific examples. It really seems that alost every model has something to offer that others dont.

It would be nice if HP would make one calculator that is includes all these small advamces in the one machine.

PS? Wjilst googling Arcsin on the HP35s I stumbled across this awesome site! Chocker block full of some very complicated problems.

http://homepage.mac.com/nwjh/HP-35S/index.html

#40

Quote:
As for the 8x8 determinant, thanks for the example. Ill have a play with that and can now see for myself whats missing.

If you do you will find that the 35s outperforms the 15c for a simple reason -- more digits in the mantissa.
#41

Quote:
I guess if you want to spend the time programming the 35s, you could do an 8x8 determinant, but you can do that out of the box on the 15c.

Not possible unless you write a long, complicated program on the 35s.


The program has aleady been written. See Stefan's HP-35s Matrix Multitool thread of November 2, 2007, near the top of Archive 17, or go directly to it at http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv017.cgi?read=127861. You will also find some material in that thread which compares the results from Stefan's program and those from the HP-15C and the HP-41 Advantage module.

You can also look at Article 886 where I wrote some additional programming to do other matrix tasks using Stefan's program for input.

Palmer


#42

Ah, or type in a long program. :-)


#43

Quote:
Ah, or type in a long program. :-)

And with that comment you have recognized the real deficiency of the 35s for many users -- the absence of an input/output capability. The other major deficiency with respect to entering programs is the unreliability of the check sum.

But wasn't the absence of an input/output capability recognized as a requirement for use on NCEES tests? I suggest that trying to combine the development of an NCEES calculator with the release of a device commemorating the original HP-35 led to some compromises that left all users somewhat unhappy. I also suggest that the push to release the HP-35s at the HP-35 anniversary may have led to an earlier release than was justified by the development status at the time.

Edited: 3 Sept 2011, 2:37 p.m.


#44

Quote:
But wasn't the absence of an input/output capability recognized as a requirement for use on NCEES tests?

Yes, lack of I/O was an absolute requirement for NCEES approval. Lack of alpha capability was also a requirement, they either overlook or are unaware of the limited alpha capability that the 35s has via its equations.

Edited: 3 Sept 2011, 4:10 p.m.

#45

Quote:
Can you give me an example of a problem that can be solved on the 15C (or 42s) that can't on the 35s?

Here is a list quoted from my post of 7 August 2011.

Quote:
To claim true complex domain support, a machine must execute all of its functions that are mathematically defined in the complex domain by operating on or generating the appropriate values. For a few random examples, try that 35S to evaluate these:



1. arcsin(2)

2. ln(-2)

3. arctan(1+i)

4. cosh(1+i)

5. cos(1+i)

6. arcsinh(1+i)

7. ln(1+i)

8. exp(1+i)

9. i^i

10. arccosh(0.5)



The 42S handles all these (as do the RPL machines)...the 15C is similar but slower, though with its limited display what is child's play on the 42S requires some mental effort to keep things straight on the 15C...


#46

The 35s can evaluate several of the examples on your list:

 1.  cannot do
2. can do. You must enter -2 as -2+i0, but you must do the
same on wp34s for example.
3. cannot do
4. cannot do
5. can do directly, i.e., key in 1, i, 1, press COS, see answer.
6. cannot do
7. can do directly, i.e., key in 1, i, 1, press LN, see answer.
8. same as 7 above, does it just fine
9. can do directly, press i, enter, y^x
10. cannot do

I agree that it should handle all of the above directly, but the functions it has are quite useful.

edit - also can do no. 5 (Thanks Dieter, I missed that one.)


Edited: 2 Sept 2011, 3:46 p.m.

#47

Well, the 35s cannot do hyperbolic and inverse trig in the complex domain. Which accounts for half of your examples. You could have chosen all ten examples that way to show what a completely unuseable device the 35s is. ;-)

In fact, with the mentioned exceptions, the 35s handles all other examples easily. Even easier than the 15C since you don't have to remember things like the use of flag 8 or the meaning of a small c in the display. ;-) The 35s has a more direct approach: enter a real number and the result will be real (or an error). Enter a complex number (maybe with a zero imaginary part) and the result will be complex.

Your examples:

 -2i0 ln   => 0,6931 i 3,1416
1i1 ln => 0,3466 i 0,7854
1i1 e^x => 1,4687 i 2,2874
1i1 cos => 0,8337 i-0,9889
And finally, ultimately elegant:
  i ENTER y^x => 0,2079 i 0

Yes, I like it. :-)

Dieter


#48

Thanks Dieter, they really should edit the "bugs" listed which is bandied around so authoritively.

As you have demonstrated, many so called bugs are just "doesnt do it like my old calculator". I like you think the 35s complex mode makes sense and is easy.

Of course it would be nice to have it switch automatically into complex mode for root -1. The 32sII couldnt do complex hyperbolics either, yet these are sold for big $$ on ebay and not bandied as unusable.


#49

Quote:
Thanks Dieter, they really should edit the "bugs" listed which is bandied around so authoritively

There is nothing in the 35s bugs list article involving any of these computations or anything even close to them.

In fact no complex operations are even mentioned in the bug list.

There is one mention of a complex number and this is in bug #19 where the presence of a complex number in a register prevents the linear solver from working. Definitely a bug but not one in the complex function set.

That all said, I'd be surprised if there weren't numeric issues in the complex functions.

Maybe you should read the bugs list article before denigrating it. As for editing it, as I've already pointed out, I'm quite happy and willing to do so. My criteria is that more than one person reproduces a bug not being present anymore.


- Pauli


#50

A few remarks regarding the 35s bug list.

First, I would not consider the fact that ALL mode often requires scrolling a bug. It's intended this way, simply because ALL does what it says: it displays *all* digits of the mantissa. Due to the limited space (14 displayable digits) this cannot be done including the exponent. Yes, that's certainly not nice (and I really appreciate the 34s ALL nn mode), but it's the way the 35s is supposed to work. This feature should be moved to the section of "items that cannot be classified as bugs since they are documented or work correctly", which is where it belongs.

Then there is the cos/tan issue (bugs 2 and 3) for angles close to 90 degrees.

Let's take a closer look at this.

                       correct mantissa         HP35s           error
----------------------------------------------------------------------
cos(89,9) 1,74 532 836 590 1,74 532 836 590 0
cos(89,99) 1,74 532 924 313 1,74 532 924 306 -7D 12
cos(89,999) 1,74 532 925 191 1,74 532 925 091 -1D 10
cos(89,9999) 1,74 532 925 199 1,74 532 925 -2D 10
cos(89,99999) 1,74 532 925 199 1,74 532 92 -5D 9
cos(89,999999) 1,74 532 925 199 1,74 532 9 -3D 8
cos(89,9999999) 1,74 532 925 199 1,74 532 -9D 7
cos(89,99999999) 1,74 532 925 199 1,74 532 925 199 0
cos(89,999999999) 1,74 532 925 199 1,74 532 925 199 0
cos(89,9999999999) 1,74 532 925 199 1,74 532 925 199 0
The problem seems to be the loss of digits as the argument moves closer to 90 degrees.

So, instead of full 12 digit precision the result may carry only 11 to 6 valid digits. The remaining digits are simply missing. Yes, precision is lost. But are these results completety "dud", as the bug list calls it? All results are correct within -1 ULP of the displayed result.

By the way, I now remember a discussion on the 34s quantile functions, proposing to return a result with less than the full 16 digits, say: 10 or 8, if a full precision result would take too much time or effort. ;-)

The loss of precision in the cosine routine also affects the tan-results that are obviously evaluated by dividing sine by cosine:

                       correct mantissa         HP35s           error
----------------------------------------------------------------------
tan(89,9) 5,72 957 213 354 5,72 957 213 355 +1D 12
tan(89,99) 5,72 957 789 313 5,72 957 789 338 +2D 11
tan(89,999) 5,72 957 795 072 5,72 957 795 401 +3D 10
tan(89,9999) 5,72 957 795 130 5,72 957 795 785 +6D 10
tan(89,99999) 5,72 957 795 131 5,72 957 812 200 +2D 8
tan(89,999999) 5,72 957 795 131 5,72 957 877 856 +8D 7
tan(89,9999999) 5,72 957 795 131 5,72 960 832 397 +3D 6
tan(89,99999999) 5,72 957 795 131 5,72 957 795 131 0
tan(89,999999999) 5,72 957 795 131 5,72 957 795 131 0
tan(89,9999999999) 5,72 957 795 131 5,72 957 795 131 0
These tan-results returned by the 35s can easily be obtained by manually dividing the sine values by the cosine as shown above.

Example:

tan(89,999)
= sin(89,999) / cos(89,999)
= 0,999999999848 / 1,74532925091 E-5
= 5,72 957 795 400 E+4
 
tan(89,99999)
= sin(89,99999) / cos(89,99999)
= 1,00000000000 / 1,745329 E-7
= 5,72 957 877 856 E+6
 
tan(89,9999999)
= sin(89,9999999) / cos(89,9999999)
= 1,00000000000 / 1,74532 E-9
= 5,72 960 832 397 E+8
As you see, we get exactly the same results as returned by the 35s. In fact, the 35s may even be slightly better due to the internal 15-digit arithmetics.

So, the loss of precision in the tangent calculation simply is a result of the digit loss in the cosine routine.

There are other examples of earlier HP calculators showing loss of precision in their trig functions. Take a look at the HP-41 (and most probably the HP-67/97 and 15C as well) in radians mode and see how the results of the good old times compare to today's:

                  mantissa as returned by              correct result
"good old HP" HP-35s
-----------------------------------------------------------------------
sin(3,1415) 9,26 535 898 7 9,26 535 896 582 9,26 535 896 607
sin(3,14159) 2,65 359 2,65 358 979 2,65 358 979 324
sin(3,1415926) 5,35 9 5,35 897 9 5,35 897 932 385
sin(3,14159265) 3,59 3,58 979 3,58 979 323 846
sin(3,141592653) 5,9 5,89 793 238 463 5,89 793 238 463
sin(3,141592654) -4,1 -4,10 206 761 537 -4,10 206 761 537
Should we also consider the 41/67/97/15C result in the left column to be "dud"? Is this also known as a bug in these calculators, returning "dud" sine results for arguments close to Pi? It's the same as with the 35s: in sin(3,1415) the last two digits are wrong, and as the argument gets closer to Pi, precision drops to merely two valid digits. As opposed to the 35s who returns at least six. ;-)

So, let's be fair.

Dieter


#51

Explain why scrolling is needed on the 35S when there is no scrolling needed on the 33S.
http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv017.cgi?read=125421
Still consider it not a bug?


#52

Hi Paul,

Quote:
Explain why scrolling is needed on the 35S when there is no scrolling needed on the 33S.
http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv017.cgi?read=125421

You will find the answer in the first message of that thread: The 33s simply does not display all digits when in ALL mode. In the example given, it displays just 4,2631597346E-7 (eleven out of twelve digits), while the 35s displays all of them and adds the missing 3 at the end - which is the reason why the final 7 of the exponent moves out of the display.

There are two ways to implement a display mode like this: first, the calculator can do what the mode says: display all digits. Since the display has 14 places while the device uses a 12-digit mantissa, it is clear that this can require scrolling. On the other hand, the calculator may display less than all 12 digits to make the value fit in the display. Since up to six display digits can be occupied by signs, an E and a three-digit exponent, in the worst case only 8 out of 12 digits can be shown. So that's an ALL command that doesn't show all digits. Maybe it should better be named STD or FLOAT or something like that. ;-)

In both cases it's a tradeoff. Actually I prefer the second approach since the full mantissa can be displayed by using MANT or SHOW, but the 35s method is another valid option.

Quote:
Still consider it not a bug?

It's the way HP chose the 35s to work. No, I don't like it, but it still is not a bug. ;-)

Dieter

#53

Quote:
But are these results completety "dud", as the bug list calls it?

The bug list just says "dud" and this they are, they are both incorrect and they could easily be better. I wouldn't say these results are "completely dud" however.


Quote:
By the way, I now remember a discussion on the 34s quantile functions, proposing to return a result with less than the full 16 digits, say: 10 or 8, if a full precision result would take too much time or effort. ;-)

Yes. The difference being that this would have been documented as a known defect if it came to pass. Besides, with your able assistance, we fixed these ;-)


Quote:
The loss of precision in the cosine routine also affects the tan-results that are obviously evaluated by dividing sine by cosine:

I suspected as much.


- Pauli


#54

Quote:
Quote:
The loss of precision in the cosine routine also affects the tan-results that are obviously evaluated by dividing sine by cosine:

I suspected as much.


That was also my opinion when I first noticed the tan bug on the HP-33S five years ago. However, according to an analysis by Karl Schneider the HP-33S uses the CORDIC algorithm to compute the trigonometric functions, which would imply tangent is computed first.

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv016.cgi?read=103989


Gerson.

#55

There are double standards and a witch hunt by some re: the 35s. Outisde of 89.99999 the 35s is more accurate than the 42s for other trig values.

Its just a different algorithm. The "buglist" as published is somewhere between propoganda and hysteria, and only 50% accurate.

Daniel.


#56

Quote:
The "buglist" as published is somewhere between propoganda and hysteria, and only 50% accurate.

You keep saying this. Put your money where your mouth is and tell us which nine items on the bug list aren't bugs.

I'm happy to accept that the COS and TAN items are manifestations of the same bug. The list is eighteen bugs if we accept this.


I'm willing to accept Dieter's suggestion that the ALL display problem isn't strictly a bug but an annoyance.


Eight more please.


- Pauli


#57

Ok, though searchig the archive is a pain;

3. Not a bug
4. What does meaningless mean?
6 dont get it, works either way
7 is just a limit
9, shows correct value
15. Just did it and pressed run 20 times, always same answer

-466.9270

Then I just got bored

So sorry, your right, more than half might be accurate, though a fraction of that relevant. I guess you can say the buglist is buggy.


Edited: 6 Sept 2011, 6:38 a.m.


#58

Quote:
...searchig the archive is a pain;

3. Not a bug


Use Google instead. For instance, the search key site:www.hpmuseum.org 35S + checksum will return about 121 results, the first of which being

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv017.cgi?read=121069

It this is not a bug then nothing else is.

#59

Quote:
3. Not a bug

Since when can we class incorrect checksums as not a bug? That re-classification of yours would turn the whole computing world upside-down!

Quote:
4. What does meaningless mean?

OK, so perhaps "inconsistent" or "incorrect" would have been more appropriate. However, the intended meaning is quite clear from the context - one synonym for "meaningless" is "useless", and that is exactly what an inconsistent program checksum & length is.

For the implication of these 2 bugs, see the italics in the 'remarks' section of my post below on complex arcsin & arccos.

Regards,
-B

#60

Quote:
3. Not a bug

You are kidding right? Enter a program. Take the checksum. Clear the program. Enter the program anew. Take the checksum. This time the checksum is different. How can that possibly not be a bug??? You have a very "interesting" definition of bug if so.

The program needs to have numbers and/or expressions in it and as far as I'm aware nobody has isolated the cause of the problem.


This is relevant when you want to share a program with someone else. I'll use this program as an example. After all that typing you'd like to know that you've entered it correctly. The checksum should help here only it doesn't. My records list the checksum I got for this program as EB55. You won't get the same.

The sharing of programs and pieces of code is one of the great strengths of this community. Open source well before that term was coined.


Quote:
4. What does meaningless mean?

The size returned for programs can be incorrect. Similar conditions to #3 above. Taking that same program, the reported length was 3331 bytes. Enter it and the free memory drops by close to 8kb. One (or both) of these two sizes is incorrect. The program size certainly is wrong.

Again this is useful when sharing programs as a validity check. Also useful if you want to add another routine to your calculator and you'd like to see if it will fit -- not such a big issue for the 35S with its loads of RAM.


Quote:
6 dont get it, works either way

Can someone else please confirm this and I'll add a note saying bug fixed in recent versions. It definitely was a bug but might not be anymore.


Quote:
7 is just a limit

But still a bug I think. Why can't I enter a new label here? I can delete an earlier step, enter the label and then add the step back in and things are happy. Still, I'm will to concede this one as weird and unusual behaviour rather than a bug.


Quote:
9, shows correct value

Only the value scrolls sometimes and you can no longer see the first digit. As Dieter pointed out and as I mentioned earlier, I'm willing to say this isn't strictly a bug and I'd already given you this one.


Quote:
15. Just did it and pressed run 20 times, always same answer

-466.9270


#15 one doesn't return a result. I assume you mean #14 :-) Again, can someone confirm this and I'll note it as fixed in recent firmware.


Quote:
Then I just got bored

I'm not surprised, the next one #15 is an infinite loop hang :-)


I manually confirmed all the bugs except the first one when the list was compiled and amended soon after the release of the 35S. They all definitely exist in my 35S. Some might have been addressed in the meantime.

However, I'm not about to go out and buy a recent model 35S just to validate that these bugs do or do not still exist.


- Pauli


#61

HP-35S SN: 74601701

In my unit both #6 and #14 are still bugs. Note that for number 6 in RADIX, mode in a program RADIX. shows as RADIX, and RADIX. shows as RADIX, so it is wrong in BOTH directions. Appears to be reversed.

Cheers,

-Marwan

#62

Quote:
pressed run 20 times, always same answer

-466.9270


In a recent thread you wrote that you tried to confirm this bug but weren't able to enter the equations as equations but rather did it by keystroke programming. If this is still the case, you won't see the bug that only shows when having entered EQNs. Read the manual concerning EQN entry before always repeating the same mistake!

#63

Quote:
Well, the 35s cannot do hyperbolic and inverse trig in the complex domain...You could have chosen all ten examples that way to show what a completely unuseable device the 35s is. ;-)

The vast complex domain capability of the HP 35S is only "half-vast". :-)

It is sufficient to discredit HP 35S firmware design if these many examples of inconsistent or incomplete complex domain competency can be cited. They aren't bugs...they simply indicate HP's deliberately indifferent and less than mediocre HP 35S firmware design.

HP 35S firmware design, entirely new 20 years after HP 42S introduction, is grossly inferior in general function and capability. Almost all of the functionality of an improved HP 42S could easily have been designed into the HP 35S for only the cost of developing the firmware!

The HP 35S is from the start an abandoned one-shot project. Not one of the well-documented bugs has been corrected, almost five years since introduction. Most Pioneer (and other) series had firmware imperfections quickly addressed. The HP 42S had firmware versions A, B, and C in its first four years.

Quote:
...the 35s handles all other examples easily. Even easier than the 15C since you don't have to remember things like the use of flag 8 or the meaning of a small c in the display. ;-)

That's very true. I never cite the HP 15C as a good example of a generalized complex domain machine. It is the first HP that had this capability in firmware, but it is more than a little awkward to use. The HP 42S corrected this with its alphanumeric display capability and many other improvements.

Edited: 6 Sept 2011, 11:41 a.m.

#64

Complex ArcSin & ArcCos On the HP35S


To make life easier, I decided to implement a few common functions that allow for inputs resulting in complex answers, namely:

Sqrt(x), x < 0

Arcsin(x), |x| > 1

Arccos(x), |x| > 1

Log10(x), x < 0

The following formulae were used:

Arcsin(x) = -i Ln(ix+Sqrt(1-x2))

Arccos(x) = -i Ln(x+Sqrt(x2-1))

Log10(x)=Ln(x)/Ln(10)
where
Ln(x)=Loge(x)


This calculator has a more intuitive aib complex number representation, and the answers are presented as such. However, during my use with complex numbers on the HP35S, I found that it was a pain to separate the real and imaginary parts and thus also added a routine to easily separate a complex number (usually an answer of a previous calculation) into the real part (X-register) and complex part (Y-register).

Using the labels as per the listing the routines are called as follows: (x can be real or complex)

Sqrt of negative numbers: x XEQ I002

arcsin of numbers |x| > 1: x XEQ I007

arccos of numbers |x| > 1: x XEQ I025

Log10 of negative numbers: x XEQ I039

Separate the complex number in RE and IM parts: aib XEQ I046

Label	Command	Comment
I001 LBL I
I002 0i0 CMPLX SQRT
I003 +
I004 0.5
I005 y^x
I006 RTN
I007 0i0 CMPLX ASIN(x) |x|>1
I008 +
I009 ENTER
I010 ENTER
I011 2
I012 y^x
I013 +/-
I014 1i0
I015 +
I016 XEQ I002
I017 x<>y
I018 0i1
I019 *
I020 +
I021 LN
I022 0i-1
I023 *
I024 RTN
I025 0i0 CMPLX ACOS(x) |x|>1
I026 +
I027 ENTER
I028 ENTER
I029 2
I030 y^x
I031 1i0
I032 -
I033 XEQ I002
I034 +
I035 LN
I036 0i-1
I037 *
I038 RTN
I039 LN CMPLX LOG10(x), x<0
I040 0i0
I041 +
I042 10
I043 LN
I044 ÷
I045 RTN
I046 STO A Extract RE & IM parts into X(RE) & Y(IM) regs
I047 ABS
I048 RCL A
I049 ARG
I050 SIN
I051 *
I052 RCL A
I053 ABS
I054 RCL A
I055 ARG
I056 COS
I057 *
I058 RTN
Remarks

Program length and checksum are not provided as they make no sense on this calculator.
(Note to snaggs: here we sharing programmers usually put the length & checksum so that others have some confidencen that they have typed it in correctly - bummer, doesn't work on the 35s)
The two-tiered complex number system of the 32S means that in effect you are left with a two-level stack when doing complex maths. This means some added manipulation and use of storage registers.

In contrast, the 35s implementation of complex numbers means a full four-level stack is available for complex maths. With the added feature of the keytop i, I find complex number entry easier than the 42S. Some functions on the 35s can be made to do complex calculations by adding 0i0 to the arguments (e.g. y^x and Ln(x) ).
    Please note that:
  • I have not extensively tested these functions, just a few random points
  • Accuracy of the tested points was 9 digits or better compared to results on a real 42S.
I’m sure there are ways to optimise this. Any suggestions/comments welcome.


Mike,
So now you can do some complex stuff on the 35s :-), and you should still have plenty space of other programmes (the same functions were similarly programmed on the 32S and used 112.5 bytes)

I'm sure it shouldn't take too much more to do arctan and the hyp functions ;-)

-B

#65

Thanks Bart, nice work!

#66

I've found the following expression to be more accurate to calculate arc cos in the complex domain:

acosh z = Ln[z + sqrt(z-1) sqrt(z+1)]

Reason being the branch selection for SQRT does make a difference, and that gets lost if you pre-select it by compacting the formula before hand.

Cheers,
'AM.


#67

Thank you Ángel, it is always good to have input from a master maths programmer :-).

Thanks,
-B

#68

If you are seriously interested in writing programs on/for a calculator, I strongly recommend that you skip past the 35s and get a 50G. There is no I/O on the 35S, nor the 15C, nor the 42. In our modern world, why the hell would anyone want to start out new with something like that?!! Remember, many of us "experts" are old-timers who learned to use (and appreciate) these old non-I/O machines back when there weren't any other low-cost alternatives. (Excepting the Sharp programmables. but that is another story).

I know you like the 35S. It is somewhat cool. But it is also such a damn shame that it wasn't properly finished.

You will do yourself a big favor if you cut and run at this point. Heck, skip the calculators entirely and go right to Wolfram etc....

Edited: 2 Sept 2011, 5:16 p.m.


#69

Well, we cant take Matlab or Wplfram into exams, we can take any calculator we like.

As for the 35s vs 50g. I bought a 49g+ years ago when it came out. I couldnt even figure out how to do basic things like nPr on it. It has remained in my drawer unused.

I like the fact that so many functions on the 35s are on the keys. I will have a crack at the 48 programming again over the Christmas holidays, direction fields would be nice. But for routine calculating I find he 35s so easy!

Ive already put 250 hours through my 35s.


#70

Quote:


Ive already put 250 hours through my 35s.


Hi snaggs,

you keep a logbook or have an hourmeter to clock usage on your 35s? ;-)

hpnut in Malaysia

#71

Quote:
There is no I/O on the 35S, nor the 15C, nor the 42.

That's not at all true for the HP 42S. It has I/R printer output, and it has audio beep output. These are great advantages. The audio beep in particular I've found to be very useful to prompt for user input during a long-running program.

I suspect you refer actually to memory I/0. The only time I've ever lost anything on any of my HP 42S units is when I was fooling around with that remarkable built-in memory scanner/debugger. I've had several 400-step programs stored in my daily-use HP 42S that have been there for 14 years.

But...memory I/O would be nice.

#72

With all due respect, your dismissal of the 35S as a "fool's toy" and acceptable only for trivial uses is way off base. While the 35S is certainly far from the best that HP has produced, it is still very usable.

Anyone with qualification in a scientific or engineering discipline should also know that not everyone in science or engineering needs complex number support. I'm a civil engineer with more than 30 years experience and, except for fooling around with them on my 42S, I haven't used complex numbers since college.


#73

Quote:
With all due respect, your dismissal of the 35S as a "fool's toy" and acceptable only for trivial uses is way off base. While the 35S is certainly far from the best that HP has produced, it is still very usable.

Anyone with qualification in a scientific or engineering discipline should also know that not everyone in science or engineering needs complex number support. I'm a civil engineer with more than 30 years experience and, except for fooling around with them on my 42S, I haven't used complex numbers since college.


Well said, Fred.

Don't want to speak for snaggs, but I think I understand his points. For the most part, as I see it, the posters on this Forum tend to be super critical. Not only of calculator design, but as to technical nomenclature, even to the point of sometimes parsing each others sentence structure. And snaggs and you are right about some of the bugs being meaningless in the real world of everyday engineering calculations. The criticisms from this group have to be taken in context. The 35s is a useful calculator, just disappointing compared to the quality expected from HP. And the biggest disappointment is, no fixes being made.


#74

The problem is that we oldsters have long memories of the great past products that set HP apart from all the other calc manufacturers. I remember engineers cursing the crummy keyboards on their cheap but affordable calcs, while I was in calc heaven with my HP-35 that cost me 2 weeks takehome pay. Today's market is intolerant of such high pricing, and the result is something like the HP-35s. It's not that the HP-35s is so terrible, but that the older stuff was really good. I recently added an HP-32S to my stable, and it's general quality is massively better than the HP-35s. I had no problem paying $100+ for it, but I can't see any college student doing it. BTW, I still have my original HP-35 and it still works great.


#75

Quote:
It's not that the HP-35s is so terrible, but that the older stuff was really good.

You hit the proverbial nail on the proverbial head.

#76

Agreed.

#77

What you say Michael makes perfect sense. One good thing, is HP seem to have learnt from the backlash, look how tne 15c relaunch has been handled. Give the hardcore users a free calc and find the ellusive bugs.

Maybe there is hope that a 35sII could be successfully executed to its full potential,

As for cursing crummy keyboards, the 35s is still a bastion of quality compared to the casio FX 82 AU plus recommended for my course.

Does this count as double shot keys? Help me!!

Edited: 2 Sept 2011, 6:46 p.m.

#78

Martin....

I agree. I can't understand why anyone would imply that complex number support is the key (only?) criteria for the usefulness of a scientific calculator. Obviously, many scientists and engineers need complex number support. On the other hand, it should be equally obvious that many do not. To make it the key criteria is unrealistic and frankly self-centered.

That being said, I do agree that there is no excuse for not providing something like the HP-42S level of complex number support on a modern high-end scientific calculator. But the HP-35S is NOT high-end but mid-level. For me, root solving and linear regression are far more important than complex numbers, but that's just me.

As great as HP calculators have been over the years, none have been perfect and none have had exactly the mix of features I would have specified. Since the market is not homogeneous, this makes perfect sense. That's why I like progammability: I can add the capabilities that HP "left out."

BTW, my experience with HP calcs started with an HP-35 that my dad (a high school chemistry teacher) bought right after it was announced. I was in 9th grade. I bought it from him when he upgraded to the HP-45. I then bought an HP-55 as a senior in high school, followed by a 34C in college and a 41CV and a 41CX early in my engineering career. My everyday calculator is a 42S I bought in 1989. I also have a 48G+, a 32Sii, a 35S, and several others. I have done a lot of programming on the 41CV/CX and 42S and a little on the 48G+. (What I wouldn't give for a 41/42 hybrid, but that will never happen.)

The 35S sits on the desk in my home office as a convenience calculator. I keep a couple of simple programs and a couple of equations in it. While I know there are bugs, and the keyboard sometimes misses keystrokes, the 35S does a good job fulfilling its role as a mid-level calculator. It will never be a 41CX or a 42S and we shouldn't expect it to be.

I never could get into the 15C, as good as it is. First, after years of handholding to do calculations, I prefer the vertical format. Second, I didn't see it as that big of a jump up from the 34C like the 41 was, and it can't hold a candle to the subsequent 42S.


Edited: 2 Sept 2011, 9:08 p.m.


#79

Fred,

Quote:
I can't understand why anyone would imply that complex number support is the key (only?) criteria for the usefulness of a scientific calculator. Obviously, many scientists and engineers need complex number support. On the other hand, it should be equally obvious that many do not. To make it the key criteria is unrealistic and frankly self-centered.

I don't think I've used complex numbers since College Algebra. Did we use them in Calculus courses? I can't remember. I don't think the Forum is dominated by civil engineers [:-)
Quote:
As great as HP calculators have been over the years, none have been perfect and none have had exactly the mix of features I would have specified. Since the market is not homogeneous, this makes perfect sense. That's why I like progammability: I can add the capabilities that HP "left out."

Precisely.
Quote:
BTW, my experience with HP calcs started with an HP-35 ...

I'm an HP late-bloomer, starting with a 20s in 1993. Now have a few models...
Quote:
I never could get into the 15C, as good as it is.

Having followed the speculation and hoopla for a couple of years, I find myself being tempted to get one of the new ones, but when I really think about it, I can't imagine why I would want one.

#80

The last time I did complex number calcs for real was in the one electrical engineering course I had to take, which was in my 3rd year of college. I had the HP-55 at the time and probably used a few of the complex number programs in the Mathematics Programs book that I bought from HP. I'm certain we hit complex numbers in Calculus a time or two and definitely in that part of Physics that deals with electricity and magnetism, but beyond that I really don't remember.

The only reason I would buy an anniversary edition of either the 12C or 15C would be for the nostalgia. Most of the calcs in my modest collection are ones I use/have used for school and work and I don't collect for profit.

#81

You call the 35S a mid-level calculator, not high end, but HP calls the 35S the ultimate scientific calculator right on the packaging.
They are advertising it as a high end scientific.


#82

True, but advertising hyperbole doesn't make it so.

By comparison with other HP offerings, both historically and contemporaneously, the only time the HP-35S would have been considered high-end would be if it had been available back in the 1970s. The HP-41C and its system, released in 1979, would have immediately relegated the 35S to mid-level status. Susequent high-end HPs (42S, 28 and 48 series) would have kept it there. In today's world, the presence of the HP-50G keeps the 35S at a mid-level. The 10S looks like the low end.

I have a hunch that one of the main reasons HP has a mid-level calculator is that the 35S and the earlier 33S are approved for use on the NCEES exams for professional licensure for engineers and surveyors...but it's only a hunch.

#83

Quote:
As great as HP calculators have been over the years, none have been perfect and none have had exactly the mix of features I would have specified

I used to think that the 41 was as close as possible to that ideal, but now I know it for sure: the 41 CL is such an ideal, as it removes the only possible objection one could have held against the original 41: speed.

Add to that the ROM library built in, and you have perfection in your hands.

Just my opinion, of course :-)

Edited: 6 Sept 2011, 3:15 a.m.


#84

Quote:
the 41 CL is such an ideal

I concur! :)

Massimo

#85

Does the 41CL have multi-character labels? Alpha entry looks easy with the letters printed on the keys.

What does it have to replace the EQN button? Im usig that to store a bunch of simple equations like the binomial dsitribution and some preditor prey models.

Id miss the 2 line LCD though.

Daniel.

Quote:

I used to think that the 41 was as close as possible to that ideal, but now I know it for sure: the 41 CL is such an ideal, as it removes the only possible objection one could have held against the original 41: speed.

Add to that the ROM library built in, and you have perfection in your hands.

Just my opinion, of course :-)


Edited: 6 Sept 2011, 7:01 p.m.


#86

Quote:
Does the 41CL have multi-character labels? Alpha entry looks easy with the letters printed on the keys.

Yes it does. Alpha entry is very easy. Much nicer than the 42S, IMHO.


Quote:
What does it have to replace the EQN button?

It doesn't. No equations.


- Pauli


#87

Quote:
--------------------------------------------------------------------------------
What does it have to replace the EQN button?
--------------------------------------------------------------------------------

It doesn't. No equations.


Actually, since it includes the AECROM module, it does offer quite a powerful algebraic formulas -> focal programs converter.

Massimo


#88

My thoughts exactly, a notable pioneering implementation of Equations, worth the learning curve.


#89

How does one turn the calculator off with this module installed? Every time I press on it changes length units on me.

- Pauli


#90

If that's on your CL it's probably be due to the TURBO settings. Try it with the original speed.- The unit change is supposed to kick in only if you hold the ON key longer than what's needed for the turning-off action. It works for me.


#91

Does the 41CL use the original AECROM image or the verion that you enhanced to use the 13-digit math routines?


#92

Both are available.

Edited: 9 Sept 2011, 5:41 p.m.

#93

Quote:
Does the 41CL use the original AECROM image or the verion that you enhanced to use the 13-digit math routines?

Good lateral thinking Mark, but I did no changes at all to the ON-key interrupt, nor to the invoked code (believe me, I know better than that :-)

While it's "possible" that something happened during the changes, the ON functionallity works very well on my CL, even at higher turbo speeds BTW.

#94

Nice catch Ángel. I'm running this on my CL at maximum turbo (this is the only way I run now).


- Pauli

#95

If the HP-42S had I/O like the 41C had, it would be THE next to perfect calculator, running circles around the 41C-whatsoever. But unfortunately HP had the 48SX in the make at that time already, and they feared internal competition most probably - who would buy a sledgehammer featuring a RePeLlent programming language as long as (s)he can get a pocket sized user friendly multitool? So in this case the good was the enemy of the better, reverting a popular saying for the worse :-/

FWIW,
Walter

P.S. Exactly this I tried to post this morning, but received "Your message has been sent to the moderators for review. Acceptable messages will be posted as soon as a moderator is available. Having posts reviewed by moderators keeps the spam in check. We apologize for any inconvenience." No comment.


#96

Was it perhaps the MiXeDCaSe of RePeLlent ?

edit: No, it wasn't.


Edited: 7 Sept 2011, 5:00 p.m.

#97

Quote:
If the HP-42S had I/O like the 41C had, it would be THE next to perfect calculator, running circles around the 41C-whatsoever

Agreed, except for that "lame" ALPHA scheme (IMHO)- which Gene seems to prefer :-) If it only had followed the wp34S philosophy of filling the keyboard first and using menus only as a last resort, I'd have had much more respect for this RPN champ.

Jake


#98

Yes, save the soft-ALPHA (can't imagine how anyone would prefer it over the 41 approach) - but that's the proverbial "path not taken", much to our dismay... so what if analysis is all we can do now.

Cheers,
'AM

#99

I know the 41C alpha keyboard like the back of my hand, but I don't mind the 42S "pick board" alpha scheme. The greatly expanded character set demanded menus. You could have filled the keyboard with fixed alpha assignments without accounting for all the characters the 42S is capable of manipulating. Yes it's annoying, but XTOA for all of those characters would really have been a pain.

Nowadays I use Free42, and enjoy the freedom of keyboard alpha entry. I only have to deal with the 42S alpha scheme if and when I transfer programs to my real machine.


That would be the ultimate: a calculator featuring a slide-out QWERT keyboard. Would reduce clutter ;-) For sure that will be banned from NCEES etc. but who cares ...


The querty keyboard makes the TI 92(+) and Voyage 200 more appealing to me then the functionally identical TI-89. To make a calculator with such a keyboard pocketable, a folding or sliding mechanism would be needed. I have a Ben NanoNote on my shelf which would come close if it only had a more calculator friendly keyboard. It has enough power for a calculator application but the key labels (and key feeling) are totally inappropriate.

Quote:
You could have filled the keyboard with fixed alpha assignments without accounting for all the characters the 42S is capable of manipulating.


Well...you could fill the keyboard with the HP41 alpha characters, and also the top row "alternately" gets the soft-key menu with the remaining "special" characters. That way, regular letters take one keystroke each, and only the others would require two each. Check out http://h20331.www2.hp.com/hpsub/downloads/Newsletters_HP_Calculator_eNL_02_April_2011_v2.pdf and click on the "Tweaking the HP42S" article link. Also, you could go to http://www.pahhc.org/keyboards.htm#The_HP42S_versus_a_proposed_HP42S+:_ and scroll to the bottom and click on the link marked "The HP42S+ ALPHA Keyboard"....Just one person's ideas.

Jake

Jake


I'd forgotten how thoroughly you studied this, Jake. At the risk of being treading a deeply furrowed path here, I'd like to give my 2-2 dollars worth of feedback. First, I like the layout very much. I love it that more programming functions are accessible without menus. I also like how you implemented the alpha characters. The old pick boards are still there but more accessible. And like you say, the most common characters are directly accessible. (Where have I seen that particular arrangement of alpha keys before? :) I also have to say that, although you have tried to minimize clutter, (successfully I think,) the density of available functions on that keyboard just warm the cockles of my gadget-geek heart. :) The excellent color contrast is a big help here.

But the display needs work :). I want higher resolution for selfish reasons. My Yatz42 game has to omit soft menu labels because the minimum vertical size I could squeeze a die image into was 9 pixels high. Using binary coding per the 42S manual, a column containing three vertical dots and the borders has to be 101010101. That means I have to take one row of the bottom line for the die border. I'm going to place my own caret marks below each die to indicate they can be toggled with the soft keys.


Quote:
But the display needs work :). I want higher resolution for selfish reasons.

If there was a guarantee that they'd sell a bazillion of 'em, I bet they'd consider doing it. Instead of a campaign like "Bring Back the HP15C" (which apparently worked after over 5 years of trying), perhaps we need something like "Bring FORTH the 42S!"

:-)

Jake


Put up a petition! I'll buy at least two. :)

Quote:
perhaps we need something like "Bring FORTH the 42S!"
That'll kill it for sure :-)

Quote:
"Bring FORTH the 42S!"

absolutely! - yet that's going to be an even harder nut to crack, specially if it's true that the source code is lost.

But wouldn't that be something?


Seems like there's some pretty good 42S code circulating out there. Perhaps Thomas would cut HP a private license?

My real dream is an HP43+, however. I want the top-end connected calculator that HP would be selling now if they hadn't gone with RPL in the late 80s.


It would be interesting to have a hardware platform with more guts in it than the 30b to port our firmware to. That way users may even chose between a 42S+ (Free42 based) or a 43S (34S based). :-)


Quote:
It would be interesting to have a hardware platform with more guts in it than the 30b to port our firmware to. That way users may even chose between a 42S+ (Free42 based) or a 43S (34S based). :-)

HP-50G?


Quote:
HP-50G?

Definitively not! According the criteria I stated in
a previous post, the HP 50G falls short in more than one point.


Edited: 11 Sept 2011, 5:23 p.m.

*face palm*

Quote:

absolutely! - yet that's going to be an even harder nut to crack, specially if it's true that the source code is lost.

But wouldn't that be something?



Just assume everything happening at HP like it happens everywhere in large companies like it happens in villages of that size. In a way, all these are representative samples of the population around ;-)


I have only worked for small companies, and yet I have still seen some really goofy things happen. I can't even imagine the things going on behind the scenes at a large company. Too many cooks....


Quote:
I have only worked for small companies, and yet I have still seen some really goofy things happen. I can't even imagine the things going on behind the scenes at a large company. Too many cooks....


I worked for Bell Labs for many years, and we kept a library full of lab notebooks documenting inventions, production processes, and all sorts of irreplaceable data taken by some true experts (not me). When they sold our division and downsized, they threw them all in the dumpster out back. I cannot imagine what all was lost.


That is absolutely horrible.

Quote:
absolutely! - yet that's going to be an even harder nut to crack, specially if it's true that the source code is lost.

There is no 15C source either--that didn't stop'em. If EMU42 can run from the 42S ROM, then new HW can too.

These old calcs were programmed in assembly language or machine code. We've got the source--you just need to disassemble them.

Quote:
No letters anywhere.

A few counter examples:

running
A 2 2
Error 0

I had to defend my first HP love, sorry :-)

Gerson.


Well, A,b,C,c,d,E,F,G,H,I,J,L,n,O,o,P,q,r,t,U, and u are readable and unambiguous. That's it.


We also squeezed M and W into the 7-segment portion of the 34S by using pairs of characters.

Also, h, i and Y are possible.

- Pauli

Edited: 2 Sept 2011, 3:16 a.m.


Quote:
Also, h, i and Y are possible.

Frankly, I forgot h. Thought of i - didn't include it though. But Y looks like 4 and is thus rightfully excluded. So now: A,b,C,c,d,E,F,G,H,h,I,i,J,L,n,O,o,P,q,r,t,U, and u are readable and unambiguous. That's it for a 7-segment display.

|_|
|
Looks like Y to me and cannot be confounded with a 4.

    _  _                     _
|_||_ |_ _ _ _ _ _|
| |_ _| |_|| | ||_| | .

Looks like a µ to me :-)

I like this more:

|_|
_|

What do you think?

Massimo


And the winner is ... Massimo! :-)

Quote:
Well, A,b,C,c,d,E,F,G,H,I,J,L,n,O,o,P,q,r,t,U, and u are readable and unambiguous. That's it.

But attempting a simple mechanical translation back to the
originally intended character is a context sensitive mapping,
eg: "runnin9": '9 -> {'9', 'g'}, "5EL": '5' -> {'5', 'S'},
etc.. Certainly feasible but it adds another layer of
clunk to the UI.

So I find myself warming up to your plea for at least a circa
1985 native graphic matrix display support in a year 2011
calculator. I still applaud the Voyager firmware design to
take living within 7-segments as far as it did. But nostalgia
aside, bottom line cost just isn't a reasonable argument to
avoid a matrix display as it was in 1980. And the legacy
technical limitations have largely become non-issues.

Edited: 2 Sept 2011, 10:04 a.m.


How about something akin to the 14-segment display of the HP-41? Would the current 12C+/15C LE processor be able to drive that? And is such a beast even available anymore?

Admittedly a fully addressable dot matrix display would be better but if the current processor is capable of driving a 14-segment LCD might that be the optimal solution as no other hardware changes would be needed (or would there need to be other changes?

I still say: Give me a 17bii+ with 42S firmware and I/O! Old tech, I know, but I *LOVE* my HP-42S! Maybe one day HP will update the 17bii+ with a new processor and make it flashable and then our local heroes can come up with the ultimate HP-41 replacement.

Cheers,

-Marwan


Quote:
How about something akin to the 14-segment display of the HP-41? Would the current 12C+/15C LE processor be able to drive that? And is such a beast even available anymore?

I believe I've still seen that display topology kicking around
but it is extremely rare. Even straight reflective (vs.
transreflective, eg: backlight-able) graphic/character displays
are rare these days -- you can find them but the footprint
and resolution selection are quite limited.

Quote:
Admittedly a fully addressable dot matrix display would be better but if the current processor is capable of driving a 14-segment LCD might that be the optimal solution as no other hardware changes would be needed (or would there need to be other changes?

If the firmware supports only rendering to a numeric display
you end up (best case) with a better looking numeric display
but confined to the original UI.

The argument which exists for a graphic display in a voyager
application running under emulation is that code external to
the legacy firmware can take advantage of the improved display
format.


I was thinking more along the lines of what a repurposing project could do with a 14-segment LCD or a dot-matrix LCD with the required supporting hardware installed in a Voyager package.

Quote:
How about something akin to the 14-segment display of the HP-41? Would the current 12C+/15C LE processor be able to drive that?

Yes, the CPU would be capable of driving such a display. The internal LCD driver can handle up to 400 segments.

Out of reach is a full dot matrix display, at least without external hardware which makes using an integrated CPU with LCD controller somewhat pointless.


- Pauli


Quote:
Out of reach is a full dot matrix display, at least without external hardware which makes using an integrated CPU with LCD controller somewhat pointless.

I initially suspected so too. But it may still be the best
current choice for an ARM SoC from a power/speed/flash_size
perspective even foregoing use of the LCD controller.


Agreed. I've not really been following developments in SoCs for a couple of years now.


Pauli

UG;
I'm guessing that the new 15 is flashable. So maybe someday there will or can be a "WP 15s" that adds those characters as alpha, with arcl and prompt. As someone once told me: "I'm a surveyor. I can't spell for shit but i can abbreviate the hell out of anything"

n, E, EL, Pt, no, Hd, U(V)d, AnGL, In, OUt, GrAdE...... it's all there.


Snags; It's like someone else said. The 15 only had a half a K of memory. A surveyor for example could put two programs into a 15, which would do a couple of things each, depending on how the solve function was implemented. You could have a traverse/inverse/sideshot program and a really nice vertical curve routine that would do asymmetrical VCs if that's how you entered it.
That's it for room, and it's easily remember-able if you use it regularly. Still though; I'd like that abbreviated prompt and alpha recall feature.


Quote:
So maybe someday there will or can be a "WP 15s" that adds those characters as alpha, with arcl and prompt.

No chance.

We've already decided to skip the 15c as a repurposing base for the simple reason: the display.


- Pauli

Quote:
UG;
I'm guessing that the new 15 is flashable. So maybe someday there will or can be a "WP 15s" that adds those characters as alpha, with arcl and prompt.

Honestly I think that is unlikely. IMHO the 15c takes the
industry award for the most successful attempt to pack as much
functionality into a 7-segment UI as the world will ever see.
It may be possible to best that effort as you describe above
but I expect doing so would be well beyond the point of
diminishing returns.

Moreover functional extension would require a firmware re-write.
The attraction of the 15c at this point in time is the
corresponding firmware can be leveraged via running it unaltered
(+/-) under emulation on low power off-the-shelf SoCs. It is
essentially an opportune coincidence of technologies which
hasn't before economically existed.

That said, about the only scenario I could envision for a
legacy firmware re-write would be something akin to a "labor
of love" open source collaborative effort. Even for the 15C
which as evidenced here has about the most passionate following
you will ever find for a pocket calculator, I don't think a
rewrite will ever materialize. And given the presumed successful
productization of the 15c+ I'd imagine HP has concluded its
low-hanging-fruit leverage of that technology.


Paul & UG; Agreed for all those reasons and - why rewrite a 15LE when the ubiquitous new 12 could be repurpesed instead. However; with the success of the rewrite of the 30b/34s's ARM we must keep in mind that any sad & useless hp financial can be made into a real workhorse.

So thanks to Tim, Cerill, Sam and everyone who had something to do with producing something that the Trinity (plus Eric) could make better.


Quote:
Agreed for all those reasons and - why rewrite a 15LE when the ubiquitous new 12 could be repurposed instead.

Not sure I understand here. If I were to do a scientific repurposing of the Voyager hardware, starting with the 15LE makes more sense than starting with the 12C. The keyboard labels can be reused for a start. The 15C's layout is very good and covers most things.

There are plenty of enhancements possible:

  • More program steps.
  • More registers.
  • Fill out the complex functions (e.g. gamma, Py,x and Cy,x).
  • Extra matrix operations.
  • More conditional tests.
  • Integer bases.

There is plenty of flash left for sure and I suspect quite a bit of RAM too. The limit will always be the display and a deal of creativity would be necessary to make everything fit the seven segment format. That or tell everyone you have to carry a thick quick reference guide around.

I wonder how long it will be before the 15LE gets the memory expansion. If we're lucky, it might even be as simple as patching the ROM image -- 11 x 11 determinants :-)


- Pauli


Paul; I should type fuller sentences or none. I meant that i agree with you that it would not be a good return on your time to do a "WPXX" Voyager because of the screen limitations. But if someone ever does that (and if the 12c ARM architecture is the same as the 15, or at least big enough) it would pay off to use the 12 because there will probably be a bunch of them and they'll be cheaper. After all; it's not a limited edition. Eric makes fine overlays so the original keys' functions isn't important.

Me personally, i hope you three keep using your time on the 34s. There must be something it doesn't do yet.


Quote:
Me personally, i hope you three keep using your time on the 34s.

We've got plans beyond the 34S :-) Nothing concrete until the 34S is finished lest we never finish it.


Quote:
There must be something it doesn't do yet.

Matrix support is the obvious one.


- Pauli

Quote:
Not sure I understand here. If I were to do a scientific repurposing of the Voyager hardware, starting with the 15LE makes more sense than starting with the 12C. The keyboard labels can be reused for a start. The 15C's layout is very good and covers most things.

I'd agree, if the plan was to live within the functionality
defined by the 15c and there is certainly an argument to
be made for doing so. Particularly as it likely would
gently shepherd something approximating a 15c firmware
rewrite which is goodness by any measure.

But the existing 12c+ econo keycaps are more agreeable to
engraving should we have other ideas. There is also
something less sacrilegious about bandsawing a 12c+ for
experimentation. Maybe that stigma will minimize once
15c+ are more prevalent.

Quote:
There are plenty of enhancements possible:

  • More program steps.
  • More registers.
  • Fill out the complex functions (e.g. gamma, Py,x and Cy,x).
  • Extra matrix operations.
  • More conditional tests.
  • Integer bases.

One pie-in-the-sky thought for the surplus flash within a
KINOMI module was to some extent help a 16c and 15c interoperate.
But the more I thought about it the more it seemed like a
unjustifiable dead-end effort without any reusable code as
a by product of the development. I suppose I've found myself
increasingly questioning to what extent the real-world
practical benefits of running decades old black-box firmware
in emulation overshadow the limitations of customization and
maintenance.

Quote:
The limit will always be the display and a deal of creativity would be necessary to make everything fit the seven segment format. That or tell everyone you have to carry a thick quick reference guide around.

I think a replacement for the segment display needs to happen
unless we're content to keep emulating enhanced voyager firmware.
Semi-standard 32x144 and 32x160 graphic formats exist and would
fit the segment display aperture quite well. The problem is
the controller and/or interconnect such that we're dealing with
a COG extension or interconnect flange which will cause the
resulting footprint to outgrow the available area. But this
seems such a promising and enabling upgrade that considerable
effort is well justified to ferret out a solution.

Quote:
I wonder how long it will be before the 15LE gets the memory expansion. If we're lucky, it might even be as simple as patching the ROM image -- 11 x 11 determinants :-)

I admittedly haven poked at the 12C+ pcb in sufficient detail
to determine if/where the SPI lines are brought out, but
that's about the only expansion route of reasonable throughput.
Doubly so as the SPI controller IIRC has DMA support.
nvSRAM looks like single solution which would address several
needs. But even if the stock PCB doesn't furnish access to the
needed sam7l lines a replacement board wouldn't be too difficult
to justify.


Quote:
One pie-in-the-sky thought for the surplus flash within a KINOMI module was to some extent help a 16c and 15c interoperate.

Copying the stack between the two would be enough for interoperation. Even better if that bit of memory in both emulators was the same locations. Still, I think you are correct about the reward vs effort involved.


Quote:
I admittedly haven poked at the 12C+ pcb in sufficient detail
to determine if/where the SPI lines are brought out...

That wasn't the point of what I wrote. The existing ARM cpu has sufficient RAM for the memory expansion I linked to. It doubles the number of bank registers in the 15c -- 64*7 = 448 bytes. The CPU has 2kb of non-volatile RAM and a lot of this is likely empty.


- Pauli


Quote:
Copying the stack between the two would be enough for interoperation.

Copy the stack? While the 15C and 16C stack are the same depth (four levels plus LastX), they aren't even always the same width: 56 bits on 15C, 1 to 64 bits on 16C. What does a 15C Matrix A turn into on a 16C? What does the number 123456788abcdef0h turn into on a 15C?


The only thing that makes sense copying is reals. At least copying without some manner of conversion.


Does the 16c really maintain the five stack registers separately resizing them as required? I've seen the synthetic information for the 15c but I don't remember seeing similar for the 16c.


- Pauli


The stack in the 16C is stored as 64 bits per level. 56 out of 64 are stored in one register, and the extra 8 bits from all four levels and LastX are combined and stored in another register. However, when using WSIZE < 64, not all bits are used.

There isn't much published information on synthetics on the 16C because (unlike the original 15C) there is no known technique for gaining access to memory the user wasn't intended to access.

A good idea would be to have switchable register sets. In one you can have several programs. In another set, other group of programs; and another, mostly free for heavy matrix work.

But the most logical first mod would be to move the upper register limit to 128.

A built-in constants library, I guess? But I'd probably use the HP50g for things like that (constants AND units)

Schooling has probably permanently frozen (at least approximations for) a lot of the ones I'd be likely to use into my brain, anyway (c~3x10^8 m/s, h-bar-c ~197 ev-nm, kT ~ 1/40eV, etc., etc.)

For me the thing the 15c can't do that I like on the 35s is the equation solver. I have many such equations that I need to solve one way or the other on a regular basis and the 35s makes that a breeze. They are only very simple linear equations but having them preloaded in the calculator and tested speeds up things quite a bit for me. However, in truthfulness, I have now moved on to mostly using the multiple equation solver in the 50g because of the capability of multiple equations and the use of units.


Same here, Ive been loading lots of eqn's in for pop models, prey etc whilst doing questions and are able to reuse them in other questions and tests.

Its great for discrete equations, and doesnt use up any labels! It would be cumbersome to write programs to solve all these! Im not sure what the downside is?

Daniel.


On the 50G you can copy and edit equations. On the 35s you can edit only...another point for the 50G...

Quote:
It would be cumbersome to write programs to solve all these! I'm not sure what the downside is?

There's no downside when comparing equation writing on the 35s to programming on the 15c.

However, one of the reasons the 35s got slammed was, compared to equation writing on the 27s and 17b series, the 35s stinks. HP just evolved the 32s series Solver a little bit, instead of incorporating the Solver from the aforementioned models, which is greatly superior.


Yes! That solver (the one from the 17b/19b/27S) should be made available on every calc in HP's lineup. There are many cases where it is an easier and more intuitive solution than programming. I like using the solver for conversions where you can solve either way from a single equation rather than have to write 2 routines in RPN.

Lots of other uses too and lots of power when you really dig into it. Having both the solver and RPN programming in the same machine would be great. The 35S had a chance to get that right and didn't. Of course you have that capability with the 48 series calcs (solver but with RPL) but now we are talking larger graphing calculators.

Cheers,

-Marwan


I gave up using the RPN models for daily use (though there is usually a 15c in the drawer if I can't find anything).

"Daily use" is now the 17b series and the 27s, along with the trusty 48gx.


Quote:
I gave up using the RPN models for daily use (though there is usually a 15c in the drawer if I can't find anything).

"Daily use" is now the 17b series and the 27s, along with the trusty 48gx.


Bill, we are a lot alike. I, too use the last three you mentioned (except 48sx instead of gx) most of time. But instead of a 15c, I keep a 32sii around, mostly for the fraction math.

The two line dot matrix LCD of the 35s allows for some important features the 15C will never have:

  • listing function names in programs
  • catalog of constants
  • readable complex numbers
But that's it IMHO. OTOH, the 35s has the bugs listed while the old 15C does not have any known bugs at all. That's it as well :-/

So it depends on your personal preferences to some extent.


Quote:
while the old 15C does not have any known bugs at all. That's it as well :-/

Actually, there is one known bug in the 15c firmware. That's pretty good after 30+ years of searching -- it was only identified in the past year or three. I forget the details but it is rather esoteric and even if you encountered it you most likely wouldn't notice anyway. It certainly isn't a numeric issue or a hard lock crash.

There is a second almost bug. The ability to create weird matrix descriptors using the ON-D shift the X register combination, this allows access to system memory and program space via the registers. Technically not a bug since, according to the documentation, this key combination should always be followed by CLx.

To me, the effort and attention to detail put into making the 15c the best possible calculator is summed up by the comment on page 179 of the Advanced Functions Handbook:

Quote:
A function that grows to infinity or decays to 0 exponentially fast as its argument approaches +/- infinity may suffer an error larger than one unit in its 10th significant digit, but only if its magnitude is smaller than 10-20 or larger than 1020; and though the relative error gets worse as the result gets more extreme (small or large), the error stays below three units in the last (10th) significant digit. The reason for this error is explained later. Functions so affected are ex, yx, x! (for noninteger x), SINH, and COSH for real arguments. The worst case known is 3201, which is calculated as 7.968419664 x 1095. The last digit 4 should be 6 instead, as is the case for 7.2933.5, calculated as 7.968419666 x 1028.

Not only concerned about getting the answer correct, but identifying the (most likely) worst case where it is out by 2 ULP!

If you haven't already get a copy of this volume (it is on the MoHPC DVD) and read pages 172 onwards. You will be enlightened.


- Pauli


Quote:
There is a second almost bug.

I wouldn't even consider that an "almost bug". As you point out, the manual says that ON-D should be followed by CLx. If you fail to follow the instructions, you get undefined results, and it's your own fault, not HP's.

However, whether you call it a bug or not, I am 99.9999% certain that it will be "fixed" in the 15c Limited Edition.

Quote:
Is there anything the 15c can't do compared to the 35s?

  1. Fit in your pocket, with case.
  2. Not miss keystrokes. (Dunno about the LE). IIRC, I had a few issues with the bottom row of my 35s. I put it in storage after that. BTW, having same problem with '+' on my 30b (or more accurately my 29.5b).
  3. More complete complex number support. Once in complex mode I do not have to do anything special to do complex operations. I do however need to do something special to view the results.
  4. STO a number with one less keystroke.
  5. Decade magnitude battery life. I just took out my 35s from storage to test a few things and I couldn't. Dead batteries. I must admit however, it's very good looking.

Quote:
Would the 15c replace it for daily usage?

For me, yes. I guess it really depends on what you do daily. The 15C was my only daily calculator in the '80s. I had to learn to do everything on it. To this day, its operations are etched in my brain. With the 35s I have to relearn a few things about programming and how to work around the complexities of its complex number support.

Edited: 2 Sept 2011, 11:04 a.m.


I forgot to add that the 15C is available as an emulator on just about every platform.


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP-27S speed compared to HP-42S Tommi 3 138 06-05-2013, 05:55 PM
Last Post: Christoph Giesselink
  Programs for 15C and 35S Eddie W. Shore 25 477 05-23-2013, 03:58 PM
Last Post: Eddie W. Shore
  Original 15C Keyboard Test Works With 15C LE!!! DigiGal 5 219 09-26-2011, 07:33 PM
Last Post: M. Joury
  34s - stack lift with PI compared to 15c - difference - anyone else able to repeat this? Gene Wright 39 848 07-16-2011, 11:30 PM
Last Post: Jake Schwartz
  ARM-based 12c compared to the old one Jose Gonzalez Divasson 14 358 03-15-2011, 11:38 AM
Last Post: Marcus von Cube, Germany
  HP 97 clutch repair methods compared Ed Sowell 13 312 04-26-2010, 07:39 AM
Last Post: Marcus von Cube, Germany
  48sx compared to 50g Hiawatha Wheelwright 29 646 01-18-2010, 04:43 PM
Last Post: Nacho
  HP-67 and TI SR-52 compared Marcus von Cube, Germany 16 417 05-11-2008, 03:47 PM
Last Post: Marcus von Cube, Germany
  Games on 35s, 48gx or 15c Vincze 10 262 08-16-2007, 10:21 AM
Last Post: Pal G.

Forum Jump: