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


« Next Oldest  Next Newest »

▼
08272012, 12:33 AM
▼
08272012, 12:46 AM
welcome to the club
08272012, 02:09 AM
On the other hand, 50g is farly impressive even when compared to TI nspire cx cas. seems like 50g is one of the few calc that will actually handle infinity. 1/0=inf. tan pi/2 = inf.
Edited: 27 Aug 2012, 2:10 a.m. ▼
08272012, 02:23 AM
Hi. IIRC, the HP71B has a 'defense mechanism' for the infinity occurrence. Cheers. Luiz (Brazil) ▼
08272012, 03:06 AM
But is there any other calc we know of beside 50g that would even handle the value inf? i don't think 50g really distinguish between + and  inf. maybe that's for the replacement. But that's definitely impressive in my book, even if it's just rudimentary..
i played aroud with my newly acquired nspire cx cas. the active color display is nice, but all that will do is drain battery faster. ▼
08272012, 03:13 AM
Take the WP 34S and set flag D. Then enter 0 +/ 1/x and you'll get infinity d:)
08272012, 09:14 PM
For the record the TInspire CX CAS does handle +/ infinity.
limit(1/x,x,0,+) > +oo Miles ▼
08272012, 10:10 PM
what about inv tan (inf) and tan (pi/2) ? ▼
08282012, 08:27 AM
On my TI Voyage 200 (and therefore probably on the TI89), inv tan (infinity) = pi/2 and tan (pi/2) = "undef". Working out the limit of tan (x) as x tends to pi/2 from below gives +(infinity); as x tends to pi/2 from above gives (infinity). Nice! Nigel (UK)
09072012, 09:54 AM
Quote: The CAS CX does handle those cases too. Just entering tan(pi/2) gives "undef" but the following work:
tan^1 +oo > pi/2
08272012, 02:23 AM
Does it handle the case for both values of the pole correctly? The value at the nPI/2 pole is +/ inf, depending from which side one approaches the pole. ▼
08272012, 02:27 AM
This is the case for TAN, COT, SEC and COSEC because all of them include a 'divide by' and subsequent reciprocal, which leads to divide by zero (by definition).
08272012, 08:13 AM
"Does it handle the case for both values of the pole correctly? The value at the nPI/2 pole is +/ inf, depending from which side one approaches the pole. " Yes, the syntax is '1/X' 'X=0+0' lim > +oo '1/X' 'X=00' lim > oo
'TAN(X)' 'X=PI/2+0' lim
'TAN(X)' 'X=PI/20' lim
'TAN(X)' 'X=PI/2' lim (oo infinity) etc.
I would be very surprised if the TI CAS don't do this !! Edited: 27 Aug 2012, 8:19 a.m.
08272012, 04:03 PM
50G = proper descendent of Bill Wickes' RPL masterpiece, the 48GX. Painstakingly and tirelessly worked on by a skeleton crew (including C. de B. IIRC), the 50G is a true professional tool. A platform not only for User RPL in the classic sense, but SysRPL and even ARM programming. Some have even written C++ code and compiled it (I think). The 35s was a good idea, but it seems to me that there must have been too much outsourcing. It would be interesting (over coffee with the tape recorder turned off) to get the inside scoop in the 35s.
I love the 20B and now 30B platform. I have barely scratched the surface but when you see that the small but dedicated calculator group has put out a product which not only serves a market niche in the business models, but also a tinkerer's and programmer's niche at the same timeno *that* is a great thing that should all make us *very* happy, regardless of what the upper level of HP is doing (for instance to the laptops we buy). Edited: 27 Aug 2012, 4:06 p.m.
08272012, 08:21 AM
Quote:
. I got mine as a present and spent about one month trying it out and wrote five full articles about it, one or two were sent to HPCC and published in Datafile ("Storing Lotsa Lotsa Numbers" and "Going back to the roots"), and the remaining ones were not and still remain as PDF files on some backup hard disk of mine. After writing said articles I then stopped using the HP35s altogether. There was much to like and it certainly was a quality RPN calculator with a nice classic form factor, good keyboard, decent display, lots of memory and functionality and such, but it also had some terrible flaws that seriously detracted from the fun, such as:
and many other quirks and caveats which would appear when you least expected them and would require lots of attention and awareness of them and their mainly nasty side effects. All in all, this made the calculator quite unreliable and little fun to use, more like an insufferable chore, so I stored it for good. A real pity if you ask me, as it had so much potential to be a really fine, useable, powerful RPN calc but alas, due to some very sloppy and illspecified firmware it wasn't to be but was a complete letdown instead.
Best regards from V.
▼
08272012, 10:11 AM
Complex number handling is abyssmal as you say. It just doesn't have that great feeling to it like say 42s. I suppose for the price point, it has more features than 32s, but i mean i hate to have to even justify something by bringing up price as a point. They definitely could ve handle the feature set better. ▼
08272012, 01:46 PM
The 35s was a *major* improvement over the 32SII it relaced (let's forget about the ugly, much less capable and likewise buggy 33s). If it weren't for all those bugs, it could have seperated me from my 32SII when it comes to daily use. If the fine calculator people at HP were allowed to improve and debug existing calculators instead of getting out new buggy calcs all the time, we would have had quite some fine machines by now. ▼
08272012, 04:08 PM
The 35s shares the exact same completely unacceptable major bugs found in the 33s ... :(
08282012, 04:53 AM
Quote: Exactly what I thought after a few weeks playing around. It is now a "shelf" machine, like some oldies. For daily use I went back to the 32SII.
08272012, 10:26 AM
Quote: Valentín, that's exactly my opinion. Also, the worst thing is so far HP has done nothing to fix any of these bugs, despite some of them are known since the very release date. I can't help comparing present day HP to the company that once had this attitude towards a lesser original HP35 bug:
Quote:^{(Quoted from http://www.hpmuseum.org/hp35.htm)} Best regards, Gerson. ▼
08272012, 10:45 AM
hp35s is crippled by birth, no I/O, no flash, RIP ▼
08272012, 11:20 AM
I don't know if this is meant to be an incindiary comment or not. HP is not at fault for not including those features. Those features are required to be absent in order for the calculator to be approved by NCEES for use on the FE and PE exams. If you have a problem with that, HP should not be the target of your anger, but NCEES. For me, I am just happy that NCEES will allow the use of RPN calculators and that I am not forced to use something that does not come naturally to me. ▼
08272012, 04:10 PM
What you say is true, however as HP has chosen not to fix the product and is certainly not going to WR existing, then it is RIP as far as serious users aer concernedsince you can't repair the damn thing with new firmware.
08272012, 06:53 PM
I'm stating facts. The calculator is full of bugs and shortcomings and there is no way to be fixed. It should never be released. ▼
08282012, 04:48 PM
Quote:Try to remember the time period before the 35s was released. There was a huge thrill of anticipation in this community that the release would coincide with an anniversary of the release of the original 35.
08272012, 12:19 PM
Quote: Would that be the same HP which produced in its next series the most incompetent design in all calculator history? I write, of course, of the Woodstock series with battery charging system that was guaranteed to destroy the calculator if and when conditions developed that were almost certain to occur in the natural use of the machine. It's a pity that Packard worried about a relatively minor and nonfatal firmware flaw in one machine, yet ignored a gross hardware design fault in every calculator of the very next generation which could destroy the machine.
08282012, 09:51 AM
I have to admit I have not been using my 35S lately.
08282012, 11:52 AM
Hi all. Shouldn't HP be getting these feedback responses and perhaps screenshots so that they can see the shortcomings and issues with the 35S? I think, the more HP hears about and sees these errors and mathematical discrepancies, they would be made aware more concretely of the flaws in the 35S and either issue a newly ROMrevised 35S or an entirely new model to replace the 35S. ▼
08282012, 11:56 AM
Oh yes, that's the idea we were all waiting for :> Please search the archives ... sometimes ... maybe even before posting ... ▼
08292012, 01:10 AM
Yes yes. I know what you mean. I'm just questioning because I wonder if HP is just shrugging our input off because either just a few of us are alerting HP and that doesn't justify (to HP) issuing a ROM revision or complete 35s redesign since the 95% of 35s owners haven't chimed in about the bugs. ▼
08292012, 03:05 AM
No i don't think you know what he means. Even if every person who bought one complained to HP they still wouldn't change a thing. Like the man said it's all in the archives.
08292012, 08:02 AM
Unlike the ARM based calculators with flashable ROM, the 35s is a 6502 clone with mask ROM (i.e. "programmed" in the factory and cannot be updated), and HP probably purchased it by the million.
▼
08292012, 12:41 PM
There was some discussion of removing the guts of the 35s and replacing with new components. Probably harder than it sounded and not worth the effort. (I still have the dxf files of the PCB if anyone would like to take a crack at it.)
▼
08302012, 06:34 AM
Hi Jeff,
08302012, 12:12 AM
Thank you for the concise and detailed explanation. Now that I understand that the chip is directly mounted on the PCB, I can see why a 35S refit would be overwhelming. That helps me understand the situation a lot better. ▼
08302012, 06:37 AM
Here is a thread with some photos by Jeff of the 35S taken apart: HP35s Internal Investigations ▼
08302012, 06:55 AM
Bart, thanks for excavating :) @Matt: I hope this explains even to you what I meant when I stated above that some research in the museum archives may often help a lot. Instead of asking the obvious, at least. Please ...
08302012, 12:50 PM
Those are interesting posts that I missed, with PCB photos in that thread. It's interesting that the HP 35S hardware designers used a crystal for the system clock. Perhaps there was some consideration of giving the 35S some clock/calendar functions. ▼
08302012, 01:11 PM
The crytal is not used for the system clock, but for display refresh and keyboard scanning. The processor clock frequency is programmed by R1.
08282012, 01:05 PM
The people at HP who actually have expertise and design calculators already know all about it. Obviously there is a management decision above them to leave it alone.
08282012, 05:24 PM
There just simply isn't a large enough market to justify fixing or releasing new RPN scientific models. When this calculator was introduced in 2007, the iPhone had just appeared. After five years, you probably can't convince many people to purchase a separate calculator when their phone does as much and more. Not to mention the only real value of the 33s/35s is that it can be used on NCEES board approved tests.
As stated previously, I think HP's RPN scientific calcs are done. I don't expect a new release. I could be proven wrong, but between capable mobile devices, PCs, laptops, and a company that is losing revenue, it's an unlikely proposition. Edited: 28 Aug 2012, 5:25 p.m.
08292012, 07:52 AM
Perhaps not "impressive", especially in the programming and complex world, but I like the 35S as an everyday calculator. I like the form, the keyboard, the constants and conversions (though I wish there was a ftm rather than incm), and the big enter button in the right place. Yes it is too bad that the flaws aren't addressed, but it is nice that there is still a decent RPN scientific calculator out there for sale. IMO, of course. ▼
08292012, 08:12 AM
If i want an everyday calc, could ve just use my smartphone with free42 and emu48. I expect better when i actually spend almost $50 on an HP calc. actually, i don't mind spending slightly more for one with better program and complex number support. ▼
08292012, 08:22 AM
Quote: That would be an HP42S, though "slightly" wouldn't probably apply. I don't use physical HP calculators anymore but if I had to, I'd probably go for a 42S. It's a fun machine to use and to program, fast and capable. Except for the lack of mass storage, there's not much to limit your creativity and the few actual limits are fun to try and overcome.
Best regards from V. ▼
08292012, 08:49 AM
Buenas tardes Valentin, may I recommend you try a WP 34S? Mathematically, it can do all the HP42S can do (except some matrix operations) plus a significant bit more. And the project is about to reach its end, so a thorough investigation would be appreciated, especially performed by a math guru as you are. ▼
08292012, 03:02 PM
Hi, Walter:
Quote: Thanks a lot for your continued appreciation and kind words, Walter. I lost most of my formerly considerable interest in calculatorrelated matters a few years ago after some particularly discouraging events and haven't fully recovered it back yet so I'm not really for allocating alwaysscarce free time to such matters again but simply content myself with just the occasional post here to somewhat remain in touch with all of you, out of sheer nostalgia.
Nevertheless, I'll contribute a simple sample computation for you to check how well does your beloved WP 34S cope with it: Numerically find a root of
Of course the exact root is
See how many correct digits does your builtin WP 34S Solve functionality provide at various precisions. The same goes for other people reading this and using either the WP 34S or other HP (or whatever brand) models as long as they don't use symbolics.
Thus, to make this test results meaningful for this machine, you should use instead as first guesses 1 and 2, which do straddle the exact root and whose arithmetic mean doesn't happen to be the root.
Best regards from V.
Edited: 30 Aug 2012, 4:28 a.m. after one or more responses were posted ▼
08292012, 03:47 PM
Hello Valentin,
Quote:
WP 34S (V3.1 3089) Best regards, Gerson. ▼
08302012, 04:33 AM
Quote: Thanks, Gerson. I've edited my original post above to reflect the fact of such chance event occurring and stating that the initial guesses should be 1 and 2 instead, lest the result is rendered meaningless.
Best regards from V. ▼
08302012, 08:15 AM
OK, I plotted the equation y = sin(x + cos(x))  1 and found its root at pi/2 is the maximum of this function. So, in an attempt to cure the problem, I modified the equation slightly: y = sin(x + cos(x))  1 + d with d << 1.
I solved it for different values of d (stored in R00). These are the results for DBLON, taking 0 and pi as first guesses and setting the display to ALL 00 (edit: I added the results of a second run with 1 and 2 as first guesses): d x_root(0, pi) x_root(1, 2)Just checked the HP15C Owner's Handbook, Appendix D. The function given by Valentin doesn't fulfill the conditions stated on p.221f there. Although that's not explaining why the algorithm seems to fail, it shows at least that other folks may have had problems, too, with such functions. Let's take a closer look to the last case solved properly and the first case apparently going banana (d = 1e8 and d = 1e9 for the initial estimates 1 and 2):
SLV returns for d = 1e8: x= 1,6654825901, yx= 9,44475624443e14, z= 0 Despite of the strange result, it's fully correct. The function Valentin gave us is periodic. It has an infinite number of roots. And the neighborhood of each root is extremely illconditioned. Close to the roots, the function runs almost horizontally. So any search algorithm working with the tangent to the curve will become unstable, i.e. the next sample point may be far off and another root will be found (remember: there is an infinite number of them). OK, and what's to be learned? Do not throw anything you don't know in any automatic device :)
Edited: 31 Aug 2012, 6:38 a.m. after one or more responses were posted
08292012, 03:56 PM
Buenas noches Valentin, Calling SLV in default DECM, FIX 11 returns 1.570 796 326 79(4 896) with the last four digits used internally and only displayed by the equivalent of SHOW.
Calling SLV in FIX 11, DBLON returns
Cordialmente,
001 LBL A Edited: 29 Aug 2012, 4:05 p.m. after one or more responses were posted ▼
08292012, 04:04 PM
I would like to point out once more that IMHO it's not a good idea at all to make the results of SLV dependent from the display setting. This is completely different from the way classic HPs did it  including the 15C and others that the manual refers to. And if really required, the user may limit accuracy manually in other ways.
Edit after Walter's edit: Of course we can do it shorter on the 34s. 001 LBL ABTW, the final digit 2 is the rounded 34th digit of Pi (3) divided by 2 and rounded up. Simply set RM 2 and you get ...9751. ;) Dieter
Edited: 29 Aug 2012, 4:18 p.m. ▼
08292012, 05:55 PM
The solver isn't particularly dependent on the display setting. The test for equality with zero after each function evaluation is via x[approx]0? which is display setting based but is only different from a standard x=0? conditional if you are in FIX mode. The initial test for the two estimates being equal is also display dependent but this shouldn't impact most searches  if your guesses are this close together and bracket a root, you already know it & don't need the solver.
▼
08292012, 06:28 PM
Quote:Except in FIX mode. ;) As far as I understand, the solver quits as soon as the function result rounds to zero. Which I think is not a good idea. If the user wants to have it this way, he may simply add a ROUND instruction at the end of the function subroutine. Dieter
08292012, 05:17 PM
Valentin, I do wish you would get a 34S. :) ▼
08292012, 05:55 PM
Me too. I'd like to see the device stressed to the limit to see what it is really capable of.
08292012, 06:05 PM
I do not want to pour too much water into the wine, but there might be a simple reason why the 34s instantaneously returns a correct result: if its first guess simply is the (arithmetic) mean of the two guesses  that's pi/2 here  and this value solves the equation (i.e. the returned result is zero, which numerically is true for many values near pi/2), the solver may quit and simply return this result.
Now look at this: Guesses result DBLOFF result DBLONThe two guesses in line 4 both do not solve the equation, but their arithmetic mean is close enough to return exactly 1 for sin(x + cos(x)), at least to 34 digits. And so... Then look at the last line. f(1,5707) is about 1,1E26, which is rounded to zero in single precision and so the solver quits. However, in double precision that's not close enough to zero, whereas f(1,5708) is, so here simply the second guess is returned. Hmhmhmhmhmhmhmmm... Dieter
Edited: 29 Aug 2012, 6:23 p.m. after one or more responses were posted ▼
08292012, 06:18 PM
Quote: Yes it will stop immediately if any function evaluation is zero.
08292012, 06:50 PM
Quote: Looks like Valentin has laughed last, at last. :) ▼
08302012, 10:55 AM
I am sure he is ROFLing all the way. This is a perfect example of "know your maths and know your machine", otherwise GIGO. This function is very flat in the region of the roots. E.g. the 35s will find any solution from approximately 1.55 to 1.59 acceptable due to the 12 digit precision. The guesses have to be reasonably close to the desired root as well (1.4 to 1.9), otherwise the solver could get to a point where it doesn't converge (it gets the same nonzero answer for two values with a small delta) and gives up.
08292012, 03:59 PM
Quote: 001 LBL DBTW, in the world of limitedprecision arithmetics there is more that just one single value for which sin(x + cos(x)) equals 1 when rounded to working precision. For instance, for x = 1,57 the result is 1 even when rounded to 20 (!) digits. Simply because x + cos(x) approaches pi/2. Dieter
Edited: 29 Aug 2012, 4:08 p.m.
08312012, 08:22 AM
I did some playing around with the function. It's not only flat at the root, it's damn flat: the first 5 derivatives of the function are all zero at the root. No wonder that numerical solver algorithms using the derivative of the function get in trouble. The only scheme I'm aware of that can reliably solve such an equation must use bisection or a similar approach and the first two guesses need to bracket the solution. Even then, any 'solution' which evaluates to (almost) zero in the given accuracy is acceptable
08302012, 05:45 AM
Also am I correct that you can only store 26 programs since the initial program labeling can only be one letter from A to Z? if so what a waste of the 30kb of available program memory. ▼
08302012, 06:06 AM
Actually it's 27 as you can have one unlabelled space. ▼
08302012, 06:38 AM
Quote:
▼
08302012, 07:15 AM
It is manageable. For example the curve fitting programs in chapter 16 of the manual use several labels, I have combined them into 1 label: curve fitting program for the 35s ▼
08302012, 09:31 PM
Quote:I looked at your program. I suggest that you should change the sequence of operations so that the data is entered and stored before the type of fit is selected. ▼
08312012, 06:30 AM
Thanks, sounds like a sensible thing to do. I'll look into it when I have some time. ▼
08312012, 04:58 PM
Quote:Consider adding a best fit option by comparing the correlation coefficients. See the HP48s for an example. Also consider calculating and displaying the residuals. Both of these options are easy if you enter the data first.
08302012, 06:17 AM
Quote:
No, you are absolutely wrong. 26 programs is more than enough for calculator, and 30K is not too much, since every operator consumes 3 bytes and every register 37 bytes. ▼
08302012, 06:37 AM
No limit on labels? but the initial label at the top only allows one alpha letter entry. if you can only have 27 programs that means each program needs to use average of a little over 1kb. That's fairly sizeable programs. i don't think most programs use more than 1/4 or 1/2 kb. ▼
08302012, 08:41 AM
Quote:
You have two statements. Regarding program sizes: my average program on HP35S is approx 2.5KB, it comprises of about 450 lines and contains approx 30 number constants. Your mileage may vary.
▼
08302012, 06:28 PM
Quote:
▼
08302012, 09:46 PM
Quote:What you should do is constrct a menu a the beginning of the master program. Something like this will do for three sub programs AAA, BBB, and CCC. Z001 LBL Z Edited: 30 Aug 2012, 10:41 p.m. ▼
08302012, 10:47 PM
That might be fine if these are related subprograms and subroutines, but if they are all completely not related to each other, then we might definitely have a mess on our hands. ▼
08312012, 12:29 AM
Personally, I doubt anybody having 26 completely independent programs. There will always be some classes (possible).
08312012, 06:25 AM
Quote: Quote:I use 15 labels and have used approx 15kB on my 35s. With the 35s I have a piece of paper where I write the label and the program. This is either in the form of "D: Pauli's game" or "Z002: R>P ; Z015: P>R". Let's say labels can have 2 alpha characters, then it could become: "AD: Pauli's game" or "ZA: R>P ; ZB: P>R". I really don't see any less confusion keeping track of it all. I am going to need to keep notes anyway to remember the now 676 possible program labels. OK, so I am averaging 1kB per label, so theoretically I could run out of labels before running out of memory. However, the calculator needs free RAM to do it's own calculations (e.g. the manual states the integrate function is particularly memory hungry). Also free RAM is needed to run the programs, particularly if they make use of functions like solve, integration or use indirect addressing. I am not saying things are ideal on the 35s, but in this case "where there's a will, there's a way", or rather "there is a way, do you have the will?". 
Possibly Related Threads…  
Thread  Author  Replies  Views  Last Post  
Impressive TI NSpire CX CAS Multiple Integration  Namir  43  11,721 
12232011, 05:24 AM Last Post: Thomas Klemm 

Very impressive aucton on TAS  Namir  18  3,964 
03032011, 09:27 PM Last Post: Palmer O. Hanson, Jr. 