HP-9 ==== original HP48G series manuals. Does anyone know of any good sites that sell them?!? I am also trying to find a decent introductory guide to SysRPL programming for the 48, as well. Grant. ==== If you want to buy a new set of documentation for the 48 series, look on ebay for nmz, I've bought many items from him and his service is outstanding. Hope this helps. Roberto. > original HP48G series manuals. Does anyone know of any good sites that sell > them?!? I am also trying to find a decent introductory guide to SysRPL > programming for the 48, as well. > Grant. ==== > original HP48G series manuals. Does anyone know of any good sites that sell > them?!? Try http://www.calcpro.com/ or http://www.hpcalculators.com/, or maybe search on eBay. > I am also trying to find a decent introductory guide to SysRPL > programming for the 48, as well. Try http://www.hpcalc.org/ or http://membres.lycos.fr/ekalin/index.php. -- James ==== I can't tell from the terse description and the lack of an image, but this sounds like a possible lead: http://www.calculatorsource.com/hp-49g-adv-manual.html > original HP48G series manuals. Does anyone know of any good sites that sell > them?!? I am also trying to find a decent introductory guide to SysRPL > programming for the 48, as well. > > > Grant. > > > ==== FOLLOWUP: I must be an idiot. I went back to the beginning and used the DEFAULT posts helped me very much. Jim ==== The HP-49g+ is available now from CalcPro. I ordered mine from there and had it the next day. ==== Samson Cables now has them in stock. I preordered mine, and the tracking number confirms it has shipped today. > The HP-49g+ is available now from CalcPro. I ordered mine from there and had > it the next day. ==== Same here, got mine today from Samson cables. > Samson Cables now has them in stock. I preordered mine, and the tracking > number confirms it has shipped today. > The HP-49g+ is available now from CalcPro. I ordered mine from there and > had > it the next day. > > ==== > I suppose there are different ROM versions, if the power problem was fixed > with one. > Do you know where to get the latest ROM from? > > Dave > It's on HP's website: http://h20015.www2.hp.com/en/softwareCategory.jhtml?reg=&cc=us&pagetype=soft ware&prodId=hp49ggraph351775&lc=en&sw_lang=en&docparent=software ==== I can verify that the 49G+ colon blinks irregularly, but the slight flickering at the bottom is present regardless of the clock setting here. > > Can you confirm my observations? > > Michael > ==== > I can verify that the 49G+ colon blinks irregularly, but the slight > flickering at the bottom is present regardless of the clock setting here. It seems that the slight flickering of the bottom pixel lines in the label area is gone with the latest ROM I'm not sure, your search the net and try it yourself. ==== > in the label area is gone with the latest ROM That is? Later as 1.22? Michael -- -= Michael Hoppe , =------ ==== Is there a ROM newer than 1.22? I still have the flickering with it... > >>I can verify that the 49G+ colon blinks irregularly, but the slight >>flickering at the bottom is present regardless of the clock setting here. > > It seems that the slight flickering of the bottom pixel lines > in the label area is gone with the latest ROM > I'm not sure, your search the net and try it yourself. > > ==== > Is there a ROM newer than 1.22? I still have the flickering with it... ??? It must be my eyes then.... ==== Veli, I am currently having the same issue. Did you ever manage to resolve this one? I also downloaded...and I think I installed the new ROM...might have done something wrong though, Im not sure. Does the calculator display any sort of message if you have updated the ROM correctly, or is there a location within the calculator I can view the current ROM version? -Tristan > Is there a ROM newer than 1.22? I still have the flickering with it... > ??? > It must be my eyes then.... ==== > Veli, > I am currently having the same issue. Did you ever manage to resolve > this one? I also downloaded...and I think I installed the new > ROM...might have done something wrong though, Im not sure. Does the > calculator display any sort of message if you have updated the ROM > correctly, or is there a location within the calculator I can view the > current ROM version? > -Tristan > > Is there a ROM newer than 1.22? I still have the flickering with it... > ??? > It must be my eyes then.... I repeat: It must be my eyes then.... ==== > Probably in a month or two Tottenham Ct Rd will be swarming with them. I am there every weekend but still no sign... Arnaud ==== > > 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 Tomorrow you can test it yourself, but I *guess* that even if it works, it does not take the new header area in it most propably works using the old lower area of the display only. Excuse my limited SysRPL knowledge and reluctance for testing I'm currently translating some text for Finnish users and have unfortunately no time for tests, sorry > 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 ==== The detailed physics of what goes on in an engine are not really fully understood - turbulence, flame propogation, etc. all have effects on combustion efficiency and emissions, and the equations cannot be solved analytically. A numerical simulation with any significant detail of one combustion event in a single cylinder takes days on modern computers. It's not a trivial problem that automotive companies neglected because it would cost money; it's an ongoing research problem that they're spending millions of dollars on trying to improve. > You are correct. However the main reason this happened was that > Detroit was unwilling ( ie.TOO CHEAP) to redesign the gasoline engine > from the ground up to emit fewer pollutants Honda did start to work > on this problem with the stratified charge engine. At the time it met > all the EPA standards without a lot of the add on junk, that Detroit > used to meet the EPA standards on their autos. ==== > You are correct. However the main reason this happened was that > Detroit was unwilling ( ie.TOO CHEAP) to redesign the gasoline engine > from the ground up to emit fewer pollutants Honda did start to work > on this problem with the stratified charge engine. At the time it met > all the EPA standards without a lot of the add on junk, that Detroit > used to meet the EPA standards on their autos. Well, I do not know about the reason why, but I laught hard when I discovered what the air pump in my engine was for! (ie: When they do polution check for your car, they check what % of the exhaust is bad gases. So, how do you reduce the % of bad gaz? either you improve the engine (dificult), or you add some clean air in the exhaust! This is exactly what the air pump do, it injects some clean ari in the exhaust, effectively reducing the % of bad gaz from the engine! AND THIS IS LEGAL!) laught... ==== > (ie: When they do polution check for your car, they check what % of the > exhaust is bad gases. So, how do you reduce the % of bad gaz? either you > improve the engine (dificult), or you add some clean air in the exhaust! > This is exactly what the air pump do, it injects some clean ari in the > exhaust, effectively reducing the % of bad gaz from the engine! AND THIS IS > LEGAL!) Forgive an off-topic note, but in post-1975 cars here in the US, the air pump doesn't provide enough air to dilute the exhaust significantly. However, it does provide enough oxygen to combust any carbon monoxide, most particulates, and other pollutants while still in the exhaust system. Especially if there's a catalytic converter as well. Also, here the pollution rules specify grams of each item, not percentage. So dilution won't help pass anyway. Regarding computation of engine operation - in the '70s when the first full 3D analysis was done the results were immediately suspect as they showed the air as oscillating at a varying frequency unrelated to the combustion cycle. Only later did someone notice that the cylinder is a closed resonant chamber and the oscillation was the acoustics that really do take place but don't show up in a gross pressure measurement. Nothing like a multikilowatt slide whistle to enliven analysis! Best to you - Jim Horn ==== It looks like there's a bug in the division code in all HP 12-digit calculators. When almost any whole number is divided by certain powers of 2, the last digit is rounded incorrectly... not earth-shattering, but surprising, especially after all the work HP did with Prof. Kahan to get every digit correct. Simplest example: 4097/4096 is mathematically equal to 1.000244140625 ... which clearly should be rounded to 1.00024414063 ... but HP truncates it instead, getting 1.00024414062 ... inconsistent with HP's round up from 5 rule. In case the above is not clear, here's one that should be. 100000000001 2 / --> 50000000000.5 (correct) 200000000001 2 / --> 100000000000 (wrong) Strangely, the correct answer is obtained by using the obvious System RPL code: :: 2%>%% %%/>% ; Strange. -Joe- ==== > It looks like there's a bug in the division code in all HP 12-digit > calculators. > > When almost any whole number is divided by certain powers of 2, the > last digit is rounded incorrectly... not earth-shattering, but > surprising, especially after all the work HP did with Prof. Kahan to > get every digit correct. > > Simplest example: 4097/4096 is mathematically equal to > 1.000244140625 ... which clearly should be rounded to > 1.00024414063 ... but HP truncates it instead, getting > 1.00024414062 ... inconsistent with HP's round up from 5 rule. > > In case the above is not clear, here's one that should be. > > 100000000001 2 / --> 50000000000.5 (correct) > 200000000001 2 / --> 100000000000 (wrong) > > Strangely, the correct answer is obtained by using the obvious System > RPL code: > > :: 2%>%% %%/>% ; > > Strange. > > -Joe- Joe? This cannot be you posting??? You see 'round to even' or 'unbiased rounding' at work. No other brand of calculators does that, and it's IEEE 854 (er.. not sure about the number) Consider this: if you were to 'round up' every time, then the errors would be: x round error x.0 0.0 0.0 x.1 0.0 0.1 x.2 0.0 0.2 x.3 0.0 0.3 x.4 0.0 0.4 x.5 1.0 0.5 x.6 1.0 -0.4 x.7 1.0 -0.3 x.8 1.0 -0.2 x.9 1.0 -0.1 As you can see, all errors cancel out on average - save for the midway .5 case. So IEEE 8xy included 'unbiased rounding': foe x even; x.5 rounds to x, for x odd it rounds to x+1, so the errors cancel out on average. The fact that in SysRPL you do get 'round up' is because the 'round to even' is only enforced in *single* *UserRPL* operations (that's why you have a PACK and a PACKSB entry in ML - PACKSB rounds the previous example to even, PACK rounds up). I have a zillion examples somewhere. Oh as I said, it applies only to single calculations - and no matrix calculation is considered a single calculation. so x*y is not always equal to [x]*y 1 GET (the first rounds to even, the second rounds up) boundary=----=_NextPart_000_0136_01C39518.923D9910 ==== --------------------------------------------------------------------- X > is only enforced in *single* *UserRPL* operations (that's why you have > a PACK and a PACKSB entry in ML - PACKSB rounds the previous example > to even, PACK rounds up). > > I have a zillion examples somewhere. Oh as I said, it applies only to > single calculations - and no matrix calculation is considered a single > calculation. > > so x*y is not always equal to [x]*y 1 GET (the first rounds to even, > the second rounds up) Well that's a neat trick, Werner! I hope we could have the 71B rounding settings for our new 49g+ For best viewing use fixed width font: Type of Flag Rounding -11 -12 ------------------- Near 0 0 Zero 0 1 Positive 1 0 Negative 1 1 ------------------- ==== Ha ha, but this is because HP is doing things in a little bit more subtle way in the case of a 0.5 rounding. It does not always do a round up (the type of rounding depends on the parity of the digit above the rounded value and if they were or were not a reminder in the division). > :: 2%>%% %%/>% ; works as you expect because the reminder of the division is lost in between the 2 sysrpl instructions... > It looks like there's a bug in the division code in all HP 12-digit > calculators. > When almost any whole number is divided by certain powers of 2, the > last digit is rounded incorrectly... not earth-shattering, but > surprising, especially after all the work HP did with Prof. Kahan to > get every digit correct. > Simplest example: 4097/4096 is mathematically equal to > 1.000244140625 ... which clearly should be rounded to > 1.00024414063 ... but HP truncates it instead, getting > 1.00024414062 ... inconsistent with HP's round up from 5 rule. > In case the above is not clear, here's one that should be. > 100000000001 2 / --> 50000000000.5 (correct) > 200000000001 2 / --> 100000000000 (wrong) > Strangely, the correct answer is obtained by using the obvious System > RPL code: > :: 2%>%% %%/>% ; > Strange. > -Joe- ==== ho, by the way, for fun, try: 200000000001 2 / --> 100000000000 and 200000000003 2 / --> 100000000002 :-) > Ha ha, but this is because HP is doing things in a little bit more subtle > way in the case of a 0.5 rounding. It does not always do a round up (the > type of rounding depends on the parity of the digit above the rounded value > and if they were or were not a reminder in the division). > :: 2%>%% %%/>% ; > works as you expect because the reminder of the division is lost in between > the 2 sysrpl instructions... > It looks like there's a bug in the division code in all HP 12-digit > calculators. > > When almost any whole number is divided by certain powers of 2, the > last digit is rounded incorrectly... not earth-shattering, but > surprising, especially after all the work HP did with Prof. Kahan to > get every digit correct. > > Simplest example: 4097/4096 is mathematically equal to > 1.000244140625 ... which clearly should be rounded to > 1.00024414063 ... but HP truncates it instead, getting > 1.00024414062 ... inconsistent with HP's round up from 5 rule. > > In case the above is not clear, here's one that should be. > > 100000000001 2 / --> 50000000000.5 (correct) > 200000000001 2 / --> 100000000000 (wrong) > > Strangely, the correct answer is obtained by using the obvious System > RPL code: > > :: 2%>%% %%/>% ; > > Strange. > > -Joe- ==== > Simplest example: 4097/4096 is mathematically equal to > 1.000244140625 ... which clearly should be rounded to > 1.00024414063 ... but HP truncates it instead, getting > 1.00024414062 ... inconsistent with HP's round up from 5 rule. I also get the 'wrong' answers on my HP42S. > 100000000001 2 / --> 50000000000.5 (correct) > 200000000001 2 / --> 100000000000 (wrong) I tested 'equivalent' numbers on my HP15C and 16C (10 digits calculators): 1000000001 2 / --> 500000000.5 2000000001 2 / --> 1000000001 -- ----- Qui peut m'expliquer comment fonctionne le fusible thermique sur les processeurs. Est ce que cela peut se configurer ? -+- DA in : : Neuneu p.8fte un plomb -+- ==== > It looks like there's a bug in the division code in all HP 12-digit > calculators. > > When almost any whole number is divided by certain powers of 2, the > last digit is rounded incorrectly... not earth-shattering, but > surprising, especially after all the work HP did with Prof. Kahan to > get every digit correct. > > Simplest example: 4097/4096 is mathematically equal to > 1.000244140625 ... which clearly should be rounded to > 1.00024414063 ... but HP truncates it instead, getting > 1.00024414062 ... inconsistent with HP's round up from 5 rule. > > In case the above is not clear, here's one that should be. > > 100000000001 2 / --> 50000000000.5 (correct) > 200000000001 2 / --> 100000000000 (wrong) > > Strangely, the correct answer is obtained by using the obvious System > RPL code: > > :: 2%>%% %%/>% ; > > Strange. Very interesting Joe; I never noticed that. But it's not just division; Try the following: .000000000005 1 + --> 1 .000000000015 1 + --> 1.00000000002 .000000000025 1 + --> 1.00000000002 .000000000035 1 + --> 1.00000000004 .000000000045 1 + --> 1.00000000004 .000000000055 1 + --> 1.00000000006 .000000000065 1 + --> 1.00000000006 .000000000075 1 + --> 1.00000000008 .000000000085 1 + --> 1.00000000008 .000000000095 1 + --> 1.0000000001 In high school science and in statistics, I was taught to never use the always round up when the last digit is 5 rule, but rather to choose to round to either the nearest even or the nearest odd numeral, to avoid introducing a bias. I've found the always round up rule on calculators to be a bit disappointing, but I guess that financial people do it that way. I'm guessing that a round to the nearest even numeral rule is used in these calculators when converting from extended reals to reals. -- James ==== It's me again. ;-) > I'm guessing that a round to the nearest even numeral rule is used in > these calculators when converting from extended reals to reals. But %%1.000000000025E0 %%>% returns %1.00000000003, so I guess that I guessed wrong. even numeral when the next digit is 5 with no non-zero digits trailing is also known as banker's rounding. Do bankers really do it this way? Are there any bankers, CPAs, or other financial types out there that could comment? Of course this banker's or unbiased rounding does, on average, tend to prevent a bias in the sum (and therefore average) of values, but introduces its own bias in the frequency of even values versus odd values. I'm not at all sure that anyone would care about this alternative bias, but I wonder whether there's a rounding rule that prevents this too. -- James ==== ARGH! > ..000000000005 1 + --> 1 > ..000000000015 1 + --> 1.00000000002 > ..000000000025 1 + --> 1.00000000002 > ..000000000035 1 + --> 1.00000000004 > ..000000000045 1 + --> 1.00000000004 > ..000000000055 1 + --> 1.00000000006 > ..000000000065 1 + --> 1.00000000006 > ..000000000075 1 + --> 1.00000000008 > ..000000000085 1 + --> 1.00000000008 > ..000000000095 1 + --> 1.0000000001 Make that: .000000000005 1 + --> 1 .000000000015 1 + --> 1.00000000002 .000000000025 1 + --> 1.00000000002 .000000000035 1 + --> 1.00000000004 .000000000045 1 + --> 1.00000000004 .000000000055 1 + --> 1.00000000006 .000000000065 1 + --> 1.00000000006 .000000000075 1 + --> 1.00000000008 .000000000085 1 + --> 1.00000000008 .000000000095 1 + --> 1.0000000001 -- James ==== PPS: displaying a doubled up . when it's at the beginning of a line. Now that seems really strange. I'm so confused.... -- James ==== > PPS: > displaying a doubled up . when it's at the beginning of a line. Now > that seems really strange. I'm so confused.... (NNTP). You'll see why a leading dot on a line must be doubled by the client software when sending. OTOH, the client software must remove any additional dot that was placed by the peer, so you normally shouldn't see the double dot. *That* is strange. -- ----- D'accord, mais si on se met .88 utiliser des arguments intelligents dans ce genre de d.8ebat, il devient impossible de discuter. Vous sombrez dans la facilit.8e. -+- TS in GNU : La dialectique n'est plus ce qu'elle .8etait. ==== > > >>PPS: >> >>displaying a doubled up . when it's at the beginning of a line. Now >>that seems really strange. I'm so confused.... > > > (NNTP). You'll see why a leading dot on a line must be doubled by the > client software when sending. Yes, thank you, I see. I've read these before, but at the time I was lines, so the significance of a . at the beginning of a line didn't stick with me, especially as this is supposed to be transparent to the applications. > OTOH, the client software must remove any additional dot that was placed > by the peer, so you normally shouldn't see the double dot. *That* is > strange. And if I choose View, Message Source, they aren't doubled there, and the copy in my Sent folder doesn't show them doubled. It's a mystery to me. I think that in the future I'll start any such lines with a space. -- James ==== Wanna see a happy fun bug? On your hp49g+, press PRG NXT NXT RUN NXT, and then PRESS AND HOLD DOWN the F1 key for a few moments. That's the OFF menu key, so the hp49g+ will turn off... but due to a bug in the 49g+, that key will be STUCK in the down position (logically, not physically), so that as soon as the calculator is turned on, it'll turn right back off again! Hah hah hah!!! >:-O How to exit: Press ON repeatedly very rapidly until you interrupt the cycle and crash the calculator. Nothing will respond until the F1 key lost; there is not even a warmstart. This stuck key bug can be used to get almost any key stuck; for example, type OFF in alpha mode and then press and hold down the ENTER key. Boom! Remember, the only way to unstick the ENTER key is by pressing it again. There is no need to press ON repeatedly, except in the unique case of the OFF key being stuck down. Here's a fun one: type OFF, then turn off alpha mode, and press and hold down the + key. Now when you turn back on, each press of the ON key darkens the display contrast, because the + key is stuck down! Press the + key to unlock the calculator, of course. OFF can be assigned to any key. Don't hold it down when you press it, though, or the machine'll lock up! Maybe it's not a bug, but a feature: a quick & easy way to lock the calculator so that your teacher can't find your cheat notes! -Joe- -alias Harvey Pitkin- ==== He also found a 49 with a key mounted upside down, I believe Joseph K. Horn escribi.97 en el mensaje > Wanna see a happy fun bug? On your hp49g+, press PRG NXT NXT RUN NXT, > and then PRESS AND HOLD DOWN the F1 key for a few moments. That's the > OFF menu key, so the hp49g+ will turn off... but due to a bug in the > 49g+, that key will be STUCK in the down position (logically, not > physically), so that as soon as the calculator is turned on, it'll > turn right back off again! Hah hah hah!!! >:-O > How to exit: Press ON repeatedly very rapidly until you interrupt the > cycle and crash the calculator. Nothing will respond until the F1 key > lost; there is not even a warmstart. > This stuck key bug can be used to get almost any key stuck; for > example, type OFF in alpha mode and then press and hold down the ENTER > key. Boom! Remember, the only way to unstick the ENTER key is by > pressing it again. There is no need to press ON repeatedly, except in > the unique case of the OFF key being stuck down. > Here's a fun one: type OFF, then turn off alpha mode, and press and > hold down the + key. Now when you turn back on, each press of the ON > key darkens the display contrast, because the + key is stuck down! > Press the + key to unlock the calculator, of course. > OFF can be assigned to any key. Don't hold it down when you press it, > though, or the machine'll lock up! Maybe it's not a bug, but a > feature: a quick & easy way to lock the calculator so that your > teacher can't find your cheat notes! > -Joe- -alias Harvey Pitkin- ==== > ... OFF menu key, so the hp49g+ will turn off... but due to a bug in the > 49g+, that key will be STUCK in the down position (logically, not > physically), so that as soon as the calculator is turned on, it'll > turn right back off again! Hah hah hah!!! >:-O OFF or TurnOff has various components. As far as I can see, the bug is in the DEEPSLEEP command which might have been reprogrammed. How to prove this? OT49+ has the command LMN (List Menu Names) which allows a customization of the builtin menus. I replaced the rompointer xOFF by { ID SLEEP :: TakeOVER DEEPSLEEP DROP ; }. This sets the PRG/RUN menu but with the menu name SLEEP instead of OFF (no wake-up by alarms in this simplification :-) The bug has serious consequences if reacting in panic. Pressing the first best keys may easily result in the TTRM screen. Even without choice to answer YES or NO. The calculator stays frozen with this screen. I noticed this already earlier but interpreted it erroneously as a bug in Keyman's reprogrammed longhold functionality tested on F1 with various actions. I didn't expect that such a horrible bug could be built in. DEEPSLEEP finally does what is expected: Trying to wake up the baby in deep sleep is unsuccessful. It immediately falls back into deep sleep. And if you try to wake it up by force, you get the revenge: A corrupted memory. - Wolfgang ==== > ... OFF menu key, so the hp49g+ will turn off... but due to a bug in the > 49g+, that key will be STUCK in the down position (logically, not > physically), so that as soon as the calculator is turned on, it'll > turn right back off again! Hah hah hah!!! >:-O X > various actions. I didn't expect that such a horrible bug could be built > in :-) No, no, no - it's not a bug! It's a feature! I will use it to lock my calculator! (and for fun!) ==== In <87233f9e.0310170006.3e6d0f14@posting.google.com> Joseph K. Horn > Wanna see a happy fun bug? On your hp49g+, press PRG NXT NXT RUN NXT, > and then PRESS AND HOLD DOWN the F1 key for a few moments. That's the > OFF menu key, so the hp49g+ will turn off... but due to a bug in the > How in heaven did you find that one? ==== > Wanna see a happy fun bug? On your hp49g+, press PRG NXT NXT RUN NXT, > and then PRESS AND HOLD DOWN the F1 key for a few moments. That's the > OFF menu key, so the hp49g+ will turn off... but due to a bug in the > > How in heaven did you find that one? As my grandmother would say, he's as tricky as a Priest. He has too much time on his hands! 8-) Tom Lake ==== Aplets simply do not apply to the HP48,49,49+ calcs. These are programs written for the 38,39 and 40 machines. The 49G+ will run all userRPL programs of the 49G plus all libraries that use supported entries. Excellent machine. Fast too. The SD works like a charm. Flicker of bottom menu while editing. The keys feel nice to click but sometimes the enter key needs a slightly harder push to register. USB works OK. IR print is fast. !Demeter! ==== thanks to all for the reply, I appreciate the HP education, as I don't have much time to learn everything that I want to know about the calc. I would like nothing more thne to be able to program it myself, but I simply don't have the time to learn being a full time student. V/R >Aplets simply do not apply to the HP48,49,49+ calcs. >These are programs written for the 38,39 and 40 machines. >The 49G+ will run all userRPL programs of the 49G plus >all libraries that use supported entries. Excellent machine. >Fast too. The SD works like a charm. Flicker of bottom menu >while editing. The keys feel nice to click but sometimes the >enter key needs a slightly harder push to register. USB works OK. >IR print is fast. >!Demeter! ==== > 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? It simply means that it is not 38/39 compatible (and vice versa) Almost all the old programs work - if only supported entry points are used. ==== > Please comment on the following: > 1) Keyboard problems! > sticky, dropped keystrokes, etc My corner keys (F1, F6, and ENTER) and both shift keys and the zero key all have a VERY annoying habit of missing AND repeating. For example, I press and hold down a shift key to use a shift-and-hold key assignment; then I release both; then I press DROP intending to drop only level 1, and the whole stack gets cleared because the shift didn't turn off and both shifted backspace keys clear the stack!!! It happens to me only 2 or 3 hundred times a day, but it is starting to get on my nerves. I cannot key in a number containing any zeros without carefully watching the display to be sure I don't get too few or too many zeros. No, tweaking ->KEYTIME doesn't help. The keystroke actuation pressure is better than the 49G, but it's still WAY too hard. Has ANYBODY on the team ever used an HP-41?!? THAT keyboard was PERFECT, even better than the HP48. A light touch made the key jump from its rest position, in such a way that you FELT (not heard!) it make contact, and when you felt it, you knew that it was a good keystroke. Always! Not so with this keyboard. You gotta push the key with maybe 5 times the pressure of an HP-41 key, and then it makes a loud, hollow-sounding *BORNK* as it goes down AND as it comes back up again, all of which is accompanied by zero, one, or two actuations of the key, even though you only pressed the key once, felt one click, and heard two. Worse than annoying. What good is precise calculation when the input is unreliable? It's like a sports car with a loose steering wheel. > 2) Paint chipping None so far. > 3) General observations I *love* the new display. Unlike the 49G which had a thick and shiny lens, which was a Very Bad Thing, the 49g+ has a glare-free flat it doesn't scratch. And it seems to be sealed somehow, unlike the 49G's display which collected dust bunnies that multiplied like crazy and would NOT go away. The oft-maligned and little-understood SD card feature is WONDERFUL. No need to have ANYTHING stored externally any more! It even recognizes PC folders, so that :3:{ BAM BAS BATIS BANT } RCL will recall 'BANT' from the BATIS folder in the BAS folder in the BAM folder in the SD card! Warning: by folder I do NOT mean HP directories! I mean *PC* folders! Gone are the days of trying to organize hundreds of programs from the calculator. Do it on your hard drive, then mirror the directory tree into your SD card and take it with you in your 49g+. Awesome! Backup battery: great idea. Now you don't have to worry while changing batteries, nor backup to flash (which you CAN'T do when the batteries need changing!). NUMBER ONE LOVE: the SPEED of this puppy! I get very annoyed with ALL previous models now. How quickly we get spoiled! > 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 ... It was marked Marketing Sample, an early production model. Internal Serial Number: CN33100691 External Serial Number: CN33102663 -Joe- ==== X> No, tweaking ->KEYTIME doesn't help. Realize the fact: There is no ->KEYTIME Plain English: The HW is separated from that command. X > it makes a loud, hollow-sounding *BORNK* as it goes down AND as it LOL How early model do you have, Joe? Mine says: *GNAP* and only decimal point needs some attention ==== > 1) Keyboard problems! Yes Keyboard problems. Unbelievable that they could send a calculator to the market with this kind of problem. And the swedish HP-support have not heard anything about this problem. Don't HP's world wide organisation communicate? > 2) Paint chipping Yes Paint problems. > 3) General observations Otherwise a very nice calculator. > If you include from where and when you purchased the calc, serial number, Sweden Serial number: CN331.. /Pelle ==== I ordered a 49G+ from CalcPro last week, and it arrived today. Included in the package were the calculator, a soft case, batteries, a USB cable & CD, and a manual. The SN is in the CN3320xxxx range. I haven't noticed any problems yet; the keyboard does take quite a bit more force than the 48G series to operate, but all the keys work fine when pressed fully. It does seem that it would slow down input a bit having to be more forceful and deliberate on the keys, but I am still getting used to both the keyboard layout and feel - been using a 48G for years - so I can't really give a good estimate of that yet. The paint looks to be durable, but I have only had the calculator for a few hours, so I can't really say how it will hold up. Overall, the calculator looks good, and everything works quite well. There are some errors in the manual (apparently written for a different ROM or something - some menus have slightly different choices, etc.) The documentation seems to be the only weak point, but the pdfs that have been provided for download partially fill that gap. > 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 ordered a 49G+ from CalcPro last week, and it arrived today. > > Included in the package were the calculator, a soft case, batteries, a > USB cable & CD, and a manual. The SN is in the CN3320xxxx range. What sort of manual came with it? Is it the same as one of the downloadable PDF files? Which ROM version was installed? -- James ==== > > I ordered a 49G+ from CalcPro last week, and it arrived today. > > > > Included in the package were the calculator, a soft case, batteries, a > > USB cable & CD, and a manual. The SN is in the CN3320xxxx range. > What sort of manual came with it? Is it the same as one of the > downloadable PDF files? Physical Manual=170 pages on paper, PDF=~850 pages on CD The smaller is small enough to go through and latter is for reference and more detailed reading. You dealer desides if it's ever printed... > Which ROM version was installed? Always 1.20 ROM so far. > -- ---- > James Veli-Pekka ==== Correction on SN - the internal software SN is 332; the SN on the case is 331 > > Included in the package were the calculator, a soft case, batteries, a > USB cable & CD, and a manual. The SN is in the CN3320xxxx range. > ==== Soft case? Is it soft vinyl or soft leather or soft fabric? > I ordered a 49G+ from CalcPro last week, and it arrived today. > > Included in the package were the calculator, a soft case, batteries, a > USB cable & CD, and a manual. The SN is in the CN3320xxxx range. > > I haven't noticed any problems yet; the keyboard does take quite a bit > more force than the 48G series to operate, but all the keys work fine > when pressed fully. It does seem that it would slow down input a bit > having to be more forceful and deliberate on the keys, but I am still > getting used to both the keyboard layout and feel - been using a 48G for > years - so I can't really give a good estimate of that yet. > > The paint looks to be durable, but I have only had the calculator for a > few hours, so I can't really say how it will hold up. > > Overall, the calculator looks good, and everything works quite well. > There are some errors in the manual (apparently written for a different > ROM or something - some menus have slightly different choices, etc.) The > documentation seems to be the only weak point, but the pdfs that have > been provided for download partially fill that gap. > > >> 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 >> >> > ==== It's black leather, with soft fabric inside (like you'd see inside a glasses case), and a magnetic snap closure. I have scanned in an image: http://www.umr.edu/~bkaul/49gcase.html > Soft case? Is it soft vinyl or soft leather or soft fabric? > > ==== > 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. If I recall correctly, only SD cards with a size of up to 128MB are supported on the HP49G+. ==== > If I recall correctly, only SD cards with a size of up to 128MB are > supported on the HP49G+. or elsewhere. Can a 128 MB card be formatted on the 49+? Furthermore, Joe puts out that the *sector* size of his 128 MB card is 2K (which may be true -- although I don't have a tool to determine the sector size on my card), but the minimum space occupied of a stored file is the *cluster* size, IIRC. On my preformatted SanDisc the cluster size is 16K, which is a waste of space. May I reformat the card, adjusting the cluster size? If so, what is the minimal cluster size which works with the hp49+? Michael -- -= Michael Hoppe , =------ ==== > If I recall correctly, only SD cards with a size of up to 128MB are > supported on the HP49G+. > or elsewhere. Can a 128 MB card be formatted on the 49+? I just formatted a 64MB SD card, which had trouble updating the system. AFter the 49g+ format, I filled it with the PC (I used sub-directories) Later I noticed that 49LIBS is not a valib name, but using 49LIBS solved that, so :3: { 49LIBS 'L706' } RCL worked ok. AND yes, the upgrade now works from the SD, too (not only USB) > Furthermore, Joe puts out that the *sector* size of his 128 MB card > is 2K (which may be true -- although I don't have a tool to determine > the sector size on my card), but the minimum space occupied of a stored > file is the *cluster* size, IIRC. On my preformatted SanDisc the The term is cluster size. It is a binary multiple of 1/2KB or 512bytes. > cluster size is 16K, which is a waste of space. May I reformat the > card, adjusting the cluster size? If so, what is the minimal cluster > size which works with the hp49+? What the DOS FAT16 format gives that you're going to get so basically - with those tiny little calculator files you'll have almost the same capasity in a 8MB and a 128MB card. There are only 65,518 possible cluster on a card (or HD) in FAT16 Moving to FAT32 would solve that problem. It was first introduced as Windows 95 OEM Service Release 2 Default cluster size is 4K up to 8GB drive, max is 2TB (old BIOS & W2K standard was 32GB, updated to accept 128GB, then later more via 48bit addressing even older limit (BIOS/DOS) was 8GB, interrupt 13 extensions are needed) Please correct any mistakes! Veli-Pekka PS: I vote for native FAT32 support as the primary format (along with FAT16 support) to support small cluster size I hope 512 byte clusters eg. single sectors could be supported (Starting: 256MB=4K, 8GB=8K, 64GB=16K, 2TB=32K) I have a <16GB HD partition on my PC as FAT32 using 512B/sector PPS: FAT12 is for floppies, an old 2MB card of 48GX reminds me of a floppy The 49g+ can accept a kind of DOS HD of 8-128MB (SD/MMC) ==== > If I recall correctly, only SD cards with a size of up to 128MB are > supported on the HP49G+. I can't seem to find that information in either the user's guide or the user's manual that I downloaded. But perhaps it's in whatever documentation is packaged with the calculator? Or is this just something that everyone knows? -- James ==== > Buy an SD-card ... And a reader/writer as well > and keep your fingers crossed that it'll run > under W98. For what it's worth, IOGEAR's Universal Memory Bank GFR280 card reader/writer works with USB2 (reads very fast! write speed is limited by the card) just fine under Windows 98SE. It's a tiny box with slots for SD or MMC, and CF or MicroDrive, and Memory Stick, and Smart Media. SanDisk SD cards come already formatted. The sector size in a 128M card is 2K. Therefore even the smallest object stored will occupy 2K. Is there any way to change the sector size, to reduce the amount of wasted space? I tried to use Partition Magic 7.0, but it refused to even look at the flash card. -Joe- ==== > Buy an SD-card ... And a reader/writer as well > and keep your fingers crossed that it'll run > under W98. > For what it's worth, IOGEAR's Universal Memory Bank GFR280 card The URL to the manufacturer's site, please?! > reader/writer works with USB2 (reads very fast! write speed is limited > by the card) just fine under Windows 98SE. It's a tiny box with slots > for SD or MMC, and CF or MicroDrive, and Memory Stick, and Smart > Media. SanDisk SD cards come already formatted. > The sector size in a 128M card is 2K. Therefore even the smallest > object stored will occupy 2K. Is there any way to change the sector > size, to reduce the amount of wasted space? I tried to use Partition > Magic 7.0, but it refused to even look at the flash card. Yes, but then you will have less size on your card. That is the limit of the FAT16 file system. We should have FAT32 and reduce the size to 512bytes or 1/2K (well the ususal size on my FAT32 is 4K) Count it Joe: 2GB=32K clusters, 128MB=2K, 32MB=1/2K minimum Correct me if I'm in error (usually [ON] & [C] will do) ==== > *buggy In what way? > *poorly documented Did you actually even bothered to look at the new manual for the 49G+? It's rather compete if you ask me. > *outsourced where is this an issue? > *presented with physical problems I won't say much on this one. But my advice would be for you to actually do a bit of research instead of simply repeating what you think you heard Cancel-Lock: sha1:fg8Fg05mNa8xDXxpiRR7lc+oLkY= ==== >> *buggy > In what way? A single bug makes it buggy. I do not own one yet but I understand that it initially had a problem with power consumption during OFF state. Had the calculator been properly characterized and qualified before release to production, this would not have happened. The mere presence of this bug (although supposedly fixed now) raises questions as to the quality of the product overall. >> *poorly documented > Did you actually even bothered to look at the new manual for the 49G+? > It's rather compete if you ask me. Its completeness has nothing to do with anything. The 49G[+] series have both had errors (grammar, informational etc). This is totally inexcusable. Again it indicates a total lack of Quality Assurance on the part of HP...note I say HP and not any other entity. If HP places their name on the product, they are ultimately responsible for its quality. >> *outsourced > where is this an issue? Agreed. Now days this is no longer an issue. Perhaps this is more a matter of principle than anything else. I am not sure of just how much of the 49G+ is actually an HP creation. Is *any* of it? If not, then in my personal opinion, it cheapens it. Note again, my *personal* opinion. It is formed based on the ideals of a 40 year old man so only others in at least that range might understand fully the importance of name brand quality. >> *presented with physical problems > I won't say much on this one. > But my advice would be for you to actually do a bit of research instead > of simply repeating what you think you heard I hope I have not done simply that. I make no claim to own a 49G+ (I do own a 49G). But the facts surrounding both are not disputed, hence the issue of Quality is not in question. It is lacking....severely. The sad fact is that today's generation of buyers *tend* not to care. Many of the ones who complain here *do* care. Again, it is the principle. Comments welcome. Best, -Al Arduengo -- ~/.signature ==== > Agreed. Now days this is no longer an issue. Perhaps this is more a > matter of principle than anything else. I am not sure of just how much > of the 49G+ is actually an HP creation. Is *any* of it? If not, then > in my personal opinion, it cheapens it. Note again, my *personal* > opinion. It is formed based on the ideals of a 40 year old man so only > others in at least that range might understand fully the importance of > name brand quality. I understand just what you mean. It used that anything with the HP logo on it was understood to be high quality *by definition*. For many years I made purchasing decisions, for myself and for my employer, for everything from printer paper and ribbons up to minicomputer systems costing tens or hundreds of thousands of dollars, based on the idea that, If HP makes it, there's no need to look anywhere else. In recent years my attitude has changed to, If HP makes it, it probably would be better to get it from almost anywhere else. So in a sense there's still a sort of brand recognition involved; it's just that these days I see the HP name as an indicator of *lack* of quality. (That's why I'm recommending that my employer make a *very* large purchase of Sun Solaris systems rather than HP-UX systems.) -- Wayne Brown (HPCC #1104) | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== > I understand just what you mean. It used that anything with the HP > logo on it was understood to be high quality *by definition*. For many > years I made purchasing decisions, for myself and for my employer, for > everything from printer paper and ribbons up to minicomputer systems > costing tens or hundreds of thousands of dollars, based on the idea that, > If HP makes it, there's no need to look anywhere else. Wayne, I'd generally agree but then again - we know that those who have problems will be heard of here on Usenet. In the '70s that wasn't the case (pre-Usenet). Around 1977 my dad needed a way to characterize printing ink and chose a commercial Thwing-Albert falling weight viscometer to measure it. Converting the timed results to useful values in Poise was a very complex and error prone task even with a calculator. On my advice, he bought four HP-97 calculators (US$750 each in 1977 - lots more than a serious Pentium 4 machine today) after convincing the others at his lab of the remarkable reliability of HP's wonderful machines. After all, he had the many tales of such from his own son and brother (Henry Horn, editor of HP's own Key Notes). After many delays, the much anticipated machines arrived. Three were dead on arrival and never *did* work. You can guess how well that went over. Were I to use that data point (and '97s that burned out their print heads with nonnormalized numbers, etc.), I'd argue your point. But I'd be biased by a few rare examples. Perhaps we are now. I sure hope so!! Jim Horn (hey, my darn HP-25 doesn't work any more) ==== Just for info Hpcaculators.com (orSamsonCables if you prefer) is shiping the 49g+s, got mine today, looks pretty sweet so far, been out of the caculators world for a while need to catch up now > 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 ==== JUst what the title says. Looking for a state of the art Fourier program, no fast fourier (like built in). I would to write it myself, but since I don«t know programming (yet, I am ashame) it is useless. Plese need the BEST ONE out there!!! Esteban Suarez M Argentina ==== > JUst what the title says. > Looking for a state of the art Fourier program, no fast fourier (like > built in). > I would to write it myself, but since I don?t know programming (yet, I > am ashame) it is useless. Plese need the BEST ONE out there!!! I can't help you with a program, but if you *need* a Fourier program, then you can learn to program an HP48 or 49. Start at the beginning of the Manual and DO ALL OF THE EXAMPLES! You will probably find that you will soon want the Adanced Users Guide. It gives the syntax for all of the commands. The HP48 AUG is available as a zip file. I also find that USAG is a great little help. It is a program you keep on your calc and it gives you the 'USAGe' of commands. I can tell you that every time someone shows off their Palm Pilot or whatever, I can match their data handling programs. Geoff ==== >You will probably find that you will soon want the Adanced Users >Guide. It gives the syntax for all of the commands. The HP48 AUG is >available as a zip file. Where ? Can you provide a link ? > JUst what the title says. > Looking for a state of the art Fourier program, no fast fourier (like > built in). > I would to write it myself, but since I don.95t know programming (yet, I > am ashame) it is useless. Plese need the BEST ONE out there!!! > I can't help you with a program, but if you *need* a Fourier program, > then you can learn to program an HP48 or 49. Start at the beginning of > the Manual and DO ALL OF THE EXAMPLES! > You will probably find that you will soon want the Adanced Users > Guide. It gives the syntax for all of the commands. The HP48 AUG is > available as a zip file. > I also find that USAG is a great little help. It is a program you keep > on your calc and it gives you the 'USAGe' of commands. > I can tell you that every time someone shows off their Palm Pilot or > whatever, I can match their data handling programs. > Geoff ==== >You will probably find that you will soon want the Adanced Users >Guide. It gives the syntax for all of the commands. The HP48 AUG is >available as a zip file. > Where ? Can you provide a link ? There is only this file on AUR: http://www.hpcalc.org/details.php?id=1716 The User's Guide is available though: http://www.hpcalc.org/details.php?id=3937 ==== That's what I thought. The link is to a .zip that contains html files for each UserRPL command. (Useful but not really the same thing as the complete AUR). I have not yet found an electronic version of the real AUR. Sampson Cables still sells never-used HP48GX AUR manuals however. > >You will probably find that you will soon want the Adanced Users > >Guide. It gives the syntax for all of the commands. The HP48 AUG is > >available as a zip file. > > Where ? Can you provide a link ? > There is only this file on AUR: > http://www.hpcalc.org/details.php?id=1716 > The User's Guide is available though: > http://www.hpcalc.org/details.php?id=3937 ==== When you say they don't seem to work do you mean that they just don't do what you want them to or that they literally don't run? I can't help with the first because I didn't write those but if it's a real problem with the code then perhaps I can help you to contact the author. > > 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 > > > > ==== > 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. a USB mass storage device is no more than a HD looking type thing that comunicate with the PC in terms of 512B sectors. The PC then handles the file system (in FAT, or other). Do you have any idea of how much work it would be to convert on the fly the HP file system in FAT looking thing? In addition, hell would break loose when you start creating temporary object in the calculator memory and therefore change the free space on the 'virtual drive' (which is not something that the PC will be able to handle).... I agree that it would have been good for the user though... ==== Im using my HP48GX with the Conn4x build17xx (new than 16xx) since itsnot an hp49g+ im not use USB :) at windows Me and 2000 perfectly but in the con4x build 17xx hp or someone have forgotten to include the help, arch48.hp, arch49.hp and xserv48.hp intyo the kit! I hope it will be corrected in future releases... ==== > 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 In my Windows 98 it works, so who to blame? > reason I should update my OS to a newer one (call it XP) that runs slower Window 2000 works, too - and naturally my Win XP Pro also. > and make other things unusable on my PC ??? I have a multi-boot machine. I upgraded the new OS to a different partition > 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. OK - you may be right... PS: After going from 256MB to 768MB, my PC works faster in evrey OS I killed my swap file (virtual memory) all together ==== for the 49g+. The price is $149.00. ==== > for the 49g+. The price is $149.00. Well, US$149.99 actually. I wonder what the Authorized Resellers think of HP selling it direct at $26 under the MSRP. -- James ==== I searched thoroughly and didn't even see the 49g+. Does someone have a link to it? me a .8ecrit dans le message de > > for the 49g+. The price is $149.00. > Well, US$149.99 actually. I wonder what the Authorized Resellers think > of HP selling it direct at $26 under the MSRP. > -- > James ==== > I searched thoroughly and didn't even see the 49g+. Does someone have a link > to it? Umm, how about a link to some links? http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/forum.cgi?read=44517 -- James ==== > > for the 49g+. The price is $149.00. > Well, US$149.99 actually. I wonder what the Authorized Resellers think > of HP selling it direct at $26 under the MSRP. Probably the same thing they think when HP does this with (as I recall) many other products that they make! Hey HP, great idea! Just drive the stores away from your products so that they're only sold direct via your web site! Then people will never see them in the stores, wont know about them, and.... you'll make more money? I just don't get it. -- -Joshua Belsky jjbelsky@yahoo.com http://belsky.net ==== >> Well, US$149.99 actually. I wonder what the Authorized Resellers think >> of HP selling it direct at $26 under the MSRP. > Probably the same thing they think when HP does this with (as I recall) many > other products that they make! > Hey HP, great idea! Just drive the stores away from your products so that > they're only sold direct via your web site! Then people will never see them > in the stores, wont know about them, and.... you'll make more money? > I just don't get it. Yes, that's exactly how they put companies like HandiCalc out of business. Yet another of the many grudges I have against HP... Jim Lawson deserved *much* better treatment from HP than he got. -- 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 ==== Wouldn't you say that the ultimate goal for any calculator we desire in this newsgroup be a solid combination of Mathematica and TKSolver (and maybe Cray processing power)? Must have symbolics for the math and backward solve capability for design. Obviously, must be able to process quickly. ==== > Wouldn't you say that the ultimate goal for any calculator we desire > in this newsgroup be a solid combination of Mathematica and TKSolver > (and maybe Cray processing power)? Must have symbolics for the math > and backward solve capability for design. Obviously, must be able to > process quickly. - lots of hardware hack posibility - life time battery life - rechargeable - standard battery - lighter - heavier (see above comment) - backlit screen - lots of programming/hacking potential - simple - with 50000 functions - only with the function I realy need (they change depending on the person) - ultra fast (see battery life) .... Is my memory fair to the things that are asked here :-) smile, it's the WE, Cyrille ==== And don't forget a communicator capability to be beamed back to the Enterprise! > Wouldn't you say that the ultimate goal for any calculator we desire > in this newsgroup be a solid combination of Mathematica and TKSolver > (and maybe Cray processing power)? Must have symbolics for the math > and backward solve capability for design. Obviously, must be able to > process quickly. > forgot: > - Cell phone > - whifi networking > - color screen > - large keyboard > - small keyboard (well, no group is concistent isn't it) > - simple keyboard > - good HP keyboard > - plug in modules > - lots of hardware hack posibility > - life time battery life > - rechargeable > - standard battery > - lighter > - heavier (see above comment) > - backlit screen > - lots of programming/hacking potential > - simple > - with 50000 functions > - only with the function I realy need (they change depending on the > person) > - ultra fast (see battery life) > .... > Is my memory fair to the things that are asked here :-) > smile, it's the WE, Cyrille ==== > Wouldn't you say that the ultimate goal for any calculator we desire > in this newsgroup be a solid combination of Mathematica and TKSolver > (and maybe Cray processing power)? Must have symbolics for the math > and backward solve capability for design. Obviously, must be able to > process quickly. I would say that a lot of us are just interested in a really good numeric calculator and don't care about a CAS. I suppose it depends what you do with it. -- -Joshua Belsky jjbelsky@yahoo.com http://belsky.net ==== TI in PocketPC - Emulators of the calculators TexasInstruments for OSWindowsMobilePC in: http://ticalcemulator.tripod.com/ http://www.ticalc.org/archives/files/fileinfo/309/30978.html Lo que muchos esperaban , por fin ya podemos tener las TI en un PC portatil EDCG ==== --------------------------------------------------------------------- so..in file manager the structure is: port0: 240Kb port1: 127Kb (instead of 255Kb) port2: 766Kb (instead of 1085 Kb) Is it normal????? Someone can help me please????? thanks p.s. port0, port1, port2 are empty ==== installed is version1.22, the last i know! so..in file manager the structure is: port0: 240Kb port1: 127Kb (instead of 255Kb) port2: 766Kb (instead of 1085 Kb) Is it normal????? Someone can help me please????? thanks p.s. port0, port1, port2 are empty This is normal. The new ROM/RAM must use some space for the emulator (I'm just guessing now) and for the SD functionality. Not unfare after the fact that this should have been called HP-49GX. You can add up to 128MB SD into your system. Even my 8MB MMC (shared with a B/W Nokia 9110i Communicator) is not even close to being filled. ==== > installed is version1.22, the last i know! > so..in file manager the structure is: > port0: 240Kb > port1: 127Kb (instead of 255Kb) > port2: 766Kb (instead of 1085 Kb) > > Is it normal????? Someone can help me please????? > thanks > > p.s. port0, port1, port2 are empty > > This is normal. > The new ROM/RAM must use some space for the emulator > (I'm just guessing now) and for the SD functionality. > Not unfare after the fact that this should have been called HP-49GX. > You can add up to 128MB SD into your system. > Even my 8MB MMC (shared with a B/W Nokia 9110i Communicator) > is not even close to being filled. I'll agree that this is still a lot of memory; it may well be more than you'll ever use. But some may well feel that it's a bit unfair if they've looked at page 26-1 of the user's guide and seen: 0:IRAM 240KB 1:ERAM 255KB 2:FLASH 916KB And maybe even more unfair if they've visited http://www.smb.compaq.com/sp_main.asp?hp_url=searchresults.asp?store_id=8&se arch_id=164&dept_id=1001&dsc=calculators and read: 2.5 MB of total memory - 512K of RAM and 2MB of flash ROM. I don't doubt that their advertising is true, but they've neglected mentioning how much memory is used by the operating system. -- James ==== I don't know whether it's normal, but mine reads the same. - Ed ==== >I don't know whether it's normal, but mine reads the same. Mine too. Mathias -- Mathias Habel mathias.habel_no-spam_@t-online.de Remove _no-spam_ before replying ==== I'm looking for RS-232 interface cable for my HP48S (in France). Someone could help me ? greatings, Pierre ==== I bought one from Konstantin Lysenko in Canada (he lists on Ebay as Kostya30). It is very nice. I have a GX--I don't think there is any difference. http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=20335&item=3043113320 Bill > I'm looking for RS-232 interface cable for my HP48S (in France). > Someone could help me ? > greatings, > Pierre ==== I am a graduate student. Would anybody please help me to code for minimisation of multiple output functions each of 12 variables. I donot know how and where to start. I know how quine mccluskey works but donot understand how to code it. Please help me. I have my submission in 15 days. Ipseeta ==== > 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 friends!!! JimH (older'n Joe) ==== Cool ! A FX502P web site... :-) My first programmable calculator ! I've not yet finished but it's already on line : http://casio602p.free.fr Of course, i will put a link toward your 502 site. Gilles H0_hb.1364$ny5.165@news-binary.blueyonder.co.uk... > I do not deny that the problem is very difficult - I tried it on the Casio > FX-502P back in the 80s (except I preferred the output in vulgar fractions), > but by simple inspection of your challenge you've got the wrong answer for > the 5th example. The fractional part of 50000.0005 is clearly 1/20000 and so > your correct answer should be 1000000001/20000 as given by ->Q of a HP48. > www.fx502p.pwp.blueyonder.co.uk and gives the correct answer of > 50000+1/20000. I would not pretend however that the program would be up to > the challenge in general. I would of course like to see your HP48 program... > especially when it is fixed. > Peter. ==== > >> For what it's worth, my program converts >> sqrt(LOG(2)) into 998995/1820784 in 0.745 >> seconds on an hp49g+, and runs unmodified on >> an HP48GX. > > How long does it take to run on a 48GX, > or on a 49G? > > It takes approximately 3 times longer, for almost any input. > > -Joe- My SAP program (posted somewhere in this thread a few minutes ago) takes 1.31_sec on a 48GX for this problem. That certainly beats 3*0.745, even when calculated with a TI ;-) And I forgot to mention that it converts all your examples flawlessly, which doesn't mean the program is without errors ;-O ==== second 'instalment'. I'm not too happy with 'SAF' yet, though. @ QUOTREM - Quotient and Remainder @ @ bytes: 30.0 @ check: #C142h (48) @ #14A6h (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: 74.5 @ check: #25D3h (48) @ #6FABh (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 - start with p=x and q=1 1. SWAP @ stack holds 2:q 1:p, with ri = p/q WHILE @ calculate ai OVER QUOTREM DUP REPEAT @ stop when remainder is zero @ calculate ri+1 ROT END ROT DROP2 D DEPTH SWAP - ->LIST >> >> @ SAF - determine Smallest Approximating Fraction @ @ bytes: 237.0 @ check: #7A2Ah (48) @ #AE9Fh (49) @ @ In: 1: x @ Out: 2: p @ 1: q @ @ p,q are integers @ a simple / will yield the exact argument back. @ @ timing: @ .500000000001 48SX: 3.6084_s @ 48GX: 2.4226_s @ 49G: 2.649_s @ 3.14159265359 48SX: 1.3682_s @ 48GX: 0.8965_s @ 49G: 1.0372_s @ timings obtained with EMU48 << @ determine Simple Continued Fraction DUP ->CF 0. -> z cf i << @ *forward* evaluate the CF till the quotient matches the argument @ @ P[i] = ai*P[i-1] + P[i-2] @ Q[i] = ai*Q[i-1] + Q[i-2] @ @ where @ | -2 -1 0 @ ------------- @ P | 0 1 a0 @ Q | 1 0 1 @ @ we'll use a complex number to hold a (p,q) pair (0. 1.) (1. 0.) DO DUP cf 'i' INCR GET * ROT + UNTIL DUP C->R / z SAME END SWAP cf i GET 0. @ bisection to determine largest N for which @ @ P[i+1] - N*P[i] @ EVAL(---------------) = z @ Q[i+1] - N*Q[i] @ @ stack: R[i+1] R[i] a[i+1] 0. @ Ri = (Pi Qi) WHILE DUP2 - 1. > REPEAT 4. DUPN + 2. / IP DUP 5 ROLLD * - C->R / z =/ { ROT } IFT DROP END SWAP DROP * - C->R >> >> Werner ==== -=[ Sat, 18.10.03 08:28 a.m. +1300 (NZDT) ]=- in message ID <44ec85ff.0310170601.de012f6@posting.google.com> : > second 'instalment'. I'm not too happy with 'SAF' yet, though. But you *must* be happy with this first part!!!!! > @ determine Simple Continued Fraction > DUP ->CF 0. > -> z cf i > << > (0. 1.) (1. 0.) > DO > DUP cf 'i' INCR GET * ROT + > UNTIL DUP C->R / z SAME > END I racked my brain trying to figure out an elegant way to do BTW your timings *do* indicate you have approached Joe's speed on this!! I think he got about .8 seconds for the .500000000001 on the 49g+? That would probably be about 3 seconds on the 49G, and you have 2.649!! Also, FWIW, I think your second part, that does the bisection, is certainly very efficient, as it uses the stack only, and it has to be the way it is to reflect the comlexity of the calculation itself. For my money, you have won the challenge Werner!!! Overall I suppose one could possibly achieve something faster by not formally computing all of the partial quotients, as they are not needed past a certain point. But, that would entail doing too many things at once, for my brain anyway I wonder if Joe uses your complex number method? Now I see it, it seems so natural for doing 2 things at once :) -- Tony Hutchins Wellington New Zealand #8 Quantized Revision of Murphy's Law: Everything goes wrong all at once. ==== > -=[ Sat, 18.10.03 08:28 a.m. +1300 (NZDT) ]=- Hey, Werner will do! > BTW your timings *do* indicate you have approached Joe's speed > on this!! I think he got about .8 seconds for the > .500000000001 on the 49g+? That would probably be about 3 > seconds on the 49G, and you have 2.649!! IIRC, that was for SQRT(LOG(2.)), for which I get 1.5 secs (on a real 49G - shall we call them 49G- from now on?) > Also, FWIW, I think your second part, that does the bisection, > is certainly very efficient, as it uses the stack only, and it > has to be the way it is to reflect the comlexity of the > calculation itself. For my money, you have won the challenge > Werner!!! Nono -*you* have won it. All I did was copycat your work and write it the way I am used to, and I do have a fair bit of 'mini-challenge experience' ;-) > Overall I suppose one could possibly achieve something faster > by not formally computing all of the partial quotients, as > they are not needed past a certain point. But, that would > entail doing too many things at once, for my brain anyway For Pi (well its 12-digit approximation) that would be a bit faster. But the bisecting part is the most time-consuming, and I'm too lazy to combine the 'continued fraction' part and the 'forward evaluation part'. They are pretty elegant as they are. > I wonder if Joe uses your complex number method? First, I used a list - but that doesn't work an a 48S. Then I used a vector, and only thought about complex numbers by accident.. It *halves* the time. > Now I see it, it seems so natural for doing 2 things at once My feeling exactly - when Joe pointed out the superfluous x -> p/q conversion at the beginning BTW: In SAF, replace (0,1) (1,0) by -1. v/ 1. (-1. SQRT 1.), 29.5 bytes less, and it works the same way even if the second number is real i.o. complex Werner ==== -=[ Sat, 18.10.03 10:53 a.m. +1300 (NZDT) ]=- in message ID : > > > Hey, Werner will do! That's my automated header program - I should change the template so it doesn't reproduce the date as well - too lazy! > BTW your timings *do* indicate you have approached Joe's speed > on this!! I think he got about .8 seconds for the > .500000000001 on the 49g+? That would probably be about 3 > seconds on the 49G, and you have 2.649!! > > > IIRC, that was for SQRT(LOG(2.)), for which I get 1.5 secs Ah, yes, that rings a bell. Wow, you may even have a faster version than Joe's then!! Certainly very close. > (on a real 49G - shall we call them 49G- from now on?) Hehe. Maybe they are just a complex pair, the real 49G and the imaginary 49g+ :) > Also, FWIW, I think your second part, that does the bisection, > is certainly very efficient, as it uses the stack only, and it > has to be the way it is to reflect the comlexity of the > calculation itself. For my money, you have won the challenge > Werner!!! > > Nono -*you* have won it. OKok, I accept :) > All I did was copycat your work and write it the way I > am used to, and I do have a fair bit of 'mini-challenge > experience' ;-) Ahha, I am not surprised. I have learned a lot! [...] > For Pi (well its 12-digit approximation) that would be a bit > faster. But the bisecting part is the most time-consuming, > and I'm too lazy to combine the 'continued fraction' part > and the 'forward evaluation part'. They are pretty elegant > as they are. Yes they are, and it's nice to have the full partial quotient string as a by product. I can't think of any other way to do the final part. > I wonder if Joe uses your complex number method? > > First, I used a list - but that doesn't work an a 48S. Why's that? Does a 48G have extra LIST features? Couldn't you use LIST-> just like you use C->R? > Then I used a vector, and only thought about complex numbers by accident.. > It *halves* the time. WOW!! > Now I see it, it seems so natural for doing 2 things at once > > My feeling exactly - when Joe pointed out the superfluous x -> p/q > conversion at the beginning My first reaction is to avoid MOD since bad experiences with it years ago with Basic. Old habits die hard, especially when a race is on :) > BTW: > In SAF, replace (0,1) (1,0) by -1. v/ 1. (-1. SQRT 1.), 29.5 bytes less, Hehe. You have me there. You see I am way behind the times. I have never coded on an emulator and don't know what v/ is for a start. I haven't a clue as to how 2 complex numbers spring out here. I know that prefixes a command not easily displayable in regular ascii, and I just guess most of them, when I see them here, like ->. I do see how the -1 SQRT gives (0,1), but where does the (1,0) come from? > and it works the same way even if the second number is real > i.o. complex Which second number? -- Tony Hutchins Wellington New Zealand #103 Life is tons of discipline. Robert Frost ==== > 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. Will you be making the full PDQ package available somewhere (like maybe hpcalc.org)? I poked around a bit on your web site last night but couldn't find it. -- 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 ==== > 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. ;-) That would be (using my longfloat library): 1901870728566923076090143944714770339621590768313546337192526115562704339680 9635643200078081079293702997523451876888357413870030368533612856711580598677 02399073227994426905220194699766118756059055619036488502928002591 6053842551464203261023610232159405317163914781503450207392312531721347406882 3247694600005871377454979656144746826774641287402271754410094658714414873962 6803435133473281606663121381125761746030151344353855924025288111 With a total of 217+217 digits you get an accuary of pi of about 437 decimal digits. Gjermund Skailand ( sorry couldn't resist) ==== >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. Did HP actually say just as you have quoted? This a pretty bold statement; I can't find it in any of my manuals. Where did they say that? ==== > Did HP actually say just as you have quoted? II: Problem Solving Resources on page 526: ------- begin Wickes quotation ------- ->Q finds the fraction with the *smallest denominator* that matches the argument within the error limit set by the display format. For example, STD 1.61803398875 ->Q --> '514229/317811' Notice that the denominator does not have 11 digits. The fraction 139583862445/86267571272 is another representation of the original argument that evaluates to the same decimal value as 514229/317811; ->Q chooses the latter because the denominator is smaller. ------- end of Wickes quotation ------- (emphasis is Wickes') ->Q's aim is to produce the fraction with the *smallest denominator* and a given error size [emphasis is his] in the documentation for NEW2Q on Goodies Disk #3, which was his response to my 1990 DEC2FRAC program, my first attempt to improve ->Q. If both he and Bill Wickes clearly stated that ->Q was supposed to get the smallest possible denominator, you might ask why the official HP documentation only go so far as to call it a best guess. [Cf. the HP 48SX Owner's Manual (page 134), and the HP 48 Owner's Manual (page 9-5), and the HP 48 Programmer's Reference Manual (page 283), and the HP 48G Series Advanced User's Reference Manual (page 3-251)]. The reason can also be found in the NEW2Q documentation: The HP48 manuals did little to clarify this issue, especially since we wanted to make no specific claim with only a conjecture of correctness. BINGO! There it is! What HP *intended* to do is clear, and the above sentence reveals that they never really wrapped their brains around the problem, and lived in hope that it worked well enough to minimize complaints, but couldn't guarantee the *smallest* denominator. ->Q never lived up to their original stated goal, like PDQ does. -Joe- Joseph K. Horn pdq@holyjoe.us ==== >> Did HP actually say just as you have quoted? -------SNIP >BINGO! There it is! What HP *intended* to do is clear, and the above >sentence reveals that they never really wrapped their brains around >the problem, and lived in hope that it worked well enough to minimize >complaints, but couldn't guarantee the *smallest* denominator. ->Q >never lived up to their original stated goal, like PDQ does. So I take it that the answer to my question: ----------- >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. Did HP actually say just as you have quoted? This a pretty bold statement; I can't find it in any of my manuals. Where did they say that? ----------- is no? The examples you gave don't use the unqualified word equal. They use phrases like given error size, within the error limit, best guess, etc. >-Joe- >Joseph K. Horn >pdq@holyjoe.us ==== -=[ Fri, 17.10.03 9:55 p.m. +1300 (NZDT) ]=- in message ID : > >Yes! HP *claimed* to offer the smallest fraction equal to the > ^^^^^!! >displayed decimal number with the ->Q function. [...] > Did HP actually say just as you have quoted? This a pretty bold statement; I can't find > it in any of my manuals. Where did they say that? eg HP48SX Programmer's Reference Manual, ->Q finds a quotient of integers that agrees with the given number to the number of decimal places specified by the display format mode agrees with probably has to imply equals here -- Tony Hutchins Wellington New Zealand #56 A clean desk is a sign of a cluttered desk drawer. ==== >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. > > Did HP actually say just as you have quoted? This a pretty bold statement; I can't find > it in any of my manuals. Where did they say that? HP 48G Series User's Guide The accuracy of the fractional approximation is dependent on the display mode. If the display mode is Dtd, the approximation is accurate to 11 significant digits. If the display mode is n Fix, the approximation is accurate to n significant digits. ***Note word used: approximation HP 48G Series Advanced User's Reference Manual Command Reference 3-251 ->Q To Quontient Command: Returns a rational from of the argument. The rational result is a best guess, since there might be more than one rational expression consistent with the argument. ->Q finds a quontient of integers that agrees with the argument to within the number of decimal places specified by the display format mode. ***Note the quotas by HP: best guess ==== (follow up to the previous message, posted too quickly) .. but of course, I cannot call it IDIV2 any more as on the 49, IDIV2 will accept only integers. let's call it QUOTREM, then. Werner ==== -=[ Fri, 17.10.03 9:36 p.m. +1300 (NZDT) ]=- in message ID <44ec85ff.0310162150.a8b92ef@posting.google.com> : > (follow up to the previous message, posted too quickly) [I am always doing that] > .. but of course, I cannot call it IDIV2 any more as on > the 49, IDIV2 will accept only integers. let's call it > QUOTREM, then. Yep. Now your ->CF will be very short. I tried to incorporate your QUOTREM in it: << DEPTH ->D << 1 WHILE DUP 0 > REPEAT SWAP OVER DUP2 MOD ROT OVER - ROT / ROT ROT END DROP2 D DEPTH SWAP - ->LIST >>> I did this to generate either convergent denominators or numerators depending on the little string input CF-string little-string ->CONV with little string = {0 1} we get the denominators with it equal to {1 a0} we get the numerators. << DUP SIZE -> p a k << 2 k FOR i a i GET p i GET * p i 1 - GET + p SWAP + 'p' STO NEXT p 2 k OVER + SUB >>> I look forward to your next instalment Werner! -- Tony Hutchins Wellington New Zealand #177 A silly remark can be made in Latin as well as in Spanish. Miguel de Cervantes ==== All test examples are now calulated within 5 sec. on the old hp49g. Directory size is now 632 bytes. Gjermund Skailand ------------------------------------ @ Main program: continous fraction + check if accuracy is exact equal /<< DUP MANT 100000000000. * OVER XPON 11. SWAP - ALOG ROT 1. 0. 0. 1. /-> /<-B /<-Q1 /<-R1 /<-Q0 /<-R0 /<< DO DUP UNROT IDIV2 SWAP IF DUP FTRUE THEN TTTTT ELSE F /<-R1 '/<-R0' STO '/<-R1' STO /<-Q1 '/<-Q0' STO '/<-Q1' STO 0. END UNTIL END UNROT DROP2 F />> />> 'R2F' STO @ subprogram: Pick the fraction with smallest size /<< DUP F * OVER IF 1. - DUP FTRUE THEN DUP F * ROT IF /<= THEN -1. BRKT SWAP DROP ELSE DROP END ELSE DROP2 END 1 />> 'TTTTT' STO @ subprogram FTRUE, return 1 if fraction is exact /<< DUP /<-Q1 * /<-Q0 + SWAP /<-R1 * /<-R0 + / /<-B == />> 'FTRUE' STO @ subprogram F: calculate fraction /<< DUP /<-Q1 * /<-Q0 + SWAP /<-R1 * /<-R0 + />> 'F' STO @ subprogram BRKT: search for limit of continous fraction interval resulting in @ same (exact) result (bisesction?) /<< WHILE DUP2 + FTRUE REPEAT @ while still exact, expand interval until it includes oundary 2. * END OVER + @ determine boundary, using midpoint at each iter. DO OVER 2. / OVER 2. / + IP IF DUP FTRUE THEN SWAP ROT ELSE SWAP END DROP UNTIL DUP2 - ABS 1. /<= END DROP />> 'BRKT' STO ==== > > > 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. > [To Joe:] Ah yes of course! > 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 :) > [To Tony:] well, both of these combined is what IDIV2 does... so I keep it in. Werner ==== Finally I got the evil tests right. Here is my entry, all test examples are correct. The program builds the fraction one step at a time with cont. fractions, and check lower and upper end if that is better. Test of upper end may be unnecessary as it was not used in any of the test examples, and maybe I can remove it. The strange letter Z is the left-arrow, and the S is the >= . On my old hp49g it runs in about 6 seconds even for the evil ones. Gjemund Skailand main program Ç 1. CF 2. CF DUP MANT 100000000000. * OVER XPON 11. SWAP - ALOG DUP2 GCD ROT OVER / UNROT / ROT 1. 0. 0. 1. Ù Q R ZB ZQ1 ZR1 ZQ0 ZR0 Ç DO Q R IDIV2 R 'Q' STO 'R' STO DUP IF 1. - DUP FTRUE THEN OVER F * OVER F * IF S THEN 1. SF -1. BRKT F ROT DUP END END DROP DUP IF 1. + DUP FTRUE THEN OVER F * OVER F * IF S THEN 2. SF 1. BRKT F ROT DUP END END DROP F DUP2 ZR1 'ZR0' STO 'ZR1' STO ZQ1 'ZQ0' STO 'ZQ1' STO UNTIL / ZB == 1. FS? OR 2. FS? OR END ZQ1 ZR1 IF DUP2 / ZB == NOT THEN DROP2 1. 9.99999999999E499 END IF 2. FS?C THEN BMIN END IF 1. FS?C THEN BMIN END È È 'R2F' STO Ç WHILE DUP2 + FTRUE REPEAT 2. * END OVER + DO OVER 2. / OVER 2. / + IP IF DUP FTRUE THEN SWAP ROT ELSE SWAP END DROP UNTIL DUP2 - ABS 1. ? END DROP È 'BRKT' STO Ç DUP ZQ1 * ZQ0 + SWAP ZR1 * ZR0 + IFERR / THEN DROP END ZB == È 'FTRUE' STO Ç DUP ZQ1 * ZQ0 + SWAP ZR1 * ZR0 + È 'F' STO Ç DUP2 * 5. ROLL 5. ROLL DUP2 * 4. ROLL IF < THEN 4. ROLL 4. ROLL END DROP2 È 'BMIN' STO > > > 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. > > [To Joe:] Ah yes of course! > 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 :) > > [To Tony:] well, both of these combined is what IDIV2 does... so I keep it in. > Werner ==== of coyrse you can use con4x build 17## but hp have forgrtten to include thre arch48.hp and the xserv48.hp so use both from the previous version build 16## and also they have forgotten to include the help file in order to use the back up feture for the hp48 old transfer the arch48.hp to your calc and leave at the HOME dir it works fine with windows Me and 2000.