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
Is there anything the 15c can't do compared to the 35s?
|
|
« Next Oldest | Next Newest »
|
▼
09-01-2011, 06:39 PM
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 ▼
09-01-2011, 08:02 PM
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. ▼
09-01-2011, 11:19 PM
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! ▼
09-01-2011, 11:43 PM
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.
09-01-2011, 08:06 PM
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. ▼
09-01-2011, 08:14 PM
Quote: Time to start agitating for an HP-16C LE reissue, I think. ;)
Quote: "This video is not available in your country"? What gives? Best,
--- Les Bell ▼
09-01-2011, 08:16 PM
I very much doubt you will *EVER* get that--although I would buy one... or two... or three...
09-01-2011, 08:29 PM
Quote: 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.
Edited: 1 Sept 2011, 9:38 p.m.
09-01-2011, 09:47 PM
Quote:From last speaking with Cyrille, it will remain a dream, at least for HP. Patrice
09-01-2011, 08:14 PM
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
09-01-2011, 09:08 PM
Can the 15C be used in the test environments for which the 35s was specifically designed? ▼
09-01-2011, 10:05 PM
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.
09-01-2011, 10:14 PM
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 ▼
09-01-2011, 10:40 PM
Quote:
The scale is unbalanced by ▼
09-01-2011, 11:38 PM
This bug list is only 50% accurate as discussed ad-nauseum previously!
▼
09-02-2011, 12:48 AM
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.
▼
09-02-2011, 12:53 AM
I think snaggs is referring to a thread a few weeks ago in which he "debunked" some of the reported bugs. ▼
09-02-2011, 08:01 AM
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.
▼
09-02-2011, 08:13 AM
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.
09-02-2011, 07:32 AM
Certainly the 35s has issues. It was a missed opportunity that was just a ROM roll away from being a very, very good calculator.
09-01-2011, 11:16 PM
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. ▼
09-01-2011, 11:29 PM
It can't display letters at all. Program lines are key codes. Registers are numbers. No letters anywhere. Cheers, -Marwan ▼
09-01-2011, 11:32 PM
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. ▼
09-02-2011, 12:47 AM
Quote:No, they have great memories of using a 15c! Quote: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.
09-02-2011, 12:52 AM
Quote: It is more a case of the 15c not having a huge amount of memory.
09-02-2011, 01:46 AM
Quote: 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. ▼
09-02-2011, 01:58 AM
Quote: What about the 34S???? It is the only one of the three with complex gamma built in e.g. :-)
▼
09-02-2011, 09:06 AM
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! :)
09-02-2011, 02:02 AM
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? ▼
09-02-2011, 07:41 AM
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). ▼
09-02-2011, 08:10 AM
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 ▼
09-02-2011, 08:12 AM
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. ▼
09-02-2011, 12:40 PM
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
09-03-2011, 01:42 PM
Quote:If you do you will find that the 35s outperforms the 15c for a simple reason -- more digits in the mantissa.
09-03-2011, 12:59 AM
Quote: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
▼
09-03-2011, 09:44 AM
Ah, or type in a long program. :-) ▼
09-03-2011, 01:37 PM
Quote: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. ▼
09-03-2011, 04:09 PM
Quote: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.
09-02-2011, 02:03 PM
Quote: Here is a list quoted from my post of 7 August 2011.
Quote: ▼
09-02-2011, 02:24 PM
The 35s can evaluate several of the examples on your list: 1. 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.
09-02-2011, 03:09 PM
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,1416And finally, ultimately elegant: i ENTER y^x => 0,2079 i 0 Yes, I like it. :-) Dieter ▼
09-02-2011, 06:30 PM
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. ▼
09-02-2011, 06:56 PM
Quote: 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.
▼
09-04-2011, 12:34 PM
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. correct mantissa HP35s errorThe 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 errorThese 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)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 resultShould 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 ▼
09-04-2011, 01:49 PM
Explain why scrolling is needed on the 35S when there is no scrolling needed on the 33S.
▼
09-04-2011, 02:18 PM
Hi Paul, Quote: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:It's the way HP chose the 35s to work. No, I don't like it, but it still is not a bug. ;-) Dieter
09-04-2011, 06:01 PM
Quote: 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: 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: I suspected as much.
▼
09-05-2011, 11:32 AM
Quote: 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
09-05-2011, 08:40 AM
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. ▼
09-05-2011, 05:47 PM
Quote: 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.
▼
09-06-2011, 06:29 AM
Ok, though searchig the archive is a pain;
3. Not a bug -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. ▼
09-06-2011, 07:26 AM
Quote: 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.
09-06-2011, 07:35 AM
Quote: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: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.
09-06-2011, 07:37 AM
Quote: 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.
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: 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: 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: 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: 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 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: I'm not surprised, the next one #15 is an infinite loop hang :-)
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.
▼
09-06-2011, 10:02 AM
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
09-06-2011, 08:08 AM
Quote: 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!
09-06-2011, 11:17 AM
Quote: 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: 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.
09-02-2011, 08:03 PM
Complex ArcSin & ArcCos On the HP35STo 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 CommentRemarks 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) ).
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 ▼
09-03-2011, 09:20 AM
Thanks Bart, nice work!
09-06-2011, 02:09 AM
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,
09-02-2011, 04:45 PM
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. ▼
09-02-2011, 06:21 PM
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. ▼
09-02-2011, 07:02 PM
Quote: Hi snaggs, you keep a logbook or have an hourmeter to clock usage on your 35s? ;-) hpnut in Malaysia
09-06-2011, 11:30 AM
Quote: 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.
09-02-2011, 01:04 PM
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. ▼
09-02-2011, 02:21 PM
Quote: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. ▼
09-02-2011, 02:35 PM
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. ▼
09-02-2011, 02:42 PM
Quote:You hit the proverbial nail on the proverbial head.
09-02-2011, 06:45 PM
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.
09-02-2011, 07:11 PM
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. ▼
09-02-2011, 10:19 PM
Fred, Quote: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:Precisely. Quote:I'm an HP late-bloomer, starting with a 20s in 1993. Now have a few models... Quote: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. ▼
09-03-2011, 12:07 AM
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.
09-02-2011, 10:40 PM
You call the 35S a mid-level calculator, not high end, but HP calls the 35S the ultimate scientific calculator right on the packaging. ▼
09-03-2011, 12:25 AM
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.
09-06-2011, 02:15 AM
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, 3:15 a.m. ▼
09-06-2011, 10:21 AM
Quote:
I concur! :)
09-06-2011, 07:01 PM
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:
Edited: 6 Sept 2011, 7:01 p.m. ▼
09-06-2011, 07:07 PM
Quote: Yes it does. Alpha entry is very easy. Much nicer than the 42S, IMHO.
Quote: It doesn't. No equations.
▼
09-07-2011, 05:50 PM
Quote:
Actually, since it includes the AECROM module, it does offer quite a powerful algebraic formulas -> focal programs converter. ▼
09-08-2011, 03:45 PM
My thoughts exactly, a notable pioneering implementation of Equations, worth the learning curve. ▼
09-08-2011, 07:50 PM
How does one turn the calculator off with this module installed? Every time I press on it changes length units on me. - Pauli ▼
09-09-2011, 01:55 AM
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. ▼
09-09-2011, 02:21 PM
Does the 41CL use the original AECROM image or the verion that you enhanced to use the 13-digit math routines? ▼
09-09-2011, 05:40 PM
Both are available. Edited: 9 Sept 2011, 5:41 p.m.
09-10-2011, 02:14 AM
Quote: 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.
09-10-2011, 02:25 AM
Nice catch Ángel. I'm running this on my CL at maximum turbo (this is the only way I run now).
09-07-2011, 03:23 PM
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, 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. ▼
09-07-2011, 05:00 PM
Was it perhaps the MiXeDCaSe of RePeLlent ?
edit: No, it wasn't. Edited: 7 Sept 2011, 5:00 p.m.
09-08-2011, 03:28 PM
Quote: 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 ▼
09-08-2011, 03:48 PM
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,
09-08-2011, 04:47 PM
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. ▼
09-09-2011, 01:52 AM
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 ... ▼
09-09-2011, 02:46 AM
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.
09-09-2011, 03:39 PM
Quote:
Jake Jake ▼
09-09-2011, 05:22 PM
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. ▼
09-09-2011, 07:16 PM
Quote: 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 ▼
09-09-2011, 08:20 PM
Put up a petition! I'll buy at least two. :)
09-09-2011, 10:16 PM
Quote:That'll kill it for sure :-)
09-10-2011, 02:29 AM
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? ▼
09-10-2011, 02:51 AM
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. ▼
09-10-2011, 04:49 AM
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). :-) ▼
09-11-2011, 04:54 PM
Quote: HP-50G? ▼
09-11-2011, 04:58 PM
Quote: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.
09-10-2011, 08:16 AM
*face palm*
Quote: ▼
09-11-2011, 08:39 AM
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 ;-) ▼
09-11-2011, 07:34 PM
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....
▼
09-12-2011, 07:05 PM
Quote: 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.
09-12-2011, 09:28 PM
Quote: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.
09-01-2011, 11:35 PM
Quote: A few counter examples:
running I had to defend my first HP love, sorry :-) Gerson.
▼
09-02-2011, 02:29 AM
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. ▼
09-02-2011, 02:51 AM
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. ▼
09-05-2011, 03:22 PM
Quote: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.
09-02-2011, 09:59 AM
Quote:
But attempting a simple mechanical translation back to the
So I find myself warming up to your plea for at least a circa
Edited: 2 Sept 2011, 10:04 a.m. ▼
09-02-2011, 10:45 AM
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 ▼
09-02-2011, 11:14 AM
Quote:
I believe I've still seen that display topology kicking around
Quote:
If the firmware supports only rendering to a numeric display
The argument which exists for a graphic display in a voyager ▼
09-02-2011, 11:21 AM
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.
09-02-2011, 06:24 PM
Quote: 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.
▼
09-02-2011, 07:08 PM
Quote:
I initially suspected so too. But it may still be the best
09-02-2011, 11:34 PM
UG;
n, E, EL, Pt, no, Hd, U(V)d, AnGL, In, OUt, GrAdE...... it's all there. ▼
09-03-2011, 01:26 AM
Quote: No chance. We've already decided to skip the 15c as a repurposing base for the simple reason: the display.
09-03-2011, 09:25 AM
Quote:
Honestly I think that is unlikely. IMHO the 15c takes the
Moreover functional extension would require a firmware re-write.
That said, about the only scenario I could envision for a
▼
09-03-2011, 10:21 PM
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. ▼
09-03-2011, 10:51 PM
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. There are plenty of enhancements possible:
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 :-)
▼
09-04-2011, 12:06 AM
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. ▼
09-04-2011, 12:43 AM
Quote: We've got plans beyond the 34S :-) Nothing concrete until the 34S is finished lest we never finish it.
Quote: Matrix support is the obvious one.
09-04-2011, 11:56 PM
Quote:
I'd agree, if the plan was to live within the functionality
But the existing 12c+ econo keycaps are more agreeable to
Quote:
One pie-in-the-sky thought for the surplus flash within a
Quote:
I think a replacement for the segment display needs to happen
Quote:
I admittedly haven poked at the 12C+ pcb in sufficient detail ▼
09-05-2011, 12:27 AM
Quote: 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: 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.
▼
09-05-2011, 01:39 AM
Quote: 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? ▼
09-05-2011, 02:10 AM
The only thing that makes sense copying is reals. At least copying without some manner of conversion.
▼
09-05-2011, 02:56 PM
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.
09-05-2011, 03:24 PM
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.
09-01-2011, 11:18 PM
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.)
09-01-2011, 11:24 PM
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. ▼
09-01-2011, 11:30 PM
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. ▼
09-02-2011, 05:19 PM
On the 50G you can copy and edit equations. On the 35s you can edit only...another point for the 50G...
09-02-2011, 05:48 PM
Quote: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. ▼
09-02-2011, 06:28 PM
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 ▼
09-03-2011, 09:04 AM
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. ▼
09-03-2011, 05:26 PM
Quote: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.
09-02-2011, 02:16 AM
The two line dot matrix LCD of the 35s allows for some important features the 15C will never have:
So it depends on your personal preferences to some extent. ▼
09-02-2011, 02:44 AM
Quote: 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: 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.
▼
09-02-2011, 07:58 PM
Quote: 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.
09-02-2011, 11:03 AM
Quote:
Quote: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. |