HP-343 === Subject: Re: Design files for 50g serial cable > The remaining issue is that the 50g will drive RxD when the calculator > is turned off or when the serial port is closed which could fry the > calculators. This seems highly, highly unlikely: Any decently-designed serial interface is fully tolerant of having transmit data lines completely shorted to ground, so I would sure *like* to believe that shorting TxD on an 50g (which is about the worst you can do to it -- having it look into RxD on a powered-off calculator is a little more forgiving) doesn't blow anything up. I am aware that in general the 50h's serial port is quite poorly designed, at least from the software point of view, though. > Also it'd be a good idea to put resistors > on the data lines in case you forget. This is good advice. ---Joel === Subject: Re: Design files for 50g serial cable > This seems highly, highly unlikely: Any decently-designed serial interface is > fully tolerant of having transmit data lines completely shorted to ground, > so I would sure *like* to believe that shorting TxD on an 50g (which is about > the worst you can do to it -- having it look into RxD on a powered-off > calculator is a little more forgiving) doesn't blow anything up. In all fairness, I didn't say anything would blow up. And I did qualify it with could. And this is why. When a 50g is in serial off (turn the calculator on, openIO then closeIO; yes, this results in a different state from just turning the calculator on!) the TX line is driven high and the RX line is driven low. So the worst case scenario you mentioned isn't just a hypothetical worst case, it actually is the case. The TX and RX lines are connected straight to the processor with no inline resistors [1] and I believe it's just a CMOS buffer with no short circuit protection. This won't necessarily kill the calculator. Eric's 50g appears to work just fine after we discovered this the hard way. As a side note, we stumbled upon this when we were taking power measurements and discovered that our test cable caused the calculator to draw more power when off than when the the calculator was on.[2] And so we know that the current drain during the short circuit situation is fairly substantial which is consistent with our belief that there is no short circuit protection. This is not something that you want to do your calculator on purpose and should degrade the functionality of the CMOS drivers even if it doesn't fry them. -Allen :-) [1] Eric heard this from a reliable source but we haven't independently opened up a 50g and verified it. [2] Eric and I both vaguely recall this being the case but it's been over a year and we couldn't find our notes regarding exactly what the current drain was. === Subject: Re: Design files for 50g serial cable > Any decently-designed serial interface is > fully tolerant of having transmit data lines completely shorted to ground Could be, but I'm suddenly reminded of the serial port bug of the HP49G, where early production runs of that model (including mine) have a serious circuit layout error, part of which was that one serial connector pin may have been routed straight to the battery, though there had been no intention to supply external power from the serial port! I don't know who designed that hardware, but I bet that Dave Arnett was thousands of miles from the scene. What's the quality of Kinpo's hardware engineering (or did HP do any of it themselves?) -[ ]- === Subject: Re: hpgcc integration program While the news message is relatively old I'd still like to present my thoughts: 1) it should be totally compatible with the build-in integrator including the FIX mode 2) optional variables could be located in CASDIR directory Nice work... have you tested double or triple integral speeds? with this in mind and considering plotting are you now willing to think about using the old display method as The Method to specify accuracy? VPN >> > - Are the tolerance options too confusing or unnecessary? With the >> > very short run-times, it might be better to just default to 1e-12. >> >> For me that would probably be best. What is the difference in size of >> code if you remove it? My experience has been that it generally >> doesn't make a whole lot of difference. > > Probably not a significant difference. I had compatibility in mind, > but that seems less and less important the more I think about it. > Perhaps the excitement of figuring out how to determine the display > settings from within my C program blinded me to whether or not it > _should_ be done. :) Honestly, I've always thought it rather annoying > to have the display settings determine the integration tolerance. > >> With the speed, will anyone ever specify anything else? >> Any instances where you wouldn't want full out to 12? > > Probably not too often, but sometimes top speed is more important than > accuracy. For example, suppose you wanted to graph > f(x)=S(0,x,g(t),t). With the low screen resolution, the tolerance > could be quite lax so as to increase plotting speed. > > Another time you might want to control the tolerance is experimenting > with badly behaved functions. > > I think defaulting to 1e-12 with optional arguments to override the > default sounds like the best option. > > -wes === Subject: Re: What is happening on hpcalc? posting-account=eF2f0AoAAAB2spBRiZOs91ItDKLGDCIk Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > I'm still waiting to see my HP49/50 uploads updated. Well there are so many new software being added, it's only fair to wait a bit for Eric to go through the entire updated list. === Subject: Re: What is happening on hpcalc? InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 1.1.4322; .NET CLR 3.0.04506.648),gzip(gfe),gzip(gfe) > > I'm still waiting to see my HP49/50 uploads updated. > it's only fair to wait a bit Given that hpcalc is the best-planned archive I've ever seen (and free!), I'm willing to wait as long as necessary. But it does seem odd about those masses of HP48 programs. Did some HP48 owner just down a case of Red Bull and start programming? :-) Bill === Subject: Re: Design files for 50g serial cable > The TX and RX lines are connected straight to the processor with no > inline resistors [1] That definitely violates my decently-designed criteria. :-( > and I believe it's just a CMOS buffer with no short > circuit protection. Shorting a few CMOS buffers on a chip generally isn't harmful -- at least short term (seconds or minuets). But certainly not a good idea either. A cable like you describe (with resistors) is definitely the smart way to go. I apologize if I've caused undue commotion here; I just didn't want people to be so fearful of killing their $150 calculator that they became afraid to experiment with their own serial port cables. ---Joel === Subject: Re: Design files for 50g serial cable > I don't know who designed that hardware, > but I bet that Dave Arnett was thousands of miles from the scene. I'm sure you're correct... does he even still work for HP? How about Preston Brown? > What's the quality of Kinpo's hardware engineering > (or did HP do any of it themselves?) Given how all the keyboard problems and how someone thought it was a good idea to drop the switching regulator in the 50g -- saving a few pennies on production costs while eating batteries significantly faster -- I'd say nowhere near as good as the old HP. === Subject: Toggle Soft Keys hp 49g+ posting-account=5jQj0AoAAAAGAGJcqkkpunLMBpVi1N5o 2.0.50727),gzip(gfe),gzip(gfe) On the hp 49g+ using USER RPL, how would I create multiple soft key assignments like those in the BASE menu? Specifically, I would like to create a soft key menu that contains a key that I could toggle through 4 choices including 1/2, 1/4, 1/8, and 1/16, depending on the tolerance I want to set. The different choices would be displayed on the corresponding soft key label. Each key press would set a different user flag that would be used in a case statement. === Subject: Re: Toggle Soft Keys hp 49g+ posting-account=5jQj0AoAAAAGAGJcqkkpunLMBpVi1N5o 2.0.50727),gzip(gfe),gzip(gfe) > On the hp 49g+ using USER RPL, how > would I create multiple soft key assignments > like those in the BASE menu? Specifically, I > would like to create a soft key menu that contains > a key that I could toggle through 4 choices > including 1/2, 1/4, 1/8, and 1/16, depending > on the tolerance I want to set. The different > choices would be displayed on the corresponding > soft key label. Each key press would set a > different user flag that would be used in a > case statement. Quirky thing, I entered a test program into my calculator << { { 1/2 } } TMENU >> and got the expected result. But, when I inserted a double quote for inches, I get { { 1/2 } } TMENU<- >> } } in stack level one. The <- character I use here is actually the return character. How do I solve that one? Getting back to the original problem, if the menu label takes a string as an argument, how do I assign multiple strings that I will toggle through? It doesn't look like I can assign a CASE statement as a soft key argument because the calculator will display the entire string in the menu label. Does this mean I have to have 4 different TMENU's, one for each press of the soft key? That doesn't seem reasonable to me, so that's why I'm asking for help. === Subject: Re: Toggle Soft Keys hp 49g+ > But, when I inserted a double quote for inches, I get > { { 1/2 } } TMENU<- >> } } in stack level one. You could use two single quotes: [alpha] [right shift] [EQW] George === Subject: Re: Toggle Soft Keys hp 49g+ posting-account=5jQj0AoAAAAGAGJcqkkpunLMBpVi1N5o 2.0.50727),gzip(gfe),gzip(gfe) > > > But, when I inserted a double quote for inches, I get > > { { 1/2 } } TMENU<- >> } } in stack level one. > > You could use two single quotes: [alpha] [right shift] [EQW] > > George the calculator that I want to extend the string. === Subject: Re: Toggle Soft Keys hp 49g+ posting-account=Wetq3woAAABPiZBJFHDdeQpHhWMpU1nw Gecko/2008072820 Firefox/3.0.1,gzip(gfe),gzip(gfe) > > > But, when I inserted a double quote for inches, I get > > { { 1/2 } } TMENU<- >> } } in stack level one. > > You could use two single quotes: [alpha] [right shift] [EQW] The hp48 has a special string syntax to include characters. To find out how it works, do: A 34 CHR + B + Then down-arrow to edit the string. It will appear as: C$3 AB === Subject: Re: Toggle Soft Keys hp 49g+ posting-account=5jQj0AoAAAAGAGJcqkkpunLMBpVi1N5o 2.0.50727),gzip(gfe),gzip(gfe) > > > > > But, when I inserted a double quote for inches, I get > > > { { 1/2 } } TMENU<- >> } } in stack level one. > > > You could use two single quotes: [alpha] [right shift] [EQW] > > The hp48 has a special string syntax to include characters. To find > out how it works, do: > > A 34 CHR + B + > > Then down-arrow to edit the string. It will appear as: > > C$3 AB === Subject: Re: Toggle Soft Keys hp 49g+ How about using graphics e.g., a small GROB as a label > On the hp 49g+ using USER RPL, how > would I create multiple soft key assignments > like those in the BASE menu? Specifically, I > would like to create a soft key menu that contains > a key that I could toggle through 4 choices > including 1/2, 1/4, 1/8, and 1/16, depending > on the tolerance I want to set. The different > choices would be displayed on the corresponding > soft key label. Each key press would set a > different user flag that would be used in a > case statement. Quirky thing, I entered a test program into my calculator << { { 1/2 } } TMENU >> and got the expected result. But, when I inserted a double quote for inches, I get { { 1/2 } } TMENU<- >> } } in stack level one. The <- character I use here is actually the return character. How do I solve that one? Getting back to the original problem, if the menu label takes a string as an argument, how do I assign multiple strings that I will toggle through? It doesn't look like I can assign a CASE statement as a soft key argument because the calculator will display the entire string in the menu label. Does this mean I have to have 4 different TMENU's, one for each press of the soft key? That doesn't seem reasonable to me, so that's why I'm asking for help. === Subject: Re: Toggle Soft Keys hp 49g+ posting-account=5jQj0AoAAAAGAGJcqkkpunLMBpVi1N5o 2.0.50727),gzip(gfe),gzip(gfe) On Aug 24, 2:08Êam, Veli-Pekka Nousiainen > How about using graphics e.g., a small GROB as a label > > > > would I create multiple soft key assignments > > like those in the BASE menu? Specifically, I > > would like to create a soft key menu that contains > > a key that I could toggle through 4 choices > > including 1/2, 1/4, 1/8, and 1/16, depending > > on the tolerance I want to set. The different > > choices would be displayed on the corresponding > > soft key label. Each key press would set a > > different user flag that would be used in a > > case statement. > > Quirky thing, I entered a test program into my calculator > << { { 1/2 } } TMENU >> and got the expected result. > But, when I inserted a double quote for inches, I get > { { 1/2 } } TMENU<- >> } } in stack level one. The > <- character I use here is actually the return character. > How do I solve that one? Getting back to the original > problem, if the menu label takes a string as an > argument, how do I assign multiple strings that > I will toggle through? It doesn't look like I can assign > a CASE statement as a soft key argument because > the calculator will display the entire string in the > menu label. Does this mean I have to have 4 > different TMENU's, one for each press of the > soft key? That doesn't seem reasonable to me, so > that's why I'm asking for help. menu and leave the F1 label blank and use a 21x8 GROB instead? If I build a GROB beginning with GROB 21 8, what hex code would I use to display 1/2? Is there a list out there that has all of the ASCII character codes and how to use them to build a GROB on the hp 49g+? === Subject: Re: Toggle Soft Keys hp 49g+ posting-account=iY7uIQoAAAAuLKgvClKqajiXarQcLhyc Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > > would I create multiple soft key assignments > > like those in the BASE menu? Specifically, I > > would like to create a soft key menu that contains > > a key that I could toggle through 4 choices > > including 1/2, 1/4, 1/8, and 1/16, depending > > on the tolerance I want to set. The different > > choices would be displayed on the corresponding > > soft key label. Each key press would set a > > different user flag that would be used in a > > case statement. > > Quirky thing, I entered a test program into my calculator > << { { 1/2 } } TMENU >> and got the expected result. > But, when I inserted a double quote for inches, I get > { { 1/2 } } TMENU<- >> } } in stack level one. The > <- character I use here is actually the return character. > How do I solve that one? Getting back to the original > problem, if the menu label takes a string as an > argument, how do I assign multiple strings that > I will toggle through? It doesn't look like I can assign > a CASE statement as a soft key argument because > the calculator will display the entire string in the > menu label. Does this mean I have to have 4 > different TMENU's, one for each press of the > soft key? That doesn't seem reasonable to me, so > that's why I'm asking for help. you'd better learn how to ask NICELY === Subject: Re: hpgcc integration program posting-account=aJhvMAoAAABqICGF80eSUn6d3D9SANQE Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) On Aug 23, 9:17 am, Veli-Pekka Nousiainen > with this in mind and considering plotting are you now willing to think about > using the old display method as The Method to specify accuracy? The more I've thought about the issue, the more I agree with Tim's comment: With the speed, will anyone ever specify anything else? Also, I don't really like the idea of the display mode changing the answer of a calculation. We certainly wouldn't like it if SQRT or SIN behaved this way. I can understand the original logic with the HP-34C, but with today's speed, I think it's no longer needed. The defaults can still be overridden by optional arguments, so the trade- off with speed and accuracy is still available. > 1) it should be totally compatible with the build-in integrator > including the FIX mode To be totally compatible, I'd have to use the exact same Romberg implementation so as to get the same result as the built-in integrator. Since the whole point of my program was to implement a Gauss-Kronrod method, I won't be getting the exact same results anyway, so I might as well use the better results. With that in mind, I'm currently calculating with a default relative tolerance of 1e-12 and a default max depth of 200 and the result is then rounded to the 50g's max relative tolerance of 1e-11. > 2) optional variables could be located in CASDIR directory How about looking in the current directory, then PATH, then CASDIR. That way a user could have different variable values in different directories if he wanted. I have separate PHYSICS and CALCULUS directories -- physics class requires relative tolerance (significant figures) while the calculus AP exam requires absolute tolerance (decimal places). > have you tested double or triple integral speeds? No, but that's a good suggestion. The way the program is currently written, I'd have to have separate double integral and triple integral programs. I think a better way would be to have a generic program that could do any level of nested integrals. You never know when you might want that quintuple integral. I used the program in class quite successfully all last semester. There are a few bugs with the called HPStack/HPParser libraries that need to be fixed before I can release anything. (I also recently signed up for the hpgcc3-beta and am looking forward using it for this program.) I've sometimes wondered about the need for such a program. However, at the end of last year, my students were taking a standardized exam, one section of which required them to answer 17 question in 50 minutes. One of the questions required numeric integration of a function containing a cusp. In standard mode, the 50g takes 33 minutes to complete. Of course, they didn't need such high precision and using FIX 5 would give an acceptable answer in 30 seconds, but it's quite likely that many (most?) 50g users don't know about this feature as it is not documented except in the AUR. (FWIW, my program takes 0.22 seconds.) have some motivation to dust off the code and make some improvements. -wes On Aug 23, 9:17Êam, Veli-Pekka Nousiainen > While the news message is relatively old > I'd still like to present my thoughts: > > 1) it should be totally compatible with the build-in integrator > Ê Ê including the ÊFIX mode > 2) optional variables could be located in CASDIR directory > > Nice work... > have you tested double or triple integral speeds? > with this in mind and considering plotting > are you now willing to think about using the old display method > as The Method to specify accuracy? > VPN > > > > >> > - Are the tolerance options too confusing or unnecessary? ÊWith the > >> > very short run-times, it might be better to just default to 1e-12. > > >> For me that would probably be best. ÊWhat is the difference in size of > >> code if you remove it? ÊMy experience has been that it generally > >> doesn't make a whole lot of difference. > > > Probably not a significant difference. ÊI had compatibility in mind, > > but that seems less and less important the more I think about it. > > Perhaps the excitement of figuring out how to determine the display > > settings from within my C program blinded me to whether or not it > > should be done. :) ÊHonestly, I've always thought it rather annoying > > to have the display settings determine the integration tolerance. > > >> With the speed, will anyone ever specify anything else? > >> Any instances where you wouldn't want full out to 12? > > > Probably not too often, but sometimes top speed is more important than > > accuracy. ÊFor example, suppose you wanted to graph > > f(x)=S(0,x,g(t),t). ÊWith the low screen resolution, the tolerance > > could be quite lax so as to increase plotting speed. > > > Another time you might want to control the tolerance is experimenting > > with badly behaved functions. > > > I think defaulting to 1e-12 with optional arguments to override the > > default sounds like the best option. > > > -wes === Subject: Re: What is happening on hpcalc? posting-account=csTZXgoAAAAbLFyIpZhF6lUYhcG2k6N4 MathPlayer 2.10b; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648),gzip(gfe),gzip(gfe) > > Could anybody explain what is happening on hpcalc? > Maybe he's just having a case of backup plan mishap. === Subject: Re: What is happening on hpcalc? > > > > Could anybody explain what is happening on hpcalc? > > > > Maybe he's just having a case of backup plan mishap. I don't know what a backup plan mishap is, but I don't think that is the case. I think the sole addition made yesterday explains it. Eric Rechlin === Subject: Re: What is happening on hpcalc? > Given that hpcalc is the best-planned archive I've ever seen (and > free!), I'm willing to wait as long as necessary. But it does seem > odd about those masses of HP48 programs. Did some HP48 owner just > down a case of Red Bull and start programming? :-) Maybe he's found the Dead Sea scrolls of the HP48, and is too busy to be drawn out for an interview about it :) http://www.ibiblio.org/expo/deadsea.scrolls.exhibit/intro.html http://en.wikipedia.org/wiki/Dead_Sea_Scrolls [r->] [OFF] === Subject: Re: What is happening on hpcalc? It appears that many of the old programs from the Goodies Disks are being migrated to individual entries on hpcalc. Perhaps they're the best-of-the-best, the all-stars as it were. Probably very few folks these days know of, or look into, the old Goodies Disk archives. There's a lot of GOOD stuff in them, if one digs. Mr. Joseph K. Horn (JKH) did a marvelous job of compiling and explaining, to the extent possible, all of that old work. Heck, I've still got the original 3.5 inch disks ordered from Educalc (what were they, $5 ?). Just for an example, examine the two programs recently listed: SORTLN and SORTLS for sorting numbers and strings. Excellent programs that IIRC pre-dated any SORT function on the 48G series and even now can (sometimes) out-perform the general SORT on the 49/50 series. Plus, there's an opportunity to learn some SysRpl. Maybe Eric figures it's time to promote this older stuff, maybe there's additional server space or bandwidth - who knows? CR === Subject: Re: What is happening on hpcalc? It appears that many of the old programs from the Goodies Disks are being migrated to individual entries on hpcalc. Perhaps they're the best-of-the-best, the all-stars as it were. Probably very few folks these days know of, or look into, the old Goodies Disk archives. There's a lot of GOOD stuff in them, if one digs. Mr. Joseph K. Horn (JKH) did a marvelous job of compiling and explaining, to the extent possible, all of that old work. Heck, I've still got the original 3.5 inch disks ordered from Educalc (what were they, $5 ?). Just for an example, examine the two programs recently listed: SORTLN and SORTLS for sorting numbers and strings. Excellent programs that IIRC pre-dated any SORT function on the 48G series and even now can (sometimes) out-perform the general SORT on the 49/50 series. Plus, there's an opportunity to learn some SysRpl. Maybe Eric figures it's time to promote this older stuff, maybe there's additional server space or bandwidth - who knows? CR === Subject: Re: What is happening on hpcalc? posting-account=aJhvMAoAAABqICGF80eSUn6d3D9SANQE Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) I did a double-take when I saw the following new entry: PROOT Super-fast polynomial roots finder. By Bill Wickes. I thought for a moment that the legend had returned, but alas, the file dates were from 1992. I take it this is what eventually became the built-in PROOT? -wes === Subject: Re: Printed User's Guide for 50g? >> >> >I was wondering if it is possible to buy a printed copy of the 50g's user >> >guide (the ~900 page one, not the skimpy one that comes with it), outside >> >of having it printed somewhere? >> >> No, you can't - a printed copy *must* have been printed somewhere.... Ê;-) >> >> - > >Given the cost of printed books a copy from Staples or Kinko's is >quite reasonable. You can give them a 'thumb drive' with the pdf >files on it and have it printed and bound for a reasonable cost. 18 cents for double side printed page. At Kinko's, today. 900 pages is 450 double sided pages, what makes $81 for printing plus $10 for binding - it is to big to be bound as single volume. Plust tax. About $100+ all together. Not bad, taking into account that the calculator itself is $140. By the way, probably you need two books: User Manual and Advanced User Manual. Both about 900 pages A.L. === Subject: HP4820 Won't Print! All of a sudden, HP 4820 All-in-One won't print or scan, but will copy. Get an error message from the computer that 'a USB accessory has malfunctioned,' since the mouse, keyboard and card reader are working and the printer is not...guess it's the printer being referred to. Could it be something like replacing the USB cable (if so, where to buy) or putting it into another USB port (hard to get to, but I can do it)? Or what? I would be grateful for any === Subject: Re: HP4820 Won't Print! problem has been solved, just had to move cable to a different USB port... > All of a sudden, HP 4820 All-in-One won't print or scan, but will copy. > Get an error message from the computer that 'a USB accessory has > malfunctioned,' since the mouse, keyboard and card reader are working and > the printer is not...guess it's the printer being referred to. Could it be > something like replacing the USB cable (if so, where to buy) or putting it > into another USB port (hard to get to, but I can do it)? Or what? I would > === Subject: Re: How to suggest features to the hp calculator team? ) > Oh, yes, yes... And all there parenteses and such are SOOOOO... > confusing... > > A.L. > On TI-83/84, definitely confusing. The entered expression just goes on one line and wraps around to the next if it is too long. All levels of parenthesis look the same and are not highlighted as you close them. On TI-89 with pretty print on, this is not as much of a problem. S.C. === Subject: Re: How to suggest features to the hp calculator team? > Look again. They were correcting the error in the 2006 version, not > adding it. You're right. I unfairly blamed HP. I guess I saw the 128K on the one with 0.9 and assumed I was looking at the old one. :) > BTW, I'm quite impressed by the selection of images on the commerce > site. It is quite rare to see any commerce site with decent photos of > the products these days. It disappointed me too, that there was no good historical record of these products. For calculator collectors, seeing how things were in the past might be very interesting. Plus, from a consumer point of view, it is sometimes incredibly difficult to see the details of a product before you buy it if the web site selling it just has a little tiny photo, and nothing (aside from actually holding the product in your hands) can substitute for a high-resolution photo. Last fall I wanted to start making pages about each of the HP calculators to put on my web site, since HP doesn't have much good information on their web site. I ended up just putting it on the commerce site; I'll add them to the main site eventually, but I have some other things I want to finish first, since the infrastructure isn't there for them yet. I built a light box (about $25 in parts from Home Depot and an arts/crafts store), set it on my kitchen counter, set up my tripod and 4-year-old digital camera, and photographed everything. Then I spent probably 30+ hours writing detailed specifications for each calculator, cleaning up all the photographs, and putting it into web pages. I also have a bunch of photographs I took of other models in my collection, and I'll eventually bring those online too, when I have a place to put them on the site. Interestingly, that relatively minimal effort approximately doubled my calculator sales. After the secondary boost caused by adding the shopping cart in January, I now handle about one order a day. Doesn't pay the bills, but it's a fun little thing on the side. :) Eric Rechlin === Subject: Re: How to suggest features to the hp calculator team? I have been trying to reach you by mail but without success. Would be nice if you could drop me a mail ;-) Best wishes, Andreas === Subject: Re: menu in picture mode The following demonstrates showing PICT with any menu, unaffected by using NXT to scroll the menu: @ version for HP49/50 series ONLY << { A B C D E F G } TMENU { #0 #0 } PVIEW 3 FREEZE #2EE67h SYSEVAL #2EE91h SYSEVAL >> Always back up memory first, before using any SYSEVAL! The system functions invoked are: SetDA1Valid SetDA2Valid The corresponding ROM addresses for HP48S[X]/G[X] are: #38FD2h and #3915Dh === Subject: Re: My wish list for an improved 50g I wish HP or BP can make an HP49/50 ROM that could work with delimiters (thousands, millions, etc) when working WITH UNITS. Now its just impossible, when you set any kind of unit the commas are cleared. Daniel === Subject: Re: My wish list for an improved 50g > How about string processing? > B->I > << PUSH DEC ->STR 3. OVER SIZE 1. - SUB OBJ-> POP >> You must also make sure to get into Exact mode before OBJ-> or else the result will be a real type, which might not even represent exactly the same value (although it would be the same as produced by I->R) > I->B > << # SWAP + d + OBJ-> >> Watch out for inputs which are either too large or negative. The above methods employ the internal compiler, which is often slower than using just calculation. Avoidance of using the internal compiler is in fact why perfectly valid numeric port tags (e.g. :2.0:X STO) which would have worked fine in the HP48S[X]/G[X] series do not work in the HP49/50 series -- the earlier series first compiled any port tag and checked for a real result, while the later series, concerned about execution time even for relatively infrequent port operations, recognizes only :2:X and :2.:X (this can break some programs when in FIX or SCI display mode, for example). Even :2.:X was originally not recognized in early HP49G ROMs, but the necessity of allowing this was eventually conceded :) === Subject: Re: My wish list for an improved 50g > Digit separators in Standard display mode (like the HP-35s). It would have to done, however, without affecting ->STR (currently both the STD mode stack display and ->STR share one common decompiler function); otherwise ->STR would produce strings which STR-> could not re-compile, which might break lots of existing software. Doing the above also expands the maximum length of the display string by three characters: -8,888,888,888.88 In some other calculators, each display digit includes the annunciators for . and , so that no string expansion is required to show decimals and separators, but note that in the HP48/49/50 series, every character occupies its own position. You could easily create your own function, however, for displaying numbers exactly as you desire (just remove trailing zeros from normal FIX mode display); in the HP49/50 series you can even automatically overlay this display on stack level 1, whenever there is a real number on that level. > a B->I function (yes, I can use B->R and then R->I > but why not just combine them) The combination of the two existing functions is not even adequate, because the range of both user binary and integer data types exceeds the range of uniquely representable real integers (which are limited to twelve significant digits), e.g. #123456789012345d B->R R->I produces 123456789012000 Therefore, B->I and I->B ought to have been suggested during HP49G development or early deployment, but no one did (I must myself have been taking a nap at the time :) Although much simpler-looking programs than the following can be constructed to operate on one value at a time, the following are not only faster, but also accommodate input lists: << 8. SQ STWS DUP B->R R->I DUP R->B ROT - 8. ALOG SWAP OVER R->B ADD B->R SWAP - R->I - >> 'B->I' STO << 8. SQ STWS 0 MAX 18446744073709551615 MIN DUP R->B DUP B->R R->I ROT - I->R 8. ALOG SWAP OVER ADD SWAP R->B - - >> 'I->B' STO Notes: These don't restore any smaller original binary word size (which is good form to do, but can also make results look wrong). In keeping with R->B, I->B has the same minimum (zero) and maximum (2^64-1) output, indicating no range errors. Exact mode must be set before compiling the above; otherwise 18446744073709551615 will be misinterpreted as a real number. > Why is HP having so much issues > with fundamentals like keys on a calculator? These are fundamentally difficult times :) Back to basics, I say (but not Back to BASIC :) === Subject: Design files for 50g serial cable In case anyone is interested, I have posted the design files (source code and pcb/gerber files) for the Allen & Eric 50g serial cable (commonly known as the hpcalc.org cable or simply Eric's cable) at http://allenwan.com/hpcalcserialcable/ A couple notes/warnings: -the files provided are for the current hardware and software revisions which are HW:v3 and SW:ver.20080217 -for the pcb/gerber files, we didn't actually use the silk screen or solder mask layers. I don't think there's any harm in using them, but I recommend double checking clearances. -for the source code, the HPCalcSerial.c contains all of the code unique to this project. It requires a few files/libraries from AVR-libc. The code was compiled with avr-gcc. The fuse settings used for the ATtiny24 are 0xFF;0xD8;0x42 extended;high;low -Allen Wan :-) === Subject: Re: Design files for 50g serial cable Allen Wan kirjutas: > In case anyone is interested, I have posted the design files (source > code and pcb/gerber files) for the Allen & Eric 50g serial cable > (commonly known as the hpcalc.org cable or simply Eric's cable) at > http://allenwan.com/hpcalcserialcable/ > > A couple notes/warnings: > -the files provided are for the current hardware and software revisions > which are HW:v3 and SW:ver.20080217 > > -for the pcb/gerber files, we didn't actually use the silk screen or > solder mask layers. I don't think there's any harm in using them, but I > recommend double checking clearances. > > -for the source code, the HPCalcSerial.c contains all of the code unique > to this project. It requires a few files/libraries from AVR-libc. The > code was compiled with avr-gcc. The fuse settings used for the ATtiny24 are > 0xFF;0xD8;0x42 > extended;high;low > > -Allen Wan :-) May I put my ignorance on display? What happens when omitting, between the two hp50g, the converter circuitry and using only copper (ground,RX,SX)? Is there a limitation on cable length, possible damage to controller or what? What is the difference between the SW:ver.20071007 and SW:ver.20080217. Is it only code regarding the autoshutdown mode switch? Robert Tiismus === Subject: Re: Design files for 50g serial cable > May I put my ignorance on display? What happens when omitting, between > the two hp50g, the converter circuitry and using only copper > (ground,RX,SX)? Is there a limitation on cable length, possible damage > to controller or what? There are a couple of issues with that. First, I'm not aware of any cable that does that (i.e. a cross over cable for mini 4pin usb). The one we use, #150122 from Bestlink Netware would cause Vcc <--> Vcc TxD <--> TxD RxD <--> RxD GND <--> GND instead of Vcc <--> Vcc TxD <--> RxD RxD <--> TxD GND <--> GND Also one calculator's battery would attempt to charge the others. The batteries are literally directly connected to the Vcc lines on the mini 4 pin USB socket. There's nothing in between so you actually get 6v not 5v. But if you're going to build the cable yourself, you can easily fix that by building it without the power lines connected. Vcc XXXX Vcc TxD <--> RxD RxD <--> TxD GND <--> GND The remaining issue is that the 50g will drive RxD when the calculator is turned off or when the serial port is closed which could fry the calculators. You can easily work around this by not plugging in your cable until both calculators are turned on AND have their serial ports turned on (openio). And unplugging the cable before either closing IO or turning the calculators off. Also it'd be a good idea to put resistors on the data lines in case you forget. Vcc XXXX Vcc TxD <1k> RxD RxD <1k> TxD GND <--> GND where 1k is a 1k ohm resistor. This may all seem like a lot of trouble to go to but I can see the motivation given that the other available option runs around fifty dollars. The one hick-up would be getting the 4 pin mini usb cable which I'd probably be willing to sell you for five dollars shipped (in the U.S.). > What is the difference between the SW:ver.20071007 and SW:ver.20080217. > Is it only code regarding the autoshutdown mode switch? Yes, but it also coincided with us depopulating the switch that controlled the feature (there use to be a small dip switch inside the shell) and the software change made it so that it's on by default instead of off. -Allen Wan === Subject: Re: Design files for 50g serial cable posting-account=82unwgoAAABKn0foN-teZr4DLYjqF_TL Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) >The > batteries are literally directly connected to the Vcc lines on the mini > 4 pin USB socket. There's nothing in between so you actually get 6v not > 5v. Let me think. If you have alkaline batteries they have a nominal voltage of 1.5v. 4 * 1.5 volts is 6 volts. But the nominal voltage for alkaline really only applies under no load or minimal load. With a reasonable load after having been used for a while they tend to put out closer to 1.25 v. 4 * 1.25 = 5 volts. You would only get closer to 6 volts if the calculator was off. For the attempting to charge each other reasons though there definitely could be issues. >But if you're going to build the cable yourself, you can easily fix > that by building it without the power lines connected. It is advisable to leave GND connected. (your diagrams show this, but you mentioned power lines plural, so clarifying is good. This ensures both calculators are measuring the data lines voltages from the same reference level. After all battery powered devices have no reference to true earth ground, and could certainly drift by several volts relative to each other. > Vcc XXXX Vcc > TxD <--> RxD > RxD <--> TxD > GND <--> GND > > The remaining issue is that the 50g will drive RxD when the calculator > is turned off or when the serial port is closed which could fry the > calculators. You can easily work around this by not plugging in your > cable until both calculators are turned on AND have their serial ports > turned on (openio). And unplugging the cable before either closing IO or > turning the calculators off. Also it'd be a good idea to put resistors > on the data lines in case you forget. > > Vcc XXXX Vcc > TxD <1k> RxD > RxD <1k> TxD > GND <--> GND > where 1k is a 1k ohm resistor. > > This may all seem like a lot of trouble to go to but I can see the > motivation given that the other available option runs around fifty > dollars. The one hick-up would be getting the 4 pin mini usb cable which > I'd probably be willing to sell you for five dollars shipped (in the U.S.). > > What is the difference between the SW:ver.20071007 and SW:ver.20080217. > Is it only code regarding the autoshutdown mode switch? > > Yes, but it also coincided with us depopulating the switch that > controlled the feature (there use to be a small dip switch inside the > shell) and the software change made it so that it's on by default > instead of off. === Subject: Re: What is happening on hpcalc? > > Could anybody explain what is happening on hpcalc? A good question. For a week now there's been a daily flood of HP48 programs being installed. I'm still waiting to see my HP49/50 uploads updated. === Subject: Re: Drawing Arcs just to read this posting gives me as a log time hp user (1st my very own was HP-21) a very warm feeling thank you Cyrille and U 2, Yann VPN Hello the same convention as Jacob (Bearing 0¡ is North, Clockwise) and output in Graphical display, for both HP48SX & GX. You can download both SourceCode & Binary at : http://phantasie.tonempire.net/utilitaires-f7/fast-approximative-arc-t59.htm #61 No problem with speed, it is hand down the fastest code around, with output in the less-than-40ms zone for 48GX, including SysRPL header which costs about 11ms alone. However, there are still some issues with this version : 1) Accuracy is not correct. I've displayed some screenshots in the link to illustrate. I think this is a direct consequence of the selected methodology (pixel counting). I had the same issue with my first code some time ago, with equivalent accuracy consequences. 2) The first quarter is sometimes not drawn. Probably a bug into the discarding code. I tried to remove it in order to release a usable binary, but unfortunately it produced additionnal side effects, such as a sudden 90¡ output shift depending on input values (try Start Bearing = -1¡ & +1¡). The bug can probably be corrected, but the accuracy may require a different methodology, potentially resulting non-trivial code changes. As a personal sidenote, i must add that your code provided me with the contribution. === Subject: Re: Drawing Arcs posting-account=82unwgoAAABKn0foN-teZr4DLYjqF_TL Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) On Aug 12, 5:27Êpm, Veli-Pekka Nousiainen > just to read this posting gives me > as a log time hp user (1st my very own was HP-21) > a very warm feeling > > thank you Cyrille and U 2, Yann > VPN You are a *logarithmic* time HP calulator user? Hmm......... === Subject: Re: Drawing Arcs at least if you look back then timescale seems to be compressed :-D On Aug 12, 5:27 pm, Veli-Pekka Nousiainen > just to read this posting gives me > as a log time hp user (1st my very own was HP-21) > a very warm feeling > > thank you Cyrille and U 2, Yann > VPN You are a *logarithmic* time HP calulator user? Hmm......... === Subject: Re: HP 42s posting-account=5jQj0AoAAAAGAGJcqkkpunLMBpVi1N5o 2.0.50727),gzip(gfe),gzip(gfe) On Aug 12, 5:38Êam, Veli-Pekka Nousiainen > No, I'm not saying that there is such a product > but what I would like to C is > either a ARM9 or ARM7 based 42 reincarnation. > > After translating the 35s quick guide to Finnish, > I actually got the calc and > translated a 32SII small surveying program to 35S program > > I immediately noticed that it would be possible to save > all the data points into the indirect registers > but since nobody is paying me to do that... > I'm currently living on short contracts and that doesn't....pay > > SDK for the 20b Little Euro naturally hints about > programmable business calc BIG Euro > but what about SuperEuro or Sci-Euro a true 42S > High Speed USB 2.0 interface is all that is needed (perhaps SDIO?) > > I wouldn't mind even if it would be ARM9, > then HPGCC might adapt to it, too...C my point? . > > Only if ALPHA input is more 50G -like, otherwise 42 will do > May it be even HP 42SX ; X=eXpandable, that is: > ROM reflashable through SDIO and/or USB, > plus possibility to download/upload programs/data > > What 42 was missing (and the 32,33,35, too) > is possibility to save programs/data > > Therefore it is not a handheld computer, but a mere calculator > computer needs upload/download e.g.. external storage capability > > Just my .02 ?uros I used the 42 for a few years before I got my 48. The 42 was particularly enjoyable to use with the HP thermal printer because I could print circular curve and stake-out data. I thought the 42 was quite a bit faster than my 41 and I liked the 2-line display. I would not care for a reincarnation of the 42 primarily because I like a larger display. I will always like my 48 the best because it was durable, the keys were indestructible, and the big ENTER key was right where I liked it! === Subject: The Forty-Eight Forum Newsletter posting-account=5jQj0AoAAAAGAGJcqkkpunLMBpVi1N5o 2.0.50727),gzip(gfe),gzip(gfe) Does anyone out there have the complete collection of The Forty-Eight Forum newsletter that was published by Surveyor's Module Inc. (SMI) beginning with the first issue in June 1990? My last issue is July/ August/September 1992. === Subject: Re: How to suggest features to the hp calculator team? On 2008-08-11 22:53:17 +1000, cyrille de brebisson said: > hello, > > not true. > > cyrille maybe only you care .. but is that enough? -- They who would give up an essential liberty for temporary security, deserve neither liberty or security (Benjamin Franklin) === Subject: Re: How to suggest features to the hp calculator team? <48a2b95a$0$10796$426a74cc@news.free.fr> posting-account=eF2f0AoAAAB2spBRiZOs91ItDKLGDCIk Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) Knowing what your customers are willing to pay for is no easy task, not least because there are so many different users, with very very different needs. As an old example, i remembered having read a complain from land surveyors when the 48GX was phased out in favor of a much more powerfull unit ... which lacked a critical feature for them (i think it was serial connexion). That's the kind of error which makes you loose a complete customer's sector (now, this is just an illustration, i'm not assuming it was good or bad, this part is HP strategy). This is a job that the Marketing team should handle, if it ever exists. It wouldn't be the first time that a company is poorly served by abysmal marketing though. In this newsgroup, we are likely to find requests from die-hard users, extremely technicals, with very deep requests, which are bound to be uninteresting to most casual users. True but, as any buzz-marketer should know, this is exactly this kind of customer group which builds up a brand, making it acknowledged as a must have product to less-involved but still paying users. This could be usefully considered as communication effort. But well, as just said, this should be handled by marketing, not R&D teams, nowadays, technical teams have little cloud & power to steer company decisions. Quite a pity if you ask me, and that's the way it is... === Subject: Re: How to suggest features to the hp calculator team? <7IGdne2aa5wnxDzVnZ2dnUVZ_sDinZ2d@speakeasy.net> posting-account=sOAX1QkAAAC-FcySTSbz29Uk8huUtFRz CLR 1.1.4322; .NET CLR 2.0.50727),gzip(gfe),gzip(gfe) > But can it play music videos?http://www.amazon.com/dp/B00004TVDN > > The user reviews for the product above are interesting. > > > Ê Hands down, the Casio wins, and it is cheaper as well. > Ê The calculator is more user friendly. > Ê The options are menu driven in a more intuitive way. > Ê What took me a minute or two to locate and figure out out the TI, > Ê took less than half the time on the Casio... > Ê The color thing I suppose is nice, > Ê but I use the CFX-9750, which is black and white and cheaper. > TI has the USA school system eating out of its hands. Their marketing division deserves some credit though with the TI-83/84 series hype. The original vanilla TI-83 was introduced 12 years ago in 1996. Now, it is still being sold, though re-named the TI-84+/silver. The TI-84's promise keystroke-for-keystroke compatibility with the TI-83, which is a fancy way of saying We didn't bother to put any new features into this 12-year-old calculator. I prefer my $9 Casio fx-260 solar pocket scientific to the brick-sized TI-84's. I can do calculations faster on the Casio than the TI because it uses a mixed ALG/RPN entry (though I prefer pure RPN :) Another interesting fact is that currently on Amazon, the TI-84 silver sells for $135 while the 50g sells for only $118. A no-brainer if there ever was one. [Even if you refuse to go HP, the TI-89 Titanium costs only $140, making me strongly question why anyone would buy the TI-84 silver] S.C. === Subject: Re: How to suggest features to the hp calculator team? <7IGdne2aa5wnxDzVnZ2dnUVZ_sDinZ2d@speakeasy.net> posting-account=82unwgoAAABKn0foN-teZr4DLYjqF_TL Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > > > But can it play music videos?http://www.amazon.com/dp/B00004TVDN > > > The user reviews for the product above are interesting. > > > > Ê Hands down, the Casio wins, and it is cheaper as well. > > Ê The calculator is more user friendly. > > Ê The options are menu driven in a more intuitive way. > > Ê What took me a minute or two to locate and figure out out the TI, > > Ê took less than half the time on the Casio... > > Ê The color thing I suppose is nice, > > Ê but I use the CFX-9750, which is black and white and cheaper. > > TI has the USA school system eating out of its hands. Their marketing > division deserves some credit though with the TI-83/84 series hype. > The original vanilla TI-83 was introduced 12 years ago in 1996. Now, > it is still being sold, though re-named the TI-84+/silver. The TI-84's > promise keystroke-for-keystroke compatibility with the TI-83, which is > a fancy way of saying We didn't bother to put any new features into > this 12-year-old calculator. > > I prefer my $9 Casio fx-260 solar pocket scientific to the brick-sized > TI-84's. I can do calculations faster on the Casio than the TI because > it uses a mixed ALG/RPN entry (though I prefer pure RPN :) > > Another interesting fact is that currently on Amazon, the TI-84 silver > sells for $135 while the 50g sells for only $118. A no-brainer if > there ever was one. [Even if you refuse to go HP, the TI-89 Titanium > costs only $140, making me strongly question why anyone would buy the > TI-84 silver] The issue here is the arguably unlawful mandating of a specific calculator by teachers in public schools who have books with Ti-83 instructions, and no other. Consider that many average idiots could not do anything complicated with a graphing calculator without step by step instructions. (These are the people who have trouble getting into a community college). If those idiots had an HP50g, there is almost no way the teacher would be able to provide the needed step by step instructions unless they were very familiar with the calculator. This even hurts the sales of the TI-89. Well, that and the fact that some tests ban the TI-89 due to the CAS. === Subject: Re: How to suggest features to the hp calculator team? <7IGdne2aa5wnxDzVnZ2dnUVZ_sDinZ2d@speakeasy.net> posting-account=5jQj0AoAAAAGAGJcqkkpunLMBpVi1N5o 2.0.50727),gzip(gfe),gzip(gfe) On Aug 12, 9:39Êpm, username localhost > > > > > > > > > But can it play music videos?http://www.amazon.com/dp/B00004TVDN > > > > The user reviews for the product above are interesting. > > > > > Ê Hands down, the Casio wins, and it is cheaper as well. > > > Ê The calculator is more user friendly. > > > Ê The options are menu driven in a more intuitive way. > > > Ê What took me a minute or two to locate and figure out out the TI, > > > Ê took less than half the time on the Casio... > > > Ê The color thing I suppose is nice, > > > Ê but I use the CFX-9750, which is black and white and cheaper. > > > TI has the USA school system eating out of its hands. Their marketing > > division deserves some credit though with the TI-83/84 series hype. > > The original vanilla TI-83 was introduced 12 years ago in 1996. Now, > > it is still being sold, though re-named the TI-84+/silver. The TI-84's > > promise keystroke-for-keystroke compatibility with the TI-83, which is > > a fancy way of saying We didn't bother to put any new features into > > this 12-year-old calculator. > > > I prefer my $9 Casio fx-260 solar pocket scientific to the brick-sized > > TI-84's. I can do calculations faster on the Casio than the TI because > > it uses a mixed ALG/RPN entry (though I prefer pure RPN :) > > > Another interesting fact is that currently on Amazon, the TI-84 silver > > sells for $135 while the 50g sells for only $118. A no-brainer if > > there ever was one. [Even if you refuse to go HP, the TI-89 Titanium > > costs only $140, making me strongly question why anyone would buy the > > TI-84 silver] > > The issue here is the arguably unlawful mandating of a specific > calculator by teachers in public schools who have books with Ti-83 > instructions, and no other. Consider that many average idiots could > not do anything complicated with a graphing calculator without step by > step instructions. (These are the people who have trouble getting into > a community college). If those idiots had an HP50g, there is almost no > way the teacher would be able to provide the needed step by step > instructions unless they were very familiar with the calculator. > > This even hurts the sales of the TI-89. Well, that and the fact that > some tests ban the TI-89 due to the CAS.- Hide quoted text - > > - Show quoted text - We really have a great discussion going on here! When will HP call its graphing calculators by what they really are-computers or would that be a marketing blunder? I think the graphing computer would tantalize the imagination of the high school or college student shopping for a calculator. Better yet, a hand-held graphing computer, because that would remove any ambiguity that it might be a notebook computer. I think the greatest strength of any calculator is the ability to customize it to work the way I work. The USER mode allows me to assign keys but I have to memorize their assignments unless I can put an overlay over the keyboard like the 48 series allowed you to do. The quality of the hardware is also important to me. The black plastic bezel on my 49 G+ cracked after minimal use. I don't expect my calculator to endure the rigors of outdoor or industrial use but I do expect to get some use out of it before it degrades. Finally, I would like to see an HP-supported SDK that includes really good documentation for those of us who are not professional programmers, computer scientists, or electrical engineers. I see a lot of people on this Usenet group who are interested in going beyond the User Manual and I think HP should support them because happy users promote sales! === Subject: Re: How to suggest features to the hp calculator team? <7IGdne2aa5wnxDzVnZ2dnUVZ_sDinZ2d@speakeasy.net> posting-account=82unwgoAAABKn0foN-teZr4DLYjqF_TL Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > On Aug 12, 9:39Êpm, username localhost > > > > > > > > > But can it play music videos?http://www.amazon.com/dp/B00004TVDN > > > > > The user reviews for the product above are interesting. > > > > > > Ê Hands down, the Casio wins, and it is cheaper as well. > > > > Ê The calculator is more user friendly. > > > > Ê The options are menu driven in a more intuitive way. > > > > Ê What took me a minute or two to locate and figure out out the TI, > > > > Ê took less than half the time on the Casio... > > > > Ê The color thing I suppose is nice, > > > > Ê but I use the CFX-9750, which is black and white and cheaper. > > > > TI has the USA school system eating out of its hands. Their marketing > > > division deserves some credit though with the TI-83/84 series hype. > > > The original vanilla TI-83 was introduced 12 years ago in 1996. Now, > > > it is still being sold, though re-named the TI-84+/silver. The TI-84's > > > promise keystroke-for-keystroke compatibility with the TI-83, which is > > > a fancy way of saying We didn't bother to put any new features into > > > this 12-year-old calculator. > > > > I prefer my $9 Casio fx-260 solar pocket scientific to the brick-sized > > > TI-84's. I can do calculations faster on the Casio than the TI because > > > it uses a mixed ALG/RPN entry (though I prefer pure RPN :) > > > > Another interesting fact is that currently on Amazon, the TI-84 silver > > > sells for $135 while the 50g sells for only $118. A no-brainer if > > > there ever was one. [Even if you refuse to go HP, the TI-89 Titanium > > > costs only $140, making me strongly question why anyone would buy the > > > TI-84 silver] > > > The issue here is the arguably unlawful mandating of a specific > > calculator by teachers in public schools who have books with Ti-83 > > instructions, and no other. Consider that many average idiots could > > not do anything complicated with a graphing calculator without step by > > step instructions. (These are the people who have trouble getting into > > a community college). If those idiots had an HP50g, there is almost no > > way the teacher would be able to provide the needed step by step > > instructions unless they were very familiar with the calculator. > > > This even hurts the sales of the TI-89. Well, that and the fact that > > some tests ban the TI-89 due to the CAS.- Hide quoted text - > > > - Show quoted text - > > We really have a great discussion going on here! When will HP > call its graphing calculators by what they really are-computers > or would that be a marketing blunder? I think the graphing > computer would tantalize the imagination of the high school > or college student shopping for a calculator. Better yet, a > hand-held graphing computer, because that would remove any > ambiguity that it might be a notebook computer. I think the > greatest strength of any calculator is the ability to customize > it to work the way I work. > The USER mode allows me to assign > keys but I have to memorize their assignments unless I can > put an overlay over the keyboard like the 48 series allowed you > to do. Many people assign to user keys based on the existing functions of the keys, making allowing one to avoid the need of completely memorizing the functions The newer Calcs do not have special support for overlays, but that does not mean overlays are not possible. See http://pssllc.com/index.php?main page=product info&cPath=2&products id=7 for an example of an overlay for the 50G+ despite the lack of hardware support. >The quality of the hardware is also important to me. The > black plastic bezel on my 49 G+ cracked after minimal use. > I don't expect my calculator to endure the rigors of outdoor or > industrial use but I do expect to get some use out of it before > it degrades. Finally, I would like to see an HP-supported SDK > that includes really good documentation for those of us who > are not professional programmers, computer scientists, or > electrical engineers. > I see a lot of people on this Usenet > group who are interested in going beyond the User Manual > and I think HP should support them because happy users > promote sales! The simple fact is that Corporate is apparently really not that interested in the Calculator division. They would rather focus their time on the other divisions. That is quite likely why the marketing and software support (manuals, sdks, etc) of HP Calculators has been lass than stellar. As long as the calculator division remains profitable and has reasonable small expenditure and does not pester corporate more than necessary, corporate is happy to leave it alone. If the calculator division is seen as requiring too much corporate attention it is more likely to be axed. Cyrille, does that sound about right? The one thing that would be really nice is if the calculator division were spun off as a seperate company, or perhaps transferred over to Agilent Technologies (The spin off company that had most of HP's oldest divisions). I would tend to guess that Agilent would have kept the calculator product line more healthy. I will say that these days the need for powerful pocket calculators in engineering is dying, mostly due to excellent computer software, and extremely portable PCs, but I doubt the market is completly gone. After all, calculator keyboards are often more convient for entering mathematical expressions than most computer keyboards. === Subject: Re: How to suggest features to the hp calculator team? While not HP-supported we have hpgcc 2.0 and soon 3.0 which needs AFAIK a patched ROM (may it be official, please) AND Debug4x + emulators for sysRPL work plus MASD that works on the calc X Finally, I would like to see an HP-supported SDK that includes really good documentation for those of us who are not professional programmers, computer scientists, or electrical engineers. I see a lot of people on this Usenet group who are interested in going beyond the User Manual and I think HP should support them because happy users promote sales! === Subject: Re: How to suggest features to the hp calculator team? <7IGdne2aa5wnxDzVnZ2dnUVZ_sDinZ2d@speakeasy.net> posting-account=sOAX1QkAAAC-FcySTSbz29Uk8huUtFRz CLR 1.1.4322; .NET CLR 2.0.50727),gzip(gfe),gzip(gfe) > other question: Êwhy does the top of the line 50g doesn't have a color > display? Color displays use more power. The 50g's battery life is already dreadful as is. Plus, color screens (like the one on the Casio PowerGraphic) are not as crisp as monochrome ones. After using the Casio color screen calculator, I still prefer grayscale displays. S.C. === Subject: Re: How to suggest features to the hp calculator team? > Color displays use more power. The 50g's battery life is already > dreadful as is. Plus, color screens (like the one on the Casio > PowerGraphic) are not as crisp as monochrome ones. After using the > Casio color screen calculator, I still prefer grayscale displays. The color display of the iPod nano for instance is quite sharp yet the battery life is quite phenomenal (when you realize what the thing does); hence my question. --Sylvain === Subject: Re: How to suggest features to the hp calculator team? posting-account=sOAX1QkAAAC-FcySTSbz29Uk8huUtFRz CLR 1.1.4322; .NET CLR 2.0.50727),gzip(gfe),gzip(gfe) > The color display of the iPod nano for instance is quite sharp yet the > battery life is quite phenomenal (when you realize what the thing does); > hence my question. > > --Sylvain The iPod nano has a Li-ion rechargable battery with higher capacity than AAA batteries. It claims 24 hours of battery life when playing music, but you have to realize that the display backlight is not always on. When playing video, the backlight is always on and battery life is reduced to a claimed 5 hours. Five hour battery life on a calculator would not be acceptable... S.C. === Subject: Re: How to suggest features to the hp calculator team? > The 50g's battery life is already dreadful as is. That's only because the voltage regulation circuitry on the 50g is so poorly designed. I suspect that with a better design, using modern voltage regulation technology, battery life could be increased by at least 50%, and possibly much more. HP just has to show some interest in making the changes and doing another rev of the board. There might be a potential cost increase, too, but not by more than the cost of a set of AAA batteries. :) Eric Rechlin === Subject: Re: How to suggest features to the hp calculator team? <6gehl4FfenqaU1@mid.individual.net> posting-account=sOAX1QkAAAC-FcySTSbz29Uk8huUtFRz CLR 1.1.4322; .NET CLR 2.0.50727),gzip(gfe),gzip(gfe) > That's only because the voltage regulation circuitry on the 50g is so poorly > designed. ÊI suspect that with a better design, using modern voltage > regulation technology, battery life could be increased by at least 50%, and > possibly much more. ÊHP just has to show some interest in making the changes > and doing another rev of the board. > > There might be a potential cost increase, too, but not by more than the cost > of a set of AAA batteries. Ê:) Luckily, I use rechargable Ni-MH batteries :) I would still appreciate not having to charge them as frequently though. (HP, are you listening?) S.C. === Subject: Re: How to suggest features to the hp calculator team? I would love to C a PDA with Lithium battery charged via USB with a slide out calculator keyboard use the slimmest cheap model with 3G phone and PDA software forget about Saturn compatibility and step into the future!! VPN > other question: why does the top of the line 50g doesn't have a color > display? Color displays use more power. The 50g's battery life is already dreadful as is. Plus, color screens (like the one on the Casio PowerGraphic) are not as crisp as monochrome ones. After using the Casio color screen calculator, I still prefer grayscale displays. S.C. === Subject: Re: How to suggest features to the hp calculator team? using an educated guess: for better web support using java applets to simulate something like calculus training sessions hp 35S with big ENTER etc,, tells what CB says It's a miracle that hp still produces calcs I hope they will take schools back totally non-symbolic basic graphing calcs are needed cheap & easy: let JYA strip off 38g+ to hp 37G with USB VPN > hello, > > not true. > Is is really not true? If HP cared about feature requests, they would have release ROM 2.10-C already. The fact that they have not, is not a good sign. Perhaps I am wrong. I would presume you would know better about the workings of the HP calculator division than most of the rest of us. Unfortunately you are also probably limited in exactly what you can say. I don't suppose you can just announce any future plans for the 48/49 series, right? If you can just announce the plans, please enlighten us. I presume you can't just come right out and tell us what project the recent job request is for either, could you? === Subject: Re: HP 42s posting-account=sOAX1QkAAAC-FcySTSbz29Uk8huUtFRz CLR 1.1.4322; .NET CLR 2.0.50727),gzip(gfe),gzip(gfe) > I would not care for a reincarnation > of the 42 primarily because I like a larger display. > I will always like my 48 the best because it was > durable, the keys were indestructible, and the > big ENTER key was right where I liked it! > > I think a good pocket scientific with a 2-line display is needed. The current 35s has terrible complex number support that is hindered by bugs such as SQRT working only for -1+0i and not -1, for example. Complex inverse trig like on the 48 series does not work on the 35s. These features were all supported on the 42s. A reincarnation of the 42s is not needed if HP would just update the ROM of the 35s and include better complex number support. Complicated graphing calculators are not as necessary anymore due to the ubiquity of laptop computers, but a good handheld shirt pocket- sized calculator can still be very useful. Another thing HP needs to keep in mind is that there are competitor pocket calculators that sell for about $20, making the $60 HP 35s hard to justify. The only reason why I would take the 35s over say a $20 Casio is that the 35s uses RPN. If another brand started producing RPN calculators (like Casio, for example - they manage to make $20 calculators with good build quality) then there would be no reason to buy an HP. S.C. === Subject: Re: HP 42s > [HP35S] bugs such as SQRT working only for -1+0i and not -1 Is the same bug found in the HP15C? (I'm too lazy to try to find and unpack my 15C, so who else would kindly check up on this?) I remember seriously objecting, in high school, to the whole notion of pretending that negative real numbers have square roots, and I regarded the terminology imaginary as being the only true thing about it, much like asking me to believe again in the existence of Santa Claus, even though real presents were made to appear after his imaginary coming :) Only after I had Tom M Apostol's textbook in hand Mathematical Analysis: A modern approach to advanced calculus http://www.amazon.com/dp/B0007FDEJW with its chapter on considering all numbers as 2-dimensional did I finally calm down and decide that things were okay :) Has anyone found out whether Santa actually lives only at the North pole (of the vertical axis of the complex plane), or is there a Doppelg.8anger at the other end, too, for the kids who live in the southern hemisphere? http://en.wikipedia.org/wiki/Tom_M._Apostol -[ ]- === Subject: Re: HP 42s InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 1.1.4322; .NET CLR 3.0.04506.648),gzip(gfe),gzip(gfe) > > Only after I had Tom M Apostol's textbook in hand > Mathematical Analysis: A modern approach to advanced calculushttp://www.amazon.com/dp/B0007FDEJW > with its chapter on considering all numbers as 2-dimensional > did I finally calm down and decide that things were okay :) I had a look in the Toronto Reference Library for that. They didn't have that exact version, but they had plain old Mathematical Analysis, 1974, so I guess it was a follow-on ten years later. It's nicely written with great clarity, so I've become yet another > Has anyone found out whether Santa actually lives only > at the North pole (of the vertical axis of the complex plane), > or is there a Doppelg.8anger at the other end, too, > for the kids who live in the southern hemisphere? Since the Coriolis forces below the equator make things swirl the other way, the North Pole Santa has had too much trouble controlling the sleigh and has been using FedEx. He's been talking to Boeing, and this year he hopes to make it in a complex plane. Bill === Subject: Re: HP 42s But what if the South Pole Santa is left-handed? . === Subject: Re: 50G, Plot-Table-Printing to 82240 IR printer Just to add some bonus: besides writing a program, the 50G-build-in functions SEQ and MAP serve the purpose pretty well, too. === Subject: Re: USAG v1.4 for 49 series Gaak kirjutas: >> Gaak kirjutas: >> >>> Version 1.4 [28.07.2008] >>> ------------------------ >>> * improved: PICT for common commands (GOR, REPL, STO, SIZE,...). >>> * improved: extended for commands like FOR, THEN, WHILE,... >>> * added: input supports command, {command}, command, {command}. >>> * added: support to ALG mode. >>> * added: key [+/-] and menu [LANG+]. >>> * added: support to 48gII. >>> * removed: support to current font. >>> * removed: freeze for some commands. >>> http://www.gaak.org/hp/usag/ >>> - Gaak - >> >> This last one (1.4) has on my v.2.10-7 HP50G an unfortunate side effect >> :( When using it on single type argument command (like CLKADJ or >> ->KEYTIME), and pressing afterwards any key, the calculator >> warmstarts... I downloaded the 1.3 from hpcalc.org for checking. 1.3 >> runs flawlessly. >> >> Robert Tiismus >> ZZ > > Uhm?, not for me. :-( > Testing on ROM 2.09 (50g) and ROM 2.10-7 (Emu-49G) runs flawlessly. > Commands like CLKADJ and ->KEYTIME are commands with common > structure... > > More details?: > - Input mode (remember that ALG and RPN are supported now). > - Command mode (lists, strings, command). > > > - Gaak - the RPN mode, downloaded the program and tried again: 1: { CLKADJ } usag.hp It displayed the correct information, but when I pressed ANY KEY, I saw very spectacular random pattern on the screen and Try To Recover Memory? afterwards. No was unresponsible but Yes functioned. Is it possible that my unit is faulty? I got it only half a year ago and have not had much time to use it. Robert Tiismus === Subject: Re: USAG v1.4 for 49 series posting-account=HQcyKwkAAAAfyVM-3k2cuaNBENqZAwPy Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > the RPN mode, downloaded the program and tried again: > 1: { CLKADJ } > usag.hp > > It displayed the correct information, but when I pressed ANY KEY, I saw > very spectacular random pattern on the screen and Try To Recover > Memory? afterwards. No was unresponsible but Yes functioned. > > Is it possible that my unit is faulty? I got it only half a year ago and > have not had much time to use it. > > Robert Tiismus Maybe another buggy object?... libraries with bad $CONFIG?... Please, delete your 'STARTUP' variable from HOME and after Warmstart press and hold [BS]... and retry again USAG. Sorry for the inconvenience :-( - Gaak - === Subject: Re: USAG v1.4 for 49 series Gaak kirjutas: >> the RPN mode, downloaded the program and tried again: >> 1: { CLKADJ } >> usag.hp >> >> It displayed the correct information, but when I pressed ANY KEY, I saw >> very spectacular random pattern on the screen and Try To Recover >> Memory? afterwards. No was unresponsible but Yes functioned. >> >> Is it possible that my unit is faulty? I got it only half a year ago and >> have not had much time to use it. >> >> Robert Tiismus > > Maybe another buggy object?... libraries with bad $CONFIG?... > Please, delete your 'STARTUP' variable from HOME and after Warmstart > press and hold [BS]... and retry again USAG. > > Sorry for the inconvenience :-( > > - Gaak - I erased all libraries, did again ON-A-F NO. Bu still the same behavior... Then I downgraded ROM to version 2.09 (from HP site), and it behaved! The bug was back after upgrading to 2.10-7. I think it is somehow related to LANGUAGE selection, because after every crash, the LANGUAGE-> command returns 5.. I tried to look into program, to try to debug it, but it was inside CODE object. Is it this way for aesthetical reasons? That this way the stack is not cluttered with EXTERNAL's. Anyhow, I got it disassembled by this: << ->H DUP SIZE 33 SWAP SUB D9D20D9D20 SWAP + H-> ->s2 >> But could not find debugger like Jazz library had for HP48 series. So again no avail :( Robert Tiismus === Subject: Re: USAG v1.4 for 49 series posting-account=HQcyKwkAAAAfyVM-3k2cuaNBENqZAwPy Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > Gaak kirjutas: > > > > >> the RPN mode, downloaded the program and tried again: > >> 1: { CLKADJ } > >> usag.hp > > >> It displayed the correct information, but when I pressed ANY KEY, I saw > >> very spectacular random pattern on the screen and Try To Recover > >> Memory? afterwards. No was unresponsible but Yes functioned. > > >> Is it possible that my unit is faulty? I got it only half a year ago and > >> have not had much time to use it. > > >> Robert Tiismus > > > Maybe another buggy object?... libraries with bad $CONFIG?... > > Please, delete your 'STARTUP' variable from HOME and after Warmstart > > press and hold [BS]... and retry again USAG. > > > Sorry for the inconvenience :-( > > > - Gaak - > > I erased all libraries, did again ON-A-F NO. Bu still the same > behavior... Then I downgraded ROM to version 2.09 (from HP site), and it > behaved! The bug was back after upgrading to 2.10-7. I think it is > somehow related to LANGUAGE selection, because after every crash, the > LANGUAGE-> command returns 5.. I tried to look into program, to try > to debug it, but it was inside CODE object. Is it this way for > aesthetical reasons? That this way the stack is not cluttered with > EXTERNAL's. Anyhow, I got it disassembled by this: > << ->H DUP SIZE 33 SWAP SUB D9D20D9D20 SWAP + H-> ->s2 >> > But could not find debugger like Jazz library had for HP48 series. So > again no avail :( > > Robert Tiismus Good news for you... your calculator is ok, don't worry ;-) Upgrading my 50g to 2.10-7 and debugging (for you), I found the bug, The Flash Pointer 7 8E (aka ^WRITEMENU) available on all ROM versions, is wrong on 2.10-7. ^WRITEMENU (2.10-7) :: DUPTYPEREAL? case ( ... ) ; ^WRITEMENU (another version like 1.18, 1.19-6, .. 2.09) :: ZERO SIX ZERO_DO ( ... ) ; ^WRITEMENU is called for commands that requires One Argument (- >KEYTIME), No Arguments (MEM), and metas (->LIST). Obviously, ROM 2.10-7 is beta :-S Sorry for the inconvenience, again... :-( - Gaak - === Subject: comp.os.os2.networking.misc salvation --------------------------------------------------------------------- --------------------------------------------------------------------- Ophelia Marlatt GoogleBong === Subject: Re: Drawing Arcs posting-account=eF2f0AoAAAB2spBRiZOs91ItDKLGDCIk Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) At last, here is a (long awaited) usable version for Fast Arc, which seems reasonably accurate to be of any use. The binaries for HP48, 49 and 50 can be downloaded at this website : http://fastarc.webhop.org/ Input : 6 : Grob (<-- Optional, if none provided, will draw into Graphic Area) 5 : X0 4 : Y0 3 : Radius 2 : Start Bearing (¡) 1 : End Bearing (¡) Being based on the code sample by Cyrille de Brebisson, it is quite fast, although after completing the fullcircle code, the focus was no longer speed, but rather arc accuracy, and getting something out of the door before any real life issues prevent me from working on it. Version 1 seems now completed. This version have the following change compared to previous releases : 1) Accurary : Granted, the algorithm is still at its core based on an approximation, but this time, approximation should be less than one pixel, meaning in fact full accuracy as far as display is concerned. I've tried to trick the program in a number of way, and could no longer find any blatant loophole with this version. Some samples screenshots are provided in the link for illustration 2) Breisenham's cache Well, i wanted to bring something new, so here it is. I added a simple but effective cache algorithm, which allows to run breisenham only once, reusing output for all octants. It significantly improves performances and makes the code shorter (a simple read-cache replace the optimized breisenham algo within each octant). 3) Expanded Boundaries Due to improvements in register allocation, the input limits are now fairly large, up to 250 000. It is also possible to define X0 and Y0 (the center of the circle) as negative values. calculating memory pixel location, performance are good. As a funny side effect, now the program spends more time in the header than drawing the arc. This was tested with the PureCode version, which removes the header, and it resulted in 31ms being spent on header alone (on GX), which means twice more time than is necessary to draw a 30pixels half-circle on the same platform. Of course, performances on newer platform should be even better. There are still some room for improvement though, especially as i really did not optimized the arc specific part of the code. This is partly because my focus was much more on getting something accurate and fastly available. Some ideas which could make it in a future release if need be : - Sector discarding : this avoids to loop for each not-drawed pixel, improving performances for circles with parts out of screen. Of course, this cost some bytes to program. - Dynamic compilation : the program would create the code which draws Arc, using inputs to optimized tests and loops. This will improve performance by a good margin, and potentially reduce code size too. It is complex though, and make maintenance more difficult. So this is rather a last move to do, when everything else is stable. Well, i guess the next move could be on functionality, instead of ever more performances. For example, how to allow a user to replace the embedded Arc function with this one ? Would a forced save with ARC global name in the HOME directory be enough for this ? Eventually, i can also add some more features to the header to make it compatible to HP syntax on top of the one already documented in this thread. Well, if that is usefull... === Subject: Re: Drawing Arcs posting-account=82unwgoAAABKn0foN-teZr4DLYjqF_TL Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > calculating memory pixel location, performance are good. > As a funny side effect, now the program spends more time in the header > than drawing the arc. This was tested with the PureCode version, > which removes the header, and it resulted in 31ms being spent on > header alone (on GX), which means twice more time than is necessary to > draw a 30pixels half-circle on the same platform. > Of course, performances on newer platform should be even better. > TEVAL gives timings of 32-48 ms for me for your test cases on the 50g. (These were full version tests, not PureCode tests) A few larger scale testcases: <<50000 50000 20000 0 180 fastarc>> 3.16 seconds <<50000 50000 20000 0 360 fastarc>> 4.34 seconds <<50000 50000 20000 180 360 fastarc>> 2.04 seconds (the timing discrepancy between the first and last of those is surprisingly large, considering both are half arcs of the same radius and center point) For all reasonable sized circles the results seem instant. === Subject: Re: Drawing Arcs posting-account=ky6NnQoAAAAl8HjjF10EUMKbzXiIKhTR Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > At last, > here is a (long awaited) usable version for Fast Arc, which seems > reasonably accurate to be of any use. > > The binaries for HP48, 49 and 50 can be downloaded at this website :http://fastarc.webhop.org/ > > Input : > 6 : Grob (<-- Optional, if none provided, will draw into Graphic Area) > 5 : X0 > 4 : Y0 > 3 : Radius > 2 : Start Bearing (¡) > 1 : End Bearing (¡) > > Being based on the code sample by Cyrille de Brebisson, it is quite > fast, although after completing the fullcircle code, the focus was no > longer speed, but rather arc accuracy, and getting something out of > the door before any real life issues prevent me from working on it. > Version 1 seems now completed. This version have the following change > compared to previous releases : > > 1) Accurary : > Granted, the algorithm is still at its core based on an approximation, > but this time, approximation should be less than one pixel, meaning in > fact full accuracy as far as display is concerned. > I've tried to trick the program in a number of way, and could no > longer find any blatant loophole with this version. > Some samples screenshots are provided in the link for illustration > > 2) Breisenham's cache > Well, i wanted to bring something new, so here it is. > I added a simple but effective cache algorithm, which allows to run > breisenham only once, reusing output for all octants. It significantly > improves performances and makes the code shorter (a simple read-cache > replace the optimized breisenham algo within each octant). > > 3) Expanded Boundaries > Due to improvements in register allocation, the input limits are now > fairly large, up to 250 000. > It is also possible to define X0 and Y0 (the center of the circle) as > negative values. > > calculating memory pixel location, performance are good. > As a funny side effect, now the program spends more time in the header > than drawing the arc. This was tested with the PureCode version, > which removes the header, and it resulted in 31ms being spent on > header alone (on GX), which means twice more time than is necessary to > draw a 30pixels half-circle on the same platform. > Of course, performances on newer platform should be even better. > > There are still some room for improvement though, especially as i > really did not optimized the arc specific part of the code. This is > partly because my focus was much more on getting something accurate > and fastly available. > > Some ideas which could make it in a future release if need be : > - Sector discarding : this avoids to loop for each not-drawed pixel, > improving performances for circles with parts out of screen. Of > course, this cost some bytes to program. > - Dynamic compilation : the program would create the code which draws > Arc, using inputs to optimized tests and loops. This will improve > performance by a good margin, and potentially reduce code size too. It > is complex though, and make maintenance more difficult. So this is > rather a last move to do, when everything else is stable. > > Well, i guess the next move could be on functionality, instead of ever > more performances. > For example, how to allow a user to replace the embedded Arc > function with this one ? > Would a forced save with ARC global name in the HOME directory be > enough for this ? > Eventually, i can also add some more features to the header to make it > compatible to HP syntax on top of the one already documented in this > thread. Well, if that is usefull... Hello Yann, This is terrific!!! I've done some tests and everything looks great. Here are my results using a 50g with the same input values you were using for your 48 tests (Fastarc v1.hp49&50.hp): 30px, Quarter Circle: 25ms 30px, Half Circle: 26ms 30px, Full Circle: 30ms 60px, Full Circle: 33ms 150px, 3/4 Circle: 41ms Much faster than my SysRPL program :-), congratulations on your incredible success. Jacob === Subject: Re: Drawing Arcs posting-account=Q2CEjQoAAACue5ZDDhUeRzv1w0u8hxZE rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1,gzip(gfe),gzip(gfe) > 30px, Quarter Circle: 25ms > 30px, Half Circle: 26ms > 30px, Full Circle: 30ms > 60px, Full Circle: 33ms > 150px, 3/4 Circle: 41ms > > Much faster than my SysRPL program :-), congratulations on your > incredible success. Indeed that it is very good. Now the next step is to do it in ARM ASM or in HPGCC. I have an HPGCC routine around here somewhere that does something like 500-1K arcs a second and it was not very good code. TW === === Subject: Re: USAG v1.4 for 49 series > The Flash Pointer 7 8E (aka ^WRITEMENU) > available on all ROM versions, > is wrong on 2.10-7 There's more to it, because there was not just one 2.10; there must have been a regular ROM (never released by HP), and there was an experimental Geometry/Spreadsheet ROM (made for math teachers in France?) which was apparently derived from that, and you are probably using the latter. The problem appears to be that some of the FPTR slots in bank 7 seem to have been borrowed (or re-arranged) in the Geometry ROM, no longer matching their original functions (or at least not matching what extable says), while the regular orignal 2.10 ROM was no doubt actually fine. I think you would have to ask BP about how that ROM was created, to find out how these substitutions occurred, and what else might be affected by them; for example, was there not enough room to add Geometry+Spreadsheet, and were other original functions (or just their bank table pointers) replaced or re-arranged instead? > NOT_WRITEMENU (2.10-7G? wrong function in bank table?) (at 7:42797 ? in Geometry ROM) > :: > DUPTYPEREAL? > case > (...) ( clearly CAS symbolic code here, called from symbolic functions ) > ^WRITEMENU (another version like 1.18, 1.19-6, .. 2.09) (at 7:461C0 ? in regular 2.10, called from ^MENUext and other sensible places) > :: > ZERO SIX > ZERO_DO ( this is correct code ) > ; > ^WRITEMENU is called for commands that requires One Argument > (->KEYTIME), No Arguments (MEM), and metas (->LIST). > Obviously, ROM 2.10-7 is beta :-S It would seem that only the altered Geometry version has been rearranged, evidently so obscurely that it doesn't seem to have been noticed before. Evidently _you_ call ^WRITEMENU (using its original FPTR 7 8E) from USAG, although the commands themselves (in ROM) do not; perhaps you could choose another function (or copy the original code) to become free of this dependence, and thus to be compatible even with the Geometry ROM? It would be nice if the very caring HP (new?) management would care to either post the improved regular 2.10 ROM themselves, or let someone else post it unofficially, like 1.19-6 for old 49G, which was never acknowledged by HP, but which was clearly improved over HP's official 1.18 Otherwise the altered Geometry version of 2.10 might remain the only one found, and might prove incompatible with some bank 7 dependent SysRPL/ML, just as apparently in this case. [r->] [OFF] === Subject: BP, major bug in geometry rom (WAS: Re: USAG v1.4 for 49 series) Cc: parisse@fourier.ujf-grenoble.fr posting-account=82unwgoAAABKn0foN-teZr4DLYjqF_TL Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > > The Flash Pointer 7 8E (aka ^WRITEMENU) > > available on all ROM versions, > > is wrong on 2.10-7 > > There's more to it, because there was not just one 2.10; > there must have been a regular ROM (never released by HP), > and there was an experimental Geometry/Spreadsheet ROM > (made for math teachers in France?) > which was apparently derived from that, > and you are probably using the latter. > > The problem appears to be that some of the FPTR slots > in bank 7 seem to have been borrowed (or re-arranged) > in the Geometry ROM, no longer matching their original functions > (or at least not matching what extable says), > while the regular orignal 2.10 ROM was no doubt actually fine. > > I think you would have to ask BP about how that ROM was created, > to find out how these substitutions occurred, > and what else might be affected by them; > for example, was there not enough room to add Geometry+Spreadsheet, > and were other original functions (or just their bank table pointers) > replaced or re-arranged instead? I just checked. Bank 7 contains 13 commands, and then the contents of library 222. In the geometry rom, somehow after the FTR 7 C (the 13th command) apparently 22 garbage entries got inserted into the the bank table. This messed up all later bank 7 flash pointers (so FPTR 7 8E became FPTR 7 A4, etc) BP should probably be able to fix this. The issue did not impact any code compiled into bank 7 because the compiler/linker replaced the symbols with the flashpointers that had a slot incremented by 22 compared to the normal location. Unfortunately, the extable/extable2 use the original flashpointers, as do any existing programs that used those flashpointers. BP, could you please generate a new rom that does not have those bogus entries (or if they are not completely bogus that have those entries Oh, BP, I also have a few unrelated things to ask. I presume you must have had access to what would be the official 2.10 if HP had released it (if you did not have access to it, that would make basing your geometry rom on it a bit difficult i would imagine) . Any chance you you leak it? No? Ok. Just wanted to ask. :-D (BTW, the posted cas2user.s file for the geometry app was clearly not used to compile the posted rom, as CASRESERVED62 and CASRESERVED63 in the posted rom are RCLVX and STOVX. That means that two of those pseudo-userrpl commands found in CASRESERVED64-99 must have been removed. Which two where they? (Just curious).) === Subject: Re: USAG v1.4 for 49 series to my unhumble opinion: HP (Cyrille) just steel one more bank to the system and/or even another one for the extable 2 50g+ could have twice the flash and 90 MHz speed and -5V/+5V real RS-232C plus full HPGCC compatibility we can patch it up, baby VPN > >> The Flash Pointer 7 8E (aka ^WRITEMENU) >> available on all ROM versions, >> is wrong on 2.10-7 > > There's more to it, because there was not just one 2.10; > there must have been a regular ROM (never released by HP), > and there was an experimental Geometry/Spreadsheet ROM > (made for math teachers in France?) > which was apparently derived from that, > and you are probably using the latter. > > The problem appears to be that some of the FPTR slots > in bank 7 seem to have been borrowed (or re-arranged) > in the Geometry ROM, no longer matching their original functions > (or at least not matching what extable says), > while the regular orignal 2.10 ROM was no doubt actually fine. > > I think you would have to ask BP about how that ROM was created, > to find out how these substitutions occurred, > and what else might be affected by them; > for example, was there not enough room to add Geometry+Spreadsheet, > and were other original functions (or just their bank table pointers) > replaced or re-arranged instead? > > >> NOT_WRITEMENU (2.10-7G? wrong function in bank table?) > (at 7:42797 ? in Geometry ROM) > >> :: >> DUPTYPEREAL? >> case >> (...) > ( clearly CAS symbolic code here, called from symbolic functions ) > > >> ^WRITEMENU (another version like 1.18, 1.19-6, .. 2.09) > (at 7:461C0 ? in regular 2.10, called from ^MENUext and other sensible > places) > >> :: >> ZERO SIX >> ZERO_DO > ( this is correct code ) >> ; > > >> ^WRITEMENU is called for commands that requires One Argument >> (->KEYTIME), No Arguments (MEM), and metas (->LIST). >> Obviously, ROM 2.10-7 is beta :-S > > It would seem that only the altered Geometry version has been > rearranged, > evidently so obscurely that it doesn't seem to have been noticed before. > > Evidently _you_ call ^WRITEMENU (using its original FPTR 7 8E) > from USAG, although the commands themselves (in ROM) do not; > perhaps you could choose another function > (or copy the original code) to become free of this dependence, > and thus to be compatible even with the Geometry ROM? > > It would be nice if the very caring HP (new?) management > would care to either post the improved regular 2.10 ROM themselves, > or let someone else post it unofficially, > like 1.19-6 for old 49G, which was never acknowledged by HP, > but which was clearly improved over HP's official 1.18 > > Otherwise the altered Geometry version of 2.10 > might remain the only one found, > and might prove incompatible with some bank 7 dependent SysRPL/ML, > just as apparently in this case. > > [r->] [OFF] === Subject: Re: USAG v1.4 for 49 series Gaak kirjutas: > > Good news for you... your calculator is ok, don't worry ;-) > > Upgrading my 50g to 2.10-7 and debugging (for you), I found the bug, > The Flash Pointer 7 8E (aka ^WRITEMENU) available on all ROM > versions, is wrong on 2.10-7. > > ^WRITEMENU (2.10-7) > :: > DUPTYPEREAL? > case > ( ... ) > ; > > ^WRITEMENU (another version like 1.18, 1.19-6, .. 2.09) > :: > ZERO SIX > ZERO_DO > ( ... ) > ; > > ^WRITEMENU is called for commands that requires One Argument (- >> KEYTIME), No Arguments (MEM), and metas (->LIST). > Obviously, ROM 2.10-7 is beta :-S > > Sorry for the inconvenience, again... :-( > > - Gaak - I already realized that 2.09 is the way to go and downgraded the ROM uncertified ROM version! Robert Tiismus === Subject: Re: USAG v1.4 for 49 series but now that the problems is found is there a real+beta ROM version compatible 1,4,1 USAG available somewhere? > Gaak kirjutas: >> >> Good news for you... your calculator is ok, don't worry ;-) >> >> Upgrading my 50g to 2.10-7 and debugging (for you), I found the bug, >> The Flash Pointer 7 8E (aka ^WRITEMENU) available on all ROM >> versions, is wrong on 2.10-7. >> >> ^WRITEMENU (2.10-7) >> :: >> DUPTYPEREAL? >> case >> ( ... ) >> ; >> >> ^WRITEMENU (another version like 1.18, 1.19-6, .. 2.09) >> :: >> ZERO SIX >> ZERO_DO >> ( ... ) >> ; >> >> ^WRITEMENU is called for commands that requires One Argument (- >>> KEYTIME), No Arguments (MEM), and metas (->LIST). >> Obviously, ROM 2.10-7 is beta :-S >> >> Sorry for the inconvenience, again... :-( >> >> - Gaak - > > I already realized that 2.09 is the way to go and downgraded the ROM > uncertified ROM version! > > Robert Tiismus === Subject: Turn Your Laptop into a GPS System posting-account=EUzlXwoAAABj62mQOvWYG9KkVzX_y6iM Gecko/20080702 Firefox/2.0.0.16,gzip(gfe),gzip(gfe) Although it would probably amaze many people, it is possible to turn your laptop into a GPS system. === Subject: Re: Turn Your Laptop into a GPS System posting-account=VfVNIQoAAACMnyQaqeAxaRuNmCJ2YShj 1.0.3705; Media Center PC 4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022),gzip(gfe),gzip(gfe) > Although it would probably amaze many people, it is possible to turn old news...deluo has been around since 2001 === Subject: menu in picture mode posting-account=z2OflgoAAACByEbTN6tIB9mDhhglP6mP Gecko/20070508 Firefox/1.5.0.12,gzip(gfe),gzip(gfe) Is there a way in HP 50g to display grpahic screen together with user menu? I mean like the PICTURE environment, but with the custom menu? It seems like PVIEW followed by a MENU does not do any good, as well as PICTURE followed by a MENU === Subject: Re: USAG v1.4 for 49 series posting-account=HQcyKwkAAAAfyVM-3k2cuaNBENqZAwPy Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > This last one (1.4) has on my v.2.10-7 HP50G an unfortunate side effect Version 1.5 [18.08.2008] ------------------------ * improved: language correction and optimization. * improved: À ? -> Undefined Name (with language support). * fixed: bug ROM beta 2.10-7 with ^WRITEMENU. http://www.gaak.org/hp/usag/ - Gaak - === Subject: Re: HP35s - solving functions in user programs > Completely confused - The 35s has known bugs that are similar to this -- expressions that reference memory variables instead get values coming from the stack, for instance. (This is bug #15 at there was a forum discussion where some guy figured out exactly what gets substituted where during evaluation.) HP has been informed of these problems and had shown zero public interest in fixing any of them. :-( ---Joel === Subject: Re: How to suggest features to the hp calculator team? > In this newsgroup, we are likely to find requests from die-hard users, > extremely technicals, with very deep requests, which are bound to be > uninteresting to most casual users. This is the reason that, historically, HP had lots of different machines to choose from: Cheaper, less-powerful ones for casual users, and of course the HP-41 series, then -28 and -48 and -49 and -50 for die-hard users. In general the die-hard users are absolutely willing to pay more than the casual user for the extra features they desire, too. Even for such commodity products as wireless routers, some companies have figured this out: Asus sells their Premium line of routers (e.g., WL-500gP) To the casual user, this is of no benefit whatsoever, but for the power user people go and start running, e.g., BitTorrent clients or web cams or Python scripts or whatever and fully benefit from the extra memory. > nowadays, technical teams have little cloud & power to steer company > decisions. In big companies, yes. But the calculator division of HP isn't more than something like a dozen? people anyway (hard to say since, as I recall, the calculator division only has a few full-time employees but uses lots of other in-house engineers part-time), so there's no reason it has to be run from a big company vantage point. It's really a shame that Hydrix wasn't able to obtain enough funding to get Qonos into production. ---Joel === Subject: Re: How to suggest features to the hp calculator team? > other question: why does the top of the line 50g doesn't have a color > display? I'd rather have higher resolution that color, personally. Color (or at least greyscale) is handy for differentiating multiple plots on a graph though, certainly. === Subject: Re: Turn Your Laptop into a GPS System posting-account=ujnlqwkAAADa5-KcfiulE2o9CRcf_ASq Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > Although it would probably amaze many people, it is possible to turn Many Airport Shuttle drivers (etc..) have been using this before real GPS systems became affordable === Subject: Re: How to suggest features to the hp calculator team? >> In my days in a USA elementary school, >> all calculations were performed >> by first writing down the numbers, >> then commencing to perform the arithmetic upon them. >> >> That's exactly what RPN is, so back in those days, >> everyone who graduated my USA elementary school >> (and necessarily even those who taught them) >> were already masters of RPN. >> > >How do you multiply two 3-digit integers by hand? You write one down, >then write down the second, then write down the operation to be >performed (the x for multiplication). The RPN calculator is an >extension to the brain -- you enter in the two numbers and then press >[x] to multiply them. > >I can hardly imagine anyone who can just look at something like >246x894=? and multiply those two numbers on the spot just like that >(That's the TI way). > >RPN just seems more natural, unless you never knew how to do the math >by hand in the first place. > >S. Oh, yes, yes... And all there parenteses and such are SOOOOO... confusing... A.L. === Subject: Re: How to suggest features to the hp calculator team? > Oh, yes, yes... > And all there parentheses and such are SOOOOO... confusing... In case any have forgotten, the entire 49/50 series also has the TI-like Algebraic mode (which is the default, out of the box), if one wants to restrict oneself exclusively to it, while RPN mode meanwhile fully accommodates algebraic expressions at any time, thus being more general and ultimately more powerful in scope. But of course, trolls will be trolls... -[ ]- === Subject: Re: How to suggest features to the hp calculator team? >> >> >Another interesting fact is that currently on Amazon, the TI-84 silver >> >sells for $135 while the 50g sells for only $118. A no-brainer if >> >there ever was one. [Even if you refuse to go HP, the TI-89 Titanium >> >costs only $140, making me strongly question why anyone would buy the >> >TI-84 silver] >> >> Because it is better than HP50. For high Êschool student >> >> A.L. > >For the average USA high school student (who struggles with math), the >TI-84 is better than the HP 50g because teachers are more familiar >with the TI and can show their students exactly what to do. Not sure I >agree with the teaching method (do the kids learn math or just how to >push buttons?) but it's the truth. > >The same high school student can save himself over $100 by using a >simple scientific calculator (the TI-84's don't do anything that the >scientifics can't do, besides graph) and actually learning enough >mathematics to visualize the simple graphs encountered during class. > >HP 50g is better than the TI for non-students. > Excellent explanation. But I am not student, and I prefer TI or Casio. I don't like HP50. This is the must un-ergonomic piece of electronic crap. A.L. === Subject: Re: How to suggest features to the hp calculator team? <7IGdne2aa5wnxDzVnZ2dnUVZ_sDinZ2d@speakeasy.net> posting-account=sOAX1QkAAAC-FcySTSbz29Uk8huUtFRz CLR 1.1.4322; .NET CLR 2.0.50727),gzip(gfe),gzip(gfe) > >HP 50g is better than the TI for non-students. > > Excellent explanation. But I am not student, and I prefer TI or Casio. > I don't like HP50. This is the must un-ergonomic piece of electronic > crap. > > A.L. That was my opinion/generalization. You are entitled to yours, and if you like TI and Casio, then that's nobody else's business. Go on and use whatever you like. S.C. === Subject: Re: How to suggest features to the hp calculator team? posting-account=aJhvMAoAAABqICGF80eSUn6d3D9SANQE Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > Has the 48gII inherited the 3rd generation keyboard? Anyway, I still > think the 48gII is crippled by its 81K free memory and no > expandability. It is also impossible to upgrade the ROM -- a true > Read Only Memory. 128K more free memory?), USB, and upgradable ROM. (Who improves a product and doesn't advertise it? Why not call it the 48gIII or 48gIIb?) It sells for about the same as the TI-83+. > The 50g is a much better value for its modest > price increase over the 48gII. I completely agree. However, many parents don't look at best value/ price, they look at just price. -wes === Subject: Re: How to suggest features to the hp calculator team? posting-account=sOAX1QkAAAC-FcySTSbz29Uk8huUtFRz CLR 1.1.4322; .NET CLR 2.0.50727),gzip(gfe),gzip(gfe) > > Has the 48gII inherited the 3rd generation keyboard? Anyway, I still > > think the 48gII is crippled by its 81K free memory and no > > expandability. It is also impossible to upgrade the ROM -- a true > > Read Only Memory. > > 128K more free memory?), USB, and upgradable ROM. Ê(Who improves a > product and doesn't advertise it? Why not call it the 48gIII or > 48gIIb?) ÊIt sells for about the same as the TI-83+. Really? I checked HP's official website at http://h20426.www2.hp.com/product/calculators/th/en/graphing/48gII/ and at http://www.shopping.hp.com/product/calculator/Scientific/1/storefronts/F2226 A%2523ABA user. It doesn't even advertise the USB port. The 48gII software page does not include the ROM like the 50g page, suggesting that the 48gII ROM still cannot be upgraded. Also, where is this year-old 2.10-C? Either really poor marketing skills on HP's part or they just don't care. I don't know which is worse. S.C. === Subject: Re: How to suggest features to the hp calculator team? > with 80.7K free for the user. It doesn't even advertise the USB > port. The 48gII software page does not include the ROM like > the 50g page, suggesting that the 48gII ROM still cannot be > upgraded. Even funnier is when you look at the packaging. The front of the 48gII http://commerce.hpcalc.org/images/48gii-boxfront-medium.jpg serial cable: http://commerce.hpcalc.org/images/48gii-boxback-medium.jpg > Either really poor marketing skills on HP's part or they just > don't care. I don't know which is worse. Probably a little of both. It's so sad that HP has some nice products, yet they appear to show no interest in wanting to sell any of them. After all, their web site says the 48gII and 39gs are each less than 1/10 thick while at the same time saying the 40gs is 157 cm tall. Clearly they have little interest in making sure the information on their web site is accurate, as some of these mistakes have been there for years, despite my having pointed them out to them. Eric Rechlin === Subject: Re: How to suggest features to the hp calculator team? <6h3jkjFht1m9U1@mid.individual.net> posting-account=82unwgoAAABKn0foN-teZr4DLYjqF_TL Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > > with 80.7K free for the user. It doesn't even advertise the USB > > port. The 48gII software page does not include the ROM like > > the 50g page, suggesting that the 48gII ROM still cannot be > > upgraded. > > Even funnier is when you look at the packaging. The front of the 48gII > > serial cable:http://commerce.hpcalc.org/images/48gii-boxback-medium.jpg The back is incorrect because that is also the back cover of the highly abridged user's guide included. The costs of changing the back cover of a book are significantly more than the costs of updating the front of the box. On the other hand, I fail to see why HP could not put a simple sheet of paper at the back of the case before the manual that looks the same except is updated for hardware revision 2. === Subject: Re: How to suggest features to the hp calculator team? > The back is incorrect because that is also the back cover of the > highly abridged user's guide included. The costs of changing the back > cover of a book are significantly more than the costs of updating the > front of the box. I wish I could say you were right, but HP actually *did* change the back cover of the book when they re-released the 48gII. They updated the copyright date at the bottom to add 2006 and changed the number/code in the lower-right corner. At the same time, they introduced the error claiming it is 1/10 thick (yes, it says it on the back of the packaging!) when it had that totally escapes me. Compare: http://commerce.hpcalc.org/images/48gii-boxback-medium.jpg http://commerce.hpcalc.org/images/48gii-boxbackold-medium.jpg Eric Rechlin === Subject: Re: How to suggest features to the hp calculator team? <6h48afFiti90U1@mid.individual.net> posting-account=82unwgoAAABKn0foN-teZr4DLYjqF_TL Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > > The back is incorrect because that is also the back cover of the > > highly abridged user's guide included. The costs of changing the back > > cover of a book are significantly more than the costs of updating the > > front of the box. > > I wish I could say you were right, but HP actually *did* change the back > cover of the book when they re-released the 48gII. ÊThey updated the > copyright date at the bottom to add 2006 and changed the number/code in the > lower-right corner. ÊAt the same time, they introduced the error claiming it > is 1/10 thick (yes, it says it on the back of the packaging!) when it had > that totally escapes me. > > Compare:http://commerce.hpcalc.org/images/48gii-boxback-medium.jpghttp://comm erce.hpcalc.org/images/48gii-boxbackold-medium.jpg > > > Eric Rechlin Look again. They were correcting the error in the 2006 version, not adding it. However, I am quite surprised they updated the book, and even more surprised that while doing so they did not update the specs. BTW, I'm quite impressed by the selection of images on the commerce site. It is quite rare to see any commerce site with decent photos of the products these days. === Subject: Re: How to suggest features to the hp calculator team? >> with 80.7K free for the user. It doesn't even advertise the USB >> port. The 48gII software page does not include the ROM like >> the 50g page, suggesting that the 48gII ROM still cannot be >> upgraded. > > Even funnier is when you look at the packaging. The front of the 48gII > http://commerce.hpcalc.org/images/48gii-boxfront-medium.jpg > > with a serial cable: > http://commerce.hpcalc.org/images/48gii-boxback-medium.jpg > > After all, their web site says the 48gII and 39gs are each less than > 1/10 thick while at the same time saying the 40gs is 157 cm tall. > Clearly they have little interest in making sure the information on > their web site is accurate, as some of these mistakes have been there > for years, despite my having pointed them out to them. > > > Eric Rechlin > > I think you got their attention eventually, the dimensions look reasonable now. Unless I was looking in the wrong place. -- Noxonomus === Subject: Re: How to suggest features to the hp calculator team? > I think you got their attention eventually, the dimensions look > reasonable now. Unless I was looking in the wrong place. Maybe it's right somewhere, but it's wrong if you go to http://www.hp.com/calculators/ and click the Graphing link on the left. It (presently) takes you to this page, which is full of errors: By the way, it looks like they have updated the 48gII data sheet to the correct 256 KB figure, even though the web page that links to it is still wrong. Eric Rechlin === Subject: Re: How to suggest features to the hp calculator team? Data sheet has still some errors... >> I think you got their attention eventually, the dimensions look >> reasonable now. Unless I was looking in the wrong place. > > Maybe it's right somewhere, but it's wrong if you go to > http://www.hp.com/calculators/ and click the Graphing link on the left. > It (presently) takes you to this page, which is full of errors: > > > By the way, it looks like they have updated the 48gII data sheet to the > correct 256 KB figure, even though the web page that links to it is still > wrong. > > > Eric Rechlin > === Subject: Re: How to suggest features to the hp calculator team? <6h3jkjFht1m9U1@mid.individual.net> posting-account=sOAX1QkAAAC-FcySTSbz29Uk8huUtFRz CLR 1.1.4322; .NET CLR 2.0.50727),gzip(gfe),gzip(gfe) > After all, their web site says the 48gII and 39gs are each less than 1/10 > thick while at the same time saying the 40gs is 157 cm tall. ÊClearly they > have little interest in making sure the information on their web site is > accurate, as some of these mistakes have been there for years, despite my > having pointed them out to them. > I guess the 48gII is the new Apple slide rule that compliments the iPod Nano. The 40gs can be your 5'2 buddy that happens to be good at mental math. At least the back of the 48gII box (that claims only 128K memory) correctly reflects that the calculator is not a 1/10th inch thick razor. S.C. === Subject: Re: How to suggest features to the hp calculator team? <6h3jkjFht1m9U1@mid.individual.net> posting-account=zYTuBQoAAAC_bXzGjGVT5rxv8bOnpefP Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) ... > After all, their web site says the 48gII and 39gs are each less than 1/10 > thick while at the same time saying the 40gs is 157 cm tall. ... LOL, Skis perhaps? === Subject: Re: menu in picture mode posting-account=z2OflgoAAACByEbTN6tIB9mDhhglP6mP Gecko/20070508 Firefox/1.5.0.12,gzip(gfe),gzip(gfe) > Is this what you mean: > > { A B C D E F } TMENU { #0 #0 } PVIEW 3 FREEZE > > [r->] [OFF] It kind of does what I want, except that I noticed that when I have more than 6 elements and hit NEXT, it leave graphic mode and moves back to stack display. Is there a way to make it stay in graphic mode after next button? === Subject: Re: menu in picture mode Re: >> { A B C D E F } TMENU { #0 #0 } PVIEW 3 FREEZE > It kind of does what I want, except that I noticed > that when I have more than 6 elements and hit NEXT, > it leave graphic mode and moves back to stack display. > Is there a way to make it stay in graphic mode after next button? I have the dim impression that some of the SysRPL entry points whose names may begin with SetDA might have exactly that effect (to convince the SysDisplay part of the System outer loop not to redraw DA1 or DA2, which are the status and stack areas); I hope that someone who isn't so rusty on that subject (I last tried this for a triangle solver of years ago) might be able to answer more definitely (and save me the trouble of trying to figure it out again :) [r->] [OFF] === Subject: Re: menu in picture mode posting-account=82unwgoAAABKn0foN-teZr4DLYjqF_TL Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > > > Is this what you mean: > > > { A B C D E F } TMENU { #0 #0 } PVIEW 3 FREEZE > > > [r->] [OFF] > > It kind of does what I want, except that I noticed that when I have > more than 6 elements and hit NEXT, it leave graphic mode and moves > back to stack display. Is there a way to make it stay in graphic mode > after next button? The following sort of approximates what you want. It is admittedly more complicated than the original. What is really happening is that the the PICTURE display is being shown, but the regular stack is running in the background. Thus if after running the code I've attached you type 1 ENTER ENTER + F2 you will see 2 and 'B' on the stack. The screen remains showing the PICT environment until CANCEL is pressed, user flag 7 is cleared in some fashion (Hopefully by choosing an item from your menu. It is possible to open a different menu instead of your current menu. This may leave the user stuck, forcing them to press CANCEL. Pressing CANCEL may (high probability) leave cruft on the stack. But it does work. It is also possible to do extra processing on the value returned by WAIT, to prevent keys other than the Function keys and NXT (and PREV (LS+NXT)) from being KEYEVAL'ed that should prevent the opening a different menu issue. There might be a cleaner way to do this than my way, but I'm not aware of it. User Flag 7 was chosen arbitrarily. Any User flag could have been chosen. And now the code: << { { A << A 7 CF >> } { B << B 7 CF >> } { C << C 7 CF >> } { D << D 7 CF >> } { E << E 7 CF >> } { F << F 7 CF >> } { G << G 7 CF >> } } TMENU {#0 #0} PVIEW 7 SF WHILE 7 FS? REPEAT 3 FREEZE -1 WAIT KEYEVAL END >> This has been tested under emulation of the HP49+. === Subject: My wish list for an improved 50g Hardware -------- 1. Large ENTER key, just like in the older models (and the HP-35s). 2. Tactile keys like those on the HP-35s with the same key shape. Software -------- 1. Digit separators in Standard display mode (like the HP-35s). 2. A B->I function (yes, I can use B->R and then R->I, but why not just combine them). The software should be relatively easy to implement. I won't hold my breath for the hardware changes, but it would be nice. On another note, what is the deal with the mushy HP-20b keys? Why did HP take a step backward when they are capable of producing a decent keypad like the one on the HP-35s? Why is HP having so much issues with fundamentals like keys on a calculator? John === Subject: Re: My wish list for an improved 50g > Hardware > -------- > 1. Large ENTER key, just like in the older models (and the HP-35s). > 2. Tactile keys like those on the HP-35s with the same key shape. > > Software > -------- > 1. Digit separators in Standard display mode (like the HP-35s). > 2. A B->I function (yes, I can use B->R and then R->I, but why not > just combine them). Actually there are binaries that would have to convert to integers of more than 12 significant decimal digits, so they get rounded off to 12 significant digits by the B->R command. Like the binary for 2^64 -1. To get the full 64 bit binary numbers converted exactly to integer format is possible on an hp49/hp50, but not by the sequence B->R R->I. E.g., when compiled in in exact mode, this user program seems to work: << 0 1 -> x y << WHILE DUP # 0h > REPEAT IF DUP # 1H AND # OH > THEN 'X' Y STO+ END 'Y' 2 STO* SR END DROP X >> >> > > The software should be relatively easy to implement. I won't hold > my breath for the hardware changes, but it would be nice. > > On another note, what is the deal with the mushy HP-20b keys? Why > did HP take a step backward when they are capable of producing a > decent keypad like the one on the HP-35s? Why is HP having so much > issues with fundamentals like keys on a calculator? > > > John === Subject: Re: My wish list for an improved 50g > > > Hardware > > -------- > > 1. Large ENTER key, just like in the older models (and the HP-35s). > > 2. Tactile keys like those on the HP-35s with the same key shape. > > > > Software > > -------- > > 1. Digit separators in Standard display mode (like the HP-35s). > > 2. A B->I function (yes, I can use B->R and then R->I, but why not > > just combine them). > > Actually there are binaries that would have to convert to integers of > more than 12 significant decimal digits, so they get rounded off to 12 > significant digits by the B->R command. Like the binary for 2^64 -1. > > To get the full 64 bit binary numbers converted exactly to integer > format is possible on an hp49/hp50, but not by the sequence B->R R->I. > > E.g., when compiled in in exact mode, this user program seems to work: > > << 0 1 -> x y > << WHILE DUP # 0h > > REPEAT > IF DUP # 1H AND # OH > > THEN 'X' Y STO+ > END > 'Y' 2 STO* SR > END > DROP X A much better program is (again compiled in exact mode) << 4294967296 @ equals 2^32 DUP2 / B->I OVER * UNROT 1 - R->B AND B->R R->I + >> Note that 4294967296 can actually be any integer between 2^32 and 10^12 inclusive. === Subject: Re: My wish list for an improved 50g X > Actually there are binaries that would have to convert to integers of > more than 12 significant decimal digits, so they get rounded off to 12 > significant digits by the B->R command. Like the binary for 2^64 -1. > > To get the full 64 bit binary numbers converted exactly to integer > format is possible on an hp49/hp50, but not by the sequence B->R R->I. > > E.g., when compiled in in exact mode, this user program seems to work: > > << 0 1 -> x y > << WHILE DUP # 0h > > REPEAT > IF DUP # 1H AND # OH > > THEN 'X' Y STO+ > END > 'Y' 2 STO* SR > END > DROP X > >> > >> X slight modifications: << -> b @ use as a function << b 0 1 -> x y << WHILE DUP # 999999999999d > REPEAT @ no need to loop smaller IF DUP # 1h AND # 0h > @ corrected OH THEN 'x' y STO+ END 'y' y STO+ SR @ + faster than * END B->R R->I y * x + >> b DROP @ save LASTARG >> @ >> @ note small letters usage === Subject: Re: My wish list for an improved 50g Veli-Pekka Nousiainen kirjutas: > X >> Actually there are binaries that would have to convert to integers of >> more than 12 significant decimal digits, so they get rounded off to 12 >> significant digits by the B->R command. Like the binary for 2^64 -1. >> >> To get the full 64 bit binary numbers converted exactly to integer >> format is possible on an hp49/hp50, but not by the sequence B->R R->I. >> >> E.g., when compiled in in exact mode, this user program seems to work: >> >> << 0 1 -> x y >> << WHILE DUP # 0h > >> REPEAT >> IF DUP # 1H AND # OH > >> THEN 'X' Y STO+ >> END >> 'Y' 2 STO* SR >> END >> DROP X >> >> >> >> > X > slight modifications: > << -> b @ use as a function > << b 0 1 -> x y > << WHILE DUP # 999999999999d > > REPEAT @ no need to loop smaller > IF DUP # 1h AND # 0h > @ corrected OH > THEN 'x' y STO+ > END > 'y' y STO+ SR @ + faster than * > END > B->R R->I y * x + > >> b DROP @ save LASTARG > >> @ > >> @ note small letters usage > > The first one is 148.5 bytes and over 1s with #FFFFFFFFFFFFFFFh, the other one 191 bytes and 400ms with the same input. What about: << -> n << RCLF DEC -105 CF n ->STR DUP SIZE 1 - 3 SWAP SUB STR-> SWAP STOF >> >> 68.5 bytes and 60ms with the same input as above. Results are different, because first two programs assume user binary integers to be signed I assume :) Best wishes, Robert Tiismus === Subject: Re: My wish list for an improved 50g posting-account=aJhvMAoAAABqICGF80eSUn6d3D9SANQE Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) On Aug 21, 1:00Êpm, Veli-Pekka Nousiainen > > > X > > Actually there are binaries that would have to convert to integers of > > more than 12 significant decimal digits, so they get rounded off to 12 > > significant digits by the B->R command. Like the binary for 2^64 -1. > > > To get the full 64 bit binary numbers converted exactly to integer > > format is possible on an hp49/hp50, but not by the sequence B->R R->I. How about string processing? B->I << PUSH DEC ->STR 3. OVER SIZE 1. - SUB OBJ-> POP >> I->B << # SWAP + d + OBJ-> >> -wes === Subject: Re: Drawing Arcs posting-account=eF2f0AoAAAB2spBRiZOs91ItDKLGDCIk Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) use. Just some answers to latest comments : - Discrepancy : there is a side-effect to the nibble traveller methodology : it avoids calculating the memory position for each pixel, but it needs a start point. This start point has been hardcoded at position 90¡. Therefore, if you start from position 0¡, you have a worse performance penalty than starting from 180¡. This could be improved, with a bit of logic, to start immediately to the right octant, something i did for the older code. But then, this would result in quite a bit more logic, creating havoc in the carefully designed register allocation, increasing complexity & code size, therefore i started to wonder if it was really necessary to be even more faster at such a cost. In the end, i decided to keep code length & complexity as low as possible. But this, of course, can be changed if someone find it necessary. Note that, in your example, an even better solution would be to discard undrawn quarters (or octants). Because these huge arcs are out of screen, not even drawn, this would result in an almost immediate discarding. Here also, adding this bit of logic is not hugely complex, but is bound to increase code size and create complexity. Well, anyway, if there is a need for this, then why not, this can be done. - HPGCC (TW) : it is my long-term intention to move to ARM ASM some day; For the time being, i'm merely learning ASM as an entertaining exercise, and i find it more attractive to develop for my old hardware student's calc, an HP48SX. The reasoning is : if it is fast and usable enough for 48SX, then newer model will only find it even better. For sure, there is a limit, but i'm not yet good enough to cross through it. As a sidenote, note that Circle code is quite simpler to do than Arc. As an example, i've got a quick version of Fastcircle, derived from Cyrille de Brebisson example with a Breisenham cache, which only needs 30ms to draw a full circle on HP48SX, including header. This is nearly three times faster than Arc, because it is so much simpler to process. Well, I guess the next step is to submit the FastArc program software to HPCalc.org, so that anyone interested can get it in the future. === Subject: Re: menu in picture mode > Is there a way in HP 50g to display graphic screen > together with user menu? > I mean like the PICTURE environment, but with the custom menu? > It seems like PVIEW followed by a MENU does not do any good, > as well as PICTURE followed by a MENU Is this what you mean: { A B C D E F } TMENU { #0 #0 } PVIEW 3 FREEZE [r->] [OFF] === Subject: Re: menu in picture mode posting-account=z2OflgoAAACByEbTN6tIB9mDhhglP6mP Gecko/20070508 Firefox/1.5.0.12,gzip(gfe),gzip(gfe) > Is this what you mean: > > { A B C D E F } TMENU { #0 #0 } PVIEW 3 FREEZE Yes, this works, thank you. === Subject: Printed User's Guide for 50g? I was wondering if it is possible to buy a printed copy of the 50g's user guide (the ~900 page one, not the skimpy one that comes with it), outside of having it printed somewhere? === Subject: Re: Printed User's Guide for 50g? >I was wondering if it is possible to buy a printed copy of the 50g's user >guide (the ~900 page one, not the skimpy one that comes with it), outside >of having it printed somewhere? No, you can't - a printed copy *must* have been printed somewhere.... ;-) -- ---------------------------------------------------------------- Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN e-mail: pausch at stjarnhimlen dot se WWW: http://stjarnhimlen.se/ === Subject: Re: Printed User's Guide for 50g? posting-account=JjQcFAoAAADcz2TIXskmfCCFHa9-zK_4 Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > > >I was wondering if it is possible to buy a printed copy of the 50g's user > >guide (the ~900 page one, not the skimpy one that comes with it), outside > >of having it printed somewhere? > > No, you can't - a printed copy *must* have been printed somewhere.... Ê;-) > > -- > ---------------------------------------------------------------- > Paul Schlyter, ÊGrev Turegatan 40, ÊSE-114 38 Stockholm, ÊSWEDEN > e-mail: Êpausch at stjarnhimlen dot se > WWW: Ê Êhttp://stjarnhimlen.se/ Given the cost of printed books a copy from Staples or Kinko's is quite reasonable. You can give them a 'thumb drive' with the pdf files on it and have it printed and bound for a reasonable cost. I did the 900 page manual as two double sided volumes with a plastic ring binding and clear front and back covers. Good luck. Scott === Subject: Re: How to suggest features to the hp calculator team? > >Another interesting fact is that currently on Amazon, the TI-84 silver >sells for $135 while the 50g sells for only $118. A no-brainer if >there ever was one. [Even if you refuse to go HP, the TI-89 Titanium >costs only $140, making me strongly question why anyone would buy the >TI-84 silver] > Because it is better than HP50. For high school student A.L. === Subject: Re: How to suggest features to the hp calculator team? <7IGdne2aa5wnxDzVnZ2dnUVZ_sDinZ2d@speakeasy.net> posting-account=sOAX1QkAAAC-FcySTSbz29Uk8huUtFRz CLR 1.1.4322; .NET CLR 2.0.50727),gzip(gfe),gzip(gfe) > > >Another interesting fact is that currently on Amazon, the TI-84 silver > >sells for $135 while the 50g sells for only $118. A no-brainer if > >there ever was one. [Even if you refuse to go HP, the TI-89 Titanium > >costs only $140, making me strongly question why anyone would buy the > >TI-84 silver] > > Because it is better than HP50. For high Êschool student > > A.L. For the average USA high school student (who struggles with math), the TI-84 is better than the HP 50g because teachers are more familiar with the TI and can show their students exactly what to do. Not sure I agree with the teaching method (do the kids learn math or just how to push buttons?) but it's the truth. The same high school student can save himself over $100 by using a simple scientific calculator (the TI-84's don't do anything that the scientifics can't do, besides graph) and actually learning enough mathematics to visualize the simple graphs encountered during class. HP 50g is better than the TI for non-students. S.C. === Subject: Re: How to suggest features to the hp calculator team? <8Shqk.29320$C65.2802@en-nntp-01.dc1.easynews.com> posting-account=sOAX1QkAAAC-FcySTSbz29Uk8huUtFRz CLR 1.1.4322; .NET CLR 2.0.50727),gzip(gfe),gzip(gfe) On Aug 18, 12:57Êpm, Joel Koltner > This is the reason that, historically, HP had lots of different machines to > choose from: Cheaper, less-powerful ones for casual users, and of course the > HP-41 series, then -28 and -48 and -49 and -50 for die-hard users. ÊIn > general the die-hard users are absolutely willing to pay more than the > casual user for the extra features they desire, too. HP hardly as a cheaper scientific calculator these days. The 35s in the $50-60 range can hardly be called affordable in the age of sub-$10 pocket scientifics from other manufacturers such as Casio and TI. The problem is that casual users no longer go HP simply because HP's cost too much. In contrast, the 50g makes the HP48 series no longer only for die- hard users. At about $120, it is both cheaper and more capable than its competition (TI, for example). Whereas the 35s is several times more expensive than its competition, the 50g can compete favorably. HP needs to release a capable RPN pocket scientific in the sub-$20 range to compete successfully in that market. S.C. === Subject: Re: How to suggest features to the hp calculator team? > Whereas the 35s is several times more expensive > than its competition, the 50g can compete favorably. The 35s has no competition, at least not in the US. I believe it (along with its $20-cheaper sibling 33s) is the only programmable scientific calculator on the market. > HP needs to release a capable RPN pocket scientific in the > sub-$20 range to compete successfully in that market. I agree they should release a non-programmable RPN scientific to be competitive. The $40 HP 20b is price-competitive with the $33 TI BA II PLUS. TI has several scientific calculators with quality comparable to that of the TI BA II PLUS, such as the $15 TI-30X IIB and IIS. Can HP produce a $20 RPN scientific version of the 20b? That's what it would take to be competitive -- not another RPN-lacking 10s. Though maybe it would do little good. As has been pointed out already, the 50g is price-competitive with the vastly inferior TI-84 (or the powerful but little-known, compared to the 83/84, TI-89), but the teachers have been bribed to only recommend the 83/84, so that's what the students buy. Eric Rechlin === Subject: Re: How to suggest features to the hp calculator team? <6guifuFhk3o9U1@mid.individual.net> posting-account=aJhvMAoAAABqICGF80eSUn6d3D9SANQE Gecko/2008070208 Firefox/3.0.1,gzip(gfe),gzip(gfe) > Though maybe it would do little good. As has been pointed out already, the > 50g is price-competitive with the vastly inferior TI-84 (or the powerful but > little-known, compared to the 83/84, TI-89), but the teachers have been > bribed to only recommend the 83/84, so that's what the students buy. I must have missed that memo. Where do I sign up to receive my bribe? :-) I'm a long-time RPN user and would love for some of my high school students to have RPN calculators. However, the inertia of the market place is difficult to overcome. While I am primarily interested in a tool to teach math/physics concepts, students' priorities are often What do my friends have? and What color is it? (Pink, orange, blue and baby blue seem to be popular this year.) As much as I dislike the TI-83/84, I have to give a nod to their marketing. They know their target market and have covered all the bases: training for teachers, integration with textbooks, cool-factor for students. They've created a need for their product (textbooks), developed a group of people who promote their product (teachers), and have convinced a group of fickle consumers that they need their inferior product. There was a time in the early 90's when HP-28's and 48's were the cool calculators among my top students. I'm convinced that the 48gII is an ideal high school calculator, but you can't expect students to buy them them when the vast majority of teachers have never even heard of them. -wes === Subject: Re: How to suggest features to the hp calculator team? I'm convinced that the 48gII is an ideal high school calculator, but you can't expect students to buy them them when the vast majority of teachers have never even heard of them. For all the lip service that society pays to making students critical, independent thinkers, if anything it seems as if actually doing a little thinking for yourself and choosing what's best for you rather than what everyone else has is less common today than it was decades back. And look at how popular convenant restrictions are in new housing developments -- you can be as creative as you want in the design of your home, so long as you first get all the plantings, colors, vehicle storage locations, and floorplan are first all approved by others. God help us all if a neighbor wanted to paint his house purple with pink polka dots! Or buy his kid an HP 48gII. === Subject: Re: How to suggest features to the hp calculator team? > The 35s has no competition, at least not in the US. I believe it (along > with its $20-cheaper sibling 33s) is the only programmable scientific > calculator on the market. You need to throw non-graphing in there, but otherwise, yes, this is essentially true... and unfortunate. === Subject: Re: How to suggest features to the hp calculator team? >> Whereas the 35s is several times more expensive >> than its competition, the 50g can compete favorably. > >The 35s has no competition, at least not in the US. I believe it (along >with its $20-cheaper sibling 33s) is the only programmable scientific >calculator on the market. > >> HP needs to release a capable RPN pocket scientific in the >> sub-$20 range to compete successfully in that market. > >I agree they should release a non-programmable RPN scientific to be >competitive. The $40 HP 20b is price-competitive with the $33 TI BA II >PLUS. TI has several scientific calculators with quality comparable to that >of the TI BA II PLUS, such as the $15 TI-30X IIB and IIS. Can HP produce a >$20 RPN scientific version of the 20b? That's what it would take to be >competitive -- not another RPN-lacking 10s. What country are you from? Maybe in Europe high school students are smart enough to master RPN. Maybe teachers in Europe are smart enough to master RPN. But Europe is not the Whole World. A.L. === Subject: Re: How to suggest features to the hp calculator team? > Maybe in Europe high school students are > smart enough to master RPN. Maybe teachers in Europe are smart enough > to master RPN. But Europe is not the Whole World. I graduated from high school in 1989, and I can tell you that a small handful of kids (perhaps 1 in 5 in math classes) had HP calculators, and they were *not* all members of, e.g., the computer club -- just regular kids. I bought my first HP calculator that same year, an HP-28S, as I headed off to college. Formerly I'd been the proud owner of a programmable Casio calculator and then a couple of Casio handheld computers... I would have loved to have owned, e.g., an HP-71b, but I sure didn't have the money for it at the time! === Subject: Re: How to suggest features to the hp calculator team? <7IGdne2aa5wnxDzVnZ2dnUVZ_sDinZ2d@speakeasy.net> <0Dhqk.32483$4p1.27822@en-nntp-09.dc1.easynews.com> posting-account=sOAX1QkAAAC-FcySTSbz29Uk8huUtFRz CLR 1.1.4322; .NET CLR 2.0.50727),gzip(gfe),gzip(gfe) On Aug 18, 12:41Êpm, Joel Koltner > > other question: Êwhy does the top of the line 50g doesn't have a color > > display? > > I'd rather have higher resolution that color, personally. ÊColor (or at least > greyscale) is handy for differentiating multiple plots on a graph though, > certainly. I agree that resolution is more important than color. A low-resolution color display would not help differentiate between different plots - the graphs would all coincide (or at least be close to each other) on a low resolution display. S.C. === posting-account=TyjFDQoAAADVwm433wakGogpjlyvOYJI .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; SAPO 1024b02; SAPO 1024b02),gzip(gfe),gzip(gfe) Hi! http://cgi.ebay.de/Taschenrechner-HP-48-G-HP48-G-HP48G-mit-1-2-MB_W0QQitemZ1 30247656902QQcmdZViewItem?hash=item130247656902&_trkparms=72%3A823%7C39%3A1%7 C66%3A2%7C65%3A12%7C240%3A1318&_trksid=p3286.c0.m14 Ernesto. === companies made them for the 48G -- the interface wasn't something common like CompactFlash or SD cards are today, and the circuitry was simple. Cynox is still around, but doesn't appear to be selling hardware anymore: http://www.cynox.de/eng/index.html Picture: http://www.hpcalc.org/details.php?id=3747 ---Joel === Subject: trial I think the perpetrators of the disappearance of Cynthia Jane Anderson need to be brought to trial, and if found guilty, pay retribution and do prison time. About Carolyn, I don't care if I'm in love with the cunt. I think she should pay, too, money and prison time. This all goes to show that high society isn't above the law. It's a free country, but nobody is entitled to stalk the populations and kill people with that freedom. I say BUST THEM. Carolyn and everyone else involved. If you need my testimony, subpoena me. Otherwise I'll be dredging up more details for the trial. Far from it. Her father and husband will risk all to protect her, at any cost. She's just a joy-riding free spirit, isn't she? She owes all her warts to her father and husband... and all her beauties to me. Now isn't that fair? === Subject: Re: Is a^-2 in simplest form? (Hoist on my own petard!) === Subject: population +walking cycling +growth energy +water green, Cc: MCDONewt@yahoo.co.nz posting-account=TV2szgkAAACrA1vyuh8IN_0zzgzcwogw .NET CLR 2.0.50727; .NET CLR 3.0.04506),gzip(gfe),gzip(gfe) don mcd, bcc; it is about.. population +walking cycling +growth energy +water green, reduce 'thinning stream of water' from kitchen tap, you get a curve flow like fountain , ')('. ...slow down bathroom tap,you notice an hyperbolic population explosion reverse time, gravity or vortex. (rising or falling, drops.) the graph may be like rectangular hyperbola- a conic section, )(. vertical and horizontal asymptotes, equation y = c/ x. more severe than exponential population explosion .. J. newsss, should every woman have average of twins, not before age 70 years, c-section. 4 x conic sections. O circle, ellipse, parabola U, hyperbola )(. archimedes 'on sphere and cylinder, book 11.' euclid, vertex, asymptote branch. bbc tv new years day..'the power of 1.' us tv gameshow 'the power of 10. percents.' starting august 2oo8. tv3. family court, nice name 'spiral cicada koru @'.. search world year of mathematics 2000, ideas_poster_13 ff,.. square the circle, straighten the curves Luke 3.5. work it out. cyclist missed out on gold medal NZ by 1-7th second = .14 28 57.. 142,400 visitors lonely planet guide. picture usain bolt jamaica, world record 100m track 9.69s. = 3*17*19 competitor 3025 = 55^2 squared. compet 2163 = 3*7*103 3025 2163 = 17*613*2903 = 17*1779539, # 133*1338 = 1.333.9936 ^2 sqr. # 17*798*223 = 3025218 =777*229*17 = 3024861. dark energy, bubble wave. in the scheme outlined by dr cleaver, dark energy would be used to create the bubble. think of it like a surfer riding a wave... telegraph group bubble vortex vertex, warp speed. journal of british interplanetary society dominionpost 18/8/08 pg B2 Monday. >bcc robinson, very slightly expanded x 70 per cent. 12/8/08 >bcc don a bday . > >slow down bathroom tap,... you notice an hyperbolic population >explosion stream graph. Don S. McDonald ... === Subject: Re: population +walking cycling +growth energy +water green, > > ... Am I the only one who never understands any of Don S. McDonald's posts? -- He is not here; but far away The noise of life begins again And ghastly thro' the drizzling rain On the bald street breaks the blank day. === Subject: Re: population +walking cycling +growth energy +water green, <48AAA85A.D73F3970@tesco.net> posting-account=OKTeIQkAAAAZk6JK1hK7-grwpoUDNy98 CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1),gzip(gfe),gzip(gfe) On Aug 19, 6:02Êam, Frederick Williams > > > ... > > Am I the only one who never understands any of Don S. McDonald's posts? You're not alone. Sometimes you just have to let art flow over you. > > -- > He is not here; but far away > Ê The noise of life begins again > Ê And ghastly thro' the drizzling rain > On the bald street breaks the blank day. === Subject: Re: Printed User's Guide for 50g? posting-account=itRlSAoAAADIJvOzSGM8mjsK7gvlk1wg Gecko/20071127 Firefox/2.0.0.11,gzip(gfe),gzip(gfe) Some years ago I bought a very heavy printed manual for the 49g+, which should have nearly the same contents as the 50g's manual. Perhaps you can find one of these. === Subject: Re: How to suggest features to the hp calculator team? posting-account=sOAX1QkAAAC-FcySTSbz29Uk8huUtFRz CLR 1.1.4322; .NET CLR 2.0.50727),gzip(gfe),gzip(gfe) > There was a time in the early 90's when HP-28's and 48's were the cool > calculators among my top students. ÊI'm convinced that the 48gII is an > ideal high school calculator, but you can't expect students to buy > them them when the vast majority of teachers have never even heard of > them. > Has the 48gII inherited the 3rd generation keyboard? Anyway, I still think the 48gII is crippled by its 81K free memory and no expandability. It is also impossible to upgrade the ROM -- a true Read Only Memory. The 50g is a much better value for its modest price increase over the 48gII. S.C. === Subject: Re: How to suggest features to the hp calculator team? > What country are you from? > Maybe in Europe high school students > are smart enough to master RPN. > Maybe teachers in Europe are smart enough to master RPN. In my days in a USA elementary school, all calculations were performed by first writing down the numbers, then commencing to perform the arithmetic upon them. That's exactly what RPN is, so back in those days, everyone who graduated my USA elementary school (and necessarily even those who taught them) were already masters of RPN. What do they do now in school -- start performing the arithmetic before they write down the numbers upon which it is to be performed? Now _that_ must really take more smarts than we ever had :) -[ ]- === Subject: Re: How to suggest features to the hp calculator team? <6guifuFhk3o9U1@mid.individual.net> posting-account=sOAX1QkAAAC-FcySTSbz29Uk8huUtFRz CLR 1.1.4322; .NET CLR 2.0.50727),gzip(gfe),gzip(gfe) > In my days in a USA elementary school, > all calculations were performed > by first writing down the numbers, > then commencing to perform the arithmetic upon them. > > That's exactly what RPN is, so back in those days, > everyone who graduated my USA elementary school > (and necessarily even those who taught them) > were already masters of RPN. > How do you multiply two 3-digit integers by hand? You write one down, then write down the second, then write down the operation to be performed (the x for multiplication). The RPN calculator is an extension to the brain -- you enter in the two numbers and then press [x] to multiply them. I can hardly imagine anyone who can just look at something like 246x894=? and multiply those two numbers on the spot just like that (That's the TI way). RPN just seems more natural, unless you never knew how to do the math by hand in the first place. S.C. === Subject: Re: How to suggest features to the hp calculator team? > As much as I dislike the TI-83/84, I have to give a nod to their > marketing. They know their target market and have covered all the > bases: training for teachers, integration with textbooks, cool-factor > for students. They've created a need for their product (textbooks), > developed a group of people who promote their product (teachers), and > have convinced a group of fickle consumers that they need their > inferior product. That's exactly what I meant by bribe. If you give the teachers free lesson plans, they are much more likely to use your product than if they had to spend many hours on their own (and teachers, particularly younger ones who would be more interested in technology, have a lot less free time than some think!) to develop their own lesson plans. If HP is serious about the education market, they will have to do exactly what TI does -- create a comprehensive set of lesson plans, train the teachers, and convince the textbook manufacturers to mention their products. The first two will have to happen before the third, and it will take years to truly show results. They don't even need to develop a new calculator, because the 39gs is already an excellent calculator for students in the 14-17 age group who are (typically, and understandably) not interested in taking the few minutes/hours to learn RPN/RPL. > (Pink, orange, blue and baby blue seem to be popular this year.) Maybe HP could bring back the old HP 49G, if metallic baby blue is back in style! Hopefully rubber keys and rainbow screen covers (from the units made in Indonesia) are also fashionable... Eric Rechlin === > modul for the 48g?? It's not a module. It appears to be a 48G that has been opened, the 32 KB chip replaced with a 128 KB chip, another 128 KB chip added (for port 1), and a 1 MB card wired to where the GX would have slot 2 to provide ports 2-9. Eric Rechlin