HP-19 ==== Gilberto Urroz escribi.97: > Apparently R->I works only on numbers not on matrices. R->I works with numbers in matrices. R->I doesn't woork with matrices themselves :-) > Thus, the > following program can take care of it: > > << -> M << M SIZE OBJ-> DROP * 1 SWAP FOR j M j GET R->I M SWAP j SWAP > PUT 'M' STO NEXT M >> > Why not the proposed XQ? If it has something to do with it changing modes, what about << R->I >> MAP ? If the OP works a lot doing things to everything inside matrices, maybe he should assign MAP to a key. -- To contact me, for each pair of hex values add: the value itself, its reversed position (16..1) and the correspondig letter in the spam & co. EB E3 FB E1 15 37 39 32 2B 09 45 2C FC 2F 4D 4C ==== > > Gilberto Urroz escribi.97: > > Apparently R->I works only on numbers not on matrices. > > R->I works with numbers in matrices. R->I doesn't woork with matrices > themselves :-) > > > Thus, the > > following program can take care of it: > > > > << -> M << M SIZE OBJ-> DROP * 1 SWAP FOR j M j GET R->I M SWAP j SWAP > > PUT 'M' STO NEXT M >> > > > > Why not the proposed XQ? If it has something to do with it changing > modes, what about << R->I >> MAP ? If mode changes are unwanted, use ->Qpi instead. > > If the OP works a lot doing things to everything inside matrices, maybe > he should assign MAP to a key. > Both XQ and ->Qpi work to convert decimal integers to exact integers within arrays, as well as elsewhere, but ->Q and R->I do not work on arrays. Both XQ and ->Qpi will also do other conversions within arrays. While XQ sets exact mode, ->Qpi has no effect on mode settings. Notation: -> represents the right arrow character (right-shift zero)and pi represents the lower case greek pi character (left-shift Space). ==== --------------------------------------------------------------------- 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 saw garbage occur on the screen. I saw the display flicker. I tested the SD memory function with a 256 mb. chip. It seemed to function correctly (format, R/W, Viiew sub-directories that I created with Windows XP PRO and a card reader). I installed the Operating System (OS 1.22) posted on HP's web site. I re-tested the keyboard using the calculator's built-in Keybard Test. One key failed 10 consecutive times! The display still flickered. I did not see the garbage screen again. The latest Operating System obviously did not correct the keyboard problem nor the display problems. I did not bother testing to determine if the batteries would last longer than the approximate 10 hours that has been reported in this newsgroup! The functioning of the keys on a calculator are as important as the trigger on a gun. If either does not function correctly, you have a SERIOUS PROBLEM! Some of the prior posts in this newsgroup have suggested turning off' functions or suggest possible work-around solutions to correct some perceived deficiencies. I do not turn-off the dashboard lighting in my car while driving in the dark to prevent the viewing of:: warning indicators, gauges, turn signals indicators, computer information or the speedometer to conserve power or prevent flickering. I expect the car manufacturer or his agent or representative to correct the problem. I don't expect any new item I purchase to require REPAIR or FIXING on my part (automobiles, computers, camera, water heaters, guns, televisions, power tools or anything else). I try to limit my conclusions of acceptance or acceptable quality level to only those observations, measurements, tests, performance, functions or parameters that were specified as deliverable (their advertised specification, or inherently required in order to function or to do the task). I can't perform a SQUARE ROOT FUNCTION on a calculator if the key doesn't work. I concluded hp CHOSE-TO-DELIVER -A-KNOWN-DEFECTIVE PRODUCT to me. I expected hp to have recalled known defective product; especially that which was in their stock inventory, and corrected the problems prior to shipment. That is what many reputable companies do. That is why I ordered directly from hp! Having participated in the recall of Defense Material several times, I recognize the magnitude of the problem hp may have. Prior to requesting the RMA, I can not find any statements on hp's web site attributable to from Fred A. Valdez (General Manager, HP Calculator Division) or Lee-Khuan Goh (Director, Worldwide Marketing, HP Calculator Division) of hp's intentions. I also took note of the following in the calculator manual ...Copyright That NOTICE really caught my attention. It caused me to wonder about who else is involved, finance, re-branding, whose designed it, etc. ==== > 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 would like to convert the variables (mainly matrices)I upload from my 49G+ to ascii, so I can import into Excel, or JMP. I downloaded an old DOS program from HPCalc.org for the 48G, but it didn't work (numbers were still in binary format) Does anyone know of a program to convert, once the data is on a PC, or failing that, can I get a detailed file format for variables so I can write my own (probably Visual Basic) program to do it. Of course, I would much prefer the first option! I am running Windows NT and Windows 2000. ==== > I would like to convert the variables (mainly matrices)I upload from > my 49G+ to ascii, so I can import into Excel, or JMP. I downloaded an > old DOS program from HPCalc.org for the 48G, but it didn't work > (numbers were still in binary format) Does anyone know of a program to > convert, once the data is on a PC, or failing that, can I get a > detailed file format for variables so I can write my own (probably > Visual Basic) program to do it. Of course, I would much prefer the > first option! I am running Windows NT and Windows 2000. I've decided to write a pair of programs for my own use to do just that. Well, one to convert to the decompiled and translated format, and the other to translate back and compile. They won't be fancy, just UserRPL with a few SYSEVALs, but they'll do the job. I'll be happy to share them with you and anyone else who wants them. Well, but not on the PC, on the calculator itself which has exactly the right tools to do the job; why make things difficult? But I'm a bit tired and although I'm quite sure of how to go about it, I haven't actually started writing anything yet, and I wouldn't want to let them out until I'm happy with them. So have patience, maybe tomorrow. For now, I expect that putting the object on the stack, and doing ->STR (where -> is the right arrow, character 141) on it to decompile it to the string form, and then storing it in a named variable before uploading it will suffice for what you want. If you download it back to the calculator, it should be a character string. Put it on the stack and do either STR-> or OBJ-> on it to compile it again. Are you using Conn4x to transfer the variables by the Xmodem protocol? Conn4x doesn't work on my PC, so I'm using my SD card and reader to do the transfers. But as long as Conn4x and Xmodem are working correctly, it shouldn't make any difference. -- James ==== > Can anyone tell me if the HP49+'s infrared is downward compatible with > the 48GX? i.e. can we transfer data between a 49+ and a 48GX via > infrared? > > Morgan Although it is hard to believe, it appears HP has not provided the necessary driver support for backwards compatibility. ==== > > Can anyone tell me if the HP49+'s infrared is downward compatible with > > the 48GX? i.e. can we transfer data between a 49+ and a 48GX via > > infrared? NO - you should buy a PC for that (it might be cheaper to buy a 48gII and relay throught it: 49g+ <-> 48gII using IR and 48gII <-> 48GX using serial WARN: I have not tried & fried using above technique. ==== I was looking around today, and I found something I haven't seen before. 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? How do these compare to NiMH or NiCd batteries in terms of battery low warning and how long the batteries last? Lithium-ion batteries are rechargeable about 1000 times, same as NiMH. I am just curious because I have never used such batteries in common sizes as such. Even any general ideas on these cells would be helpful/interesting. (ie. What happens if charged with reverse polarity, or in the wrong charger?). I found these at RadioShack, link: http://www.radioshack.ca/estore/Product.aspx?language=en-CA&product=2318298& category=Lithium-lon+Rechargeable&catalog=RadioShack 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? > The thing to check is there fully charged, leave them stand for 10 minutes, not in anything, rest voltage. 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. 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. Hope this is useful to you and others. Enjoy reading posts to this group. Cameron downunder ==== > I was looking around today, and I found something I haven't seen before. > > 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? > > How do these compare to NiMH or NiCd batteries in terms of battery low > warning and how long the batteries last? Lithium-ion batteries are > rechargeable about 1000 times, same as NiMH. > > I am just curious because I have never used such batteries in common sizes > as such. Even any general ideas on these cells would be > helpful/interesting. (ie. What happens if charged with reverse polarity, > or in the wrong charger?). > > I found these at RadioShack, link: > http://www.radioshack.ca/estore/Product.aspx?language=en-CA&product=2318298&c ategory=Lithium-lon+Rechargeable&catalog=RadioShack > > > Albert Your link was actually for rechargeable NiMH batteries which are designed for a fast 15min charge ability. My previous experience with energizer NiMH batteries in my cd player left me quite happy. Battery low indicator worked about the same. Look into information on self-discharge and voltage for batteries you are considering. Alkaline batteries usually have 1.5v, while NiCD have 1.2v. Sometimes they both work in devices (most things I've used, but not always. A Sega Game Gear wouldn't hardly turn on with NiCD batteries when I tried before due to low voltage. Since the HP calcs have no battery charger port (that I've heard of), you would need to remove batteries to charge them, and if they must be charged daily, weekly, monthly, etc., some poeple will not mind and others will despise of 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. Alkalines generally have an expiration date which helps give some idea of a shelf-life. rayovac claimed 25 yrs that the rechargeable 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. 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... Ed Sutton ==== Group: I am having trouble getting an integral to compute on the hp 49g, the integral is as follows Int(e^(-x)*(1-e^(-x)),x,0,infinity) The answer should be 1/2 but i get overflow errors. My TI voyage 200 does it no problem, does anyone know what the settings should be to get this integral to compute. Rick ==== > Group: > > I am having trouble getting an integral to compute on the hp 49g, the > integral is as follows > > Int(e^(-x)*(1-e^(-x)),x,0,infinity) > > The answer should be 1/2 > > but i get overflow errors. > > My TI voyage 200 does it no problem, does anyone know what the > settings should be to get this integral to compute. You're not computing an integral if you're using INT. You're computing an antiderivative at a given point rather than the area under a curve. There's a difference. Use the Integral symbol (right-shift TAN). Make sure the stack has the following: 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. -- Tom Lake Experience keeps a dear school but fools will learn in no other - Poor Richard's Almanack ==== > > Group: > > > > I am having trouble getting an integral to compute on the hp 49g, the > > integral is as follows > > > > Int(e^(-x)*(1-e^(-x)),x,0,infinity) > > > > The answer should be 1/2 > > > > but i get overflow errors. > > > > My TI voyage 200 does it no problem, does anyone know what the > > settings should be to get this integral to compute. > > You're not computing an integral if you're using INT. You're computing an > antiderivative at a given point rather than the area under a curve. > There's a difference. Use the Integral symbol (right-shift TAN). Make sure > the stack has the following: > > 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. Oh yeah! If you're the person who uses algebraic mode, put the parameters in the parentheses in the same order they go on the stack. Integral-Symbol(0,Infinity-Symbol,'EXP(-X)*(1-EXP(-X)',X) Where Integral-Symbol is right-shift TAN and Infinity-Symbol is left-shift 0 of course. > > -- > Tom Lake > > Experience keeps a dear school but fools will learn in no other - Poor > Richard's Almanack > > ==== > 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 ==== > Group: > > I am having trouble getting an integral to compute on the hp 49g, the > integral is as follows > > Int(e^(-x)*(1-e^(-x)),x,0,infinity) > > The answer should be 1/2 > > but i get overflow errors. I just tried it - it works fine here, in less then a second. How are you calculating the integral? I entered it in the equation writer, and pressed 'EVAL'. I am in 'Exact Mode' - denoted by the equals sign at the top middle of the screen. cheers, Al http://alpage.ath.cx/hptute/ - HP49G+ Tutorials ==== I just got a new 49G+, and thought I read earlier in this NG that somebody had fixed up a user's guide or something with bookmarks. BUT!! I can't find it now. Anyone recall this? G Chapp ==== I belive this is it: http://www.textodigital.jazztel.es/hp49gplus/BPIA5324_CSB.zip > I just got a new 49G+, and thought I read earlier in this NG that somebody > had fixed up a user's guide or something with bookmarks. > > BUT!! I can't find it now. > > Anyone recall this? > > > G Chapp > > ==== > 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! ... Seriously, now, the HP49GII/+ definitely seem to constitue a new low for HP. They definitely deserve the prize for the absolute worst keyboard in the entire history of the industry. A colleague of mine just demonstrated his HP48GII to me: My god, what a piece of garbage! In my whole life I haver never touched a calculator, no matter how cheap, and no matter how old, that had such a ridiculous joke of a lousy keyboard. -- Helen. P.S.: I also have a feeling that the problem is in an interaction of hardware with software. Certain keypresses never seem to register, no matter how hard the key is pressed, and sometimes keypresses are registered twice. The problems are such that I would say that my colleague's calculator is completely unuseable. At least, if I was a student, I would never dare to use a piece of equipment as shoddy and unreliable as this in an exam... ==== You have made your opinions that the keyboard is crap, the screen is crap, HP is the spawn of the devil, etc, etc, known over and over again. There debates are getting very long and boring. Everyone understands your opinions... can we please discuss something else occasionally? Al Who has an electro-mag exam next week, and is not worried about missing keystrokes. ==== > You have made your opinions that the keyboard is crap, the screen is > crap, HP is the spawn of the devil, etc, etc, known over and over again. > There debates are getting very long and boring. Everyone understands > your opinions... can we please discuss something else occasionally? I love my new 49G+, it looks cool, there's nothing wrong with the keyboard, it's *soooo* fast, it's the best thing HP ever made... etc.? I don't see why those of us who disagree shouldn't continue making our opinions known also. -- 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 ==== > > > You have made your opinions that the keyboard is crap, the screen is > > crap, HP is the spawn of the devil, etc, etc, known over and over again. > > > There debates are getting very long and boring. Everyone understands > > your opinions... can we please discuss something else occasionally? > > I love my new 49G+, it looks cool, there's nothing wrong with the > keyboard, it's *soooo* fast, it's the best thing HP ever made... etc.? > I don't see why those of us who disagree shouldn't continue making our > opinions known also. Maybe that came out wrong. All I am saying is that when one person says the same thing over and over and over again, while never mentioning anything else, it gets a little boring. Say whatever you want - it's your right. Al ==== i have a buddy who owns a 48S, and another who owns a 48G. they're both built like bricks, their LCDs don't flicker, their keyboards are really niice, and trying those calcs are pretty much the reason i even thought about buying an HP calculator. so i bought a 49g+. well i can't do much about the keyboard, and i can't do much about the fact that it literally feels like a $11.99 calculator from Wal-Mart (as someone else mentioned), but can we at least request a ROM update to get rid of the LCD flickering? Will HP upgrade the ROM now, due to complaints, or will they update it at their leisure? gc ==== > You have made your opinions that the keyboard is crap, That is not an opinion; it's a fact. > the screen is crap, That the screen flickers is not an opinion, either; it's a fact. Whether or not you find that annoying to the degree indicated above is another question, but it is a deficiency. > HP is the spawn of the devil, Would you like to provide a quote where I said anything even remotely resembling such a statement? Or are you just fantasizing? > There debates are getting very long and boring. Everyone understands > your opinions... can we please discuss something else occasionally? Sure, whatever you want. I'm not keeping you. > Who has an electro-mag exam next week, and is not worried about missing > keystrokes. Good luck; you'll need it, then. Or, just take your time, checking each digit or symbol carefully as you type it in, to make sure it is actually there. Me, I prefer to use a WYTIWYG (what-you-type-is-what-you-get) calculator where I can simply rely on keypresses being actually recognized by the calculator. -- Helen. ==== Oh heck, I have just prolonged the arguement... > > the screen is crap, > > That the screen flickers is not an opinion, either; it's a fact. > Whether or not you find that annoying to the degree indicated above is > another question, but it is a deficiency. I have to agree with you here. I wonder how long it takes for a ROM update to fix it. > > > HP is the spawn of the devil, > > Would you like to provide a quote where I said anything even remotely > resembling such a statement? Or are you just fantasizing? I am amazed that anyone took that comment seriously - I'll add a smiley next time :-) > > Who has an electro-mag exam next week, and is not worried about missing > > keystrokes. > > Good luck; you'll need it, then. Or, just take your time, checking > each digit or symbol carefully as you type it in, to make sure it is > actually there. Me, I prefer to use a WYTIWYG > (what-you-type-is-what-you-get) calculator where I can simply rely on > keypresses being actually recognized by the calculator. For the 234556th time, I am not experienceing these problems to the Al > > -- Helen. ==== Having just brought my 49G+ today I am gutted by the screen flicker. I do not have any menu lines active (ie no clock etc) and still the softmenu flickers. Every time it does so I think piece of crap and get angry. Rinse and repeat and either its shortly going to get thrown through the window or I am going to go and demand a refund. My 48G may not have some of the bells and whistles of the 49G+ but at least I can use it...just my $0.02 - Rod ==== Has anyone experienced any goofy behavior transferring text files between the hp 49g+ and the PC? When I've transfer files to the PC I get a different header HPHP49-C, instead of the old (one which gets transferred from the PC as part of the string, like this %%HP: T(1)A(D)F(.);... When sending to the calculator, I get null characters inserted in front of all the line breaks and a couple of lines from the body of the of the text are copied and appended to the tail of the text string. Any ideas as what is going on? Pretty cheap and crappy behavior in my opinion. The Conn4x is also not without problems, the drivers seem to keep falling off the face of the earth and I have to reloaded them almost every other time I use the most updated version of Conn4x (on a Win 98 SE machine). The USB transfers seem to eat batteries much faster than the old serial ones (serial for breakfast?). Once I got Conn4x working for a while, I was able to flash the ROM just fine. It was very, very fast and a lot less exciting to watch than flashing the 49G. Greg S ==== 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. 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?). > ... No, unfortunately the Owner's Manual for this card doesn't seem to be > available on the Museum's CD set/DVD. But most of it should be available > in the 48G series documentation, especially if you have the Advanced > User's Reference Manual. I'm surprised that the AUR doesn't list the > 'constNAME' variables with the other reserved variables, as it does list > the reserved variables for MINEHUNT. > ==== Yeah, that works too. Somehow, SD cards are not the same as the old SX/GX cards to me--the new stuff does not have all the same feel and flavor as the old. I figured that + took care of the expandability part while giving a connotation of a new era in HP calcs. Greg > > For these main reasons it would have been better to have named this model > > the 49GII and the 49G+ should have been called the 49GII+. Leave it to > the > > marketing boneheads. > You mean 49GX or 49gx+ > eXpandable, you know? > > ==== 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 > > Also, may I add, it looks pretty stupid to see what are > > supposedly engineers dressed like that while doing a field visit (especially > > going someplace that would require safety glasses). Get real! > > Well, you seem destined for a chok when you meet your first real > engineer then :-) > > I'm an EE, and can't count how many times I have been injured in the > field (electrical choks, broken fingers aso.). I'm one of those > engineers who like to get their hands dirty - unless it's dangerous I > have no hesitation jumping in to give the other technicians/workers a > hand. I define dangerous as life threatening (high voltages with no > paramedics around etc.). Hard hat and protected footwear has been my > usual outfit on countless occasions. And I'm only an EE. The advantage > for me has been that I've become good at communicating with the > different technicians (welders, machine operators and other hard hat > guys on a construction site). > > Some engineers never leave their desks, while others are best at home > in the field. I like both, depending on the application. > ==== There are 49g+ in Perth(WA Australia) now. I just got mines yesterday from SurveySoft for $330 AUD. -- Wing Wong. Webpage: http://wing.ucc.asn.au ==== > The ROM for a 49G & 49G+ are different > (ARM9 emulating a Saturn - some native code) Is the emulator code included in the bin now too, with what we usually saw as a Saturn ROM nested inside that code? > It's your calc - you may try to fry it... I plan to take care of my calc if at all possible. I'd just like to get things working, and perhapse have fun developing stuff with/for it in the future. I did manage to get the ROM updated. Installed the Conn4x software on my mom's comp and the USB driver, crashed the driver out of memory. reinstalled the Conn4x software, updated the USB driver from HP's website, and eventually managed to made the flakey status work out so that ROM 1.22 would transfer. I think that I would have been better off acquiring a memory card and using that to update after sending the update with linux through the calc to the card. Now the bottom screen blinking is present. Clock seems to blink more irratically, and wether or not it was noticeable before, I now notice that the cursor blinks irratically too. If I remember right, the click's blinking wasn't always all that bad when on a screen without other activities such as a blinking cursor. Ed Sutton ==== > > The ROM for a 49G & 49G+ are different > > (ARM9 emulating a Saturn - some native code) > Is the emulator code included in the bin now too, with what we > usually saw as a Saturn ROM nested inside that code? The 49g+ have some native code in it's standard OS routines So the emulation is not pure. The emulator seems to be vastly improved over HP Yorke calc.exe or the EMU48 (for CE) and different in many respects. Note that HW has changed a lot! The 49g+ ROM is different enough to *not* to run on any PC or PDA emulator and vice versa. Forget about it ==== > Apparently, this module doesn't exist in 2.4. It is still experimental > in 2.6, actually. Maybe you can try on 2.4 without, but I doubt it will > work. 2.6 is quite stable now (I'm using it since 2.5.75 without real > trouble), you should try if you have the prerequisite (read > Documentation/Changes). As you know, I'm not a specialist about linux. However, I think safe_serial exists in the 2.4, since I was able to load it and I am using a 2.4 kernel. Yoann. ==== > As you know, I'm not a specialist about linux. However, I think > safe_serial exists in the 2.4, since I was able to load it and I am > using a 2.4 kernel. In Linus's vanilla kernel (actualy Marcelo's :) it does not ! # head Makefile VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 23 EXTRAVERSION = -pre9 # find . -name *usbserial* -print ./include/linux/modules/usbserial.stamp ./include/linux/modules/usbserial.ver ./drivers/usb/serial/usbserial.c ./drivers/usb/serial/usbserial.o # # find . -name *safe* -print # Some distro might have patched kernel though .. > Yoann. -- 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 ... ==== I've read a post about transfering between HP49g+ and 48SX. Wolfgang was talking about his IOMAN library, which exists for 49g+. However, even using that library on the 49g+ I have for testing, I wasn't able to transfer with a 48GX calculator. Another annoying problem : trying to probe the IR port of the 49g+, I used some assembly programs which detect data on the IR port. And both in Red Eye mode, or RS232C-IR configuration, nothing was ever able to detect a single bit of IR received. Although the IO RAM configuration about wire RS232 doesn't seem to have changed, as shows the analysis of the Xmodem internal calls, thanks to Nosy, the one of the InfraRed transmission must have been quite modified. Yoann. ==== > > I've read a post about transfering between HP49g+ and 48SX. Wolfgang > was talking about his IOMAN library, which exists for 49g+. > However, even using that library on the 49g+ I have for testing, I > wasn't able to transfer with a 48GX calculator. X To be sure, I set on both my 48GX and my 49g+ 2400 BAUD and then did IR transfer in both Kermit & XMODEM no luck! I even put the 49g+ upside down - just in case the IR was reversed that is: the sender & receiver would be upside-down and tested again with no luck PS: IR printer works and no - I did not try printing to 48GX ==== > I've seen speculation but no announcements of success (nor do I have one yet > to try out myself)... has anyone managed to program ARM code directly on > the HP49G+? As far as I know, except HP developers, no one has reported to having been able to program in native ARM on the 49g+. Yoann. ==== > > JKH confirmed that the Display-off command (dashed D in OT49+) does not > > work on the 49+ anymore. It contains the following ASM-code: > > GOSBVL SAVPTR > > GOSBVL DispOff > > GOVLNG GETPTRLOOP > > > > DispOff was used as a very dirty trick to have a slight speed gain. > This will have no effect whatsoever on the 49G+ > > Hence, he simply killed the supported pointer DispOff. Thus, nearly the > entire section SOUND on hpcalc.org is unusable on the 49+. Are JYA and > CdB really that unmusical? Did they never realize that DispOff didn't > serve speed-up but improving the sound quality? MIG-performances are in > asm and speed doesn't play any role. Only sound quality is what counts. > Interesting which other supported SysRPL or asm pointers they killed. > Backward-compatibility? Forget about it! > > - Wolfgang Is it worse that a supported entry point was removed, or that backwards compatibility was broken despite that the entry, in the words of Wolfgang's JYA's quote, ...will have no effect whatsoever on the 49G+. I assume that was meant to mean that implementing DispOff would have no effect performance or otherwise, rather than it wouldn't have an effect on backwards compatibility or wouldn't have an effect if it was still called. Is that correct, or is there more to this than I see? Ed Sutton ==== > Another broken link (problems with my keyboard :) > http://www.hp-sources.com/SoftsHP/jeux/arcade/TRONGR.ZIP Well, that's a nice game. I've played a little with it, and I achieved a high-score of about 450... :-) I congratulate you about the way you programmed it ! Yoann. ==== Merci msieur :o) It's cool to program again. Yoann Desir a .8ecrit dans le message de > > > Another broken link (problems with my keyboard :) > > http://www.hp-sources.com/SoftsHP/jeux/arcade/TRONGR.ZIP > > Well, that's a nice game. > I've played a little with it, and I achieved a high-score of about 450... :-) > > I congratulate you about the way you programmed it ! > > > Yoann. ==== > where can I order it? > > -JP Sorry, should have added links to my last message: Samson Cables - http://www.hpcalculators.com or alternatively from http://commerce.hpcalc.org/ or perhaps from HP (USA) directly at http://h30094.www3.hp.com/product.asp?sku=2407085 I couldn't find a listing for it on HP Canada's commerce site. Good luck, Mike Mander ==== > where can I order it? > > -JP I live in Vancouver, BC and about 2 weeks ago I phoned the BCIT, SFU and UBC bookstores as well as a few specialty electronics retailers that have traditionally sold HP calculators. No one had even heard of the 49g+ yet. One person even thought I was making it up and kept insisting that I must mean the discontinued 49G. After some digging, the BCIT store found a listing and said it would be $270 but had no idea how long it would take to order one in. The person seemed hesitant to try to find out and didn't seem all that interested in helping me. I gave up and ordered mine from Samson Cables in the U.S. Still waiting to receive it though, but customs can slow things down a lot. Mike Mander ==== > I notice that the red IR cover on the 49G+ has a convex outer surface. > Would this have the effect of spreading the IR beam, thus > attenuating it and shortening its range? > > An interesting experiment would be to compare performance with & > without the IR cover. > > Might a deliberately reduced IR range be an effort to regain > acceptance for use in professional exams? > > Just wondering . . . That's (almost) exactly what I've had in mind. I'd stand a better chance of storing notes, programs, etc. into my calculator to help me pass a test than I would of talking to other calcs in the class to acquire better answers; even if all of the TI calcs, my HP(s), and those occasional casio and other calcs could all talk together at the same time across the entire room. Not needing a cable for calc<->calc transfers can be nice, but I don't have much experience with such links to konw what I think of their overall quality vs. a cable setup. For my IR use, Id omst of all really like to be able to use the calc as a fancy & powerful universal remote. As for the experiment, taking measurements of IR energy at given distances straight in front of the calc, vs. off to the sides and at varying heights, all with a variety of angles at each change would be interesting. The results could then be followed up with the IR cover being removed and running the same tests; showing if is redistributing the output, refocusing the input, and perhapse if it is also filtering the IR signals to lower levels on the input and/or output. Perhapse good results could lead to an approiximate radiation pattern for the port too. =) I've heard of the thoughts of teachers fearing cheating possibilities because of IR ports in the past, but has that actually occured at all in the past. if yes, how much? Ed Sutton ==== > sentence. 'Standard USB'...do I get a cookie? > The PC of the future doesn't have serial ports and a far bigger group > of users will connect 49g+ to PCs than anything else. Do the others come with calc<->pc cables and come with the need of a ROM update out of the box? > No one has mentioned using a PDA as a serial collection device - they > are cheap, programmable in high-level languages, and have lots of > memory, etc. compared to HP calculators - why not use a PDA? > Pete M. Wilson > Gamewood, Inc. > wilsonpm@gamewood.net My dad's 'new' PocketPC at $450 or so has 64mb of ram. Not that those are the only PDAs, but it is one example of many. He needs it for phonebook, memos, appointments, etc. and all in a light pocket device with a backlit screen. As it stands, I've set him up with HP emulators on it since his main complaint is that it doesn't come with a very powerful calculator, and that at least filled the power gap. For me, graphing calcs fill my need much better than any PDA I've seen, including my dad's old PocketPC, which he gave to me (64mb ram compaq ipaq 3765), and spending a 'little' extra $$$ on a mem card would push the usable memory of my calculator far beyond what PDA owners I know have in their units. So anyone found figured out any fun things that having a calc and PDA talking can do. IR data transfer, a sort of a hub to have both connected to a PC all through one link, or using one or another as an IR repeater are what I've thought could be fun to try to do in the future. Ed Sutton ==== > > >>But why not keep the industry standard RS-232? Was there any real need >>to invent some new incarnation of RS-232 specific to the 48gII? Or to >>eliminate RS-232 from the 49g+? > > > sentence. > > The PC of the future doesn't have serial ports and a far bigger group > of users will connect 49g+ to PCs than anything else. First off, I guess you missed this paragraph: I applaud adding the USB client port (although I do wish that the USB driver and Conn4x combination worked with my PC), but I think that not also keeping the RS-232 port was a mistake. Uploading to and downloading from a computer isn't the only thing that RS-232 on the old 48 series is used for. USB is great for connecting to a suitably equipped PC, but not for connecting to other devices. Second, I guess that by industry, you mean just the PC and common PC peripherals industry. Yes, they are indeed rapidly going to USB, which is very well suited for them. But I wish that they'd keep an RS-232 port or two. But even if the PC doesn't come equipped with RS-232, it should be cheap and easy enough to add a serial I/O card. If you have a computer such as a laptop that you can't add a card to, USB to RS-232 converters are available at a low cost. So connecting any RS-232 device to just about any computer shouldn't be any real problem. USB is very unsuitable for devices that are intended for connection to anything other than a computer. RS-232 is clearly very superior to USB for these devices. To be sure, the calculator may be connected to the computer at times, but most often it's not connected to anything at all, and in the older 48 series, it's often connected to other devices. But the USB on the 49g+ is useful only for connecting to a USB host. In my opinion, RS-232 is alive and well and likely to be in use for a very long time. Just what advantage other than speed does USB offer over RS-232 for connecting two devices to each other? Oh well, maybe if I buy an IrDA to RS-232 converter, I might be able to connect the 49g+ to RS-232 devices. > No one has mentioned using a PDA as a serial collection device - they > are cheap, programmable in high-level languages, and have lots of > memory, etc. compared to HP calculators - why not use a PDA? Data collectors are hardly the only reason for connecting a calculator to something other than a computer. I don't know much about PDAs, but they generally seem to lack a decent keyboard, I very much doubt that they're programmable in RPL, I doubt that they have the mathematical functions I'd like, and with the SD card, I doubt that I'll run out of memory real soon. But on the other hand, with a good emulator with a 48G ROM on it, a PDA type device does have some advantage over a real calculator. -- James ==== > > > > sentence. > > > >Second, I guess that by industry, you mean just the PC and common PC >peripherals industry. 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. Pete M. Wilson Gamewood, Inc. wilsonpm@gamewood.net ==== > > >> >>>sentence. >>> >> >>Second, I guess that by industry, you mean just the PC and common PC >>peripherals industry. > > > 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. 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. -- James ==== > Moving the RS232 adaptor chip (that uses quite a lot of power) in the cable > and powering it from the PC is common practice Not in my experience. I have perhaps twenty different handheld devices with serial ports, and only some of the ones from HP, such as the HP-94 and HP 48GII have done this. > (this is BTW the way your mouse gets powered) My mice are powered by either USB and PS/2 ports. You are, of course, correct in that serial mice (fortunately a dying breed) were powered from the serial port. However, this is substantially different from a communications application, in that the baud rate was very low, 1200 or 2400 bps, IIRC. And even then, it sometimes caused problems if the mice were used on a long serial extension cable. > and saves a lot of power from the device. Irrelevant. If an external transceiver can be wired to steal power from the EIA-232 signals, an internal transceiver can be wired in exactly the same way. There's not any special magic in this that only allows it to be done when built into a cable. > Also, doing so allows to reduce risks of destruction of the final device > (cable is cheaper than the calc). It doesn't do that either. EIA-232 transceiver chips (such as the Maxim MAX23x and MAX32xx) are designed with a great deal of built-in ESD protection. CMOS logic-level I/O in processor chips have some ESD protection, but nowhere near as much as the EIA-232 transceivers, because it is not expected that they will be directly exposed to the outside world. If you just bring out the CMOS logic level UART I/O pins to a connector, even with some discrete transorbs (or equivalent), the port is likely to be much more susceptible to damage than if the transceiver was built in. Maybe there were good reasons for putting the transceiver in the cable, but you haven't stated any. Eric ==== > > > >>1. Is HP going even more proprietary than it has in the past i.e >>during the days of the HP41 series? HP-IL etc. >>The kulge with the cable for the 48gII. One now can not just build >>their own ant longer. Are they going to come out with an expensive HP >>only accessory to accomplish what is missing? > > > Actually, this is a pretty common practice (the 2 PDA I have with RS232 > cable do that) > > All CPU and similar that you can see around and that claim to 'support' > RS232 in fact support the protocol, but not the signal strenght (they work > in 0/3.3 v only, which is not a normal RS232 level, but much easier to > acheive on a 3.3V powered IC. If I recall correctly, this is just about the signal level from the 48SX, 48GX, and 49G. I'm well aware that it's below the minimum that RS-232 specifies, but it seems to have worked quite well for a lot of users for well over a decade. Have there been many complaints about the low signal level? > Moving the RS232 adaptor chip (that uses quite a lot of power) in the cable > and powering it from the PC is common practice (this is BTW the way your > mouse gets powered) The mouse that I'm using now isn't RS-232 to start with, and what else besides a PC would I want to connect my mouse to anyway? > and saves a lot of power from the device. I hadn't noticed that the life of the batteries in the other calculators was particularly short, and I do use the serial port fairly often. Of course, the power has to come from somewhere, and if not the calculator, then from the other device. Ok if you're connecting to a PC, but what if the other device also runs on batteries, or worse yet, like the calculator, doesn't supply power where you expect to find it? > Also, doing so allows to reduce risks of destruction of the final device Have there been many cases of the calculators (with the possible exception of the defective early 49Gs) being destroyed by power coming into them through the RS-232 port? > (cable is cheaper than the calc). How much cheaper? For the end user who needs to purchase one, that is. Is it the same cable used on some other devices, or is it HP only? > BTW, you should be able to connect 2 calcs with the RS232 using a hand made > cable without any electronics in it. You might even discover that you can > connect with a lot of devices without the adaptor circuitry... However, > this is not the RS232 standard. That's good news. Without the cable, can it still stand up to a maximum strength standard RS-232 signal coming in? How about overvoltages? But I admit that I don't know just how much the previous calculators could take; I never attempted to test one to destruction. >>2. The fact that the 49G+ can only be a USB client and not a >>USB server that according to some knowledgeable people who contribute >>to the discussions on this group, the hardware is available to have >>two USB ports on the calculator. Again is an expensive HP only >>accessory in the wings that allows two way USB communications for the >>49G+?. > > > Ok, let us speculate that there is a USB host on the HP49G+: > - Where does the power come from? remember, USB is suposed to provide up to > 500mA for the periferials. at 800mAH of power on a standard AAA, how long > will the calcualtor battery last? I'd pretty much ruled a USB host on the calculator based on the requirement for drivers, and hadn't even thought of this issue, although I had been thinking that the 500mA that my card reader supposedly requires seems like a lot of current. So just on the power requirement, a USB host on the calculator is ruled out short of going to an external power source. But an external power source opens up a whole can of worms with some people using the wrong power source, problems with keeping the external power from feeding into the batteries without requiring disconnecting them and wasting battery power in the protection circuits.... > - Where does the drivers come from? USB clients need drivers to be installed > on the calcaultor in order to work. I imagine that HP will have NO problems > whatsoever to get EVERY USB device manufacturer to create the drivers for > the HP49G+ calcualtor! After all, aren't they all already doing Windows, Mac > drivers? 49g+ might have an opinion on how much fun it is. And the Mac users... well I guess sometimes they're just plain S.O.L. unless they can make do with something designed for a Microsoft O.S. Of course, S.O.L. often describes us MS-Windows users quite well. And with a calculator as a USB host, I expect that it's users would be very much S.O.L. for drivers. I wish it were feasible, but if wishes were horses, guess what we'd be up to our necks in. The USB client on the calculator is wonderful for connecting it to suitably equipped PCs, but not good for much, if anything, else. Would it have been all that hard to keep an RS-232 port on the 49g+ for all those other uses? -- James ==== >> Heh? >> I have Sony G220 and it works fine with it's USB hub ! > with your 49g+ that is? Yes ! I even managed (just yesterday :) to get following combo working fine -> Sony G220 USB Hub <-> Bandridge USB2Serial <-> HP49G (an old one :) ps keyboard is HORRIBLE in HP49G+, everything else is quite nice pps today on the menu is connecting linux with HP49G+ :) -- 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 ... ==== > > >> Heh? > >> I have Sony G220 and it works fine with it's USB hub ! > > > with your 49g+ that is? > > Yes ! It now works on my WinXP Pro/PC [MSI 845E Max2 BLR] I have installed the USB device to every port on my Sony Trouble was a disconnected/non-functional USB bracket. I used the other one and everything went OK ==== I've had to re-load the Conn4x USB drivers a few times on my Win 98 SE machine. Once I was having problems and I went to IOPAR page of << 104 MENU >> and made sure it was set on wire transfer, and it worked. Greg S > > > > > I don't know if this has been solved yet, but try to COPY your file to > > be transfered from an open window and then PASTE into the Conn4x > > window. > > It works for me. > > Conn4x and using the SD card and reader for file transfers instead. If > and when I see a new version of the USB driver or Conn4x available, Ill > try again with Conn4x. > > -- > James > ==== > I posted this originally in the TI-89/92+/V200 discussion group. I'm > posting this here also, in case Dr. Parisse or someone else can > explain this. > > I'm curious: Isn't it possible to factor a (univariate) polynomial > modulo a composite integer? I know one can find roots mod a composite > integer by finding roots mod each of its constituent primes and then > using Hensel lifting (to make the roots correct mod p^k) followed by > the Chinese Remainder algorithm, but how would one find the > multiplicities? > hmm, actually it is possible to lift a root of a polynomial from Z/p to Z/p^k, but not with different primes. For example P:=x^7+x^3+1 has one root modulo 17 but none modulo 11. The same happens for higher order factors. This is used to compute a table of possible degrees for factors in factoring programs using distinct degree factorization and a few primes. > Am I missing something obvious? > > Also, as an add-on to my original post, is it possible to determine > how many roots a polynomial should have modulo an integer p (possibly > composite) without doing the actual factorization? > Yes, for example using xcas P:=x^7+x^3+1; p:=11; gcd(P%p,(x^p-x)%p) p:=17; gcd(P%p,(x^p-x)%p); On the 49 x^7+x^3+1 STO> P MODSTO(11) GCDMOD(P,X^11-X) MODSTO(17) GCDMOD(P,X^17-X) Hmmm, it is probably a bit harder to test this on the TI89, maybe using mathtool? ==== Why dont HP just add two new flags to 49g+ Flag1: Automatic mode switch On/Off Flag:2: Automasic restore of mode On/oFF I'm 100% sure this would give us a more peacefull world and a lot better calculators! :-) Torstein > >You are right about the out-of-control situation >that evolved one-more-time. It seems as though >there are people in this newsgroup that are >fanatics to an insane degree (like myself) for >no essential reason at all! >We need more love in our lives! People who get >obsessed about things with extreme points of view >and aggressive attitude are usually those with >a deprived balanced sexual life, proponents of >conservatism and against radical social changes. >Let us embrace all oneanother, men and women, kiss >affectionately one another, irrespectively of sex >(yes), color, and social beliefs. Let us put aside >the poisons that wel call religion and politics and >focus on the sexual animal that we call man! Then and >only then shall we realize a better and class-less world. >Besides, it is absolutely meaningless trying >to kill all TI-borgs since there are so many of them :-) > >!Demeter! ==== > > Why dont HP just add two new flags to 49g+ > Flag1: Automatic mode switch On/Off > Flag:2: Automasic restore of mode On/oFF > > I'm 100% sure this would give us a more peacefull world and a lot > better calculators! :-) > > Torstein I am surprised that you bothered to answer to this humorous and semi-frenetic posting of mine about world peace thru hardcore sex with any stranger! Well, seriously now :-), if HP wants to improve the new test machine they got out of the cage (HP49G+) they had better fix first the ALARMS screw up that happens at turn-on (on occasions)and the corresponding freezing (they coincide some times). The addition of new flags is secondary. The next best thing would be the handling of improper integrals and the support for the dirac delta function in calculus (to do my impulse response functions). Lastly they should disclose all relevant information to the emulator and the ARM architecture so that the senior programmers of this HOLY group may make use of them for better, faster and NEW programs. I love all TI-borgs. They become so cute when teased! !Demeter! ==== > I love all TI-borgs. They become so cute when teased! Hmm, I've never thought of myself as cute :-) -- Bhuvanesh ==== > > > Why dont HP just add two new flags to 49g+ > Flag1: Automatic mode switch On/Off > Flag:2: Automasic restore of mode On/oFF X Only a few flag positions remain free... Flag1 above -123: Allow/Forb. Switch Mode Flag2 should never be needed. The user settings should stay! This is how it was before and always has been! As I have told repeatedly here, the solution is: 1) save the flags that CAS may change 2) CAS processing...(flags may change) 3) restore the saved flags 4) display results ==== >> >> >> Why dont HP just add two new flags to 49g+ >> Flag1: Automatic mode switch On/Off >> Flag:2: Automasic restore of mode On/oFF >X >Only a few flag positions remain free... >Flag1 above >-123: Allow/Forb. Switch Mode >Flag2 >should never be needed. The user settings should stay! >This is how it was before and always has been! >As I have told repeatedly here, the solution is: >1) save the flags that CAS may change >2) CAS processing...(flags may change) >3) restore the saved flags >4) display results > I feel there should be some kind of indication on the answer if the calc had change mode. Or perhaps that is obvious from the answer given..... 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! Olaf ==== OK then, my local supplier now has the 49G+ in stock and I wonder if I should order one? What connectivity issues are there with this beastie, bearing in mind problems with battery life and units being DOA...are these resolved with the v1.22 ROM? JasonG ==== I have had no problem with the new connect4 posted on the HP site. Just follow the directions of some early users of the machine in a month back postings on how to connect to the USB PC side. The SD works OK for normal operations using a 64MB card (only 8.3 names). The ALARMS are screwed up sometimes upon turning the machine on and sometimes it freezes too, again after turn on. It is really fast, about 2 to 2.5 times faster for FOR loops computing floating values of trig and polynomial functions, and about 5 to 7 times faster plotting from the stack with AUTO and DRAW on trig and polynomial functions again. The BEEPER is a bit down (quiet). I hope all these things will be fixed with the next ROM > 1.22. Go ahead and buy it and join the world in beta testing this expensive and wonderful crapy machine! !Demeter! ==== Hola! > > I have had no problem with the new connect4 posted on > the HP site. Just follow the directions of some early > users of the machine in a month back postings on how > to connect to the USB PC side. The SD works OK for normal > operations using a 64MB card (only 8.3 names). The ALARMS > are screwed up sometimes upon turning the machine on and > sometimes it freezes too, again after turn on. The machine freezes? That really doesn't sound too good. :-( > It is really fast, about 2 to 2.5 times faster for FOR loops computing > floating values of trig and polynomial functions, and about > 5 to 7 times faster plotting from the stack with AUTO and > DRAW on trig and polynomial functions again. The BEEPER is > a bit down (quiet). I hope all these things will be fixed > with the next ROM > 1.22. > Go ahead and buy it and join the world in beta testing this > expensive and wonderful crapy machine! > > > !Demeter! Hmm, seems that HP have avoided the cost of actually doing proper testing on their products again...I'll have to think carefully about buying one now. :-/ JasonG ==== > >OK then, my local supplier now has the 49G+ in stock and I wonder if I >should order one? > >What connectivity issues are there with this beastie, bearing in mind >problems with battery life and units being DOA...are these resolved with >the v1.22 ROM? > > >JasonG The battery issue is solved in 1.22. (The DOA issue was really the same thing. ) Olaf ==== I have just replaced my old HP32S with an HP48G. Now, after a little testing and typing and reading the manual I have 2 questions about the HP48G. My HP32S always used digit separators. I could choose between , and . as fraction mark: 3.800.000,5 or 3,800,000.5 The HP48G uses digit separators only in the fixed mode but not in standard or scientific mode: 3800000,5 or 3800000.5 the use of digit separators helps me to see the number with one view without counting digits ;-) Is ist possible to change this ? To put a number in memory was more easy with the HP32S. I pressed STO + A...Z and the number was stored. Restore was as easy as this, i have just pressed RCL + A...Z. This is more complicated on the HP48G. Can this be changed ? Many thanks for your answer Christoph Deppe dc1ecd@darc.de ==== Where can i also upload it? othe webpages? ==== I guess from the serial number. Mine has keyboard issues and is CN33109553. > How can you tell? > > > > > Is your model one of the earlier ones? > > > > dave > > > > > Just got it and was surprised at how cheap the thing feels. Much worse > > than > > > the TI's. Think $11.99 Walmart special. Really quite lame. Worst of all > my > > 7 > > > key only works about 1/3 of the time. > > > > > > Construction issues aside, it's a powerful tool, but I doubt it will > last > > me > > > 14 years like my 48GX has. > > > > > > > > > > > > Does anyone know of a program to produce Jacobian matrices? > > > > > > > > > > > > > > > > > > > > ==== 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. Then, on the 48 and 49 serie, HP decided to put the shift keys on the left and move the operators to the rigth side while the shift keys were on the row above the ENTER key on the 65 and the 67, for example. Even the 41C have its gold shift key over the ENTER key. This placement makes for a less than perfect view of the operator keys if you, like me type with one or two fingers on the numeric keys. That way, the rest of my hand is over the arithmetic operator keys and obscure these. Of course, after zillion of hours of use I no longer have to see them but it help a bit. So I am just asking why such a move ? Then, another consideration. On the same models as before, i.e. from the 35 to the 41 included, the operators are, from top to bottom: -, +, x and Ö. Then, on the 48 and 49 they are, from top to bottom: Ö, x, - and +. So I am just asking why such a change ? This post is here just in case HP people read this newsgroup and find such observations of some value. And maybe some experts can give some clue about what dictated these changes. Jean (Johnny) Lemire from Richelieu, Quebec, Canada ==== You can't really compare these directly in the way that you want. It is correct to say that, in general, assembly is faster than sysrpl, and sysrpl is faster than userrpl, but as far as quantifying the difference in speed, you can't really do that. The speed increase will depend on the implementation and how clever you are with your code. Let us just say: your results may vary ;-) Aaron > > >>The only relevant difference (as far as speeds concerned) between user and >>sysrpl is that the former conducts error checking on function arguments. >>Therefore if your program makes many calls to functions you will notice a >>good speed increase. >>IMO it is worth the effort to learn SysRPL, especially if you already know >>UserRPL. The Kalinowski/Carsten manual is all you really need, and Debug4x >>allows fast, easy and safe compiling on the PC. >> >>dave >> >> > > Do you have comparison feedback on SysRPL vs ASM too? >Ed Sutton > > ==== 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 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. ==== > Can someone explain why telephones (touch tone) have the following layout: ... > While calculators and numeric keypads on computers keyboards have: ... > Why not use the same on both ? > Of course I am just talking about numeric keys. > Jean (Johnny) Lemire from Richelieu, Quebec, Canada. Here is probably the best answer you'll be able to find: Josh -- -Joshua Belsky jjbelsky@yahoo.com http://belsky.net ==== > If someone Want information and put it in a web then write me. > It works perfectly. > Bye It seems like there would be a lot of demand for a product like this. People who program the calculator, along with people who just want to take notes in class on it, would buy such a thing. A smart company which is responsive to its customers might actually make such a product for its calculators. Hey! TI makes a keyboard for its calculators!!! -Josh -- -Joshua Belsky jjbelsky@yahoo.com http://belsky.net ==== Excuse me, but don't imagine a cool Keyboard, it is a cheap handmade keyboard more focused to people that want to create things and for those who have a functioning calc but with a non functioning keyboard, it is possible to create one better by rs232, but I just wanted to create something special and not done. Bye. ==== > If someone Want information and put it in a web then write me. > It works perfectly. > > Bye Sounds cool. Unfortunately, HP has discontinued the 48GX. ==== > Sounds cool. Unfortunately, HP has discontinued the 48GX. Yes, but there are still plenty of 48 GX users out there. Well done. Post some more details. How did you do it. I use an older 48 sx, so no value to me, but I think it should be findable in this newsgroup for other 48 gx users as an option. Cameron downunder. ==== bo3nmq$31n$1@avanie.enst.fr... > qu'il r.8epond... Vous a-t-il r.8epondu ? La traduction reste toujours aussi foireuse. :-) Je me demande quand cette superbe machine contenant Un syst.8fme d'alg.8fbre d'ordinateur (CAS) ins.8er.8e d.8evelopp.8e haut pour manipulation symbolique future et solution progressive sera r.8eellement dispo en France. A priori, il semble qu'elle n'est pas pr.8evue dans les FNAC pour le moment... Gilles ==== > Please comment on the following: > 1) Keyboard problems! > sticky, dropped keystrokes, etc Problem keys: 4, SPC & F4 > 2) Paint chipping None > 3) General observations Serial #: CN33108966 Internal Serial # CN33208786 (FWIW, #C4002h FLASHEVAL got that on my v. 1.22 -- proceed at your own risk!) Upgrade to ROM 1.22 with Connectivity Kit from Win 2000 went fine. 16Mb SD card (from my HP digital camera) went in without a hitch, though shows only ~13Mb. Today it woke up dead -- replaced batteries & it's fine. (Did I need new batts after only ~10 days of intermittent use?) (I have been carrying it in a soft leather valise, so perhaps it had a key pressed continuously for a long time, or some such.) I added some textured stick-on vinyl non-skid (from the boat store) to the sides & back to keep it from sliding out of my hand. (Had previously done same to my Ovation guitar -- too many smooth, curvy, slidy things being made!) Overall -- very nice, fun to play with, MUCH easier to connect to computer, scads of cheap storage -- too bad about the iffy keys! ==== ^^^^^^^^^^^^^^ > > seconds on the 49, compared to 10.9 seconds on the 49+. I presume it'll > > take about a minute on the 48gx. > > I inverted a {10. 10.} RANM => 1 digit INV => 12 digits > {INV}HEAD MEM ; TEVAL > in 2.04 seconds (with LASTARG and Last Stack on) RANM is different from HILBERT, the later is usually worse. Michael -- -= Michael Hoppe , =------ ==== http://www.hp-sources.com/hp49plus/Softs49Gplus/TronGR11.zip ==== > > Well, son, [...] Son.... lol > I guess we both know why that is. > I dont have all day to post on usenet... thats why. This discussion is going nowhere... As much as i now see that i havent mentioned to many reasons about my thinking of 49g series superiority, I also see that your reasons for liking TI are even fewer. I will go at some points i just love in the 49g series, most of them lacking in any TI. -RPN. Ive said it before ill say it again. It rules. Youve said it only saves a few keystrokes (thats true...) but theres actually much more to it. Benefits to the User (me): Besides few keystrokes, it totally leaves out the order of operations (perhaps not totally, but mostly) making it easier to avoid doubts and use of unneeded parenthesis. Results are kept on the stack easier (avoids uncomfortable hist command)and its logical... what i mean is that it uses a different logic and that implies lots of benefits (at least for me) like the ones i mentioned. I could just go on and on and on and on... Benefits to the machine: Well, ive mentioned that RPN makes calculations faster... and its true. THe calculator can indeed process RPN data faster. Why?? WEll, theres no need to analyze order of operations, and no need to follow parenthesis. Those are just the obvious reasons. THere are MANY more. -Programming. User RPL System RPL mainly. Designed specifically for the use of a calculator, meaning it works great even with limited resources. Programs in these languages are small and can be executed faster with limited energy, RAM and processing power. Designed for use with RPN (mentioned above). Even smaller programs.. take pythagoras theorem, a program that calculates the hypothenuse in a right triangle (its called a right triangle right?? [english isnt my first language]) << SQ SWAP SQ + v/ >> v/--> square root symbol What could be simpler?? THe use of stack manipulation requires the use of less or no variables in most programs. THat implies faster programs. 3 different programing languages, each with its own benefits... USer RPL simple language, quite powerfull, handles many different things, perfect for simple programs or peeps (Bhuv, your right, peeps is an abbrev for people) who dont want to dedicate to much time to learning. System RPL. Extremely powerfull, adds to the speed of User RPL, Has quite a load of usefull documentation helping to learn the language. Many specialized tools ease the task of programming. Assembly. Dont know to much bout it... just hear its pretty damn fast. As for programming thats all im saying... im sure many other people can say A LOT more. -Flags. Allows for further customization, for beginners they can be left untouched harmlessly, for more experienced users, they allow pretty much anything to work as desired. Allows for easier more custimized input (example: system flag 117, soft menu--choose box, i love soft menus cant stand choose boxes). Hundresds of flags cover hundreds of things. -Hardware. Keyboard... not a strong point.. Screen.. sucks... But besides those crappy things, its not bad at all. Batteries last quite a long time, for 49g a very long time (dont know about 49g+). Its fast and reliable. 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. -RAM. 512 is quite a lot. More then I need now. Of course its nothing TO awesome. Well, im out of time. I could go on endlessly of i had the time. Hell, i didnt have a chance to mention software, which happens to be incredible. > -- Helen. -- Eddy. ==== >C programming is more powerful in my opinion. Of course, we're >entitled to our own opinions :-) It depends on your definition of powerful. As both languages, RPL and C are turing complete, there is, principally spoken, no problem, which one of the languages can solve and the other not. In these terms neither language is more powerful then the other. 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. Pure C is then one of the lessest powerfull languages (only assembler is still worse), only with heavy use of libraries (and in case of the TI calcs ROM calls) C can be considered usefull to some extend. It is is no coincidence, that C is more and more displaced by other, according to the above definition, more powerful languages for big programming projects (C++, Java, C#/.NET [ok, in future maybe]). Time and so Line of Codes are pure money..;). I have once heard, most of the self written code of companies is written in VB/COM for the sake of saving time. A third consideration concerning Programming language power takes the time into account, which you need to solve a problem with a specific language. Now this is highly subjective, as the programming experience and knowlegde of the language plays the major role here. Mathias -- Mathias Habel mathias.habel_no-spam_@t-online.de Remove _no-spam_ before replying ==== >Well, one might think that if my students' TIs can handle what they >need in their classes, they should certainly be sufficient for the >needs of 10th-grade high-school physics. Otherwise, you are more than >welcome to show us at least one of these wondrous things you can do >with your 49G that presumably cannot be done on a TI89. Now, thats easy, if you mean out of the box. Simply calculate 2^9999: it gives infinite on my V200 and a number with 3010 places on my HP49G+. A second problem: TIBasic can only do ca. 100 repeating sub routine jumps, which make recursive programming a klugde. As compensation loops in TIBasic define a new class of slowness. Yes I know, you can program it in C, but therefore you need a PC, which is not always at hand, e. g. generally outside your home. Simply put: TIBasic is too slow for more than some example scripts. In my opinion, this is one of the greatest disadvantages of the TI, it makes the to some extend useless outside the school. Another problem: The unit conversion system on the TI is by far not as advanced as on a HP. Simply try to convert 1_St into its corresponding basic SI units on a TI. My HP gave me 0.0001m^2/s. Mathias -- Mathias Habel mathias.habel_no-spam_@t-online.de Remove _no-spam_ before replying ==== > > As a matter of fact, the two are pretty much functionally > > equivalent... well, as far as the CAS goes. One sore point is > > numerical linear algebra, but that should get better in a few months. > > Hah! Can you expand on that? -- Helen 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. If you meant the functional equivalence, that would be a very long post and would still gloss over some things, but I can write something up and post it if there's enough interest. -- Bhuvanesh ==== > As I said, I am short on time right now, and we did have quite a bit > of a discussion on this before. There is no need to rehash that, but > the gist of it was that I believe that it is not only physicists that > the 49G does not offer a good value for. The best evidence is the > market success of this calculator, or rather the total lack of same. > I would never say that market success is a best evidence for any technical superiority. There are many many examples of the contrary. Price, habits are much more important. This explains also that the 49G was successfull for example in Spain. >>See above about context. And maxima can interrupt a computation >>and ask whether a variable is positive, that's similar to a mode >>switch question. > > > No, it is entirely different: you are not changing, radically, the way > the CAS operates. By the way, there are lots and lots of > inconsistencies associated with those silly mode switches. For > example, if I turn on approximate mode, then trying to evaluate the > example for INTVX in the CAS help gives an error message, while > putting the arguments on the stack and pushing the INTVX softkey still > works. Etc., etc., etc. ... > This is evaluation. If you get an example from the help it is backquoted, therefore evaluated as in algebraic mode (arguments are therefore evaluated before the function is). In RPN mode you have total control over evaluation, arguments are *not* evaluated before the function is called. This has nothing to do with approx/exact mode. You would get also different answers with other (non-autoquoting) functions and say binded variables. > I also notice that, judging from your silence on that topic, you agree > with me that not restoring the flags is simply inane, and entirely > unacceptable. > No. If the user accepts a mode switch, then it should not be restored. ==== > I would never say that market success is a best evidence for any > technical superiority. There are many many examples of the > contrary. Price, habits are much more important. This explains > also that the 49G was successfull for example in Spain. anything about technical superiority, whatever that may mean. I said the HPs are not a good value for many applications. As an example, the routines for symbolic integration that the TIs use are much less glamorous than what the HPs do, but they get the job done roughly equally well, and about an order of magnitude faster. > This is evaluation. If you get an example from the help it > is backquoted, therefore evaluated as in algebraic mode > (arguments are therefore evaluated before the function is). > In RPN mode you have total control over evaluation, arguments > are *not* evaluated before the function is called. This > has nothing to do with approx/exact mode. You would get also > different answers with other (non-autoquoting) functions and > say binded variables. Sorry, I should have said numeric mode. Producing an error message in that case when one of the variables does not have a numeric value is simply inane, period. > No. If the user accepts a mode switch, then it should not > be restored. As I said, I don't have much time for this, but this is just bad design, to avoid a stronger word. You might want to get some help in that area, and listen to Veli-Pekka... 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. -- Helen. ==== > >>I would never say that market success is a best evidence for any >>technical superiority. There are many many examples of the >>contrary. Price, habits are much more important. This explains >>also that the 49G was successfull for example in Spain. > > > anything about technical superiority, whatever that may mean. I said > the HPs are not a good value for many applications. As an example, the > routines for symbolic integration that the TIs use are much less > glamorous than what the HPs do, but they get the job done roughly > equally well, and about an order of magnitude faster. > I don't think it is the case anymore if you compare with the 49+. My own tests show that the 49+ is around 3 to 4* faster when doing CAS operations than the 49. Moreover the speed was just a question of processor speed, it had nothing to do about the usability of the CAS. And of course the CAS is not reduced to symbolic integration, there are fields where the 49 CAS is much more useful and usable than the TI89 CAS out of the box, like arithmetic or linear algebra or asymptotic expansions, that are very useful in maths (and probably elsewhere too, but maybe not in highschool). For example, I can't understand how they decided not to provide basic arithmetic instructions like polynomial euclidean division. > >>This is evaluation. If you get an example from the help it >>is backquoted, therefore evaluated as in algebraic mode >>(arguments are therefore evaluated before the function is). >>In RPN mode you have total control over evaluation, arguments >>are *not* evaluated before the function is called. This >>has nothing to do with approx/exact mode. You would get also >>different answers with other (non-autoquoting) functions and >>say binded variables. > > > Sorry, I should have said numeric mode. Producing an error message in > that case when one of the variables does not have a numeric value is > simply inane, period. > Numeric mode has been kept for 48 compatibility. I have never understood what it was designed for. You will get the same kind of error on the 48 -> you should redirect your critic to the 48 designers. > > 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 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). 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. And the annoyance of mode switch is not really that important, it affects only a few CAS flags. Maybe it will convince HP users that radian is the *intrinsic* angle unit:-) ==== > > I also notice that, judging from your silence on that topic, you agree > > with me that not restoring the flags is simply inane, and entirely > > unacceptable. > > > > No. If the user accepts a mode switch, then it should not > be restored. > Although I really can't see why the user would want to switch to radians to do x*e^-x INTVV or to complex mode to do some others I can remember right now. Arnaud ==== > Although I really can't see why the user would want to switch to radians to > do x*e^-x INTVV or to complex mode to do some others I can remember right > now. > it's just because I don't check that a particular input to a function does not require radian mode. INTVX requires radian mode as soon as a trig function is integrated -> INTVX does radian mode switch. Well, it's a calculator complain, because PC CAS assumes angles are in radians. I just do the same but I warn the user. ==== > > Although I really can't see why the user would want to switch to radians to > > do x*e^-x INTVV or to complex mode to do some others I can remember right > > now. > > > > it's just because I don't check that a particular input > to a function does not require radian mode. INTVX requires > radian mode as soon as a trig function is integrated -> > INTVX does radian mode switch. Well, it's a calculator > complain, because PC CAS assumes angles are in radians. > I just do the same but I warn the user. BUT 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... Veli-Pekka PS: A longer - safer version: 1) save the CAS affected flags 1B) check the angle mode and change argument(s) accordingly by multiplying with pi/180 or pi/200, if needed (DGR?) 2) do CAS processing silently 3) restore the flags 4A) check the angle mode and change result accordingly by multiplying with 180/pi or 200/pi, if needed (DGR?) 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... Exactly. -- 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. ==== > > 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. > Could you not have some kind of indicator in the display if the calc has changed mode during an operation? Olaf ==== > 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. > (e.g. in degree mode the antiderivative of cos(x) would be sin(x)). And that would be different from the radian-mode result how? ;-) > CAS + degree mode = bad idea. Well, the naive user might experience some surprises, but that is not in any way different from the kind of surprises people experience in the numerical evaluation of trigonometric function when they forget what mode they are in. -- Helen. ==== > >>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. ==== > A long time ago I stoped letting my little sister play Mario 3 > >>b/c it annoyed me how horrible she played :) >> > > Typical big brother. Hopefully when she reaches your age she will have a > better command of English. > > Tanya > > LOL. Help me. I can't stop reading this thread! I've really tried. ==== > > > >>the RPN underlying system which does not allow easily for > >>the same commandname for a variable number of arguments, > > > > > > Why not use an END_TAG as the 68k do (only for variable-argument > > commands)? It makes things slightly more complicated, but it's a good > > tradeoff, I think. > > > > The reason is RPN entry. If you get args from > the stack before the command name is entered, you can not allow > a variable arg number, except by having an additionnal argument, > which is the number of arguments itself (like DROPN does for example). > In algebraic mode, the parser knows the actual number of args > because of the closing parenthesis (and user functions are also > correctly handled on the HP in an algebraic entry, it's done using > the number of args before xFCNAPPLY). BTW I did not check, how > does the TI rpn program handle commands with variable > arguments number? As Bhuvanesh said ti uses END_TAG. It is an extra argument that indicates that there are no more arguments. Think of it as a closing parenthesis. Example: integrate(x+2,x) is tokenized on ti 68k as: END_TAG, X_TAG, 0x02, 0x01, POSITIVE_INTEGER_TAG, X_TAG, ADD_TAG, INTEGRATE_TAG -Samuel ==== >>The reason is RPN entry. If you get args from >>the stack before the command name is entered, you can not allow >>a variable arg number, except by having an additionnal argument, >>which is the number of arguments itself (like DROPN does for example). >>In algebraic mode, the parser knows the actual number of args >>because of the closing parenthesis (and user functions are also >>correctly handled on the HP in an algebraic entry, it's done using >>the number of args before xFCNAPPLY). BTW I did not check, how >>does the TI rpn program handle commands with variable >>arguments number? > > > As Bhuvanesh said ti uses END_TAG. It is an extra argument that > indicates that there are no more arguments. Think of it as a closing > parenthesis. > > Example: > > integrate(x+2,x) is tokenized on ti 68k as: > > END_TAG, X_TAG, 0x02, 0x01, POSITIVE_INTEGER_TAG, X_TAG, ADD_TAG, > INTEGRATE_TAG Please re-read my message carefully. It is of course possible to have a symbolic data structure with variable arg number but if I enter say x+2 x y+1 y on the stack and then I call the integrate function, how could the rpn program guess that I want to call the 2-args integrate or the 4-args integrate function? Variable arg number is only possible inside an algebraic entry or with an explicit extra arguments in RPN (or you must have 2 different functions like on the 49) or as algebraic entry. So how does the ti rpn program work? ==== > Please re-read my message carefully. It is of course possible > to have a symbolic data structure with variable arg number > but if I enter say x+2 x y+1 y on the stack and then > I call the integrate function, how could the rpn program guess that > I want to call the 2-args integrate or the 4-args integrate > function? Variable arg number is only possible inside an > algebraic entry or with an explicit extra arguments in RPN > (or you must have 2 different functions like on the 49) or > as algebraic entry. > So how does the ti rpn program work? 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. For integrate I forget the number of arguments the keyboard integrate uses. -Samuel ==== > 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 underlying system which does not allow easily for > >>the same commandname for a variable number of arguments, > > > > > > Why not use an END_TAG as the 68k do (only for variable-argument > > commands)? It makes things slightly more complicated, but it's a good > > tradeoff, I think. > > > > The reason is RPN entry. If you get args from > the stack before the command name is entered, you can not allow BULL.... 1) using lists you can have more arguments in many commands and some commands take n as the first argument to know how many...? 2) list processing introduced with the 48G allows n arguments in a list 3) some list processing (48G) commands may take an extra argument DOLIST, DOSUBS 4) DO...UNTIL...END @ END acts like THEN, in all other cases 0 args 5) GROB and GREY with 0 0 take no data after that 6) New command ; (ALG DROP) takes one or zero argument to DROP old CLEAR takes zero to DEPTH arguments 7) THIS IS UNESPECTED FROM MANY PEOPLE: Some old commands take one or two arguments DEPND, INDEP 2: start 1: end @ 'GLOBAL' @ {start end} @ {GLOBAL} @ {GLOBAL start end} BUT will return {start end} from LASTARG when start end is used (two reals) AND XLIB~ on the other hand returns the exact argument count depending on whether one or two arguments where taken > a variable arg number, except by having an additionnal argument, > which is the number of arguments itself (like DROPN does for example). exception as 1) in my list > In algebraic mode, the parser knows the actual number of args > because of the closing parenthesis (and user functions are also > correctly handled on the HP in an algebraic entry, it's done using > the number of args before xFCNAPPLY). BTW I did not check, how > does the TI rpn program handle commands with variable > arguments number? > Speaking of data structures, I find that the TI structure is > better than the HP for symbolic object in algebraic mode > because evaluation should begin with the operator, not with the > arguments, since a given operator sometimes has > to quote some of its arguments (like STO). But like the HP structure, > it is very inefficient for large expressions because it keeps the whole > data in one block, without pointers, and therefore requires > a large copy each time you modify it. A graph data structure > is much more efficient (that's what I choosed for giac/xcas). > A very good extension would be allowing list and matrices in EQW (AND units!, how could anyone forget the units?)