HP-11 ==== > > And newbie question continues. I'm trying to transfer > .txt file to HP49G, but if i have ANY special characters ex. =+/() on text > I get some blurred text on the screen and transfer failures. > I have in my mind that once (months ago) i've succeed transfering > some text, but I'm not actually sure was there any special characters.. > Please help me on this one! > > On a related note, does the HP49G use a font/character system similar > to ASCII or Unicode? (Unfortunately, I don't have my emulator with > me.) ASCII and Unicode are character encodings. A character encoding says which characters correspond to which bit strings; a font is a description of how to render characters graphically. The HP 48 uses something passably close to the ISO 8859-1 character encoding. I would guess the HP 49 does too. -- Steve VanDevender I ride the big iron http://jcomm.uoregon.edu/~stevev Little things break, circuitry burns / Time flies while my little world turns Every day comes, every day goes / 100 years and nobody shows -- Happy Rhodes ==== > 3^(2^3) = 6561 > (3^2)^3 = 729 > > 3^2^3 = 6561 or 729, depending on how you interpret it. Some people say > that the exponents first rule applies from top down, thus preferring 6561; > others say that the same operations are evaluated from left to right rule > applies to both powers, thus preferring 729. The former is more standard. Most, if not all, computer algebra systems use it, and that's the evaluation rule I was taught in college, too. To specify a particular order of evaluation, you can use parentheses, as shown above. -- Bhuvanesh ==== > The HP48 evaluates '3^2^3' as 729. > The HP49 evaluates '3^2^3' as 6561. > so if someone has an HP-48 program with some expression like the above > ('a^b^c'), > and simply transfers it to the 49G, > the program will fail due to a changed order of evaluation? > If yes then it's a time bomb... There are certain conventions in math, in exponential function, exeptionally, right bracketing is the general convention. That is, '3^2^3' should be read as '3^(2^3)' as on the HP49. But clearly, this deviation from the 48 standard should have been clearly documented at various places. Why right-bracketing for exponents? Because '(3^2)^3' cries for immediate simplification to '3^6'. And please observe that in elementary and advanced mathematical textbook the rule '(a^b)^c = a^bc is never written without brackets on the left hand side. I believe that the Corvallis people didn't yet think on combining the 48 with a CAS. Thus, they consequently applied RPN notation also where it contradicts convention. - Wolfgang ==== > The HP48 evaluates '3^2^3' as 729. > The HP49 evaluates '3^2^3' as 6561. > so if someone has an HP-48 program with some expression like the above > ('a^b^c'), > and simply transfers it to the 49G, > the program will fail due to a changed order of evaluation? > If yes then it's a time bomb... There are certain conventions in math, in exponential function, exeptionally, right bracketing is the general convention. That is, '3^2^3' should be read as '3^(2^3)' as on the HP49. But clearly, this deviation from the 48 standard should have been clearly documented at various places, at least in various ACO postings talking about backward compatibility (which is unrealistic :-) Why right-bracketing for exponents? Because '(3^2)^3' cries for immediate simplification to '3^6'. And please observe that in elementary and advanced mathematical textbook the rule '(a^b)^c = a^bc is never written without brackets on the left hand side. I believe that the Corvallis people didn't yet think on combining the 48 with a CAS. Thus, they consequently applied RPN notation also where it contradicts some traditional convention. - Wolfgang ==== Wolfgang Rautenberg escribi.97 en el mensaje > I believe that the Corvallis people didn't > yet think on combining the 48 with a CAS... I've MK installed in my 48 and AGROB for MK (http://www.hpcalc.org/hp48/apps/mk/agrob4mk.zip), one of the best grob scrollers (from JAVA): If I use the EQW for writing the expression, AGROB shows me it in pretty print without brackets, exactly as the MK or 49 stack. EVAL gives 6561. If I use only the 48 keying ' for writing in the edit line, the MK stack shows the same than before, but AGROB shows me the expression left bracketed. EVAL gives 729. The good thing of all this, is that AGROB let me see what is *really* happening ==== > I've MK installed in my 48 and AGROB for MK > If I use the EQW for writing the expression, AGROB shows me it in pretty > print without brackets, exactly as the MK or 49 stack. EVAL gives 6561. mentioned backward compatibility. JYA seemed to have assumed that everybody had the MK :-) MK stuff seems indeed to be backward compatible. But is this the right platform if one speaks of backward compatibility of the 48G and the 49G? - Wolfgang ==== > I've MK installed in my 48 and AGROB for MK > If I use the EQW for writing the expression, AGROB shows me it in pretty > print without brackets, exactly as the MK or 49 stack. EVAL gives 6561. mentioned backward compatibility. JYA seemed to have assumed that most people had the MK :-) But is MK the right platform if one speaks of backward compatibility of the 48G and the 49G? - Wolfgang ==== Wolfgang Rautenberg escribi.97 en el mensaje > But is MK the right platform if one speaks of > backward compatibility of the 48G and the 49G? Certainly not. MK48 or MK49 might run as the original 48 when possible (I think it is, in this case) ==== Wolfgang Rautenberg escribi.97 en el mensaje > But is MK the right platform if one speaks of > of the 48G and the 49G? ...but you are right: backward compatibility IS, or is no backward compatibilty. ==== > so if someone has an HP-48 program with some expression like the above > ('a^b^c'), and simply transfers it to the 49G, > the program will fail due to a changed order of evaluation? > If yes then it's a time bomb... It is more or less obvious by now that backward compatibilty - except for the most simple UsrRPL programs - is not granted. With SysRPL there are seemingly less problems, although some basic commands (e.g. XYDGROBDISP) behave differently. a way out. Before porting a UserRPL program set flag -53, edit and recompile the program which (hopefully) sets all brackets properly :-) - Wolfgang ==== >> 3^2^3 = 6561 or 729, depending on how you interpret it. Some people say >> that the exponents first rule applies from top down, thus preferring 6561; >> others say that the same operations are evaluated from left to right rule >> applies to both powers, thus preferring 729. > The former is more standard. Most, if not all, computer algebra > systems use it, and that's the evaluation rule I was taught in > college, too. To specify a particular order of evaluation, you can use > parentheses, as shown above. I just ran that expression through Maple - it doesn't even try to pass judgement on it. When it is entered, exactly as 3^2^3; it complains about expected semicolons. Haven't tried any other CAS's though. -Mike ==== > so if someone has an HP-48 program with some expression like the above > ('a^b^c'), and simply transfers it to the 49G, > the program will fail due to a changed order of evaluation? > If yes then it's a time bomb... It is more or less obvious by now that backward compatibilty - except for the most simple UsrRPL programs - is not granted. With SysRPL there are seemingly less problems, although some basic commands (e.g. XYDGROBDISP) behave differently. a way out. Before porting a UserRPL program set flag -53 on the sending machine which (hopefully) sets all brackets properly :-) - Wolfgang ==== Truss49 in the conversion done by Edwin Cordoba presents an error upon drawing the truss upon seeming is the only error because the results are performed correctly. It fits to clear up that changing the system of coordinates to a right system the truss draws correctly but the results are incorrect. Errors that Truss48 does not present. The question is if this error to be corrected by Alain soon. Greetings. V.92ctor Moctezuma Hdez. By my race spoke the spirit (I sit down the lack of clarity but my native language is Spanish) ==== I will see what can be done about that. Caspar Note that the original Truss48 is bugfree, it is just the port that is bugged. V.92ctor Moctezuma H. schreef in bericht > Truss49 in the conversion done by Edwin Cordoba presents an error upon > drawing the truss upon seeming is the only error because the results > are performed correctly. > > > It fits to clear up that changing the system of coordinates to a right > system the truss draws correctly but the results are incorrect. > > Errors that Truss48 does not present. > > The question is if this error to be corrected by Alain soon. > > Greetings. > V.92ctor Moctezuma Hdez. > By my race spoke the spirit > > > (I sit down the lack of clarity but my native language is Spanish) ==== Does anybody know something about Mika Heiskannen? What is he doing or if he is still making programs for HP calcs? I have tried to enter in his web page, but It is closed. thanks Akula ==== My Emu48 1.31 with HP49 ROM is behaving VERY BADLY. it crashes while installing libraries(they work on my real 49G), compiling system-rpl, and even using the filer. it started since I installed windows 98. on windows 95 it didn't happen. why? is that a emulator bug? my computer is a pentium 200, 32 mb ram, 1.6 gb hd, on-board HSP modem, etc... Karma Policer Bother, said Pooh, as his HP41 displayed MEMORY LOST. ==== I'm starting to program in SYS-RPL. I like to decompile built-in commands and many times I find something like this ptr 1AC93 . To decompile this I use the rclx command of the HACK library. I type #1AC93h on the stack and then run rclx and DIS. But sometimes I get something like this: Romptr AB 6D nad I don't know how to acces to this pointer. Anyone knows? Akula ==== I recently bought an HP 39G thinking it would have more than enough of what I need. I was looking in particular for good solid matrix operations, and the calculator seems to deliver. Everything seems fine, except that the calculator does not have base conversions??? What the hell? How much would you miss not having base conversions and binary/hex/octal operations if you are a software developer? (I guess it depends what kind of software developer, let's say you might do some somewhat low level stuff every now and then). Shall I return this and get an HP48xx? (I see JAndR still has the HP 48G+ for about $99). I am also shocked to see HP is kind of letting go of the calculator market or so it seems. The 49G is no longer on their website as it was previously... I wonder what's up with them. - Raist ==== If you go to my website at http://www.hphomeview.com and look on my Misc aplets page you'll find a new aplet (well a library actually) called Library L1540. This adds a whole heap of commands to the 39G which, amongst other things, do conversions. > I recently bought an HP 39G thinking it would have more than enough of > what I need. I was looking in particular for good solid matrix > operations, and the calculator seems to deliver. > > Everything seems fine, except that the calculator does not have base > conversions??? What the hell? > > How much would you miss not having base conversions and > binary/hex/octal operations if you are a software developer? (I guess > it depends what kind of software developer, let's say you might do > some somewhat low level stuff every now and then). > > Shall I return this and get an HP48xx? (I see JAndR still has the HP > 48G+ for about $99). > > I am also shocked to see HP is kind of letting go of the calculator > market or so it seems. The 49G is no longer on their website as it > was previously... > > I wonder what's up with them. > > - Raist ==== Look, Thierry Morissette , said Karma Policer, and typed: > Fascinating ... > LOL! HP49G = 100% discontinued? -- Karma Policer - Brazil Lesbian tagline: lick here -> [ ] <- ==== When I do an ON+A+F(F1+F6) it falls into the diagnostics loop (ON+F). The A(F1) key works normally. Why? ------------ Karma Policer Pentium 233 32 MB RAM 2 GB Hard Drive ==== John H Meyers used to swear: > [ser# on case vs. SERIAL command] > > They are supposed to be different. > > Apparently this long ago became a feature :) > > the very latest feature is for SERIAL to not return > any serial number at all, so your calc is not even up to date :) > > The internal, programmable serial number apparently > did not prove to be useful to anyone, least of all to HP, > which had to generate a different one in each flash chip; > it must also have been a bother to synchronize them > with the numbers on the cases, which seems never to have happened. > > Were you going to actually use the SERIAL command for something? > > > [r->] [OFF] Actually I use it. It's good to develope a (commercial) anti-piracy method for HP49 programs. You develope a program for an given 49, it will run only on the model. One thing that is so easy on HP is so hard on the PC. Why? =D -- THIS TAGLINE HAS BEEN UNREGISTERED FOR 36 DAYS- by TAG-PICK beta - picking from a 150000 lines file. ==== > > I just completed the announced keymap switcher, > ChangeKeymap, or ChKM for short. But only for the > HP49. I'm surprised how fast and easy it runs, the > normal user will be pleased. ChKM is a choose box > of only 200 bytes. I used all available tricks to > keep it small and fast, in particular Werner's. > Thus, you can now easily experiment with various > smaller or larger keymaps, for physics, etc. > > One just recalls UserKeys with option GetUK and > stores it under a name with suffix .K which by > itself integrates into the choose box. A file U.K > must be either a list obtained with GetUK or its > compression with BZ. Clearly, ChKM has its own > decompressor. Compression rate for few assignments > is very high, over 90%, and in general much smaller > than the output of the slow RCLKEYS command. > > - Wolfgang > ftp://ftp.math.fu-berlin.de/pub/usr/raut/HP49/keys > > PS. Werner, I solved the problem of extracting the Is there a source for this program other than the ftp address above, since I cannot connect with that address. ==== A while back in comp.lang.scheme there was some thread about self-evaluating evaluators (in other words, interpreters for a language written in that language itself) in which someone posted this rather odd-looking evaluator for his self-invented programming language Joy. I looked up his web page on the topic: http://www.latrobe.edu.au/philosophy/phimvt/joy.html and it turns out Joy is a stack-based language conceptually similar to RPL in many ways, although with a rather more theoretical bent. I haven't really had time to play with it but the introductory material is intriguing. Those of you with a computer science background may find the theoretical papers there kind of interesting too. I asked the author if he had ever heard of RPL before, and he said he hadn't. -- Steve VanDevender I ride the big iron http://jcomm.uoregon.edu/~stevev Little things break, circuitry burns / Time flies while my little world turns Every day comes, every day goes / 100 years and nobody shows -- Happy Rhodes