HP-8 ==== Hopefully this is a simple problem, though not for me. If there is a library with a global xNAME, say TEST already made. Then another library or program is made that wants to access TEST. Writing ID TEST in the code doesn't seem to work - sends it to the stack. I've tried also :: TEST $>ID ; . This will work, but only after pressing EVAL on the calc. Is there a way to access a global procedure made with Debug4x from another Debug4x program? Dave ==== Moin, ID TEST refers to the global variable 'TEST', so this won«t help you at all. > Is there a way to access a global procedure made with Debug4x from another > Debug4x program? You can easily access any subroutine (named or unnamed) by calling them directly via their ROMPTR. ROMPTR (both in hexadecimal) So if 'TEST' is the first program in Library 1234 (decimal) you could call it by using ROMPTR 4D2 01 . HTH Andreas ==== Yes this does work, thanks. The only worry is a lot of problems could come if another program is added to the library - since I suppose this could alter the other entry points. Dave > Moin, > > ID TEST refers to the global variable 'TEST', so this won«t help you > at all. > Is there a way to access a global procedure made with Debug4x from another > Debug4x program? > > You can easily access any subroutine (named or unnamed) by calling > them directly via their ROMPTR. > ROMPTR (both in hexadecimal) > So if 'TEST' is the first program in Library 1234 (decimal) you could > call it by using ROMPTR 4D2 01 . > HTH > Andreas ==== > Yes this does work, thanks. > The only worry is a lot of problems could come if another program is added > to the library - since I suppose this could alter the other entry points. If you append and don't change the order - how? ==== >Hopefully this is a simple problem, though not for me. > >If there is a library with a global xNAME, say TEST already made. > >Then another library or program is made that wants to access TEST. Writing >ID TEST in the code doesn't seem to work - sends it to the stack. I've tried >also :: TEST $>ID ; . This will work, but only after pressing EVAL on >the calc. > >Is there a way to access a global procedure made with Debug4x from another >Debug4x program? Uh, I can't remember exactly right now, but I guess for xNAMEs you call them by xNAME (xTEST in your example). And in the case of NULLNAMEs, you call them by just the name (TEST). Try it.. -- Beto ==== It seems to work only if the xNAME declared procedure is in the same library. It does not seem to recognise it otherwise. Dave > >Hopefully this is a simple problem, though not for me. > >If there is a library with a global xNAME, say TEST already made. > >Then another library or program is made that wants to access TEST. Writing >ID TEST in the code doesn't seem to work - sends it to the stack. I've tried >also :: TEST $>ID ; . This will work, but only after pressing EVAL on >the calc. > >Is there a way to access a global procedure made with Debug4x from another >Debug4x program? > > Uh, I can't remember exactly right now, but I guess for xNAMEs you > call them by xNAME (xTEST in your example). And in the case of > NULLNAMEs, you call them by just the name (TEST). > > Try it.. > > -- > Beto ==== > I still have my canary yellow pickett slide rule in it's original > leather case. Nice. I just now got out my 40-year-old bamboo Post Versalog (from its original leather case :-) ) and it felt amazingly good. I calculated 3.00 2.30 * getting 6.90 with one smooth stroke. > > But about the 49g+: > Is if faster, I had a 49+ in my hands for a couple of minutes recently. Without much forethought I tried 1000 ! in exact mode, which of course didn't respond immediately. With numerous other people standing around wanting a chance to try the new machine, I was a bit embarrassed while waiting the 15 or 20 seconds it took to return the answer (which I didn't check :-) ). I later tried 1000 ! on my HP49 and it required 61.8 seconds to calculate the 2568-digit factorial result. So the 49+ was roughly 3 times faster than the 49 for this example. Of course the 48 couldn't do this problem at all because of floating point range limit. > better, Bigger screen with better contrast, much more memory capacity at much cheaper prices for memory cards, much faster equation writer. The keyboard felt a lot better than the 49, although not the really great feel of the 48. I didn't notice the keyboard problems that some others have noticed on some early models, but I didn't have time to experiment. > smarter, Has all the HP49 software advantages over the 48 including: a very good CAS, exact integers and fractions, symbolic matrices, can raise square matrix to a power (and much, much faster than a naive program). > easer to program, ..... than the 48's? The 49+ retains the 49 programming enhancements: a choice of fonts to allow more lines to be seen at one time, the arrow keys work in Alpha mode, cut and paste are available, some new stack commands (DUPDUP, UNROT, PICK3, UNPICK, NIP), the Catalog (with Help for many functions) which can be used to locate and enter command after typing in the first letters of the name. I would prefer to see the angle sign visible on the primary keyboard, but if you need it often enough it would be easy to remember the required keystrokes (or one could re-assign it). I assume many keyboard shortcuts are retained from the 49. While these often were not well documented for the 49, many were posted here by the 49 developers. I look forward to purchasing a 49+ as they become more widely available. ==== > As I understand it, HP gave out a fair number of Xpanders to teachers. > There should be no problem with sales of those. > Actually, all the calculator given away by HP to teachers, students and > other beta testers were clearly marked: Non Commercial prototype, not for > resell... (or any such similar marking)... so, reselling them is not an > option... HP can mark the calculator with any sort of restriction messages it likes; they could say not for use on Tuesdays. But (in the US) there's no law that makes such a restriction binding. So unless HP actually got the recipients to sign a contract, they are free to sell them. Normally the main purpose of a prototype - not for resale legend on a prototype is because it has not yet passed FCC part 15 testing. However, the burden is on the manufacturer to keep it from being resold, not on the end user. That said, I have not sold any of the calculator-related products HP has provided to me for beta testing (most recently in 1982 or 1983), nor would I sell any that HP might choose to provide in the future. :-) ==== However, it's the only free 2-D graphing calculator on a Pocket PC. A plus is that the graphing is instantaneous, no waiting for the calculator to plot a graph point by point, which ought to be the trend and an indication of real progress in calculators. ==== I think it's not necessary to own an xpander, unless as a collectible. You can just get a pocket PC (a lot more useful) and install the Xpander software from http://www.saltire.com/xpander.html for free. The Xpander is no more than a scientific graphing calculator. It math capabilities doesn't go beyond a TI-81, with the exception of the numerical integral and plot table. I haven't used the geometric construction part of the xpander software, but it should include the standard functions for this type of application. The xpander can't do symbolic Algebra and Calculus, can't graph other types of functions except rectangular 2-D, and is not programmable. Dave ==== Dear Dante, I can access that site, EXCEPT for that page you specified. It's been a long time, but I can read most of what was said; it's too bad that last page which you said had the all-important pictures is blank when I get there! I hope some of the other guys who have tried this can answer your question. > Upgrade48 here: > > http://www.eurobotics.org/hp_upgrade3.html (spanish) > > I followed the steps there described. The 128Kb chip can be seen (I > have 32Kb there, and el PCB with two 128Kb chips). Only 20 and 22 pins > unsolder. > > Sorry for may poor english again. > ==== > TI is the piano that Amadeus (in Peanuts) is using > > Schroeder He's a kid - it's a toy - for kids USe a calc for Pro: the hp 49g+ ==== > I have downloaded and installed last Conn4x version available in HP site, > and I have some strange problems with it. > First, it doesn't find the hp49g+ using Auto, but last version used to > find it without problems. Use that version then... > Using hpx9g+ to connect, it hangs in Windows Millenium. I can't stop it > but using CTRL+ALT+SUP and selecting Conn4x. > > So, I can't send files to my calc, but I can update its ROM without > problems using it.. funny I think. > > Some people in my university reported me that UserRPL programs from HP49g > are send as string that can't be edited ('Can't edit null char'). I have > to see one calc with them, but I think it is a matter of binary/ascii > convertion, right? Right In my PC using the Windows XP Pro the Conn4x Build 1689 works every single time Maybe you should upgrade your PC OS to a more modern one (one that supports USB properly) ==== > Use that version then... I'll do. > the Conn4x Build 1689 works every single time Maybe you should upgrade > your PC OS to a more modern one (one that supports USB properly) Are you saying that Win98 core doesn't support USB properly and for that reason I should update my OS to a newer one (call it XP) that runs slower and make other things unusable on my PC ??? Every USB product I have works nice in my Windows Millenium, which license I've paid when I bought my laptop. So, I don't belive it is a Windows Millenium problem with USB, and none client would belive that if his USB memory key, his USB HP camera, his USB HP iPAQ, etc. can be connected without problems. I hope someone could give me an answer about why this USB product can't use a usb mass-storage driver, that would let the user to mount calculator HOME directory as a external disk to store data in it. Instead of that, HP/Kinpo has released drivers not finished as it seems with continous updates, and buggy connectivity kit software that doesn't work as expected. HP49G+ is an exceptional hardware and software piece, but its connection with PC is really poor. I hope this will get better in the future. --- J.Manrique L.97pez de la Fuente Users Club from Gij.97n 1077 HPCC Member ==== > I'm awating my G+ right now so I have a question for those who already > have it or may know this: > > With the additional screen space on the G+, do you have access to > additional lines for an input form? For example, could you, using > programming, have additional area for inputs? > > I have several input forms that I'd love to be able to expand to get > additional user inputs. You need to know the new internal screen system and SysRPL in order to program your own big input forms. For the end user the main benefit is to see the header all the time while accessing the whole old screen. Some rare commands and environments use the header. try PROMPT then DBUG a program and SST ==== > I have several input forms that I'd love to be able to expand to get > additional user inputs. > You need to know the new internal screen system and SysRPL > in order to program your own big input forms. tomorrow!)? Also, is there any info available as to the new internal screen system as it relates to SysRPL? I have a fairly comprehensive set of RF engineering programs (CatvLib on hpcalc.org) written exclusively in SysRPL and they use a lot of input forms that would certainly benefit from additional inputs. Simon ==== > It should be a normal selfextracting ZIP-Archive. I was able to open > it with WinZip. If an analogous tool doesn«t exist for MacOS, Well, I've tried all the expanders available for the Mac, but they won't work. > I can > send you the two files (in the case your ISP allows such big > attachments; its ~ 1.2 MB in size). isn't working) and transferred them via SD-card in my 49+. Michael -- -= Michael Hoppe , =------ ==== Dear 49+-ers, due to the massive problems I had with Conn4x -- it still doesn't work under W98, even with the 1.0.4.3-driver -- I've bought a SD-card, made by SanDisc, 256 M of size, and an appropriate card reader. As expected, the card reader didn't work properly on my wife's PC (W98), but flawlessly on my sister-in-law's machine (XP), and, of course, it works on my Mac, both under 9.2.2 and OSX. Playing a little around with the card, I've tried the FORMAT-option, accessible via ON-D. The 49+ reported a successful formatting. But the card was not readable any more (not under XP neither on the Mac). So I reformatted it, firstly under XP with the the FAT-option (not FAT32) and copied some data on the card. Weird things then happened: the files were shown on the 49+, but when I copied some files on the 49+, they were gone: the 49+ reported that the card is empty. But both on the XP-machine as on my Mac the files were present. Same desaster occurred when I formatted the card on my Mac -- under OSX (and XP as well) there are no special drivers needed. So I gave back the card and got me a new card of size 128 M. I noticed that the cluster size of the new card is 16K, whereas the cluster size of the other card was 4K (after formatted either under XP or OSX). Did I do something wrong? Some advice to SD-card-users: Don't touch the files with funny names that are shown in the 49+, but not in XP or on the Mac, as the Trashes-folder and so on. Manipulating them may yield in files of type ERROR on the 49+ or in duplicate files. Michael -- -= Michael Hoppe , =------ ==== There was a lot of discussions about the problems to connect the 49+ with a PC under Windows98 via Conn4x, also in my case it still doesn«t work. The USB driver is properly installed, the USB connection is o.k. (check is possible via ON-D) - what can I do else? Is there any official information by HP? Klaus Graichen graichen@mvtat.tu-freiberg.de Michael Hoppe schrieb im Newsbeitrag > Dear 49+-ers, > > due to the massive problems I had with Conn4x -- it still doesn't work > under W98, even with the 1.0.4.3-driver -- I've bought a SD-card, made > by SanDisc, 256 M of size, and an appropriate card reader. As expected, > the card reader didn't work properly on my wife's PC (W98), but > flawlessly on my sister-in-law's machine (XP), and, of course, it works > on my Mac, both under 9.2.2 and OSX. > > Playing a little around with the card, I've tried the FORMAT-option, > accessible via ON-D. The 49+ reported a successful formatting. But the > card was not readable any more (not under XP neither on the Mac). So I > reformatted it, firstly under XP with the the FAT-option (not FAT32) and > copied some data on the card. Weird things then happened: the files > were shown on the 49+, but when I copied some files on the 49+, they > were gone: the 49+ reported that the card is empty. But both on the > XP-machine as on my Mac the files were present. > > Same desaster occurred when I formatted the card on my Mac -- under > OSX (and XP as well) there are no special drivers needed. So I gave > back the card and got me a new card of size 128 M. I noticed that the > cluster size of the new card is 16K, whereas the cluster size of the > other card was 4K (after formatted either under XP or OSX). Did I do > something wrong? > > Some advice to SD-card-users: Don't touch the files with funny names > that are shown in the 49+, but not in XP or on the Mac, as the > Trashes-folder and so on. Manipulating them may yield in files of type > ERROR on the 49+ or in duplicate files. > > Michael > > -- > -= Michael Hoppe , =------ ==== > There was a lot of discussions about the problems to connect the 49+ with a > PC under Windows98 via Conn4x, also in my case it still doesn«t work. That's why I've bought an SD-card. > The USB driver is properly installed, the USB connection is o.k. (check is > possible via ON-D) - what can I do else? Buy an SD-card? And a reader/writer as well and keep your fingers crossed that it'll run under W98. And then forget about Conn4x. (After all, my post wasn't dealing with PC-hp49+-connection problems, but on possible problems with the card.) If you want to be a hero, try formatting your new card on the hp49+ and report the results, please. Michael -- -= Michael Hoppe , =------ ==== > > There was a lot of discussions about the problems to connect the 49+ with a > PC under Windows98 via Conn4x, also in my case it still doesn«t work. > > That's why I've bought an SD-card. > > The USB driver is properly installed, the USB connection is o.k. (check is > possible via ON-D) - what can I do else? > > Buy an SD-card? And a reader/writer as well and keep your fingers > crossed that it'll run under W98. And then forget about Conn4x. > (After all, my post wasn't dealing with PC-hp49+-connection problems, > but on possible problems with the card.) > > If you want to be a hero, try formatting your new card on the hp49+ > and report the results, please. I'm a hero: I did it about an hour ago and then I put back the data using Sandisk 6-in-1 and after that upgraded the LCD defected sales 49G+ to check if there is any difference now. Nope: it's aHW problem, but the SD beautifully upgraded the OS This is the only defective LCD that I have ever seen in Finland on any 49 Only one pixelrow is lighter, but also when you reset, you can see some of the LCD lines connecting the display. Pretty strange wiring... well, 49 good machines went to resellers... ==== > There was a lot of discussions about the problems to connect the 49+ with a > PC under Windows98 via Conn4x, also in my case it still doesn«t work. The > USB driver is properly installed, the USB connection is o.k. (check is > possible via ON-D) - what can I do else? Is there any official information > by HP? I think that Windows 98 is not anymore supported by M$ Upgrade to WIN XP Pro, it works! ==== > I think that Windows 98 is not anymore supported by M$ Upgrade to WIN XP > Pro, it works! I've tried: # apt-get update # apt-get upgrade But it doesn't update my M$ OS :-) Maybe Win98 is not supported by M$, but does it mean that HP doesn't support it on its products? Sure, they can use that policy, but I don't find serious by HP making me buying a complete new PC (new OS like XP would make my PC unsuable) to use its calc. And I am not asking about HP giving support for MSDOS 3 or similar, just for the most wide range of users. I am a happy windows (X-Windows) user... and as I've heard: ÇIn an open world, who needs gates and windows?È Perhaps, that's the problem, this is not an Çopen worldÈ. --- J.Manrique L.97pez de la Fuente Users Club from Gij.97n 1077 HPCC Member ==== > It cost DKr1700 - but it doesnt get sent out of > the country for replacement. That's an ok price. ==== Parisse Bernard skrev i melding > Make an example matrix and see if it works: > > First: Make a random matrix: > {3 3} Enter > And: MATRICES -> CREATE -> RANM > And I got: > > | -7 -3 3 | Wich gives an determinant like -669 > | 3 -9 -6 | > | -1 8 -5 | > > > N.B.: I assume you don't look for the determinant, because > the answer would be to use DET Correct. > Trying RREF, an got this matrix: > | 1 0 0 | > | 0 1 0 | > | 0 0 1 | > And this is, if the matrix above have represented an equation with 3 > unknown, ex X, Y, Z. > Then X would be 0, Y would be 0, and Z is ? Or maybe i'm wrong. Maybe I > should interpret it as it was two unknown, X and Z. Then X would be 0, Y > would be 0 and X+Y =0 or X+Y=1. Not, can't be. Maybe it's impossible to > solve. But anyway, it wasn't waas I was looking for. The determinant is > not -669. > > ... > RREF returns a full row reduced matrice, REF a half row reduce > matrice, rref is like RREF but it will not make the reduction > by dividing the lines by the diagonal non zero coeff and it > returns at level 2 the list of pivots used (with multiplicities), > so that you know when the reduction is correct (solve > pivot=0 with respect to the parameters for incorrect reduction) So by now, I wonder: What does a pivots tells me. ==== Is it posible (with hp49g rom 1-1.6) to convert a vector, Ex: [1 2 3] to a matrix [[1 2 3]] ? I know i can do the oposite by creating a matrix: [[1 2 3]] and extract out row number one: [RS] [MATRICES] CREATE ROW ->ROW One more thing: How to create a matrix looks like this: | Sin(120) Cos(60) | | Tan(45) Sin | ? ==== > Is it posible (with hp49g rom 1-1.6) to convert a vector, Ex: [1 2 3] to a > matrix [[1 2 3]] ? 1. ROW-> ==== > Is it posible (with hp49g rom 1-1.6) to convert a vector, Ex: [1 2 3] to a > matrix [[1 2 3]] ? > I know i can do the oposite by creating a matrix: [[1 2 3]] and extract out > row number one: > [RS] [MATRICES] CREATE ROW ->ROW Press [Down] to start MTRW, hit |VEC | to take the box off it, press ENTER or ARRY-> 1 SWAP + ->ARRY or use the row or column commands > One more thing: > How to create a matrix looks like this: > | Sin(120) Cos(60) | > | Tan(45) Sin | MTRW EQW SIN(120) ENTER EQW COS(60) ENTER [Down] [Left] EQW TAN(45) ENTER EQW SIN(0) ENTER ENTER or { { 'Sin(120)' 'Cos(60)' } { 'Tan(45)' 'Sin(0)' } } ENTER AXL or use the ->ARRY. or the row or column commands OR.... Veli-Pekka ==== > > or > { { 'Sin(120)' 'Cos(60)' } { 'Tan(45)' 'Sin(0)' } } ENTER > AXL > or > use the ->ARRY put the elements on the stack:' 'Sin(120)' 'Cos(60)' 'Tan(45)' 'Sin(0)' and then put the list {2 2} on the stack and enter the command ->ARRY Note that this procedure also may be used to create a matrix with algebraic entries (e.g. cos(t) - sin(t) sin(t) cos(t) ) > or the row or column commands > OR.... > Veli-Pekka > > -- Hans Kristian ==== Veli-Pekka Nousiainen skrev i melding > > Is it posible (with hp49g rom 1-1.6) to convert a vector, Ex: [1 2 3] to a > matrix [[1 2 3]] ? > I know i can do the oposite by creating a matrix: [[1 2 3]] and extract > out > row number one: > [RS] [MATRICES] CREATE ROW ->ROW > > Press [Down] to start MTRW, hit |VEC | to take the box off it, press ENTER Wow, That's easy. Fast too, takes me < 3 secs to carry out. > ARRY-> 1 SWAP + ->ARRY > or use the row or column commands How ? Which row/column commands? > One more thing: > How to create a matrix looks like this: > | Sin(120) Cos(60) | > | Tan(45) Sin | > > MTRW EQW SIN(120) ENTER EQW COS(60) ENTER [Down] [Left] > EQW TAN(45) ENTER EQW SIN(0) ENTER ENTER > or > { { 'Sin(120)' 'Cos(60)' } { 'Tan(45)' 'Sin(0)' } } ENTER > AXL That works. Also it's easy to write. Btw: AXL commad access: [Left shift] 6[CONVERT] 5.[MATRIX CONVERT] 1.[AXL] > use the ->ARRY. or the row or column commands > OR.... > Veli-Pekka ==== > > Veli-Pekka Nousiainen skrev i melding > > > Is it posible (with hp49g rom 1-1.6) to convert a vector, Ex: [1 2 3] to > a > > matrix [[1 2 3]] ? > > I know i can do the oposite by creating a matrix: [[1 2 3]] and extract > out > > row number one: > > [RS] [MATRICES] CREATE ROW ->ROW > > Press [Down] to start MTRW, hit |VEC | to take the box off it, press ENTER > > Wow, That's easy. Fast too, takes me < 3 secs to carry out. > > ARRY-> 1 SWAP + ->ARRY > or use the row or column commands > > How ? Which row/column commands? [1 2 3] 1 ROW-> PS: you should read the new manuals... ==== Geir Klemetsen skrev i melding > > Veli-Pekka Nousiainen skrev i melding > > > Is it posible (with hp49g rom 1-1.6) to convert a vector, Ex: [1 2 3] to > a > > matrix [[1 2 3]] ? > > I know i can do the oposite by creating a matrix: [[1 2 3]] and extract > out > > row number one: > > [RS] [MATRICES] CREATE ROW ->ROW > > Press [Down] to start MTRW, hit |VEC | to take the box off it, press ENTER > > Wow, That's easy. Fast too, takes me < 3 secs to carry out. > > ARRY-> 1 SWAP + ->ARRY > or use the row or column commands > > How ? Which row/column commands? > > > One more thing: > > How to create a matrix looks like this: > > | Sin(120) Cos(60) | > > | Tan(45) Sin | > > MTRW EQW SIN(120) ENTER EQW COS(60) ENTER [Down] [Left] > EQW TAN(45) ENTER EQW SIN(0) ENTER ENTER > or > { { 'Sin(120)' 'Cos(60)' } { 'Tan(45)' 'Sin(0)' } } ENTER > AXL > > That works. Also it's easy to write. > Btw: AXL commad access: > [Left shift] 6[CONVERT] 5.[MATRIX CONVERT] 1.[AXL] > > use the ->ARRY. or the row or column commands > OR.... > Veli-Pekka > Btw: I found an aven more easy way to write a matrix with sin() and cos() inside: Ex: [['Sin(120)' 'Cos(60)] 'Tan(45)' 'Sin(0)'] ==== No-one knows? I thoght someone would. Oh well, nevermind. If you have a 49G+: Take a look at SERIAL and ROMUPLOAD with nosy. It is strange, it seems the calculator detects the hardware it is running on... each hardware specific command seems to reference a pointer, #2F3Bf, that returns TRUE on the 49G+. Pity I can't try it on the 49G (but I bet it returns false) EG take ROMUPLOAD It begins... CK0 PTR 2F3BF (the pointer I was talking about) case :: Not available (this runs if on ARM) ; (code to upload the ROM is run here if the above Pointer returns false - I doubt it will work though, the hardware is too different) So the calc runs this pointer, if TRUE, doesn't let you update the ROM, if false, the ROMUPDATE is called. Chances are this code will fail - the hardware is very different, and there is no RS232 port. I do not know sysRPL so I can't proceed further, but some other guru's may like to take a look. cheers, Al PS I just searched the web, and my hunch is right. Please see this page: http://zon.astro.uva.nl/~dominik/hpcalc/entries/hp49g/entries_287.html The pointer does return true if on an ARM ==== > [...] it seems the calculator detects the hardware it is running on [...] Sounds familiar. Hmmm ... extracting a working version for the 49G from the 49G+ .bin file does seem to be feasible after all ;-) Not too hard ... I wonder why they did it this way. If someone manages to do it, would there be any problems in publishing it? ==== > I am playing around with the 49G's ROM with nosy. > > Suppose I see a test somewhere that normally fails for some reason - > and I want to jump over it. I guess I need to find the destination > address and SYSEVAL it. And then later: > No-one knows? I thoght someone would. Oh well, nevermind. > > If you have a 49G+: Take a look at SERIAL and ROMUPLOAD with nosy. It > is strange, it seems the calculator detects the hardware it is running > on... each hardware specific command seems to reference a pointer, > #2F3Bf, that returns TRUE on the 49G+. Pity I can't try it on the 49G > (but I bet it returns false) [snip] > CK0 > PTR 2F3BF (the pointer I was talking about) > case > :: > Not available (this runs if on ARM) > > ; BTW the test is not there on the 49G (1.19-6). PTR 2F3BF looks as if it could work in Nosy, but causes a TTRM. There are a couple of ways how you can skip the test: * You can compile and run :: ' xROMUPLOAD ROMPTR@ NOTcaseFALSE INNERCOMP #4- ::N 5UNROLL 4DROP ; then EVAL the resulting program (the above simply strips the first four commands from ROMUPLOAD) * The same also works in UserRPL if you have a library with a rompointer recaller like Pivo's LTools. Make sure you have the hacker library attached (256 ATTACH), then run << { ROMUPLOAD } RclRomp @ or an equivalent command OBJ-> DROP ->LST OBJ-> 4 - ->LIST ->PRG 5 ROLLD 4 DROPN EVAL >> * If you have Jazz installed, you can use SDB to debug :: xROMUPLOAD ; Just use ->IN to step into the ROMPTR then SKIP to get across the test. I doubt Jazz runs on the 49G+ though. You can even use a GOTO in some cases, but not here because it's a ROMPTR. In theory you could even (in assembly) look up the library it's in yourself, switch flash banks, jump to the code, and on return switch back. Hope that helps... - Thomas -- foo and bar, respectively. ==== I am about to purchase a 49G+. Does it support a 64 Mb SD card ?(I don«t really know what type that is as I«m accustomed to the 48 SX and GX type cards...). BR Matti ==== > >I am about to purchase a 49G+. Does it support a 64 Mb SD card ?(I >don«t really know what type that is as I«m accustomed to the 48 SX and >GX type cards...). > >BR Matti I have a 64MB MMC card in mine and can archive to it... Pete M. Wilson Gamewood, Inc. wilsonpm@gamewood.net ==== > > I am about to purchase a 49G+. Does it support a 64 Mb SD card ?(I > don«t really know what type that is as I«m accustomed to the 48 SX and > GX type cards...). Javisst, naturligtvis, och MMC med. Bror-Peter ==== I assume that many others who share this group have preordered the 49g+. Since they are due to start arriving at our homes in the coming week, I would like to take an informal poll on the new batch. If we address the reported problems to date (keyboard, paint) and any new ones, maybe we can determine if HP has fixed them. Please comment on the following: 1) Keyboard problems! sticky, dropped keystrokes, etc 2) Paint chipping 3) General observations If you include from where and when you purchased the calc, serial number, etc, it might help us decide from where the best ones are coming ... If we know how many get returned versus kept, it will be a good indicator of the latest quality. I know several people have reported the keyboard problem so far, but we don't have a terribly good idea of the ratio of good/bad ones, etc. Therefore, please respond even if your calc has no problems. Maybe this will help. Mitch ==== > I assume that many others who share this group have preordered the 49g+. > Since they are due to start arriving at our homes in the coming week, I > would like to take an informal poll on the new batch. If we address the > reported problems to date (keyboard, paint) and any new ones, maybe we can > determine if HP has fixed them. > > Please comment on the following: > 1) Keyboard problems! > sticky, dropped keystrokes, etc > 2) Paint chipping > 3) General observations Defective LCD pixel columns # 38 right after the HEX E vertical line Only when writing to that column and the column after that also goes light on contrast. Tested using truth plot The problems is in HW - unintependent of ROM version. Calc on warranty repair now... PS: No color ever chipping off unless calc dropped on it's corner to a hard surface from table distance of higher. ==== I have converted my User RPL programs into a Library, and I live the speed increase. In the directory that formed this library are about 350 little programs stored in variables. Question #1: Why can I not call the name of a library command from a user key. My workaround was to assign a user key to a little program that then called the library name. Why?? Question #2: Is there any speed reason to possibly split my 350 command library into smaller libraries?? Question #3: Does the order of the variables that created a library have any affect on access time?? Should I ORDER the directory, to place the most frequently used commands at the front of a library?? John Evers ==== John Evers schrieb > I have converted my User RPL programs into a Library, and I live the > speed increase. In the directory that formed this library are about > 350 little programs stored in variables. I wonder, that there is a speed increase? Sure, you will have the benefit of getting memory free, in the home-dir. > Question #1: Why can I not call the name of a library command from a > user key. My workaround was to assign a user key to a little program > that then called the library name. Why?? You are using OT49 from Wolfgang Rautenberg: http://www.math.fu-berlin.de/~raut/WR49/index.htm Please read carefully the *.htm documentation. All of your little programms need to be in the visible-list! You need to *attach the library! When you call a programm of the library manualy, just by typing the name of the program, does it work? If yes, you should be able to assign this prog to a key. By the way, Wolfgang has a nice tool to make keyassignments (see link above). s. Link above :-) Best wishes Heiko ==== > I have converted my User RPL programs into a Library, and I live the > speed increase. In the directory that formed this library are about > 350 little programs stored in variables. > > Question #1: Why can I not call the name of a library command from a > user key. My workaround was to assign a user key to a little program > that then called the library name. Why?? You can do it easely, in fact, they are lots of ways, but: { LIBCOMMANDNAME } 1 GET KeyNumber.PlaneNumber ASN will do fine. > Question #2: Is there any speed reason to possibly split my 350 > command library into smaller libraries?? no, it will go at the same speed > Question #3: Does the order of the variables that created a library > have any affect on access time?? Should I ORDER the directory, to > place the most frequently used commands at the front of a library?? no, this would not change anything. > > > John Evers ==== Does anyone know a program which is able to plot functions in 2 variables ( f:R^2->R ) on the 39g/40g? I tried the 2 programs form Collin Croft's site, but they are written in hp-basic and they doesn't seem to work on my 39g. Greets, Rob ==== Please, where could someone buy the 49G+ in London? I will be spending the next year here doing an MSc in Imperial College, and I think that it would be very helpful to have a new calc, although my 49G and 32SII are always there when I need them. Alex Markatis Civil Engineer ==== > > Please, where could someone buy the 49G+ in London? > I will be spending the next year here doing an MSc in Imperial College, > and I think that it would be very helpful to have a new calc, > although my 49G and 32SII are always there when I need them. > > > Alex Markatis > Civil Engineer I live just outside london and have been monitoring the situation. Search ggogle for hp49g+ site:uk and you will find a company quoting Dec. Probably in a month or two Tottenham Ct Rd will be swarming with them. Doesnt the HPCC have meetings at Imperial (read up on comp.sys.hp48 and visit the freqntuly mentioned web sites to learn more). I think www.hpcc.org is the place you want. good luck! ==== > > Please, where could someone buy the 49G+ in London? > I will be spending the next year here doing an MSc in Imperial College, > and I think that it would be very helpful to have a new calc, > although my 49G and 32SII are always there when I need them. > > > Alex Markatis > Civil Engineer Classic Calculators should have them soon: http://www.davik.plus.com/index.html Aubrey. ==== Don't read this. It will be all greek to you... > Please, where could someone buy the 49G+ in London? > I will be spending the next year here doing an MSc in Imperial College, > and I think that it would be very helpful to have a new calc, > although my 49G and 32SII are always there when I need them. Ante man kalh tyxh sto metaptyxiako kai na koita3eis na mh se xalasoyn oi Aggloi ekei pera... Be well :) -- Al. Andreou ==== I'm trying to use the program hptalx on Debian Sid. Is there anyone who have used this program on Debian with success? I think the problem is in the configuration of lrzsz, who handle the serial port. Is there anybody who can help me? Ciao Angelo -- L'esperienza e' cio' che permette ad una persona di commettere nuovi errori invece che ripetere i vecchi. ==== --------------------------------------------------------------------- I have a version that works with the 48G as well as the 49G. The newer, according to the website, only works with the 48GII and the 49G+. But, the 48GII still have a normal serial port. Can I use the newer Conn4x with an HP48GX? It would be nice to have support for all the connectable calculators. Toby boundary=----=_NextPart_000_0008_01C3942A.730B6610 ==== --------------------------------------------------------------------- Well try it with 9600 baud setting (remember to use Xmodem) and tell us what happened. I have a version that works with the 48G as well as the 49G. The newer, according to the website, only works with the 48GII and the 49G+. But, the 48GII still have a normal serial port. Can I use the newer Conn4x with an HP48GX? It would be nice to have support for all the connectable calculators. Toby ==== I just saw, in Fry's (Manhattan Beach, CA) a rpn financial calculator (I did not buy it) it has the usual financial keys, e^x, log, no trig functions, and some keys related to programming (prm, x<=y, ...). No '=' key, just enter. Don't know how much programming capability it has. Martin Cohen ==== In message , Martin >I just saw, in Fry's (Manhattan Beach, CA) a rpn financial calculator >(I did not buy it) it has the usual financial keys, e^x, log, >no trig functions, and some keys related to programming (prm, x<=y, >...). > >No '=' key, just enter. > >Don't know how much programming capability it has. It's a straight clone of the 12C, including the same 99 steps of keystroke programming. -- Bruce Horrocks Surrey England ==== > I just saw, in Fry's (Manhattan Beach, CA) a rpn financial calculator > (I did not buy it) it has the usual financial keys, e^x, log, > no trig functions, and some keys related to programming (prm, x<=y, > ...). > > No '=' key, just enter. > > Don't know how much programming capability it has. > > Martin Cohen > Here is a link to one: http://shop1.outpost.com/product/3783316 Charles Perry P.E. ==== >> I just saw, in Fry's (Manhattan Beach, CA) a rpn financial calculator >> (I did not buy it) it has the usual financial keys, e^x, log, >> no trig functions, and some keys related to programming (prm, x<=y, >> ...). >> >> No '=' key, just enter. >> >> Don't know how much programming capability it has. >> >> Martin Cohen >> > Here is a link to one: > http://shop1.outpost.com/product/3783316 > Charles Perry P.E. Now if only that company would make an HP-15C clone! Or even a 10C! I would buy ten of them! -- -Joshua Belsky jjbelsky@yahoo.com http://belsky.net ==== > Some people have a slight problem with the keyboard. They can learn to > press a little harder. > I don't agree. This keyboard causes a lot of mistakes and slows down the use. A 50$-Casio or even a TI has a better handling with the keyboard. Nevertheless, the HP has the better operating-system and and the better concept. Stefan ==== > > Some people have a slight problem with the keyboard. They can learn to > press a little harder. > > > > I don't agree. This keyboard causes a lot of mistakes and slows down X ??? I tested some calculators (49G+) on users with various backgrounds and NONE of them hit the keys so that there would be mistakes Looks like only an old HP 48 user is going get some misses I should try more people - you need a light touch. Hmmm....maybe because the situation and the calc is new to them people tend to press the keys carefully? This needs more testing PS: Only some calcs have these slight problems with kb BUT almost every *old* hp user is going to have some trouble so I agree that it has to be fixed.... ==== Some Clarification: As a working engineer, I know from painful first experience, that switching tools can be a real pain--and a time sucker. Yes, the 49G+ is more capable, yes, the various flaws may and hopefully will be worked out, but in the mean time the best solution for everyday needs is to find a copy of what one already uses. regarding buggy--I refer merely to the reports here in c.s.hp48 regarding battery drain, as well as other more nebulous issues (issues that may be user-rather than hardware-for instance stuff with file transfer). regarding documentation: lots of PDF pages does not automatically equal good. No, I have not read the whole thing yet, but from perusing it, I don't see great improvement over the 48. Outsourced--that merely means that there is likely to be more trouble than has already been found (so I am a pessimist---I DEAL with outsourcing every day!) Hardware Problems----numerous reports of keypress non-registering issues. Well, IF and WHEN hp fixes these issues, we will here about it here on the c.s.hp48---until then, hold your horses if you are a practical man just needing a reliable tool.... And somehow, I DO think hp will get the hardware right this time...but be patient. Bill > > > > > > > > I am an Engineer, and my HP28S just died. I would like to buy a HP48GX > > or a HP49G but they are discontinued. Does anyone know where I might > > find one in the US or Canada? > > Get the new hp 49g+ > http://www.hpcalc.org/hp49gplus.php > It's fast, has USB, IrDA, SD/MMC interface > > > Yes, BUT it is also: > *new > *buggy > *poorly documented > *outsourced > *presented with physical problems > > > If you are an engineer looking for a reliable piece of equipment, by all > means use something proven--like the 48 or the 28. (I am an engineer and > use the 48 and the 32 and the 15). > > > Maybe the 49+ will eventually prove to be good--but it sure is not, yet. > > > > > Bill > > > > ==== > Some Clarification: X > regarding documentation: lots of PDF pages does not automatically equal > good. No, I have not read the whole thing yet, but from perusing it, I > don't see great improvement over the 48. X Yes, but you have never tried to use a 49G with it's manuals PS: the new machine is simply fast, modern and pretty. ==== Veli-Pekka Nousiainen replied: > >>Some Clarification: > > X > >>regarding documentation: lots of PDF pages does not automatically equal >>good. No, I have not read the whole thing yet, but from perusing it, I >>don't see great improvement over the 48. > > X > Yes, but you have never tried to use a 49G with it's manuals The advice I read WRT the HP49 manuals, when the issue was the rebate (which I got) was that you might as well cut all the way through em to get the bar-code, as the manuals were pretty much worthless. Having tried to use them to find out how to solve specific problems, I can verify the accuracy of the claim. It's a shame, as HP's manuals used to be the best around. Rich > PS: the new machine is simply fast, modern and pretty. > > ==== > Veli-Pekka Nousiainen replied: message > X >>regarding documentation: lots of PDF pages does not automatically equal >>good. No, I have not read the whole thing yet, but from perusing it, I >>don't see great improvement over the 48. > X > Yes, but you have never tried to use a 49G with it's manuals > > The advice I read WRT the HP49 manuals, when the issue was the rebate > (which I got) was that you might as well cut all the way through em > to get the bar-code, as the manuals were pretty much worthless. Having > tried to use them to find out how to solve specific problems, I can > verify the accuracy of the claim. > > It's a shame, as HP's manuals used to be the best around. Well the new manuals ARE good! (and the best around) Any old 49G user should download the new manuals immediately http://www.hpcalc.org/hp49gplus.php Directly: User Guide (856 pages) http://h20015.www2.hp.com/content/common/manuals/bpia5324/bpia5324.pdf User Manual (176 pages) http://h20015.www2.hp.com/content/common/manuals/bpia5323/bpia5323.pdf ==== > *poorly documented > > Around 1000 pages in the manuals and a lot of 49G and 48 literature applies. How good are those 1000 pages, though? (Although it does seem better than the 49G documentation, it has lots of room for improvement.) -- Bhuvanesh ==== > > *poorly documented > > Around 1000 pages in the manuals and a lot of 49G and 48 literature applies. > > How good are those 1000 pages, though? (Although it does seem better > than the 49G documentation, it has lots of room for improvement.) Much better than TI 89 manuals ! I enjoy the detailed matix operations like Chapter 11 Matrix operations and linear algebra Gauss-Jordan elimination with full pivoting Calculating the inverse matrix step-by-step and I also like this one Chapter 16 Differential Equations Applications of Laplace transform in the solution of linear ODEs Defining and using Heaviside's step function in the calculator ... AND the rest of that chapter is simply amazing! PS: For the first the confidence intervals and hypothesis testing are properly explained in the 49 manuals ==== > Much better than TI 89 manuals ! My comments weren't intended to be flame bait. They simply expressed my opinion. Bhuvanesh. ==== > Much better than TI 89 manuals ! > > My comments weren't intended to be flame bait. > They simply expressed my opinion. OK, tell then that you'd wish that TI would enahnce the manuals rather than cut back. The current TI manuals are worse than the older, true, eh? ==== > > Much better than TI 89 manuals ! > > My comments weren't intended to be flame bait. > They simply expressed my opinion. > OK, tell then that you'd wish that TI would enahnce the manuals > rather than cut back. > The current TI manuals are worse than the older, true, eh? Oh, you mean the module things? I don't use those. I much prefer a single document. -- Bhuvanesh ==== HAHAHAHAHAHAHAHAHAHAHAHA Sorry, I could not control it. I didn't know other esotericist lurked here. you put up a webpage about the compiler don't forget to include it to the Brainfuck category in ODP (http://dmoz.org/) and submit it to the Brainfuck archive at http://esoteric.sange.fi/. -- Al. Andreou ==== > then, it still sounds stupid--as there is nothing inherently evil in having > that interest. Ugh, visions of CF as a dungeon mistress, ugh... -- Al. Andreou ==== 81B1? Ooh! Ooh! Saturn opcodes are in the new machines, and is willing to tell us what they are? I found one in the code for A-> and MAKESTR, namely, 81B1: The old HP48/49G return-to-RPL code is: 142 164 808C This disassembles as A=DAT0.A D0+5 PC=(A) of course. The new 49g+ return-to-RPL code is: 81B 164 808C which disassembles as garbage, because there cannot be an 81B opcode, but there can be an 81Bx opcode, of which 81B1 is undefined in the old Silicon Saturn. So, does 81B1 perform a return-to-RPL? If so, was 81B1 merely dropped on top of the old code, leaving the rest of the nibbles (64808C) as dead code, to prevent entry points from moving? Or is something more wonderful and mysterious going on here? And what other new codes are there? Please please please... I'm dying to know... -Joe- ==== > AFAIK, unless you patent your algorithm for > every possible way it may be used, anybody > may use it. All you own at the moment is the > and I guess it could be named 'Horn Algorithm' > if it's truly new. So if you don't want > others to freely use your algorithm, patent it > or keep it for yourself; Both being Bad Things > anyway in my opinion. I agree that keeping it to myself would be a Bad Thing, which is why I and will post it in full shortly, and (c) took a vow never to do that with anything. ;-) As for patenting it, wouldn't it be a Good Thing IF I did that AND (a) either gave or licensed it to HP for them do put it into their calculators, and (b) released it for free use by everybody EXCEPT as a built-in feature of any handheld device? That way, everybody would benefit, even TI and their ilk could offer it as add-on software. Only HP would be able to advertise the best fraction calculators where best refers to the fractions, not to the calculators, of course. >:-O Since all this is currently being appraised by Powers That Be, *please* advise if I'm blissfully strolling down a primrose path, since I am not familiar with the legalities involved. If it DOES get patended, it will be known as the PDQ Algorithm, not Students would see a button that says HORN, and they'd push it, and complain that it doesn't work. The preceding is a printable paraphrase of what was actually said. ;-) I'll bet anybody here up to $1.53 that it is in fact a new algorithm. This offer will stand until the first time I lose the bet, at which time all bets are off. :-b -Joe- ==== Here's the first subprograms needed (working on the rest): @ IDIV2 - Quotient and Remainder @ @ bytes: 30.0 @ check: #C142h (48) @ not needed on 49 @ @ In: 2: a @ 1: b @ @ Out: 2: q @ 1: r @ @ so that b*q + r = a @ << DUP2 MOD ROT OVER - ROT / SWAP >> @ ->CF - Create Simple Continued Fraction @ @ bytes: 98.0 (48) @ 96.0 (49) @ check: #E52Bh (48) @ #5800h (49) @ @ In: 1: x @ @ Out: 1: { a0 a1 .. an }, ai integer (any i), and ai>0 for i>0 @ @ x = a0 + 1/(a1 + 1/(.. + 1/an)) @ << DEPTH -> D << @ turn x into p/q DUP MANT 1E11 * OVER / SWAP OVER * @ stack holds 2:q 1:p, with ri = p/q WHILE @ calculate ai OVER IDIV2 DUP REPEAT @ stop when remainder is zero @ calculate ri+1 ROT END ROT DROP2 D DEPTH SWAP - ->LIST >> >> Werner ==== -=[ Fri, 17.10.03 07:25 a.m. +1300 (NZDT) ]=- in message ID <44ec85ff.0310160809.5da536fa@posting.google.com> : > Here's the first subprograms needed (working on the rest): > @ IDIV2 - Quotient and Remainder > @ > @ bytes: 30.0 > @ check: #C142h (48) > @ not needed on 49 > @ > @ In: 2: a > @ 1: b > @ > @ Out: 2: q > @ 1: r > @ > @ so that b*q + r = a > @ > << DUP2 MOD ROT OVER - ROT / SWAP >> I *never* realized that MOD would do the job there. I did wonder, but never tested it. Great - you have made an IDIV2 for the 48 :) > @ ->CF - Create Simple Continued Fraction > @ > @ bytes: 98.0 (48) > @ 96.0 (49) > @ check: #E52Bh (48) > @ #5800h (49) > @ > @ In: 1: x > @ > @ Out: 1: { a0 a1 .. an }, ai integer (any i), and ai>0 for i>0 > @ > @ x = a0 + 1/(a1 + 1/(.. + 1/an)) > @ > << > DEPTH > -> D > << > @ turn x into p/q > DUP MANT 1E11 * OVER / SWAP OVER * > @ stack holds 2:q 1:p, with ri = p/q > WHILE > @ calculate ai > OVER IDIV2 DUP > REPEAT @ stop when remainder is zero > @ calculate ri+1 > ROT > END > ROT DROP2 > D DEPTH SWAP - ->LIST > >> >> This is much better than my current version: << DUP IP 1 ->LIST SWAP E12 SWAP FP OVER * WHILE DUP 0 > REPEAT DUP 4 ROLLD IDIV2 3 ROLLD + 3 ROLLD END * + >> This returns a zero on the last position (that last * + does that), but I can see you will use DEPTH with your string to figure out how far to go with it. Interesting how you use the stack - I must expand my imagination - it only extends to a 4 levels I really look forward to your next instalment :) I will try your ->CF today. It is a work of ART!!! I wondered about MANT as well. Your MANT E11 * is probably better than FP E12 * - then your OVER / creates a perfect E12 :) Very interesting. Is it true that I could take your text above, store it in a file on the desktop and then transfer it to a HP48/49 and it would work? Could you point me to something at www.hpcalc.org that explains this format, especially the @ for comments ? -- Tony Hutchins New Zealand ==== > I *never* realized that MOD would do the job there. Is there any other way? Any other method (e.g. / IP first) gets roundoff errors. > Your MANT E11 * is probably better than FP E12 * > - then your OVER / creates a perfect E12 :) Because of MOD's accuracy, you don't need to turn the input into a ratio of huge integers; just start with the unmodified input as the numerator, 1 as the denominator, and start looping. Cool, huh? It's *mathematically* identical to what you were doing, but faster and just as accurate, thanks to HP's MOD code. -Joe- ==== -=[ Fri, 17.10.03 12:59 p.m. +1300 (NZDT) ]=- in message ID <87233f9e.0310161327.2963399e@posting.google.com> : > > I *never* realized that MOD would do the job there. > > Is there any other way? Any other method (e.g. / IP first) gets > roundoff errors. There was another way I did it my way with IP first. This was my IDIV2: << N D / IP DUP 0 > <<1 ->>IFT 'Q' STO N D Q * - 'R' STO WHILE R D >= REPEAT R D - 'R' STO Q 1 + 'Q' STO END Q R >> If my IP was positive I took 1 away from it, and then, I gave it back if it were needed. Hehe. Rather pointless I admit, given that we have MOD ;-) LOL! You should have seen my first version - it built up the 'Q', one by one, from zero, but it was a bit slow. > Your MANT E11 * is probably better than FP E12 * > - then your OVER / creates a perfect E12 :) > > Because of MOD's accuracy, you don't need to turn the input into a > ratio of huge integers; just start with the unmodified input as the > numerator, 1 as the denominator, and start looping. Cool, huh? It's > *mathematically* identical to what you were doing, but faster and just > as accurate, thanks to HP's MOD code. WOW is all I can say. The code shrinks. IDIV2 is not needed (well, can't be used then). MOD gives the remainder to carry forward - meanwhile we need to reconstruct the integral quotient that we capture: N D MOD gives R, and Q=(N/D -R)/D which will be an exact integer, thanks to the MOD :) two about PDQ :) -- Tony Hutchins Wellington New Zealand #191 Whom God wishes to destroy, he first makes mad. Proverb ==== -=[ Fri, 17.10.03 2:05 p.m. +1300 (NZDT) ]=- in message ID <10889033ROBOTLX@news.cis.dfn.de> : [...] > WOW is all I can say. The code shrinks. IDIV2 is not needed > (well, can't be used then). MOD gives the remainder to carry > forward - meanwhile we need to reconstruct the integral quotient that > we capture: N D MOD gives R, and Q=(N/D -R)/D which will be an > exact integer, thanks to the MOD :) Whoops! Q=(N-R)/D -- Tony Hutchins Wellington New Zealand #302 When you win, nothing hurts. Joe Namath ==== > Congratulations to Tony Hutchins! He wins the Best Fraction > Challenge! In fact, he's the first person to post a program that > finds the two smallest integers which divide to any given decimal in > less than 5 seconds! Well done! I still havent got it right with the Evil ones, But for what it is worth, in my longfloat (arbitrary precision) library there are 3 simple commands - for converting a longreal to a simple fraction - for converting a simple fraction to a continued fraction - for converting a continued fraction to a simple fraction The continued fractions use lists. But no minimum fractions:-( Gjermund Skailand ==== -=[ Thu, 16.10.03 6:07 p.m. +1300 (NZDT) ]=- in message ID <87233f9e.0310151125.12e1b945@posting.google.com> : > Congratulations to Tony Hutchins! He wins the Best Fraction > Challenge! In fact, he's the first person to post a program that > finds the two smallest integers which divide to any given decimal in > less than 5 seconds! Well done! I'll still be looking at this till Christmas I think. My old paper HP49G Advanced User's Guide (the one with the black cover - must be rare), just told me that IDIV2 does exactly what my 'NDQR' code does. And it works great too - eg E12 500000000001 IDIV2 gives 1 and 499999999999 - even in approx mode (contrary to the manual). > Joe, you must tell us the story as to > how you came to investigate this - > .. if there is a story :-) Is it part > of a book/paper you intend to publish? > > Sorry, no story. Just one of the things I've stumbled into > while playing around with numbers and HP calculators for > the past 27 years. However, I'm currently working with HP > to see that this algorithm, which I call the PDQ algorithm > (P Divided by Q), will be used in place of the current > ->Q algorithm in future models. Great idea!!! I look forward to that. It might even be in a future 49g+ ROM :) > However, my proposal goes beyond that, allowing the > accuracy to be specified several ways: by a maximum > tolerable error, or maximum tolerable denominator, > or minimum exact-match decimal places, or real-world > tolerance by a user-specified scalar. Terrific. I see the old ->Q in there somewhere ;-) > Finally, some sort of Fraction Hunter application (Fraction > Ranger? Fraction Scout? Best Fraction Finder? PDQ?) HP can invent a name :) Harvester ? Picker? Your PDQ is so thorough in finding excellent and useful fractions. And surprising fractions! It is almost forensic. It finds new fractions. And it works right up to the limits of the HP48/49 precision, because of that 15 digit thing you mentioned, and the internal rounding. > would allow the user to see simultaneously the input, > the output, the previous and next fraction (if any), their > respective errors, and real-world scalar error, with options > to single-step and back-step through the continued-fraction > convergents and/or intermediate convergents. Will be very educational. I hope there is also a built-in partial quotient generator. They are so interesting. And the reverse. ->PQ and PQ-> :) GCD must already do something like that internally. > This would be helpful in many real-world applications that > rely on precise tolerances, and it would also be ideal for > teaching fractions, decimals, continued fractions, rationals > and irrationals, and many other concepts. Indeed. Now I know why your domain is holyjoe - you like whole numbers :) > If HP doesn't bite the bait, I'll just publish it all on > the web for all to see and use as they wish. Meanwhile, have > fun with it! *I* am sure HP will use it :) And soon, I hope. I looked up my old 1965 Encyclopedia Britannica - it has a there jumps to more complex features. > Legal Fine Print [...] Hehe I have done you a favour then - anybody studying my code would just get very confused - no chance of translating it :) It's amazing the piracy that happens in business circles though - recently I was pointed to an *non hp* financial calculator which seems to be a 12C clone!!!!! (I ordered one). -- Tony Hutchins New Zealand ==== Joe defines a best fraction for the purposes of this challenge as: the smallest integers which, when divided on the calculator, yield exactly the same number as the input. Let us call this a Best(JH) fraction. There might be other best fractions which are not Best(JH). To use one of Joe's examples: Input: 6.0030000004 (the strange number on the HP38G case) Output: 14823406 / 2469333 Two other fractions which both evaluate to 6.0030000004 on the HP48 are: 15009499/2500333 and 15195592/2531333 They have special properties; who can characterize them? I think one might say that best is in the eye of the user. For example, suppose one were designing a synthesiser to generate a 6.0030000004 Hertz frequency. One way to do it would be to buy a crystal oscillator running at a frequency of 14823406 Hertz and divide that output by 2469333; this would be the Best(JH) way to do it, but would it be the best way? What does best mean for you? Joe's challenge is fascinating and difficult, but I'm not sure that the Best(JH) fraction is the best except in curiosity and educational value. Can anybody think of a situation where 14823406/2469333 would be preferred to 15009499/2500333 as an approximation to 6.0030000004? When would the slightly smaller numerator and denominator of 14823406/2469333 compared to 15009499/2500333 be of value, given the special property of 15009499/2500333 (said property to be determined by the audience). The ->Q function on the HP48 gives 15003496/2499333 for 6.00300000004 (in STD mode), which lacks the special property that 15009499/2500333 has. This posting is not meant to belittle or minimize this latest excellent challenge of Joe Horn (who is a friend of mine). :-) ==== > I think one might say that best is in the eye of the user. Hurwitz and most other mathematicians agree with you. In fact, my full PDQ package outputs the Hurwitz Accuracy of each convergent (calculated as the actual error times the denominator squared times the square root of five) so that the user can base his or her decision on that, if they wish. Loosely, the Hurwitz Accuracy of a convergent is a kind of ratio of the number of digits of input over the number of digits of output. If making gears, for example, it would make no sense to go from a 22/7 gear ratio to a 179/57 gear ratio in an attempt to approximate pi, because even though 179/57 is a better fraction for pi, it offers only 0.0000227 increase in accuracy, roughly 2 centimeters per kilometer! This can be seen easily by looking at the Hurwitz Accuracy of 22/7 for pi (namely, -0.138546713972020) versus the Hurwitz Accuracy of 179/57 (namely 9.021486720965779). Hurwitz proved that any convergent with an Hurwitz Accuracy less than 1 (absolute value) must be a continued fraction convergent, and not merely one of the intermediate convergents. In brief, the continued fraction convergents yield the best fractions IF AND ONLY IF the bang per buck is considered, that is, the number of digits you get out compared to the number of digits you put in. In this sense, there is no better fraction than 355/113 for pi until you get out to something 440 digits. The calculation of that fraction is left as an exercise for the reader. ;-) Hurwitz Accuracy is only one kind of accuracy. There are others, each appropriate for some particular tasks. I discussed several in my conference paper. > What does best mean for you? As I hope I explained during this thread already, it means different things for different *purposes*. If one's task demands a complete and accurate examination of ALL the fractions that approach any given decimal number, then every fraction in that list is a best fraction, and the PDQ Algorithm is the only way to find all of them. On the other hand, if one has no need of precision or completeness, then the age-old continued-fraction-only algorithm based on 1/FP(x) will suffice, such as HP's ->Q. > Joe's challenge is fascinating and difficult, > but I'm not sure that the Best(JH) fraction > is the best except in curiosity and > educational value. Fun and learning. Everything comes down to those two. -- Donald Shimoda, reluctant messiah. PDQ solves a previously unsolved problem. Why? Because it was there, and nobody else was trying to solve it. Amen. > Can anybody think of a situation where > 14823406/2469333 would be preferred to > 15009499/2500333 as an approximation to > 6.0030000004? Yes! HP *claimed* to offer the smallest fraction equal to the displayed decimal number with the ->Q function. It cannot read your mind to know what YOU mean by best, so it simply churned out the smallest fraction equal to the input (in STD mode)... or at least it was SUPPOSED to. PDQ does exactly what ->Q claimed to do but never did. > When would the slightly smaller numerator and > denominator of 14823406/2469333 compared to > 15009499/2500333 be of value, given the special > property of 15009499/2500333 (said property to > be determined by the audience). Is said property that the latter has a much better Hurwitz Accuracy, namely 0.7447095671868303496, as compared to -67.732319542344457 for the former? If that's not the one you had in mind, it's still true. > The ->Q function on the HP48 gives > 15003496/2499333 for 6.00300000004 > (in STD mode), which lacks the special > property that 15009499/2500333 has. The former has a Hurwitz Accuracy of -1.491059671430066483, which also not as good as the latter's (given above). Something that Hurwitz seemed not to notice (or care about) is that his definition of best omits not only all of the intermediate convergents (as it seems you too would prefer to do) but also all the regular ones based on a partial quotient that is smaller than the largest one so far. This would mean that pi only has 3/1, 22/7, and 355/113 as best fractions, with the next best fraction having something around 440 digits in it. An algorithm that spits out THOSE fractions is trivial, and pretty useless considering the paucity of fractions it generates. It doesn't find ANY for the square root of 3 (other than 2/1, which is not very satisfying!). > This posting is not meant to belittle > or minimize this latest excellent challenge > of Joe Horn (who is a friend of mine). :-) You, Bob Wilson, and Bob Hall have given me no end of delightful food You to y'all! The best payment for a good idea is another good idea. -- Richard J. Nelson -Joe- ==== -=[ Thu, 16.10.03 12:39 p.m. +1300 (NZDT) ]=- in message ID <87233f9e.0310141508.48ab1978@posting.google.com> : > *That* is what gave me the clue to doing > the expansion - I don't start with .500000000001 > but that*E12 /E12 - I start with an integral > hidden tip!! > > That's the trick for avoiding the 1/FP(x) roundoff errors that have > plagued decimal-to-fraction algorithms forever. They have indeed - I looked into decimal->fraction using continued fractions earlier this year. And everything I saw used the 1/x. I started with the PPC ROM version - always a good place to start :) Joe, I don't know how, but I missed this post yesterday - despite eagerly looking out for another hint!! > You have taken your first steps into a larger world. > -- Obi-Wan Kenobi Indeed, the wholesome world of integers :) > I seem to be stumped as to how to hop, skip > and jump to near the 33333333335 denominator. > > MASSIVE HINT (spoiler, actually) #2: With the list of > partial quotients handy, examine the *differences* between > successive intermediate convergents' numerators. Now do > the same for their denominators. When the pattern hits > you, it'll hit you hard, so be sure to be sitting down! Ahha! I missed this spoiler, and I only started looking at this out of desperation. I noticed one example by chance - that 2 LOG SQRT case. I got there by trial and error with little understanding. But, what a thrill to see it work for all cases! Actually successive convergents are very closely related - multiplying numerators by the others denominators and taking the difference one seems to get 1!!! [...] > although the results go up and down in a sawtooth > like way, overall they are probably well-behaved. > > Indeed they are. Have fun! I did - and now I might try and improve the RPL by using INCR and STO+ etc and see how many globals I can just keep on the stack instead. And I should prove to myself that there are no other better candidates lurking. Fascinating. It has a certain beauty and simplicity, once one -- Tony Hutchins Wellington New Zealand #229 It's not over till it's over. Yogi Berra ==== -=[ Thu, 16.10.03 6:51 p.m. +1300 (NZDT) ]=- in message ID <10901473ROBOTLX@news.cis.dfn.de> : > Joe, I don't know how, but I missed this post yesterday - > despite eagerly looking out for another hint!! about the time I did a chkdsk /f and found cross-linked files. My poor old DOS machine was the problem, not cis.dfn.de, nor my home-grown newsreader. First time I have seen this - everything looked like it was working fine, but ... the - Tony ==== I am new to Grobs for my HP39G. Using XNVIEW to create a .gro from a .jpg, and then GRS64 to create the Aplet from that; how do I (first?) reduce the ~80K jpg (ex camera) down to 131x64 pixels? many thanks, Minkey. ==== Several months ago my HP 48SX became sluggish in powering on. Momentarily depressing the ON key won't power it up. In frustration I discovered that holding the A and ON keys simultaneously would turn it C. -- C. -- Charles Poynton ==== Well, it's nice to see another RPN calculator on the market. If they could make a scientific version before the April FE exams, they would have quite a business! I think the state boards will have to stand up to the NCEES on their calculator policy. What are the choices currently being produced for RPN scientific calculators? Kevin ==== According to the comparison sheet, the 49G+ does not support aplets. Is this saying that you can't run after market user written programs? If this is not true, will the 49G+ support most of the current 49 programs on HPCALC.ORG? TIA