HP-27 HP-27 ==== Just a note that http://bugs.hpcalc.org/ is set up to handle bug reports on the HP49G+ and HP48GII platforms as well as the HP49G platform. I'm not sure when Eric added these, but they're there now. Let's make use of this. I hope that HP is monitoring bugzilla. Of course, use common sense when posting bugs. Using bugzilla to ask for a higher resolution display or an RS-232 port on the 49g+, for example, wouldn't make sense. Make sure that you're really using the calculator correctly before posting a problem as a bug; maybe ask on the newsgroup first. Pay attention to the platform, version, and so on when making bug reports. Before reporting a new bug, check whether it's already been posted, and if it has already been posted, add any relevant additional information to the original post rather than starting a new one. If it's not really a bug but you'd like to see a feature added, post it as an enhancement. I'm not sure whether bugzilla would be the place to report hardware problems such as keypresses being missed; I'd think not. But on the other hand, for all I know, maybe that's partly or even entirely a software problem. Nor am I sure about reporting problems with HP supplied software such as the USB driver or Conn4x. I'd think it would be. Of course problems with non-HP software should be directed to the developer, not posted a on bugzilla. -- James ==== > Just a note that http://bugs.hpcalc.org/ > is set up to handle bug reports on the > HP49G+ and HP48GII platforms as well as > the HP49G platform. and entered over a dozen bugs! :-) -Joe- ==== >Just a note that http://bugs.hpcalc.org/ is set up to handle bug reports >on the HP49G+ and HP48GII platforms as well as the HP49G platform. I'm >not sure when Eric added these, but they're there now. Let's make use of >this. I hope that HP is monitoring bugzilla. > Beta testing program?... A.L. ==== Bugzilla is web based bug tracking software developed by mozilla.org for tracking bugs for the Mozilla browser. It's open source and freely available. Not sure if that's what you were asking... > > > Beta testing program?... > > A.L. ==== > > >>Just a note that http://bugs.hpcalc.org/ is set up to handle bug reports >>on the HP49G+ and HP48GII platforms as well as the HP49G platform. I'm >>not sure when Eric added these, but they're there now. Let's make use of >>this. I hope that HP is monitoring bugzilla. >> > > > Beta testing program?... > > A.L. When I go to hpcalc, I get the ibiblio mirror that has not been updated since Oct. 17. Also, there does not seem to be a 40g+ setcion, which would be nice. Martin Cohen ==== > >> >> >>> Just a note that http://bugs.hpcalc.org/ is set up to handle bug reports >>> on the HP49G+ and HP48GII platforms as well as the HP49G platform. I'm >>> not sure when Eric added these, but they're there now. Let's make use of >>> this. I hope that HP is monitoring bugzilla. >>> >> >> >> Beta testing program?... >> >> A.L. > > When I go to hpcalc, I get the ibiblio mirror that has not been > updated since Oct. 17. > > Also, there does not seem to be a 40g+ setcion, which would be nice. > > Martin Cohen > I meant 49g+, not 40g+. Martin Cohen ==== I just received my new HP49G+ calc from Samson Cables and quickly noticed that the F6 key doesn't work properly compared to the rest of the keys. I need to press it harder for it to make a beep. I am VERY disappointed. ==== If that's the only key theres a problem with you should count yourself lucky. > I just received my new HP49G+ calc from Samson Cables and quickly > noticed that the F6 key doesn't work properly compared to the rest of > the keys. I need to press it harder for it to make a beep. > I am VERY disappointed. ==== Wow. I get mine tomorrow and face transfering 10 years of programming from my 48GX. Hope it isn't too dissappointing. Scott > I have just received my new HP 49G+. After opening the box, bringing > it into life with the batteries and downloading the last ROM version, > I started trying it to see how it works. > > I like the screen and the leathercase. It responds quickly and behaves > fine generally speaking, pretty much like an HP 49G. > > But I can assure you that most of the things being said in this > newsgroup are true: > > 1. The bottom row of the screen flickers a bit every now and then. It > is something wery short but IT IS there. Surely, new software > refinements will avoid this. > > 2. The keyboard does not always register your keypress. I think it is > (again) a software problem since the keyboard test (I did it three > times) does not show any misbehaviour with the keys. So, unless the > keyboard test is cheating us, new software upgrade should solve this > matter. > > 3. I witnessed a garbage collection scene. It lasted for 1 or 2 > seconds only and then disappeared. Again, good software improvements > will avoid this dirty show. > > 4. A small bit of golden paint has gone from the top. It is something > very small but unfortunately I SEE the damn thing everytime I look at > the screen. True, this time a new software improvement will not solve > this strange disease (paint peeling) unless the improvement is SO > incredibly GOOD that I forget about the rest. > > My next step was to compare this calculator with two old glories: HP > 28S and HP 48GX. I wanted to compare their speeds and ended up > comparing everything. > > To make it short, I keyed in a simple program (Fibonacci modified with > other tracendental operations). The result was clear: > > HP 49G+ speed = 2 x HP 48GX speed = 4 x HP 28S speed > > There I was looking at the three jewels. The HP 28S was showing its > elegancy, its excellent and expanded keyboard which makes programming > a pleasure and its pure RPN system (yes, with a big ENTER key). > > Then I had the robust and well designed HP 48GX, the height of HP's > development, still pure RPN (and yes, yes, with a big ENTER key > again), ready to be expanded and with improved software and trustable > keyboard. > > And finally, the newcomer. > > Which one is the best? Who cares! Even the question is stupid. > > highest model and I admit that I love its great improvements over the > other two models concerning editing and creating programs, function > graphing, conection to other calculators and computers and its > excellent and cheap storage system (just to keep and retrieve files, > remember this is not a MP3 player!) And let's not forget speed! > > The point is the other two calc belong to the past and only this > present time really matters. There won't be HP 15C or HP 41C anymore; > we may like it or not. Yes, I would love the HP 49G+ repackaged as a > HP 48GX but that is not going to happen. Things have changed and most > of us (already aged) don't like it. New style designs, new materials, > new software, new needs. HP could desing a very good machine with the > best materials, with a price tag of 1000 euros and they could sell > 2000 or 3000 machines. People are NOT ready to pay that much anymore. > And HP can earn more money selling ink cartidges. > > We have to be more positive and see future with an open mind. > Continuous destructive criticism never achieved any positive result. > It is true that HP must be told about the deficiencies of the new > machines but in a helping way. > ==== > Here is probably the best answer you'll be able to find: Interesting, but their history is wrong. Adding machines with one column of buttons per digit position predated cash registers by at least a decade. Adding machines and calculators did not evolve from cash registers, but rather cash registers evolved from adding machines. I was going to send them a correction, but they require registration to post messages, and I'm generally not willing to take the time to do that on any web site that I don't use on a regular basis. ==== >> Here is probably the best answer you'll be able to find: > Interesting, but their history is wrong. Adding machines with one > column of buttons per digit position predated cash registers by > at least a decade. Adding machines and calculators did not evolve > from cash registers, but rather cash registers evolved from adding > machines. Indeed you are correct. I think that the most logical reason for the keypad on telephones going from top to bottom is the letters on the keys. > I was going to send them a correction, but they require registration > to post messages, and I'm generally not willing to take the time > to do that on any web site that I don't use on a regular basis. -- -Joshua Belsky jjbelsky@yahoo.com http://belsky.net ==== That's great news - but please report on your findings; in particular, have any of the experiences by users from this NG been corrected, or are we still left wanting ?? Manfred. ----- > There are 49g+ in Perth(WA Australia) now. I just got mines yesterday from > SurveySoft for $330 AUD. ==== > > That's great news - but please report on your findings; in particular, > have any of the experiences by users from this NG been corrected, or > are we still left wanting ?? > > Manfred. > 1. The 7 and 3 key require more force 2. The is no percievable flickering unless clock is on 3. Good paint 4. Don't know about batteries yet. Haven't upgraded rom either. No problems with connection software. Wing Fong Wong ==== Is it possible to make a user function which accepts two inputs, which I can also use in EQW? I'd like to be able to do this: ...RP(r1,r2)... to compute paralell resistances. I can do it for two resistances on the stack easily enough, but would like to be able to use it in EQW. XYZ ==== r1*r2 RP(r1,r2)= ------- r1+r2 This worked for me in EQW. I used the SPC (space) key separating the local variables for the function RP(r1,r2). Then use left shift 2 (DEF) key to create the function. Entering any combination of two resistor values then produces the parallel equivalent value of the network. Hope its what you were trying to accomplish. >Is it possible to make a user function which accepts two inputs, which >I can also use in EQW? I'd like to be able to do this: ...RP(r1,r2)... >to compute paralell resistances. I can do it for two resistances on >the stack easily enough, but would like to be able to use it in EQW. > >XYZ ==== > Is it possible to make a user function which accepts two inputs, which > I can also use in EQW? I'd like to be able to do this: ...RP(r1,r2)... > to compute paralell resistances. I can do it for two resistances on > the stack easily enough, but would like to be able to use it in EQW. Yes, just type your function name and use spaces to seperate the resistor values. I just tried it, it works. AL > > XYZ ==== > > I love all TI-borgs. They become so cute when teased! > > Hmm, I've never thought of myself as cute :-) Me either. ==== > http://www.hp-sources.com/hp49plus/Softs49Gplus/TronGR11.zip What is the difference between Mode 1 and Mode 2? Matthew F. G. ==== In mod2, the tunnel becomes smaller and smaller. My top score in Hard mod 2 is 1214 > > http://www.hp-sources.com/hp49plus/Softs49Gplus/TronGR11.zip > > > What is the difference between Mode 1 and Mode 2? > > Matthew F. G. > ==== > It's about 2 weeks since I got my HP49g+. But I read this group for > months before it arrived. I am a programmer and now program in DELPHI > and have owned every model calculator that HP has come out with since > the HP65. Some many years ago I also programmed these calculators. But > back then you got every bit of info from HP. Now with this purchase of > the hp49G+ and the hp49G before it, the information that HP supplies > is woofully inadequate. > > I have downloaded all the books and tutorials that I could find at > hpcalc.org and others but I am still left wanting. If you think of the > indepth manuals that you get with a product like Delphi (6 for the > moment)you can imagine what I mean. > > HP we need complete and comprehensive manuals in order to program and > use the HP49G+ to its fullest. If they exist now, could you tell me > where to find them? > > I am talking about UserRpl and SystemRpl. I have all the usual books > and downloads for both languages but still need more. More indepth > expainations and examples. Take a case in point. Informs. Everything I > have read about it thus far cannot tell me how to program a checkbox > as a field in an inform. Yes there are programs to do them, but how > did the programmer program it in. What were the commands? see my > point. > > I am usually a helper in that I write lots of useful programs but I > need the tools. All I really have now is the HP49G+, I now need the > indepth manuals. > > HP where are they? If you haven't already done so, visit http://membres.lycos.fr/ekalin/. The 49G and 49g+ inherited a lot from their predecessors, the 48 series, which in turn inherited a lot from the 28 series. Don't ignore information written for these. Visit http://www.engr.uvic.ca/~aschoorl/ and http://m.webring.com/hub?ring=hp48 -- James ==== > > It's about 2 weeks since I got my HP49g+. But I read this group for > > months before it arrived. I am a programmer and now program in DELPHI > > and have owned every model calculator that HP has come out with since > > the HP65. Some many years ago I also programmed these calculators. But > > back then you got every bit of info from HP. Now with this purchase of > > the hp49G+ and the hp49G before it, the information that HP supplies > > is woofully inadequate. > > > > I have downloaded all the books and tutorials that I could find at > > hpcalc.org and others but I am still left wanting. If you think of the > > indepth manuals that you get with a product like Delphi (6 for the > > moment)you can imagine what I mean. > > > > HP we need complete and comprehensive manuals in order to program and > > use the HP49G+ to its fullest. If they exist now, could you tell me > > where to find them? > > > > I am talking about UserRpl and SystemRpl. I have all the usual books > > and downloads for both languages but still need more. More indepth > > expainations and examples. Take a case in point. Informs. Everything I > > have read about it thus far cannot tell me how to program a checkbox > > as a field in an inform. Yes there are programs to do them, but how > > did the programmer program it in. What were the commands? see my > > point. > > > > I am usually a helper in that I write lots of useful programs but I > > need the tools. All I really have now is the HP49G+, I now need the > > indepth manuals. > > > > HP where are they? > > If you haven't already done so, visit http://membres.lycos.fr/ekalin/. > > The 49G and 49g+ inherited a lot from their predecessors, the 48 series, > which in turn inherited a lot from the 28 series. Don't ignore > information written for these. > > Visit http://www.engr.uvic.ca/~aschoorl/ and > http://m.webring.com/hub?ring=hp48 I was mostly refering to the specific changes that had to have happened as a result of changing the processor. ==== > It's about 2 weeks since I got my HP49g+. But I read this group for > months before it arrived. I am a programmer and now program in DELPHI > and have owned every model calculator that HP has come out with since > the HP65. Some many years ago I also programmed these calculators. But > back then you got every bit of info from HP. Now with this purchase of > the hp49G+ and the hp49G before it, the information that HP supplies > is woofully inadequate. > > I have downloaded all the books and tutorials that I could find at > hpcalc.org and others but I am still left wanting. If you think of the > indepth manuals that you get with a product like Delphi (6 for the > moment)you can imagine what I mean. > > HP we need complete and comprehensive manuals in order to program and > use the HP49G+ to its fullest. If they exist now, could you tell me > where to find them? > > I am talking about UserRpl and SystemRpl. I have all the usual books > and downloads for both languages but still need more. More indepth > expainations and examples. Take a case in point. Informs. Everything I > have read about it thus far cannot tell me how to program a checkbox > as a field in an inform. Yes there are programs to do them, but how > did the programmer program it in. What were the commands? see my > point. > > I am usually a helper in that I write lots of useful programs but I > need the tools. All I really have now is the HP49G+, I now need the > indepth manuals. > > HP where are they? I'm sure you wont need to do much aside from promising HP copious amounts of money and signing a stack of non-disclosure agreements to get at the information. Seriously though, I would love to find some real information on this calculator, and all my efforts to do so have failed. Reverse engineering it seems like the best way to me right now, but I don't have the spare change kicking around to get anything more than the ROM from HP's website. If someone could help me find some key pieces of information like the ROM entry point and which parts are Saturn assembly and which are ARM assembly, I'm sure that we could find out plenty with IDA and a saturn disassembler. ==== > Another keyboard consideration. > I personnaly prefer the keyboard layout with the aritmetic operators: > +, -, x and Ö on the left side. > Why ? > Because, since I am rigth handed, while my fingers rest on number keys > when punching data I see, without obstruction, the arithmetic > operators key and so I loose no split second hitting the rigth one. > This layout was used on nearly every calculator up to and including > the 41C serie. I checked the HP Museum for some pictures to ascertain > that. I agree with you completely, but for a different reason. Like you, I am right-handed and normally hold the calculator in my left hand. However, I generally use my left thumb to press the keys and use my right hand for jotting things down on paper, typing on a PC keyboard, etc. at the same time. The 41 is very easy to use this way, but the 48 is more difficult because it's a little bit wider and the keys are smaller. I have to shift the calculator a little in my hand to get my thumb to reach all the way across to the +, -, x and Ö keys. If those keys had remained on the left and the ALPHA, SHIFT and ON keys had been placed on the right then it would be much easier to use. The arrangement of the arithmetic keys and the choice of colors (for the G series) are my only complaints about the 48 keyboard. (At least ENTER is the right size and in the right place!) -- Wayne Brown (HPCC #1104) | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== > > > Another keyboard consideration. > > > I personnaly prefer the keyboard layout with the aritmetic operators: > > +, -, x and Ö on the left side. > > > Why ? > > > Because, since I am rigth handed, while my fingers rest on number keys > > when punching data I see, without obstruction, the arithmetic > > operators key and so I loose no split second hitting the rigth one. > > > This layout was used on nearly every calculator up to and including > > the 41C serie. I checked the HP Museum for some pictures to ascertain > > that. > > I agree with you completely, but for a different reason. Like you, > I am right-handed and normally hold the calculator in my left hand. > However, I generally use my left thumb to press the keys and use my > right hand for jotting things down on paper, typing on a PC keyboard, > etc. at the same time. If you're right-handed, why are you holding the calculator in your weak hand? Also it strikes me as a bit odd that you'd need to see the arithmetic buttons for speed. Maybe I've been using the calculator for too long, but the fingers (thumb really as I hold my 48G in my right hand, using my thumb to push the various buttons) knows where they are like in typing or playing piano, though without looking I can tell you its plus, minus, times, divide from bottom to top. ==== >> >> > Another keyboard consideration. >> >> > I personnaly prefer the keyboard layout with the aritmetic operators: >> > +, -, x and Ö on the left side. >> >> > Why ? >> >> > Because, since I am rigth handed, while my fingers rest on number keys >> > when punching data I see, without obstruction, the arithmetic >> > operators key and so I loose no split second hitting the rigth one. >> >> > This layout was used on nearly every calculator up to and including >> > the 41C serie. I checked the HP Museum for some pictures to ascertain >> > that. >> >> I agree with you completely, but for a different reason. Like you, >> I am right-handed and normally hold the calculator in my left hand. >> However, I generally use my left thumb to press the keys and use my >> right hand for jotting things down on paper, typing on a PC keyboard, >> etc. at the same time. > If you're right-handed, why are you holding the calculator in your > weak hand? Because, as I said, I'm usually using my right hand for other things, like writing with a pencil or typing on a PC keyboard, or using a mouse, or holding a Coke, etc. When I'm *not* doing something else at the same time I usually have the calculator on a tilted stand on my desk so that I can use *both* hands to manipulate the keys. In that situation the layout doesn't matter as much, since I'm familiar with it and all the keys are easy to reach. > Also it strikes me as a bit odd that you'd need to see the arithmetic > buttons for speed. Maybe I've been using the calculator for too long, > but the fingers (thumb really as I hold my 48G in my right hand, using > my thumb to push the various buttons) knows where they are like in > typing or playing piano, though without looking I can tell you its > plus, minus, times, divide from bottom to top. For me the issue isn't speed or being able to see the keys, it's that my thumb isn't long enough to reach easily across the width of the entire keyboard. I can reach the first four columns easily but have to juggle the calculator a bit in my hand to reach the fifth column, which is a bit awkward and makes me worry that sooner or later I'm going to drop it while doing this. I'd prefer to have all the numeric and arithmetic keys in the first four columns for that reason. -- Wayne Brown (HPCC #1104) | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== > > For me the issue isn't speed or being able to see the keys, it's that my > thumb isn't long enough to reach easily across the width of the entire > keyboard. I can reach the first four columns easily but have to juggle > the calculator a bit in my hand to reach the fifth column, which is a > bit awkward and makes me worry that sooner or later I'm going to drop > it while doing this. I'd prefer to have all the numeric and arithmetic > keys in the first four columns for that reason. While its not too much of a problem for me to hold the calculator in my left hand and reach the far column (my piano teacher always commented on the reach my hand size gives me) I can see how it would be a problem. But that does raise the issue of why the calculator should be changed to suit you at the expense of those who would then find the new arrangement difficult. ==== > But that does raise the issue of why the calculator should be changed > to suit you at the expense of those who would then find the new > arrangement difficult. It also raises the issue of why it ever was changed in the first place, since the arrangement I want is exactly what the 41 already had. In fact, almost every HP handheld from the first HP-35 right down to the HP-41 had the arrangement I prefer. Why was it changed on the 48 and following models at the expense of everyone who was accustomed to the original arrangement? -- Wayne Brown (HPCC #1104) | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== [This is a reply and a sort of mini-challenge] > It also raises the issue of why it ever > was changed in the first place ... Simple answer: Right-hand efficiency. Longer answer: The [+] key was moved to the bottom right corner (where it has almost always been on huge clunky adding machines) for the simple reason that it's the key closest to your right hand and therefore easiest to reach. The [+] key is the most-used key on large adding machines (and that's why they are called -- all together now -- ADDING machines). On the latest HP calculators, the supposition is that the ENTER key is the most-used key, and that's why it was moved to that position, bumping up the [+] key. Are HP scientific calculators just glorified adding machines? Yes. For all their power and glory, the most-used function is *still* addition. (Maybe not by YOU, but certainly by most users). Bottom line: It was NOT an arbitrary choice. It may clash with your personal preferences, personal artistic sense, ingrained habits, or left-thumb usage (in my case, all four of the above), but there WAS a reason for the change. Mini-challenge: Can anybody here think of a way to write an invisible program that keeps count of exactly how many times each key is pressed? To be bearable, the program would have to be transparent to the user, that is, not interfere with regular operations, nor noticeably slow down the user interface. It would be very interesting to see an actual list of the keys sorted in most-used to least-used order. Placement of keys could then be based on reality instead of suppositions. It would also help individual users place their key assignments in the most efficient locations. -Joe- ==== Sorry, but it was changed with the 10-series. 11c, 12c, and 15c have the arithmetic keys arranged the way the 48/49 have them These calculators were intro'd back in 1981. Gene -- * These statements and opinions are mine alone and do not reflect my employer's views. * > > > But that does raise the issue of why the calculator should be changed > > to suit you at the expense of those who would then find the new > > arrangement difficult. > > It also raises the issue of why it ever was changed in the first place, > since the arrangement I want is exactly what the 41 already had. > In fact, almost every HP handheld from the first HP-35 right down to > the HP-41 had the arrangement I prefer. Why was it changed on the 48 > and following models at the expense of everyone who was accustomed to > the original arrangement? > > -- > Wayne Brown (HPCC #1104) | When your tail's in a crack, you improvise > fwbrown@bellsouth.net | if you're good enough. Otherwise you give > | your pelt to the trapper. > e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== > Sorry, but it was changed with the 10-series. > 11c, 12c, and 15c have the arithmetic keys arranged the way the 48/49 have > them > These calculators were intro'd back in 1981. Well, I *did* say almost every HP handheld from the first HP-35 right down to the HP-41, not every handheld. I'm quite familiar with the Voyager calcs, since my 16C is my most highly-prized HP and is the one I have owned the longest. But the Voyagers are horizontal-format calculators, and require (for me at least) two-handed usage anyway. It actually took me a little while to get used to the 41 keyboard layout because I'd been using the 16C for about a decade before getting my first 41. But I quickly became convinced that it was ideal for a vertical-format calculator. So now, I don't see any reason why these two basic layouts -- one for horizontal calcs, the other for vertical -- shouldn't be preserved (almost) unchanged for any conceivable future calculator. If you put an HP-35 and an HP-41CX side-by-side, there is a very clear family resemblance. A 41 with a card reader installed is almost the same size and shape as a 48. I don't see why the 48 couldn't have looked almost exactly like a 41 with a large LCD in place of the card reader. In fact, if HP is still making calculators 100 years from now, I think it *still* should look more like an HP-35 than a 49G+, or even a 48. -- Wayne Brown (HPCC #1104) | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== Well, you had said Why was it changed on the HP48? It wasn't. It was changed on the series 10, the 75C, the 71B, the 28C, etc. By the time the 48SX was introduced in 1990, it had been 10 years since a vertical format calculator was introduced with the function keys on the left side. No surprise it me that the convention in place from 1972 until 1980 (8 years) was not carried over after a 10 year period where the function keys had been on the right side. By 1990, they had been on the right side longer than they had been on the left side earlier. The last calculator with the arrangement you prefer was the 41c/34c, I think. That was 23 years ago. I know the lack of a large ENTER key in the right spot of the keyboard is a show-stopper for you (although you do seem to get by with a vertical ENTER key in a different location on your 16c), but that's a preference that may not come back. Suppose someone had decided I'll never buy another business calculator unless it has a large key labeled 'SAVE' in the middle of the keyboard...it's nonsense to rename a key after it has been in use by business people for several years just to match what the engineering calculators show Things change. I'm just glad to have RPN. Gene -- * These statements and opinions are mine alone and do not reflect my employer's views. * > > Sorry, but it was changed with the 10-series. > > > 11c, 12c, and 15c have the arithmetic keys arranged the way the 48/49 have > > them > > > These calculators were intro'd back in 1981. > > Well, I *did* say almost every HP handheld from the first HP-35 right > down to the HP-41, not every handheld. I'm quite familiar with > the Voyager calcs, since my 16C is my most highly-prized HP and is the > one I have owned the longest. But the Voyagers are horizontal-format > calculators, and require (for me at least) two-handed usage anyway. > It actually took me a little while to get used to the 41 keyboard > layout because I'd been using the 16C for about a decade before getting > my first 41. But I quickly became convinced that it was ideal for a > vertical-format calculator. So now, I don't see any reason why these > two basic layouts -- one for horizontal calcs, the other for vertical -- > shouldn't be preserved (almost) unchanged for any conceivable future > calculator. > > If you put an HP-35 and an HP-41CX side-by-side, there is a very clear > family resemblance. A 41 with a card reader installed is almost the same > size and shape as a 48. I don't see why the 48 couldn't have looked > almost exactly like a 41 with a large LCD in place of the card reader. > In fact, if HP is still making calculators 100 years from now, I think > it *still* should look more like an HP-35 than a 49G+, or even a 48. > > -- > Wayne Brown (HPCC #1104) | When your tail's in a crack, you improvise > fwbrown@bellsouth.net | if you're good enough. Otherwise you give > | your pelt to the trapper. > e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== > Well, you had said Why was it changed on the HP48? > It wasn't. It was changed on the series 10, the 75C, the 71B, the 28C, etc. > By the time the 48SX was introduced in 1990, it had been 10 years since a > vertical format calculator was introduced with the function keys on the left > side. No surprise it me that the convention in place from 1972 until 1980 > (8 years) was not carried over after a 10 year period where the function > keys had been on the right side. By 1990, they had been on the right side > longer than they had been on the left side earlier. > The last calculator with the arrangement you prefer was the 41c/34c, I > think. That was 23 years ago. I thought the 48 was supposed to be the successor to the 41. Isn't that where the 4 in the model number comes from? So what difference does it make if some other models had a different layout? And what does the passage of 10 years (or 23, or any other length of time) have to do with it? I can't see what's wrong with having one layout for the vertical format machines and another for the horizontal models. (I would, in fact, be opposed to a Voyager-style machine with a 41-type key layout.) In fact, I wouldn't mind if every family of HP calcs had completely different layouts (as long as they're original HP-developed layouts and not copies of some other company's layout). But there always should be at least *one* top-of-the-line model whose design pays clear homage to the 35 design. > I know the lack of a large ENTER key in the right spot of the keyboard is a > show-stopper for you (although you do seem to get by with a vertical ENTER > key in a different location on your 16c), but that's a preference that may > not come back. The vertical ENTER is still large and prominent. As I thought I'd explained a time or two before, the primary benefit of the large ENTER key for me is that it proclaims loudly and unmistakably, THIS IS AÊHEWLETT-PACKARD RPN CALCULATOR! I like the idea of HP being *proud* of the technology they invented, of them *wanting* to emphasize that their products are different, that they have an unshakeable belief that anything HP invents must *by definition* be better than anything anyone else invents. I like the implication that you're not just buying a product, you're being initiated into an elite society and that you can't use Their Products unless you become One of Them. That's the clear impression that I received from them when working with their HP3000 minicomputers years ago. Calling one of their service technicians was like consulting a member of a priesthood of wizards and mysterious gurus who were only too happy to share their arcane knowledge with a willing pupil. (In all my years of dealing with IBM, I've *never* had an IBM tech instruct me over the phone to open the back of a CPU cabinet, rearrange some of the cables and dip switches and reinitialize an I/O board -- all with the processor running *Production* applications! Yet an HP Customer Engineer had me do that on several occasions while troubleshooting I/O subsystem problems. On another occasion a different CE talked me through dismantling a washing-machine-sized disk unit to remove a defective chip that he said wasn't needed anyway because, It's only there to keep idiots from formatting the wrong disk pack. You can run just fine without it. It was rather like working with Scotty on the Starship Enterprise to squeeze a little more out of the warp engines. :-) *That's* the kind of We're better than the rest, the rules don't apply to us attitude that I came to expect from HP -- not the current We're afraid to be different, we have to look and act like everybody else. > Suppose someone had decided I'll never buy another business calculator > unless it has a large key labeled 'SAVE' in the middle of the > keyboard...it's nonsense to rename a key after it has been in use by > business people for several years just to match what the engineering > calculators show Actually, I'd have no problem with that. Keeping the HP-80's SAVE key on the business models would be a good way to distinguish the business and engineering calculators. In fact, I think I'd prefer it that way. > Things change. I'm just glad to have RPN. So am I. Unfortunately, it looks like I'll only have it until all the older models have worn out... -- Wayne Brown (HPCC #1104) | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== oN 06-Nov-03, Wayne Brown said: > It also raises the issue of why it ever was changed in the first > place, since the arrangement I want is exactly what the 41 already > had. In fact, almost every HP handheld from the first HP-35 right > down to the HP-41 had the arrangement I prefer. Why was it changed > on the 48 and following models at the expense of everyone who was > accustomed to the original arrangement? Damned good question! But it's Carly's HP now, and she doesn't seem to be much on constructive input.... -- Bill ==== > Priorities, I guess. I guess also it is possible to over-depend on the > AUR. I may have a problem there, too, as I am using it also to cover my > tail as far as using my 49G+ as well. Funny that you should mention that. It looks as if HP expects us to have the AUR and use it. See page C-13 References for non-CAS commands in the 49g+ user's guide. > Anyhow, a well thought out, detailed answer and I thank you for it. In > fact, I saved it as a textfile so that I can peruse it at a more > leisurely pace (stuff here expires in, what, 2 days?). It depends on which usenet server you're using, but there's the Google archive. Visit http://groups.google.com/groups?q=comp.sys.hp48 to read this newsgroup all the way back to 1991 (see http://groups.google.com/groups?group=comp.sys.hp48&selm=1900%40seq.uncwil.e du). Well, I suppose some posts may have been lost in the transition from archive is a great research tool. But although it's great for researching old posts, the most recent message in the archive may be several hours old, so it's not the best server for active participation. What we write is available over the whole world and preserved for posterity, so restraint when posting is wise. -- James ==== He he he... But hey, I'd like to think I've also grown up more over the years! Back to calculators... > ... > What we write is available over the whole world and preserved for > posterity, so restraint when posting is wise. > > > ==== : : 4. A small bit of golden paint has gone from the top. It is something : very small but unfortunately I SEE the damn thing everytime I look at : the screen. True, this time a new software improvement will not solve : this strange disease (paint peeling) unless the improvement is SO : incredibly GOOD that I forget about the rest. I've now had two -49g+s--first one died--and the paint is still sticking to both. But the main reason for paint peeling, I believe, is lousy preparation and lousy pre-cleaning of the surface before applying the paint. It's none of my business, but if I were you I would send the defective thing back--preferably to HP directly, although they won't take it until it's 31 days old--so that HP can see for themselves that they've got a major process problem. Subcontracted work can be very successful, provided that it is contracted to experts who both audit their own processes and host audits by their customers. These calculators should all be pulled from store shelves all over the world, sent straight back to China, and there the manufacturer should have to inspect every single one of them. If the failure rate is over 4 defectives in 1,000,000 [yes, I meant to say one million] they should be forced to replace the top plastic part on every single calculator, submit them for reinspection, and then relaunch the product just in time for Christmas. Will it happen? NO Would it happen if I were Quality Assurance Director for HP? NO And, I fear, the reason is that HP's QA Department has had its balls cut off by the attitude conveyed down to the ranks by Fearless Leader Lady. I have loved the little blue hp logo for 33 years. Once I was in the hospital for chest pain; the emergency room people ripped off my clothes, shaved both hairs off my chest, hooked up countless wires in a rainbow of colors to me, and threw me into intensive care. The only thing that looked the least bit familiar was the tiny little blue hp logo on the front of the beeping machine that also was flashing its soothing green LED. I didn't even know what the name of the machine was, but I did know that if hp thought I was Ok, I probably was. No longer. Quality is a religion. You either believe in it or you don't. There are easy, inexpensive techniques for monitoring the level of quality in the output of a subcontractor. But if they don't comply, if they don't have a sincere belief that quality is the single most important aspect of what is being sold, they need to be brought up short and made to fix everything that went wrong. Every one of us would cheer HP to the rafters if they issued a quality recall of our -49g+s. I wish I thought we would have the chance. ==== > >No longer. Quality is a religion. You either believe in it or you don't. >There are easy, inexpensive techniques for monitoring the level of quality >in the output of a subcontractor. But if they don't comply, if they don't >have a sincere belief that quality is the single most important aspect of >what is being sold, they need to be brought up short and made to fix >everything that went wrong. > Greed is the religion now. A.L. ==== > > : > : 4. A small bit of golden paint has gone from the top. It is something > : very small but unfortunately I SEE the damn thing everytime I look at > : the screen. True, this time a new software improvement will not solve > : this strange disease (paint peeling) unless the improvement is SO > : incredibly GOOD that I forget about the rest. > > I've now had two -49g+s--first one died--and the paint is still sticking > to both. But the main reason for paint peeling, I believe, is lousy > preparation and lousy pre-cleaning of the surface before applying the > paint. It's none of my business, but if I were you I would send the > defective thing back--preferably to HP directly, although they won't take > it until it's 31 days old--so that HP can see for themselves that they've > got a major process problem. > > Subcontracted work can be very successful, provided that it is contracted > to experts who both audit their own processes and host audits by their > customers. These calculators should all be pulled from store shelves all > over the world, sent straight back to China, and there the manufacturer > should have to inspect every single one of them. If the failure rate is > over 4 defectives in 1,000,000 [yes, I meant to say one million] they > should be forced to replace the top plastic part on every single > calculator, submit them for reinspection, and then relaunch the product > just in time for Christmas. > > Will it happen? > > NO > > Would it happen if I were Quality Assurance Director for HP? > > NO > > And, I fear, the reason is that HP's QA Department has had its balls cut > off by the attitude conveyed down to the ranks by Fearless Leader Lady. > > I have loved the little blue hp logo for 33 years. Once I was in the > hospital for chest pain; the emergency room people ripped off my clothes, > shaved both hairs off my chest, hooked up countless wires in a rainbow of > colors to me, and threw me into intensive care. The only thing that looked > the least bit familiar was the tiny little blue hp logo on the front of > the beeping machine that also was flashing its soothing green LED. I > didn't > even know what the name of the machine was, but I did know that if hp > thought I was Ok, I probably was. > > No longer. Quality is a religion. You either believe in it or you don't. > There are easy, inexpensive techniques for monitoring the level of quality > in the output of a subcontractor. But if they don't comply, if they don't > have a sincere belief that quality is the single most important aspect of > what is being sold, they need to be brought up short and made to fix > everything that went wrong. > > Every one of us would cheer HP to the rafters if they issued a quality > recall of our -49g+s. I wish I thought we would have the chance. Now no one wants to admit a problem because it will generate so much bad press and since the press can't seem to tell a correct story (I bought an HP scanner long after CNN reported that HP wasn't going to make scanners for exmaple) the bad PR of recalling a product will overshadow any good PR they miht get for doing the right thing and fixing a product. Its much easier and cheaper to quietly hope the problem goes away. I still have my 48sx I bought new in 92 with my very first tax refund from working my very first part time job. I was one of the few who would pay the extra $ for a quality product and the quality of the 48sx led me to buy three HP printers, one laptop, two scanners, and a 10/100 switch since then. I hadn't been following this NG in a while and last I heard HP wasn't producing new calculators until I spotted a new model in an office supply store, I came back to see what they had. It appears they are producing them,but none worthy to replace/add alongside my 48sx. I was really hoping I wasn't going to be disapointed. ==== > > : > : 4. A small bit of golden paint has gone from the top. It is something > : very small but unfortunately I SEE the damn thing everytime I look at > : the screen. True, this time a new software improvement will not solve > : this strange disease (paint peeling) unless the improvement is SO > : incredibly GOOD that I forget about the rest. > > I've now had two -49g+s--first one died--and the paint is still sticking to > both. In that situation, I wouldn't know whether or not the paint was sticking to the dead one. It would have gone straight back to the supplier for replacement. Dave ==== Try University bookstores. Here at Utah State University the HP 49G+ is selling for about US $ 130 and the HP 48GII for about US$ 90. G. Urroz Logan, Utah ==== > The thing to check is there fully charged, leave them stand for 10 > minutes, not in anything, rest voltage. Batteries normally only need sit if they aren't near room temperature. Refrigerated batteries may store longer than room temperature batteries, but will begin operating like a dead battery and not get up to normal performance until they have warmed up. Running batteries in a heated state may make them seem to perform better for some applications, but is damaging to the batteries; a NiCD quickly goes from 500 charge cycles in a life to below 100 to provide an example. Another characteristic that effects voltage on NiCD (and probably others) is called topping off; 'rapidly' charging a battery that is already full, which adds an extra jolt in the initial use for high drain devices. Doing so results in a slightly higher voltage than a standard charged NiCD for the start of its use and reduced future charge cycles due to damage to the overcharged cells. Trickle (slow rate) charging is not as damaging to batteries, and even does not damage some batteries that are already full. Dead batteries will also appear to regain a little bit of energy if left sitting around (Try removing an unfunctional battery from a voltage sensitive device and restore it a few minutes later to see that you get, perhaose, a few seconds more use out of it). The battery will quickly drop to its previous state when used because it doesn't store much. > Different types of batteries have different voltages in view of the > different chemistry they use. For example nicad batteries when fully > charged tend to be about 0.1 v less than non rechargable batteries. If > a device needs 10 batteries, that adds up to say 14 V not 15 V. NiCD has 1.2v during normal charged operation, and that holds except at the end of the charge (where it drops lower) and the beginning of a charge (where it raises a little bit during charging). Alkaline have a normal charged voltage of 1.5v, with the voltage slowly falling down throughout its use (making battery level approximation easy). > Most devices are fairly forgiving, after all batteries loose their > voltage as they get used by about 0.1 to 0.2 V with AA batteries. The > HP calcs use only 3, so I imagine there will be no problems voltage > wise. NiCD are often considered 'drained' when they drop vrom 1.2v to 1.0v. I can't remember any standard 'drained' voltage for alkalines, but I usually just run them until they are unacceptable in performance anyways. Ed Sutton ==== >> It was a charger for AA/AAA rechargeable lithium-ion batteries. I >> wonder, has anyone tried these batteries before in the HP49/HP49+ or >> perhaps other models? >> I found these at RadioShack, link: >> http://www.radioshack.ca/estore Product.aspx?language=en-CA&product=2318298&category=Lithium-lo +Rechargeable&catalog=RadioShack > Your link was actually for rechargeable NiMH batteries which are > designed for a fast 15min charge ability. My previous experience with I was actually seeking information on Lithium-Ion batteries instead of NiMH or NiCd. I actually saw charger and batteries in the Lithium-lon Rechargeable section of RadioShack, the only item in the group. I thus assumed that these were indeed lithium batteries, but I guess not. I was specifically asking about lithium batteries because I've never had experience with them. > If you were considering rayovac, check out rayovac battery products > at http://www.rayovac.com for rechargeable alkaline batteries if you > want my suggestion of rechargeable batteries. TI used to sell calcs > with them, but I guess those days are over. I personally try to run > duracell ultra batteries in my ti86/89 because the calcs fade during > operations with most all other batteries quite noticeably since they > were overclocked. The rayovac generally worked like normal alkaline to > me as long as I would charge them 'before' they reach the point where > they are 'dead', after which a charge does not help out right; now I > find them hard to locate in stores near me though. I've used rechargeable alkaline batteries before, and they were fairly cheap and charged rather quickly. The only complaint I had with them is that you had to recharge them before their charge was depleated. The brand I used, Pure Energy claimed really long shelf-life as well, but typically half the batteries would begin to leak after a year. I generally like to use batteries until their last piece of charge, without worrying about them permanently loosing some of their capacity, as in alkaline cells. > alkalines could hold a charge. NiCD need to be charged once purchased > because they generally are discharged if they were charged prior to > packaging. I don't know how NiMH should act, but it seems like they > discharge on their own somewhere close to NiCD. Yes, NiMH batteries loose charge if not used up, but they're generally more reliable than NiCds, their memory effect is not as problematic as NiCd batteries, and the current provided is a bit higher. They can also be recharged many times, around 1000 times they claim. I generally use NiMH batteries in cases that require rechargeable batteries, but sometimes they're too expensive. Here it's around $10 CND for two AA NiMH batteries if I recall correctly. > Different batteries have their own care, life, application, etc. Did > this help, or would you like more information? It's 01:01 A.M.; time > for someone else to step in and correct my mistakes in the future... batteries in AA/AAA sizes, do they exist? RadioShack makes it seem like they exist, and it is possible to make them. Albert ==== > >> It was a charger for AA/AAA rechargeable lithium-ion batteries. I > >> wonder, has anyone tried these batteries before in the HP49/HP49+ or > >> perhaps other models? > >> I found these at RadioShack, link: > >> http://www.radioshack.ca/estore > Product.aspx?language=en-CA&product=2318298&category=Lithium-lo > +Rechargeable&catalog=RadioShack http://www.rayovac.com/15minutes/facts.html should clear up the 'IC-3 technology', which appears as a rapid-charge NiMH by those docs. In checking, my NiMH AA 2 pack was Energizer 1700mAh 1.2v. > I was actually seeking information on Lithium-Ion batteries instead of NiMH > or NiCd. I actually saw charger and batteries in the Lithium-lon > Rechargeable section of RadioShack, the only item in the group. I thus > assumed that these were indeed lithium batteries, but I guess not. I was > specifically asking about lithium batteries because I've never had > experience with them. You would probably need a battery pack. Individual cell voltages are (during most of the discharge cycle) about 3.6v, with a wider range between charged voltage and discharged voltage; 3 alkalines have a wider range than 1 when they are ran in series as the HP calcs use them. I do not know the min/max voltages that the calcs allow while still operating. Li-ion cells will also discharge somewhat on their own. http://voltaicpower.com/Secondaries/li-ion.htm may have some useful battery details, but I'm sure google would have had more to say if I looked at the results for 6 secs instead of 5. > I've used rechargeable alkaline batteries before, and they were fairly cheap > and charged rather quickly. The only complaint I had with them is that you > had to recharge them before their charge was depleated. The brand I used, > Pure Energy claimed really long shelf-life as well, but typically half > the batteries would begin to leak after a year. My rayovac rechargeable alkaline charger should charge batteries in under 4 hrs if i remember right, but the connections are badly oxidized since I never cleaned them since I got it many years ago. I still have my origional 8 AAA batteries that I bought and keep in my wireless super nintendo controllers when i got into the batteries, but I've had others leak. In my last 3 packs of 4 AA batteries I bought all at once, i later realized that 1 had a leaky battery. I should send it to rayovac if I can get a free good pack. > I generally like to use batteries until their last piece of charge, without > worrying about them permanently loosing some of their capacity, as in > alkaline cells. Charging once every 2 months when they aren't dead still by far beats charging every week and a half because they discharged too much (perhaose risking memory loss/lithium cr2032 cell drainage. > Yes, NiMH batteries loose charge if not used up, but they're generally more > reliable than NiCds, their memory effect is not as problematic as NiCd > batteries, and the current provided is a bit higher. They can also be > recharged many times, around 1000 times they claim. I generally use NiMH > batteries in cases that require rechargeable batteries, but sometimes > they're too expensive. Here it's around $10 CND for two AA NiMH batteries > if I recall correctly. My NiMH were around $6-$10 US I think, but it was far too long ago for me to remember specifically now. NiMH should match voltage, but NiMH have greater capacity. I really haven't had any memory problems, nor did I find them worth ever concerning myself about. As a result, I no longer remember what leads to memory problems. =/ I don't know how the batteries perform as the charge cycles move on in NiMH for certain, but NiCD end up with shorter runtimes as the cycles add up. > batteries in AA/AAA sizes, do they exist? At least close to AA size, but usually slightly larger. If used in the AAA calcs, and you find that you are bulding your own 'battery box', consider multiple cells paralelled for extra capacity, and perhapse a charge port that allows you to charge cells without removing them, or charge individual cells. =) > RadioShack makes it seem like they exist, and it is possible to make them. Radio Shack makes a lot of things 'seem' to be. I try to follow scientific fact over what Radio Shack retailers tell me. I need to bring my ARRL handbook with me next time I go in so that I can make it clear that their understanding of gold plating for connectors is wrong...Well, as I was saying... Ed Sutton ==== rechargeable > batteries in AA/AAA sizes, do they exist? > > RadioShack makes it seem like they exist, and it is possible to make them. > > Albert Albert, AFAIK Li-Ion batteries are not available in standard sizes. The reason is that their charging requirements are quite different from NiCd and NiMH cells. Connecting Li-Ion cells to the wrong type of charger is dangerous and potentially explosive. Because of this the manufacturers are not permitted to sell them as replacements for standard cells. David Loomes ==== > AFAIK Li-Ion batteries are not available in standard sizes. The reason is > that their charging requirements are quite different from NiCd and NiMH > cells. Connecting Li-Ion cells to the wrong type of charger is dangerous > and potentially explosive. Because of this the manufacturers are not > permitted to sell them as replacements for standard cells. Yes, I realize the danger involved with Lithium-Ion cells, that's why I was surprised to see them in normal sizes. I thought they might have inplemented an automatic checking routine of some sort. However, it was just a false alarm. The store was mistaken. Albert. ==== > > L4: 0 > > L3: +infinity symbol (left-shift 0) > > L2: 'EXP(-X)*(1-EXP(-X)' > > L1: 'X' > > > > then push right-shift TAN and 1/2 will be displayed almost > instantaneously. > > Try UNDOing the result (press right-shift HIST). The four stack > levels should come back. > > Then try integrating again (press right-shift TAN). The .5 result > appears about 30 seconds later. hmmmm. Thoughts? > > (Still better than the 49G.. consistantly takes around one minute). > > Matt Calc was in exact the first time, and approx the second time. possibly a difference in wether symbolic vs. numeric integration is performed? Ed Sutton ==== Does anyone know the bast program to use to make and view txt files on the HP480GX? I'm using MK and have a 1Mg card. It seem that I have to compile or convert the txt file into a VIT file? then load it into home or a list and execute a probram...but nothing seems to be working. Any help would be much appreciated. thanks ==== > Gosh, talk about bursting someone's balloon. Be assured that I didn't do this to show off or to put Toby down. It just looked a little like a MC ;-) No, seriosly - I have coded a lot of crappy programs when I started learning to program the HP48SX and GX (not saying that Tobys program is crappy, it's merely somewhat inefficient). There's no doubt that Toby learnt a lot when writing his program, and I hope he also learned a bit seeing my solution. I know I've learned quite a few things following the brilliant guys on this ng. It may be a silly little program, but the good part is doing the programming. The habit of writing compact code that performs very well (that was necessary on the HP48 to make anything work satisfactory) has helped me tremendously in my professinal life. I currently code for several types of embedded processor cores (as well as high level programming), and I often hear sighs from my colleagues when I provide them with a solution in 2 minutes that they have fought for days over. I just hope my little program helped shed a little more light on the RPL gem. ==== > I just hope my little program helped shed a little more light on the > RPL gem. > So you are the mysterious author of this program documented at http://www.hpcalc.org/hp48/docs/programming/1minmarv.zip originally presented at the HHUC99 Conference, HP Vancouver as One-Minute Marvels by Wlodek Mier-Jedrzejowicz and Richard Nelson. One wonders why you were not listed as the author??? ==== Marlon, I think the author is John H. Meyers: http://groups.google.com/groups?selm=4qu3qv%245u4%40news.iastate.edu Didn't you ever reinvent the wheel? It's a great feeling ... as long as one doesn't search google groups :-) ==== It did, seriously. The fact that tghe command ORDER can handle repeated entries so graciously was the oversight. Most of the job was to ensure a clean list, without repetitions. I'm allright, man... Toby > > > Gosh, talk about bursting someone's balloon. > > Be assured that I didn't do this to show off or to put Toby down. It > just looked a little like a MC ;-) No, seriosly - I have coded a lot > of crappy programs when I started learning to program the HP48SX and > GX (not saying that Tobys program is crappy, it's merely somewhat > inefficient). There's no doubt that Toby learnt a lot when writing his > program, and I hope he also learned a bit seeing my solution. I know > I've learned quite a few things following the brilliant guys on this > ng. > > It may be a silly little program, but the good part is doing the > programming. > > The habit of writing compact code that performs very well (that was > necessary on the HP48 to make anything work satisfactory) has helped > me tremendously in my professinal life. I currently code for several > types of embedded processor cores (as well as high level programming), > and I often hear sighs from my colleagues when I provide them with a > solution in 2 minutes that they have fought for days over. > > I just hope my little program helped shed a little more light on the > RPL gem. > ==== WOW ! Friend brought a 256MB SD card (used and filled in Ipaq) and I tried it in HP49G+ . Well, it kinda worked -> - I was able to browse all files in the root dir - I was _NOT_ able to enter any subdir - I was able to copy from/to root dir any file Filer[1-5] behaved the same. HP Ipaq recognized any file I copied onto SD card. -- Mario Mikocevic (Mozgy) mozgy at hinet dot hr It's never too late to have a good childhood! The older you are, the better the toys! My favourite FUBAR ... ==== > > >> Today I requested and received a RMA for the return of a hp49g+ >>calculator. >> >>I ordered the hp49g+ calculator online DIRECT from HP's SMB web site on >>10/21/03. >>I received it via UPS on 10/27/03. >>It was shipped from Indianapolis, IN. >> >>It was received with the the DEFECTIVE operating system installed. >>Upon testing its operation, I found that some keys failed to function.. > > > >>I concluded hp CHOSE-TO-DELIVER -A-KNOWN-DEFECTIVE PRODUCT to me. > > > Don't expect any coments here. Your post is politically incorrect. > Everybody knows that HP calculators are The Best Calculators In The > World. Oh... They don't work?... Really?.... So what?... > > I returned mine too. Back to TI 89. If you haven't noticed plenty of strongly negative comments about the 49G and 49g+, then I guess that you don't read many posts in this newsgroup. Some of us are willing to give HP yet another chance and hope that they get things right. Carl and you choose not to, and I don't find fault with either of you for that. What is there to comment on? -- James ==== > > > > > >> Today I requested and received a RMA for the return of a hp49g+ > >>calculator. > >> > >>I ordered the hp49g+ calculator online DIRECT from HP's SMB web site on > >>10/21/03. > >>I received it via UPS on 10/27/03. > >>It was shipped from Indianapolis, IN. > >> > >>It was received with the the DEFECTIVE operating system installed. > >>Upon testing its operation, I found that some keys failed to function.. > > > > > > > >>I concluded hp CHOSE-TO-DELIVER -A-KNOWN-DEFECTIVE PRODUCT to me. > > > > > > Don't expect any coments here. Your post is politically incorrect. > > Everybody knows that HP calculators are The Best Calculators In The > > World. Oh... They don't work?... Really?.... So what?... > > > > I returned mine too. Back to TI 89. > > If you haven't noticed plenty of strongly negative comments about the > 49G and 49g+, then I guess that you don't read many posts in this > newsgroup. > > Some of us are willing to give HP yet another chance and hope that they > get things right. Carl and you choose not to, and I don't find fault > with either of you for that. What is there to comment on? I know HP calculators have problems. I've been using them for years, and I have also been using TI calculators for years. Overall, TI has been much much more stable than HPs more recent calculators. I wasn't refering to negative comments about HP calculators. Negative feedback certainly has its merits and everyone is entitled to their own opinion. However, what I find curious is the number of posts in this group that contain nothing but yeah, I love my TI or something to that extend. ==== > > > Today I requested and received a RMA for the return of a hp49g+ > >calculator. > > > >I ordered the hp49g+ calculator online DIRECT from HP's SMB web site on > >10/21/03. > >I received it via UPS on 10/27/03. > >It was shipped from Indianapolis, IN. > > > >It was received with the the DEFECTIVE operating system installed. > >Upon testing its operation, I found that some keys failed to function.. > > > > >I concluded hp CHOSE-TO-DELIVER -A-KNOWN-DEFECTIVE PRODUCT to me. > > Don't expect any coments here. Your post is politically incorrect. > Everybody knows that HP calculators are The Best Calculators In The > World. Oh... They don't work?... Really?.... So what?... > > I returned mine too. Back to TI 89. > > A.L. I always wondered why so many TI users post here. Are you just looking for complains so you can add your amen? I don't want to start anything here, but it seems to me that half the conflicts are resolved with HP sucks yah I love my TI. I believe there is a group for TI posters as well, and if not I suggest you create one. ==== >> Don't expect any coments here. Your post is politically incorrect. >> Everybody knows that HP calculators are The Best Calculators In The >> World. Oh... They don't work?... Really?.... So what?... >> >> I returned mine too. Back to TI 89. >> >> A.L. > >I always wondered why so many TI users post here. Are you just >looking for complains so you can add your amen? I don't want to >start anything here, but it seems to me that half the conflicts are >resolved with HP sucks yah I love my TI. I believe there is a >group for TI posters as well, and if not I suggest you create one. Because I have some nice HP calculators from the time when they were manufactured by HP, and I like them (unfortunately, my HP16 was stolen last week from my office). I am using TI because the golden age of HP calculators is past, and the whole story with the newest one seems for me like an attempt to reanimate dead body. However, if they fix problems with their newest model, I will buy one. For a while I don't love them enough to pretend that there are no problems. A.L. P.S. I have also huge collection of Sharps, including early pocket computers and large collection of Casio. I simply like calculators as gadgets. But I don't LOVE them such as the majority of people that post to this group do. ==== So you are so important that if you buy one calculator for $130 that is something great. Who are you, JC? > > >> Don't expect any coments here. Your post is politically incorrect. > >> Everybody knows that HP calculators are The Best Calculators In The > >> World. Oh... They don't work?... Really?.... So what?... > >> > >> I returned mine too. Back to TI 89. > >> > >> A.L. > > > >I always wondered why so many TI users post here. Are you just > >looking for complains so you can add your amen? I don't want to > >start anything here, but it seems to me that half the conflicts are > >resolved with HP sucks yah I love my TI. I believe there is a > >group for TI posters as well, and if not I suggest you create one. > > Because I have some nice HP calculators from the time when they were > manufactured by HP, and I like them (unfortunately, my HP16 was > stolen last week from my office). I am using TI because the golden > age of HP calculators is past, and the whole story with the newest > one seems for me like an attempt to reanimate dead body. However, if > they fix problems with their newest model, I will buy one. For a > while I don't love them enough to pretend that there are no > problems. > > A.L. > > P.S. I have also huge collection of Sharps, including early pocket > computers and large collection of Casio. I simply like calculators > as gadgets. But I don't LOVE them such as the majority of people > that post to this group do. ==== oN 04-Nov-03, Ralph Hunt said: > I always wondered why so many TI users post here. Are you just > looking for complains so you can add your amen? I don't want to > start anything here, but it seems to me that half the conflicts are > resolved with HP sucks yah I love my TI. I believe there is a > group for TI posters as well, and if not I suggest you create one. Actually, as a long-time HP calculator fan, and now one who has been forced into the TI side of things, I would say that there may be many here who keep hoping for a new HP that will be the TI-killer. I certainly do. I have a 41CV, a 48SX, a 49G, and now, a 49G+. As much as Carly appears to have ruined the company, and while my recent experience with HP printers has been unsatisfactory, I cannot help but hope for more in an HP calculator. I also have a TI-86 and a TI-89. I've read online that the HP-49 graphs more rapidly than the TI-89. Not even close. The 89 will graph in a couplle of seconds a function that my HP-49 ponders over for >20 seconds. My 49G+ is closer to the speed of the 89, but I've only had it for a day, and haven't had time to throw myself into the learning of all its features. I don't *like* algebraic entry, and the HP-49 irritated me because some functionality appeared to be available in algebraic mode that was not available in RPN. So far, the 49G+ seems to put algebraic and RPN on an equal footing. I'd love to toss my TI calcs, and find happiness in an HP, as I have since the HP-21 came out (I couldn't afford the original 35!) But I'm not willing to toss a Lexus in exchange for a Geo. I love what HP used to produce, but in my view, they have to win me over again. I hope the 49G+ will do that, but I shan't hold my breath. -- Bill ==== Well, speaking as a HP style calculator fan, while I do feel uncomfortable reading the pro-TI posts, feel also that having comments like these shed more light on the entire calculator situation. IF indeed HP has fallen on their faces, and TI makes a superior product, it should be made known, especially to HP. That having been said, I think that the, well, at least my, 49G+ works well, for what it is, a very programmable graphing RPL/algebraic/with CAS calculator and since I havent' experienced any of the much discussed failures other than the occasional flicker (oh my, the machine is hereby trash :p ), I'd even say it's basically well made. As for well-designed... well, I am more at ease with a machine that is not graphing, scientific, RPN, keystroke programmable, so for what it was ostensibly intended for, I'd GUESS it's designed fairly well. But, I haven't gotten close to even basic competency in programming a 48 or 49 style calculator. I still find myself thinking and reacting in a RPN keystroke kind of a way. > >> >> >>> Today I requested and received a RMA for the return of a hp49g+ >>>calculator. >>> >>>I ordered the hp49g+ calculator online DIRECT from HP's SMB web site on >>>10/21/03. >>>I received it via UPS on 10/27/03. >>>It was shipped from Indianapolis, IN. >>> >>>It was received with the the DEFECTIVE operating system installed. >>>Upon testing its operation, I found that some keys failed to function.. >>> >> >> >>>I concluded hp CHOSE-TO-DELIVER -A-KNOWN-DEFECTIVE PRODUCT to me. >>> >>Don't expect any coments here. Your post is politically incorrect. >>Everybody knows that HP calculators are The Best Calculators In The >>World. Oh... They don't work?... Really?.... So what?... >> >>I returned mine too. Back to TI 89. >> >>A.L. >> > > I always wondered why so many TI users post here. Are you just > looking for complains so you can add your amen? I don't want to > start anything here, but it seems to me that half the conflicts are > resolved with HP sucks yah I love my TI. I believe there is a > group for TI posters as well, and if not I suggest you create one. > ==== Also seems as though you should be able to use one of the commercially avaiable PDA keyboards with the new 48 & 49s since they now support IRDA. They are relatively inexpensive and work quite well. Would need to write a small driver routine. Bob ==== please!!! can you publish some more information about this keayboard? I am really interested on it. ==== >> << -> X 'FLOOR(pi/ASIN(X))' >> >> I get 1 as the result. >> It should be 2. > When you do FLOOR(expression) the expression > is *numerically* evaluated first. Ouch, thats an onion in the ointment. How do I know which functions behave this way? -- Jostein Trondal ==== Your program on the 49 g gives 2. I do not know why put thier must be a reason. Gary > >> << -> X 'FLOOR(pi/ASIN(X))' >> > >> I get 1 as the result. > >> It should be 2. > > > When you do FLOOR(expression) the expression > > is *numerically* evaluated first. > > Ouch, thats an onion in the ointment. > How do I know which functions behave this way? > > > -- > Jostein Trondal ==== Still nice to know, that one can get calculators, that do not work out of the box. The one I got today did not work - pressing on on did not work. I had to press reset once and the system was there .... Strange, Marten Feldtmann ==== Probably with version 1.20 so your batteries are worn down before start. Get a set of new batteries and upgrade it to version 1.22 would be my advice. Torstein > Still nice to know, that one can get calculators, that do not > work out of the box. The one I got today did not work - pressing on on > did not work. > > I had to press reset once and the system was there .... > > > Strange, > > > Marten Feldtmann > ==== > Probably with version 1.20 so your batteries are worn down before start. Get > a set of new batteries and upgrade it to version 1.22 would be my advice. Were the batteries installed in yours when you received it? They weren't in mine, they were next to the calc on the blister pack -- Tom Lake There are three kinds of people in the world - Those who can count and those who can't. ==== Yes, the batteries were installed when delivered - but the batteries were ok. I did not need to use new ones. Today I tried out the USB interface under W2000 and this was also a pain. I reinstalled the software and the driver from the disc several times without success in connectiong to the HP. Actually after doing the installation with the newest software versions from the net I finally was able to upgrade the ROM (but a simple connect was still not possible). After upgrading to 1.22 I was able to connect to the HP from my laptop. I noticed some flickering of the LCD screen mostly on the lowest rows of pixels - which is not a very good sign. I like this machine, but I get the following feeling: * the product is not ready and the technology is getting much more complicated (USB) and this takes even more time to make it stable. * I was expecting much about the new IrDA, but no documentation, no documentation about it ... * I really would like to use the HP to collect measure results from external systems and I hope, that IrDA would be the best way, but after doing some more research this area (IrDA) is very, very unfinished. We will need many more updates to the software to get more out of this machine. Marten Tom Lake schrieb: > >>Probably with version 1.20 so your batteries are worn down before start. > > Get > >>a set of new batteries and upgrade it to version 1.22 would be my advice. > > > Were the batteries installed in yours when you received it? They weren't in > mine, they were next to the calc on the blister pack > > > ==== For a bunch of calculator nerds, you all sure do gripe a lot! > Yes, the batteries were installed when delivered - but the batteries > were ok. I did not need to use new ones. > > Today I tried out the USB interface under W2000 and this was also > a pain. > > I reinstalled the software and the driver from the disc several times > without success in connectiong to the HP. > > Actually after doing the installation with the newest software versions > from the net I finally was able to upgrade the ROM (but a simple connect > was still not possible). > > After upgrading to 1.22 I was able to connect to the HP from my laptop. > > I noticed some flickering of the LCD screen mostly on the lowest rows > of pixels - which is not a very good sign. > > I like this machine, but I get the following feeling: > > * the product is not ready and the technology is getting much more > complicated (USB) and this takes even more time to make it stable. > > * I was expecting much about the new IrDA, but no documentation, no > documentation about it ... > > * I really would like to use the HP to collect measure results from > external systems and I hope, that IrDA would be the best way, but > after doing some more research this area (IrDA) is very, very > unfinished. > > We will need many more updates to the software to get more out of this > machine. > > > Marten > > > > Tom Lake schrieb: > > > >>Probably with version 1.20 so your batteries are worn down before start. > > > > Get > > > >>a set of new batteries and upgrade it to version 1.22 would be my advice. > > > > > > Were the batteries installed in yours when you received it? They weren't in > > mine, they were next to the calc on the blister pack > > > > > > > ==== What's the NG for? > For a bunch of calculator nerds, you all sure do gripe a lot! > > > > > > > >>Yes, the batteries were installed when delivered - but the batteries >>were ok. I did not need to use new ones. >> >>Today I tried out the USB interface under W2000 and this was also >>a pain. >> >>I reinstalled the software and the driver from the disc several times >>without success in connectiong to the HP. >> >>Actually after doing the installation with the newest software versions >>from the net I finally was able to upgrade the ROM (but a simple connect >>was still not possible). >> >>After upgrading to 1.22 I was able to connect to the HP from my laptop. >> >>I noticed some flickering of the LCD screen mostly on the lowest rows >>of pixels - which is not a very good sign. >> >>I like this machine, but I get the following feeling: >> >>* the product is not ready and the technology is getting much more >> complicated (USB) and this takes even more time to make it stable. >> >>* I was expecting much about the new IrDA, but no documentation, no >> documentation about it ... >> >>* I really would like to use the HP to collect measure results from >> external systems and I hope, that IrDA would be the best way, but >> after doing some more research this area (IrDA) is very, very >> unfinished. >> >>We will need many more updates to the software to get more out of this >>machine. >> >> >>Marten >> >> >> >>Tom Lake schrieb: >> >>> >>> >>>>Probably with version 1.20 so your batteries are worn down before start. >>>> >>>Get >>> >>> >>>>a set of new batteries and upgrade it to version 1.22 would be my >>>> > advice. > >>> >>>Were the batteries installed in yours when you received it? They >>> > weren't in > >>>mine, they were next to the calc on the blister pack >>> >>> >>> >>> > > ==== Point taken!!! > What's the NG for? > > > > For a bunch of calculator nerds, you all sure do gripe a lot! > > > > > > > > > > > > > > > >>Yes, the batteries were installed when delivered - but the batteries > >>were ok. I did not need to use new ones. > >> > >>Today I tried out the USB interface under W2000 and this was also > >>a pain. > >> > >>I reinstalled the software and the driver from the disc several times > >>without success in connectiong to the HP. > >> > >>Actually after doing the installation with the newest software versions > >>from the net I finally was able to upgrade the ROM (but a simple connect > >>was still not possible). > >> > >>After upgrading to 1.22 I was able to connect to the HP from my laptop. > >> > >>I noticed some flickering of the LCD screen mostly on the lowest rows > >>of pixels - which is not a very good sign. > >> > >>I like this machine, but I get the following feeling: > >> > >>* the product is not ready and the technology is getting much more > >> complicated (USB) and this takes even more time to make it stable. > >> > >>* I was expecting much about the new IrDA, but no documentation, no > >> documentation about it ... > >> > >>* I really would like to use the HP to collect measure results from > >> external systems and I hope, that IrDA would be the best way, but > >> after doing some more research this area (IrDA) is very, very > >> unfinished. > >> > >>We will need many more updates to the software to get more out of this > >>machine. > >> > >> > >>Marten > >> > >> > >> > >>Tom Lake schrieb: > >> > >>> > >>> > >>>>Probably with version 1.20 so your batteries are worn down before start. > >>>> > >>>Get > >>> > >>> > >>>>a set of new batteries and upgrade it to version 1.22 would be my > >>>> > > advice. > > > >>> > >>>Were the batteries installed in yours when you received it? They > >>> > > weren't in > > > >>>mine, they were next to the calc on the blister pack > >>> > >>> > >>> > >>> > > > > > ==== > Probably with version 1.20 so your batteries are worn down before start. Get > a set of new batteries and upgrade it to version 1.22 would be my advice. > Torstein Shouldn't HP provide these new batteries? They are selling the calculator with batteries, and therefore the batteries should work! -- -Joshua Belsky jjbelsky@yahoo.com http://belsky.net ==== >> Probably with version 1.20 so your batteries are worn down before start. Get >> a set of new batteries and upgrade it to version 1.22 would be my advice. > >> Torstein > >Shouldn't HP provide these new batteries? They are selling the calculator >with batteries, and therefore the batteries should work! How was you calculator packaged? Blister pack or box. Mine came in a blister pack and the batteries were not installed in the calculator. Harold A. Climer Dept.Of Physics,Geology,and Astronomy University of Tennessee at Chattanooga Chattanooga TN USA 37403 ==== Excellent little game. Hp needs to refuse to replace the up arrow button if this game has been installed. I gave mine a good workout. My top score after 10 minutes was only 105. John ==== That was my first thought as well...: how long will the up-arrow-button keep working after I installed this game... Martin > Excellent little game. Hp needs to refuse to replace the up arrow > button if this game has been installed. I gave mine a good workout. My > top score after 10 minutes was only 105. > > John ==== > Anyway I'm afraid we will never see this changes made to the 49g+. Yes, it's quite unlikely, unless they hire a CAS developer. -- Bhuvanesh ==== >> Anyway I'm afraid we will never see this changes made to the 49g+. >Yes, it's quite unlikely, unless they hire a CAS developer. You seem to implicate, that Mr Parrise and the rest of the team, which developed the CAS of the HP49G(+) could not be called CAS developers? Mathias -- Mathias Habel mathias.habel_no-spam_@t-online.de Remove _no-spam_ before replying ==== > > >> Anyway I'm afraid we will never see this changes made to the 49g+. > > >Yes, it's quite unlikely, unless they hire a CAS developer. > > You seem to implicate, that Mr Parrise and the rest of the team, which > developed the CAS of the HP49G(+) could not be called CAS > developers? > > Mathias Is the CAS ever currently further developed? I haven't known of much for updates besides what changes in hp49g* rom versions. Ed Sutton ==== > > Anyway I'm afraid we will never see this changes made to the 49g+. It > would demand some serious changes in how the calc works or.... > > Lets hope I'm wrong! Actually, someone has addressed this with http://www.hpcalc.org/details.php?id=5493. It's not completely transparent as it requires some setup, but once setup it does appear to be transparent. BTW, I've not tried it as I don't care about the flag changes, though the variable twiddling might be helpful. - Paul ==== I have my hp49g for about 4 years and i am quite pleased with it. But I really hate the keyboard and the display. and a faster calc will always be great. What do you say - those of you who own the new model - sholud I buy it or not ? Will I be pleased with the new keyboard ? Or should I wait a while - But I don't think HP will come out with a new model than the hp49g+ in the 4 next years. So - BUY IT OR NOT ? That's the question. Idan ==== Wait till hp updates the 49g software. -Samuel http://www.calvin.edu/~sstear70/ > > I have my hp49g for about 4 years and i am quite pleased with it. > But I really hate the keyboard and the display. and a faster calc will > always be great. > > What do you say - those of you who own the new model - sholud I buy it > or not ? > Will I be pleased with the new keyboard ? > Or should I wait a while - But I don't think HP will come out with a > new model than the hp49g+ in the 4 next years. > > So - BUY IT OR NOT ? That's the question. > > > Idan ==== I can't exactly say whether you should buy it or not. I sit next to a guy in vector calc who has a 49g and I have a 49g+. We tried out each others' keyboards and definitely agree that the 49g+ keyboard is way better. I'm not sure about the display though. It is definitely faster. Matthew F. G. > > I have my hp49g for about 4 years and i am quite pleased with it. > But I really hate the keyboard and the display. and a faster calc will > always be great. > > What do you say - those of you who own the new model - sholud I buy it > or not ? > Will I be pleased with the new keyboard ? > Or should I wait a while - But I don't think HP will come out with a > new model than the hp49g+ in the 4 next years. > > So - BUY IT OR NOT ? That's the question. > > > Idan ==== At least wait until they get some of the bugs of initial production out... > > I have my hp49g for about 4 years and i am quite pleased with it. > But I really hate the keyboard and the display. and a faster calc will > always be great. > > What do you say - those of you who own the new model - sholud I buy it > or not ? > Will I be pleased with the new keyboard ? > Or should I wait a while - But I don't think HP will come out with a > new model than the hp49g+ in the 4 next years. > > So - BUY IT OR NOT ? That's the question. > > > Idan ==== I tried to update to 1.22 on my new 49G+, but no luck. The instructions in the dialog box do not appear to work, and neither do those in the read me file that came with the ROM update from the HP site (though they are different in sequence.) If anyone here can tell me how they did it, I'll be much happier than now. BTW, the USB connection to the connectivity kit, while attempting to follow the ROM update instructions, has several times sucked up all of my P4 under Win2K :( Oh, and the example of using DIV2 on page 5-12 doesn't work. I was hoping to see much improvement compared to the old HP49, but so far, am disappointed. -- Bill ==== On my hp49g+ I have rom v1.22 uploaded via conn4X under WinXP Pro. I did try the example on page 5-12 of the User's Manual. In RPN mode, entering each tick enclosed expression followed by DIV2 produced a result of X^7 + X^5 + X^3 +X X - 1 There were no labels, per se; but it seems reasonable that the stack level 2 contained the quotient, and stack level 1 contained the remainder. Don't give up on your calc ...(yet :^). I think experience and patience will reveal it to be a pretty marvelous tool. Sure beats the hell out of an abacus ... at least for me. Keep trying various things with your conn4X, also. I had trouble at first, but if you see your hp49g+ driver show up under device manager with the calc plugged IN and ON; then make sure you're using the RED right-shift key and the CHROME right-arrow to invoke the XMODEM SERVER it might just begin to make sense. The directions are a little intimidating; but they did work for me. Especially the calculator reset manuever afterwards. They say to hold the (+) and (-) keys down together and after you use the paper clip gadget trick , wait a little bit before releasing those keys. (I didn't do the WAIT thing, but it still worked, anyway!) Some win98SE user's haven't had any luck with conn4X and went the SD route, instead. I was ready to do that, too; until I discovered that I was using the wrong key for my right arrow. I used the little red right arrow above the 0 key ... WRONGO! heh heh! Pretty stupid on my part, but funny it is ... looking back on it! I bought a 256MB SD module from Costco, along with the SD Imagemate 8 in 1 interface adapter. It all works per the manuals (both SD and HP). Some people have had problems with that, too, but it seems to do all that HP claimed it would do. Good luck. -Dale- >Oh, and the example of using DIV2 on page 5-12 doesn't work. > >I was hoping to see much improvement compared to the old HP49, but so >far, am disappointed. ==== oN 05-Nov-03, motz said: > On my hp49g+ I have rom v1.22 uploaded via conn4X under WinXP Pro. I > did try the example on page 5-12 of the User's Manual. In RPN mode, > entering each tick enclosed expression followed by DIV2 produced a > result of > > X^7 + X^5 + X^3 +X > X - 1 > > There were no labels, per se; but it seems reasonable that the stack > level 2 contained the quotient, and stack level 1 contained the > remainder. I tried it in algebraic mode, and got only error messages. > Don't give up on your calc ...(yet :^). I think experience and > patience will reveal it to be a pretty marvelous tool. Sure beats the > hell out of an abacus ... at least for me. I haven't and won't. But so far, I am more than a little disappointed. In the old days, an HP calculator manual was practically a math class, but now, it's barely an intro. > Keep trying various things with your conn4X, also. I had trouble at > first, but if you see your hp49g+ driver show up under device manager > with the calc plugged IN and ON; then make sure you're using the RED > right-shift key and the CHROME right-arrow to invoke the XMODEM SERVER > it might just begin to make sense. The directions are a little > intimidating; but they did work for me. Especially the calculator > reset manuever afterwards. They say to hold the (+) and (-) keys down > together and after you use the paper clip gadget trick , wait a little > bit before releasing those keys. (I didn't do the WAIT thing, but it > still worked, anyway!) I got it done. I had some keyboard issues of my own , and once I got that right, *and* did all the sequence things as given in the dialog (clicking my heels together three times, too, for luck), it did work. > Some win98SE user's haven't had any luck with conn4X and went the SD > route, instead. I was ready to do that, too; until I discovered that > I was using the wrong key for my right arrow. I used the little red > right arrow above the 0 key ... WRONGO! heh heh! Pretty stupid on > my part, but funny it is ... looking back on it! > > I bought a 256MB SD module from Costco, along with the SD Imagemate 8 > in 1 interface adapter. It all works per the manuals (both SD and > HP). Some people have had problems with that, too, but it seems to > do all that HP claimed it would do. Good luck. About SD. I just picked one up at Costco, and when I plug it in, there's no indication that it is found. Following the sad little instruction in the User's Manual shows no port 3. Is there some decoder ring trick for that, too? -- Bill ==== You refer to the good old days of HP calculator. I call that the golden era of HP calculators. For those who missed that era here are the prices we had to pay for HP calculators in 1975 in Montreal. This was in the bookstore of the Polytechnic School of Montreal University. HP 35 : 350 $ Can HP 45 : 450 $ Can HP 65 : 1 000 $ Can (yes one thousand). And at this time the canadian $ was about on par with the american $. The fun part was that we agreed to buy these machines because we know we were buying top quality. This quality was showing in every aspect of the package, including the documentation which was also top notch. Just some ideas of what we got in these years. - Demo machines in the store for us to try as long as we whished. - Demonstrations by HP performed in the school auditorium to show the solidity of these machines. The guy trew an HP 45 on the terrazzo floor from a heigth of four feet. The machine ran perfectly. He did the same with an HP 35. Same result. He trew the 35 against the back wall of the auditorium. Aside from a cracked corner, the machine still functionned. - Support by HP that I would like to get today. A friend brough his defective 35 (yes, there were problems even at that time, nothing's perferct)in HP's offices, near Montreal. The clerck had him wait about 30 minutes while they actually fixed its machine. He walked out with a working 35. Another had a small problem with its 25. Since the machine could not be repaired in a short time, they lended him a 25C while his machine was on repair. In 1979, I was on the verge of buying a 67 after the price dropped to about 500 $ Can from the 800 $ can that was asked for in 1977. I am lucky to have waited long enough because I got a 41C instead, for 400 $. The common factor for all these machines up to the 48SX that I bough in 1989 was a continuous increase in power while maintaining an overall superior quality that showed even in documentation. Although the Hard plastic casing and the leather carrying pouch of the 45 had long been replaced by cardboard boxes and more vinyl like carrying pouches, the manuals were still very nicely done. I can comprehend that when there is so much stuff packed in a 49G or G+ machine that the required documentation would be as thick as a huge telephone book. But at least they could do what they did for the 48SX. Provide the basic manual and the programming manual and offer the advanced manual as option. I downloaded the advanced user guide for the 49G from the Web and printed it. No small task and I spent a lot of time, paper and printer ink. HP save big money by not including that with the machine. I understand where they cut prices to be able to offer such powerfull calculators for about 300 $ Can. They could at least pack a CD ROM containing the PDF files with the calculator. That way we would at least save the serch and dowload time on the net. I think that they should have enough time, since the introduction of the 49G, to assemble some complete documentation. At least we have now good Web sites and this newsgroup to get some help. But I cannot consider the actual era any more as a golden one for HP. They are only doing what every other company is doing, making the largest net income. I am sorry for all this complaining but, if, in the 70s and 80s I was a maniac in developping software for my HP calculators, today I consider these as a complement to my computer and use them only for pure number crunching. And for that function, the 49G keyboard is not efficient as per my standards. Too bad. I only play occasionnaly with it to check a few things but I do not use it for extensive number crunching. My 41CX is still my prefered one for that purpose. Some will ask why I did not bough a cheaper and simpler machine. The answer is that I bough a 48SX out of curiosity since my 41CX was still working well. This machine became my workhorse in the 90s. After it was stolen in 2001, the only logical choice was ieyher a 48GX or a 49G. I should have gone for a 48GX but the larger memory and power of the 49G was too tempting. With a good keyboard the 49G would be my workhorse but it is not. Jean (Johnny) Lemire from Montreal, Quebec, Canada ==== There might be: You might want to try ON-D where you be presented with a list of 10 options, number 9 of which is format. If you format your SD, it should be visible in Left-Shift Files the file manager, as port 3:SD . -Dale- >About SD. I just picked one up at Costco, and when I plug it in, >there's no indication that it is found. Following the sad little >instruction in the User's Manual shows no port 3. Is there some decoder >ring trick for that, too? > ==== oN 06-Nov-03, motz said: > There might be: You might want to try ON-D where you be > presented with a list of 10 options, number 9 of which is format. > If you format your SD, it should be visible in Left-Shift Files the > file manager, as port 3:SD . the inaquacy of both the User's Manual and the User's Guide, however. -- Bill ==== from the old 49G, adding several functions to it. The problem is, it is now 113 functions, and that is really way to much for just one long soft menu (19 pages). Is there a way to have a nested $VISIBLE menu for a library, like how many of the built-in menus have? For example, if you press the [SYMB] button, then there are ALG, ARITH, CALC, etc. sub-menus shown, instead of all of the functions. This is basically what I would like to do with the menu for my library of functions. I am using the CRLIB from 256 MENU to create the library. ==== > from the old 49G, adding several functions to it. The problem is, it is > now 113 functions, and that is really way to much for just one long soft > menu (19 pages). Is there a way to have a nested $VISIBLE menu for a > library, like how many of the built-in menus have? For example, if you > press the [SYMB] button, then there are ALG, ARITH, CALC, etc. sub-menus > shown, instead of all of the functions. This is basically what I would > like to do with the menu for my library of functions. I am using the > CRLIB from 256 MENU to create the library. Well, the system is most definitly not designed to do that.... however, that does not mean that it can not be done :-) you might be able to do it using the extention program (there is a message sent to the program when the users presses on the library button, so you could rewrite your own menu at this point and create sub-directory)... ==== > > > from the old 49G, adding several functions to it. The problem is, it is > > now 113 functions, and that is really way to much for just one long soft > > menu (19 pages). Is there a way to have a nested $VISIBLE menu for a > > library, like how many of the built-in menus have? For example, if you > > press the [SYMB] button, then there are ALG, ARITH, CALC, etc. sub-menus > > shown, instead of all of the functions. This is basically what I would > > like to do with the menu for my library of functions. I am using the > > CRLIB from 256 MENU to create the library. > > Well, the system is most definitly not designed to do that.... > however, that does not mean that it can not be done :-) > > you might be able to do it using the extention program (there is a message > sent to the program when the users presses on the library button, so you > could rewrite your own menu at this point and create sub-directory)... > What Cyrille hints at is using the library message handler for this, as described in Appendix B.2.3 of Programming in SystemRPL 2nd Edition. I have used this in the constant Tools Library (http://www.hpcalc.org/details.php?id=3179) to implemented left and right shift functionality for keys in the $VISIBLE menu. You can even completely ignore the $VISIBLE rompointers and install any menu you like through the message handler The only disadvantage is that this only work if you access the library menu through the LIBS key/menu. If you do 1234 MENU, the message handler is (unfortunately) not called. Cyrille, could this be called a bug? If yes, Jean Yves please consider this message as a bug report. - Carsten ==== > What Cyrille hints at is using the library message handler for this, > as described in Appendix B.2.3 of Programming in SystemRPL 2nd Edition. > I have used this in the constant Tools Library > (http://www.hpcalc.org/details.php?id=3179) to implemented left and > right shift functionality for keys in the $VISIBLE menu. > You can even completely ignore the $VISIBLE rompointers and > install any menu you like through the message handler > The only disadvantage is that this only work if you access the > library menu through the LIBS key/menu. If you do 1234 MENU, the > message handler is (unfortunately) not called. Theoretically, the MENU (and TMENU) command could easily be expanded to do the same as if pressing the corresponding LIB menu key which calls the library number as a message handler my means of which one can create the most complex menus programmed by $EXTPRG. But only very few people use $EXTPRG because it assumes familiarity with SysRPL. Thus, reprogramming probably doesn't pay for the developers. First of all, Christopher has to know whether all his 118 visibles are needed as visible rompointers. This is the case only if others should use them in their programs or key assignments. The ones executable only by key need not necessarily be rompointers but just menu names. Secondly, he has to know how the built-in menu system is organized - very similar to that of a complex CST menu with subdirecties. Knowing the latter would even suffice though some details may not be documented. There is still the possibility of destinating a special rompointer, call it MkMenu, which sets the desired menu with all its subdirectories. This is done in Timeman, for instance. The command Aset sets here a particular menu related to alarms whose options need not be programmable. This keeps the number of visible rompointers in a library small. At any rate, the possibility of creating HELP options in CAT for complex but important lib commands should be used as much as possible as soon as somebody offers his library to the public. The more that memory space isn't anymore a problem on the 49+. This is supported by the library manager D<->L from OT49(+) for users not familiar with SysRPL. - Wolfgang http://page.mi.fu-berlin.de/~raut/WR49/OT49.htm ==== All 113 programs do need to be visible to normal users, since they are all intended to be user-level functions. Is there at least an easy way to make a soft menu item have the little manila-folder-like tab that they use for directories and sub-menus? Other than that, writing a nesting menu program would be trivial. > >>What Cyrille hints at is using the library message handler for this, >>as described in Appendix B.2.3 of Programming in SystemRPL 2nd Edition. >>I have used this in the constant Tools Library >>(http://www.hpcalc.org/details.php?id=3179) to implemented left and >>right shift functionality for keys in the $VISIBLE menu. >>You can even completely ignore the $VISIBLE rompointers and >>install any menu you like through the message handler >>The only disadvantage is that this only work if you access the >>library menu through the LIBS key/menu. If you do 1234 MENU, the >>message handler is (unfortunately) not called. > > > Theoretically, the MENU (and TMENU) command could easily be expanded to > do the same as if pressing the corresponding LIB menu key which calls > the library number as a message handler my means of which one can create > the most complex menus programmed by $EXTPRG. But only very few people > use $EXTPRG because it assumes familiarity with SysRPL. Thus, > reprogramming probably doesn't pay for the developers. > > First of all, Christopher has to know whether all his 118 visibles are > needed as visible rompointers. This is the case only if others should > use them in their programs or key assignments. The ones executable only > by key need not necessarily be rompointers but just menu names. > > Secondly, he has to know how the built-in menu system is organized - > very similar to that of a complex CST menu with subdirecties. Knowing > the latter would even suffice though some details may not be documented. > > There is still the possibility of destinating a special rompointer, call > it MkMenu, which sets the desired menu with all its subdirectories. This > is done in Timeman, for instance. The command Aset sets here a > particular menu related to alarms whose options need not be > programmable. This keeps the number of visible rompointers in a library > small. > > At any rate, the possibility of creating HELP options in CAT for complex > but important lib commands should be used as much as possible as soon as > somebody offers his library to the public. The more that memory space > isn't anymore a problem on the 49+. This is supported by the library > manager D<->L from OT49(+) for users not familiar with SysRPL. > > - Wolfgang > http://page.mi.fu-berlin.de/~raut/WR49/OT49.htm <1a8f5fe5.0311031523.1ffc80b4@posting.google.com> <1gIpb.14$gf1.58624@newsfep1-win.server.ntli.net> <1a8f5fe5.0311041012.52970cbc@posting.google.com> ==== In message , >> >>>I don't agree, because if the calc would switch silently >>>in rad mode to make the integral and then back to previous angle >>>mode, you could get what appears to be a wrong answer >> Not if the switch is done correctly. >> > >Then please explain how the mode switch should be done. -- Bruce Horrocks Surrey England ==== > Or, take a poll and ask people what they think on the subject. See if > you can find anyone, anyone at all, who agrees with you that the way > these mode switches are handled makes any sense whatsoever. > I agree. Im sure theres many more. Of course, the poll should ake into consideration how many people are correctly informed about why it is that way. > -- Helen. -- Eddy. ==== > Maybe it will convince HP users > that radian is the *intrinsic* angle unit:-) > Not engineers, but then they don't really need the CAS... Arnaud ==== >>Maybe it will convince HP users >>that radian is the *intrinsic* angle unit:-) >> > > > Not engineers, but then they don't really need the CAS... > You are right, I should have written CAS user not HP users. Well, maybe some time in the future, even engineers will use radian as angle unit, I don't see any intrinsic reason to keep using degree except it's the common usage. ==== > >>> Maybe it will convince HP users >>> that radian is the *intrinsic* angle unit:-) >>> >> >> >> Not engineers, but then they don't really need the CAS... >> > > You are right, I should have written CAS user not HP users. > Well, maybe some time in the future, even engineers will use > radian as angle unit, I don't see any intrinsic reason to keep using > degree except it's the common usage. angle? -- James ==== > angle? > Why should I do it with a rational numbers? Why not as pi * a rational number? This is the same kind of question as if I ask you for the length of an arc of a circle of radius 1 given its measure in degree or radians. ==== >> angle? >> > Why should I do it with a rational numbers? Why not as > pi * a rational number? > This is the same kind of question as if I ask you for the length of > an arc of a circle of radius 1 given its measure in degree or radians. When an angle is specified, how often is the reason so that someone can determine the length of the arc of a circle given the angle and the circle's radius, or the radius of a circle given the angle and length of an arc? I expect that more commonly, the interest is in the sides or other angles of a triangle. After all, doesn't the word trigonometry come from the Greek for triangle measuring? I expect that, at least initially, the ancients became interested in discovering and exploring the subject due to practical interests in the properties of triangles. Some angles of particular interest, although expressible as pi times a rational number of radians, can't be expressed as a pi times a non-repeating decimal number of radians. This one's weak, but just tradition and common usage. *We* would know that, for example, an angle specified as pi * 1/2 radian is a right angle, but I'd bet that a lot of people who need to use angular measures don't know what a radian is. Can you imagine a draftsman ever specifying an angle in radians? Even as pi times a rational number of radians? Or someone looking at the print understanding what it means? I doubt that radian measure is even mentioned in any of the relevant standards. If I have to calculate an angle and compare it to the specification, I need it in usually in decimal degrees, or just possibly degrees, minutes, and seconds, but never in radians. Radian measure does seem natural for mathematics, especially for mathematics beyond basic trigonometry, and even for that I'd think that understanding radian measure is essential to any real understanding beyond using cookbook formulas. But for non-mathematicians, I expect the familiar degrees for angular measure to be used a long time into the future, although with the use of calculators and computers, degrees, minutes and seconds are giving way to decimal degrees. And certainly mathematicians should be able to convert these to radian measure, but many non-mathematicians would have problems converting radian measure to degrees. -- James ==== Let's get even more fundamental- the nontechnical coworkers of the engineers and draftsmen all understand what a 180 degree turnabout is; they know 90 degrees (I'm not sure about 0 degrees, however), but they all think pi is something their auntie makes for them on a holiday. And then there are kids- students, pre-teenagers really, beginning to receive instruction on angles and circles. I think radians, polar coordinates, etc., are kind of beyond the complete grasp of most kids that age, no matter how bright, except for the gifted few. > right > >> angle? > >> > > Why should I do it with a rational numbers? Why not as > > pi * a rational number? > > This is the same kind of question as if I ask you for the length of > > an arc of a circle of radius 1 given its measure in degree or radians. > > When an angle is specified, how often is the reason so that someone can > determine the length of the arc of a circle given the angle and the > circle's radius, or the radius of a circle given the angle and length of > an arc? > > I expect that more commonly, the interest is in the sides or other > angles of a triangle. After all, doesn't the word trigonometry come > from the Greek for triangle measuring? I expect that, at least > initially, the ancients became interested in discovering and exploring > the subject due to practical interests in the properties of triangles. > > Some angles of particular interest, although expressible as pi times a > rational number of radians, can't be expressed as a pi times a > non-repeating decimal number of radians. > > This one's weak, but just tradition and common usage. *We* would know > that, for example, an angle specified as pi * 1/2 radian is a right > angle, but I'd bet that a lot of people who need to use angular measures > don't know what a radian is. > > Can you imagine a draftsman ever specifying an angle in radians? Even as > pi times a rational number of radians? Or someone looking at the print > understanding what it means? I doubt that radian measure is even > mentioned in any of the relevant standards. If I have to calculate an > angle and compare it to the specification, I need it in usually in > decimal degrees, or just possibly degrees, minutes, and seconds, but > never in radians. > > Radian measure does seem natural for mathematics, especially for > mathematics beyond basic trigonometry, and even for that I'd think that > understanding radian measure is essential to any real understanding > beyond using cookbook formulas. > > But for non-mathematicians, I expect the familiar degrees for angular > measure to be used a long time into the future, although with the use of > calculators and computers, degrees, minutes and seconds are giving way > to decimal degrees. And certainly mathematicians should be able to > convert these to radian measure, but many non-mathematicians would have > problems converting radian measure to degrees. > ==== > Let's get even more fundamental- the nontechnical coworkers of the > engineers and draftsmen all understand what a 180 degree turnabout is; > they know 90 degrees (I'm not sure about 0 degrees, however), but they > all think pi is something their auntie makes for them on a holiday. > > And then there are kids- students, pre-teenagers really, beginning to > receive instruction on angles and circles. I think radians, polar > coordinates, etc., are kind of beyond the complete grasp of most kids > that age, no matter how bright, except for the gifted few. You are mixing two different notions, radians and polar coordinates. I believe that the perimeter of a circle expressed as pi*diameter is teached in primary school. Therefore I don't see any reason why a child who understands the perimeter of a circle would not understand the measure of an arc of circle, and therefore the measure of the corresponding angle in radians. It's just because teachers are so used to degrees that they teach degrees before radians. Polar coordinates is much more complex, and should not be taught before say 15 years when people understand what coordinates are. ==== You're right, I was throwing in too many ideas here. I am too opinionated especially when it comes to what areas of math should be taught when to whom. I do not know about Europe or Asia, really, but here in the US, the teaching of math to younger students is no longer coherent and focused in my opinion. I may be also a victim! This may be why I relate separate issues! Also, as in science, current understanding of people in industry or research of the importance of certain issues in math don't seem, at least here in the US, to filter down to the lower educational levels. This is probably one reason why HP has a harder time selling their version of calculators to most students. (If I offend anyone, I apologize in advance!) Still, I see your point. > >> Let's get even more fundamental- the nontechnical coworkers of the >> engineers and draftsmen all understand what a 180 degree turnabout is; >> they know 90 degrees (I'm not sure about 0 degrees, however), but they >> all think pi is something their auntie makes for them on a holiday. >> >> And then there are kids- students, pre-teenagers really, beginning to >> receive instruction on angles and circles. I think radians, polar >> coordinates, etc., are kind of beyond the complete grasp of most kids >> that age, no matter how bright, except for the gifted few. > > > You are mixing two different notions, radians and polar coordinates. > I believe that the perimeter of a circle expressed as pi*diameter > is teached in primary school. Therefore I don't see any reason > why a child who understands the perimeter of a circle would not > understand the measure of an arc of circle, and therefore the > measure of the corresponding angle in radians. It's just because > teachers are so used to degrees that they teach degrees before > radians. Polar coordinates is much more complex, and should > not be taught before say 15 years when people understand what > coordinates are. > ==== > > Could you not have some kind of indicator in the display if the calc has > changed mode during an operation? > By default they are, approx/complex/angle mode are displayed in the status area. ==== > > The rpn program has menus that let you pick if the command and the > > version of it. You can pick the 2 arg version, the 3 arg version, > > the 4 arg, etc. > > > > that's ok for interactive input, but you can not write > a program that way. Is the ti programmable in rpn with > the rpn program? The rpn program is just an interface. -Samuel http://www.calvin.edu/~sstear70/ ==== > Going in deeper at the hardware > -Flash ROM. Just Rocks. 1 MB user memory, practically uncorruptable, > another .5-1MB for the OS making it upgradeable, just awesome, allows > for easy bug correction and getting more add ons. WOW, i love this > feature. > I must add that ive never seen flash corrupting in any 49g. In fact > ive tried to purpously do it and wasnt able to. Ti also has this. You have more faith in HP than I do. I've considered buying a 49g+, but I ain't going to do that until hp updates the 49g. (Even then I doubt I'll buy one anyway.) They can fix a bug like battery drainage and they'll do it fast, but can they fix a bug in the CAS? I want to see ->v3 work correctly with symbolic inputs. I'll send see if the next 49g+ has it fixed. This should be really easy. -Samuel ==== > It should be relatively simple to port some subset of BLAS and > possibly LAPACK. I just haven't had time to do it. I'm not > particularly good at porting, but no one else seems to want to do it. Ah, too bad, I thought you were hinting at a nice new revision of TIs AMS... I really don't understand why linear algebra is so exceedingly slow, given the speed of other operations. If they fix that, I may in fact consider switching to TI at some point. -- Helen. ==== > I don't think it is the case anymore if you compare with the 49+. It is. Someone posted an example of some integral, which takes something like 4.x seconds on a 49G+, and about 0.6 seconds on a TI89. I also mentioned the example of numerical integration, which is roughly a factor of 3 faster on the TI89 compared to the 49G+. > My own tests show that the 49+ is around 3 to 4* faster when > doing CAS operations than the 49. Sure, but the 49G is slow as molasses... > Numeric mode has been kept for 48 compatibility. I have never > understood what it was designed for. Yup, that is a complete mystery to me, too. It makes no sense at all. > You will get the same kind of error on the 48 -> you should redirect > your critic to the 48 designers. Sigh... Why do you have to take everything personally? > I just can't understand people who would accept a silent > mode switch degree to radian, integrate, and then back > radian to degrees which would lead to the false conclusion > that integrating cos(x) in degrees gives sin(x). Then why not give the correct result? > The only viable alternative to the current situation would > be to check every CAS function and make changes so that > degrees mode is handled. But I don't have time to do that, > I have another CAS to develop. Frankly, the radians switch is a red herring, I think. The switches to complex mode, or approximate mode, or symbolic constants, etc. are much more annoying. There is no reason at all not to save and restore these flags, silently, without any fussing. > And the annoyance of mode switch is not really that important, There are many, many people who disagree. I, for one, think this nonsense is entirely unacceptable. > it affects only a few CAS flags. Yup, with a total of maybe two dozen or so potential calculator configurations... -- Helen. ==== >> I don't think it is the case anymore if you compare with the 49+. > >It is. Someone posted an example of some integral, which takes >something like 4.x seconds on a 49G+, and about 0.6 seconds on a TI89. >I also mentioned the example of numerical integration, which is >roughly a factor of 3 faster on the TI89 compared to the 49G+. > But doesn't theTI use a table lookup for doing integrals etc? If it does, it is not quite fair to compare it to an HP unless it is using the exact same method. You can not compare Apples and Oranges. Harold A. Climer Dept.Of Physics,Geology,and Astronomy University of Tennessee at Chattanooga Chattanooga TN USA 37403 ==== > But doesn't theTI use a table lookup for doing integrals etc? If it > does, it is not quite fair to compare it to an HP unless it is using > the exact same method. You can not compare Apples and Oranges. Why in the world would that not be fair? All that counts is if I get a solution. I could not care less if the calculator uses a warp drive to cruise out to hyperspace in order to find out that int cos(x) dx=sin(x), or if it looks up the result in a table. Now, of course, if the subset of integrals that the HP can find was substantially larger than the one for the TIs, that would be a different matter, but that does not seem to be the case. On the other hand, Parisse is correct that there are, indeed, cases were the HP is faster fidning integrals than the TIs, so that is something one has to keep in mind. -- Helen. ==== > > But doesn't theTI use a table lookup for doing integrals etc? If it > > does, it is not quite fair to compare it to an HP unless it is using > > the exact same method. You can not compare Apples and Oranges. > > Why in the world would that not be fair? All that counts is if I get a > solution. I could not care less if the calculator uses a warp drive to > cruise out to hyperspace in order to find out that int cos(x) > dx=sin(x), or if it looks up the result in a table. I agree with Helen. There is, at least, a large precedent for such comparisons (e.g. the Steinhaus benchmark). > Now, of course, if > the subset of integrals that the HP can find was substantially larger > than the one for the TIs, that would be a different matter, but that > does not seem to be the case. One thing that would be relatively easy to implement is Horowitz reduction: http://mathworld.wolfram.com/HorowitzReduction.html It is part of MathTools, but it would be nicer if it were built-in. > On the other hand, Parisse is correct that there are, indeed, cases > were the HP is faster fidning integrals than the TIs, so that is > something one has to keep in mind. That is the case in any CAS comparison, pretty much. There are always examples one of them does faster. A general comparison should therefore be weighted for commonly used things. -- Bhuvanesh ==== > >>I don't think it is the case anymore if you compare with the 49+. > > > It is. Someone posted an example of some integral, which takes > something like 4.x seconds on a 49G+, and about 0.6 seconds on a TI89. You will always find examples that are faster on one of the calc and conversely, it was still the case with the HP49, e.g. look at Olivier Miclo comparisons. If you don't take many examples, then why not judge with my favorite example 1/(x^4+1)^4 :-)? > I also mentioned the example of numerical integration, which is > roughly a factor of 3 faster on the TI89 compared to the 49G+. > Numerical integration is not part of the CAS, it is part of the HP48 (and most probably the 28). Therefore I never made testings, do you judge on one example or on a representative list of examples? > >>You will get the same kind of error on the 48 -> you should redirect >>your critic to the 48 designers. > > > Sigh... Why do you have to take everything personally? > When someone make a criticism on the CAS, then it is > >>I just can't understand people who would accept a silent >>mode switch degree to radian, integrate, and then back >>radian to degrees which would lead to the false conclusion >>that integrating cos(x) in degrees gives sin(x). > > > Then why not give the correct result? > Seems simple, but it is in fact long to do if you want to be sufficiently sure not to forget one case. Moreover I'm not sure it is possible to find a good definition for exp(i*x)*sin(x) if x is in degree. What should be the antiderivative of this function? Really, radian is the only reasonable unit for angles. > > > Frankly, the radians switch is a red herring, I think. The switches to > complex mode, or approximate mode, or symbolic constants, etc. are > much more annoying. There is no reason at all not to save and restore > these flags, silently, without any fussing. > Then set the silent flag on, and press shift-i or shift-num simultaneously to switch the modes if they have changed (something you can check with the header). Or even better define a user key assignement which restores your default flag configuration. > >>And the annoyance of mode switch is not really that important, > > > There are many, many people who disagree. I, for one, think this > nonsense is entirely unacceptable. > I have seen around 10 people in this newsgroup, that's not that many people, but they make a lot of messages about that:-) ==== A second, somewhat less brief take on this issue... > You will always find examples that are faster on one of the calc > and conversely, it was still the case with the HP49, e.g. look > at Olivier Miclo comparisons. If you don't take many examples, > then why not judge with my favorite example 1/(x^4+1)^4 :-)? Good example, point taken. So there are integrals that the HP does faster than the TI. Good. > Numerical integration is not part of the CAS, it is part > of the HP48 (and most probably the 28). Therefore I > never made testings, do you judge on one example or > on a representative list of examples? That seems to be the case generally. I am somewhat curious as to why that is, actually, and would be interested in examples where it might not be the case. I really do not understand why the TIs are so much faster in that case, just as I don't understand why they are so excruciatingly slow in the linear lagebra area. > Seems simple, but it is in fact long to do if you want > to be sufficiently sure not to forget one case. Moreover > I'm not sure it is possible to find a good definition > for exp(i*x)*sin(x) if x is in degree. Well, I am sure you understand that that issue has nothing at all to do with a CAS. Just check what numerical values you get for, say, i*sin(x)-sinh(i*x), with x any real number, when in degrees mode. So, yes, degrees mode is clearly a kludge, meant for a very special subset of applications, and for that particular case I may even agree with you that reminding the user of that fact can be useful. You may notice, however, that no calculator issues any warnings when users try to evaluate mixed expressions containing trigonometric and non-trogonometric functions in degrees mode. I think the philosophy is simply to assume that the user knows what s/he is doing. Which is not always true, of course... On the other hand, it is clear that, with your attempt to confine the discussion to the forced radians-mode switch, you are being disingenious, to the point of being misleading. Given the fact that you have a good understanding both of the mathematics and the technical aspects, I must assume that this is intentional on your part. The pertinent word for this kind of a snow job is dishonesty. You know as well as I do that none of the issues around degrees mode exist with respect to any of the other mode switches. Do you deny this? > Then set the silent flag on, and press shift-i or shift-num > simultaneously to switch the modes if they have changed > (something you can check with the header). Or even better > define a user key assignement which restores your default > flag configuration. I guess you are even writing this with a straight face... -- Helen. ==== > On the other hand, it is clear that, with your attempt to confine the > discussion to the forced radians-mode switch, you are being > disingenious, to the point of being misleading. Given the fact that > you have a good understanding both of the mathematics and the > technical aspects, I must assume that this is intentional on your > part. The pertinent word for this kind of a snow job is dishonesty. > You know as well as I do that none of the issues around degrees mode > exist with respect to any of the other mode switches. Do you deny > this? > I'm not sure I understand what you say. There are not that many flags that are not restored by the CAS: those I consider affecting so much the CAS behavior that I warn the user the CAS must change them to solve the problem, and that this change will completely modify the next CAS command. This is the case for approx mode and complex mode. ==== > I'm not sure I understand what you say. There are not that many > flags that are not restored by the CAS: > those I consider affecting so much the CAS behavior that > I warn the user the CAS must change them to solve the problem, > and that this change will completely modify the next CAS command. > This is the case for approx mode and complex mode. Yes, so why don't you restore the flags after the command is done? What I am saying is that there are no issues of the kind one might perceive for the degrees/radian switch for these flags. You know this very well, and yet you try to suggest to people (apparently successfully to some of the more naive participants in this thread) that there is a rational reason not to restore the flags. As I have said before, there is no other CAS in common use that requires the kinds of silly mode switches that yours has. Why do you think that is? could still type in their arguments in terms of their familiar units (and do so easily and conveniently), and all the inconsistencies of degrees mode would be avoided. ==== > > Yes, so why don't you restore the flags after the command is done? > What I am saying is that there are no issues of the kind one might > perceive for the degrees/radian switch for these flags. You know this > very well, and yet you try to suggest to people (apparently > successfully to some of the more naive participants in this thread) > that there is a rational reason not to restore the flags. As I have > said before, there is no other CAS in common use that requires the > kinds of silly mode switches that yours has. Why do you think that is? > I have no idea, but for sure it gives users of these systems habits so that they think other way of doing things is wrong. Following the same kind of idea, one could say: RPN is completely silly because none of the calculator manufacturers except HP make RPN calculators. The interesting question should be: given someone who does not know any CAS system, and knows enough math to understand what really happens, would he find my mode switches really silly? About approx mode, I believe that the TI89 solved this using AUTO mode, following the blackbox-CAS philosophy I don't like. I think it is much preferable that students are confronted to the problem of choosing exact/approx mode as soon as possible. Remember that I developped the 49G CAS as a mathematical pedagogical tool. Note that even popular PC CAS like Maple are sometimes very inconsistent on exact/approx mode, for example if you enter 0.0 as initial value for a recurrence relation like x->sqrt(2+x), it will return exact values (tested with maple V.5). ==== > > > > Yes, so why don't you restore the flags after the command is done? > > What I am saying is that there are no issues of the kind one might > > perceive for the degrees/radian switch for these flags. You know this > > very well, and yet you try to suggest to people (apparently > > successfully to some of the more naive participants in this thread) > > that there is a rational reason not to restore the flags. There are many rational reasons. My personall favorite is to avoid mistakes.My friend who used another brand of calcs, you can guess which one im talking about, failed miserably in a 2 question phjysics exam because he couldnt correctly use trigs... why?? negative, weird and wrong answers.... IT was working with radians and he didnt notice. Worst thing is he didnt switch to radian mode. Hell, it wasnt even in radian mode!! I forgot what function he was using for that error, but, if you ask me, id rather be warned. > >As I have > > said before, there is no other CAS in common use that requires the > > kinds of silly mode switches that yours has. Why do you think that is? > > > > The interesting question should be: given someone who does not know > any CAS system, and knows enough math to understand what really happens, > would he find my mode switches really silly? > About approx mode, I believe that the TI89 solved this using AUTO mode, > following the blackbox-CAS philosophy I don't like. I think it is much > preferable that students are confronted to the problem > of choosing exact/approx mode as soon as possible. Remember that > I developped the 49G CAS as a mathematical pedagogical tool. Personally, about exact-aprox mode... I have no problems with that. It allows more customization, if thats what youll call it. When i enter, lets say 60 SIN, i get the answer v/3/2 (square root of 3 halves) in exact mode, and an irrational decimal number in aprox mode. Its detail like these that make the user dependace worth while. Not to mention it also affects the way expressions are evaluated... With some AUTO mode i would probably never get the answer i want when working with polynomials and stuff like that. ==== > There are many rational reasons. My personall favorite is to avoid > mistakes.My friend who used another brand of calcs, you can guess > which one im talking about, failed miserably in a 2 question phjysics > exam because he couldnt correctly use trigs... why?? negative, weird > and wrong answers.... IT was working with radians and he didnt notice. > Worst thing is he didnt switch to radian mode. Hell, it wasnt even in > radian mode!! I forgot what function he was using for that error, but, > if you ask me, id rather be warned. It can't have been working with radians in degree mode (or vice versa) unless your friend specifically asked it to. > Personally, about exact-aprox mode... I have no problems with that. It > allows more customization, if thats what youll call it. > When i enter, lets say 60 SIN, i get the answer v/3/2 (square root of > 3 halves) > in exact mode, and an irrational decimal number in aprox mode. Its > detail like these that make the user dependace worth while. Not to > mention it also affects the way expressions are evaluated... With some > AUTO mode i would probably never get the answer i want when working > with polynomials and stuff like that. You could always set it to EXACT or APPROX if you want. I personally prefer the AUTO mode. What do you mean when you say, working with polynomials? Solving polynomial equations? -- Bhuvanesh ==== > > There are many rational reasons. My personall favorite is to avoid > > mistakes.My friend who used another brand of calcs, you can guess > > which one im talking about, failed miserably in a 2 question phjysics > > exam because he couldnt correctly use trigs... why?? negative, weird > > and wrong answers.... IT was working with radians and he didnt notice. > > Worst thing is he didnt switch to radian mode. Hell, it wasnt even in > > radian mode!! I forgot what function he was using for that error, but, > > if you ask me, id rather be warned. > > It can't have been working with radians in degree mode (or vice > versa) unless your friend specifically asked it to. Really?? Im not so sure about that. There are some things that just wont work with degrees. There sort of an obolete unit if you ask me, but still should be used. I mean theyre pretty usefull. > > > Personally, about exact-aprox mode... I have no problems with that. It > > allows more customization, if thats what youll call it. > > When i enter, lets say 60 SIN, i get the answer v/3/2 (square root of > > 3 halves) > > in exact mode, and an irrational decimal number in aprox mode. Its > > detail like these that make the user dependace worth while. Not to > > mention it also affects the way expressions are evaluated... With some > > AUTO mode i would probably never get the answer i want when working > > with polynomials and stuff like that. > > You could always set it to EXACT or APPROX if you want. I > personally prefer the AUTO mode. What do you mean when you say, > working with polynomials? Solving polynomial equations? Ill give you an example. Lets say X^2+2*v/3x+3 FACTOR Exact mode: (X+v/3)^2 Aprox Mode: (X+1.7320..,)^2 Auto Mode: ???????????????????????? My point is that its easy to get undesired answers. So, auto mode isnt a must IMO. ==== > Ill give you an example. Lets say > X^2+2*v/3x+3 > FACTOR > > Exact mode: (X+v/3)^2 > Aprox Mode: (X+1.7320..,)^2 > Auto Mode: ???????????????????????? I don't know what you were doing, but I get the same result as for exact mode. The HP, on the other hand, will not factor your expression at all when in approximate mode. > My point is that its easy to get undesired answers. So, auto mode isnt > a must IMO. The only point of your example that I can see is that it is easy to get undesired answers if you do not have any clue at all of what it is you are doing. -- Helen. ==== > > Ill give you an example. Lets say > > X^2+2*v/3x+3 > > FACTOR > > > > Exact mode: (X+v/3)^2 > > Aprox Mode: (X+1.7320..,)^2 > > Auto Mode: ???????????????????????? > > I don't know what you were doing, but I get the same result as for > exact mode. The HP, on the other hand, will not factor your expression > at all when in approximate mode. My point exactly. No, what you say is not true. I got the answer shown in approx mode. Whats my point?? You have no idea what you say, and only reply to points that you *think* you can prove wrong. > > > My point is that its easy to get undesired answers. So, auto mode isnt > > a must IMO. > > The only point of your example that I can see is that it is easy to > get undesired answers if you do not have any clue at all of what it > is you are doing. > Well, thats another thing i wanted to mention. Some people might say your rude. What i say is that your just a bitter old hag. Get Real! Your the one that doesnt know what you say. I think that you just assume things (with no foundation) in most cases. Of course very few of your points do make sense, all your chatering has gone no where. Now, when you actually learn to use 49g series calcs and know something about the subject, as well as changing your attitude (my recomendation: get a therapist and a life) then perhaps it would be nice to discuss with you. I think it's time for me to filter some messages. It's really a pity that you believe you have The Knowledge, in a domain where you have not proven to have it. Parisse said it that way, ill say it this way: Im out of here... Im sorry Helen, but I cant waste any more time argueing with you, cause you just suck. Arrogant physics teacher that teaches math to physicists and speaks without knowing what she says. Look at what Parisse said... you think you have knowledge in a domain where you have not proven to have it. I actually think it has been proven that you DONT have it. Cya! ---end of topic for me... ==== > Ill give you an example. Lets say > X^2+2*v/3x+3 > FACTOR > > Exact mode: (X+v/3)^2 > Aprox Mode: (X+1.7320..,)^2 > Auto Mode: ???????????????????????? In AUTO mode, you would get an exact result unless you put a decimal point in, say, sqrt(3.), or you do approx(factor(...)) > My point is that its easy to get undesired answers. So, auto mode isnt > a must IMO. Not a must, but it usually gives me what I want, just like the autosimplification (let's not start another discussion on the latter, please :)) -- Bhuvanesh ==== > I have no idea, but for sure it gives users of these systems habits > so that they think other way of doing things is wrong. Following > the same kind of idea, one could say: RPN is completely silly because > none of the calculator manufacturers except HP make RPN calculators. But that is not what I am saying. > The interesting question should be: given someone who does not know > any CAS system, and knows enough math to understand what really happens, > would he find my mode switches really silly? Yes, that is the question. The answer to the question actually has little to do with whether or not we are talking about a CAS, or some other system. This is a question as to how one should design user interfaces in such situations. I'll give you an example: When you run a game on a PC, often times the design of the game may require that you switch resolutions and/or color depths of the display. All the games that are on the market (all current ones, anyway) handle this in such a way that, potentially after asking the user (there is nothing wrong with asking, of course), the resolution is switched, and, once the user quits the game, the graphics configuration in effect before the game ran is restored (but not restoring the graphics configuration would be considered inane). Now, just go out and ask somebody what s/he would think of a software designer who, like you, says something like well, if you don't like the new graphics settings, press shift-i or shift-num simultaneously to switch the modes if they have changed, or my conclusion on this is that users of previous games had some habits, they just did not learn a few new tricks. See what kind of answers you will get. > Note that even popular PC CAS like > Maple are sometimes very inconsistent on exact/approx mode, > for example if you enter 0.0 as initial value for a > recurrence relation like x->sqrt(2+x), it will return exact values > (tested with maple V.5). I can't check Maple V.5; they are at release 9 now... In any case, the behavior you describe would be considered a bug. I just checked in R8, and there the issue does not exist. -- Helen. ==== > > > The interesting question should be: given someone who does not know > > any CAS system, and knows enough math to understand what really happens, > > would he find my mode switches really silly? > > Yes, that is the question. The answer to the question actually has > little to do with whether or not we are talking about a CAS, or some > other system. This is a question as to how one should design user > interfaces in such situations. I'll give you an example: When you run > a game on a PC, often times the design of the game may require that > you switch resolutions and/or color depths of the display. All the > games that are on the market (all current ones, anyway) handle this in > such a way that, potentially after asking the user (there is nothing > wrong with asking, of course), the resolution is switched, and, once > the user quits the game, the graphics configuration in effect before > the game ran is restored (but not restoring the graphics configuration > would be considered inane). Hold it... That comparison is way off. Your talking about PC games. PLatform games like Mario Advanced pretty much dont have those settings. But PC games do. Now, i say your comparison is off, because a PC game is made, well for a PC, anyone that meets certain requirements. A game that needs 8 MB RAM and a pentium processor can run on a machine that has 8 MB RAM and a pentium processer as it can also run on a Pentium 4 with 1 GB RAM. The monitors used in different PCs, the OS settings, so many things that can influence potential resolution outcome. Unlike that, the HP 49g CAS is made... well for the HP 49g. So, I will slightly modify your comparison. I will compare it to a game like you did, just that it will be a platform game, a game made for a portable device, Mario Advanced (just an example). Lets say, that one gets used to certain controls. If at a certain level or for some reason, the controls have to be changed, then the user should be told so. If not, marios behaviour would be strange and wrong. You say it would be a good idea to change back the controls?? FINE CHANGE EM BACK WHATS THE BIG DEAL??????????????????????????????????? ==== >>The interesting question should be: given someone who does not know >>any CAS system, and knows enough math to understand what really happens, >>would he find my mode switches really silly? > > > Yes, that is the question. The answer to the question actually has > little to do with whether or not we are talking about a CAS, or some > other system. This is a question as to how one should design user > interfaces in such situations. I'll give you an example: When you run > a game on a PC, often times the design of the game may require that > you switch resolutions and/or color depths of the display. All the > games that are on the market (all current ones, anyway) handle this in > such a way that, potentially after asking the user (there is nothing > wrong with asking, of course), the resolution is switched, and, once > the user quits the game, the graphics configuration in effect before > the game ran is restored (but not restoring the graphics configuration > would be considered inane). > > Now, just go out and ask somebody what s/he would think of a software > designer who, like you, says something like well, if you don't like > the new graphics settings, press shift-i or shift-num simultaneously > to switch the modes if they have changed, or my conclusion on this > is that users of previous games had some habits, they just did not > learn a few new tricks. See what kind of answers you will get. > > I don't consider your comparison to be correct, because the game does not interfer with the rest of the applications. You will not for example use a result of the game that would depend on the screen resolution in your spradsheet. The CAS answer after the CAS command that switched the mode will be used in another command or displayed so that the user will read it and it has a meaning depending on this flag. You could avoid mode switch in a context non-sensitive CAS, but that does not exist, or you would have to pass so many arguments to any subroutine that it would never be usable. ==== > I don't consider your comparison to be correct, because the > game does not interfer with the rest of the applications. I agree, it would be really nice if the CAS did not interfere with the rest of the calculator system... > You will not for example use a result of the game that would > depend on the screen resolution in your spradsheet. I might. Why not? > The CAS answer after the CAS command that switched the mode > will be used in another command or displayed so that the user > will read it and it has a meaning depending on this flag. Let's cut through your obfuscation, why don't we? Here's an example: I am in numeric results mode, but for some reason I want to know what the integral of sin(x) is, a result which I may use later in order to obtain some numeric results. So, in order to do the integration, the CAS switches the flag, finds the result, and switches the flag back. Would you like to explain to me what would, or even could, be wrong with that result? Or, in what way the interpretation or meaning of that result would depend on any sort of flag setting? By the way, believe it or not, a TI89 will give you a result for your symbolic integral even if you switch it from automatic to numeric mode. How about that? And don't get me started on the kind of nonsense that happens on the HP if you select complex mode. I'll give you a hint: If I select complex mode, I might indicate that I _allow for_ complex results. It does _not_ mean that I want the CAS to take great pains in order to produce a complex result even if a much simpler real result is available. Again, that is something that all professional CAS, including the one on the TI calculators, seem to understand. On the HP, on the other hand, you have to be careful to try and always stay in real mode, if you want to avoid getting silly complex results even for things as straightforward as the integral of x*cos(x), say. And god help me if I happen to stumble upon a calculation where the CAS decides it needs to switch to complex mode, and I forget to switch back to real mode before trying to find a simple antiderivative... In short, the HP CAS is a mess, and essentially unsuitable for any market that one might target with such a device. I might add that I used to think that much of the fault for that lies with the poor overall management of the HP49G project, but you are telling me in no unclear words that a good part of this mess is in fact intentional, and by design. -- Helen. ==== >>I don't consider your comparison to be correct, because the >>game does not interfer with the rest of the applications. > > > I agree, it would be really nice if the CAS did not interfere with the > rest of the calculator system... > I don't see how it could not (with CAS relevant settings of course but the CAS does not modify any non CAS flags), it's completely embedded in the OS. >>The CAS answer after the CAS command that switched the mode >>will be used in another command or displayed so that the user >>will read it and it has a meaning depending on this flag. > > > Let's cut through your obfuscation, why don't we? Here's an example: I > am in numeric results mode, but for some reason I want to know what > the integral of > sin(x) is, a result which I may use later in order to obtain some > numeric results. So, in order to do the integration, the CAS switches > the flag, finds the result, and switches the flag back. Would you like > to explain to me what would, or even could, be wrong with that result? > Or, in what way the interpretation or meaning of that result would > depend on any sort of flag setting? > In approx mode, factorization is not done the same way as in exact mode since multiplicities of roots can not be detected because gcd of polynomials require exact data. Since factorization is required as soon as you integrate any rational fraction, the approx/exact flag has an influence on the antiderivative research. For sin(x) it would not change the answer, but as explained before, I can't do a checking for each particular argument. > By the way, believe it or not, a TI89 will give you a result for your > symbolic integral even if you switch it from automatic to numeric > mode. How about that? > > And don't get me started on the kind of nonsense that happens on the > HP if you select complex mode. I'll give you a hint: If I select > complex mode, I might indicate that I _allow for_ complex results. It > does _not_ mean that I want the CAS to take great pains in order to > produce a complex result even if a much simpler real result is > available. So let me show you that complex mode is not restricted to the fact that the answer has some i inside. Consider the antiderivative of 1/x, in real mode it is returned as ln(abs(x)) as every student learns. But this answer is wrong if x might be complex, ln(x) is the right answer in C. Another example is sqrt(z^2)=|z| in real mode, but that's also wrong in complex mode. In complex mode, you will get z*sign(re(z)). Your comparison with the TI CAS is not correct, because the TI CAS was not really designed to handle complex in a mathematically satisfactory way. I don't have a TI at hand, but my recollection is that the TI CAS does not compute correctly gcd of polynomials with complex coefficients (expand something like ((x+2+i)*(x-1+2*i))^2*(x+3+5*i)) and try to factor it back) or that it is not possible to do partial fraction decomposition over C. Please note that (even adding the fact that the TI89 does not provide the simplest polynomial arithmetic routine to the user), I don't consider this as a sign that the TI CAS is a total mess unsuitable to do any math and it's the fault of the designers. Perhaps they decided to do so to have something easier. > Again, that is something that all professional CAS, > including the one on the TI calculators, seem to understand. On the > HP, on the other hand, you have to be careful to try and always stay > in real mode, if you want to avoid getting silly complex results even > for things as straightforward as the integral of x*cos(x), say. And > god help me if I happen to stumble upon a calculation where the CAS > decides it needs to switch to complex mode, and I forget to switch > back to real mode before trying to find a simple antiderivative... > > In short, the HP CAS is a mess, and essentially unsuitable for any > market that one might target with such a device. > > I might add that I used to think that much of the fault for that lies > with the poor overall management of the HP49G project, but you are > telling me in no unclear words that a good part of this mess is in > fact intentional, and by design. > I think it's time for me to filter some messages. It's really a pity that you believe you have The Knowledge, in a domain where you have not proven to have it. adieu ==== > In approx mode, factorization is not done the same way as in > exact mode since multiplicities of roots can not be detected > because gcd of polynomials require exact data. Since factorization > is required as soon as you integrate any rational fraction, > the approx/exact flag has an influence on the antiderivative > research. For sin(x) it would not change the answer, but > as explained before, I can't do a checking for each particular > argument. You seem to be curiously unable to grasp the point I am making, judging from the way you bob and weave around the issue: The above has nothing at all to do with what I was asking for. I was asking you if you could demonstrate how a silent mode switch and restore would lead to a wrong result, or a result that might be interpreted wrongly. Seeing how you are going to great lengths to avoid answering that question, I must assume that you agree that no such problem exists. Yet you refuse to say so. Why is that? Otherwise, as far as the general wisdom of CAS modes is concerned, I maintain that this is a terrible kludge, and I repeat that no professional CAS makes use of this idea, for good reasons. In the case of distingusihing between complex and real variables, what is typically done is to allow the user to declare certain variables as real/complex. Switching to a real mode, or complex mode, that assumes that all variables are real/complex is helpful only in a very restricted set of situations. > So let me show you that complex mode is not restricted to the > fact that the answer has some i inside. Please, spare me. You can believe me that I have _some_ understanding of the requisite mathematics. > Your comparison with the TI CAS is not correct, because > the TI CAS was not really designed to handle complex in a > mathematically satisfactory way. I don't know if that is true. For example, the TIs treat the cases of the integral of 1/x just fine. On the other hand, even in complex mode the TI gives sqrt(z)=|z|. That is an obvious bug, and a serious one at that. TI should fix that, immediately. > I don't have a TI at hand, but my recollection is that the TI CAS does > not compute correctly gcd of polynomials with complex coefficients > (expand something like ((x+2+i)*(x-1+2*i))^2*(x+3+5*i)) and try > to factor it back) That works perfectly fine on my TI. > or that it is not possible to do partial fraction > decomposition over C. I don't really know. I don't usually do CA on calculators, and I don't use TI calculators, except in order to try out your examples in this thread ;-) > Please note that (even adding the fact that the TI89 > does not provide the simplest polynomial arithmetic routine > to the user), I don't consider this as a sign that > the TI CAS is a total mess unsuitable to do any math and it's > the fault of the designers. You may notice that I did not say that the HP CAS is unsuitable to do any math and it's the fault of the designers; you might want to make a habit out of reading more closely other people's arguments. What I am saying is that the designers of the TI CAS quite obviously invested a lot more effort into considering the useability of their system than what was done on HP's side. > Perhaps they decided to do so to have something easier. Most likely, yes (of course, the above square-root bug is something else; that's just plain wrong). > I think it's time for me to filter some messages. [Shrug...] That is your prerogative, of course. -- Helen. ==== > I don't know if that is true. For example, the TIs treat the cases of > the integral of 1/x just fine. On the other hand, even in complex mode > the TI gives sqrt(z)=|z|. That is an obvious bug, and a serious one at > that. TI should fix that, immediately. That is not a bug, as far as I know. The variable should be specified to be complex by appending an underscore. sqrt(z_^2) correctly remains unevaluated. In my opinion, it should have been exactly the opposite: variables should be assumed to be complex unless specified to be real. -- Bhuvanesh ==== > >>I don't know if that is true. For example, the TIs treat the cases of >>the integral of 1/x just fine. On the other hand, even in complex mode >>the TI gives sqrt(z)=|z|. That is an obvious bug, and a serious one at >>that. TI should fix that, immediately. > > > That is not a bug, as far as I know. The variable should be specified > to be complex by appending an underscore. sqrt(z_^2) correctly remains > unevaluated. > Hmmm, the drawback of this option is that you can not expect the argument of a square root to be squarefree anymore. Another option would be to simply choose one branch of the sqrt, that's mathematically less correct, but you can really use the expression in further computations. I'm anyway convinced that there is not one better option to handle this because there is an intrinsic mathematical problem here: it can not be hidden under the carpet, it is the user job to document himself about the way each particular CAS handle this. > In my opinion, it should have been exactly the opposite: variables > should be assumed to be complex unless specified to be real. > I have the same preference, therefore on the 49, in real mode all variables are assumed to be real, in complex mode all variables are assumed to be complex except if they are in the REALASSUME list. ==== > That is not a bug, as far as I know. The variable should be specified > to be complex by appending an underscore. sqrt(z_^2) correctly remains > unevaluated. Ahh, thanks for setting me straight on this! That's a pretty neat idea, btw. Maybe I should consider switching over to TI... My main problems with the TIs are that I don't like the form factor of the Voyage 200 too much, and the keyboard of the TI89 is such a desaster. I am not talking about the hardware, of course (after all, this is not one of the new HPs...), but the keyboard layout. And for a calculator, the TI89 certainly takes the cake as the calculator with the most inane keyboard layout ever to see the surface of the earth. With the exception of exponentiation, not a single one of the commonly used mathematical functions can be reached through a single key, and some of them (like base-10 logarithm, or exotic stuff like 1/x) are not present on the keyboard at all. [Sigh...] Let's just hope my HP48s will last... -- Helen. ==== >> Sigh... Why do you have to take everything personally? Well, Helen, your posts are often rude. Calling a stranger Honey or son, or telling him what you were already doing when he was probably still in diapers, or referring to someone as the little snot-nose or a team as a couple of kids off the street is just plain bad behaviour. I sure hope that you don't treat your students that way, and if you do, I certainly hope that they complain to the administration of wherever it is that you work. header, there's a good chance that I'll see you treat someone very rudely, and surely that person is likely to take it very personally. > When someone make a criticism on the CAS, then it is I can understand that. I also understand everyone working on the 49G was working under constraints, and that improving on and adding to legacy code is difficult. But I hope that you can understand that users may have valid complaints. >>> And the annoyance of mode switch is not really that important, >> >> >> >> There are many, many people who disagree. I, for one, think this >> nonsense is entirely unacceptable. >> > > I have seen around 10 people in this newsgroup, that's not > that many people, but they make a lot of messages about that:-) Just in case I haven't been counted yet, I find the mode switches without restoring the original modes to be one the worst annoyances of trying to use the 49G. How many seem to think that leaving the calculator in a changed mode after any built-in command, library command, or program that isn't specifically for changing modes is a good idea? I suspect that I could count them all with a single finger. Haven't you ever noticed that most the programs or libraries that others develop and make publicly available save and restore any settings that they force? In my opinion, not doing so is just plain bad programming. -- James ==== > > Well, Helen, your posts are often rude. Calling a stranger Honey or > son, or telling him what you were already doing when he was probably > still in diapers, or referring to someone as the little snot-nose or a > team as a couple of kids off the street is just plain bad behaviour. I > sure hope that you don't treat your students that way, and if you do, I > certainly hope that they complain to the administration of wherever it > is that you work. My guess is that shes reeeeeaaaaaaaallllllllyyyyyy old. She said she used HP calcs when i was in diapers.... hell, now thats a hag!!! I picture her as Gruntilda from Banjo-Kazooie. Even if considered rude, i guess that shes only a TI lover that hates modern HPs.... and even so, shes posting in Hp48 newsgroup. wtf... Now, have you ever had a literature or math teacher thats old, creepy and just a pain?? I guess shes the same thing, just that shes gone over to mathematical physics. > > header, there's a good chance that I'll see you treat someone very > rudely, and surely that person is likely to take it very personally. > Who takes it personally?? It may seem that Parisse took it sort of personally... but i dont agree... i think hes just defending his work (mainly his ideas and his posture). I see hes quite confident of what he says. ==== > My guess is that shes reeeeeaaaaaaaallllllllyyyyyy old. > She said she used HP calcs when i was in diapers.... hell, now thats a hag!!! I'm guessing she said that because your posts sound childish. I'm not saying your position is wrong, but you don't show any evidence supporting your claims. Kinda like me saying, HP's suck! TI's rock! BTW, please don't take my comments negatively. I'm just trying to explain my impression based on your posts. -- Bhuvanesh ==== > > My guess is that shes reeeeeaaaaaaaallllllllyyyyyy old. > > She said she used HP calcs when i was in diapers.... hell, now thats a hag!!! > > I'm guessing she said that because your posts sound childish. I'm not > saying your position is wrong, but you don't show any evidence > supporting your claims. Kinda like me saying, HP's suck! TI's rock! > > BTW, please don't take my comments negatively. I'm just trying to > explain my impression based on your posts. Yep. I pretty much said HP rules TI drools... but when the hag asked and parisse and many others. I think its just reckless for a blind TI user (JIC not talking about you, some of your posts are indeed cool) to go into a newsgroups HP48 And start ranting and complaining and indirectly insulting people. BTW, i wont take your comments negatively. Theres no need to. Also... please dont take mine the wrong way... I just dont like to see *TI can do that easy!!* when reffered to an HP issue... im sure no one does... but keep making those comments. PS: Bhuv where ya from?? Just curious. ==== > PS: Bhuv where ya from?? Just curious. India, originally, but I've been in the US since about mid-1995 (just when the Internet was getting really popular). -- Bhuvanesh ==== >Just in case I haven't been counted yet, I find the mode switches >without restoring the original modes to be one the worst annoyances of >trying to use the 49G. I have to go with Mr. Parisse here. Think of it: The calc silently changes these switches without telling while doing calulations and switches them silently back to the old settings (which is technically speaking perfectly possible). Now I«m forced to think, that the given results are valid for the old flag setting without any knowledge, that this is wrong. I personaly think, that Mr. Parisses approch is the best here: making a change, but telling about it. Mathias -- Mathias Habel mathias.habel_no-spam_@t-online.de Remove _no-spam_ before replying ==== > Think of it: The calc silently changes these switches without telling > while doing calulations and switches them silently back to the old > settings (which is technically speaking perfectly possible). Now I«m > forced to think, that the given results are valid for the old flag > setting without any knowledge, that this is wrong. I think you don't understand the situation. Apart from the red herring of the radians switch, the validity of the result has nothing at all to do with the flag setting. -- Helen. ==== What Mr. Parisse is saying: Option 1 - If solving a problem requires a mode shift, then error out & say the problem can't be solved in the current mode - rely on the user to change to mode manually & resolve the problem & then do whatever he/she wants to then. Option 2 - Offer to change the mode - realizing that the answer will be in that mode - AND leave the mode as changed - otherwise the answer may not be valid in the starting mode. For example - complex vs. real or approx. answer vs. exact answer. The user friendly option is # 2 - but at least warn the user that the mode change is needed & the calc is left in that mode when finished with the solution. Now for any problem that to be solved requires a foray into another mode but ends up with a result that is useful in the starting mode, then the mode change should be transparent. I don't know how many problem solutions result in this kind of action. Now about RAD vs. DEG: >Mr. Parisse: Moreover I'm not sure it is possible to find a good >definition for exp(i*x)*sin(x) if x is in degree. What should be >the antiderivative of this function? Really, radian >is the only reasonable unit for angles. Even exp(x)*sin(x), sinh(x)*sin(x) or x*sin(x) doesn't make sense to evaluate in DEG mode. HOWEVER, engineers like to do algebraic manipulations and calculus as if they were in RAD mode, but then evaluate in DEG mode. I can't think of a single reason why anybody in the world would ever want to take a derivative or integral of a function containing trignometric functions in DEG mode & screw around with the 180/PI constants. The solution is to do ALL algebraic manipulations & calculus as if RAD mode was set, but leave DEG mode set afterwards. Sounds simple? Maybe, but I wonder if this would screw up the step-by-step feature? John Edry > > >>Just in case I haven't been counted yet, I find the mode switches >>without restoring the original modes to be one the worst annoyances of >>trying to use the 49G. > >I have to go with Mr. Parisse here. >Think of it: The calc silently changes these switches without telling >while doing calulations and switches them silently back to the old >settings (which is technically speaking perfectly possible). Now I«m >forced to think, that the given results are valid for the old flag >setting without any knowledge, that this is wrong. I personaly think, >that Mr. Parisses approch is the best here: making a change, but >telling about it. ==== >What Mr. Parisse is saying: > >Option 1 - If solving a problem requires a mode shift, then error out & >say the problem can't be solved in the current mode - rely on the user >to change to mode manually & resolve the problem & then do whatever >he/she wants to then. > >Option 2 - Offer to change the mode - realizing that the answer will >be in that mode - AND leave the mode as changed - otherwise the >answer may not be valid in the starting mode. For example - complex >vs. real or approx. answer vs. exact answer. I think, instead, that in many cases is a useful thing that the calculator does not reset flags that it has changed to perform an operation. In this way, it's possible to have some problem, for me. For example, I need to create an operation (like SOLVE) that needs complex mode on, while I'm using the real mode, Naturally, the calculator ask for the switching, and then he completes the operation. But, after this, it may cause some problem setting the flag to real mode again: this because probably now I've a complex result, and now I need the complex mode to continue to work... For example, if I find roots of X^2+1=0 when I'm in the real mode, the calculator asks for the switching, and then it gives results, that are -i and i: after this, what's the sense of returning in real mode? If I want to use these values, I must to remain in complex mode. In this case, the changing of the flag is a good thing, for me, because, if the calculator returns to the real mode, I must to switch every time I use these results, and it's annoying. Daniele ==== > > > >Just in case I haven't been counted yet, I find the mode switches > >without restoring the original modes to be one the worst annoyances of > >trying to use the 49G. > > I have to go with Mr. Parisse here. > Think of it: The calc silently changes these switches without telling > while doing calulations and switches them silently back to the old > settings (which is technically speaking perfectly possible). Now I«m > forced to think, that the given results are valid for the old flag > setting without any knowledge, that this is wrong. I personaly think, > that Mr. Parisses approch is the best here: making a change, but > telling about it. > > Mathias I would like another flag :-) Lets call it Silent mode change and restore on/off Torstein > > -- > Mathias Habel > mathias.habel_no-spam_@t-online.de > Remove _no-spam_ before replying ==== > Haven't you ever noticed that most the programs or libraries that others > develop and make publicly available save and restore any settings that > they force? In my opinion, not doing so is just plain bad programming. I agree. Even on the HP-41, with its limited resources for storing and manipulating flags, many programmers made the effort to save flag settings and restore them at the end of the program. Those familiar with synthetics often used RCL d and STO d for this purpose -- which can be a bit of a challenge given a four-level stack and the normalization issues involved if you try to store the flag register in a numbered data register. -- Wayne Brown (HPCC #1104) | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== > I can understand that. > > I also understand everyone working on the 49G was working under > constraints, and that improving on and adding to legacy code is > difficult. > > But I hope that you can understand that users may have valid complaints. > > Usually, I try to improve the code when users have valid complaints and tell them in a constructive manner like you do. But unfortunately for the 49, I do not have time to invest in large changes like those that e.g. accepting degree mode in CAS functions would require (assuming it would make sense everywhere). Therefore the current situation is a trade-off, not perfect, but I think most users should live with that, especially since the modified flags are not modified without warning the users, and are displayed in the status area, and affected flags can easily be restored by a user-key press using a program and user key assignement. Note that this kind of behaviour was also present in the 48, if you are for example solving an equation numerically the X variable will be assigned and when you leave the solver it is not restored (or purged), this can also perturb the user when he later evaluates an expression that contains X. My conclusion on this is that users of previous HP calcs had some habits, they just did not learn a few new tricks. And that is most probably because the 49 can almost be used like a 48. ==== > Then set the silent flag on, and press shift-i or shift-num > simultaneously to switch the modes if they have changed > (something you can check with the header). Or even better > define a user key assignement which restores your default > flag configuration. You are just being obstinate. None of these silly gyrations should be necessary. > I have seen around 10 people in this newsgroup, that's not > that many people, but they make a lot of messages about that:-) Yup, disregarding your own opinion, a hundred percent of them think the mode switches are an unnecessary aggravation. -- Helen. ==== > Then please explain how the mode switch should be done. Why, such that the CAS resturns the correct result for the derivative and anti-derivative of trigonometric functions. I assume you don't need help figuring out what that means... -- Helen. ==== > > you could do the following: > > 1) save the CAS affected flags > > 2) do CAS processing silently > > 3) restore the flags > > 4) show result > > The HP calculatrice before the 49G *never* changed any flags > > automatically on any calculation - including limited symbolics > > nor should they do it today... > > I don't agree, because if the calc would switch silently > in rad mode to make the integral and then back to previous angle > mode, you could get what appears to be a wrong answer > (e.g. in degree mode the antiderivative of cos(x) would be sin(x)). > CAS + degree mode = bad idea. Well Parisse, i see your points. In fact i must say that what you have done is wonderfull. But, theres still a little problem. When using SOLVEVX for example, it asks for a mode switch to radians. IF i am using trig functions, what i do is change to rads, solve the equation and evaluate the functions after switching back to degrees. Now, i understand what you say; but how about this idea: Having a 3rd option. Switch to RAD mode? Yes No Silent. If silent is chosen then do what ==== > Now, i understand what you say; but how about this idea: Having a 3rd > option. > Switch to RAD mode? Yes No Silent. If silent is chosen then do what I'm not against that, but it requires a lot of work if you want to be sure that it is done consistently for all functions. And as explained in another thread, what is the meaning of exp(i*x)*sin(x) in degree mode? Should i multiply only the arg of sin or also the arg of exp? ==== > > >C programming is more powerful in my opinion. Of course, we're > >entitled to our own opinions :-) > > > Some people define the power of a language acoording to the number of > lines of code you need to solve a problem: the less code you need to > write the more powerful the language is said to be. Through this definition, User-RPL would be extremely powerful. OF course, taking the advantage of RPN. But, when i speak of power, what i mean is how well the language fits the hardware. Ill explain; Even though c++ (for example) is a very nice language that can solve tons and problems and do many many many things, if used in a regular calculator i assume that due to limited RAM and processing capabilities, it would not be to efficient. In this case, RPL is designed for use with RPN calculators, working optimumly with limited RAM, each program consuming very little space. ==== > But, when i speak of power, what i mean is how well the language fits > the hardware. Ill explain; Even though c++ (for example) is a very > nice language that can solve tons and problems and do many many many > things, if used in a regular calculator i assume that due to limited > RAM and processing capabilities, it would not be to efficient. Right. And the TIGCC team has made it clear that they are not going to even try to support C++ programming (because of extremely bloated code, among other things). > In this case, RPL is designed for use with RPN calculators, working > optimumly with limited RAM, each program consuming very little space. One can optimize C code as well... -- Bhuvanesh ==== > > But, when i speak of power, what i mean is how well the language fits > > the hardware. Ill explain; Even though c++ (for example) is a very > > nice language that can solve tons and problems and do many many many > > things, if used in a regular calculator i assume that due to limited > > RAM and processing capabilities, it would not be to efficient. > > Right. And the TIGCC team has made it clear that they are not going to > even try to support C++ programming (because of extremely bloated > code, among other things). To start, i never mentioned C or TI programing (Because im not to wel informed about TI capabilities and stuff... i mean ive tried it, didnt like it and didnt look at much). C++ Was just an example i gave. > > > One can optimize C code as well... Imagine if RPL code is optimized... ==== > >But, when i speak of power, what i mean is how well the language fits >the hardware. Ill explain; Even though c++ (for example) is a very >nice language that can solve tons and problems and do many many many >things, if used in a regular calculator i assume that due to limited >RAM and processing capabilities, it would not be to efficient. > Ah, I have to step in here... There are very few cases where C++ is less effecient than C when programmed in the same way, and some where C++ is more effecient. One of the designing principles of C++ was that it not ever add features that made it less effecient than C overall, i.e. if you use exception handling then that could slow down function call/return, but if you never use exception handling it should be as effecient as C and you don't have to pay a penalty for using the language. Pete M. Wilson Gamewood, Inc. wilsonpm@gamewood.net ==== I was poking around my SD card and decided to view something called HPERRLOG.TXT. It says Fatal Error number 19087409 (0x1234031) reported in Capture.cpp rev 1.103, line 475 (This card was taken from an HP Photosmart 812 digital camera and stuck into my 49G+ without formatting, so that might confuse things a bit . . .) Anyone know where that message comes from? ==== Well, as it's Capture.cpp, i'd be led to think it is from the digital camera capturing photos, but i could be wrong. -MrM > I was poking around my SD card and decided to view something called > HPERRLOG.TXT. It says Fatal Error number 19087409 (0x1234031) > reported in Capture.cpp rev 1.103, line 475 > > (This card was taken from an HP Photosmart 812 digital camera and > stuck into my 49G+ without formatting, so that might confuse things a > bit . . .) Anyone know where that message comes from? ==== The SD card reader in my HP49G+ failed yesterday. This doesn't bode well for the new HP calcs. I didn't have problems with the paint flaking off, and haven't got any keys that doesn't work (but quite a few keypresses not registered!). Well, the keyboard is better than the one on the HP49G by far - it has a very good feel too, if it would just register keystrokes at a broader angle of attack (or else the bounce algorithm should be recoded). I have also experienced a couple of freezes that required RESET. One time was when using the BZ uncompressor on a large object (20k) and another time in the filer. Using ROM v1.22. have probably inserted and extrcated an SD card 20 or 30 times over the last weeks before the reader failed. ON-D 7 reports CARD TEST FAIL, and this happens with all 4 SD cards (all 128 MB versions) I own (and they work fine in my external reader on Win2k and WinXP). They are of course formatted with FAT16 aso. the loss is acceptable. The problem is that now that I have seen how easily the SD card reader fails, there's no chance that I *will* buy a new one :-) I think I'll contact HP Denmark for a replacement, but if they won't touch it, I guess my HP49G+ story is over for now. Anobody else with failing SD card readers on the HP49G+? ==== > Anobody else with failing SD card readers on the HP49G+? Not yet, my hp49g+ survived around 30 SD card in/out cycles so far. Some 256MB and some 64MB. I have to say that I have seen some very spectacular LCD layouts when trying to do something with SD card .. -- Mario Mikocevic (Mozgy) mozgy at hinet dot hr It's never too late to have a good childhood! The older you are, the better the toys! My favourite FUBAR ... ==== Just thought I'd throw in my $0.02 worth about the 49g+ from perhaps a slightly different perspective than some others have. I just received my 49g+ yesterday from Samson Cables (just over two weeks delivered to Vancouver, BC, Canada) and have messed around with it a fair bit already. I will briefly run through some of the obvious things and touch a little upon something that I haven't seen mentioned here much - User RPL speed. FYI, I also own an HP-97, 11C, 48SX and 49G and at one point owned a 41CV, 28C and 71B as well. Knowing me, this might become a fairly long posting, so you are warned... ;-) (Yup, it has... long and drawn out...) 1) If the keyboard didn't have a few bad keys, I would quite like it. As it stands, my 7 and right-shift key are spotty and require a little more pressure. With my 49g+, it definitely seems to be strictly a mechanical contact problem - if the 7 key doesn't register, press a little harder without releasing and it will register then. Nevertheless, unless it gets worse, I still prefer it to my 49G's keyboard (if anything, it may have already gotten a little better.) I have already gotten in the habit of pressing slightly harder and rarely miss a key now. For piece-of-mind, I find it beneficial, indeed almost necessary, to have the key-beep function on however. Man, what I wouldn't do to have a classic HP high-quality keyboard with the large Enter key on the 49g+ though... 2) While the 49g+ feels quite light and hollow, the case is actually quite rigid and accurately assembled (tight seams etc.) and not at all creaky. One wonders if the 49g+ could have been made thinner (and denser) overall with maybe a little more taper towards the bottom by having a side-mounted SD card slot. I was surprised to see that the 49g+ is actually larger (slightly wider and longer although slightly thinner) than my 48SX with its two huge expansion card slots! I have already gotten used to the weight and density of the 49g+ and it does not bother me, although the battery compartment position does make it slightly top-heavy when doing hand-held calculations. 3) The LCD is beautiful! It totally puts my 48SX LCD to shame and has much, much better contrast. It is also much better than my 49G where, even though the contrast is good, the LCD pixels cast fairly long internal shadows in some lighting conditions and the display is deeply recessed behind that thick piece of plastic. This makes it hard to read small fonts and soft-menus on the 49G screen when, for example, using a single desk lamp that is well off to the left or right of the calculator. Upon closer inspection, I noticed that the 49g+ pixels still cast shadows, but the shadow density seems lower and they seem a little shorter. In any case, all in all, a great LCD display on the 49g+! (Smaller pixels and higher resolution would, of course, still be appreciated...) 4) Yes, there is a slight sporadic flicker on the bottom two or three rows of pixels, both with ROM 1.20 and 1.22 and with or without the clock display. I am surprised at how bothered people are by this. For me it is a non-issue, but I can see how others may be more annoyed by it. 5) The painted case and printed keys (I think) concern me. I can't see it holding up as well to heavy use like my 11C has for the last 20 years! I wish, as do many others perhaps, that at some point HP will revert back to their classic styling and readable colour schemes with a darker, matte finish. Having bright shiny gold paint, that light glares from, can make the 49g+ key labels hard to read at times. It is certainly an improvement in legibility over the 49G though, but nowhere near as legible (IMO) as my 48SX is. 6) SD slot is a great feature. USB... generally yes, also good. For frequent uploading and downloading of data, it is more convenient than swapping the SD card in and out but I sure wish the 49g+ would have implemented a standard USB Mass-Storage compliant interface. That way it could be plugged in, without drivers or software, to most modern operating systems - including Macintosh systems - and simply come up on the machine as one or more mounted drives. Then files could simply be transferred via drag-and-drop. Although I suppose HP would then also have to include some sort of utility to help with the various text-file character translation modes - or have automatic translation occur in the calculator perhaps. 7) The tiny included manual is very inadequate. There isn't even a quick-reference booklet anymore. As many others have said, HP used to make the best manuals. No longer, it seems. Heck, I think my 11C manual was even larger! HP should include an equivalent to the excellent 48G Series AUR manual or at least have one available for purchase. None of the PDF files I have downloaded for the 49G or 49g+ come close. If anyone can point me to a function/command-reference for the 49G series, I would be most appreciative! I do use my 48G AUR for the 49 but there is certainly a lot of functionality that is not covered... 8) I find it somewhat inexcusable that with the return of an IR port, the 49g+ cannot communicate with older HP 48 series calculators - this really surprises me. Also, while I don't personally mind the lack of a wired serial port, I can see why others would like to have one. It would be nice if HP would make a premium version of the 49g+... built-in RS232 (as well as USB and IR), a classic high-quality keyboard (large Enter key also!) with full and detailed printed documentation. I would be more than willing to pay an extra $100 (or whatever) for a premium version if need be. Please... no debates on whether or not this should have already been included in the existing price - I realize there will likely be much disagreement on that point. Now -finally!- to the main part of my post... SPEED! For some perspective on my following comments keep this in mind: I almost never use the CAS and I rarely use function plotting. In general, the built-in functionality of my 48SX is all I need, although a few enhancements such as input forms and additional list processing functions etc. have been a welcome addition on the newer models. Heck, if the 71B had been designed with a multi-line display, I would probably still be using it today. The larger display was my main reason for going with the 28C and then the 48SX - not all the built-in symbolics or plotting functions. Of course, User RPL is also much nicer than BASIC though... (my opinion!) In any case... my main use for HP calculators, since the 71B, has been for high-level language programming of software to solve numerical problems - first BASIC on the 71B and then User RPL starting with the 28C, then the 48SX and 49G . Not Forth or Assembler or System RPL. I have taken a huge liking to User RPL because of its elegance, flexibility and its massive number of built in functions that speed coding and help to simplify programs. I have written everything from a phone-number database program, to astronomy software (calculating planetary and solar data for example) to a topographical map coordinate translation program (not sure what to call that one.) In general, I usually have a substantial and friendly user-interface on my software and have written all manner of routines for prompted data input, multi-page full-screen list displays (similar to choose-boxes), output text formatting etc. - all in User RPL. However... anyone who has tried to program such things in User RPL will likely be able to relate: some parts of my programs always felt sluggish. They worked well, worked reliably and were easy to use, but often... ran... so... s--l--o--w--l--y... Don't even start... ;-) Yes I know I should have learned System RPL or Saturn assembly but I couldn't be bothered. I already knew Pascal, Modula-2, C, C++, 80x86 assembly etc. and just couldn't be bothered to learn yet another programming language which, in the end, would only be applicable to my calculator. This is where, for me, I find the biggest improvement in the 49g+. My programs run so much faster! My display output formatting routines are speedy and everything feels substantially snappier. I'm sure a stopwatch would report a disappointing increase in speed but believe me, it sure feels like a lot more than the two or three-fold improvement (on average) that it is. The 49g+ must have crossed a kind of magical threshold for me where suddenly the user-interface speed (or lack thereof) is no longer noticeable or bothersome. The 49G was an improvement over the 48SX in this way as well, but nowhere near as much an improvement as the 49g+ is. The frequent pauses (garbage collection?) that occurred when running my programs on the 49G also seem to be a thing of the past. So there you have it. Despite its flaws, I am (so far) very happy with the purchase of my new hp 49g+. It has breathed new life into my existing programs and rather than learning how to write software for the Palm-OS (in order to gain some speed in a portable computing device), I will simply be happy to keep using what I like and what I am already familiar with - User RPL. Hopefully there is even more room for improvement if HP can start converting more ROM routines into native ARM code. One feature request I would like to make of User RPL though: now that we have lots of RAM and SD memory, why not add the ability to comment one's programs ?!! HP? Are you listening...? That's all folks... If you actually managed to read through all of Mike Mander ==== > [...] > One feature request I would like to make of User RPL though: now that > we have lots of RAM and SD memory, why not add the ability to comment > one's programs ?!! HP? Are you listening...? You can comment UserRPL code when you develop it on a PC. During a Kermit upload, the calculator will not only translate the << etc. trigraph sequences to their RPL words, but also discard everything between @ and newline. As you know, the programs are compiled during upload, so all formatting and comments are lost. If you really want commented code on the calc, you may want to keep source code as string object, or use comment DROP sequences, both of which may be waste of memory. Georg. ==== > > One feature request I would like to make of User RPL though: now that > > we have lots of RAM and SD memory, why not add the ability to comment > > one's programs ?!! HP? Are you listening...? > > You can comment UserRPL code when you develop it on a PC. During a Kermit > upload, the calculator will not only translate the << etc. trigraph > sequences to their RPL words, but also discard everything between @ and > newline. > > As you know, the programs are compiled during upload, so all formatting and > comments are lost. If you really want commented code on the calc, you may > want to keep source code as string object, or use comment DROP sequences, > both of which may be waste of memory. This is the only case I know where comments DO slow down programs and make them bigger :-) ==== > > If you really want commented code on the calc, you may > > ... use comment DROP > sequences, > > both of which may be waste of memory. > This is the only case I know where comments DO slow down programs and > make them bigger :-) Indeed, the ideal slow-down tool for programs which run too fast on the HP49G+ and to fill up all this unused empty memory :-) By the way, it is no problem to write a small program for the reserved variable betaENTER which does the following: While still in the command line, each time you press ENTER on your commented program string, your source is not only nicely compiled but at the same time, a copy of the source with all its comments is saved automatically on the SD-card. ==== > > > [...] > > One feature request I would like to make of User RPL though: now that > > we have lots of RAM and SD memory, why not add the ability to comment > > one's programs ?!! HP? Are you listening...? > > You can comment UserRPL code when you develop it on a PC. During a Kermit > upload, the calculator will not only translate the << etc. trigraph > sequences to their RPL words, but also discard everything between @ and > newline. the past, but would (optionally) also like the comments to persist inside the calculator as well. Specifically, I would like the ability to make changes to my code on-the-fly, in the calculator, and then be able to seamlessly download the changes back to my PC for backup without losing all the original comments in the process. If memory in the calculator is tight, one could then strip the code of comments inside the calculator if needed (with a new STRIPCOMM function or something) to reclaim some precious memory space. > As you know, the programs are compiled during upload, so all formatting and > comments are lost. If you really want commented code on the calc, you may > want to keep source code as string object, or use comment DROP sequences, > both of which may be waste of memory. I have thought of such workarounds for commenting code as well but they are inelegant solutions at best. I don't mind the wasted memory since I would expect that from keeping comments in any case, but I wouldn't want the slowdown of constantly pushing and popping strings to/from the stack during program execution. I realize that until recently, HP's haven't really had enough memory to afford liberal use of source code comments, so I am not critisizing their current absence. Rather, it is just another feature request that (I feel) may be useful to add on in the future. > > Georg. Mike Mander ==== > I realize that until recently, HP's haven't really had enough memory > to afford liberal use of source code comments, so I am not critisizing > their current absence. Rather, it is just another feature request > that (I feel) may be useful to add on in the future. it would perhaps be better to think before posting :-) It is obvious that comments on any source code should *not* occur in a compiled program (thrown away during execution, say). An advantage of the SD-card is that you can keep in it your commented source code forever, with as many comments as you want. That was previously possible only on cost of built-in port memory or if programming with Debug4x which saves everything on a PC. Be happy that this is no problem anymore on the 49+, even for very large projects. - Wolfgang ==== > > I realize that until recently, HP's haven't really had enough memory > > to afford liberal use of source code comments, so I am not critisizing > > their current absence. Rather, it is just another feature request > > that (I feel) may be useful to add on in the future. > > it would perhaps be better to think before posting :-) > It is obvious that comments on any source code should *not* occur in a > compiled program (thrown away during execution, say). An advantage of I totally agree, one would not want the unnecessary overhead of skipping over comment sequences in a running program and I am not suggesting a simplistic implementation that would cause program execution to slow down. Despite the fact that I've been using HP-48/49 calculators for over ten years now, I consider myself a newbie in comparison to all the experienced people in this group. Therefore, what I am about to suggest may not be feasible on the 49g+, but how about this: When a UserRPL program gets compiled, whether from pressing Enter in the built-in editor or when transferring a text file from a PC, the compiler could strip out each comment sequence and place it in an array, in system memory somewhere, that is tied to that particular program with an index for each comment string indicating its position in the code. That way, there is no overhead during program execution, just more overhead during the compile phase - and of course memory overhead for the saved comments. Subsequently, when a program is decompiled during transfer back to the PC or when it is opened with the 49's built-in editor, the decompiler would place the comment sequences back into the displayed code at the correct positions. Obviously, the compile and decompile would be slowed by the need to take out and add in comments, but with a 75MHz ARM at our disposal now, couldn't that be a relatively quick process? I admit that there are more pressing things that need work on the 49g+, so I suppose something like this would be very low on the priority list. As well, maybe I am the only one here who would like to see something like this implemented? As I mentioned in my long post, I only have experience in UserRPL and not SystemRPL or Saturn Assembler and thus lack a detailed understanding of the underlying hardware and system software. Therefore, my above suggestion may not even be technically feasible. > the SD-card is that you can keep in it your commented source code > forever, with as many comments as you want. That was previously possible > only on cost of built-in port memory or if programming with Debug4x > which saves everything on a PC. Be happy that this is no problem anymore > on the 49+, even for very large projects. > - Wolfgang Mike Mander ==== >When a UserRPL program gets compiled, whether from pressing Enter in >the built-in editor or when transferring a text file from a PC, the >compiler could strip out each comment sequence and place it in an >array, in system memory somewhere, that is tied to that particular >program with an index for each comment string indicating its position >in the code. That way, there is no overhead during program execution, >just more overhead during the compile phase - and of course memory >overhead for the saved comments. > >Subsequently, when a program is decompiled during transfer back to the >PC or when it is opened with the 49's built-in editor, the decompiler >would place the comment sequences back into the displayed code at the >correct positions. Obviously, the compile and decompile would be >slowed by the need to take out and add in comments, but with a 75MHz >ARM at our disposal now, couldn't that be a relatively quick process? > I think that is very interesting since they're have been Smalltalk implementations that work exactly like this. Pete M. Wilson Gamewood, Inc. wilsonpm@gamewood.net ==== I have a 38G that I got without manual. I have nearly figured out how it works but can't seem to be able to do any programming on it. Does anyone know where I could find information about that or an online manual. Arnaud ==== The 38G is very similar to the 39G and you can find an online manual for that and information on programming at http://www.hphomeview.com/help.htm > I have a 38G that I got without manual. I have nearly figured out how > it works but can't seem to be able to do any programming on it. Does > anyone know where I could find information about that or an online > manual. > > > Arnaud X-Face: #0?irvdFiM!(Tpl}/tO%_kuSW_^9G5aeIEnY1uNPcd@N_U.B30*[%N-cnqSC,rEfeqm:b oR({RM{x03]Iv}^2xc7J][^MkbL3DYdLevZ$&h0WbH!i:>O1i#FLy/mO2G~xMF *uQnfN4xre8v9%0fqg;i.!ymm~6w2nEx);Q~Q*8&dUO(fn ==== > Pour les francophones, allez voir la description de la HP49g+ sur le site > suisse de HP : > > http://h40043.www4.hp.com/products/calculator/graf49gplus_f.htm > > Absolument LAMENTABLE. > > Quand on lit une pareille traduction d'une multinationale comme HP on se > demande vraiment si cette marque consid.8fre encore ses clients autrement que > comme des pompes .88 frics ou des cr.8etins. > > Au lieu de s'occuper de ses stocks-options, de ses actionnaires et de virer > xxx% du personnel, Madame Carla Fiorina ferait bien d'embaucher des > traducteurs... Quand on constate un tel niveau d'amateurisme pour dans une > telle multinationale, on ne s'.8etonne plus des probl.8fmes de claviers ou de > piles des HP49g+. > > Il fut un temps o.9d HP .8etait synonyme de qualit.8e.... > Il fut un temps... :-(( > > Gilles > > ************* > Extrait : > > - Un syst.8fme d'alg.8fbre d'ordinateur (CAS) ins.8er.8e d.8evelopp.8e haut pour > manipulation symbolique future et solution progressive > - La capacit.8e localiser .88 limiter, .88 manipuler, copient et des expressions > d.8ecoupent, ins.8frent r.8esoudre progressivement. > - Entr.8ee de donn.8ees tr.8fs simple le mode de texte dans UPN ou alg.8ebrique. > - Grande m.8emoire interne avec un .8elargissement de la m.8emoire par les > Secure-Digital (SD) carte. USB raccordement pour des PC rapporte rapides .88 > l'.8echange des programmes .88 partir des PC ou d'Internet > - Large multiplicit.8e de possibilit.8es de solution des d.8epenses de r.8esultat et > des solutions d'avis dans 2 ou dans la repr.8esentation graphique dans 3D. > > ************** Je ne vois pas seulement de sorte que vous reprochiez ait cette traduction. Elle est bien pr.8esent.8ee et il n'y a aucun d.8efaut des othographes dans les mots. Il est incompr.8ehensible ? Il est exact un d.8etail. Ce qui importe l'intoxication, .88 condition que la bouteille soit eue... Merde : c'est l'inverse : - ( Merci babelfish :-D -- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com ==== > Dear Wolfgang, I appreciate heaps your work. Recently I started > dealing with the HP49G+. It seems to me your Keyman Library > (otherwise brilliant) is serving the HP49 ok. > I can't get a short, normal hit on my 49g+ in 99 out of 100 hits. > It's always been treted as a Long hold. > It must have to do with the difference in speeds. > I just can't reproduce your examples. > I've been trying, still... > Please, help! [Received from ] Dear all, it is impossible for me to answer all question I get daily concerning my is written in Keyman.htm. On the 49+, you *must* create a variable 'lht' in HOME in which you should store 1000 (as a zint or real). Maybe 900 is also OK, or perhaps 1100. In addition, write << 360. ->KEYTIME >> in the variable STARTUP. It is not true that the number in KEYTIME is irrelevant for the HP49+, at least not in ROM 1.22. As far as I remember the default value in KEYTIME is 0. But then some keys have a tendency to bounce. - Wolfgang ==== >Wolfgang- >Your HP49G+ page one of the first I checked out >when I did a search a few days ago. Looks like you've >got a good selection of tools there for download. Are all >of the tools listed on your page 49G+ compatible? >My question to you is this: I've not been able to find >information on the commands and arguments required for >the built-in libraries 256 and 257. Can you provide info >or links to same? Are there any other built-in libraries >that I'm not aware of? There are a lot of built-in libs. But these are the only two which are not attached automatically. However, they are attached by the library OT49+. Some of the commands of this libs are easily understood. But the majority need some knowlegde of the operating system. Unfortunately, I don't know a document which explains them to the normal user, not to the hacker. Maybe somebody knows? - Wolfgang http://page.mi.fu-berlin.de/~raut/WR49 ==== My 49g+ locks up whenever I exit from NOON (a routine in timeman). Any key I press causes an OFF (system shuts down.) Now when I attempt to turn it back on by pressing the ON key, it goes on for 2 seconds and then shuts off automatically. Sometimes, if I am very fast and very lucky, I can force a warmstart by pressing ON and immediately after pressing C (F3). Unfortunately this does not always work. In these occasions I have to reset by inserting my Hewlett-Packard Corporate-Issued System Reset Actuating Tool, otherwise known as a paperclip. Up to now I have always been able to reset the system. But I hold my breath every time. : >Wolfgang- : >Your HP49G+ page one of the first I checked out : >when I did a search a few days ago. Looks like you've : >got a good selection of tools there for download. Are all : >of the tools listed on your page 49G+ compatible? : : : >My question to you is this: I've not been able to find : >information on the commands and arguments required for : >the built-in libraries 256 and 257. Can you provide info : >or links to same? Are there any other built-in libraries : >that I'm not aware of? : : There are a lot of built-in libs. But these are the only two which are : not attached automatically. However, they are attached by the library : OT49+. Some of the commands of this libs are easily understood. But the : majority need some knowlegde of the operating system. Unfortunately, I : don't know a document which explains them to the normal user, not to the : hacker. Maybe somebody knows? : : - Wolfgang : http://page.mi.fu-berlin.de/~raut/WR49 ==== > My 49g+ locks up whenever I exit from NOON (a routine in timeman). Any key I > press causes an OFF (system shuts down.) Now when I attempt to turn it back > on by pressing the ON key, it goes on for 2 seconds and then shuts off > automatically. Sometimes, if I am very fast and very lucky, I can force a > warmstart by pressing ON and immediately after pressing C (F3). > Unfortunately this does not always work. In these occasions I have to reset > by inserting my Hewlett-Packard Corporate-Issued System Reset Actuating > Tool, otherwise known as a paperclip. Up to now I have always been able to > reset the system. But I hold my breath every time. system that has to do with its tendency for bouncing user-assigned keys. There is no bug in Noon or Timeman. It runs perfectly on the HP49. Noon will not lock up the way you described when exiting Noon by pressing a key very short (staccato). If an unshifted key is assigned, e.g., with a long-hold functionality, you are in danger. The only fixing which comes to my mind at present is to have a real about 500 in KEYTIME to prevent bouncing. But this may make the keys somewhat slower. Fortunately, this type of locking up of the 49+ is harmless. One has to use a paper-clip to provoke a warmstart. But no key assignment is lost and date&time are still correct. This type of a lock-up never happened on the 49. It occurs often and has nothing to do with Noon. I'm already used to it and fixed a paper-clip on my pullover :-) - Wolfgang > : >Wolfgang- > : >Your HP49G+ page one of the first I checked out > : >when I did a search a few days ago. Looks like you've > : >got a good selection of tools there for download. Are all > : >of the tools listed on your page 49G+ compatible? > : > : > : >My question to you is this: I've not been able to find > : >information on the commands and arguments required for > : >the built-in libraries 256 and 257. Can you provide info > : >or links to same? Are there any other built-in libraries > : >that I'm not aware of? > : > : There are a lot of built-in libs. But these are the only two which are > : not attached automatically. However, they are attached by the library > : OT49+. Some of the commands of this libs are easily understood. But the > : majority need some knowlegde of the operating system. Unfortunately, I > : don't know a document which explains them to the normal user, not to the > : hacker. Maybe somebody knows? > : > : - Wolfgang > : http://page.mi.fu-berlin.de/~raut/WR49 ==== > I hate to have to tell my students that only > a TI calculator will work with them.( LabPro) > I really leaves a bad taste in my mouth not > to be able to say HP's will work too. Doesn't the HP48GII offer exactly what you need? If I'm not mistaken, it has the same RS232 port as the original HP48SX/GX. -Joe- ==== > > I hate to have to tell my students that only > > a TI calculator will work with them.( LabPro) > > I really leaves a bad taste in my mouth not > > to be able to say HP's will work too. > > Doesn't the HP48GII offer exactly what you need? If I'm not mistaken, > it has the same RS232 port as the original HP48SX/GX. > > -Joe- Unfortunately, they have significantly changed the serial port on the GII. It no longer works with many (possibly a majority of) RS-232 devices. Bob ==== > > I hate to have to tell my students that only > > a TI calculator will work with them.( LabPro) > > I really leaves a bad taste in my mouth not > > to be able to say HP's will work too. > > Doesn't the HP48GII offer exactly what you need? If I'm not mistaken, > it has the same RS232 port as the original HP48SX/GX. > > -Joe- Unfortunately, they have significantly changed the serial port on the GII. It no longer works with many (possibly a majority of) RS-232 devices. Bob ==== >> I hate to have to tell my students that only >> a TI calculator will work with them.( LabPro) >> I really leaves a bad taste in my mouth not >> to be able to say HP's will work too. > >Doesn't the HP48GII offer exactly what you need? If I'm not mistaken, >it has the same RS232 port as the original HP48SX/GX. > >-Joe- It might be OK when they get all the bugs worked out. Unfortunately the GII has no FLASH upgrade capability and also has a smaller user RAM left after the OS overhead than the GX,,which will work.( albeit much more slowly than the GII) Of course that might not make a difference. You would have to write your own software for the GII to talk to the interface box, but I do not see that as being too much of a problem considering all the great 48 programmers that prowl these regions Some simple programs have already been written for the Vernier ULI box which also has an RS-232 port A Programmer's Reference Manual is available for both the ULI box and LabPro on Vernier's web site. Some energetic young lad might even be able to sell them to Vernier and I would not have that bad taste in my mouth any longer, Harold A. Climer Physics/Geology/Astronomy Lab Instructor U. Tennessee At Chattanooga ==== >But just how standard is USB? It looks to me as if each client device >needs its own driver on each host that it connects to. That's not my >idea of standard. I don't think that is a fair criticism of USB. If I plug in any RS-232 device to a host, how well will it work without software? It is true that many USB devices have special drivers, but that is because of the nature of the device, or sometimes the poor implementation of their USB service. New digital cameras that use direct USB connection are an example of USB done right - they act just like a USB hard drive, and that makes sense considering the typical use of the connection. If the only purpose of the 49g+ interface was to send and receive files, there is no reason hp couldn't have implemented it as a USB disk drive and not required any driver. Pete M. Wilson Gamewood, Inc. wilsonpm@gamewood.net ==== > > >>But just how standard is USB? It looks to me as if each client device >>needs its own driver on each host that it connects to. That's not my >>idea of standard. > > > I don't think that is a fair criticism of USB. If I plug in any RS-232 > device to a host, how well will it work without software? I think that as a general rule, the firmware/software to configure the serial (RS-232 or similar) port and send or receive data is built into the device or its operating system. Sort of like a driver, except that I don't have to add separate firmware/software to connect to a different device. A terminal emulator works fine for sending and receiving from the 48 series. Heck, even the DOS COPY command will work. For something more than transferring a simple short data stream, like a file transfer, I'll probably want more appropriate software. Sort of like Conn4x, except that Conn4x seems to be specialized for a few calculators. With Kermit or Xmodem, for example, I can transfer to and from quite a variety of devices, as long as they have the matching software installed. > It is true > that many USB devices have special drivers, but that is because of the > nature of the device, or sometimes the poor implementation of their > USB service. New digital cameras that use direct USB connection are an > example of USB done right - they act just like a USB hard drive, and > that makes sense considering the typical use of the connection. If the > only purpose of the 49g+ interface was to send and receive files, > there is no reason hp couldn't have implemented it as a USB disk drive > and not required any driver. Well, maybe. I see that Cyrille has already responded to this part. I'm not sure of all that the USB port is supposed to be able to do. The documentation leaves a lot to be desired. The Conn4x and USB driver combination doesn't work on my PC yet, except for updating the flash ROM. For example, are we supposed to be able to print (to a terminal emulator) via USB? Or use the XMIT and SRECV commands via USB? -- James ==== Dear hp49g user, read it with the hp49g+ and convert it to a RPL program. Is it possible to get the others translators, I mean KVISLF, KVIS, etc. I would like to do the inverse process: from a RPL program in the hp49g+ ---> translation ---> SD card --> PC and read the text program. F. Aguilo ==== > >But just how standard is USB? It looks to me as if each client device > >needs its own driver on each host that it connects to. That's not my > >idea of standard. > > I don't think that is a fair criticism of USB. If I plug in any RS-232 > device to a host, how well will it work without software? It is true > that many USB devices have special drivers, but that is because of the > nature of the device, or sometimes the poor implementation of their > USB service. New digital cameras that use direct USB connection are an > example of USB done right - they act just like a USB hard drive, and > that makes sense considering the typical use of the connection. If the > only purpose of the 49g+ interface was to send and receive files, > there is no reason hp couldn't have implemented it as a USB disk drive > and not required any driver. This would be a good idea, if it was (easely) feaseable... Let me explain USB drive use a sector type of interface. ie: the pc asked for sector n of the hard drive and the sector is transfered to it, exactly as on an IDE drive. The PC then handles the files as a file system now, for a digital camera, no problem, they have a SD card, or similar in them and they send the sector requested by the PC from the SD card. on a hp calcualtor, there is a file system, yes, but it is COMPLETLY different from the PC file system. what would the calcualtor do when the pc request sector 0 (partition table)? well, it could, on the fly create a fony sector and send it to the pc... what does the calcualtor do when the pc require the FAT? well, same thing... up to here, all is good.... now, what happen when the PC read files? no problem again (I mean appart from the implementation that is starting to get tricky), it can generate something that looks like a hard drive from the internal file system... now, the PC starts to send writing orders on sectors for the calculator... what does the calculator do with them? well, this starts to get dificult, because these sectors are not linked with any file, and the calc does not know about sectors, only of files... well, let us save them (how many will we save? who knows).... anyway, at one point in time, the PC sends modifications to the FAT and the root directory, the calc can now go back on all the data received, make sense of it and transform everything back in calc files! ouf... (this include for example a file open for read/write and modified in the middle, files moved from A to B, directory changed (remember, on the calc, a directory is also a file... how does the PC deal with that)....) mind you, in this scenaro, how does the calc manage memory? oups... because as it need memory to work, but also needs memory that is the free memory on the hard drive... but as a hard drive can not resize itself, this will not work... again, what happends when the PC starts a defrag? that can not possibly make sense for the calcualtor... what I mean is that the idea is excelent, but unfortunately, not implementable due to the legacy of the HP48G file system... ==== > > > >>>But just how standard is USB? It looks to me as if each client device >>>needs its own driver on each host that it connects to. That's not my >>>idea of standard. >> >>I don't think that is a fair criticism of USB. If I plug in any RS-232 >>device to a host, how well will it work without software? It is true >>that many USB devices have special drivers, but that is because of the >>nature of the device, or sometimes the poor implementation of their >>USB service. New digital cameras that use direct USB connection are an >>example of USB done right - they act just like a USB hard drive, and >>that makes sense considering the typical use of the connection. If the >>only purpose of the 49g+ interface was to send and receive files, >>there is no reason hp couldn't have implemented it as a USB disk drive >>and not required any driver. > > > This would be a good idea, if it was (easely) feaseable... > > Let me explain USB drive use a sector type of interface. ie: the pc asked > for sector n of the hard drive and the sector is transfered to it, exactly > as on an IDE drive. > The PC then handles the files as a file system > > now, for a digital camera, no problem, they have a SD card, or similar in > them and they send the sector requested by the PC from the SD card. > > on a hp calcualtor, there is a file system, yes, but it is COMPLETLY > different from the PC file system. what would the calcualtor do when the pc > request sector 0 (partition table)? well, it could, on the fly create a fony > sector and send it to the pc... what does the calcualtor do when the pc > require the FAT? well, same thing... > > up to here, all is good.... > now, what happen when the PC read files? no problem again (I mean appart > from the implementation that is starting to get tricky), it can generate > something that looks like a hard drive from the internal file system... > > now, the PC starts to send writing orders on sectors for the calculator... > what does the calculator do with them? well, this starts to get dificult, > because these sectors are not linked with any file, and the calc does not > know about sectors, only of files... well, let us save them (how many will > we save? who knows).... > anyway, at one point in time, the PC sends modifications to the FAT and the > root directory, the calc can now go back on all the data received, make > sense of it and transform everything back in calc files! ouf... (this > include for example a file open for read/write and modified in the middle, > files moved from A to B, directory changed (remember, on the calc, a > directory is also a file... how does the PC deal with that)....) > > mind you, in this scenaro, how does the calc manage memory? oups... because > as it need memory to work, but also needs memory that is the free memory > on the hard drive... but as a hard drive can not resize itself, this will > not work... > again, what happends when the PC starts a defrag? that can not possibly make > sense for the calcualtor... > > > what I mean is that the idea is excelent, but unfortunately, not > implementable due to the legacy of the HP48G file system... Ok, I'm well aware that the file system inherited from previous calculators is very different from the file system used on a hard drive (and the SD card). And the file system inherited from previous calculators is too well suited to a calculator to discard. I guess replacing it would mean scrapping RPL too, and I certainly don't want to ever see that. And I'm aware the the 49g+'s handling of the file system on the card is, so far, not up to what we'd like,; the inability to create subdirectories, for a start. But surely the 49g+ isn't totally ignorant of the SD card's file system either. I mean, it apparently can and does read to and write from directory entries, the FATs, and the appropriate clusters, and it can format the card. Obviously it gets information about the card's format from the boot record, and even information about the card is kept in the 49g+'s operating system when it's not actually accessing the card. Maybe the 49g+ could totally hand control of the card to the PC when it's accessing the card via USB? Of course, if the 48g+'s operating system is keeping information about the card in memory, it would have to be refreshed when control were handed back, but I suppose that this has to be done any time that a card is inserted anyway. By the way, I've been turning the 49g+ off when removing or inserting the card, but wonder whether that's necessary. Is the card supposed to be hot-pluggable? Just a few stray thoughts, and I'm glad that you guys know more about it than I do. -- James ==== > > > > Actually, I had the problem with the word standard. After dealing > > with serial devices for over 20 years, that is one word I never use > > when it comes to RS-232. > > Ok, yes, there are indeed many different options to be aware of when > using RS-232. It's very flexible, and that flexibility can be a > disadvantage. You have to make sure that the two devices talking to > each other agree on a variety of options, and furthermore, if it's not a > direct connection, you have to be careful that anything relaying data > can handle whatever goes through without mangling it. I'm sure that > we've all had some very frustrating experiences using RS-232. But, > especially for direct connections, it's not overwhelming; there are a > limited number of things that could be going wrong. If one or both > devices are capable of being configured to use different options, a > successful connection is usually possible. It sounds like you are talking about things like baud rate, stop bits, parity, control flow, etc. Getting the settings right is only half of the battle, though. When I read James' post, I was thinking more along the lines of compatability at the electrical level. Lots of devices cut some corners in their RS-232 drivers/receivers. Usually it is done to save a little cost, sometimes because the designer didn't really understand RS-232 well enough. Either way, the devices typically work with *most* other devices, but then you'll run into a combination where both sides took shortcuts that conflict with one another. I believe a previous HP calculator (49G?) had problems like this with older Macintoshes. I saw one very odd case where two devices couldn't communicate, but then if the cable was made 3' longer everything worked fine. None of this is a problem with the RS-232 specification itself, but rather with the large collections of devices which are assumed to be RS-232, but don't really meet the full spec. Dave ==== > > >> > >> > Actually, I had the problem with the word standard. After dealing >> > with serial devices for over 20 years, that is one word I never use >> > when it comes to RS-232. >> >>Ok, yes, there are indeed many different options to be aware of when >>using RS-232. It's very flexible, and that flexibility can be a >>disadvantage. You have to make sure that the two devices talking to >>each other agree on a variety of options, and furthermore, if it's not a >>direct connection, you have to be careful that anything relaying data >>can handle whatever goes through without mangling it. I'm sure that >>we've all had some very frustrating experiences using RS-232. But, >>especially for direct connections, it's not overwhelming; there are a >>limited number of things that could be going wrong. If one or both >>devices are capable of being configured to use different options, a >>successful connection is usually possible. > It sounds like you are talking about things like baud rate, stop bits, > parity, control flow, etc. Those and signaling on other lines besides transmit and receive data. not be required on either. Of course the various connectors can also be a problem; which pin is which signal? It helps if you have a manual for the device. > Getting the settings right is only half of > the battle, though. > > When I read James' post, I was thinking more along the lines of > compatability at the electrical level. Lots of devices cut some corners > in their RS-232 drivers/receivers. Usually it is done to save a > little cost, sometimes because the designer didn't really understand > RS-232 well enough. Either way, the devices typically work with *most* > other devices, but then you'll run into a combination where both sides > took shortcuts that conflict with one another. I believe a previous HP > calculator (49G?) had problems like this with older Macintoshes. I'm aware that it can be a problem, but I've personally only had it happen to me when trying to use a fairly long cable with a defective device putting out a very weak (well below RS-232 specifications) signal. Well, I have run across some that didn't go negative for the mark signal, just to 0V, but I was aware that they weren't really RS-232 (the manuals made that clear) before actually trying to make the connections, and I knew that level shifters would be needed. According to the HP 48 I/O Technical Interfacing Guide, the 48 series' transmit signal is +/-3.0V minimum, 3.5V typical. And for the received signal the operating ranges are -15.0V to .03V for a mark, and 1.0V to 15.0V for a space. The absolute maximum allowable voltage for both is +/-25V. I believe that the 49G (except for some early defective units) is the same. Quite possibly those early 49Gs with the serial port hardware bug having trouble with some Macintoshes and perhaps some other devices are what you heard about. cable might be the same, but I wouldn't want to count on it being able to take +/-25V, or even +/-15V, without anything getting fried; any volunteers? The special cable, I'd guess, is there to boost the signal into the recommended range, but could also limit the received voltage. I don't have copies of the RS-232 standards (they aren't free) but as far as I can tell, the RS-232 standards specify, for transmitting, -15.0V to -5.0V for a mark and +5.0V to +15.0V for a space. But for receiving, -15.0V to -3.0V for a mark, and +3.0V to +15.0V for a space. And everything should be able to withstand at least +/- 25V. So those calculators don't meet the recommended standard for transmitted signal levels, but with any luck (the other device meets or exceeds the standard for received signals and not much signal loss) it ought to work, and usually it does. My Sharp EL-5520 manual says that the output is 4-6V, and warns that it uses CMOS components, and voltages exceeding the allowable range may manual for the Sharp CE-137T level converter, it seems that what it expects from the handheld is 0 to +0.5V for a mark and +3.3V to +5.5V for a space, so I guess that straight from the EL-5520 it's even worse than the HP calculators; the signal doesn't swing negative for a mark. For the output from the level converter, it claims -10 to -3V for a mark and +3 to +5.5V for a space; still not necessarily up to the standard, but it works for me. I really don't know which (if any) standard the Macintoshes claim to support, or whether they meet it. > I saw one very odd case where two devices couldn't communicate, but then > if the cable was made 3' longer everything worked fine. That is strange. My guess is that it wasn't entirely the peak voltage levels, but perhaps more the pulse shape. Maybe the extra length changed the cable capacitance just enough to allow it to work. Or if it was a different cable entirely instead of a matter of adding an extension, maybe the longer cable actually had less signal loss or distortion. > None of this is a problem with the RS-232 specification itself, but > rather with the large collections of devices which are assumed to be > RS-232, but don't really meet the full spec. I agree. If the device has a serial port, then they should say which (if any) standard it meets. Best if the device actually meets some standard, but if it doesn't, then they should say so very clearly up front. At least the 48SX engineers were well aware of the problem, and did find a way to make it close enough to work with most RS-232 devices. But I don't think that the full story ever made it into the Owner's Manual; I think that it never actually mentions RS-232, but uses the term serial instead. So they didn't actually lie about it, they just let the buyers assume that serial means RS-232. As far as I can tell, the special cable for the 48gII is intended to be a way to get the transmitted data signal into the recommended range. Certainly that's a worthy goal, but in my opinion a misguided method of meeting it, even if some PDAs do it that way. Surely electronic devices have advanced a bit since the 48SX was designed; it would've been better to put it all into the calculator and draw any power needed from its own batteries, rather than relying on being able to get power from the other device. I guess that it's too late now; the 48gII is already in consumers' hands. Maybe on the next calculator.... -- James ==== It occurred to me that, with all the memory that's available on a 49g+, there isn't anything keeping one from storing a brief summary of all available commands, to be utilized when trying something new. I robotically walked through the CAT menu, appending each command to a string, and then parsed the string into a sorted, corrected list of 762 command strings. I envision three lists, each with the same number of entries: 1. the 762 commands (perhaps to grow in the future?); 2. a list of strings briefly explaining what the corresponding commands do, and 3. a list of lists, each detailing the various combinations of arguments accepted by the corresponding command. (Remember the CATALOG function on the 28C/S?) A simple application would return the explanation of and/or arguments allowed for a given command. Of course, once the information is available in a structured form, other bells & whistles could follow. (I don't think a .pdf reader would be the way to go just yet ... ) The whole business should fit well within the 49G+ memory, and could be stored on the SD card by experienced users when not in use. I figure if several folks could divide up the investigation & data entry, we could have a shared resource in no time. (Its availability might make for greater acceptance of the new model among new users.) Responses? Ideas? Am I off base? (Is there something already available??) Do let me know! ==== >It occurred to me that, with all the memory that's available on a >49g+, there isn't anything keeping one from storing a brief summary of >all available commands, to be utilized when trying something new. > Don't know if it is available (beyond the CAS Help) but definitely a good idea. Pete M. Wilson Gamewood, Inc. wilsonpm@gamewood.net ==== > Well, I decided to attempt to just disassemble the ROM. Does anyone > happen to have any pointers that could simplify this task a bit? For > starters, it would be quite helpful to know where the actual starting > point is and what this ROM contains. Sorry for the delay, here is what I could find: The 1.19.6 rom is ~4Mnibbles long. Actually, if you dump it with hexdump, you'll see that only 2Mnibbles are really used, the rest seems garbage. It starts with 0000000 6 2 9 4 0 8 0 1 8 0 3 0 1 0 0 0 The 1.22 rom is ~2.5Mnibbles long. I looked for the nibbles above and could find them at nibble #78000 (491520): 0078000 6 2 9 4 0 8 0 1 8 0 3 0 1 0 0 0 So I got rid of the preceding ~500Knibbles (which might very well be arm native code), and the result was a 2Mnibbles rom. I tried it on the Saturn 4.1.1.1 emulator, but of course it didn't work :o) (why ? new opcodes for instance, and some new hardware accesses) I then wanted to check for saturn-visible rom differences. On 1.19.6 roms, what is seen by Saturn as address #0 resides at nibble #40000: 0040000 7 0 0 0 0 4 3 0 5 2 3 6 d 6 1 8 So I again stripped off the previous 256Knibbles part of each rom. Then I launched vimdiff between both hexdumps, and I could then see only the little differences between 1.19.6 and 1.22 (I should have kept a 1.20 copy somewhere, there would have been even fewer differences). That's how I could see the 81Bx and BUSCC tricks. What is left ? Well, I even don't know that much about the 49g rom layout, so I can't tell much about the 256Knibbles part, but I'd really try to disassemble the 512Knibbles part, and maybe find some saturn emulator code ? Samuel Thibault ==== > > Well, I decided to attempt to just disassemble the ROM. Does anyone > > happen to have any pointers that could simplify this task a bit? For > > starters, it would be quite helpful to know where the actual starting > > point is and what this ROM contains. > > Sorry for the delay, here is what I could find: > > The 1.19.6 rom is ~4Mnibbles long. Actually, if you dump it with hexdump, > you'll see that only 2Mnibbles are really used, the rest seems garbage. > It starts with > 0000000 6 2 9 4 0 8 0 1 8 0 3 0 1 0 0 0 > > The 1.22 rom is ~2.5Mnibbles long. I looked for the nibbles above and > could find them at nibble #78000 (491520): > 0078000 6 2 9 4 0 8 0 1 8 0 3 0 1 0 0 0 > > So I got rid of the preceding ~500Knibbles (which might very well be arm > native code), and the result was a 2Mnibbles rom. I tried it on the > Saturn 4.1.1.1 emulator, but of course it didn't work :o) (why ? new > opcodes for instance, and some new hardware accesses) > > I then wanted to check for saturn-visible rom differences. On 1.19.6 > roms, what is seen by Saturn as address #0 resides at nibble #40000: > 0040000 7 0 0 0 0 4 3 0 5 2 3 6 d 6 1 8 > > So I again stripped off the previous 256Knibbles part of each rom. > > Then I launched vimdiff between both hexdumps, and I could then see only > the little differences between 1.19.6 and 1.22 (I should have kept a > 1.20 copy somewhere, there would have been even fewer differences). > That's how I could see the 81Bx and BUSCC tricks. > > What is left ? Well, I even don't know that much about the 49g rom > layout, so I can't tell much about the 256Knibbles part, but I'd really > try to disassemble the 512Knibbles part, and maybe find some saturn > emulator code ? > > Samuel Thibault ROMs. I've got an ARM disassembler as well as all the rest, so once I finish moving and get some free time I'll definately give this another go. Would you be interesting in maybe getting together on IRC or some other more real-time medium and work on this? Ideally I'd like to get a complete disassembly of the ROM with ARM and Saturn asm nicely seperated and a good idea of the boot up procedures (basicly how the calculator gets from OFF state to Saturn emulation). ==== > Would you be interesting in maybe getting together on IRC or some > other more real-time medium and work on this? Well #hp48, on the efnet network is there for this. I'm nicked youpi on it. Maybe a CVS holding commented disassembly would be interesting. Samuel Thibault ==== Whenever I use ON+C to reboot the calculator, I lose my system font size setting and have to re-set it every time -- none of the other settings seem to be affected. This is rather annoying -- think it'll be fixed in a ROM update, or is there something I'm missing here? Matthew F. G. ==== > Whenever I use ON+C to reboot the calculator, > I lose my system font size setting and have > to re-set it every time -- none of the other > settings seem to be affected. This is rather > annoying -- think it'll be fixed in a ROM > update, or is there something I'm missing here? Store << FONT7 ->FONT >> into 'STARTUP' in the HOME directory. Then it'll set FONT7 automatically after each warmstart. Cool, huh? You can put almost anything you want into 'STARTUP' but be sure it's stuff that cannot possibly cause an error. A buggy STARTUP is a Bad Thing. My personal 49g+ STARTUP at this moment is << 256 ATTACH -62 SF 1000 ->KEYTIME >>. -Joe- ==== I think it's the suits, ties, and faux calculators that are unrealistic in the picture! :) > Well... It may be shocking but I'm an engineer (CE) too and I do get to > field work on a semi-regular basis. I'm sorry, but hard hats and safety > glasses (and possibly OSHA required steal-toed work boots) don't go well > with suits, ties and faux calculators. ;-) > > Greg > > ==== > what kind of level of complaining do we need to obtain in order for HP > to address the lcd flickering problem some of us are having with a > patch? ==== > > what kind of level of complaining do we need to obtain in order for HP > > to address the lcd flickering problem some of us are having with a > > patch? > > > A solution to the flickering is [Press ON plus up-arrow]. > > I tried it and during the short time I had to watch it, it appears to work. That's the Print LCD command. The calc is probably busy trying to find the printer and forgets to service the clock interrupt. Tom Lake If it wasn't for the bullet in my pocket, the Bible would have killed me. ==== > That's the Print LCD command. The calc is probably busy trying to find the > printer and forgets to service the clock interrupt. will this impact battery life, (with or without the clock turned on)? // greenchile505 ==== The only time I notice a flicker is within about 1-2 seconds after I complete an operation IF I don't push anything else. Makes one wonder if it is somehow powering down after running something. If I'm continuing to work, I don't ever see a flicker. Rom 1.22, SN CN33103XXX. Gene -- * These statements and opinions are mine alone and do not reflect my employer's views. * > > what kind of level of complaining do we need to obtain in order for HP > > to address the lcd flickering problem some of us are having with a > > patch? > > > A solution to the flickering is [Press ON plus up-arrow]. > > I tried it and during the short time I had to watch it, it appears to work. > > Matt ==== > > what kind of level of complaining do we need to obtain in order for HP > > to address the lcd flickering problem some of us are having with a > > patch? > > > A solution to the flickering is [Press ON plus up-arrow]. > > I tried it and during the short time I had to watch it, it appears to work. > > Matt WOW! It not only gets rid of the flickering - the flashing colon in the time display becomes much more regular also. ONward and UPward! Rick ==== >> You can solve the problem yourself by turning off the on-screen clock. >> That'll also make your batteries last a lot longer. >The only reliable way I have seen to solve the problem is to turn the >calculator off. What a great machine: There's a solution for >everything! ... Judging from most of your posts you really seems to hate the HP49G+. But why? If you dont«t like it, don«t use it. But it is really neccesary to make such noise about it, telling everyone how much better the TI calcs are (especially in a HP calc newsgroup) and that in an IMHO rude manner? Mathias -- Mathias Habel mathias.habel_no-spam_@t-online.de Remove _no-spam_ before replying ==== I have searched the manual and the right shift cat directory but did not fine what I would recongnize as the Q key like on the HP48sx. Where is it hidden? format question I set mode to display 3 dec places. when I input a number, example 10000 then 10000 is on the display if I mult by say 1.2 then divide by 1.2 the display is 10,000.000 How can I get 10,000.000 by just entering the number all the time? I like to see tha comma separators. On the hp48 I just set the mode to fix 3 and when I enter 100000 I get 10,000.000 David ==== Ah, I missed the part about ->Q in your post. My last calculator was a HP48SX as well. Look at appendix K in the manual. You need to go to the MAIN menu (look in the CATalog). Then go to the REWRITE submenu. The function is XQ() XQ(0.5) => 1/2 See XNUM also. Matthew F. G. > I have searched the manual and the right shift cat directory > but did not fine what I would recongnize as the Q key like on the > HP48sx. Where is it hidden? > > format question > > I set mode to display 3 dec places. when I input a number, > example 10000 then > 10000 is on the display > if I mult by say 1.2 then divide by 1.2 > the display is > 10,000.000 > > How can I get 10,000.000 by just entering the number all the time? > I like to see tha comma separators. > On the hp48 I just set the mode to fix 3 and when I enter > 100000 I get > 10,000.000 > > David ==== There are two ways you can do this: one, you can enter it like 10000. [1][0][0][0][0][.] with the decimal point Or, if you want it to show it like that w/o putting in the decimal point, you can change the CAS to 'approx' mode, by hitting [Mode][F3 (CAS)][down arrow][down arrow][F3 (chk)] then [F6][F6] for OK-OK There is a shortcut to switch modes, hold down right shift, then press enter -- you'll see a symbol in the header change between '=' for exact and '~' for approx mode. Hope this helps, I'm learning to use my 49g+ as well. Matthew F. G. > I have searched the manual and the right shift cat directory > but did not fine what I would recongnize as the Q key like on the > HP48sx. Where is it hidden? > > format question > > I set mode to display 3 dec places. when I input a number, > example 10000 then > 10000 is on the display > if I mult by say 1.2 then divide by 1.2 > the display is > 10,000.000 > > How can I get 10,000.000 by just entering the number all the time? > I like to see tha comma separators. > On the hp48 I just set the mode to fix 3 and when I enter > 100000 I get > 10,000.000 > > David ==== Sorry, but you are falling for a a couple of traps from the difference between the 48SX / 48GX and the 49G level calculators. 1) They have a new type called INTEGER. Input a number like 1000 and press ENTER and you have placed the INTEGER 1000 on the stack. Fix 3 does not place commas into integers. To show integers you must be in a fix mode and be dealing with REAL numbers. Type 1000 then the decimal point to get a real. It will show with commas. This has been true for 4 years now. The reason the 48 series doesn't do this is that they don't have the integer type. HP has been asked to find a way to show integers with commas as well as show commas when in standard mode. Given the LARGE number of things the user community asked for that were incorporated into the 49G+, I think there is a good chance this will come in the future. 2) The ->Q function is present but not as a key on the calculator. You can execute the function by typing '->Q' then EVAL. Press the single quote, press right shift, press zero, press ALPHA, press Q, then press ENTER. Then EVAL. If you use this function frequently, then I would assign it to a key and use the USER keyboard. Or develop a custom menu. Both are described in the Customizing your calculator training aid for the 49G+ available for download for free from HP's website. Gene -- * These statements and opinions are mine alone and do not reflect my employer's views. * > I have searched the manual and the right shift cat directory > but did not fine what I would recongnize as the Q key like on the > HP48sx. Where is it hidden? > > format question > > I set mode to display 3 dec places. when I input a number, > example 10000 then > 10000 is on the display > if I mult by say 1.2 then divide by 1.2 > the display is > 10,000.000 > > How can I get 10,000.000 by just entering the number all the time? > I like to see tha comma separators. > On the hp48 I just set the mode to fix 3 and when I enter > 100000 I get > 10,000.000 > > David ====