HP-2 I would like to thank Wolfgang and Otto, who spend a lot of effort into a new site on http://www.math.fu-berlin.de/~raut/ which is called: HP 49G/49G+ Tools on http://www.math.fu-berlin.de/~raut/WR49/ All Tools and its documentations are available in HTML. You will find as well zip-files for all these well known *men for offline documentation, for: Unitman Timeman Libman Appsman ... as well as OT49 ... Enjoy! Heiko ==== > I would like to thank Wolfgang and Otto, > who spend a lot of effort into a new site on > http://www.math.fu-berlin.de/~raut/ > which is called HP 49G/49G+ Tools on > http://www.math.fu-berlin.de/~raut/WR49/ This is, as to my knowledge, the first organized site of tools and games for both the HP49G and the HP49G+. Each package *.zip contains either an extra library for each calc (e.g., OT49 and OT49+) or a lib working on both. Only few things do not yet run on the new 49+, marked with a [-] in the listing. The new Filer5 for the 49+ (from Filers) could also be made compatible with the 49 but easier keeping 2 versions because Filer5 allows to make *dated* HOME backups also on the SD-card if present. The builtin filer does not offer this comfort... - Wolfgang ==== > This is, as to my knowledge, the first organized site of tools and > games for both the HP49G and the HP49G+. Maybe time to update your photo too ! ==== > This is, as to my knowledge, the first organized site of tools and > games for both the HP49G and the HP49G+. > Maybe time to update your photo too ! Instead of looking at other people's foto You'd better debugging ROM 1.22 (reports found here), in particular the filer. Option NEW is displayed in minifont. That's ok - apart from that user decision of creating a new file or a new directory should be the first option. But PURGE (flag -76 clear) uses the current font. Then FONT8 is too large for long names like 2: HOME 25.9.03 07.15 which match the filer display perfectly. Thus, the PURGE dialog *must* be in minifont. And it seems to be obvious that the filer's headline should be displayed in the Header and not below the Header's separator (49+). - Wolfgang ==== What does 0^0 equal? ALG48, and 49g on approx mode says one. Ti-89 gives one, but with the message, warning 0^0 replaced by 1. HP49 on exact gives ?. ==== You've stumbled upon one of Math's many mysteries ;-) http://mathforum.org/dr.math/faq/faq.0.to.0.power.html > What does 0^0 equal? ALG48, and 49g on approx mode says one. Ti-89 > gives one, but with the message, warning 0^0 replaced by 1. HP49 on > exact gives ?. ==== > What does 0^0 equal? ALG48, and 49g on approx mode says one. Ti-89 > gives one, but with the message, warning 0^0 replaced by 1. HP49 on > exact gives ?. 0^0 has been discussed endless times, search for it in the newsgroups. It is often regarded as an indeterminate expression because there are 2 different limits (0^x, x->0 = 0 whereas x^0, x->0 = 1). There are some people who define it as 1, probably because the function x^x has that limit. It might make sense in some aspects. All in all it's a question of definition. Axel ==== > What does 0^0 equal? ALG48, and 49g on approx mode says one. Ti-89 > gives one, but with the message, warning 0^0 replaced by 1. HP49 > exact gives ?. > There are > some people who define it as 1, probably because the function x^x has > that limit. Not for that. Moreover, because lim a^x = 1 as x -> 0 for an arbitrary real parameter a including 0. That lim x^x = 1 is a special case of the more general result lim f(x)^g(x) =1 if x approaches 0 from the right (in the complex plane), provided z |-> f(z) and z |-> g(z) are global analytic functions with limit 0 as z approaches 0 (Rotando/Korn The Indeterminate Form 0^0 . Mathematics Magazine, Vol. 50 (1977), pp. 41-42. This result supports in some sense that in most cases it is reasonable to set 0^0 = 1, but not more. On the 49, 0^0 depends on Flag -3. If flag -3 is clear it yields ?, also a good idea. What is ? ? Its an algebraic evaluating to an equally named rompointer (XLIB 788 137) which either errors or evals FPTR 6 2E5 which again generates a symbolic. If flag -3 is set (Function -> num) 0^0 yields 1 - a warning as on TI 89 is not a bad idea! A full understanding of a possible definition or non-definition of 0^0 can only be reached by investigation the analytic function x^y which has a bad singularity at (0,0), no matter whether regarded as a two-variable real or complex function. Draw the real function (x,y) -> x^y in 3D in the unit circle (best in cylindric coordinates) and look at it from all sides. This strange function is growing exponential along the Y-axis, but polynomial along the X-axis. - Wolfgang ==== > ... Draw the real function (x,y) -> x^y in 3D in > the unit circle (best in cylindric coordinates) and look at it from all > sides. This strange function is growing exponential along the Y-axis, > but polynomial along the X-axis. Sorry, (x,y) |-> x^y is a real function as long as y is not negative. Hence, better draw it in a square with (0,0) at the lower left corner or in the middle of the left-hand side of the square, in 3D XYZ coordinates. - Wolfgang ==== HP32sII returns: Invalid y^x I think that the answer depends on what kind of poit of view you choose. The limit is 1. I think it is a good to return a error or a warning. This has been discussed in many NGs many times. Niclas > What does 0^0 equal? ALG48, and 49g on approx mode says one. Ti-89 > gives one, but with the message, warning 0^0 replaced by 1. HP49 on > exact gives ?. ==== > Sorry, (x,y) |-> x^y is a real function as long as y is not negative. I don't think so. (-1.2)^3.4 = a real value? Rick ==== > It is often regarded as an indeterminate expression because there are > 2 different limits (0^x, x->0 = 0 whereas x^0, x->0 = 1). If you define, as usual, exp(x)=sum(n=0 to infinite)(x^n/n!) then you have to define 0^0=1 if you want to have exp(0)=1.... Last year my teacher told me that there was no problem with 0^0 because of this definition of exp. -- Thomas Deniau Unix is user friendly. It's just selective when choosing friends. ==== Yes, well noted. BUT, if you take y negative, then the result is complex. ttfn JasonG > >>Sorry, (x,y) |-> x^y is a real function as long as y is not negative. > > > I don't think so. (-1.2)^3.4 = a real value? > > Rick > > > ==== > Not for that. Moreover, because lim a^x = 1 as x -> 0 for an arbitrary > real parameter a including 0. On the 49, 0^0 depends on Flag -3. Not for a=0. It's easy to see, that lim 0^x = 0 as x -> 0. Fabian ==== > >> Not for that. Moreover, because lim a^x = 1 as x -> 0 for an arbitrary >> real parameter a including 0. On the 49, 0^0 depends on Flag -3. > >Not for a=0. It's easy to see, that lim 0^x = 0 as x -> 0. > >Fabian Or, to be absolutely pedantic about it, lim 0^x = 0 as x -> 0+; unfortunately, lim 0^x as x->0- is undefined. Since it's clearly not continuous, one has to question the validity of using limits on this function at all. -- Matthew Funke (mff@hopper.unh.edu) ==== First of all I want to thank for various corrections. I wish students in my course on foundations of analysis were so attentive... > If you define, as usual, exp(x)=sum(n=0 to infinite)(x^n/n!) then you > have to define 0^0=1 if you want to have exp(0)=1.... > Last year my teacher told me that there was no problem with 0^0 because > of this definition of exp. You see, teachers may be mistaken :-) There are many definitions of the exponential function. The one which you said to be the usual one, is not particularly convenient because familiarity with the theory of infinite series is needed to understand it. The most elementary although abstract definition was given by Alfred Tarski in his textbook from 1937. He first proves the basic theorem that - up to isomorphism - there is one and only one continuously ordered group. Since both the additive group of reals and the multiplicative group of positive reals are continuously ordered, there must be an isomorphism (which clearly maps 0 onto 1). It is uniquely determined if its value for 1 is chosen, a (positive) real b, say. This is precisely the function x |-> exp_b(x). Tarski's definition made it clear (without the ordinary stepwise definition of b^x) why the logarithmic reduction of real multiplication to addition so phantastically works. Since an isomorphism is always a one-to-one mapping, exp_b has trivially an inverse, and this is just the function log_b. - Wolfgang ==== > Not for that. Moreover, because lim a^x = 1 as x -> 0 for an arbitrary > real parameter a including 0. That lim x^x = 1 is a special case of the > more general result lim f(x)^g(x) =1 if x approaches 0 from the right > (in the complex plane), provided z |-> f(z) and z |-> g(z) are global > analytic functions with limit 0 as z approaches 0 (Rotando/Korn The > Indeterminate Form 0^0 . Clearly h(x) := exp(1/x)^x is a counterexample where at least f is not analytic, but lim_(x->0) h(x) = e != 1. > This result supports in some sense that in most cases it is > reasonable to set 0^0 = 1, but not more. Simmply *define* for arbitrary reell a recursively: a^0 := 1 and a^(n + 1) := a*a^n. Then -- with a = 0 -- 0^0 = 1 and 0^n = 0 if n > 0. > A full understanding of a possible definition or non-definition of 0^0 > can only be reached by investigation the analytic function x^y ^^^^ No. Avoid all limites and live long and prosper with the definition given above. Michael -- -= Michael Hoppe , =------ ==== 2. Since it has IR, will it work with the printer? 2a. Will the IR printer be reissued? If you look at product specifications for the g+, you get the specifications for the g (unless the title is a typo). In there it says, regarding the HP infrared printer, Not available. Martin Cohen ==== > 2. Since it has IR, will it work with the printer? I tried it, and yes it works... ==== The Best Fraction Challenge (An Extremely Difficult Challenge Disguised as a Mini-Challenge) DEFINITION OF BEST FRACTION: What fraction is equal to 0.5? There are, of course, infinitely many correct answers to that question. If we limit the answers to ratios of positive integers, there are still infinitely many answers: 1/2, 2/4, 3/6 ... 1234/2468 ... all evaluate to 0.5 on a calculator. But the *smallest* integers (more precisely, the least non-negative integers), with a ratio of 0.5, are 1 and 2. In this sense, the best fraction for 0.5 is 1/2. CHALLENGE: Write a program (none such has ever been published!) that inputs any positive decimal number, and outputs the best fraction for it on the HP48 or HP49, that is, the smallest integers which, when divided on the calculator, yield exactly the same number as the input, in 5 seconds or less for any input, in 100% User RPL. Hundreds of *similar* programs have been written over the years. In fact, the ->Q function is similar. But NONE of these meet the Best Fraction Challenge. All of them yield some answers not exactly equal to the input, or some answers that aren't the best. WARNING! I have posted this challenge here (in various forms) over the past 13 years, and almost every time some people responded with haughty disdain, crowing that it's a trivial and already-solved problem... but of course, when taken to task, they all failed to post a program that would have proved them right. If you really think that the above is as easy as it sounds, then to save face *please* code it up and test it on the following examples before bragging here about how easily you could do it if you only had the time or some other EXAMPLES of inputs and CORRECT outputs (NOT ->Q outputs!) for the HP48/49: Input: 2 SIN (in RAD mode) Output: 1029101 / 1131754 Input: 6.0030000004 (the strange number on the HP38G case) Output: 14823406 / 2469333 Input: 0.999999999975 (the worst case ->Q number) Output: 39215686274 / 39215686275 Input: 0.9498580222 (my telephone number!) Output: 1306259 / 1375215 Input: 50000.00005 Output: 999050001 / 19981 Input: 0.500000000001 Output: 166666666668 / 333333333335 Input: 0.69999937 Output: 777777/1111111 Input: 0.903493239856 Output: 528118/584529 Of course, the program must also be able to handle ordinary inputs, 0.5 etc. copies of the program to anybody, for reasons to be revealed soon. If ANYBODY can meet or beat my program, it will be of monumental importance to me and to all users of calculator fractions. Good luck! Happy Programming! -Joe- Joseph K. Horn pdq@holyjoe.us ==== > The Best Fraction Challenge > (An Extremely Difficult Challenge Disguised as a Mini-Challenge) > > CHALLENGE: Write a program (none such has ever been published!) that > inputs any positive decimal number, and outputs the best fraction for > it on the HP48 or HP49, that is, the smallest integers which, when > divided on the calculator, yield exactly the same number as the input, > in 5 seconds or less for any input, in 100% User RPL. Pardon my ignorance, but can't this already be accomplished using the XQ function? I worked through some of your example problems with it, and they seemed to be properly reduced. James ==== I do not deny that the problem is very difficult - I tried it on the Casio FX-502P back in the 80s (except I preferred the output in vulgar fractions), but by simple inspection of your challenge you've got the wrong answer for the 5th example. The fractional part of 50000.0005 is clearly 1/20000 and so your correct answer should be 1000000001/20000 as given by ->Q of a HP48. www.fx502p.pwp.blueyonder.co.uk and gives the correct answer of 50000+1/20000. I would not pretend however that the program would be up to the challenge in general. I would of course like to see your HP48 program... especially when it is fixed. Peter. > The Best Fraction Challenge > (An Extremely Difficult Challenge Disguised as a Mini-Challenge) > > DEFINITION OF BEST FRACTION: What fraction is equal to 0.5? There > are, of course, infinitely many correct answers to that question. If > we limit the answers to ratios of positive integers, there are still > infinitely many answers: 1/2, 2/4, 3/6 ... 1234/2468 ... all evaluate > to 0.5 on a calculator. But the *smallest* integers (more precisely, > the least non-negative integers), with a ratio of 0.5, are 1 and 2. > In this sense, the best fraction for 0.5 is 1/2. > > CHALLENGE: Write a program (none such has ever been published!) that > inputs any positive decimal number, and outputs the best fraction > for it on the HP48 or HP49, that is, the smallest integers which, when > divided on the calculator, yield exactly the same number as the input, > in 5 seconds or less for any input, in 100% User RPL. > > Hundreds of *similar* programs have been written over the years. In > fact, the ->Q function is similar. But NONE of these meet the Best > Fraction Challenge. All of them yield some answers not exactly equal > to the input, or some answers that aren't the best. > > WARNING! I have posted this challenge here (in various forms) over the > past 13 years, and almost every time some people responded with > haughty disdain, crowing that it's a trivial and already-solved > problem... but of course, when taken to task, they all failed to post > a program that would have proved them right. If you really think that > the above is as easy as it sounds, then to save face *please* code it > up and test it on the following examples before bragging here about > how easily you could do it if you only had the time or some other > > EXAMPLES of inputs and CORRECT outputs (NOT ->Q outputs!) for the > HP48/49: > > Input: 2 SIN (in RAD mode) > Output: 1029101 / 1131754 > > Input: 6.0030000004 (the strange number on the HP38G case) > Output: 14823406 / 2469333 > > Input: 0.999999999975 (the worst case ->Q number) > Output: 39215686274 / 39215686275 > > Input: 0.9498580222 (my telephone number!) > Output: 1306259 / 1375215 > > Input: 50000.00005 > Output: 999050001 / 19981 > > Input: 0.500000000001 > Output: 166666666668 / 333333333335 > > Input: 0.69999937 > Output: 777777/1111111 > > Input: 0.903493239856 > Output: 528118/584529 > > Of course, the program must also be able to handle ordinary inputs, > 0.5 etc. > > copies of the program to anybody, for reasons to be revealed soon. If > ANYBODY can meet or beat my program, it will be of monumental > importance to me and to all users of calculator fractions. > > Good luck! Happy Programming! > > -Joe- > Joseph K. Horn > pdq@holyjoe.us ==== -=[ Sun, 12.10.03 11:48 a.m. +1300 (NZDT) ]=- in message ID : > I do not deny that the problem is very difficult - I > tried it on the Casio FX-502P back in the 80s (except I > preferred the output in vulgar fractions), but by simple > inspection of your challenge you've got the wrong answer > for the 5th example. The fractional part of 50000.0005 > is clearly 1/20000 and so your correct answer should be > 1000000001/20000 as given by ->Q of a HP48. That is thw whole point of the challenge - here is Joe's answer: Input: 50000.00005 Output: 999050001 / 19981 And 19981 is LESS than 20000. Joe's answer is surprisingly correct :) Not only better than the 20000 denominator, but he claims it to be the best - quite sensational. I can't wait to see where his program will be published. It must be a totally new approach. > available at www.fx502p.pwp.blueyonder.co.uk and gives > the correct answer of 50000+1/20000. I would not pretend > however that the program would be up to the challenge in > general. I would of course like to see your HP48 program... > especially when it is fixed. I suspect that it won't need fixing. Although a real counter-example would no doubt be welcomed. - Tony ==== Tony Hutchins a .8ecrit dans le message de > -=[ Sun, 12.10.03 11:48 a.m. +1300 (NZDT) ]=- > > > in message ID : > > I do not deny that the problem is very difficult - I > tried it on the Casio FX-502P back in the 80s (except I > preferred the output in vulgar fractions), but by simple > inspection of your challenge you've got the wrong answer > for the 5th example. The fractional part of 50000.0005 > is clearly 1/20000 and so your correct answer should be > 1000000001/20000 as given by ->Q of a HP48. > > That is thw whole point of the challenge - here is Joe's answer: > > Input: 50000.00005 > Output: 999050001 / 19981 > > And 19981 is LESS than 20000. > Joe's answer is surprisingly correct :) It is because of a tiny approximation error. I checked it on a Math soft on the PC, which performs exact calculation, and substracting the two fractions shows an error of 19/399620000. So, no, Joe's answer's mathmatically wrong, it's just a twist from the HP48/49 that makes it right (4E-8 is neglected in regard to the number of digits and their order in 50000.00005 as too small to be significant) I'm still curious as to how you achieved that, though. > Not only better than the 20000 denominator, but he claims it > to be the best - quite sensational. I can't wait to see > where his program will be published. It must be a totally new > approach. > > available at www.fx502p.pwp.blueyonder.co.uk and gives > the correct answer of 50000+1/20000. I would not pretend > however that the program would be up to the challenge in > general. I would of course like to see your HP48 program... > especially when it is fixed. > > I suspect that it won't need fixing. Although a real > counter-example would no doubt be welcomed. > > - Tony > ==== Joseph K. Horn a .8ecrit dans le message de > The Best Fraction Challenge Here's how I'd do it, assuming I had a previous prime algorithm: (I'll call it PP, I suppose Joe has that somewhere for the 48, but I can't find it, and I think Erable has it in built-in for the 49) Input: Positive integer Output: << -> X << X ->Q OBJ-> DROP DROP SWAP DROP 'Q' STO Q 'R' STO WHILE Q X * 0 RND Q / X == REPEAT Q DUP 'R' STO PP 'Q' STO END ' Q R * 0 RND + / + R + ' + OBJ-> >> >> Needless to say (and as I stated in another post), this should give (I can't test it) the best fraction that will return a correct result in the HP48/49 (and I insist, it only works because of how the ints are in the HP48/49) > Good luck! Happy Programming! > > -Joe- > Joseph K. Horn > pdq@holyjoe.us ==== Oops. I forgot a bit. xD Output: Fraction ==== -=[ Sun, 12.10.03 1:36 p.m. +1300 (NZDT) ]=- in message ID : news client =Microsoft Outlook Express 6.00.2800.1158 previous messages in thread =3 + 1 for your message tot ref chars=133 chars per id =44.3333333333333 Top Thread id=<87233f9e.0310111202.76499b2a@posting.google.com> > Tony Hutchins a .8ecrit dans le message de > -=[ Sun, 12.10.03 11:48 a.m. +1300 (NZDT) ]=- > > > in message ID : > > > I do not deny that the problem is very difficult - I > > tried it on the Casio FX-502P back in the 80s (except I > > preferred the output in vulgar fractions), but by simple > > inspection of your challenge you've got the wrong answer > > for the 5th example. The fractional part of 50000.0005 > > is clearly 1/20000 and so your correct answer should be > > 1000000001/20000 as given by ->Q of a HP48. > > That is thw whole point of the challenge - here is Joe's answer: > > Input: 50000.00005 > Output: 999050001 / 19981 > > And 19981 is LESS than 20000. > Joe's answer is surprisingly correct :) > > It is because of a tiny approximation error. I checked it on a Math soft on > the PC, which performs exact calculation, and substracting the two > fractions shows an error of 19/399620000. So, no, Joe's answer's > mathmatically wrong, it's just a twist from the HP48/49 that makes it > right (4E-8 is neglected in regard to the number of digits and their order > in 50000.00005 as too small to be significant) > > I'm still curious as to how you achieved that, though. > > Not only better than the 20000 denominator, but he claims it > to be the best - quite sensational. I can't wait to see > where his program will be published. It must be a totally new > approach. > > > available at www.fx502p.pwp.blueyonder.co.uk and gives > > the correct answer of 50000+1/20000. I would not pretend > > however that the program would be up to the challenge in > > general. I would of course like to see your HP48 program... > > especially when it is fixed. > > I suspect that it won't need fixing. Although a real > counter-example would no doubt be welcomed. > > - Tony > > -- Tony Hutchins Wellington New Zealand #113 Fate often saves a warrior when his courage endures. Beowolf ==== > Pardon my ignorance, but can't this already be > accomplished using the XQ function? No. XQ has the same faults as ->Q, namely, it gets answers that are either (a) not the best, (b) not equal to the input, or (c) both of the above. > I worked through some of your example problems > with it, and they seemed to be properly reduced. Umm... No. Look again. XQ gets horribly wrong answers for all of the examples except 50000.00005 which it can't even handle (XQ Error: Overflow!!!). Compare the answers you get with the answers that I listed with each example. None match, and some are WAY off. ->Q is better than XQ, but even that fails to get the right answer to ANY of my examples. > ... by simple inspection of your challenge you've > got the wrong answer for the 5th example. The > fractional part of 50000.0005 is clearly 1/20000 > and so your correct answer should be > 1000000001/20000 as given by ->Q of a HP48. Ummm... No. Look again. I want the BEST FRACTION (not the obvious one), with BEST FRACTION being defined as the ratio of the smallest two integers which, when divided ON AN HP48 or HP49, yield exactly the input. Yes, 50000.00005 can be represented by 1000000001/20000, but please look closer at the answer I gave. It has a SMALLER numerator and denominator, AND it evaluates to the same thing as the input ON AN HP48 or HP49. Therefore it is a better answer. And since there are no smaller integers that work, it's the best fraction for the input. Recap: 1000000001 / 20000 = 50000.00005 on an HP48/49, but 999050001 / 19981 = 50000.00005 on an HP48/49 too. So the latter is better. Nothing is better than it, so it's the best fraction. > is available at www.fx502p.pwp.blueyonder.co.uk and > gives the correct answer of 50000+1/20000. The correct answer depends on the machine, just like the correct sine of 2 depends on the machine. If you tell me how many digits the FX-502P calculates with, and whether it truncates or rounds the last digit, then I can tell you what it should return for the examples. BRIEF VERSION OF THE CHALLENGE: I have a decimal fraction. I want to divide two integers ON AN HP48 or HP49 and get EXACTLY that decimal fraction. What are the SMALLEST two integers that'll work? > I would of course like to see your HP48 program... > especially when it is fixed. It is working perfectly... unlike any other decimal to fraction program or function that I know of. It'll be posted here after this challenge has had enough time to simmer. HOMEWORK: What is the BEST fraction for sqrt(LOG(2)) on an HP48 or HP49? -Joe- ==== > > HOMEWORK: What is the BEST fraction for sqrt(LOG(2)) on an HP48 or > HP49? > > -Joe- For LOG, base 10, I get 998995/1820784, which works but may not be best. For LN, base e, I get 462042/554969, which also works, but may not be best. ==== > HOMEWORK: What is the BEST fraction for sqrt(LOG(2)) on an HP48 or > HP49? > > -Joe- On my 49g+, using XQ: 29422/53625 ==== -=[ Sun, 12.10.03 10:36 p.m. +1300 (NZDT) ]=- > For LOG, base 10, I get 998995/1820784, which works but > may not be best. FWIW that gets my vote as well. I haven't a clue how to get there is less than 5 seconds though. The continued fraction method leapfrogs way over that. -- Tony Hutchins New Zealand #71 All computers wait at the same speed. ==== > > The correct answer depends on the machine, just like the correct > sine of 2 depends on the machine. If you tell me how many digits the > FX-502P calculates with, and whether it truncates or rounds the last > digit, then I can tell you what it should return for the examples. How many digits does the 49g calculate with?? Does it truncate or round the last digit?? Need that for a shot at the program. TY ==== >> HOMEWORK: What is the BEST fraction for >> sqrt(LOG(2)) on an HP48 or HP49? > > For LOG, base 10, I get 998995/1820784, > which works but may not be best. > > For LN, base e, I get 462042/554969, > which also works, but may not be best. Congrats! You got the best fractions for both cases! PUH-LEEEEEZE tell me how you did it! Did you use an HP48 or 49? How long did it take? I'm dying to know!!! For what it's worth, my program converts sqrt(LOG(2)) into 998995/1820784 in 0.745 seconds on an hp49g+, and runs unmodified on an HP48GX. -Joe- ==== > > Pardon my ignorance, but can't this already be > accomplished using the XQ function? > > No. XQ has the same faults as ->Q, namely, it gets answers that are > either (a) not the best, (b) not equal to the input, or (c) both of > the above. > > I worked through some of your example problems > with it, and they seemed to be properly reduced. > > Umm... No. Look again. XQ gets horribly wrong answers for all of > the examples except 50000.00005 which it can't even handle (XQ Error: > Overflow!!!). Compare the answers you get with the answers that I > listed with each example. None match, and some are WAY off. ->Q is > better than XQ, but even that fails to get the right answer to ANY of > my examples. > > > ... by simple inspection of your challenge you've > got the wrong answer for the 5th example. The > fractional part of 50000.0005 is clearly 1/20000 > and so your correct answer should be > 1000000001/20000 as given by ->Q of a HP48. > > Ummm... No. Look again. I want the BEST FRACTION (not the obvious > one), with BEST FRACTION being defined as the ratio of the smallest > two integers which, when divided ON AN HP48 or HP49, yield exactly the > input. > > Yes, 50000.00005 can be represented by 1000000001/20000, but please > look closer at the answer I gave. It has a SMALLER numerator and > denominator, AND it evaluates to the same thing as the input ON AN > HP48 or HP49. Therefore it is a better answer. And since there are > no smaller integers that work, it's the best fraction for the input. > > Recap: > > 1000000001 / 20000 = 50000.00005 on an HP48/49, but > 999050001 / 19981 = 50000.00005 on an HP48/49 too. > So the latter is better. > Nothing is better than it, so it's the best fraction. OK Joseph I see what mean, although I'm not sure that it is useful. I suspect that the System RPL of '->Q' calculates errors on the at a higher accuracy than is returned to the user and so the denominator is closer to the true answer of the input number. Your answer is also valid for your interpretation on the FX-502P which also returns exactly 50000.00005 for 999050001/19981. > > is available at www.fx502p.pwp.blueyonder.co.uk and > gives the correct answer of 50000+1/20000. > > The correct answer depends on the machine, just like the correct > sine of 2 depends on the machine. If you tell me how many digits the > FX-502P calculates with, and whether it truncates or rounds the last > digit, then I can tell you what it should return for the examples. This is not straight forward. The FX-502P works to 12 places (but truncates to 10 if you put a value in a memory!). It truncates to 12 places... unless the last 2 digits are greater than 49 and the 8th, 9th & 10th digits are 999 in which case it rounds up the 9s to carry forward into the 7th digit. This rather dubious logic prevents decimal errors leading to .99999... when the next integer is the correct answer. > > BRIEF VERSION OF THE CHALLENGE: I have a decimal fraction. I want to > divide two integers ON AN HP48 or HP49 and get EXACTLY that decimal > fraction. What are the SMALLEST two integers that'll work? > > I would of course like to see your HP48 program... > especially when it is fixed. > > It is working perfectly... unlike any other decimal to fraction > program or function that I know of. It'll be posted here after this > challenge has had enough time to simmer. I look forward to it. > > HOMEWORK: What is the BEST fraction for sqrt(LOG(2)) on an HP48 or > HP49? > > -Joe- ==== >> What is the BEST fraction for sqrt(LOG(2)) > On my 49g+, using XQ: 29422/53625 Close, but no cigar. 29422/53625 is not EQUAL to sqrt(LOG(2)) on the HP48/49. The challenge, as clearly stated, requires that the fraction evaluate to EXACTLY the same number as the input. Using your solution, the input and output are, respectively: .548662004939 .548662004662 (compare last three digits) Even being off by 1 digit in the last place invalidates a solution; this answer is off by 277 digits in the last place. Not acceptable. XQ answers a diferent question than my challenge. XQ is meant for the removal of noise in numbers that are known to be clean ratios. For example, suppose you see a reference in a book to 0.8947368421 and the context makes it clear that they're talking about some kind of ratio of reasonably small integers. They obviously rounded it off to 10 digits, but HP uses 12 digits, so applying ->Q to that decimal yields a ratio of two huge integers... clearly not what we're looking for. Applying XQ yields the nice answer of 17/19. WHICH ANSWER IS RIGHT DEPENDS ON THE QUESTION. If the question is instead, What are the smallest two integers which divide on the HP48 or HP49 to get a result of exactly 0.8947368421? then the best answer is neither what ->Q yields nor what XQ yields, but is instead 8171112721/9132420100 (obtained on my hp49g+ in 1.12 seconds). -Joe- It is difficult to answer when one does not understand the question. -- Sarek (Star Trek IV) ==== Ok, I tested it since yesterday, and it appears it's useless. I searched for other solutions, and it puzzles me how you can do that in less than 5 seconds. Here's why: Bruteforcing my way down a big problem: it can take a lot of time if ->Q gives a wrong result (one that once ->NUMed is different from the input). sqrt(ln(2)) is a good example. Another problem is a stopping condition, if I start from a valid ->Q result, I can tell it to keep lowering Q until it reaches a Q that makes Q X * 0 RND Q / different from X A less calculating method seems to be, starting from the right fraction (not the best): Let's call the fraction Q/D (not best) and Qb/Db (best). If you divide Q by d from D going down, the stop point is the result which has the lowest number of digits, while still having RND(d*X)/d == X As you can guess, the problem is to have Q and D to start with, since ->Q can gives wrong results, and so does a continuous fraction method (tried it, it fails because of the approximation, I might retry it with different parameters than the one I found (it was a VB algorithm) to see if I can adjust it to the HP's precision). In both cases, what really kills me is how to find a starting point that's close enough and/or a method to converge faster to a solution. BlackLotus a .8ecrit dans le message de > > Joseph K. Horn a .8ecrit dans le message de > The Best Fraction Challenge > > Here's how I'd do it, assuming I had a previous prime algorithm: (I'll call > it PP, I suppose Joe has that somewhere for the 48, but I can't find it, and > I think Erable has it in built-in for the 49) > > Input: Positive integer > Output: > > << -> X > << X ->Q OBJ-> DROP DROP SWAP DROP > 'Q' STO Q 'R' STO > WHILE Q X * 0 RND Q / X == > REPEAT Q DUP 'R' STO PP 'Q' STO > END > ' > Q R * 0 RND + / + R + ' + OBJ-> >> >> > > Needless to say (and as I stated in another post), this should give (I can't > test it) the best fraction that will return a correct result in the HP48/49 > (and I insist, it only works because of how the ints are in the HP48/49) > > Good luck! Happy Programming! > > -Joe- > Joseph K. Horn > pdq@holyjoe.us > > ==== > It is because of a tiny approximation error. I checked it on a Math soft on > the PC, which performs exact calculation, and substracting the two > fractions shows an error of 19/399620000. So, no, Joe's answer's > mathmatically wrong, it's just a twist from the HP48/49 that makes it > right (4E-8 is neglected in regard to the number of digits and their order > in 50000.00005 as too small to be significant) The 49 CAS itself (in exact mode) will do: '1000000001/20000 - 999050001/19981' EVAL '-19/399620000' But the challenge does not ask for a mathematically exact result, but an exact result when the fraction is approximated to a 48 or 49 real. RaM. ==== > > HOMEWORK: What is the BEST fraction for sqrt(LOG(2)) on an HP48 or > HP49? > > -Joe- > > On my 49g+, using XQ: 29422/53625 On my 49, in approximate mode, 'SQRT(LOG(2,)' evaluates to .548662004939 but '29422/53625' evaluates to .548662004662. ==== > >> HOMEWORK: What is the BEST fraction for >> sqrt(LOG(2)) on an HP48 or HP49? > > For LOG, base 10, I get 998995/1820784, > which works but may not be best. > > For LN, base e, I get 462042/554969, > which also works, but may not be best. > > Congrats! You got the best fractions for both cases! > > PUH-LEEEEEZE tell me how you did it! Did you use an HP48 or 49? How > long did it take? I'm dying to know!!! I used a very primitive and very slow method based on Farey fractions. as outlined below. Let x be the decimal number to be aproximated, and assume it is not already an integer. Find integers n1 < x and n2 > x, and start with fractions n1/d1 and n2/d2 where d1 = d2 = 1. Then decrease the interval by taking n/d in place of the appropriate endpoint, where n = n1 + n2 and d = d1 + d2. Eventually, but very slowly, n/d gives the correct decimal on the 49, at least for all the decimals I have tried. I also did several tests using reals for which XQ gives the wrong values without getting any wrong answers. A variant on continued fractions should give the same results in considerably less time, but I haven't got the bugs worked out of it yet. > > For what it's worth, my program converts sqrt(LOG(2)) into > 998995/1820784 in 0.745 seconds on an hp49g+, and runs unmodified on > an HP48GX. > > -Joe- My program on my 49 takes about 53 seconds for the same result. ==== Virgil a .8ecrit dans le message de > I used a very primitive and very slow method based on Farey > fractions. as outlined below. > > Let x be the decimal number to be aproximated, and assume it is not > already an integer. > Find integers n1 < x and n2 > x, and start with fractions n1/d1 and > n2/d2 where d1 = d2 = 1. > > Then decrease the interval by taking n/d in place of the appropriate > endpoint, where n = n1 + n2 and d = d1 + d2. > > Eventually, but very slowly, n/d gives the correct decimal on the > 49, at least for all the decimals I have tried. I also did several > tests using reals for which XQ gives the wrong values without > getting any wrong answers. > > A variant on continued fractions should give the same results in > considerably less time, but I haven't got the bugs worked out of it > yet. > I thought about that problem all day long, and I never came to think about that. Maybe I should have taken maths and not economics. :p > My program on my 49 takes about 53 seconds for the same result. It takes less than 3 seconds on my HP48 using the method you described; my program takes 357 bytes. ==== > How many digits does the 49g calculate with?? > Does it truncate or round the last digit?? User RPL calculates internally with a truncated 15-digit mantissa, then rounds that down to 12 digits and returns that to the user as the final answer. -Joe- ==== > > The Best Fraction Challenge > (An Extremely Difficult Challenge Disguised as a Mini-Challenge) > > CHALLENGE: Write a program (none such has ever been published!) that > inputs any positive decimal number, and outputs the best fraction for > it on the HP48 or HP49, that is, the smallest integers which, when > divided on the calculator, yield exactly the same number as the input, > in 5 seconds or less for any input, in 100% User RPL. > > Pardon my ignorance, but can't this already be accomplished using the XQ > function? I worked through some of your example problems with it, and they > seemed to be properly reduced. > > James Try it with one of his examples... 0.69999937 XQ produces '111106/158723'. Then pressing ->NUM produces the decimal .699999369972, which means that XQ's result is not the best possible fraction. The best fraction, of course, is '777777/1111111'. ==== what about 3.14159265359? ==== > what about 3.14159265359? pi is a special case. It is taken into consideration as a 15-nibble version internally and the 12 number version si actually 13 digits precise: 3.14159265358979 15 => round to 13 3.141592653590 BUT what is the answer, Joe? ==== reth a .8ecrit dans le message de > what about 3.14159265359? > 1146408/364913 > ==== -=[ Tue, 14.10.03 04:50 a.m. +1300 (NZDT) ]=- in message ID <3f8a9c77$1@dnews.tpgi.com.au> : > what about 3.14159265359? I the ->Q answer for that (1146408/364913) satisfies the challenge. Like others, I lost a few hours yesterday, but the challenge did come with a warning. My result works well on most examples, but fails *miserably* on .50000000001 and also the HP38G number. I start with a continued fraction method and so lose the last 1 as .500000000001 1/X 1/X = .5 only :( Maybe I need a MANT somewhere. But, where?. I look forward to seeing Joe's code :) -- Tony Hutchins New Zealand #2 Save whales - collect the whole set. ==== I have a question here, because I lack the mathematical knowledge to solve a part of the problem. I tried Virgil's method, and it seemed to work fine until I tried a number like 50000.00005. There it kind of killed my hopes, because it takes horribly long to get the answer. I looked a little, and it seems it chockes on the limit cases such as 0.001 (it requires 999 iterations), especially when it uses all the digits and a lot of them are similar. I think my iterations can go up to (1/X)-1 (or 1/(1-X)-1), which means close 1E11 iterations to reach a result for 0.999999999975. Way too long. I spent a good while trying to figure how to get the solution with as little iterations as possible, and while some CF algorithms looked nice, they often return the exact result, not the best result. I tried changing the way the interval is shrunk, but it doesn't cut much time. I looked deeper and tried to find what is special with the result we want, and I found a few things. First, if X is my number, and Q/D the fraction I'm looking for, then it appears that D*X <> Q, but Q/X = D, due to rounding. We know X, we'll search Q, then. Also, the Q/X we're looking for has to particualrity of being an integer, which means that CEIL(Q/X)=FLOOR(Q/X)=IP(Q/X)=Q/X. How does that help? Well, the Q that we're looking for is the smallest Q so that IP(Q)/CEIL(Q/X)=X (or FLOOR(Q/X)/CEIL(Q/X)=1, with Q an integer. The problem is, the 48's built-in solver stops on extremums or sign changes, or leaps over the solution. So, you guessed it, my problem is to find the solution to that fairly simple equation, given that the built-in solver chokes (not to say is useless), and that derivation won't work. So, the possibilities I see are these: Either I can find a solving algorithm and chances are it will go faster than the convergence I used so far, or I can find a derivable mathematical formula that says exactly the same as my IP(Q)/CEIL(Q/X)-X=0, except without IP and CEIL, since the HP won't derivate them. I don't know if they're the way Joe chose (I doubt it, I usually find the most complicated solution to a problem), but I'd like to explore it, and I don't have the knowledge to solve that equation. I figured it could be interesting, since ideally, finding a solution would take pretty much the same time regardless of the starting value. ==== > what about 3.14159265359? The best fraction for pi on an HP 12-digit calculator is what ->Q returns for it in STD mode: 1146408/364913. Same is true for pi^e, which for all I know is a rational number, though I doubt it. -Joe- ==== -=[ Tue, 14.10.03 07:13 a.m. +1300 (NZDT) ]=- in message ID : > I have a question here, because I lack the mathematical > knowledge to solve a part of the problem. I lack the knowledge of how to differentiate those IP functions as well - you have step functions there. Possibly there is no classical way to handle them. > I tried Virgil's method, and it seemed to work fine until > I tried a number like 50000.00005. There it kind of killed > my hopes, because it takes horribly long to get the answer. The CF algorithm really helps on that one - it gives the 20000 denominator instantly. AFAIK the only way to test if smaller denominators work is to decrement the 20000 by 1 until it doesn't work. It doesn't take long. I suspect some process like this is what makes Joe's algorithm sometimes take 5 seconds, instead of under 1 second. > I looked a little, and it seems it chockes on the limit cases > such as 0.001 (it requires 999 iterations), especially when > it uses all the digits and a lot of them are similar. I > think my iterations can go up to (1/X)-1 (or 1/(1-X)-1), > which means close 1E11 iterations to reach a result for > 0.999999999975. Way too long. I spent a good while trying > to figure how to get the solution with as little iterations > as possible, and while some CF algorithms looked nice, they > often return the exact result, not the best result. But CF is great to get near the best answer - I think successive results always bound the answer. The trick is not to let the CF go too far. A good place to stop is when Denominator*X=Numerator, which often happens before the exact result. [...] -- Tony Hutchins New Zealand ==== Tony Hutchins a .8ecrit dans le message de > -=[ Tue, 14.10.03 07:13 a.m. +1300 (NZDT) ]=- > > The CF algorithm really helps on that one - it gives the 20000 > denominator instantly. AFAIK the only way to test if smaller > denominators work is to decrement the 20000 by 1 until it > doesn't work. It doesn't take long. I suspect some process > like this is what makes Joe's algorithm sometimes take 5 > seconds, instead of under 1 second. > But for example, on sqrt(log(2)), the CF algorithm I still have returns 418507862138/762779012161, which is far from the best solution (and lower than the exact solution), and going your way down from here is going to take long. On the same idea, I realized that sometimes the exact fraction and the best fraction are such that there's a set of values where the fraction is true, then a set of value where it's false (I used that as a stopping condition in the first try I made) and then back to a set where it's true again like with sqrt(log(2)). > > But CF is great to get near the best answer - I think > successive results always bound the answer. The trick is not to > let the CF go too far. A good place to stop is when > Denominator*X=Numerator, which often happens before the exact > result. > [...] > > -- > Tony Hutchins > New Zealand > ==== > what about 3.14159265359? > > 1146408/364913? ==== -=[ Tue, 14.10.03 08:31 a.m. +1300 (NZDT) ]=- in message ID : > But for example, on sqrt(log(2)), the CF algorithm I still have returns > 418507862138/762779012161, Calling that N/D, and the target X, I stop CF when I have D*X=N This happens when D=470069 I think. This really helps in most of the examples, but not all ... so it is not the key by any means -- Tony Hutchins New Zealand ==== > what about 3.14159265359? > > The FX-502P actually has it built in pi wrong at 3.14159265358 i.e. truncated to 12 places rather than rounded to 3.14159265359. Casio even got it successor the FX-602P wrong with 3.14159265360! Peter. ==== Tony Hutchins a .8ecrit dans le message de > -=[ Tue, 14.10.03 08:31 a.m. +1300 (NZDT) ]=- > > Calling that N/D, and the target X, I stop CF when I have D*X=N > This happens when D=470069 I think. This really helps in most > of the examples, but not all ... so it is not the key by any > means Just for the record, 470069*sqrt(log(2)) is an integer (257909), but 257909/470069 is different (by 1E-12, the last digit) from sqrt(log(2)). And I know it's not the perfect solution, which puzzles me as how Joe did it. > -- > Tony Hutchins > New Zealand > > ==== -=[ Tue, 14.10.03 09:43 a.m. +1300 (NZDT) ]=- in message ID : > Just for the record, 470069*sqrt(log(2)) is an integer (257909), but > 257909/470069 is different (by 1E-12, the last digit) from sqrt(log(2)). Yup the CF method is pretty good at getting close, quickly. What eludes me is a general rule :( I tried lots of variations hoping that one would suddenly work for all examples, and then I could see if I could understand it by general reasoning, after playing about. I learned to program quickly, and it was fun - I like working with the 49g+. It seems I was lucky there as my keyboard is fine. No keys stand out as non-functional, and I don't use a hammer. > And I know it's not the perfect solution, which puzzles me > as how Joe did it. It will be very interesting to see the answer-the logic, and the implementation. I can't even do that example of .5 + E-12 - I keep losing the E-12 ... and CF jumps to D=250,000,000,001 on the second term!! If I divide that by 15 I get close. I almost have a different program for each example. I reckon if I could see how to do that one ... I might see how to find 2 denominators D1,D2 such that I know the answer is D1,D2 or something bigger like D1+D2. Then if an answer is found it always needs checking in case there is a lower equivalent, separated by 1,2,3 etc. Also I may be totally wrong about everything . What we need is probably a number theory expert. But it sounds like Joe himself has broken new ground here! -- Tony Hutchins New Zealand ==== > ... AFAIK the only way to test if smaller > denominators work is to decrement the 20000 > by 1 until it doesn't work. It doesn't take > long. I suspect some process like this is > what makes Joe's algorithm sometimes take 5 > seconds, instead of under 1 second. You're hot on the trail, but FYI I'm pretty sure that the slowest input for my program is the worst case number 0.999999999975, which takes 1.25 seconds (on a 49g+). > But CF is great to get near the best answer - > I think successive results always bound the > answer. The trick is not to let the CF go too > far. That's one of the charms of my program: it never introduces ANY roundoff error at any point, not even with 1/x. It is partly based on continued fractions, but it does NOT use FP(1/x) [like everybody else does] because that loses information at every iteration. My method loses NO information, and in fact marches inexorably towards the best fraction every time, with at most a handful of iterations, even with inputs that are pure evil, such as the ones with large partial quotients such as .500000000001, whose continued fraction expansion is exactly [0; 1, 1, 249999999999, 2]. MASSIVE HINT: Write a program that converts any input number to its the solution to this Best Fraction Challenge is just a hop, skip and a jump. Literally. In case it helps, here are the *EXACT* continued fraction expansions of the examples that have appeared in this thread so far. Instead of the usual notation [integer part; partial quotient, pq, pq, ...], I'll just show 'em in a list, HP style. Remember, the operative word here is EXACT! For example, pi is not exactly equal to 314159265359/100000000000, but HP's version of pi *is* exactly equal to that, mathematically. Let's call it HP pi. HP 2 SIN (in RAD mode) = { 0 1 10 39 1 12 1 2 1 45 1 25 1 22 14 1 1 24 } 6.0030000004 = { 6 333 3 2499 1 2 333 } 0.999999999975 = ( 0 1 3999999999 } 0.9498580222 = { 0 1 18 1 16 1 1 1 12 1 3 24 3 6 5 1 14 2 } 50000.00005 = { 50000 20000 } 0.500000000001 = { 0 1 1 249999999999 2 } 0.69999937 = { 0 1 2 3 15872 1 2 1 1 12 3 2 } 0.903493239856 = { 0 1 9 2 1 3 4 1 2 6 1 5 1 6 7 1 11 15 18 4 } HP sqrt(LOG(2)) = 0.548662004939 = { 0 1 1 4 1 1 1 3 7 7 9 1 6 1 5 1 1 2 3 10 2 20 1 7 2 2 } HP sqrt(LN(2)) = 0.832554611158 = { 0 1 4 1 34 1 5 6 3 1 1 9 6 1 14 1 6 1 1 178 1 2 } 0.8947368421 (almost 17/19) = { 0 1 8 2 526315789 } 17/19 (*not* HP 17/19, but the real thing) = {0 1 8 2 } HP pi = { 3 7 15 1 292 1 1 1 2 1 4 1 1 1 1 1 3 1 68 2 4 2 } HP pi^e = 22.4591577184 = { 22 2 5 1 1 1 1 1 3 2 1 1 3 8 1 8 1 11 1 3 4 2 } -Joe- ==== -=[ Tue, 14.10.03 1:11 p.m. +1300 (NZDT) ]=- in message ID <87233f9e.0310131516.429c8ab7@posting.google.com> : [...] > even with inputs that are pure evil, such as the ones > with large partial quotients such as .500000000001, > whose continued fraction expansion is exactly [0; 1, 1, > 249999999999, 2]. I get [0; 1,2], which converts back to .666', so indeed it is pure evil, evil extended .[1] Many many thanks for your tips Joe! I see the problem I now have to deal with. I seem to have to do reciprocals - I can see how to recover lost digits (DUP 1/x 1/x - for example), but I can't see what to do with them yet - especially with the above example I want a reciprocal of the .500000000001 that is at least under 2. A nice puzzle - how to adjust a reciprocal. > MASSIVE HINT: Write a program that converts any input number > to its *exact* continued fraction expansion, and vice versa. > is just a hop, skip and a jump. Literally. MANY THANKS!!!! Literally? I can't find these hop,skip & jump functions in user RPL That should keep me on the straight and narrow over the next month ;-) Today, for the first time, I really followed the continued fraction notation - in the past all those divisions made me dizzy I already tried to reverse the process but failed there too - with the evil one above - going backwards in RPN style from the end of the fraction, I lost significance at the first + below: 2 1/x 249999999999 + 1/x 1 + 1/x 1 + 1/x 0 + ... and I just end up with .5 again. Still that's better than .666[1]. Once I crack this I'll be on the way, I hope. So, I have to find a way to avoid reciprocals - but this looks rather tricky, given the usual simple continued fraction notation :) No, no, I just need accurate reciprocals. Or somehow turn everything on its head. > In case it helps, here are the *EXACT* continued fraction expansions > of the examples that have appeared in this thread so far. [...] follow what you mean! I'll be working on this on the train and hope to soon see the 49g+ march ineluctably to the correct answers - after I figure out the hop and the skip and the jump :) I can almost imagine I will have to hop to the right denominator interval, and maybe skip to one end and jump about a bit in the interval - *that* part I have been doing already. This is a terrific challenge - although I consider it recreational I feel it also might have uses in computer science - hope it does! [1] Oops I see I made a mistake above - for the .500000000001 I get [0;2], not [0;1,2] which converts back to .5, not .666'. Unintentional. -- Tony Hutchins Wellington New Zealand #248 I praise loudly; I blame softly. Queen Catherine II ==== -=[ Tue, 14.10.03 9:32 p.m. +1300 (NZDT) ]=- in message ID <87233f9e.0310131516.429c8ab7@posting.google.com> : [...] Joe, me again. I made progress :) > inputs that are pure evil, such as the ones with large partial > quotients such as .500000000001, whose continued fraction expansion is > exactly [0; 1, 1, 249999999999, 2]. I can do this now. Took me a while to un-confuse myself > MASSIVE HINT: Write a program that converts any input number to its > the solution to this Best Fraction Challenge is just a hop, skip and a > jump. Literally. I seem to have a problem doing the reverse - getting back to the exact number..see below [...] > For example, pi is not exactly equal to > 314159265359/100000000000, *That* is what gave me the clue to doing the expansion - I don't start with .500000000001 but that*E12 /E12 - I start hidden tip!! Than I saw a worked example of old Euclid's algorithm for GCD and that gave me another hint. This is stuff I never studied at school. [...] The problem: Input: 0.500000000001 Output: 166666666668 / 333333333335 The expansion in partial quotients: [0; 1, 1, 249999999999, 2]. a0 a1,a2, a3 , a4 (notation) To reverse the process I assume I calculate successive convergents:p1/q1,p2/q2,p3/q3 and p4/q4. I thought p4/q4 would give me the original .500000000001 p0=a0=0 p(-1)=1 q0=1 q(-1)=0 p1=a1*p0+p(-1)=1*0+1 =1 q1=a1*q0+q(-1)=1*1+0 =1 p1/q1=1/1=1 p2=a2*p1+p0=1*1+0 =1 q2=a2*q1+q0=1*1+1 =2 p2/q2=1/2=.5 p3=a3*p2+p1=249999999999*1+1 =250000000000 q3=a3*q2+q1=249999999999*2+1 =499999999998 Oh!!! I see the error!! q3 sb=499999999999 p3/q3=.500000000001 Yeah! p4=a4*p3+p2=2*250000000000+1 =500000000001 q4=a4*q3+q2=2*499999999999+2 =E12 p4/q4=.500000000001 - exactly. OK, I think I can now do the reversal. I seem to be stumped as to how to hop, skip and jump to near the 33333333335 denominator. Is there a different way to do the convergents? Maybe backwards? You can tell I haven't the foggiest idea how to be sure I am homing in on the Best Fraction for the HP48/49. For all I know it could be lurking almost anyware. However I do have p3/q3. So I must check backwards with smaller denominators until I find the earliest example where the p/q equals our value, on the HP48/49. Ahha .. maybe it is as I once suspected that there is a whole series of *consecutive* results that give the answer. So, maybe I: 1. hop to the first endpoint that gives the answer. 2. That means the previous convergent doesn't give the answer. So I just skip to the denominator in the middle, and check that out. 3. This way I establish a new interval to look in, and I jump to that one :) Yup, successive bisection - might be a general method. Joe, in writing this I think I found my way! I started to write because I was stumped. I'm still a bit worried that somehow an earlier value may exist - but although the results go up and down in a sawtooth like way, overall they are probably well-behaved. -- Tony Hutchins Wellington New Zealand #77 Allen's Axiom: When all else fails, follow instructions. ==== Horn says... > For what it's worth, my program converts sqrt(LOG(2)) into > 998995/1820784 in 0.745 seconds on an hp49g+, and runs unmodified on > an HP48GX. How long does it take to run on a 48GX, or on a 49G? ==== > For example, pi is not exactly equal to > 314159265359/100000000000, > > *That* is what gave me the clue to doing > the expansion - I don't start with .500000000001 > but that*E12 /E12 - I start with an integral > hidden tip!! That's the trick for avoiding the 1/FP(x) roundoff errors that have plagued decimal-to-fraction algorithms forever. You have taken your first steps into a larger world. -- Obi-Wan Kenobi > I seem to be stumped as to how to hop, skip > and jump to near the 33333333335 denominator. MASSIVE HINT (spoiler, actually) #2: With the list of partial quotients handy, examine the *differences* between successive intermediate convergents' numerators. Now do the same for their denominators. When the pattern hits you, it'll hit you hard, so be sure to be sitting down! > Yup, successive bisection - might be a general method. Put that together with the previous paragraph, and you have my program, sans bells & whistles. > although the results go up and down in a sawtooth > like way, overall they are probably well-behaved. Indeed they are. Have fun! -Joe- ==== -=[ Wed, 15.10.03 3:48 p.m. +1300 (NZDT) ]=- in message ID <11475796ROBOTLX@news.cis.dfn.de> : > Joe, me again. I made progress :) Joe, I can now make all the examples work. The final hopping skipping and jumping *did* stump me - took about 5 attempts. I have it working, based on sort of heuristic theory ;-) eg .500000000001 BF leaves this in the stack: 166666666668 333333333335 Here is BF, with some comments where the line begins with ' << ' don't allow negative input ABS 'Z' STO ' create partial quotients, and the convergents Z MAN MPQN 'could use PN QN / and a counter 'now, HOP to the first convergent which produces 'an exact-HP48/49 result ' This is called N2/D2 & the previous one is NJ/DJ ' DJ is actually the JUMPING unit 1 'D2' STO PN 1 GET 'N2' STO 1 'K' STO WHILE N2 D2 / Z NOTEQUAL (i.e. =/= ) REPEAT K 1 + 'K' STO N2 'NJ' STO PN K GET 'N2' STO D2 'DJ' STO QN K GET 'D2' STO END ' now we do the jumping backwards from N2/D2 ' we start about the middle of the whole interval 0->D2 ' There, we find D3 and N3 ' The trick is that we hop back from D2 ' in steps of DJ ' If N3/D3 is indeed a BETTER FRACTION candidate we use D3 ' as D2 - otherwise we shift D1 up to D3, and work ' from the middle of the new D1->D2 ' J is the distance from 'D3 to D2' measured in steps of ' DJ 0 'D1' STO D2 DJ / 2 / IP 'J' STO WHILE J 0 > REPEAT D2 DJ J * - 'D3' STO N2 NJ J * - 'N3' STO N3 D3 / Z == <> <> IFTE D2 D1 - DJ / 2 / IP 'J' STO END N2 D2 >> MAN - this makes the AN list of partial quotients for a positive fraction Z I make the list end with a 0. << ->Z << {} Z IP + 'AN' STO E12 DUP Z FP * WHILE DUP 0 > REPEAT DUP 'D1' STO NDQR SWAP AN SWAP + 'AN' STO D1 SWAP END AN 0 + 'AN' STO >> >> NDQR (used by MAN) takes positive integers N D in stack and outputs integers Q R where N=Q*D + R and R is less than D, and not negative. The bit before the WHILE is to quickly get a good first guess for Q. This puts Q and R on the stack as well as making global variables for them - I'm in a hurry << -> N D << N D / IP DUP 0 > <<1 ->>IFT 'Q' STO N D Q * - 'R' STO WHILE R D >= REPEAT R D - 'R' STO Q 1 + 'Q' STO END Q R >> >> Here is the last piece - MPQN: uses AN (list of partial quotients) and produces PN and QN - lists of pk and qk such that pk/qk is kth convergent. << 1 'P0' STO 0 'Q0' STO AN 1 GET 'P1' STO 1 'Q1' STO {} P1 + 'PN' STO {} Q1 + 'QN' STO AN 2 GET 'AK' STO 2 'K' STO WHILE AK 0 > REPEAT AK P1 * P0 + 'P2' STO AK Q1 * Q0 + 'Q2' STO P1 'P0' STO P2 'P1' STO Q1 'Q0' STO Q2 'Q1' STO PN P2 + 'PN' STO QN Q2 + 'QN' STO K 1 + 'K' STO AN K GET 'AK' STO END >> None of the examples take more than 3-4 seconds, on a 49g+,so it is 3-4 times slower than your program Joe. I only just got this functional, with what I am sure is a very limited subset of RPL I see now I could calculate pk/qk as I go, calculating the ak and can stop as soon as I have the first exact HP48/49 result. Also, I make far too many global variables. But, I'm just so pleased to see it working :) Really great challenge - thanks! I'm not really sure about my jumping unit, but, as it does 'hit' on the likely candidates, there must be something to it. I soon realised I couldn't just look at all possibilities, unless of course the prior convergent has denominator 1. The likely candidates are more or less quantized by the prior convergent. - Tony ==== -=[ Wed, 15.10.03 6:40 p.m. +1300 (NZDT) ]=- in message ID <87233f9e.0310131516.429c8ab7@posting.google.com> : > In case it helps, here are the *EXACT* continued fraction > expansions of the examples that have appeared in this thread > so far. It did help :) Now I have it all at least functional (in case anyone keys in the programs from my last post, the MAN can do with a DROP DROP at the end), I've been experimenting. The square root of 3 is fascinating - on the HP48/49 it produces nearly 30 partial quotients!!!! Starting with 9 pairs of 1 2. I get 716035/413403 for the best fraction. Joe, you must tell us the story as to how you came to investigate this - .. if there is a story :-) Is it part of a book/paper you intend to publish? -- Tony Hutchins Wellington New Zealand #252 What you will do matters. All you need is to do it. Judy Grahn ==== >> For what it's worth, my program converts >> sqrt(LOG(2)) into 998995/1820784 in 0.745 >> seconds on an hp49g+, and runs unmodified on >> an HP48GX. > > How long does it take to run on a 48GX, > or on a 49G? It takes approximately 3 times longer, for almost any input. -Joe- ==== Does anyone know how the commands BUFLEN, XMIT, and SRECV will function on the 49G+. I suspect that by using a cable that does not connect to the 5 volt wire, serial communication could be achieved over this port. I hope that I am right, does anyone know for sure??? What are the valid port speeds using the wire or the IrDA. John Evers ==== > Does anyone know how the commands BUFLEN, XMIT, and SRECV will > function on the 49G+. I suspect that by using a cable that does not > connect to the 5 volt wire, serial communication could be achieved > over this port. I hope that I am right, does anyone know for sure??? > What are the valid port speeds using the wire or the IrDA. It seems like the calc accepts speeds up to 115,200 There is always the hp48gII, too... ==== Does anyone know if there is a software solution to connect a 4xG to a Mac running OS X? I would like to purchase one of the new calculators, but if I will be unable to connect it to my machine I see little poiunt in doing so. ==== In <2104bf34.0310051230.2b4d0502@posting.google.com> Luke Petschauer > Does anyone know if there is a software solution to connect a 4xG to a > Mac running OS X? I would like to purchase one of the new calculators, > but if I will be unable to connect it to my machine I see little > poiunt in doing so. > The way I do it is by using a SD card reader plugged on the USB port. I copy all the files I need from MacOS to the SD card then put the SD card into the calculator. Works quite well, and is faster than using the connectivity kit on a Windows PC ==== > In <2104bf34.0310051230.2b4d0502@posting.google.com> Luke Petschauer > Does anyone know if there is a software solution to connect a 4xG to a > Mac running OS X? I would like to purchase one of the new calculators, > but if I will be unable to connect it to my machine I see little > poiunt in doing so. > > > The way I do it is by using a SD card reader plugged on the USB port. I > copy all the files I need from MacOS to the SD card then put the SD card > into the calculator. Works quite well, and is faster than using the > connectivity kit on a Windows PC > Can you upgrade from version 1.20 to 1.22 this way? ==== FYI VirtualPC ought to be able to run the connectivity kit since it's USB-based. ==== I have a couple of (I hope) simple questions about plotting on the HP48GX. (1) How do I plot a line with undefined slope? Plotting X=6 should give me a vertical line at X=6. However, using the Function plot type, everything I try gives me a horizontal line at Y=6 instead. What am I missing? (2) With the Scatter plot type I can plot specific points that represent, for instance, the vertices of a parallelogram. Is there a way to get the calculator to connect the dots and draw the parallelogram itself? (IOW, I want to input the coordinate pairs and get a connected figure, not just the individual points.) -- Wayne Brown | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== > I have a couple of (I hope) simple questions about plotting on the HP48GX. > > (1) How do I plot a line with undefined slope? Plotting X=6 should > give me a vertical line at X=6. However, using the Function plot type, > everything I try gives me a horizontal line at Y=6 instead. What am > I missing? > > (2) With the Scatter plot type I can plot specific points that represent, > for instance, the vertices of a parallelogram. Is there a way to get > the calculator to connect the dots and draw the parallelogram itself? > (IOW, I want to input the coordinate pairs and get a connected figure, > not just the individual points.) > Abput (1): could you explain in detail what are you doing? I'll try to help. ==== > > I have a couple of (I hope) simple questions about plotting on the HP48GX. > > (1) How do I plot a line with undefined slope? Plotting X=6 should > give me a vertical line at X=6. However, using the Function plot type, > everything I try gives me a horizontal line at Y=6 instead. What am > I missing? > > (2) With the Scatter plot type I can plot specific points that represent, > for instance, the vertices of a parallelogram. Is there a way to get > the calculator to connect the dots and draw the parallelogram itself? > (IOW, I want to input the coordinate pairs and get a connected figure, > not just the individual points.) > > > Abput (1): could you explain in detail what are you doing? I'll try to help. Here's an example: If I want to plot y=2, I can go into the plot screen, choose TYPE: Function, set the EQ to 'Y=2' and reset all the options to the defaults. Then when I press ERASE and DRAW it gives me a horizontal line that crosses the Y axis at 2. That works as I would expect. However, if I do the same thing with EQ set to 'X=2' it still gives me the same horizontal line as Y=2. What I expected to see was a vertical line that crosses the X axis at 2. I've tried changing the independent variable to Y (the default is X) but it doesn't change the way the plot is drawn. I don't remember all the other things I've tried changing, but none of them has worked. An example from my son's geometry homework was to plot y=x+2, y=2, and x=6, then find the area of the triangle enclosed by the lines. Plotting these equations on paper gives a vertical line, a horizontal line, and a slanted line that intersect to enclose a right triangle with vertices at (0,2), (6,8) and (6,0). Plotting all three equations on the calculator gives the base and hypotenuse of the triangle, but the vertical line that should form the third side (corresponding to X=6) actually is rendered as another horizontal line parallel to the base and crossing the Y axis at Y=6. It's a very simple thing to do on paper, but I just can't figure out how to it on the calculator. -- Wayne Brown | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== but I posted it to the newsgroup by mistake. That's what I get for using a different newsreader than the one I'm used to using. :-) -- Wayne Brown | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== I can't speak for everyone, but I'm interested in this thread. I'd kinda like to know what comes out of it. John > > > > > > but I posted it to the newsgroup by mistake. That's what I get for > using a different newsreader than the one I'm used to using. :-) > > -- > Wayne Brown | When your tail's in a crack, you improvise > fwbrown@bellsouth.net | if you're good enough. Otherwise you give > | your pelt to the trapper. > e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== Wayne, Regarding how to plot vertical lines, refer to Wlodek's answer in Datafile V16N4p7. Jordi ==== X > An example from my son's geometry homework was to plot y=x+2, y=2, and > x=6, then find the area of the triangle enclosed by the lines. Plotting > these equations on paper gives a vertical line, a horizontal line, and a > slanted line that intersect to enclose a right triangle with vertices at > (0,2), (6,8) and (6,0). Plotting all three equations on the calculator > gives the base and hypotenuse of the triangle, but the vertical line > that should form the third side (corresponding to X=6) actually is > rendered as another horizontal line parallel to the base and crossing > the Y axis at Y=6. It's a very simple thing to do on paper, but I just > can't figure out how to it on the calculator. X 1) Press & hold [Left-Shift] while pressing [2D/3D] Press [F2 B] to choose |CHOOS| and there choose Parametric Go to Indep: 'X' and press [ALPHA] [LS] [ T] [ENTER] Press |V CHK| so that _ Simult changes to V Simult and please check that V Connect is checked. Finally go to H-Tick and press 5 ENTER 5 ENTER to make the tick marks twice as dense along the axes 2) Press & hold [LS] while pressing [Y=] then press |ADD| Note: x=6 is 6+i*t as a parametric function, so key in: [ 6 ] [ + ] [LS] [ i ] [ * ] [ALPHA] [LS] [ T] [ENTER] Note: y=2 is t+i*2 as a parametric function, so key in |ADD| [ALPHA] [LS] [ T] [ + ] [LS] [ i ] [ * ] [ 2 ] [ENTER] Note: y=x+2 is t+i*(t+2) as a parametric function, so key in |ADD| [ALPHA] [LS] [ T] [ + ] [LS] [ i ] [ * ] [LS] [ - ] Note: This will bring up the ( ), then continue with: [ALPHA] [LS] [ T] [ + ] [ 2 ] [ENTER] Finally Press |ERASE| and then |DRAW| Watch the all three functions to plot simultaneously. 3) When the plot has finished press |ZOOM| then |ZFACT| and press [ 2 ] [ENTER] [ 2 ] [ENTER] and then check that V Recenter on cursor is checked, press [V CHK] if needed. Then press | OK | On the plot screen move cursor approximately in the middle of the horizontal line on the right side of the screen and press |ZOUT| Wait and see, behold: you have a perfect plot showing the triangle! ==== > Wayne, > Regarding how to plot vertical lines, refer to Wlodek's answer in Datafile > V16N4p7. > Jordi I'm not the only one to have this problem. :-) For John Cadick (and anyone else who's following this thread): The basic idea is to use the Parametric plot type and input a complex expression rather than an equation. For instance, 'X=6' could be entered as '(6,X)' (or as '6+X*i' instead). A parametric plot of this expression gives a vertical line like I wanted. -- Wayne Brown | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== instructions well enough to do the same thing on my 48, and it worked perfectly. -- Wayne Brown | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== > > > > > > but I posted it to the newsgroup by mistake. That's what I get for > using a different newsreader than the one I'm used to using. :-) > Don't be. What would be a good reason for hiding the information from the rest of the group. Usenet benefits from third-parties who can find errors and bogosity in others' answers and from others who also benefit from the questions and answers. ==== > For John Cadick (and anyone else who's following this thread) a spam blocking system. Jordi ==== There's another solution: check out the User's Guide discussion on Conic plots, Section 23 page 16. ==== > There's another solution: check out the User's Guide discussion > on Conic plots, Section 23 page 16. I tried that, and still didn't get the vertical line at X=6. However, I'm happy with the Parametric plot solution. -- Wayne Brown | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== > There's another solution: check out the User's Guide discussion > on Conic plots, Section 23 page 16. > > I tried that, and still didn't get the vertical line at X=6. However, > I'm happy with the Parametric plot solution. Haa! BUT id you would have a HP 40G, 48GII, 49G or 49G+ then you could use oo (infinity) [maybe MAXREAL does it, too.] Function Plot, change ticks to 5 and 5 like before Y1(X)=oo*(X-6) Y2(X)=2 Y3(X)=X+2 |ERASE| |DRAW| By checking again that ZOOM factors are 2 & 2, and recentering is selected go again to the middle of horizontal line and select zoom out. To have the area you need to do a coordinate transformation, by going down by 2 into the X negative direction in order to limit the area with the x-axis. Edit all the equations appending -2 Y1(X)=oo*(X-6)-2 @ pretty pointless here with the vertical line Y2(X)=2-2 @ == x-axis, you may delete this equation from plot-list Y3(X)=X+2-2 @ now goes through the origo. |ERASE| and |DRAW| the plot again and then select |FCN| If anything below goes wrong, check the equations and try to repeat A1..3 A1) Press |ISECT| and you get (0.,0.) ; Press [ - ] to see the menu again Was it right? IF not try A2) Press [NXT] and then |NXEQ| you see 'Y2(X)' right? A3) Press [ - ] to see the menu again and press [NXT] Then do A1) again OK?, with I-Sect: (0.,0.) you continue to B) B) Press |AREA| and see a cross marked at the Intersection C1) Press [NXT] and then |NXEQ| you see 'Y3(X)' right? C2) Press [ - ] to see the menu again and press [NXT] C3) Press |ISECT| and you get (6.,6.) ; Press [ - ] to see the menu again D) Press |AREA| and you get Area: 18. After pressing [ON] [ON] you are back to the stack and the level 1 is: Area:18. If you try to |SHADE| it will continue down from the X-axis Note: You could also use |ROOT| instead of |ISECT| Try it and have fun with plotting! ==== Am I dreaming or from the pictures in hpcalc.org it seems that HP had returned to the lifted screen like in the 48g ? i mean - does the keyboard has a little slope so that the screen will be lifted and this will give a better view ? because if it is true - its really great. hope you understood what i mean.... so - who already hold the new toy in his hands - please report.. bye Idan ==== Yes, its not as inclined as the 48, but there is an incline. I'm happy about this also. -- Douglas Rohm drohm@bellsouth.net ==== As far as I can see it the only drawback to the new 49G+ is the keyboard is less than what people hoped for (seeing the other worries have been taken care of.) So given that some people have had awile to get used to the keyboard is it fast and accurate??? By the sounds of it I will get one when *my* retailer gets one in. I'll be happy if the keyboard is reasonably fast and accurate. My only other real concern other than that would be the paint flaking off, but I am hoping this will not be an issue. So what is the verdict, is the keyboard just a matter of it not clicking at the right moment or is it more problematic? Somehow I get the feeling that the problems so far have been blown out of proportion a little, but hey we pay big money to have quality gear too. MC ==== What's Port H on the 49G and 49G+? Here's what I mean: As you know, both machines can refer to Port 0 as Port R (e.g. :0:FOO = :R:FOO); Port 1 as Port E (e.g. :1:BAR = :1:BAR, etc); Port 2 as Port F; and the 49G+ can refer to Port 3 as Port SD. Also, the 49G (only) can refer to Port 0 as Port RAM; Port 1 as Port IRAM; and Port 2 as Port FROM. Finally, both machines use all other port names (except IO perhaps?) as synonyms for main memory (not a port at all). For example, storing something into :A:FOO stores into 'FOO' in main VAR memory. BUT -- and here's the strange thing -- attempting to store into Port H (e.g. 123 :H:FOO STO) generates a Bad Argument Type error. What is this mysterious Port H? -Joe- ==== >I will tell the group when I order it and when I have it... I hope it won't >take too long... >Martin Du kan jo ta deg en tur opp til Tapir p.8c Gl¿shaugen .8c kj¿pe en hvis de fortsatt befinner deg i Trondheim....... Torstein >> Yes, you're right... I will order one in 7 hours... living in >Switzerland... >> >> I can order one in 7 hours too. The question is when will you receive it. >> > ==== Unfortunately, I haven't ever been to Trondheim... but one day I would like to visit the town... and years back when I bought my 49G, I think I bought it from the company that now calls itself for Handit (www.handit.se)... or maybe et was BB Marketing in Norway... don't know anymore. Unfortunately Handit don't sell calculators anymore...:-( Martin > >I will tell the group when I order it and when I have it... I hope it won't >take too long... >Martin > > Du kan jo ta deg en tur opp til Tapir p.8c Gl¿shaugen .8c kj¿pe en hvis de > fortsatt befinner deg i Trondheim....... > > Torstein > > >> Yes, you're right... I will order one in 7 hours... living in >Switzerland... >> >> I can order one in 7 hours too. The question is when will you receive it. >> > > ==== Try www.cynox.de Their web site is in English, too and afaik they ship to to France as well. Peter Lott > > I ordered it using the telephone > and was told that I will have to pay the bill that is enclosed when I > receive the calc...but this was only possible because I live in Switzerland. > > They don't ship in France :-( > Where did German and Spanish people posting here get their calc from ? > Maybe it's easier to ship in France from Germany or Spain (since they > are in the European Union) > > -- > Thomas Deniau > Unix is user friendly. It's just selective when choosing friends. ==== > Unfortunately, I haven't ever been to Trondheim... but one day I would like > to visit the town... and years back when I bought my 49G, I think I bought > it from the company that now calls itself for Handit (www.handit.se)... or > maybe et was BB Marketing in Norway... don't know anymore. Unfortunately Anyone knows what happened to BB Marketing? ( I even got a free t-shirt together with my first hp49) Gjermund Skailand PS Er TAPIR p.8c nett? ==== OR www.dynatech.de. They ship worldwide. HP49G+ for Euro 169.50. Delivery from middle of September...... just ordered one. Arnold >Try www.cynox.de >Their web site is in English, too >and afaik they ship to to France as well. >Peter Lott > > >> >> I ordered it using the telephone >> and was told that I will have to pay the bill that is enclosed when I >> receive the calc...but this was only possible because I live in Switzerland. >> >> They don't ship in France :-( >> Where did German and Spanish people posting here get their calc from ? >> Maybe it's easier to ship in France from Germany or Spain (since they >> are in the European Union) >> >> -- >> Thomas Deniau >> Unix is user friendly. It's just selective when choosing friends. ==== > Anyone knows what happened to BB Marketing? > ( I even got a free t-shirt together with my first hp49) Dark blue with white stripe around neck ? And some strange sign on that white stripe ? I got t-shirt like that with hp40g ! -- Mario Mikocevic (Mozgy) mozgy at hinet dot hr It's never too late to have a good childhood! The older you are, the better the toys! My favourite FUBAR ... ==== Holy COW!! Mozgy!!! Where the heck have you been??!! How are things?! I love to see the HP gurus from times past show up here. It re-energizes my love of this calc. Best, -Al (exal) > >> Anyone knows what happened to BB Marketing? >> ( I even got a free t-shirt together with my first hp49) > > Dark blue with white stripe around neck ? > And some strange sign on that white stripe ? > I got t-shirt like that with hp40g ! > > > -- > Mario Mikocevic (Mozgy) > mozgy at hinet dot hr > It's never too late to have a good childhood! > The older you are, the better the toys! > My favourite FUBAR ... ==== > > Anyone knows what happened to BB Marketing? > ( I even got a free t-shirt together with my first hp49) > > Dark blue with white stripe around neck ? > And some strange sign on that white stripe ? > I got t-shirt like that with hp40g ! > No, actually a white t-shirt with BB-marketing logo on the front, which I happen to be wearing today! Gjermund ==== > Holy COW!! Mozgy!!! Where the heck have you been??!! How are things?! WOW ! He he, I even thought that nobody would recognize me !:) Silly me. How me be doin' !? Eh, working mostly and lurking here from time to time. All that noise about new HP calcs got me a bit more awake. > I love to see the HP gurus from times past show up here. It > re-energizes my love of this calc. Yeah, it brings memories of past times .. > > Best, > -Al (exal) Take care, -- Mario Mikocevic (Mozgy) mozgy at hinet dot hr It's never too late to have a good childhood! The older you are, the better the toys! My favourite FUBAR ... ==== Some sites claim the full equation library has returned on the 49G+. Is this true? How about the constants lib? Anything else new? Mitch ==== The constants library is still on the 49G... it never left. Just type CONLIB. For the eqn library on the 49G, I use eql49 r2.7... it's a fairly nice program with all the 48's equations. I don't know about the 49G+'s possible equation library.... sorry. > Some sites claim the full equation library has returned on the 49G+. Is > this true? How about the constants lib? Anything else new? > > Mitch > > ==== > The constants library is still on the 49G... it never left. Just type > CONLIB. For the eqn library on the 49G, I use eql49 r2.7... it's a fairly > nice program with all the 48's equations. > > I don't know about the 49G+'s possible equation library.... sorry. Same as the 49G, the runors were wrong http://www.hpcalc.org/details.php?id=3181 > > Some sites claim the full equation library has returned on the 49G+. Is > this true? How about the constants lib? Anything else new? > > Mitch > > > > ==== > The constants library is still on the 49G... it never left. Just type > CONLIB. For the eqn library on the 49G, I use eql49 r2.7... it's a fairly > nice program with all the 48's equations. > > I don't know about the 49G+'s possible equation library.... sorry. > Same as the 49G, the runors were wrong > http://www.hpcalc.org/details.php?id=3181 > > > Some sites claim the full equation library has returned on the 49G+. Is > > this true? How about the constants lib? Anything else new? > > > > Mitch > > > > > > > > ==== As brought up in another thread, which is correct? Does the 49g+ really have less memory than the 49g? The manual states that it should be 256, 256, 1MB (roughly) and has a screen shot showing that. Mine seemed to have about 256, 128, 768 before I installed software on it. > >> I found something strange about my 49g+. I have no objects in my port >> 1, and when I go to the Filer, it shows 127kb free; but if I run <<1 >> PVARS>>, I got 262128 bytes free (256 kb). Please do it in your 49g+ >> and tell me if you get that diference too. >You found a bug ... > Pete M. Wilson Gamewood, Inc. wilsonpm@gamewood.net ==== >As brought up in another thread, which is correct? > >Does the 49g+ really have less memory than the 49g? > >The manual states that it should be 256, 256, 1MB (roughly) and has a >screen shot showing that. Mine seemed to have about 256, 128, 768 >before I installed software on it. This picture is from a HP49G or a non-production-HP49G+, I think. It states having 916K flash free, which is not correct for the HP 49G+. My has only 766 K free. If you take in account, that the HP49G+ supports SD cards and the FAT file system and needs some additional code for the ARM-to-Saturn emulation, it seems very logic, that its OS uses up more Flash ROM..:) Btw, 1 PVARS gave me 131064 bytes with ROM 1.22. Mathias -- Mathias Habel mathias.habel_no-spam_@t-online.de Remove _no-spam_ before replying ==== It also seems like the manual is a lightly editted version of the HP 49G manual that was never editted well. It's been a long time since I've seen a manual with so many typos and other errors. It does state that the system uses 1MB, so I guess that is just another error? > >>As brought up in another thread, which is correct? >> >>Does the 49g+ really have less memory than the 49g? >> >>The manual states that it should be 256, 256, 1MB (roughly) and has a >>screen shot showing that. Mine seemed to have about 256, 128, 768 >>before I installed software on it. > >This picture is from a HP49G or a non-production-HP49G+, I think. It >states having 916K flash free, which is not correct for the HP 49G+. >My has only 766 K free. If you take in account, that the HP49G+ >supports SD cards and the FAT file system and needs some additional >code for the ARM-to-Saturn emulation, it seems very logic, that its OS >uses up more Flash ROM..:) > >Btw, 1 PVARS gave me 131064 bytes with ROM 1.22. > >Mathias Pete M. Wilson Gamewood, Inc. wilsonpm@gamewood.net ==== [HP49G+ memory] >It does state that the system uses 1MB, so I guess that is just >another error? Maybe the amount of free flash. Ok, in reality its only 766 K, but for HPs marketing specialists 1Mb sounds just better..;) Mathias -- Mathias Habel mathias.habel_no-spam_@t-online.de Remove _no-spam_ before replying ==== > > [HP49G+ memory] >It does state that the system uses 1MB, so I guess that is just >another error? > > Maybe the amount of free flash. Ok, in reality its only 766 K, but for > HPs marketing specialists 1Mb sounds just better..;) > The new Carly-Way marketing specialists never seemed to check with the development team, but the facts are: brutto: 2MB Flash, 1/2 MB RAM available to the user: less than 768KB Flash + 368KB RAM Total about 1280KB, which is 10* 128KB of the hp 48gII Not too bad anyway. Then you can bring in a 128MB SD, that is ~ 128,000KB Should be enough... ==== Do you know if there is a limit to how big of an SD card the HP 49G+ can use? I have seen 512MB ones online, and that would be pretty cool if one of those would work in the calculator. > Not too bad anyway. > Then you can bring in a 128MB SD, that is ~ 128,000KB > Should be enough... ==== > Do you know if there is a limit to how big of an SD card the HP 49G+ can > use? I have seen 512MB ones online, and that would be pretty cool if > one of those would work in the calculator. Standard DOS FAT16 limit is 2GB/32KB clusters You maybe may be able to format the SD as 4GB/64K clusters 512MB or 1/2 GB should be ok I have tested so fasr only 64MB SD, 8MB MMC, 64MB MMC ==== Dear all, I got the first shippement of the 49G+ in Singapore, and this is my first impression. The good -------- 1) Pleasant looking. The calc looks a lot more serious than the 49G, and to my taste even more serious than the 48GX, which psychadelic colors I do not like. My favourite was the 48SX, but this is gone. The color scheme of the 49G+ offers high contrast and makes the labels very readable. The incredible light weight (lighter than a Palm V !) makes the calc feel cheap, always it seems quite robust. 2) The case: Very pleasant lether with magnetic closer. This makes the item looks very classy. I like this case even better than the original '48. Good move. 3) Very nice screen. The cover is much closer to the screen, the contrast is very good, although the screen flickers sometimes. The 7-level stack display is really impressive. 4) Impressive connectivity: USB + SD + IrDA, what else to ask for ? This is the most communicating calc ever, leaving TI far behind. 5) The speed: as already mentionned here, the calc is 4-6 times faster than the 49G, which is already 2-3 times faster than the 48GX. Nobody will ever label HP calculators as slow again. The bad ------- 1) The plasting painting. I can't believe that just after opening the box the painting on the ring around the calc is already teared off. This does not look serious at all. 2) Keys not registring. As for the 17BII+, the keys, although being solid, do not register all the time. This is especially true, on my unit, of the On key (very hard to press), and of the +/- key. For all that we can bash the 49G rubber keys, these at least would always register !! On the 49G+ the keys are too stiff and makes a lot of noise, which is not always desirable. I find this most irritating not to be able to rely on keys - it gives me the same insecure feeling of dealing with Microsoft Windows and always wondering whether the system got my mouse click or not. I hope that time will make things better, but this does not give me confidence. 25-year old calculators such as the good old 41 have much better keys; my old 28S has very pleasant and robust keys too; where is progress ? 3) Some points of the keyboard layout: Although the layout has some strong points like the 49G (conditional on keyboard, no letters on arrows, touch and hold for graphic top keys functions), I really can't stand the lack of the angle key and the small enter key. At least the 49G+ put back the Eval and ' keys unshifted. I guess with time we will get used to the keyboard. 4) The manual: While the supplied manual on CD looks fairly well done, I really can't stand the idea of having to print it myself. I tried to print in a booklet format, but there are so many pages that I cannot staple it. Besides, the pages are very small, a lot of space is wasted with the 4 corners lines. I have nothing against respecting the environment, but I just hate the idea of not having a proper manual. The unknown ------------ Battery life: I have read some reports about the calc which would not turn on with the set of supplied batteries. It did not happen with me. The calc did not give me any battery problems for the whole week-end, but it is too early to say. One important point: I upgrade the ROM to version 1.22 on HP web site. This ROM claims to save battery a lot better while the calculator is off. While it pleases me to see that HP seems to be active in releasing ROM updates, it makes me worried for the poor future owners of the 48GII: Since this calc will not have FLASH memory, will this mean that they will not be able to correct drastic flaws such as battery consuption ? Time will tell, but for now I am glad to own a 49G+ and not a 48GII ! Overall ------- I am still proud to own this calc and to see that RPL and RPN are not dead. I wish the 49G+ a big commercial success to promote these concepts. Overall I like the machine a lot. Welcome back HP, but please could you make on effort on trivial matters, such as painting, keys, and printed manuals ? This would be perfect ! I also deeply regret the death of 41/42 compact yet powerful RPN calculators. The 32SII was nice but no replacement for them (no alphanumrics, no matrixes, 2-level stack complex numbers only...). The 33S looks awful and will not be a good replacement for the 32SII IMHO. The 48GII will be quite limited (memory + lack of flash) and does not bring real value; I have very little interest/respect in the 39G+ (the 38/39/40 series to me was a mistake - no RPN and ridiculous applet concept, what for ?); the 17BII+, to me, is more a downgrade than a upgrade to the original 17BII; Same for the 12C PT and its bugs; I have yet to see the 19BII+, but I can already say that the 49G+ is the only real innovative move of HP since 1999. So, long live the 49G+ ! :-) My 2 cents. Vincent ==== > 4) The manual: While the supplied manual on CD looks fairly well done, I > really can't stand the idea of having to print it myself. I tried to > print in a booklet format, but there are so many pages that I cannot > staple it. Besides, the pages are very small, a lot of space is wasted > with the 4 corners lines. I have nothing against respecting the > environment, but I just hate the idea of not having a proper manual. I have printed the Spanish manual, and it is very complete but (there is always a ÇbutÈ): - As you've pointed, there is a lot of wasted space because the corners lines. - No navigation help. Being a pdf document, it could add hyperlink menu support, so it would be easy to go to different zones. It has been done on hp49g pdf manuals, I think. This could help on screen reading. Any way, it is great having this doc. --- J.Manrique L.97pez de la Fuente Users Club from Gij.97n 1077 HPCC Member ==== But in my opinion - keyboard is the most important thing in a calculator. What does it gives me if i have a BMW but no wheels.. What does it give me if I have computer with bad keyboard or a bad mouse ? What does it... well - you get my point. Paint that comes off ? oh come on HP !!!!! What are we - in the sixties ? Man - it really makes me mad. my father manufactures less hi-tec technology but paint wouldn't come off in years !!!!! and i am talking about a decade !!! Well - I dont have so much money so spend. I thought I was going to sell my 49g with a great joy that i have a nice replacement.. Well - I ain't gonna sell nothing yet !!! I prefer painted slow stiff old 49g than a BUZZ LIGHT YEAR that cannot fly !!! (TOY STORY) My dear friend - if you want a good advice - pack your new toy and We are good customers and we ain't gonna let anyone to fool us ! 160 $ isnt low price for a calc. and for 160 $ - at least the paint shouldn't come off... It's not your fault my dear friend but I say : HP SUCKS !!! Bye Idan Technion Israel ==== One more thing : If you bought a new car and the color would came off the first time you touch it I am sure you would return it - so if it is about keyboard problems - well - you know what i think... You know - in hebrew - there is a frase that says you show a half job only to a dunky... and we all are not.. All the best Idan ==== print to the HP82240B IR printer? Tom Scott ==== Good review. So the keyboard is the same as the new financial calculators (10Bii, 17Bii+)? In that case I won't be too worried. ==== I purchased an hp49g+ from Singapore, serial No:CN33109123, but the connectivity program Conn4x is not able to locate the calculator. The connect using box identifies the calculator: HP9xg+ once you have plugged it in to the USB port, then you are instructed to press right red button and right arrow on the calculator, and the calculator displays Awaiting Server Cmd. On the computer you get Looking for calculator then an error message of Unable to open communications to HPx9G+ Any help would be appreciated. Andrew Buckwell ==== > 4) The manual: While the supplied manual on CD looks fairly well done, > I really can't stand the idea of having to print it myself. I tried to > print in a booklet format, but there are so many pages that I cannot > staple it. Besides, the pages are very small, a lot of space is wasted > with the 4 corners lines. I have nothing against respecting the > environment, but I just hate the idea of not having a proper manual. I printed the manual in booklet format 20 pages at a time. It is not very fun, as with 874 pages you have to issue 44 partial print commands specifying page numbers to get the whole manual printed. I keep the 44 pieces together with a big metal clasp (not sure if this is the correct word) and the book results quite manageable. About the crop lines, I prepared a version of the english manual with normal margins (i.e., cropped by the crop lines), and with the pages correctly sorted. There is a link and more details in this message: http://groups.google.com/groups?selm=3f5a2426%40shknews01 RaM. ==== > 4) The manual: While the supplied manual on CD looks fairly well done, I > really can't stand the idea of having to print it myself. I tried to > print in a booklet format, but there are so many pages that I cannot > staple it. Besides, the pages are very small, a lot of space is wasted > with the 4 corners lines. I have nothing against respecting the > environment, but I just hate the idea of not having a proper manual. I printed the manual in booklet format 20 pages at a time. It is not very fun, as with 874 pages you have to issue 44 partial print commands specifying page numbers to get the whole manual printed. I keep the 44 pieces together with a big metal clasp (not sure if this is the correct word) and the book results quite manageable. About the crop lines, I prepared a version of the english manual with normal margins, and with the pages correctly sorted. There is a link and more details in this message: http://groups.google.com/groups?selm=3f5a2426%40shknews01 RaM. ==== I keep getting a message that the file is corrupt. I have tried downloading it multiple times. Mitch > 4) The manual: While the supplied manual on CD looks fairly well done, > I really can't stand the idea of having to print it myself. I tried to > print in a booklet format, but there are so many pages that I cannot > staple it. Besides, the pages are very small, a lot of space is wasted > with the 4 corners lines. I have nothing against respecting the > environment, but I just hate the idea of not having a proper manual. > > I printed the manual in booklet format 20 pages at a time. It is not > very fun, as with 874 pages you have to issue 44 partial print > commands specifying page numbers to get the whole manual printed. I > keep the 44 pieces together with a big metal clasp (not sure if this > is the correct word) and the book results quite manageable. > > About the crop lines, I prepared a version of the english manual with > normal margins (i.e., cropped by the crop lines), and with the pages > correctly sorted. There is a link and more details in this message: > > http://groups.google.com/groups?selm=3f5a2426%40shknews01 > > RaM. ==== > I keep getting a message that the file is corrupt. I have tried downloading > it multiple times. It worked fine for me. It's a great job. I wish he had included bookmarks, though! (Never satisfied!) Tom Lake ==== To avoid stapling problems, I take the printout to Kinko's. For $5.00 or so, they can add a decent cover and bind the manual to your liking. It's more compact than most original manuals (fits nicely in a backpack). I recommend a large coil binding so you can lay the book open flat on your desk... Mitch > I keep getting a message that the file is corrupt. I have tried > downloading > it multiple times. > > It worked fine for me. It's a great job. I wish he had included bookmarks, > though! (Never satisfied!) > > Tom Lake > > ==== Mitch, Have you checked your version of Acrobat Reader? I have had 'corrupt file' issues with people using an earlier version to open files created with the current version (v6). Jeff > I keep getting a message that the file is corrupt. I have tried downloading > it multiple times. > > Mitch > > > ==== The famous, fabulous HP49G grayscale programs such as GDREAM32 and SCROLL.MAX do not work on the hp49g+, perhaps due to timing differences or the use of unsupported entry points. But the 49g+ ought to be able to produce even smoother grayscale graphics than the 49G, since it's so much faster. Does anybody know of any grayscale software for the 49g+ that actually works? -Joe- If it's Gray, RCL it. -- Arnold ==== > The famous, fabulous HP49G grayscale programs such as GDREAM32 and > SCROLL.MAX do not work on the hp49g+, perhaps due to timing > differences or the use of unsupported entry points. But the 49g+ I think it's the timing. The new HW is so different. You might need to go native... > ought to be able to produce even smoother grayscale graphics than the > 49G, since it's so much faster. Does anybody know of any grayscale > software for the 49g+ that actually works? There is no such thing at all. Even if something works - it flickers terribly! I have to give that back - I was of no help at all, but depress...despair... > > -Joe- > If it's Gray, RCL it. -- Arnold Swarzenegger? ==== > The famous, fabulous HP49G grayscale programs such as GDREAM32 and > SCROLL.MAX do not work on the hp49g+, perhaps due to timing > differences or the use of unsupported entry points. But the 49g+ GDREAM32 was a great program, but I believe GRS64 was even better. It is able to guess the number of greyscale levels of a picture, it has 4 different ways of displaying greyscale grobs, it can change contrast, you can reduce the number of levels displayed... Download it on hpcalc.org, perhaps one of the displaying methods is adapted to the HP49G+, who knows ? > There is no such thing at all. > Even if something works - it flickers terribly! The fact is that the screen has probably no longer a refreshing period of 1/64 s. And even if it has, there are 16 more lines, which changes the time needed to refresh one line. This could mistake the original 49G programs. Yoann. ==== > ... GRS64 was even better. ... > Download it on hpcalc.org, perhaps one of the > displaying methods is adapted to the HP49G+ ... 49g+ pretty badly. As soon as you run it, the display goes very faint (not flickering, though), and stops responding to ANY keys, even ON+C. The only way out seems to be a paper-clip reset. :-( -Joe- ==== And who has tested some greyscale games ??? Do they works on HP49+?? Maybe try Puzzle-Bobble 2 :)) > The famous, fabulous HP49G grayscale programs such as GDREAM32 and > SCROLL.MAX do not work on the hp49g+, perhaps due to timing > differences or the use of unsupported entry points. But the 49g+ > ought to be able to produce even smoother grayscale graphics than the > 49G, since it's so much faster. Does anybody know of any grayscale > software for the 49g+ that actually works? > > > -Joe- > If it's Gray, RCL it. -- Arnold ==== If this thing was done right, I'd be happy with $400 USD. Zip Disk (well, perphaps common consumers would not be, but a new fame will take its time...) previous posts... With a 75mhz processor one should definitively abandon the idea of 5 years' duration of batteries (also a rechargeable batteries, like a PDA, will not so bad). But this consumption would have much more sense if they had worked, little by little, at an assembly optimization of the code, to gain an exceptional performance, as it was done on 49g. If 75mhz were well spent, what a nice toy it would be....;-) Alex ==== > But this consumption would have much more sense if they had worked, > little by little, at an assembly optimization of the code, to gain an > exceptional performance, as it was done on 49g. > This makes no sense. The 49G is not power efficient because of how it's programmed. It's power efficient because of the Saturn CPU running at 4Mhz only. An *assembly* optimisation of the code will not get you a great deal of power saving if your CPU is running at 75Mhz. Only lowering the speed of the CPU will ==== > This makes no sense. The 49G is not power efficient because of how it's > programmed. It's power efficient because of the Saturn CPU running at > 4Mhz only. > > An *assembly* optimisation of the code will not get you a great deal of > power saving if your CPU is running at 75Mhz. Only lowering the speed of > the CPU will Alex's point might make more sense to you if you think of it in the context of putting a Ford V8 engine into a Citroen 2CV, then keeping the transmission locked in low gear. -- John Miller LILO, you've got me on my knees! (from David Black, dblack@pilot.njin.net, with apologies to Derek and the Dominos, and Werner Almsberger) ==== Alex M. schrieb im Newsbeitrag > If this thing was done right, I'd be happy with $400 USD. Zip Disk > (well, perphaps common consumers would not be, but a new fame will take its > time...) > > previous posts... > > With a 75mhz processor one should definitively abandon the idea of 5 years' > duration of batteries (also a rechargeable batteries, like a PDA, will not > so bad). > But this consumption would have much more sense if they had worked, little > by little, at an assembly optimization of the code, to gain an exceptional > performance, as it was done on 49g. What were the options for the new HP49G+? 1) speeding the existing saturn cpu up again 1.1) produce a new speeded up saturn 2) writing all the software new from scratch for a new faster CPU 3) emulating the saturn on top of another cpu 1) Speeding up the saturn again would have given problems regarding battery life. 1.1) As the calculator market isn't that big, making a new saturn cpu only to be used in a calculator wasn't realy an option, I guess. 2) Writing all the software from scratch for a new cpu would mean to loose all the existing and already debugged software. Years of work and experience would have been lost in that case. 3) Emulating the saturn cpu on top of another cpu means to loose a bit of raw cpu power but has otherwise only advantages over the other options. -most of the code from the 49g can be reused on the 49g+ -most of the programs written for the 48/49 will still run on the 49g+ -people used to the 48G and 49G don't have to learn anything new So one day the software running now on a 75Mhz ARM cpu might run on top of a portable 1Ghz calc (or whatever). Still you will use the same software based on the software from the 49G. So I really can't see a design flaw by emulating the saturn on top of another cpu. > If 75mhz were well spent, what a nice toy it would be....;-) It is actually, IMO. Roman > Alex ==== > An *assembly* optimisation of the code will not get you a great deal of > power saving if your CPU is running at 75Mhz. Only lowering the speed of > the CPU will Wouldn't the ARM spend a lot more time in power savings modes if it were running native code vs. the emulator? ==== > An *assembly* optimisation of the code will not get you a great deal of > power saving if your CPU is running at 75Mhz. Only lowering the speed of > the CPU will > > Wouldn't the ARM spend a lot more time in power savings modes if it were > running native code vs. the emulator? > I think that all the ARM based (and similar) CPU already have they own power saving modes and thus I don't quite understand your point. I would maybe lower the slow mode 12MHz to 6MHz if it would really save some power. It's not all CPU while waiting... In a future HP 49GX II+ I'd like to see a user adjustable clock speed. Like A) Automatic = full speed when getting power from USB 75MHz when on batteries, 30MHz when batteries are low. B) Semiauto = same as auto, but user determine the MHz C) Manual = User determines the behavior by setting the MHz manually unindependent of the batteries and power. A shortcut like [ON]&[DA] to go slower would be nice. (*) The CPU could go (Samsung already has 533MHz ARM) up to 1GHz and I want all that raw power on a rechargeable battery. I would use B) the semi-auto mode (*) currently - for compatibility reasons - I'd like to adjust the spped of the + It is too fast! 75MHz => 48MHz would make it 48GII and ~30MHz is old 49 then back gain to 75MHz for the the top speed. All this using [ON]&[DA] It's just an idea...what do others (except developers) think? ==== i can change the CPU freq in my PDA ( ARM SA 1110 ) http://killefiz.de/zaurus/showdetail.php?app=827 ==== > >>But this consumption would have much more sense if they had worked, >>little by little, at an assembly optimization of the code, to gain an >>exceptional performance, as it was done on 49g. >> > > > This makes no sense. The 49G is not power efficient because of how it's > programmed. It's power efficient because of the Saturn CPU running at > 4Mhz only. > > An *assembly* optimisation of the code will not get you a great deal of > power saving if your CPU is running at 75Mhz. Only lowering the speed of > the CPU will While all other things being equal, I'd agree, not all things are equal. CMOS draws current only while switching state, so with the same geometry, there is a relation (probably linear, at least at low frequencies, but I'm not positive) between current draw and clock speed. But the ARM is almost certainly with a newer smaller geometry, maybe 0.13 micron, while the Saturn is a much older design with a much larger geometry. Smaller transistors draw less current when switching state, the ARM does not draw 75/4=18.75 as much current as the Saturn, and from looking at ARM's core figures, it probably draws pretty near the same current. I think that part of the greater current draw is the 49G+'s memory. And I don't know how much current SD cards draw, I would think enough (even when not being accessed) to affect battery life. And I still wonder how much cache the 49G+ has. Given the size of calculator programs, I wonder if the 4K cache would be adequate. The above from general principle and the initial research in the ARM. If you have specifics that affect the result please correct me. Rich ==== So I really can't see a design flaw by > emulating the saturn on top of another cpu. > I agree, hpcalc.org is here to support this view. I just hope like many here that it is (or will be) possible to bypass the emulator. Arnaud ==== X > This makes no sense. The 49G is not power efficient because of how it's > programmed. It's power efficient because of the Saturn CPU running at > 4Mhz only. > > An *assembly* optimisation of the code will not get you a great deal of > power saving if your CPU is running at 75Mhz. Only lowering the speed of > the CPU will X > But the ARM is almost certainly with a newer smaller geometry, > maybe 0.13 micron, while the Saturn is a much older design with > a much larger geometry. Smaller transistors draw less current 2 microns. How about a Saturn in, say 0.25 microns?? Why not that? It's 8 times less or 64*smaller area. > when switching state, the ARM does not draw 75/4=18.75 as much > current as the Saturn, and from looking at ARM's core figures, > it probably draws pretty near the same current. > > I think that part of the greater current draw is the 49G+'s memory. > And I don't know how much current SD cards draw, I would think > enough (even when not being accessed) to affect battery life. > > And I still wonder how much cache the 49G+ has. Given the size of > calculator programs, I wonder if the 4K cache would be adequate. 16K+16K typical for an ARM 920T http://www.arm.com/armtech/ARM922T?OpenDocument ==== >> Wouldn't the ARM spend a lot more time in power savings modes if it were >> running native code vs. the emulator? >> > I think that all the ARM based (and similar) CPU already have they own > power saving modes and thus I don't quite understand your point. What I am driving at is that native code would execute much faster than the emulated code so that the time the CPU is idle would be greater. That idle time would be in a low power mode. ==== > What I am driving at is that native code would execute much faster > than the emulated code so that the time the CPU is idle would be > greater. That idle time would be in a low power mode. > Let me reply with this: If you believe the HP49G+ is just an emulation of an HP49 I think we're all making a big mistage: On my Jornada 548 (SH3 133Mhz), Emu48 was just twice faster than a real HP48. Look at the Palm version of Emu48 running on a very similar CPU (ARM 75Mhz) how fast is the emulation? It's slower than a real HP49! Certainly not 3-6 times faster as some people has mentionned. Must be a fair bit of native code in there otherwise you wouldn't see such a speed gain. A typical usage of a calculator is about 5 minutes of CPU time per hour at max. So emulator or not, your calculator is already spending most of its time in idle mode. ==== > Alex's point might make more sense to you if you think of it in the > context of putting a Ford V8 engine into a Citroen 2CV, then keeping > the transmission locked in low gear. > Funny how the 4WD became a 2CV instantly... All these analogy with cars are totally inapropriate. Put a V8 engine in a 2CV, ley say how far it goes and how the softly suspension will handle the extra weight ==== > Funny how the 4WD became a 2CV instantly... > All these analogy with cars are totally inapropriate. Well, largely, maybe, but not totally. :-) > Put a V8 engine in > a 2CV, ley say how far it goes and how the softly suspension will handle > the extra weight Without even bothering to look it up, I've got $100 that says it's been done (albeit with suspension mods). -- John Miller Live fast, die young, and leave a flat patch of fur on the highway! -The Squirrels' Motto (The Hell's Angels of Nature) ==== >> This makes no sense. The 49G is not power efficient because of how it's >> programmed. It's power efficient because of the Saturn CPU running at >Alex's point might make more sense to you if you think of it in the context >of putting a Ford V8 engine into a Citroen 2CV, then keeping the >transmission locked in low gear. (John Miller) I'm sorry, I've expressed bad my point of view, that's substantially according to John's observation. There's nothing bad in emulating the old (and debugged!) code on 75mhz. Furthermore, imo, batteries' consumption may be not more than nothing, with the patience to recharge the hp49 like a cell phone or a PDA, things which everybody is accustomed to. The aesthetic, intellectual fact remains. However, nowadays it's by far no more time for such old fashioned optimizations, (neither for the emotion to push to limits any hardware), and, perhaps, a cheap keybord is close to the whole, a cheaper design. Let me remember that many excellent parts of the hp49 software was done by aentusiastic end-user, and not all came from hp. Alex ==== > Let me reply with this: > If you believe the HP49G+ is just an emulation of an HP49 I think we're > all making a big mistage: > On my Jornada 548 (SH3 133Mhz), Emu48 was just twice faster than a real > HP48. > Look at the Palm version of Emu48 running on a very similar CPU (ARM > 75Mhz) how fast is the emulation? It's slower than a real HP49! > Certainly not 3-6 times faster as some people has mentionned. > > Must be a fair bit of native code in there otherwise you wouldn't see > such a speed gain. Correct me if I am wrong as I know very little about the hp hardware. Or actually writing an emulator. So forgive me if I stick my foot in my mouth. Let us consider a simple emulator. This emulator must do three tasks: 1) emulate the cpu and memory, 2)emulate the screen 3)emulate the keyboard. In particular I am concerned with task 2 emulating the screen. The hp49g screen is 131 * 64 = 8384 pixels. A 49g emulator must go through all these pixels 25 times a second and convert them from single bits to 8/16 bits for the actual video memory. (What kind of screens do the above PDAs have?) I chose 25 times a second because that is about what movies at the theatre run at. However at 25hz emulated greyscale might not look so good. So maybe the emulator refresh at 50 hz. Does anyone know the refresh rate of the emulators? Could somebody tell how good looking 4 color greyscale looks on these emulators. The Point: On the 49g+ I expect that the emulated saturn code has direct access to video memory. No screen emulation is needed. Thus this bottle neck is Eliminated. Task 3, Emulating the Keyboard: Depending on how designed emulating the keyboard should be much easier for the 49g+ than it is for a PDA. -Samuel ==== >>> This makes no sense. The 49G is not power efficient because of how it's >>> programmed. It's power efficient because of the Saturn CPU running at > >>Alex's point might make more sense to you if you think of it in the context >>of putting a Ford V8 engine into a Citroen 2CV, then keeping the >>transmission locked in low gear. (John Miller) > > I'm sorry, I've expressed bad my point of view, that's substantially > according to John's observation. > > There's nothing bad in emulating the old (and debugged!) code on 75mhz. > Furthermore, imo, batteries' consumption may be not more than nothing, > with the patience to recharge the hp49 like a cell phone or a PDA, things > which > everybody is accustomed to. Indeed not everybody. I have both a 48GX and 49G, but neither a mobile phone nor PDA (and little sign of getting either). My earliest calculators (Casio and a TI66) last for years with button cells (obviously apples and pears). A bientot Paul -- Paul Floyd http://paulf.free.fr (for what it's worth) Surgery: ennobled Gerald. ==== After reading that below: 1) *================================================* > What I am driving at is that native code would execute much faster > than the emulated code so that the time the CPU is idle would be > greater. That idle time would be in a low power mode. > > > Let me reply with this: > If you believe the HP49G+ is just an emulation of an HP49 I think we're > all making a big mistage: > On my Jornada 548 (SH3 133Mhz), Emu48 was just twice faster than a real > HP48. > Look at the Palm version of Emu48 running on a very similar CPU (ARM > 75Mhz) how fast is the emulation? It's slower than a real HP49! > Certainly not 3-6 times faster as some people has mentionned. > > Must be a fair bit of native code in there otherwise you wouldn't see > such a speed gain. > > A typical usage of a calculator is about 5 minutes of CPU time per hour > at max. So emulator or not, your calculator is already spending most of > its time in idle mode. > 2) *================================================* Message 47 in thread I assume it is. If not, we're FUBAR anyway. > Unfortunately, it isn't that easy. Many ML programs access the > hardware directly ( especially the display and associated registers ). I see every ML instruction look in a global jump table where the registers, that it needs to access, are located. Such a jump table is created whenever you enter RPL mode on the XScale device. Overhead won't be very noticable, but if it is, we could sacrifice a couple of kB Flash for such a static address table. > Whatever you want to call it, it's still emulation. Alright, you win this one ;-) 3) *================================================* Well if the CPU has a ?KB internal RAM file, then by STeen words but if it is, we could sacrifice a couple of kB Flash for such a static address table. EXCEPT we do this using internal RAM file of 4K THAT would explain the speed of the emulator, which is simply fantastic compare to the EMU48 on a Jornada 720 that I'm using (203MHz) when you think that it is about in par with the slower 48GII in 48MHz (BTW: thay could haver called the 49G+ 75GX) My suggestion for the ACO team: cpnsider codong the Forth/RPL inner loop natively this could speed up the OS globally ==== I just installed the new 1.22 ROM. Installation didn't work using the SD card installation method, but I could install it via USB. I was very pleased to see that they added the capability to format SD cards with this new release. Just press ON-D, and a format option will be displayed. If you select it, it will format your installed SD card to FAT16. I tried it, and it works fine. Also the SD card recognition bug has been fixed, you don't have to take out and re-insert the card any more to use it. Thomas ==== Yes, it seems that ON+D menu has been updated, because now it says VERSION 3.45 instead of 3.39 from previous ROMs --- J.Manrique L.97pez de la Fuente Users Club from Gij.97n 1077 HPCC Member ==== I order one from educal.net, should be here by tuesday, they have them on stock. Paul Estepan ==== Please report if you dont mind about the quality of the product when you get it. from what country are u ? and from where they are sending it ? when you get the packege refer to : 1. hp49g+ keyboard quality. 2. screen 3. speed 4. compare to the hp49g 5. compare keyboard to 48g's keyboard 6. did the shippment arrived on time ? 7. did you have everything in the packege ? Because i am interested buying from them.. thanks idan ==== I saw a 1.22 ROM for the 49G+ on hpcalc.org. (I believe this question has been asked before but never properly answered) Can I install this ROM on my 49G? If I can what are the advantages/disadvantages and is it any different from installing a normal 49G ROM on the 49G? Thanxz in Advance CID ==== > I saw a 1.22 ROM for the 49G+ on hpcalc.org. (I believe this question > has been asked before but never properly answered) Can I install this > ROM on my 49G? No, the 49g+ ROM won't work on the 49G. Tom Lake ==== > I saw a 1.22 ROM for the 49G+ on hpcalc.org. > (I believe this question has been asked before > but never properly answered) Can I install this > ROM on my 49G? No. It expects the 49g+'s hardware. -Joe- ==== > I saw a 1.22 ROM for the 49G+ on hpcalc.org. > (I believe this question has been asked before > but never properly answered) Can I install this > ROM on my 49G? No. It expects the 49g+'s hardware. -Joe- ==== > > I'm experiencing the same problems. I have also observed that the > filer shows only 60MB for a 64MB card. Where are the other 4MBs? I > suspect that the SD card support will need some debugging to be > useful. But ok for the moment at least it seems to be possible to The main reason is hardware manufacturer always mentionning card size *unformatted*. I found what the filer report to be extremely accurate. > store programs and even execute them in the SD card. Sometimes I get a > 'unknown DOS error' when accessing the SD card. I will also experiment > know that formatting can cause problems (FAT16 / FAT32). I heard that > Windows XP doesn't properly support the FAT16 format. I'll let you > know when I find out more. > Of course it supports FAT16.. I use it all the time! The newly support for FAT32 in digital camera is also very recent (hum, that's a recursive sentence) ==== I have updated the 49G+ english User Guide with more than 1000 bookmarks. So, it is cropped, sorted and bookmarked now. I made the bookmarks in only a few hours, but I hope I didn't make too many mistakes. There are formatting errors in some headings of the original text, font size not matching with the true heading level; when detected, I have corrected them in the bookmark hierarchy, but I have not touched the text itself. The guide would still need a few hundreds internal links, mainly from the index and from cross references scattered in the text, but I don't think I am going to do that work anytime soon, if at all. Also, I don't plan to enhance the non-english versions of the guide, as it seems like they where already enhanced enough by their translators. The new version is here: http://www.textodigital.jazztel.es/hp49gplus/BPIA5324_CSB.zip I hope you find it useful. RaM. ==== even willing to invest a few hours so that their documentation would be more usable? >:( > I have updated the 49G+ english User Guide with more than 1000 > bookmarks. So, it is cropped, sorted and bookmarked now. > I made the bookmarks in only a few hours, but I hope I didn't make too > many mistakes. There are formatting errors in some headings of the > original text, font size not matching with the true heading level; > when detected, I have corrected them in the bookmark hierarchy, but I > have not touched the text itself. > The guide would still need a few hundreds internal links, mainly from > the index and from cross references scattered in the text, but I don't > think I am going to do that work anytime soon, if at all. Also, I > don't plan to enhance the non-english versions of the guide, as it > seems like they where already enhanced enough by their translators. > The new version is here: > http://www.textodigital.jazztel.es/hp49gplus/BPIA5324_CSB.zip > I hope you find it useful. > RaM. -- -Joshua Belsky jjbelsky@yahoo.com http://belsky.net ==== Okay, I'm confused. I haven't changed any of my software versions, but I could successfully extract your newer file. it might be more apt to compare their owners. I rarely see TIers put in the time and effort that HP lovers do, or a willingness to provide all of this work for free. I doubt Urroz is going to write volumes on the TI-89 for science & engineering. But, I digress... Is there any difference in the way you ZIPped the earlier file in comparison to this one? Mitch > > even willing to invest a few hours so that their documentation would be > more usable? >:( > > I have updated the 49G+ english User Guide with more than 1000 > bookmarks. So, it is cropped, sorted and bookmarked now. > > I made the bookmarks in only a few hours, but I hope I didn't make too > many mistakes. There are formatting errors in some headings of the > original text, font size not matching with the true heading level; > when detected, I have corrected them in the bookmark hierarchy, but I > have not touched the text itself. > > The guide would still need a few hundreds internal links, mainly from > the index and from cross references scattered in the text, but I don't > think I am going to do that work anytime soon, if at all. Also, I > don't plan to enhance the non-english versions of the guide, as it > seems like they where already enhanced enough by their translators. > > The new version is here: > http://www.textodigital.jazztel.es/hp49gplus/BPIA5324_CSB.zip > > I hope you find it useful. > > RaM. > > -- > -Joshua Belsky > jjbelsky@yahoo.com > http://belsky.net > ==== > even willing to invest a few hours so that their documentation would be > more usable? >:( In fact, including bookmarks and cross references would be very much easier if the original word processing document (not the PDF) was available. If the manual has been outsourced, however, it is possible that HP even has not the original document. It could be they forgot to request it, or a bookmarked version, or both, in the contract. Weirder things have happened in the esoteric world of outsourcing. RaM. ==== > Is there any difference in the way you ZIPped the earlier file in comparison > to this one? Both files were made with the very same tools. If you had corrupted downloads, it was probably because of unreliability of the connection, or of my ISP's servers. I have been looking at the log they provide, and it seems like about 10% of the downloads are truncated. It seems also like people just retry, and get it right. RaM. ==== >> even willing to invest a few hours so that their documentation would be >> more usable? >:( > >In fact, including bookmarks and cross references would be very much >easier if the original word processing document (not the PDF) was >available. If the manual has been outsourced, however, it is possible >that HP even has not the original document. It could be they forgot to >request it, or a bookmarked version, or both, in the contract. Weirder >things have happened in the esoteric world of outsourcing. > >RaM. I do not know, but I have a program that will take a PDF document and convert it back to a Microsoft Word document. However, I have tried it on several PDF document, and it does not always preserve the formatting and some of the fonts are not correct after the change The software is by ScanSoft and is PDF to Word converter. I will give it a try later this AM and let you know how it goes. It will probably take a while, as this is a big document. Harold A. Climer Dept.Of Physics, Geology, and Astronomy U.T Chattanooga Chattanooga TN USA ==== I need keyeval command but in the 48gx. any ideas ? thanx. ==== > > I need keyeval command but in the 48gx. any ideas ? Erable and Keyman have that command for the 48 ==== [48gII] BUG in insufficient memory and CATalog 1) TO get the meory low, load all of eqlib49 to a 48gII 2) Move to port 0 and reboot 3) Test it and then test 48MHz speed by using 1000! like this: 1000{!}HEAD MEM;TEVAL 4) Press CATalog => Insufficient Memory error AND first stack level object is replaced by ! @ BUG !!! [which is the first item in the CATalog.] ROM is 1.20, not tested on any other calculatrice/ROM There is about 2500 bytes memory left ==== > [48gII] BUG in insufficient memory and CATalog > > 1) TO get the meory low, load all of eqlib49 to a 48gII > 2) Move to port 0 and reboot > 3) Test it and then test 48MHz speed by using 1000! like this: > 1000{!}HEAD MEM;TEVAL > 4) Press CATalog > => Insufficient Memory error AND > first stack level object is replaced by ! @ BUG !!! > [which is the first item in the CATalog.] > > ROM is 1.20, not tested on any other calculatrice/ROM > There is about 2500 bytes memory left > > Does the 48gII have a flash rom. If not, that sounds very bad. What about battery drain? Arnaud ==== > [48gII] BUG in insufficient memory and CATalog > > 1) TO get the meory low, load all of eqlib49 to a 48gII > 2) Move to port 0 and reboot > 3) Test it and then test 48MHz speed by using 1000! like this: > 1000{!}HEAD MEM;TEVAL > 4) Press CATalog > => Insufficient Memory error AND > first stack level object is replaced by ! @ BUG !!! > [which is the first item in the CATalog.] > > ROM is 1.20, not tested on any other calculatrice/ROM > There is about 2500 bytes memory left > > > Does the 48gII have a flash rom. If not, that sounds very bad. What about > battery drain? Well, there is still time before the full US production to fix the keyboard (I tested a 48gII as sold in Finland AND [F2 B] and [F4 D] are often ignored) and that rare bug mentioned above. There is no Flash and the batteries seem to last forever. PS: I can't reproduce that error in the latest 49g+ ROM ==== As I already mentioned, tools related to the famous MIG library do not work on 49+. A pitty. The code of the SysRPL command setbeep on which all beep generation is based, doesn't run as it should. You hear a beep only if duration is about .1_s, not 10 milliseconds as in the 48/49. Still worse, if duration is too short, the system is in danger. One can prove this playing Bach's violin concert Edur from my site below. Therein, the performance tempo can be increased pressing key + *during the play*. At the first impression it runs perfect on the 49+. But if playing too fast, the sound suddenly disappears and the system may crash if not pevented by a warmstart. IMHO, a good OS should protect short beep duration by defining a minimal duration for each frequency, corresponding to the shortest time a human ear is able to identify it as a tune. Apart from the above problem, the 49+ beep is much lower than on the 49. Again, the OS should allow to turn the volume up to please also people with weeker ears. - Wolfgang http://www.math.fu-berlin.de/~raut/WR49/ Look under Music and load JSBACH.zip. ==== HP49. I thought it would be a two-hour hack, but only after a night and a day it worked. For an explanation what BrainFuck is and what it isn't, read http://www.muppetlabs.com/~breadbox/bf/ I have posted it to hpcalc.org, but as usual, if you can't wait drop be great if someone with an hp49g+ could test it, since I don't have one. Have fun - Thomas -- foo and bar, respectively. ==== > > HP49. I thought it would be a two-hour hack, but only after a night > and a day it worked. > > For an explanation what BrainFuck is and what it isn't, read > > http://www.muppetlabs.com/~breadbox/bf/ > > I have posted it to hpcalc.org, but as usual, if you can't wait drop > be great if someone with an hp49g+ could test it, since I don't have > one. > > Have fun > > - Thomas Brilliant! What a total waste of time! Just what is needed for some lateral thinking.... hee...hee ==== So, how big is your compiler? is it on the HP49 or on the PC? How did you do the putchar and getchar? > > HP49. I thought it would be a two-hour hack, but only after a night > and a day it worked. > > For an explanation what BrainFuck is and what it isn't, read > > http://www.muppetlabs.com/~breadbox/bf/ > > I have posted it to hpcalc.org, but as usual, if you can't wait drop > be great if someone with an hp49g+ could test it, since I don't have > one. > > Have fun > > - Thomas > > -- > foo and bar, respectively. ==== > So, how big is your compiler? The whole library is 1325 bytes, the compiler itself 1116 bytes. It might be possible to pull it below 1kB with some optimizations. > is it on the HP49 or on the PC? It is a pure HP49 program: Written on the 49 for the 49 =) > How did you do the putchar and getchar? For getchar, the compiled program pops a string off the stack and takes the input from there. It keeps track of the character count so that it can consistently write 0 to the current cell on and after EOF. putchar is done in steps. At the beginning all memory is allocated (with MAKERAM$) and 30000 bytes of it are used for the cell array. A pointer to the next free byte is kept in a register; . is then compiled to allocate a byte, write the character to the free byte, and move the pointer. (Actually both putchar and getchar are done with a subroutine call.) At the end of execution the output characters are moved 30000 bytes towards the bottom of memory, so that they now lie immediately at the beginning of the string; then Shrink$ is called and the string pushed as output. The obvious downside is that you cannot write interactive programs; but this way programs can be run one after the other to simulate a pipe. - Thomas -- foo and bar, respectively. ==== > > HP49. I thought it would be a two-hour hack, but only after a night > and a day it worked. > > For an explanation what BrainFuck is and what it isn't, read > > http://www.muppetlabs.com/~breadbox/bf/ > > I have posted it to hpcalc.org, but as usual, if you can't wait drop > be great if someone with an hp49g+ could test it, since I don't have > one. > > Have fun > > - Thomas Then you might be interested in this program by Jeffry Johnston.. http://esoteric.sange.fi/brainfuck/impl/interp/calculator/hp48bf.txt ==== > So, how big is your compiler? > > The whole library is 1325 bytes, the compiler itself 1116 bytes. It > might be possible to pull it below 1kB with some optimizations. See the attached non optimized version :-) Is yours a compiler or an interpretor? > How did you do the putchar and getchar? > > For getchar, the compiled program pops a string off the stack and > takes the input from there. It keeps track of the character count so > that it can consistently write 0 to the current cell on and after EOF. Ups, my version does not do that.. I should modify it... > putchar is done in steps. At the beginning all memory is allocated > (with MAKERAM$) and 30000 bytes of it are used for the cell array. > A pointer to the next free byte is kept in a register; . is then > compiled to allocate a byte, write the character to the free byte, and > move the pointer. (Actually both putchar and getchar are done with a > subroutine call.) At the end of execution the output characters are > moved 30000 bytes towards the bottom of memory, so that they now lie > immediately at the beginning of the string; then Shrink$ is called and > the string pushed as output. Yep, same for me.. > The obvious downside is that you cannot write interactive programs; > but this way programs can be run one after the other to simulate a > pipe. attached my version of BF: ASSEMBLE RPL xNAME BF :: CK1&Dispatch #3 :: GARBAGE CODEM %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % register usage in the compiler: % D1: input stream, all non recognize characters are ignored % D0: output stream (compiled code) % Ba: input nb chr (nb of chr left in input stream) % Da: - output memory (the negative of the memory for compilation) % RSTK: the stack pointer for the [ and ]s % R0: address of string in which stuff is compiled %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % register useage in compiled code % D0: memory pointer % D1: output stream pointer (no memory bound yet) % R1: start of output stream % Ca: input stream (no boundary test either) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% SAVE GOSBVL MAKERAM$ D1=(5)$806F8 A=DAT1.A D1=A A=DAT1.A D1=A D1+5 C=DAT1.A C-5.A CSRB.A B=C.A D1+5 C=D.A D-16.A SKNC { GOTO .memerr } D=-D.A CD0EX D0=C C-D.A C-10.A RSTK=C CD0EX D0+5 A=0.A DAT0=A.A CD0EX % init [] stack D0-10 LC DCC DAT0=C.3 D0+10 % copy the startup code SKUB { *.d SAVE GOSBVL MAKERAM$ % D0= mem pointer C=D.A CD0EX D1=C CD0EX GOSBVL WIPEOUT % erase! D1=(5)$806F8 A=DAT1.A D1=A A=DAT1.A D1=A D1+10 % D1= input C=D.A CSRB.A AD0EX D0=A C+A.A R1=C.A CD1EX % C= input, D1= output *.e } LC(5) .e-.d GOSUB .copdat { { B-1.A SKNC { GOTO .end } A=DAT1.B D1+2 LC(2) @ ?A#C.B { B=0.A UP2 } LC(2) < ?A#C.B { $32 D0-2 P=2 EXIT2 } LC(2) > ?A#C.B { $32 D0+2 P=2 EXIT2 } LC(2) + ?A#C.B { $38 A=DAT0.B A+1.B DAT0=A.B P=8 EXIT2 } LC(2) - ?A#C.B { $38 A=DAT0.B A-1.B DAT0=A.B P=8 EXIT2 } LC(2) . ?A#C.B { $38 A=DAT0.B DAT1=A.B D1+2 P=8 EXIT2 } LC(2) , ?A#C.B { $3E CD0EX A=DAT0.B D0+2 CD0EX DAT0=A.B P=14 EXIT2 } LC(2) [ ?A#C.B { C=RSTK CD0EX DAT0=C.A D0-5 CD0EX RSTK=C $3D A=DAT0.B ?A#0.B { SKIPL { } } P=13 D+5.A EXITNC2 GOC .memerr } LC(2) ] ?A#C.B { C=RSTK C+5.A RSTK=C CD0EX A=DAT0.A D0=A D0+10 % Ca: bottom PC-6, Aa: top PC D0: Place for GOTO bottom value D-5.A % memory is comming back! ACEX.A C=A-C.A C-4.A DAT0=C.4 % poke jump to C= bottom-4-Top-5 = bottom-top-9 D0: bottom-4 D0=A C+6.A LA 08000 ?C>=A.A -> .errtoolong C=-C.A CSL.A CSL.W LC C8 P=5 EXIT2 % poke up jump (top-bottom-3) } UP } DAT0=C.WP CD0EX C+P+1 CD0EX C=D.A C+P+1 D=C.A P=0 GOC .memerr UP } *.memerr C=0.A C+1.A GONC .er *.errtoolong LC 10111 GOC .er *.[]err LC 1010C *.er RSTK=C LOAD C=RSTK GOVLNG ErrjmpC_asup *.end % copy the startup code SKUB { *.d2 A=R0.W AD1EX D1+10 C=R1.A D0=C C=A-C.A GOSBVL MOVEDOWN CD1EX CD0EX GOSBVL Shrink$_asup LOAD A=R0.A DAT1=A.A RPL *.e2 } LC(5) .e2-.d2 GOSUB .copdat C=RSTK D1=C D1+5 A=DAT1.A ?A=0.A { LC 1010D GOTO .er } GOSBVL Shrink$_asup LOAD A=R0.A DAT1=A.A RPL *.copdat A=C.A D+C.A SKNC { GOTO .memerr } C=RSTK R4=C.A C=RSTK CD1EX RSTK=C { A-1.A EXITC C=DAT1.1 DAT0=C.1 D1+1 D0+1 UPNC } C=RSTK D1=C C=R4.W PC=C ENDCODE ' CK1&Dispatch #3 ' GARBAGE 4ROLL TWO ::N THREE ::N ; ; ==== While in the latest 49-ROMs no rompointer-shifting had been observed, the important ROMPTR B5 124 from 19-6 has moved or killed in ROM 1.22. This is just the list of the admissible Baud rates: 1200, 2400, 4800, 9600, 15360. Clearly, changing stable pointers and rompointers is poison for advanced programming, needless to explain this here in detail. Has anybody information on other admissible baud rates on the HP49+ ? - Wolfgang ==== > > While in the latest 49-ROMs no rompointer-shifting had been observed, > the important ROMPTR B5 124 from 19-6 has moved or killed in ROM 1.22. > This is just the list of the admissible Baud rates: 1200, 2400, 4800, > 9600, 15360. Clearly, changing stable pointers and rompointers is poison > for advanced programming, needless to explain this here in detail. > Has anybody information on other admissible baud rates on the HP49+ ? Note: Default baud rate in the HP49+ is 115200, in the HP49G it is 9600. There is a stable pointer for the real 115200 already in 19-6: PTR 26E4B. It is impossible to maintain a common library Ioman for both the 49 and the 49+, not because of the above, but because even the number of basic messages changed in ROM 1.22, e.g., the messages RECV renames and some related ones. Let me notice that builitin message numbers never changed in all the 49-ROMs hithertoo. This will be an additional problem for backward compatibility. It has nothing to do with language-sensibility (the above message is unexpectedly not translated into French). IMHO, the developer simply didn't care enough on backward compatibility. - Wolfgang ==== > > While in the latest 49-ROMs no rompointer-shifting had been observed, > the important ROMPTR B5 124 from 19-6 has moved or killed in ROM 1.22. > This is just the list of the admissible Baud rates: 1200, 2400, 4800, > 9600, 15360. Clearly, changing stable pointers and rompointers is poison > for advanced programming, needless to explain this here in detail. > Has anybody information on other admissible baud rates on the HP49+ ? > > Note: Default baud rate in the HP49+ is 115200, in the HP49G it is 9600. > There is a stable pointer for the real 115200 already in 19-6: PTR > 26E4B. > > It is impossible to maintain a common library Ioman for both the 49 and > the 49+, not because of the above, but because even the number of basic > messages changed in ROM 1.22, e.g., the messages RECV renames and some > related ones. Let me notice that builitin message numbers never changed > in all the 49-ROMs hithertoo. This will be an additional problem for > backward compatibility. It has nothing to do with language-sensibility > (the above message is unexpectedly not translated into French). IMHO, > the developer simply didn't care enough on backward compatibility. > > - Wolfgang Isnt there a 'simple' solution for this? Write code symbolically (as you all do), but do late-binding. Bit like pre-binding on Windows or Unix: when user downloads program from the web, a special 'prepare' program is run (maybe integral with the downloader, or sitting on the HP itself), which then translates the machine dependent entry points via a mapping/ symbol table. I think it would be a shame for the sw gurus out there to have to limit their markets or do twice as much work. Maybe even have a redirection lib which one installs on ones calc. You call into the lib and it jumps to the correct entry point for that machine. order my HP49G+. BTW I am the author of the original HP48 X11 em48 - I havent played with my HPs in a long while but look forward to getting my hands dirty again. Am considering getting stuck in to a Financial package (purely for personal fun - happy to share what I come up with). I always thought the HP48 family was the ultimate but surprised that some financial algs from the HP calcs werent on there. Has anyone pointers to algorithms/maths for these (Bond calcs for instance). I did some reading on google and they seem easy to implement which is why i thought i would have a play.... ==== -=[ Sat, 27.9.03 1:29 p.m. +1200 (NZT) ]=- in message ID <6d4c5e97.0309261140.a7de48b@posting.google.com> : [...] > Am considering getting stuck in to a Financial package > (purely for personal fun - happy to share what I come up > with). I always thought the HP48 family was the ultimate > but surprised that some financial algs from the HP calcs > werent on there. Has anyone pointers to algorithms/maths > for these (Bond calcs for instance). www.hpcalc.org seach on phillips You will find his financial package for the 48 & 49 -- Tony Hutchins Wellington New Zealand ==== -=[ Sat, 27.9.03 7:54 p.m. +1200 (NZT) ]=- in message ID <10922278ROBOTLX@news.cis.dfn.de> : > Has anyone pointers to algorithms/maths > for these (Bond calcs for instance). > > www.hpcalc.org > seach on phillips > You will find his financial package for the 48 & 49 I have now tried this out on my HP49 - using the FIN49...ZIP that John Meyer adjusted. This FIN was first written in 1996. The Bonds program is top-notch!! I was delighted to see my old UBONDS (a solver for the HP200LX, written as a challenge in 1995, and recently published in HPCC DataFile V22N1) given by Don Phillips as a reference, and indeed I find the source code easy to follow ;-) So, I recommend FIN49 to anyone wanting to do or study Bond solving on the HP49. The HP19Bii Bonds application scope is a subset of FIN49. FIN49 gives a full breakdown of internediate calculations of last and next coupon dates and days in between. This is probably the trickest part of the code. UBONDS for the HP200LX palmtop is also available at http://homepages.paradise.net.nz/th did a perfect transposition - the algorithms are given in my even older (1983) book MFC also referred to at that site. -- Tony Hutchins Wellington New Zealand ==== > -=[ Sat, 27.9.03 7:54 p.m. +1200 (NZT) ]=- > > > So, I recommend FIN49 to anyone wanting to do or study Bond > solving on the HP49. The HP19Bii Bonds application scope is a > subset of FIN49. FIN49 gives a full breakdown of internediate > calculations of last and next coupon dates and days in > between. This is probably the trickest part of the code. > > UBONDS for the HP200LX palmtop is also available at > http://homepages.paradise.net.nz/th > > did a perfect transposition - the algorithms are given in my > even older (1983) book MFC also referred to at that site. Super - great. Just what I was after. I will have a play and then try to re-implement it, referring back to the code just for the heck of it. thanks again ==== > is impossible to maintain a common library Ioman for both the 49 and > the 49+, not because of the above, but because even the number of basic > messages changed in ROM 1.22, e.g., the messages RECV renames and some > related ones. Let me notice that builitin message numbers never changed > in all the 49-ROMs hithertoo. This will be an additional problem for > backward compatibility... > Isnt there a 'simple' solution for this? Write code symbolically > (as you all do), but do late-binding. Bit like pre-binding on Windows > or Unix: when user downloads program from the web, a special 'prepare' > program is run (maybe integral with the downloader, or sitting on the > HP itself), which then translates the machine dependent entry points > via a mapping/ symbol table. This may work for simple programs, but not for advanced projects. The best you can do is using the old source code as a base for reprogramming. I'll give a simple example. Assume that a HP49-rogram uses the command CLLCD which clears the entire display. Not so on the HP49+. Here it only clears the area beneath the Header (this area is the HARDBUFF in the new device). Thus, you have to do more in order to clear entirely the larger display on the 49+. Running a program as intended is not only a software question but obviously depends essentially on the hardware. - Wolfgang ==== via a mapping/ symbol table. > > This may work for simple programs, but not for advanced projects. The > best you can do is using the old source code as a base for > reprogramming. I'll give a simple example. Assume that a HP49-rogram > uses the command CLLCD which clears the entire display. Not so on the > HP49+. Here it only clears the area beneath the Header (this area is the > HARDBUFF in the new device). Thus, you have to do more in order to clear > entirely the larger display on the 49+. Running a program as intended is > not only a software question but obviously depends essentially on the > hardware. > > - Wolfgang Hmm...not with you here. If CLLCD is different between HP48 and HP49 or HP4[89] and HP49G+, then one could conceivably emulate - have an interposed library which retains prior behaviour. I'm not saying its easy and doing appropriate upwards and backwards testing is almost certainly not worth it for most apps out there. But conceivably its easily solvable.... Its just a matter of removing dependence on specific ROM code. I've had to do that on numerous occasions for Windows (eg things implemented in NT 4 but not there on Win 98, so you have private versions of unimplemented or broken functions). Ditto for all Unixes - if one platform doesnt support your function of choice or is broken then you provide a local version to override the default. Its probably not worth it, but it seems doable - even if the tool simply warned of inappropriate ROM entry points rather than providing a fallback. This kind of tool would be great in providing some API or other to detect which calc you were on and stop you proceding if something bad were to happen if you proceeded. -- pdf ==== > While in the latest 49-ROMs no rompointer-shifting had been observed, > the important ROMPTR B5 124 from 19-6 has moved or killed in ROM 1.22. > This is just the list of the admissible Baud rates: 1200, 2400, 4800, > 9600, 15360. Clearly, changing stable pointers and rompointers is > poison for advanced programming, needless to explain this here in > detail. Stable? this entry point was totally unsupported in the first place. Using a ROMPOINTER to code in the ROM is bad practice and you shouldn't be surprised if it doesn't work anymore. Now using ROM pointer to data inside a code is even worse. ==== > IMHO, > the developer simply didn't care enough on backward compatibility. That is so much rubbish... you are using unsupported entries, don't be surprised for what happen. If you want to use messages, use supported ones ; or create your own message table in your library ==== > IMHO, > the developer simply didn't care enough on backward compatibility. > > That is so much rubbish... > you are using unsupported entries, don't be surprised for what happen. > If you want to use messages, use supported ones ; or create your own > message table in your library Are you sure that all the messages are in place. The FinLib49 works now on ROM 1.22, but it *looks* like some messages _might_ have changed. What are the new messages of the plus? Can you dig them out for us? Anybody else in progress of making a new 1.22 compatible error message native language library? WR/Deutch? ==== > IMHO, > the developer simply didn't care enough on backward compatibility. > That is so much rubbish... You're extremely polite as always. I get along with unsupported pointers and rompointers, don't worry :-). It's a fact that built message numbers of the 48 didn't change when passing to the 49! Ok, we seemingly cannot rely anymore on this facilitation for programming. Very easy to prove that even 49-UsrRPL programs do not run as expected on the 49+. Do you want an example? (NB: I'm not talking on the Header). Backward compatibility is not granted. > you are using unsupported entries, don't be surprised for what happen. > If you want to use messages, use supported ones ; or create your own > message table in your library I try to avoid message tables in libraries; these mostly unnecessarily blow up the code. Hence, I use builtin messages whenever possible. And speed isn't anymore an issue on the 49+. - Wolfgang ==== Why is it that JYA is being completely rude with most everyone on this NG? I understand there may be posts on stuff that most likely is in the manual (RTFM) or in previous posts (simple search), but is there a need to be so snooty and rude? Especially with developers such as WR who provide the community with invaluable programs and utilities? If this group is making you so angry or fed-up, maybe you should move on to other endeavors. Just a thought. Doug to how you treat people in this NG. > > IMHO, > > the developer simply didn't care enough on backward compatibility. > > That is so much rubbish... > > You're extremely polite as always. I get along with unsupported pointers > and rompointers, don't worry :-). It's a fact that built message numbers > of the 48 didn't change when passing to the 49! Ok, we seemingly cannot > rely anymore on this facilitation for programming. > > Very easy to prove that even 49-UsrRPL programs do not run as expected > on the 49+. Do you want an example? (NB: I'm not talking on the Header). > Backward compatibility is not granted. > > you are using unsupported entries, don't be surprised for what happen. > If you want to use messages, use supported ones ; or create your own > message table in your library > > I try to avoid message tables in libraries; these mostly unnecessarily > blow up the code. Hence, I use builtin messages whenever possible. And > speed isn't anymore an issue on the 49+. > > - Wolfgang ==== X > It's a fact that built message numbers > of the 48 didn't change when passing to the 49! Ok, we seemingly cannot > rely anymore on this facilitation for programming. > > Very easy to prove that even 49-UsrRPL programs do not run as expected > on the 49+. Do you want an example? (NB: I'm not talking on the Header). > Backward compatibility is not granted. X If you have done some research then can you give me an example (or rather all the changed messages :) and one example of a UserRPL that has changed from the old 49G <3f79adc7$0$57369$bb8e7a08@news2.usenetcompany.com> ==== In message <3f79adc7$0$57369$bb8e7a08@news2.usenetcompany.com>, Douglas >Why is it that JYA is being completely rude with most everyone on this >NG? I understand there may be posts on stuff that most likely is in >the manual (RTFM) or in previous posts (simple search), but is there a >need to be so snooty and rude? Especially with developers such as WR >who provide the community with invaluable programs and utilities? If >this group is making you so angry or fed-up, maybe you should move on >to other endeavors. Just a thought. I think you should be asking the question why developers are so demanding of J-Y A just because some feature or other changed? You mention WR so I'll use the example of his post in this very thread in which he complains that some 49G programs won't run on the 49G+. Well: a) who said that they would, and b) why is this J-Y A's fault? I don't recall HP ever claiming that the 49G+ was 100% compatible with 49G code and that *every* program *without exception* would run identically. The very fact that the new calc runs faster will inevitably break some programs. Any half decent programmer could tell you that just from the specs alone. Also, I don't recall seeing any clear statement of which bits J-Y is responsible for and which bits are HP's or Kinpo's or anyone else's. Presumably, only the updated 49G rom is J-Y's. The emulator, the hardware etc. are all someone else's. In many ways, the nit-picking level of detail in the complaints is most heartening. If the only differences that can be found are buried in the detail of rom pointers that were never guaranteed to be stable, but just happened to have been so, then this surely is a credit to the design team to have made such fundamental hardware changes with so little software impact? -- Bruce Horrocks Surrey England ==== Bruce, Details or no details, developers or no developers, JYA's comments are simply rude. I never said programs that don't run on the 49G+ are because of JYA. I don't know the intricate details of that, never said I did. I'm simply referring to his attitude, which basically sucks. Even if WR is using bad techniques with ROMPOINTER's, does that mean it's okay to be rude to him? Simply say, in a constructive way, thats not the right way to do it or I wouldn't do it that way and give some helpful tips if possible. And if someone doesn't know, they don't reply or say they don't know. Afterall, wasn't this newsgroup established for the purpose of helping other hp calculator users? Also, I didn't see JYA's name in the original post. For the record, me stating how rude JYA is acting in no way means I don't appreciate all the work he's done with the 49G. It's an amazing machine and I love it. I'm simply referring to how he reacts to people in this NG. You simply misinterpreted my post or put too much thought into it. No one is blaming JYA. Doug > I think you should be asking the question why developers are so > demanding of J-Y A just because some feature or other changed? > > You mention WR so I'll use the example of his post in this very thread > in which he complains that some 49G programs won't run on the 49G+. > Well: > a) who said that they would, and > b) why is this J-Y A's fault? <3F74214F.E2BEE7AB@math.fu-berlin.de> ==== > It's a fact that built message numbers > of the 48 didn't change when passing to the 49! Ok, we seemingly > cannot rely anymore on this facilitation for programming. Could you tell me the message numbers that has changed on the HP49 on ROM 1.22? Message that didn't move from the HP48 to the HP49... <3F74214F.E2BEE7AB@math.fu-berlin.de> <3F79AC4E.E20BBC1B@math.fu-berlin.de> ==== In <3f79adc7$0$57369$bb8e7a08@news2.usenetcompany.com> Douglas Rohm > Why is it that JYA is being completely rude with most everyone on this > NG? I'm not being rude to Wolfgang I'm just responding in a similar manner ( or so I think) to his original post. Like: Obviously the programmer didn't care about backward compatibility ( knowing perfectly that he's talking about me here) Or like: Fatal Error, every body should know.. It's a shame Totally unacceptable change Wolfgang seems to think that anything that make his program not work anymore must be due to the totally inacceptable behavior of one person. That because he's such a good programmer that obviously it should be his way. complaining about something that was never official in the first place. Continuously telling you how you should have done it. What you've done is crap then I would like to know how you feel. Maybe you're right, I should move on and not bother anymore. The fact is I care on how people feel about things I created. And I always welcome suggestions. Not continuous criticisms on how things should be and wy if I had done things their way it would be so much better. Because it's been going on like this for years not only here but by <3F74214F.E2BEE7AB@math.fu-berlin.de> <3F79AC4E.E20BBC1B@math.fu-berlin.de> <3f79adc7$0$57369$bb8e7a08@news2.usenetcompany.com> <30ZCgeD2Xge$EwRL@nodomain.nodomain.us> ==== In <3f7a3dd6$0$57396$bb8e7a08@news2.usenetcompany.com> Douglas Rohm > Also, I didn't see JYA's name in the original post. If you had looked in a slightly different way, you would have seen that whenever Wolfgang refers to a programmer without naming it, it's me he's talking about... and he very well know that ;) I don't think I'm rude with everything in the forum, and if I am .. So be it. <3F74214F.E2BEE7AB@math.fu-berlin.de> ==== > The FinLib49 works now on ROM 1.22, but it looks like > some messages might have changed. You should be the one telling me what has changed as you're the one using them in your finlib library I will have a look if you tell me what exactly the problem is ==== > > complaining about something that was never official in the first place. > Continuously telling you how you should have done it. What you've done > is crap then I would like to know how you feel. > > Maybe you're right, I should move on and not bother anymore. The fact is > I care on how people feel about things I created. And I always welcome > suggestions. > Not continuous criticisms on how things should be and wy if I had done > things their way it would be so much better. > I've been a programmer for laboratory equipment automation, and I've also had to listen to lots of criticism. The endless why can't it do this/that......? would annoy me sometimes also, and my programming was not on a World-wide scale like the 49G. Even with the criticism, I think everyone here respects you and your work. I would also remind the group that you frequently respond to 49G users' questions in a way that is not common in today's marketplace. Tom ==== > complaining about something that was never official in the first place. > Continuously telling you how you should have done it. What you've done > is crap then I would like to know how you feel. > Because it's been going on like this for years not only here but by I can understand that. You've put tons of time, sweat, and tears into your work. I would probably start to feel that way also. Maybe it's the language someone and be totally confused as to the manner in which it was written. It's While we're on the subject, I asked this a week or so ago, but did you contribute to the 49G+ ROM code? If so, in what capacity? If you'd rather not reply to the group on this I understand. Doug ==== X > Because it's been going on like this for years not only here but by BUT A) Did I actually ever refer you as a programmer or anything similar? Sorry, if I referred to your person in regarding your abilities Not sorry, when I have blamed your French style, so be it (-; B) During the years HP has never corrected these bad things: 1) EQW has no more units capability 2) CAS now changes flags and does not respect user's settings During the years there has not been any new object enhancements 1) Symbolic Complex, Complex in Polar Mode with units 2) EQW/Command line to accept { lists } and [arrays] C) HP Hardware has still some trouble and some things are missing: 1) use of *AA* rechargeables & the USB cable (PC) as a charger 2) also a serial for the 49G+ I suggest a hp 49g Pro * THESE WERE NEVER MEANT PERSONALLY * but addressed to you simply because you were the only contact in HP (well Cyrille, too) and even supportive when outside the HP (Parisse, too) The best thing is: it is/was all free of charge! PS: sorry for constantly nagging about flags/units/complex but students in Finland constantly nag to me about these... ==== > If you have done some research then can you give me an example > (or rather all the changed messages :) > and one example of a UserRPL that has changed from the old 49G Numbers changed on those messages which may not be listed officially, of these messages on the 49 doesn't exist. A internal or external lib may store 256 different messages in $MESSAGE, hence there is alway room to add some new messages. For instance, new boot messages have been added in the 49+. The last one in ROM 1.22 is Disk Protected. A nice browser for getting all these (with the option NUM in the menu to ask for the number) is easily made with CHOOSEX from my lib CHOOSEext(ension), discussed here 1 or 2 years ago, updated only on my site. the program << 1. 2500. FOR f f .01 BEEP 100. STEP >> on both the 49 and the 49+. I'm not talking here on the difference in the sound. Although the 49+ is general faster, here it seems first to collect all its power for 2 secconds, to finally start the sound. The 49+ has problems with the BEEP command (internally setbeep) if given to a too small frequency and duration time. - Wolfgang ==== > While in the latest 49-ROMs no rompointer-shifting had been observed, > the important ROMPTR B5 124 from 19-6 has moved or killed in ROM 1.22. I had a look, and the *important* ROM pointer is referring to a message used by the flag browser. Obviously, if the flag list content changes this entry will change too. There's just no way to support this one or too fix it. and it has definitely changed from the 48 to the 49. For example, in this list on the 48G you had Print via IR/Wire which doesn't exist on the 49 and re-appeared on the 49G+. I guess the word *important* has a different meaning for you and for me :) ==== > I had a look, and the *important* ROM pointer is referring to a message > used by the flag browser. Obviously, if the flag list content changes > this entry will change too... it seems that ROMPTR B5 124 which contained a list of baud rates (and is indeed not that important :-) has no relevance on the 49+ at all. I tried to let the 49+ communicate with my old 48 via IR, but in vain. Is it true that the 49+ is sending/receiving at with baud 115200 only? The TRANSFER screen in the 49+ APPS box doesn't contain a choice for baud anymore. Wolfgang ==== > I had a look, and the *important* ROM pointer is referring to a message > used by the flag browser. Obviously, if the flag list content changes > this entry will change too... > > it seems that ROMPTR B5 124 which contained a list of baud rates (and is > indeed not that important :-) has no relevance on the 49+ at all. I > tried to let the 49+ communicate with my old 48 via IR, but in vain. Is > it true that the 49+ is sending/receiving at with baud 115200 only? The > TRANSFER screen in the 49+ APPS box doesn't contain a choice for baud > anymore. When you are in the TRANSFER scree, if you press NEXT RESET(F1), [Reset All], then you get a Baud choose where you can modify speed to 9600 (among other 7 posibilities). But I could't tranfer with my 48gx even modifying that baud rate, it seems that it only affects transfers via wire. I would really like to be able to transfer directly betwen my 48gx and 49g+. Jorge Cevallos ==== using COPY or MOVE in Port2 say, to copy a library to the SD-card yields the (wrong) error message Invalid DOS Name and does not copy. Thus, the lib object has either be put into a list or better compressed before saving it on the the SD-card. Clearly, these operations, if started in a SD card, have to take care of this. An involved task ... This concerns in particular saving such huge libs like extable or SDIAG on the card. If you don't intend to fix it, I'll write a tool for saving all builtin ports on the SD-card in one action. This may be used by those which are forced to return their 49+ because of the unreliable keyboard. Even after 10 days of intensive use of my 49+ the SPC key does not show any sign of operating more reliable. Meanwhile I discovered some other keys with this intolerable defect, in particular, your new EVAL key. If too short (staccato) pressed it doesn't eval despite the key click :-) - Wolfgang PS. A very bad thing that the SD-card does not accept long names. Can't we force it to keep going with time? ==== > > using COPY or MOVE in Port2 say, to copy a library to the SD-card yields > the (wrong) error message Invalid DOS Name and does not copy. Thus, > the lib object has either be put into a list or better compressed before > saving it on the the SD-card. Clearly, these operations, if started in a > SD card, have to take care of this. An involved task ... This concerns > in particular saving such huge libs like extable or SDIAG on the card. > > If you don't intend to fix it, I'll write a tool for saving all builtin > ports on the SD-card in one action. This may be used by those which are in a way that is easy to read for me and a good example how to describe a problem. I have experienced the same problems. AND please do write you back-up utility anyway! > forced to return their 49+ because of the unreliable keyboard. Even > after 10 days of intensive use of my 49+ the SPC key does not show any > sign of operating more reliable. Meanwhile I discovered some other keys > with this intolerable defect, in particular, your new EVAL key. If too > short (staccato) pressed it doesn't eval despite the key click :-) > > - Wolfgang > PS. A very bad thing that the SD-card does not accept long names. Can't > we force it to keep going with time? Ditto! PS: thank you both for your contributions to HP 4x ==== > PS. A very bad thing that the SD-card does not accept long names. > Can't we force it to keep going with time? > The SD card accepts long name when you use strings like: 123123 :3:This is a long name STO RCL, PURGE all works with long name. Not the filer though. A pity ==== > The SD card accepts long name when you use strings like: > 123123 :3:This is a long name STO > RCL, PURGE all works with long name. Not the filer though. A pity True, but that puts us nevertheless in a bad situation. Because the filer is needed to read the card. It does not display long names but displays your example as [?]A ERROR 19 That is, only the first letter of the long name is read and the object type is not recognized. And PURGE from the filer does not only not work but reacts very much like Windows (if a task cannot be executed simply forget about it but don't tell anything to the user :-) - Wolfgang PS. Thus, the filer and hence ROM 1.22 need updating anyway. I offer you again a use of some of the additional tools of my Filer5. In particular the extremely convenient ARCHIVE/RESTORE choose box which includes also the SD card. ==== :)) > PS. A very bad thing that the SD-card does not accept long names. > Can't we force it to keep going with time? > > > The SD card accepts long name when you use strings like: > > 123123 > :3:This is a long name > STO > > RCL, PURGE all works with long name. Not the filer though. A pity > ==== > > PS. A very bad thing that the SD-card does not accept long names. > > Can't we force it to keep going with time? > > > The SD card accepts long name when you use strings like: > RCL, PURGE all works with long name. Not the filer though. A pity if there'll be a new ROM version please do not forget to fix an old bug in your editor. When being in edit mode with a many lines text, the cursor moves very well when changing the font during an edit session. But it doesn't do so when toggling CurrentFont/Minifont during edition, i.e. flag -73 (wrong position and garbage text in minifont) This may not bother the normal user who never toggles the current font with Minifont during an edit session (as he has indeed no possibility to do so unless he is familiar with a TakeOver). But this bothers very much in advanced programming. For instance, my eyes see well at certain hours of the day, but not in the late evening. Hence, I want a change to a normal font *without* interrupting a long lasting programming session. Wolfgang ==== I purchased an hp49g+ from Singapore, serial No:CN33109123, but the connectivity program Conn4x is not able to locate the calculator. The connect using box identifies the calculator: HP9xg+ once you have plugged it in to the USB port, then you are instructed to press right red button and right arrow on the calculator, and the calculator displays Awaiting Server Cmd. On the computer you get Looking for calculator then an error message of Unable to open communications to HPx9G+ Any help would be appreciated. Andrew Buckwell ==== > I purchased an hp49g+ from Singapore, serial No:CN33109123, but the > connectivity program Conn4x is not able to locate the calculator. > The connect using box identifies the calculator: HP9xg+ once you > have plugged it in to the USB port, then you are instructed to press > right red button and right arrow on the calculator, and the calculator What's your point in posting 5 times the same message answering previous threads which have nothing to do with your problem! ==== > I purchased an hp49g+ from Singapore, serial No:CN33109123, but the > connectivity program Conn4x is not able to locate the calculator. The > connect using box identifies the calculator: HP9xg+ once you have plugged it > in to the USB port, then you are instructed to press right red button and right > arrow on the calculator, and the calculator displays Awaiting Server Cmd. This is in the wrong thread, but I cannot find the proper one so I'll reply here (Please make your own thread in future!). You have started the wrong server on the calculator. Press the shift key, then RELEASE IT, then press the arrow key. It should say something like Xmodem Server - waiting command I think. I have run into this problem myself. cheers, Al ==== Dear 49-ers, usually I have the clock shown in my HP calcs. The 48GX displays the seconds as well, and if you look closely you will see the display slightly flicker every time a new second is shown. The time is shown with dividing colons, e.g., 09:15:23. On the 49g the time is shown without displaying the seconds, e.g., 10:04, but the colon is blinking every second, i.e., for one second the colon is visible, the other second not. You cannot see any flickering of the screnn while : is blinking. On the new 49g+ the time is shown exactly as on the 49g, but the blinking is not regular: you'll see the colon and then it disappeares and shows up again etc, but not so regular as on the 49g. Furthermore, a flickering occurs in the few last lines of the display, which disappeares when the clock is not shown. Can you confirm my observations? Michael -- -= Michael Hoppe , =------ ==== > Dear 49-ers, > > usually I have the clock shown in my HP calcs. The 48GX displays the > seconds as well, and if you look closely you will see the display > slightly flicker every time a new second is shown. The time is shown > with dividing colons, e.g., 09:15:23. > > On the 49g the time is shown without displaying the seconds, e.g., > 10:04, but the colon is blinking every second, i.e., for one second the > colon is visible, the other second not. You cannot see any flickering > of the screnn while : is blinking. > > On the new 49g+ the time is shown exactly as on the 49g, but the > blinking is not regular: you'll see the colon and then it disappeares > and shows up again etc, but not so regular as on the 49g. Furthermore, > a flickering occurs in the few last lines of the display, which > disappeares when the clock is not shown. > > Can you confirm my observations? > Yes, Michael All the models perform as you described. I'm afraid that due to Saturn emulation (SW/HW/timing) the slight flickering of the last few pixel rows in the 49G+ menu label area will stay. ==== > I'm afraid that due to Saturn emulation (SW/HW/timing) > the slight flickering of the last few pixel rows > in the 49G+ menu label area will stay. > V I fail to see what emulation has anything to do with the screenflickering at the bottom. Also the previous post was about that the colon not blinking regularly not about the bottom of the screen blinking. Answered too fast again (as usual) ==== > I'm afraid that due to Saturn emulation (SW/HW/timing) > the slight flickering of the last few pixel rows > in the 49G+ menu label area will stay. > V > I fail to see what emulation has anything to do with the > screenflickering at the bottom. Do you mean that there is no Software-Hardware combination timing problems that is a cause of this slight flickering (which went unnoticed for many weeks for me until pointed out here) ? Then what is your best guess about it? > Also the previous post was about that the colon not blinking regularly > not about the bottom of the screen blinking. What about that colon irregularity then? Your answer? > Answered too fast again (as usual) BUT you did not answer at all! )-: ==== > What about that colon irregularity then? Your answer? Umm, maybe a good dose of Imodium? ;-) Sorry, I just couldn't quite resist that one. -- James ==== > Also the previous post That's me! > was about that the colon not blinking regularly > not about the bottom of the screen blinking. It was on both: Furthermore, a flickering occurs in the few last lines of the display, which disappeares when the clock is not shown. Michael -- -= Michael Hoppe , =------ ==== >> I'm afraid that due to Saturn emulation (SW/HW/timing) >> the slight flickering of the last few pixel rows >> in the 49G+ menu label area will stay. >> V > I fail to see what emulation has anything to do with the > screenflickering at the bottom. > Also the previous post was about that the colon not blinking regularly > not about the bottom of the screen blinking. > Answered too fast again (as usual) He always speaks politely to you, apologizes when he gets something wrong, and usually agrees with you. Yet you never miss an opportunity to criticize or insult him (especially with those little backhanded remarks like as usual). I guess Megha Shyam and Doug Burkett (and others) were right about you. -- Wayne Brown | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== > was about that the colon not blinking regularly > not about the bottom of the screen blinking. > > It was on both: Furthermore, a flickering occurs in the few last lines > of the display, which disappeares when the clock is not shown. > > Michael Try putting in a brand new set of batteries. I noticed screen flickering on my HP48GX last week, and last night while programming, the low-bat signal flickered on and off while I was running a long computation. I doubt that these 2 things are unrelated. Geoff ==== In message , Veli-Pekka >Do you mean that there is no Software-Hardware combination timing >problems that is a cause of this slight flickering (which went >unnoticed for many weeks for me until pointed out here) >? >Then what is your best guess about it? No one complaining about the screen flickering has said anything about the lighting conditions they were in at the time and what effect, if any, it has. This is akin to complaining to your optician that you had trouble seeing while at home last night without mentioning that there was a power cut. :-) -- Bruce Horrocks Surrey England ==== In message , Wayne Brown >I guess Megha Shyam and Doug Burkett (and others) were right about you. Go on then, what have they told you? Legal disclaimer: statements written are of the author's own volition and may not be inferred, inter*^£^£)!£)& NO CARRIER -- Bruce Horrocks Surrey England <2kTdb.2$H43.1@reader1.news.jippii.net> ==== > I guess Megha Shyam and Doug Burkett (and others) > were right about you. I don't remember Doug Burkett, and I would prefer not to talk about I think I have every right to doubt it. I could go on on the 6 months late payment, hiding numbers and so on.. Not very honnest business people ==== > In message , Wayne Brown >>I guess Megha Shyam and Doug Burkett (and others) were right about you. > Go on then, what have they told you? You can find Megha Shyam's opinion at: http://www.hpcalc.org/hp48/docs/misc/hpmarket.zip party (who forwarded a copy to me), so I won't quote his remarks here. Suffice it to say that his comments agreed with Megha's comments about the behavior of the ACO team in general and JYA in particular. My point is that both of them made these comments in 2000, which shows that some things don't change (at least in JYA's case). -- Wayne Brown | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== >> I guess Megha Shyam and Doug Burkett (and others) >> were right about you. > I don't remember Doug Burkett, and I would prefer not to talk about > I think I have every right to doubt it. I could go on on the 6 months > late payment, hiding numbers and so on.. Not very honnest business > people Doug Burkett was an avid HP user who abandoned comp.sys.hp48 in 1999 after being flamed repeatedly for not following the party line. As for Megha Shyam, well, all I can say is that his version of events is different from yours. I wasn't involved so I don't know which version is correct and I won't comment about your business relationship. Both he and Doug, though, were complaining of rude treatment from you (and the rest of ACO, but you in particular) at least as far back as 2000. wants to keep the discussion as pleasant as possible). -- Wayne Brown | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== > Doug Burkett was an avid HP user who abandoned comp.sys.hp48 in 1999 after > being flamed repeatedly for not following the party line. than posts on c.s.hp48. One positive thing that I've noticed since then is that more people here have realized that the HP49G(+) may not be the best calculator for everything. However, I still sometimes see attempts to push problems under the rug and pretend they don't exist. (Note: I'm not claiming that the TI-68k are the best for everything either. As I've said repeatedly, TI's and HP's have their own strengths and weaknesses.) > wants to keep the discussion as pleasant as possible). disappear, by the way? -- Bhuvanesh <2kTdb.2$H43.1@reader1.news.jippii.net> ==== > Doug Burkett was an avid HP user who abandoned comp.sys.hp48 in 1999 > after being flamed repeatedly for not following the party line. Oh I remember now, I suggested that if he had problems with the 49G keyboard it was because he may have had weak fingers :) Well, it's a pity he can't get over it ==== > (Note: I'm not claiming that the TI-68k are the best for everything > either. As I've said repeatedly, TI's and HP's have their own > strengths and weaknesses.) Yes. For example, one of the strengths of TI-68k calculators is as paperweights. One of their weaknesses is their calculator functionality. Sorry, I couldn't resist. -Josh -- -Joshua Belsky jjbelsky@yahoo.com http://belsky.net ==== > > Yes. For example, one of the strengths of TI-68k calculators is as > paperweights. One of their weaknesses is their calculator functionality. > > Sorry, I couldn't resist. No need to apologize! It was a perfectly natural response! The guy is asking for trouble. Seek and destroy with extreme prejudice all infidels :-) !Demeter! ==== >> Doug Burkett was an avid HP user who abandoned comp.sys.hp48 in 1999 >> after being flamed repeatedly for not following the party line. > Oh I remember now, I suggested that if he had problems with the 49G > keyboard it was because he may have had weak fingers :) > Well, it's a pity he can't get over it which I referred was written in September 2000, and may or may not reflect his current feelings. -- Wayne Brown | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== > > (Note: I'm not claiming that the TI-68k are the best for everything > either. As I've said repeatedly, TI's and HP's have their own > strengths and weaknesses.) > > Yes. For example, one of the strengths of TI-68k calculators is as > paperweights. One of their weaknesses is their calculator functionality. > > Sorry, I couldn't resist. > > -Josh Isn't the 49g a little heavier than the 89? If so, the former would make a better paperweight ;) -- Bhuvanesh <662e00ed.0310011505.700822c@posting.google.com> <662e00ed.0310020544.38c06904@posting.google.com> ==== In message <662e00ed.0310020544.38c06904@posting.google.com>, Bhuvanesh >> >> (Note: I'm not claiming that the TI-68k are the best for everything >> either. As I've said repeatedly, TI's and HP's have their own >> strengths and weaknesses.) >> >> Yes. For example, one of the strengths of TI-68k calculators is as >> paperweights. One of their weaknesses is their calculator functionality. >> >> Sorry, I couldn't resist. >> >> -Josh > >Isn't the 49g a little heavier than the 89? If so, the former would >make a better paperweight ;) So you're saying the TI is no good as a paperweight, either? :-) -- Bruce Horrocks Surrey England ==== I just updated the package Terror on my site below. It's a really pleasant game on the 49+ now. Helps fighting with feelings of aggression :-) - Wolfgang http://www.math.fu-berlin.de/~raut/WR49/index.htm See under GAMES ==== I have bought a 49g+ a week ago and I have been trying to update it's ROM but I am unable to press the reset button on the back in order to reset the calc (as ordered by the Connectivity Kit). How long must be the object that I insert into the calculator? | va.va | ==== -=[ Thu, 9.10.03 3:05 p.m. +1300 (NZDT) ]=- in message ID : [...] > How long must be the object that I insert into the calculator? I used a paper-clip, unbent to make a wire suitable for poking in that little hole on the back of the case. I just poked the wire into the hp49g+ until it made contact with something, which I assume was the reset button ;-) Were you using a ball-point or something that touched the sides of the hole? You need a wire that goes in freely, without touching, as the button is indeed hidden a fair way in. -- Tony Hutchins Wellington New Zealand ==== In the manual is says to use a paperclip, just straighten one out and insert and push firmly, you should feel it hit the piece of steel that it has to hit and then close on the switch. MC > > I have bought a 49g+ a week ago and I have been trying to update it's > ROM but I am unable to press the reset button on the back in order > to reset the calc (as ordered by the Connectivity Kit). > > How long must be the object that I insert into the calculator? > > | va.va | ==== I keep a length of paperclip material in the battery compartment. > In the manual is says to use a paperclip, just straighten one out and insert > and push firmly, you should feel it hit the piece of steel that it has to > hit and then close on the switch. > MC > > > I have bought a 49g+ a week ago and I have been trying to update it's > ROM but I am unable to press the reset button on the back in order > to reset the calc (as ordered by the Connectivity Kit). > > How long must be the object that I insert into the calculator? > > | va.va | > > ==== The paper clip tip works great, thanks! | va.va | ==== A resistor or other component (with higher current rating) leg works also + you dont have to unbend it! DAve > > I have bought a 49g+ a week ago and I have been trying to update it's > ROM but I am unable to press the reset button on the back in order > to reset the calc (as ordered by the Connectivity Kit). > > How long must be the object that I insert into the calculator? > > | va.va | ==== I'd like to announce the release of the library in subject; is a brief description follows. The library is a collection of Gasdynamics Tables for exact computations of flows properties. Completely written in SysRPL, the library has an RPN approach (that is the main difference from other simlar libraries on hpcalc), which I think to be more efficient. By now it includes the following tables: Isentropic flow, Fanno Line, Rayleigh Line, Normal Shock Waves and Prandtl-Meyer Angle. I'll be very happy if someone want to test it, also on the HP49G+. If you are interested, until the library isn't published on hpcalc.org, I can send You can contact me at kickaha@tiscali.it -- Per rispondere rimuovere il SiPAriuM To reply remove the SiPAriuM ==== I point directly to you my questions because in the Debug4x about window I read that HPTools are copyright by HP Company and you. I know you are sure a very busy people (especially now with this new HP49G+ project), so I hope you can find some little time to answer me. I want to ask for something already posted here and maybe you know where I'm wrong. Original post follows: > I have a doubt about the declarations of local subroutines in the wonderful > Debug4x development system. Surfing throught google past posts I seen that > for declaring a generic subroutine to be local in a source file (*.S) I > should write: > LOCAL MyRoutine > LOCALNAME MyRoutine > :: > ... some code ... > ; > > The automaticaly generated header file for my project haven't now the line: > EXTERNAL MyRoutine > and I think this is right, because I want MyRoutine to be visible only in > its specific module. > The project compiles well, but the program don't work on the emulator. When > recalling such routine I receive either: > - An Interrupted error message > A TTRM > A busy calculator for infinite time. :o) > > Adding break-points don't help me to understand what's wrong, because it > seems the error happens before... > I simply would like to call with the same name two routines in two modules > (because they do similar work and I can simply see from the module name what > are the routines for). Is there a way to do this? Hope you can find some times to answer me. Kickaha ==== >> The automaticaly generated header file for my project haven't now the > line: >> EXTERNAL MyRoutine >> and I think this is right, because I want MyRoutine to be visible >> only in its specific module. This is not related.. EXTERNAL means that this entry will be called using a ROMPOINTER within the module. LOCALNAME can be used when using absolute references, when you call an entry directly by an address. In your case, as you're creating a user library is not possible. Declare it with: NULLNAME MyRoutine So the system will call this entry using a ROMPOINTER. You can still declare the entry as LOCAL with the statement: LOCAL Myroutine at the top of your file or in the header file. ==== >> The automaticaly generated header file for my project haven't now the > line: >> EXTERNAL MyRoutine >> and I think this is right, because I want MyRoutine to be visible >> only in its specific module. > This is not related.. EXTERNAL means that this entry will be called > using a ROMPOINTER within the module. > LOCALNAME can be used when using absolute references, when you call an > entry directly by an address. In your case, as you're creating a user > library is not possible. First of all thank.you for answering me... I know you are a busy person... Also thank.you for the explanation... can you point me to more references to these arguments > Declare it with: > NULLNAME MyRoutine > > So the system will call this entry using a ROMPOINTER. > You can still declare the entry as LOCAL with the statement: > LOCAL Myroutine at the top of your file or in the header file. The problem is that if I write in the header file: LOCAL MyRoutine when I rebuild the project the Debug4x environment automatically changes LOCAL MyRoutine in EXTERNAL. MyRoutine If I declare LOCAL MyRoutine in the module AFTER the INCLUDE Header.h statement I get the error Cannot make local (I guess because the Debug4x has replaced in the header the LOCAL MyRoutine with EXTERNAL MyRoutine). If I declare LOCAL MyRoutine in the module BEFORE the INCLUDE Header.h statement I get the error Illegal symbol re-use (and still LOCAL references n the header has changed into EXTERNAL). Where I'm wrong? Is there a setting to avoid automatic build of the header file? Kickaha ==== > If I declare LOCAL MyRoutine in the module AFTER the INCLUDE Header.h > statement I get the error Cannot make local (I guess because the Debug4x > has replaced in the header the LOCAL MyRoutine with EXTERNAL MyRoutine). > If I declare LOCAL MyRoutine in the module BEFORE the INCLUDE Header.h > statement I get the error Illegal symbol re-use (and still LOCAL > references n the header has changed into EXTERNAL). > > Where I'm wrong? Is there a setting to avoid automatic build of the header > file? > > Kickaha Sounds like a Debug4x bug. I will look into it when I have some time. You cannot stop the automatic header build but you could remove the INCLUDE Header.h from the routine which has the LOCAL definition. You would then have to manually copy in the correct parts from the header. This would let you keep working. -- - - - - - - - - - - - - - - - - Bill Graves RKBA! bgraves@ix.netcom.com ==== William Graves ha scritto nel messaggio ...(SNIP)... > Where I'm wrong? Is there a setting to avoid automatic build of the header > file? > > Kickaha > > Sounds like a Debug4x bug. I will look into it when I have some time. kickaha@tiscali.it > You cannot stop the automatic header build but you could remove the INCLUDE > Header.h from the routine which has the LOCAL > definition. You would then have to manually copy in the correct parts from the header. > This would let you keep working. This is so uncomfortable :o( I've already named routines with different names in different modules even if they do similar taks because I haven't been able to solve the problem. So I think I'll keep this different names instead of declaring the external rotuines in each module removing INCLUDE Header.h or including another header file. Hope you could find time to dig into this problem (and release a bug-fix if it's the case); it's not so important but anyway if fixed the Debug4x will be improved. Kickaha ==== Kickaha, I have looked at Debug4x and the problems you have experienced. I have read the previous comments and they seem confusing. JYA is the real expert on these matters BUT what was given previously in this thread does not match what I see with the HPTools. A library has to have all its entries called via ROMPTRS. The EXTERNAL tag is needed to force DOROMP for all references to tag. LOCAL tag will not generate the needed DOROMP when tag is referenced. Also xNAME, NULLNAME etc is needed to force a value into the hash table or the ROMPTR entry numbers. If you do not use one of these, you get no entry in the table for use with the DOROMP calls. This will then generate an error message because the entry is not defined. So far, then, you must use both EXTERNAL and xNAME etc. However, if you do use xNAME, NULLNAME etc, tag will be a global label and your desire for restricting the name space has failed. I do not think you can do what you wish. JYA may know something I do not. However, LOCALNAME tag or LOCAL tag will only create conflicts with the earlier lines, as you have seen in your trials. My conclusions: 1. Anything defined with EXTERNAL and xNAME (etc) will be a global name. This cannot be changed to only a locally known name. 2. Debug4x current behaviour is correct - actually this is forced by the HPTools which Debug4x calls. 3. Restricting the name space to one source module of a library does not seem possible based on the above. I agree this could have been done differently but the tools are now very old and changes kill old code! JYA: if I missed something, please let me know. I could not get the HPTools to do what was previously shown in this thread! Author of Debug4x. -- - - - - - - - - - - - - - - - - Bill Graves RKBA! bgraves@ix.netcom.com > Declare it with: > NULLNAME MyRoutine > > So the system will call this entry using a ROMPOINTER. > You can still declare the entry as LOCAL with the statement: > LOCAL Myroutine at the top of your file or in the header file. > The problem is that if I write in the header file: > LOCAL MyRoutine > when I rebuild the project the Debug4x environment automatically changes > LOCAL MyRoutine in EXTERNAL. MyRoutine > > If I declare LOCAL MyRoutine in the module AFTER the INCLUDE Header.h > statement I get the error Cannot make local (I guess because the Debug4x > has replaced in the header the LOCAL MyRoutine with EXTERNAL MyRoutine). > If I declare LOCAL MyRoutine in the module BEFORE the INCLUDE Header.h > statement I get the error Illegal symbol re-use (and still LOCAL > references n the header has changed into EXTERNAL). ==== William Graves ha scritto nel messaggio > Kickaha, > I have looked at Debug4x and the problems you have experienced. I have read the > previous comments and they seem confusing. JYA is the real expert on these > matters BUT what was given previously in this thread does not match what I see with the > HPTools. It seems we posted near at the same time :o) > A library has to have all its entries called via ROMPTRS. > The EXTERNAL tag is needed to force DOROMP for all references to tag. > LOCAL tag will not generate the needed DOROMP when tag is referenced. Ok... probably JYA explained it to me in previous posts, but I missed the point... what I've understood is that a DOROMP is needed to call commands from libraries > Also xNAME, NULLNAME etc is needed to force a value into the hash table or the > ROMPTR entry numbers. If you do not use one of these, you get no entry in the table > for use with the DOROMP calls. This will then generate an error message because the > entry is not defined. What is this hash table? If I understood wellm, it is a table for the library to know the addresses (or the names for those addresses) where commands can find other commands. Is this right? Could you point me to some documents? Have I to read more carefully the HPTools documentation? ---(SNIP some discussions on LOCAL)--- > My conclusions: > 1. Anything defined with EXTERNAL and xNAME (etc) will be a global name. This > cannot be changed to only a locally known name. Agree: I've experienced it. :o) > 2. Debug4x current behaviour is correct - actually this is forced by the HPTools which > Debug4x calls. I still think Debug4x is a great Development Environment.. it has a lot of facilities, even with this small uncomfortable behaviour > 3. Restricting the name space to one source module of a library does not seem possible > based on the above. I agree this could have been done differently but the tools are now > very old and changes kill old code! I can understand this. HP released HPTools for free, so the code wasn't updated. Probably also this updating is unneeded because - I guess - the architecture of hp calcs seems the same from the 48(SX?) and is based on the RPL... I can't imagine the big effort that produced so many years ago the architecture of the calcs we still use nowadays! It's a storming thought for me! Maybe I'm the first to experience this problem because I don't well understand how HPTools and the hp machines work and, coming from modern computer languages, I assumed things not obvious on the hp calcs! An experienced programmer probably don't even tried to do a thing like this with HPTools! :o) I've to study more! BTW I will like to thank you and JYA for your work and all the wonderful contributions you gave, give and will give to our community. Kickaha ==== One would expect that pressing EVAL in the filer of the 49+ would eval the scanned object. But it does order w.r.t. names as on the 49. EVAL is executed on 44.3 (CAT on the 49+). This corresponds precisely to the 49 but is clearly contra-intuitiv on the 49+. I refer to ROM 1.20. Putting EVAL on 42.1 is no problem. But this conflicts with name sorting. OK, the latter could be done by 42.4 (alpha-shift). But then there will arise another problem. Name sorting is presently hardcoded in the 49-filer on the keys 42.1 and 42.4. Thus, filers of the 49 and 49+ either cannot be the same (hence, no common rom in future) or a new common filer has to be created which is less easy. - Wolfgang PS. For the above reason I must postpone the publication of an alternative filer for the 49+. It was already prepared. Unfortunately, I did not know about the permutation of EVAL and CAT. ==== > - Wolfgang > PS. For the above reason I must postpone the publication of an > alternative filer for the 49+. It was already prepared. Unfortunately, I > did not know about the permutation of EVAL and CAT. roms ? With my HP49G ROM 1.19-6, the filer displays a highlighted box out of order when launched from the hidden directory... Yoann D.8esir (yoanndesir@yahoo.com) ==== > One would expect that pressing EVAL in the filer of the 49+ would eval > the scanned object. But it does order w.r.t. names as on the 49. EVAL is > executed on 44.3 (CAT on the 49+). This corresponds precisely to the 49 > but is clearly contra-intuitiv on the 49+. I refer to ROM 1.20. This flaw has meanwhile be fixed in Filer5 on my site below which is for prefer doing advanced programming on the calculator while sitting in an armchair) does not yet run on the HP49+. Filer5 has only 1.6 KB and IMHO an optimal filer for a high-quality calc. It has a 2-page menu with several features not on the builtin filer, e.g., an informator in the menu showing the active hardkeys. Since EVAL returned to a prominent place, the info screen differs slightly from the screen of my HP49-filers. The new EVAL key (N) really evals (not so in ROM 1.20). Name sorting is on rightshift EVAL (where is it in the builtin Filer?) Sorting files with respect to name, size or type is phantastically fast even if you have dozens of files in HOME or Port2 or perhaps Port3. And there is a version informator on key V (including ROM and CAS versions). You can play music or games on the baby without leaving the filer at all. Apropo music. Unfortunately, MIG does not work anymore on the HP49g+. No Play-Bach at present, simply because the machine is too fast :-) Also most greyscale grob viewers have to be revised. - Wolfgang ftp://ftp.math.fu-berlin.de/pub/usr/raut/HP49/tools/Filers/Filers.htm ==== Those you have already a HP49+ should have a look in a new library called Msgman, a small but powerful message manager. You can find each of the thousands of builtin messages for use in your own programs. Many of these messages are language-sensitive. E.g., the message searcher FndM which normally displays searching ... will show cherche ... if switching to French. Everything is on my site. Browse Msgman.htm below, no obligation to load anything. In the last screen-shot of Msgman.htm you'll see the messages of the builtin lib 257 (MASD), written in exciting Franglais. For instance, Insuffisant Memory, really suffisant ... Forgiven! It is well-known that French hate foreign languages, in particular Enlish and German. - Wolfgang http://www.math.fu-berlin.de/~raut/WR49/Msgman.htm ==== I got an HP-100LX today. It's quite an interesting machine. The one I got doesnt have a backup-battery tray. Do any of you know where I can get one? Is there anyway I can turn off the annoying low backup battery message until I do get one? ==== +----------------------------------------------+ | Sun, 21.9.03 10:24 a.m. +1200 (NZT) | +----------------------------------------------+ in message ID <91017fd2.0309201251.10e1adda@posting.google.com> : > I got an HP-100LX today. It's quite an interesting > machine. The one I got doesnt have a backup-battery tray. Do > any of you know where I can get one? Is there anyway I can > turn off the annoying low backup battery message until I > do get one? http://www.palmtop.net Search on killmsg You will find KILLMSG.ZIP (3K), and inside a BIOS Message Killer by Mack Bagette. -- Tony Hutchins Wellington New Zealand #116 Do not use a hatchet to remove a fly from your friend's forehead. Chinese Proverb ==== -=[ Sun, 21.9.03 11:45 a.m. +1200 (NZT) ]=- in message ID <91017fd2.0309201251.10e1adda@posting.google.com> : > I got an HP-100LX today. It's quite an interesting machine. The one I > got doesnt have a backup-battery tray. Do any of you know where I can > get one? Is there anyway I can turn off the annoying low backup > battery message until I do get one? Oops I forgot about the battery-tray. Best thing is to join fabricate one - it just holds the backup battery in place. To join hplx-l, just send a message like this: ---- subscribe hplx-l --- The subject doesn't matter. It's a fairly quiet list (no more than 5-10 a day), but folk are very helpful and some have lots of spare parts. Also, try www.thaddeus.com - they may have battery trays. -- Tony Hutchins Wellington New Zealand #28 Wife:Whisper something dirty in my ear.Husband:Kitchen. ==== -=[ Sun, 21.9.03 12:14 p.m. +1200 (NZT) ]=- in message ID <10782783ROBOTLX@news.cis.dfn.de> : > Oops I forgot about the battery-tray. Best thing is to join > fabricate one - it just holds the backup battery in place. To > join hplx-l, just send a message like this: Oops some of it got stripped out. The message is sent to listserv@uconnvm.uconn.edu and just has subscribe hplx-l in the body downloaded usenet messages - very cunning! Got me! :( I only with just 120 messages :( -- Tony Hutchins Wellington New Zealand #47 Bother, said Pooh as he got cattle-prodded. ==== ==== I realize this is off topic, but I was hoping someone who lives in the US could recommend a good newsgroup provider. I was using my ISP provider, but as usual, its terrible. I then started using Meganetnews to get access but they're not very good either. Anyone found a great newsgroup provider that they could recommend? -- Douglas Rohm drohm@bellsouth.net ==== > >> >>>It's a good thing the automobile industry doesn't do things this way, >>>or it wouldn't be possible to buy a car with a manual transmission; >>>we'd all be stuck with automatics. >>> >> >>It's a lot harder to buy a manual than you think... > > > Well, I did once deal with a car salesman who just couldn't seem to > believe that I really wanted a manual. He kept trying to talk me into > a different model than the one I wanted, and also kept pointing out > that it had an automatic, even though I kept telling him I didn't WANT > an automatic. I finally gave up and went to another dealer who was > willing to sell me the car I actually wanted to buy. > That's interesting. Here in Sweden, manual transmission is the standard. Automatics are the exceptions (mostly driven by people who really need it, e.g. disabled). ==== > This new Swen worm [...] Got me! :( Same here ... Please note my new address. ==== I don't like what I have been hearing about the power consumption why not add AC power for indoor use to conserve battery power? Off subject, but will it come with a protective carrying case like the TIs? ==== > I don't like what I have been hearing about the power consumption An intermediate unofficial release of 1.21 seemed to had this problem, which is fixed by the latest (unofficial) release of ROM, the 1.22. Any fixes comes out pretty quickly for this new calc - even before it is released in the USA market! > why not add AC power for indoor use to conserve battery power? I would have hoped for an USB power input, BUT you can use an external charger & rechargeable AAA batteries. Keep an extra fresh set of NiMH ready in the charger and switch immediately when the low power indicator shows up. > Off subject, but will it come with a protective carrying case like the TIs? With every HP 49G+ comes a black, stylish real leather hard case with magnetic latch/lock that automagnetically snaps on ==== use a new 49G+ since one week now... It's an amazing device (replaced an old 48S)... I think, there's a bug in the Derivation-Part of the CAS... Enter the following Expression: d --((-2X+3)^100) dX As everybody knows, the result is -200*(-2x+3)^99 My HP produces the following after pressing EVAL: 1267650600228229401496703205376*(100*x^99)-190147590034234410224505480806400 *(99*x^98).... ....and so on until ^100 is down to ^0... When I press ON right after EVAL, the correct expression is shown... Everything set to exact mode, Real, radians. Vars were purged. ROM 1.22 Any ideas (except throwing it in trash)? Pascal ==== +use a new 49G+ since one week now... It's an amazing device (replaced +an old 48S)... +I think, there's a bug in the Derivation-Part of the CAS... +Enter the following Expression: +d +--((-2X+3)^100) +dX +As everybody knows, the result is -200*(-2x+3)^99 +My HP produces the following after pressing EVAL: +1267650600228229401496703205376*(100*x^99)-19014759003423441022450548080640 0*(99*x^98).... +....and so on until ^100 is down to ^0... +When I press ON right after EVAL, the correct expression is shown... +Everything set to exact mode, Real, radians. Vars were purged. +ROM 1.22 +Any ideas (except throwing it in trash)? + Pascal To scale down the problem: d d 2 2 --((-2X+3)^3) = 3*(-2X+3)*--(-2X+3) = 3*(-2X+3) *(-2) = 24*X -72*X+54 dX dx You appear to want the penultimate expression; the HP49G+ gave you the ultimate expression. The expressions are mathematically equivalent. I believe that same is true of your original result. Randolph J. Herber, herber@dcdrjh.fnal.gov, +1 630 840 2966, CD/CDFTF PK-149F, Mail Stop 318, Fermilab, Kirk & Pine Rds., PO Box 500, Batavia, IL 60510-0500, USA. (Speaking for myself and not for US, US DOE, FNAL nor URA.) (Product, trade, or service marks herein belong to their respective owners.) ==== > As everybody knows, the result is -200*(-2x+3)^99 > > My HP produces the following after pressing EVAL: > > 1267650600228229401496703205376*(100*x^99)- > 190147590034234410224505480806400*(99*x^98).... > > .....and so on until ^100 is down to ^0... > That's because you expect the 49G+ to give you the same result as your HP48SX. When you press EVAL the result will be fully developped. To get the same result as the HP48SX use RPN argument for example: '(-2X+3)^100' 'X' d And you'll get what you expect Otherwise, both result are mathematically equivalent ==== >That's because you expect the 49G+ to give you the same result as your >HP48SX. Without an X - it's really old ;-) >When you press EVAL the result will be fully developped. Grmpf! >And you'll get what you expect You're right... The user was too dumb to use his device... Sorry, Pascal ==== >>That's because you expect the 49G+ to give you the same result as your >>HP48SX. > Without an X - it's really old ;-) The HP48SX came out before the HP48S, actually. :D -Josh -- -Joshua Belsky jjbelsky@yahoo.com http://belsky.net ==== > Without an X - it's really old ;-) Actually, you would be surprised to know then that the 48S is newer than the 48SX by a few months! ==== >Actually, you would be surprised to know then that the 48S is newer than >the 48SX by a few months! Hmmm... OK... But it' too old to solve some really simple things (eg. Bi-Quadratic Expressions, which are solved completely wrong)... But.... Back to HP49g+ and a bit OT in this thread... Have you ever tried to Integrate the result of my derivation expample? I enter x and press RightShift and TAN... I stopped the process after 45 Minutes - by reset, ON was not responding, that's too long for a simple integration... What's my mistake? Did I use the wrong function, or is there something different... If the function doesn't contain something like x^a, everything works fine... I also can't press EVAL after derivating my example (to collect 2*100 which works with all other functions, i tried)... It results in really long process... Any ideas? And, another one that drives me crazy... The Equation is: 2x^2+3y^2=14 if I solve for x or y, the result is { } everytime... Every lower grade student can solve that by hand and there _is_ an result (and a really easy one)... I've only checked Simp Non-Rational in CAS-Settings, all other settings untouched... Ahhh... I have to mention... My not so old HP48S can solve that simple expression... And the result looks quite good... So long, Pascal ==== >The Equation is: 2x^2+3y^2=14 if I solve for x or y, the result is { } >everytime... Every lower grade student can solve that by hand and >there _is_ an result (and a really easy one)... Just to mention... After turning complex mode on, a solution can be solved... But, there's nothing complex in that function... Can't see any j (or i, for the mathematics) in the equation... Pascal ==== > >The Equation is: 2x^2+3y^2=14 if I solve for x or y, the result is { } > > Just to mention... After turning complex mode on, a solution can be > solved... It considers y to be near +infinity, and therefore thinks the result would in the end turn out to be complex. Look here for the original post by Mr. Parisse: http://groups.google.com/groups?selm=3A9364A1.8197BDDF%40fourier.ujf-grenobl e.fr - Thomas -- foo and bar, respectively. ==== >It considers y to be near +infinity, and therefore thinks the result >would in the end turn out to be complex. &#$¤%! Argl! Sorry... I can't believe in that! HP is not able to solve that problem? Too complex? So I have to check both versions - real _and_ complex before choosing a result? Oh Lord! Pascal Maybe that integration problem is something similar... ==== >>It considers y to be near +infinity, and therefore thinks the result >>would in the end turn out to be complex. > > > > &#$¤%! Argl! Sorry... I can't believe in that! HP is not able to solve > that problem? Too complex? > So I have to check both versions - real _and_ complex before choosing > a result? No, you should be in complex mode if you search roots of polynomials with parameters. Y is assumed to be near +infinity or near 0 depending on the flag increasing/decreasing power, therefore the calc answer in real mode has to be empty in the first case. ==== >No, you should be in complex mode if you search roots of polynomials >with parameters. Y is assumed to be near +infinity OK, I read that in yor original post some time ago... But, the result will also solved with Incr. Pow checked - even when in real mode... Why is there no complex mode needed? There a bug somewhere... Same problem with some internal tools when FM is checked to switch between . and , as decimal delimiter. Pascal ==== > > >>No, you should be in complex mode if you search roots of polynomials >>with parameters. Y is assumed to be near +infinity > > > OK, I read that in yor original post some time ago... But, the result > will also solved with Incr. Pow checked - even when in real mode... > Why is there no complex mode needed? > There a bug somewhere... > no, because in this case Y is assumed to be near 0 hence (13-3*Y^2)>=0 and the sqrt is real. If incr. power is not checked then Y is assumed to be near +infinity, where (13-3*Y^2)<0 and has no sqrt in R. ==== I recently had an opportunity to experiment with a 49g. It was the first RPN entry calculator that I have used - all of the calculators that I have owned are algebraic TIs. Within minutes, I was hooked on RPN. In fact, I was so impressed that I am planning to obtain the new 49g+ as soon as it reaches North America. In an attempt to become more familiar with its operation, I have been playing around with a 49g emulator. There are a couple things that I am used to being able to do on my TIs that I cannot figure out how to accomplish on the HP: 1) On the TIs, when graphing, you can set the X and Y scale - the space between each tick mark, expressed in terms of the variable's value. If the range of a graph was Y=-10..10, with a Y-scale of 10, there would be two tick marks; if the graph was then zoomed out to -20..20, there would be four. On the HP, the tick marks are measured according to pixels (as far as I can tell); they do not match up with the values of the variable in any way, and do not change when the graph is zoomed in or out. I'm presuming that this behaviour is the same in the new 49g+. Is there any way to get it to place tick marks based on the variable, a la the TIs? 2) The TIs provide various zoom functions that automatically adjust the dimensions of a graph to fit functions and scatter plots. These functions require no user input, and automatically adjust both the displayed X and Y ranges. The closest match that I can find on the 49g is the AUTO function in the 2D/3D setup menu. However, this requires first determining the minimum and maximum values for either X or Y. Is there any function that will automatically determine optimal viewing settings that does not require the user to first enter one of the two ranges? If not, has this functionality been provided by user-created programs? James ==== Regarding the 49G and 49g+, James asked: > Is there any way to get it to place tick marks > based on the variable, a la the TIs? At the bottom of the 2D/3D Plot Setup screen, you'll see H-Tick, V-Tick, and Pixels. Set the desired horizontal and vertical tick spacing there, and turn off the Pixels option so that the tick spacing corresponds to the values along the axes rather than to the number of pixels. If you don't see those options at the bottom of the 2D/3D screen, go to the top of that screen and select a plot type for which tick marks makes sense (e.g. Function). Hope this helps! -Joe- ==== > At the bottom of the 2D/3D Plot Setup screen, you'll see H-Tick, > V-Tick, and Pixels. Set the desired horizontal and vertical tick > spacing there, and turn off the Pixels option so that the tick spacing > corresponds to the values along the axes rather than to the number of > pixels. Well... duh! *bonks forehead against wall* For some reason, my eyes weren't seeing the Pixels option. James ==== >> At the bottom of the 2D/3D Plot Setup screen, you'll see H-Tick, >> V-Tick, and Pixels. Set the desired horizontal and vertical tick >> spacing there, and turn off the Pixels option so that the tick spacing >> corresponds to the values along the axes rather than to the number of >> pixels. > Well... duh! *bonks forehead against wall* For some reason, my eyes > weren't seeing the Pixels option. Don't feel bad, James -- you're not the only one. Even after Joe's very clear explanation, I hunted around for several minutes before finding the Pixels option -- and I've actually *used* that option before! (Part of the problem for me is that I almost always use the left-shift Plot and softkeys method, rather than right-shift Plot with the choose menus, and I only tried the menus after poking around on the softkeys for a while without finding that option.) -- Wayne Brown | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== First of all how do you graph vertical lines on the 49G like X=5? Second is there a program or built in feature that allows you to graph linear inequalities like Y>2X-2. Lastly is there any program to do linear programing so that the calc gives you the min and max of a function given the constraints? Thanxz in Advance CID ==== > First of all how do you graph vertical lines on the 49G like X=5? That's a horiziontal line. I have no idea how to graph vertical lines - why do you need to? > Second is there a program or built in feature that allows you to graph > linear inequalities like Y>2X-2. not that I know of - check HPcalc.org. > Lastly is there any program to do > linear programing so that the calc gives you the min and max of a > function given the constraints? I have some simple programs at http://alpage.ath.cx/hptute/hpprog.htm. One of them, CP (Critical Points) should fit the bill. You give it a function in terms of X and it tells you the critical points, their values, and type (eg a min or max). It does not test the limits, but thats easy to do yourself. > > > Thanxz in Advance no probs, Al ==== > First of all how do you graph vertical lines on the 49G like X=5? Not in the FUNCTION graphing process. You need in my opinion to draw the graph using the TRUTH or PARAM option. But of course, it can be drawn on a HP49. > Second is there a program or built in feature that allows you to graph > linear inequalities like Y>2X-2. Yes : the TRUTH plotting type. > Lastly is there any program to do > linear programing so that the calc gives you the min and max of a > function given the constraints? Well, getting the min and the max of a function is easy : just draw the fuction, then use the FCN menu icon and EXTR. Bye, Yoann. ==== > Well, getting the min and the max of a function is easy : just draw > the fuction, then use the FCN menu icon and EXTR. Does this allow you to enter constraints? -- Bhuvanesh ==== Al Borowski skrev i melding > First of all how do you graph vertical lines on the 49G like X=5? > > That's a horiziontal line. > > I have no idea how to graph vertical lines - why do you need to? > > > Second is there a program or built in feature that allows you to graph > linear inequalities like Y>2X-2. > > not that I know of - check HPcalc.org. Just use the puilt-in plotting function of the calc. 1 if the expression is true and 0 if not. > Lastly is there any program to do > linear programing so that the calc gives you the min and max of a > function given the constraints? > > I have some simple programs at http://alpage.ath.cx/hptute/hpprog.htm. > > One of them, CP (Critical Points) should fit the bill. You give it a > function in terms of X and it tells you the critical points, their > values, and type (eg a min or max). > > It does not test the limits, but thats easy to do yourself. > > > > Thanxz in Advance > > no probs, > > Al > ==== You can move the cursor close to the extreme you want (min or max), I usually just put it within ten pixels and it works fine. >> Well, getting the min and the max of a function is easy : just draw >> the fuction, then use the FCN menu icon and EXTR. > > Does this allow you to enter constraints? > > -- > Bhuvanesh -- ==== > First of all how do you graph vertical lines on the 49G like X=5? > > That's a horiziontal line. > Actually, it's a vertical line; X=5 no matter what Y is. Try plotting it by hand, and you'll see. The HP won't graph it as a function because technically it isn't a function. If you convert it to a polar graph, it'll plot it. A polar plot of 'R1(X)=5/cos(X)' will give you a vertical line going through where X=5 would normally be (were it not a polar graph). There's a way to do it as a parametric plot, but I can't remember off-hand how the 49 wants to see parametric equations. It's got something to do with complex numbers, but I've never really had to use it, so I don't know how. --CS ==== > > >>>First of all how do you graph vertical lines on the 49G like X=5? >>> >>> >There's a way to do it as a parametric plot, but I can't remember >off-hand how the 49 wants to see parametric equations. It's got >something to do with complex numbers, but I've never really had to use >it, so I don't know how. > You should be able to do a vertical line at x=5 in a parametric plot like: x: '5' y: '100*(t-1) tmin: 0 tmax: 2 How you set up 'y' will be determined by what your t-range is. I dont know what the default range is, but basically, to see a vertical line, you have to choose a t-range and / or y expression such that it goes from y_min to y_max. Aaron ==== Thanxz the truth plot works work great except for one flaw. It takes FOREVER to shade in the graph. Can I speed up this process in any way? Thanxz, CID ==== O yeah I forgot to say my step is 5 and I have checked pixels. ==== > > First of all how do you graph vertical lines on the 49G like X=5? > > That's a horiziontal line. > > Actually, it's a vertical line; X=5 no matter what Y is. Try plotting > it by hand, and you'll see. > oops, you're right. I read that as Y = 5 :-p cheers, Al ==== > how do you graph vertical lines on the 49G like X=5? After 'PPAR' PURGE: Try a FUNCTION (default) type plot of '1E499*(X-5)' FUNCTION '1E499*(X-5)' STEQ ERASE DRAX DRAW PICTURE Or a PARAMETRIC type plot of '(5,X)' PARAMETRIC '(5,X)' STEQ ERASE DRAX DRAW PICTURE Or just draw a LINE: (5,-3.1) (5,3.2) ERASE DRAX LINE PICTURE Or, borrow a barometer, tie it to the end of a string, go to the top of a building, hold the string 5 units away from the side of the building as you lower the barometer, etc. http://cns.physics.gatech.edu/~andreas/physicsfun/barometer.html http://www.mum.edu . ==== > is there a program or built in feature that allows you to graph > linear inequalities like Y>2X-2. Faster than a speeding TRUTH plot: Using the SHADE plotting function: (perhaps someone can find the equivalent LIBEVAL or FLASHEVAL) http://groups.google.com/groups?selm=3B863B08.2039517%40miu.edu Using Jim Donnelly's INPLOT program: http://groups.google.com/groups?selm=3B8695A1.3173982D%40miu.edu The moon is more useful than the sun, because the moon shines at night when you want the light, whereas the sun shines during the day when you don't need it. My Gran'pa used to tell us almost the same thing: You's kin make a heap mo' money sellin' moonshine than sunshine :) [r->] [OFF] ==== 1.- i use to use 'trunc' in order to see the final result of calculations, however, if the mode cylindric in on and i try to 'trunc' a complex number, it isn't truncated anymore, is there any workaround to achieve this?. 2.- How is name lookup carried accomplished in a program?, if a have a local variable in my program and i have another (differents) programs all along the directory, how is some 'name' in my program searched, i mean: << 2 hola >>, but hola could be a command, a local variable or several programs of mine in several folders. 3.- At the top of my screen i have the number 2, the manual indicates that it's a user indicative, but it doesn't say anymore (or at least, i haven't yet seen it). Any hint will be wellcome. ==== The 2 means that user flag 2 is set. To clear it do the following: Press 2 ENTER, then turn on alpha mode by presing the alpha key twice. Then press the 'C' key then the 'F' key. The press ENTER. rdb. > 3.- At the top of my screen i have the number 2, the manual indicates that > it's a user indicative, but it doesn't say anymore (or at least, i haven't > yet seen it). Any hint will be wellcome. > ==== Just to advertise a similar (but more mature) product (not on offer for inclusion in ROM): http://www.hpcalc.org/details.php?id=4515 Roger Saravia schreef in bericht > Dear Gurus: > > I had worked so hardly developing a software related to structural > analysis. This program needs only about 6200 bytes of RAM and is > capable to solve the most complex plane structures using the finite > element method. Furthermore, each problem can be entered easily using > the matrix writer of the calculator. Besides, this software can > report all analysis data in a matrix format letting the user make any > calculation with the results. This program has been tested and > produce 100% precission guaranted results. Finally, my real intention > is offer this software for the ROM of the next calculators generation > because its features. Please, I let me invite you visit this site: > > http://www.geocities.com/rgrsrv/kar > > > Roger Saravia > Structural Civil Engineer > La Paz - Bolivia ==== Maybe Caspar and Eva don't know much about the world of structures in civil engineer. I will let me compare my software versus the respectable software suggested by Caspar and Eva: Kardestuncer software just needs only about 6 K of RAM (versus 74 K of the other) * Kardestuncer can solve also grids (the other doesn«t solve grids) * Kardestuncer has a easily way for entering the data like the traditional professional PC programs (the other doesn«t have a easily way). I have more argument but I will finish here, Roger. > Just to advertise a similar (but more mature) product (not on offer for > inclusion in ROM): > http://www.hpcalc.org/details.php?id=4515 > > > > > Roger Saravia schreef in bericht > Dear Gurus: > > I had worked so hardly developing a software related to structural > analysis. This program needs only about 6200 bytes of RAM and is > capable to solve the most complex plane structures using the finite > element method. Furthermore, each problem can be entered easily using > the matrix writer of the calculator. Besides, this software can > report all analysis data in a matrix format letting the user make any > calculation with the results. This program has been tested and > produce 100% precission guaranted results. Finally, my real intention > is offer this software for the ROM of the next calculators generation > because its features. Please, I let me invite you visit this site: > > http://www.geocities.com/rgrsrv/kar > > > Roger Saravia > Structural Civil Engineer > La Paz - Bolivia ==== I did not mean to start a flame war, but now you want to.... True, FEM48/49 does not solve grids, ONLY frames, trusses and continious beams (including beam analysis).... True, FEM48/49 is a bit large (however, it is modular, so 74 kB is not needed at all) and may SEEM to be a bit complex, but hey, most important/significant software is like that. However, FEM48/49 DOES allow for data entry with matrices, just RTFM (and it offers data entry on prompt and with wizards). And, since you labeled your message An important software for the HP48 and the HP company and even offered it for the inclusion in future calculator ROMs you sure created high expectations with everyone (at least with me). Do not be suprised if not everyone is as amazed with your program as you are yourself! (it ususaly works that way, alas) So, 6 kB is sure nice but users will have to have the manual handy to on) seem to have a lot of memory.... why not make a nice user interface etc etc. Caspar, a Structural Engineer who don't know much about the world of structures.... PS: structural engineering software on a calc is mostly (99%) used by students who want to cheat on there exams! Roger Saravia schreef in bericht > Maybe Caspar and Eva don't know much about the world of structures in > civil engineer. > > I will let me compare my software versus the respectable software > suggested by Caspar and Eva: > > Kardestuncer software just needs only about 6 K of RAM (versus 74 K of > the other) > > * Kardestuncer can solve also grids (the other doesn«t solve grids) > * Kardestuncer has a easily way for entering the data like the > traditional professional PC programs (the other doesn«t have a easily > way). > > I have more argument but I will finish here, > > Roger. > > > > Just to advertise a similar (but more mature) product (not on offer for > inclusion in ROM): > http://www.hpcalc.org/details.php?id=4515 > > > > > Roger Saravia schreef in bericht > > Dear Gurus: > > > > I had worked so hardly developing a software related to structural > > analysis. This program needs only about 6200 bytes of RAM and is > > capable to solve the most complex plane structures using the finite > > element method. Furthermore, each problem can be entered easily using > > the matrix writer of the calculator. Besides, this software can > > report all analysis data in a matrix format letting the user make any > > calculation with the results. This program has been tested and > > produce 100% precission guaranted results. Finally, my real intention > > is offer this software for the ROM of the next calculators generation > > because its features. Please, I let me invite you visit this site: > > > > http://www.geocities.com/rgrsrv/kar > > > > > > Roger Saravia > > Structural Civil Engineer > > La Paz - Bolivia ==== Dear Gurus: I had worked so hardly developing a software related to structural analysis. This program needs only about 6200 bytes of RAM and is capable to solve the most complex plane structures using the finite element method. Furthermore, each problem can be entered easily using the matrix writer of the calculator. Besides, this software can report all analysis data in a matrix format letting the user make any calculation with the results. This program has been tested and produce 100% precission guaranted results. Finally, my real intention is offer this software for the ROM of the next calculators generation because its features. Please, I let me invite you visit this site: http://www.geocities.com/rgrsrv/kar Roger Saravia Structural Civil Engineer La Paz - Bolivia ==== This ODE was recently posed as a challenge on www.hpmuseum.org by Valentin Albillo. y'=x^2 + y^2 y(0)=0 Find y(2) It is really tricky. The actual answer is: y(2)=317.7224607575... I tried it on both the HP49G and hp49g+ in the Solve diff eq. application under NUM.SLV, using the defaults for Tol:.0001 and Step:Dflt. BTW if anyone knows exactly what the default Step is I'd like to know. The new hp49g+ manual is really good, but I couldn't find exactly what that step is. I suspect it is really small. So, the NUM.SLV screen looks like: F: SQ(X)+SQ(Y) Indep:X Init:0 Final 2 Soln: Y Init:0 Final ? We solve for Final Y. On both machines we get 319.942 The HP49G took 2 minutes 25 seconds and the hp49g+ took only 40 seconds!!! So the 49g+ is 3.6 times faster!! I don't think it is possible to get any closer to the answer of 317.7225 without transforming y. I was actually really surprised to see how close the calcs got, with default settings. If anyone can get a closer answer, without transforming the equation, I'd be really interested. I am not quite sure exactly how the RKF method works - every adjustment I tried made the answer wander further afield. - Tony ==== > I don't think it is possible to get any closer to the answer > of 317.7225 without transforming y. I was actually really > surprised to see how close the calcs got, with default Transformation would not help since the approach is numerical. If you increase the tolerance to 0.0000001 then you get (after a while :-( 317.729... Happy computing :-) !Demeter! ==== +----------------------------------------------+ | Mon, 15.9.03 8:09 p.m. +1200 (NZT) | +----------------------------------------------+ in message ID <5bff2c2e.0309142307.794271f7@posting.google.com> : > > I don't think it is possible to get any closer to the answer > of 317.7225 without transforming y. I was actually really > surprised to see how close the calcs got, with default > > Transformation would not help since the approach > is numerical. I could be wrong here, but I think transformation can speed up the numerical approach. If, for example you examine the slope-field and manage to approximate the functional form of the answer the equation can almost be transformed to y'=1, which makes numerical solution easier :) > If you increase the tolerance to > 0.0000001 then you get (after a while :-( 317.729... That must take a while indeed ;-) I wanted to get nearer 317.7225. Actually I guess reducing the tolerance still further may achieve this but will take a long time. As it is the y' starts at 0 and ends up at about 2^2 + 317^2 or 100,492 which is a steep gradient. On the hp49g+ , using Tolerance of E-10, and the transformation the Valentin used: y=TAN(z), the equation becomes z'=(x^2 + TAN^2(z))/(1+TAN^2(z)). In NUM.SLV I tried '(SQ(X)+SQ(TAN(Y)))/(1+SQ(TAN(Y)))' and in just under a minute got a value near Pi/2, then ON TAN gave me 317.722459904 which rounds well to 317.72246. It is only E-6 too low. On the HP49G that would take 4 minutes For the above transformation the transformed Y' varies from 0 up to about 1 (as the TAN parts dominate). So, there is not as much slope variation as in the original, and this should make numerical slope-following methods work better. It sure seemed a lot faster for the default tolerance - just a few seconds as against 40. -- Tony Hutchins Wellington New Zealand ==== The way you phrased it seemed as though you thought it was impossible to get an accurate enough answer without transformation while what you really meant was doing it in less time! ;-) !Demeter! ==== > On the hp49g+ , using Tolerance of E-10, and the > transformation the Valentin used: y=TAN(z), the equation > becomes z'=(x^2 + TAN^2(z))/(1+TAN^2(z)). In NUM.SLV I tried > '(SQ(X)+SQ(TAN(Y)))/(1+SQ(TAN(Y)))' and in just under a minute > got a value near Pi/2, then ON TAN gave me 317.722459904 which > rounds well to 317.72246. It is only E-6 too low. It's even closer than that. Here are sixteen digits, using Mathematica: 317.7224606757503 Scott -- Scott Hemphill hemphill@alumni.caltech.edu This isn't flying. This is falling, with style. -- Buzz Lightyear ==== +----------------------------------------------+ | Tue, 16.9.03 10:24 a.m. +1200 (NZT) | +----------------------------------------------+ in message ID <5bff2c2e.0309150727.43e3a9e3@posting.google.com> : > > The way you phrased it seemed as though you > thought it was impossible to get an accurate enough > answer without transformation while what you really > meant was doing it in less time! ;-) Deneter, you are 100% correct and I thank you for your insight into this. Indeed it is just a matter of time, and there is virtually nothing in it as far as accuracy goes. Very interesting! I was thinking that the numerical method would suffer from high calculator roundoff error, and also maybe have convergence problems of its own, if it took a long long time. But then again the transformation y=TAN(x) itself has a very high derivative near Pi/2 and so a small change in x means a large change in y giving a limitation on the accuracy in the transformed answer. We can't win, except in time ;-) I just tried Tol=E-10 with the raw x^2 + y^2 and after 5.5 minutes on the 49g+ (would take about 20 on the 49G) got y(2)=317.722455297. This is starting to look very much like 317.72246 ... E-11 gives 317.722458318 after 9 minutes and E-12 gives 317.722446669 after 15.5 minutes. In view of the internal accuracy of the 49 I guess a tolerance of less than E-10 is a bit silly on my part, and the answers start to wobble about. We are left with the 317.72246 I think. E-20 would be a good way to test my 49g+ batteries. I would not have investigated this without the 49g+ though - it does have a speed advantage over the 49G :) Using the TAN transformation with tolerance E-10 I got 1.56764893615 after 90 seconds and TAN=317.722459904. Adding 1 in the last place, TAN(1.56764893616)=317.722460913. So, the transformation itself limits us to 317.72246. TAN jumps around the answer in a leap of 1009 units in the last place!! Yes, you are 100% correct - there is really no significant advantage in accuracy by using the transformation. I never expected that! -- Tony Hutchins Wellington New Zealand #51 (A)bort, (R)etry, (F)ail, (I)nfluence with large hammer. ==== +----------------------------------------------+ | Tue, 16.9.03 11:29 a.m. +1200 (NZT) | +----------------------------------------------+ in message ID : > > On the hp49g+ , using Tolerance of E-10, and the > transformation the Valentin used: y=TAN(z), the equation > becomes z'=(x^2 + TAN^2(z))/(1+TAN^2(z)). In NUM.SLV I tried > '(SQ(X)+SQ(TAN(Y)))/(1+SQ(TAN(Y)))' and in just under a minute > got a value near Pi/2, then ON TAN gave me 317.722459904 which > rounds well to 317.72246. It is only E-6 too low. > > It's even closer than that. Here are sixteen digits, > using Mathematica: > > 317.7224606757503 original post :( So, the 49g+ answer I have above is 8E-7 below. I must have rounded that to E-6 :) Did Mathematica get that by a numeric method, or by evaluating the symbolic solution with Bessel functions in? It would be very cool if the 49g+ could do that. Valentin mentioned the name Riccati in connection with the symbolic solution to this type of ODE. -- Tony Hutchins Wellington New Zealand #304 Words form the thread on which we string our experiences. Aldous Huxley ==== > > Did Mathematica get that by a numeric method, or by evaluating > the symbolic solution with Bessel functions in? It would be > very cool if the 49g+ could do that. Valentin mentioned the > name Riccati in connection with the symbolic solution to > this type of ODE. Have a look at this interesting document (PDF format): http://www.prenticehallmath.com/epdela/laprojects/chapt11/proj11.4/proj11-4. pdf It does discuss and solves (both symbolically and numerically) this particular equation and several other related ones. ==== > > transformation the Valentin used: y=TAN(z), the equation > > becomes z'=(x^2 + TAN^2(z))/(1+TAN^2(z)). In NUM.SLV I tried > > '(SQ(X)+SQ(TAN(Y)))/(1+SQ(TAN(Y)))' and in just under a minute > > got a value near Pi/2, then ON TAN gave me 317.722459904 which > > rounds well to 317.72246. It is only E-6 too low. > > It's even closer than that. Here are sixteen digits, > using Mathematica: > > 317.7224606757503 > > original post :( > > So, the 49g+ answer I have above is 8E-7 below. I must have > rounded that to E-6 :) > > Did Mathematica get that by a numeric method, or by evaluating > the symbolic solution with Bessel functions in? It would be > very cool if the 49g+ could do that. Valentin mentioned the > name Riccati in connection with the symbolic solution to > this type of ODE. I told it to solve it numerically, and gave it a target accuracy of 21 digits. The procedure failed with 22 digits. If I had read the thread on www.hpmuseum.org, I probably wouldn't have bothered. :-) On the other hand, if I had done enough homework, then I would have used Mathematica to obtain a symbolic solution, and given many more digits, e.g. 100: 317.72246067575030839907204681017644147298868403840 32963780385579653968698050792566085568288903574577 Scott -- Scott Hemphill hemphill@alumni.caltech.edu This isn't flying. This is falling, with style. -- Buzz Lightyear ==== +----------------------------------------------+ | Wed, 17.9.03 06:25 a.m. +1200 (NZT) | +----------------------------------------------+ in message ID : > Have a look at this interesting document (PDF format): > > http://www.prenticehallmath.com/epdela/laprojects/chapt11/proj11.4/proj11-4.p df > > It does discuss and solves (both symbolically and numerically) this > particular equation and several other related ones. Many thanks! I have only ever solved one (maybe two) other ODE numerically, about 30 years ago. When Valentin posed his challenge I did a google search, but failed to find that pdf, or anything remotely similar. It's absolutely perfect! Looks like I'd better add Edwards & Penny to my library ;-) -- Tony Hutchins Wellington New Zealand ==== +----------------------------------------------+ | Wed, 17.9.03 10:16 a.m. +1200 (NZT) | +----------------------------------------------+ in message ID : > I told it to solve it numerically, and gave it a target > accuracy of 21 digits. The procedure failed with 22 digits. > If I had read the thread on www.hpmuseum.org, I probably > wouldn't have bothered. :-) Hehe - yes it wobbles about a bit on the numerical solution. On the 49g+ with Tol=.001 it gives 318.96... then with Tol=.0001 it goes up to 319.94... after that it keeps coming down giving its closest answer for To E-10 (317.722455297) - and with even smaller Tol it drops to 3177.722439...at E-13, up to 317.722467420 at E-14, and as I am testing my batteries I have continued :) The E-14 run takes over an hour. Suddenly I saw the ((*)) pop up. Now, I know this is the low bat icon. Imagining I am a new user I looked in the supplied user's manul *and* in the full PDF and it does *refer* to the low battery icon, but as far as I can tell it *never* gives a picture of the icon. *Even* the HP49G User's Guide at least shows a little picture of it on page D-3. With the TAN transformation the 49g+ numerical solution does not wobble at all - it gradualy approaches it's best answer at E-10 and gives exactly the same for E-11. > On the other hand, if I had done enough homework, then I would have > used Mathematica to obtain a symbolic solution, and given many more > digits, e.g. 100: > > 317.72246067575030839907204681017644147298868403840 > 32963780385579653968698050792566085568288903574577 it for future reference. -- Tony Hutchins Wellington New Zealand #173 In baseball, you don't know nothing. Yogi Berra ==== No, but its easy to buy it, e. g. at www.educalc.net. Its located in singapore, but you get your calc really fast. I ordered it on a sunday via Internet and got it on the next thursday via FedEx. Be aware that some of the new HP49G+ calcs have some difficulties with the keyboard. They ignore sometimes your keypresses, which could be annoying. If you don«t like this, you«ll have to wait for HP correcting this in a new product charge or wait for a new ROM (i«m not shure wether it«s a hardware or software fault). Mathias -- Mathias Habel mathias.habel_no-spam_@t-online.de Remove _no-spam_ before replying ==== > >No, but its easy to buy it, e. g. at www.educalc.net. Its located in >singapore, but you get your calc really fast. I ordered it on a sunday >via Internet and got it on the next thursday via FedEx. > >Be aware that some of the new HP49G+ calcs have some difficulties with >the keyboard. They ignore sometimes your keypresses, which could be >annoying. If you don«t like this, you«ll have to wait for HP >correcting this in a new product charge or wait for a new ROM (i«m not >shure wether it«s a hardware or software fault). > >Mathias Yikes, they are selling it for $295 + $36 shipping. I think I'd better wait longer :-) ==== >> >>No, but its easy to buy it, e. g. at www.educalc.net. Its located in >>singapore, but you get your calc really fast. I ordered it on a sunday >>via Internet and got it on the next thursday via FedEx. > Yikes, they are selling it for $295 + $36 shipping. I think I'd better > wait longer :-) Actually... those prices are in Singapore dollars. The conversion rate is approximately $1 Singapore = $0.55 USD, if I remember correctly. James ==== This is a virus, do not execute anything from it! -- The Direct3D Graphics Pipeline-- code samples, sample chapter, FAQ: Pilgrimage: Utah's annual demoparty ==== Have tried to archive a 100K home directory, and get a memory error. The filer properties shows about 75K available to each port, though the correct amount is shown in Tree View. This could be why it gets a memory error in backup to Port 2, or what. Dave ==== > The new processor of hp49g+ is ARM9 but what refernece ?? > > Where I can get the ARM9 processor datasheet ? http://www.arm.com/armtech/ARM922T?OpenDocument ==== I guess you will have to wait until someone opens a HP49G+ and looks at the references on the chip, if it is not a COB package :-) anyone has pictures of a HP49G+ guts yet? cheers, Cyrille > The new processor of hp49g+ is ARM9 but what refernece ?? > > Where I can get the ARM9 processor datasheet ? > > > ==== I'm under impression, that ARM9 supports natively only binary integer data. That raises interesting question, how to improve future HP calculators beyond simply emulating (very inefficiently) Saturn's integer and floating point BCD arithmetic. If HP decides in the future to optimize the code, they will face interesting dillema either to change the CPU again to one that supports BCD efficiently, or to recode the software with the binary data format and abandon BCD completely. This surely will enrage many HP calculator purists despite FP binary being several times more accurate for the same word size :-). Also such recoding seems extremally labor intensive if we just want to improve current HP 49 software and make it run faster on ARM. BTW TI with it's M68K CPU faces practically the same dillema because of the very primitive support for BCD of this particular CPU. But TI at least is already partially binary with the integer type data, so translating floating point to binary might seem to be a little more natural for them. Of course they can also still choose future CPU that support BCD better than M68K. Jack ==== > If HP decides in the future > to optimize the code, they will face interesting dillema either to > change the CPU again to one that supports BCD efficiently, or to > recode the software with the binary data format and abandon BCD > completely This topic has been discussed over and over do you just like to restart a big flame war?. First of all you would have a very difficult time to find a CPU that has a BCD support these days. 2nd, why use binary data? sure it's more accurate but it's definitely not appropriate in calculator use (and especially financial one) So here we go again with the great Marchel... ==== > First of all you would have a very difficult time to find a CPU that has > a BCD support these days. > > 2nd, why use binary data? sure it's more accurate but it's definitely > not appropriate in calculator use (and especially financial one) Speed Mr. Jean Yves, speed. Haven't you noticed, that HP49 was absolute disasterous flop that ended up you being fired from HP as a side effect. This is BTW the main reason HP went for ARM to speed it up and to answer number one reason users complained after release of original 49. Do I have to explain such obvious things ? > > So here we go again with the great Marchel... Hmm. Is this all you can mange to introduce into discussion ? Jack ==== > Speed Mr. Jean Yves, speed. Haven't you noticed, that HP49 was > absolute disasterous flop that ended up you being fired from HP as a > side effect. Of course.. Must be the reason why I'm not working at HP anymore... Damn, I should have known about this BCD speed... > Hmm. Is this all you can mange to introduce into discussion ? Well, glad to see that after two years all you can talk about is still about why nobody's is using binary in their calculator... They must have read your previous posts... 17BII, 33S all BCD math libraries. No doubt people who did that will get fired too. ==== > Of course.. Must be the reason why I'm not working at HP anymore... > Damn, I should have known about this BCD speed... You didn't seem to grasp that relatively simple reason why ACO is no more. > 17BII, 33S all BCD math libraries. No doubt people who did that will get > fired too. Oh, no. Those simple toys do not require speed to compete with manual input. I thought, you have better understanding of target market for graphic - engineering programmable calulcators, but you seem to confuse them with toys. Face it, HP 49 ended up to be a toy for a few enthusiasts. But as you said yourself, even designers of modern CPU's do not share you love for BCD anymore. But, I guess as usual, you consider them idiots too. > Jack ==== > > Of course.. Must be the reason why I'm not working at HP anymore... > Damn, I should have known about this BCD speed... > > You didn't seem to grasp that relatively simple reason why ACO is no more. > > 17BII, 33S all BCD math libraries. No doubt people who did that will get > fired too. > > Oh, no. Those simple toys do not require speed to compete with manual input. > I thought, you have better understanding of target market for graphic - engineering > programmable calulcators, but you seem to confuse them with toys. Face it, > HP 49 ended up to be a toy for a few enthusiasts. > > But as you said yourself, even designers of modern CPU's do not share you love > for BCD anymore. But, I guess as usual, you consider them idiots too. > > > > Jack The only Jackass here is Jack, who don't understand about the difference between calculators and computers AND that the binary math is actually flawed (-; Now, troll, go away, please! PS: With people like Jack and Helen around - this NG should be moderated Bhuvanesh is a nice TI-person and I easily take JYA's snappy comments to me. ==== > PS: With people like Jack and Helen around - this NG should be moderated > Bhuvanesh is a nice TI-person and I easily take JYA's snappy comments to > me. people in this group. While you are at it, you should also outlaw any criticism of the new 49G+. At the very least, any hint of criticism should be required to come along with a statement of support for the calculator. Most people in this group have this kind of thing down pat anyway. As in: The calculator comes with a broken keyboard out of the box, but it is a great calculator. The calculator gobbles up batteries in no time flat, and does not properly recognize SD cards. No problem, though, you can solve these issues by downloading a new BIOS, which gives you a beautifully flickering screen. I love this machine. The fine golden paint on the case comes off, and is usually scratched off right out of the box. It's a beautiful calculator. The most amazing thing to me is, these people are probably posting this kind of stuff with a straight face. No further comment. -- Helen. ==== > people in this group. and some entertaining comments. Especially funny was scientific comment such as binary math is actually flawed in a floating point math. I wonder what part of it is exactly flawed. It must add wrong or something, Or another comment like don't understand about the difference between calculators and computers. Just put those two comments in the together to discover humor :-) Jack ==== > people in this group. > > and some entertaining comments. Well, somebody started it with idiots remark and deserves some feedback! > Especially funny was scientific comment such as binary math is actually > flawed in a floating point math. I wonder what part of it is exactly flawed. It When I was on my first year as a professional programmer with formal training I worked with an IBM Cobol programming system and found a bug in coverting from signed binary (was it COMP-3?) to DISPlay format. There was indeed an undocumented bug in the IBM Cobol and yes, the binary math is flawed and that is scientific in theory/practice. > must add wrong or something, Or another comment like don't understand > about the difference between calculators and computers. > > Just put those two comments in the together to discover humor :-) Yep! There is indeed humor embedded. > the computers have flawed math and calculators do not. That must be the > reason why computers make mistakes, he,he,he. I wonder, why > is it that HP 49 also has bugs ? Every system - complicated enough - typically with have human errors the hardware itself may sometimes also have errors (Pentium bug). The BCD floating point libraries in the HP calculators have always been of very high quality. The used algorithms have accuracy & stability build-in. BCD style is used in banking systems (and in languages like Cobol) where binary math and binary to decimal errors are not tolerated. > on purpose ! It must be one of those cases of black helicopters taking over > the world conspiracy theory :-) I didn't say anything like that, BUT now that you mention it - there must be a cons_piracy ==== I think you are being a tad unfair here. > At the very least, any hint of criticism > should be required to come along with a statement of support for the > calculator. Most people in this group have this kind of thing down pat > anyway. As in: > > The calculator comes with a broken keyboard out of the box, but it is > a great calculator. A few people have reported that some keys do not register when they have clicked. I agree that this is a little annoying, but the keyboard is still a great improvment over the 49g. Keep in mind that all these units are from the 'bleeding edge', and may be fixed later. > > The calculator gobbles up batteries in no time flat, and does not > properly recognize SD cards. No problem, though, you can solve these > issues by downloading a new BIOS, which gives you a beautifully > flickering screen. I love this machine. So we agree that the SD cards problem and power drain are no longer issues - you are complaining about the flicker. To be specific, the bottom 2 lines of pixels on the screen flicker occasionaly (maybe once or twice a minute? I have not measured it.). This is a valid complaint - but not a major issue I think. > > The fine golden paint on the case comes off, and is usually scratched > off right out of the box. It's a beautiful calculator. The paint DOES look good. I have not seen this problem - it sounds like a bad batch went through? I'm sure this will be fixed ASAP. > > The most amazing thing to me is, these people are probably posting > this kind of stuff with a straight face. > > No further comment. -- Helen. Perhaps people give a statement of support for the calculator becase despite the complaints above, it is still a very good machine? The keyboard is much improved over the '49G, the screen is larger and clearer (I think the flicker is not very noticable), there is tons of features and the whole thing is very fast. I think you should get your hands on one. HP have obviosuly tried to address the issues people complained about in the past, and I think they've suceeded. There are a few small QA problems common to all new products, but they are fixable. cheers, Al ==== > > A few people have reported that some keys do not register when they have > clicked. I agree that this is a little annoying, but the keyboard is > still a great improvment over the 49g. I just can't understand the *huge* amount of slack that people are willing to give HP on keyboard issues. They've proven in the past that they can produce *excellent* keyboards, so why should anything less *ever* be acceptable? It's this stupid idea that HP has that they can downgrade some aspects of the product if they make up for it with new features. Sorry, but I don't accept that. Any new calculator that HP produces should have, in addition to new features: * a keyboard *at least as good* as the *best* keyboard on any of their other calculators; * a display *at least as good* as the *best* display on any of their other calculators; * a case design, finish and durability *at least as good* as the *best* case on any of their other calculators; * etc. I know what some of you will say to this: But it's a new situation, because they've outsourced manufacturing and they don't have access to their old manufacturing techniques. Well, whose fault is that? Here's a hint: It's not the customers' fault. HP makes decisions about how they manufacture their products; they have all the responsibility (and the blame) for any resulting problems. If they've ever done something right once, I expect them to keep getting it right -- with no exceptions. > Keep in mind that all these units are from the 'bleeding edge', and may > be fixed later. The time for fixing problems is before the product is released, not afterward. Any problem that is fixable should have been fixed before anyone outside HP saw it. > So we agree that the SD cards problem and power drain are no longer > issues - you are complaining about the flicker. It's nice that they fixed the problems so quickly. It would have been even nicer if they had actually *tested* these things for a few weeks before shipping them out. Clearly *no one* at HP bothered to use one of them long enough to find out how quickly they drained batteries. > Perhaps people give a statement of support for the calculator becase > despite the complaints above, it is still a very good machine? > The keyboard is much improved over the '49G, the screen is larger and > clearer (I think the flicker is not very noticable), there is tons of > features and the whole thing is very fast. Which is *no excuse* for even a *single one* of the problems mentioned above. There's no excuse for *anything* they've done right in the past not being done right *from the very beginning* on new models. -- Wayne Brown | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock ==== > If HP decides in the future to optimize the code, they will face > interesting dillema either to change the CPU again to one that > supports BCD efficiently, or to recode the software with the binary > data format and abandon BCD completely. That is not a dilemma. The only reasonable option is to use what the big CAS systems do: the base numeric type is a quotient of two multi- precision integers. To get the same results as RPL currently does you simply contrain the denominator to be a power of 10 and the numerator to have 12 significant digits for REAL and 15 significant for EXTENDED REAL. Complex is just a pair of such quotients. -JimC ==== > > If HP decides in the future to optimize the code, they will face > interesting dillema either to change the CPU again to one that > supports BCD efficiently, or to recode the software with the binary > data format and abandon BCD completely. > > That is not a dilemma. The only reasonable option is to use what the > big CAS systems do: the base numeric type is a quotient of two multi- > precision integers. To get the same results as RPL currently does > you simply contrain the denominator to be a power of 10 and the > numerator to have 12 significant digits for REAL and 15 significant > for EXTENDED REAL. Complex is just a pair of such quotients. > Can you tell more about what you are thinking. ==== > That is not a dilemma. The only reasonable option is to use what the > big CAS systems do: the base numeric type is a quotient of two multi- > precision integers. To get the same results as RPL currently does > you simply contrain the denominator to be a power of 10 and the > numerator to have 12 significant digits for REAL and 15 significant > for EXTENDED REAL. Complex is just a pair of such quotients. > > Can you tell more about what you are thinking. He thinks about system that is used by the Microsoft Windows calculator, where real numbers are represented by the ratio of two integers as long as the system is capable to keep them in a reasonable size. It has advantage over BCD or binary to preserve ideal precision when division operator is used. Base four mathematical operations on the rational numbers remain rational, so rational representation is (unlike BCD and binary for division) always precise for those and is the only one that is not a compromise. Of course, it is also the most memory huingry and the slowest. Unfortunately all those systems break down with any math function that when operates on rational number, generates irrational answer, such as sqare root, logarithmic or trigonometric. Therefore using rational numbers in a scientific - engineering calculator makes even less sense than BCD or binary. When engineering functions are considered, no finite state machine is capable to represent numbers precisely, so the compromise always has to be made even with your beloved BCD. If one considers just four basic math operators, rational is the only one with no compromise. In case, when all functions are considered, the fastest and the most precise with the same memory footprint is by far binary (that is scientific fact :-) ) > > Jack ==== > > Well, somebody started it with idiots remark and deserves some feedback! I used idiots sarcastically referring to the unknown third person - CPU designer, who happen to be on my side by ignoring BCD despite both of you guys opinion about it's superiority. This is simple figure of speech. I don't see how you can consider jackass as a figure of speech about the unknown third person ? I challenge you to find an example when I called either you or JYA or anybody else on this forum anything but ones online handle. I consider name calling to be derogatory to the caller, not to the one that is called the name :-) > When I was on my first year as a professional programmer with formal > training > I worked with an IBM Cobol programming system and found a bug > in coverting from signed binary (was it COMP-3?) to DISPlay format. > There was indeed an undocumented bug in the IBM Cobol > and yes, > the binary math is flawed and that is scientific in theory/practice. Bug is not a flaw but a fixable human error. How binary has a scientific flaw is beyond me. According to my knowledge as long as the overflow or underflow does not occur binary is precise for addition, subtraction and multiplication exactly as BCD. Also EXACTLY as BCD it is imprecise for division. The only flaw of binary is, that it is in some cases (unlike BCD) incapable to precisely represent decimal number displayed in the calculator window. I don't consider this to be a big deal. I loose BCD precision as soon as I use division per any prime number for example. BCD is maybe capable to represent precisely the number displayed in the window after the division but THE DISPLAYED NUMBER IS ALREADY INCORRECT TO START WITH and with BCD of the same memory footprint is has more error than binary. This is a scientific fact :-) > Every system - complicated enough - typically with have human errors > the hardware itself may sometimes also have errors (Pentium bug). > The BCD floating point libraries in the HP calculators have always been > of very high quality. The used algorithms have accuracy & stability > build-in. I don't deny this. That is why it is a challenge and cost if HP will ever try to convert them to binary. On the other hand most modern CPU's already have libraries of binary math very stable, precise and tested in a numerous computers. > BCD style is used in banking systems (and in languages like Cobol) > where binary math and binary to decimal errors are not tolerated. This is the second seriously flawed argument because it proves, that people who are involved in HP calc design have no clue who is their target customer. See the following reasons 1) I have yet to see a single real estate agent or car dealer that is trying to sell me a loan using HP 48, HP 49 or TI 89. Those people are using calculators specialized toward typical banking operations like HP17B. The key is a letter B here :-). I don't particularly care what coding is used in those machines :-) 2) I have yet to see a single real estate agent or car dealer who is using his calculator to write long multioperational programs with multiple iterative loops where the iterated operation artificially magnifies initial imprecise representation of the binary coding. Also because he or she is not using lengthy programs, he or she really doesn't care if his single math operation last one or hundred milliseconds. 3) I have yet to see a single example of home loan or car loan which when calculated with binary coded machine will create payment calculation error even close to be half US cent so it could be rounded to the wrong payment by one cent. 4) It is ridiculous to assume that trillion dollar banking calculations will be performed on the handheld device with the precision required by the bank. You, guys, are so quick to dismiss any complaint about the unacceptable timing when one is playing with large matrix or lengthy program arguing that such problem should be solved on the computer. Well, you guys, are strangely blind to the fact, that EXACTLY THE SAME ARGUMENT applies to this case. Let me spell it for you. TRILLION DOLLAR LENGTHY CALCULATIONS THAT REQUIRE ENHANCED PRECISION AND HAVE ANY LEGAL IMPLICATIONS WILL NEVER EVER BE RUN ON THE HANDHELD CALCULATOR, especially one that is designed for engineers and scientists :-) 5) It is ridiculous to assume, that the target customer of the graphing calculator which suppose to be engineer or scientist will use this calculator to perform only basic three mathematical operations i.e. addition, subtraction, multiplication, where precise representation of what is on the display is preserved in BCD, will remain preserved in the operations and the minimal binary representation error might be artificially magnified. Quite contrary. The target customer will almost definitely use division which can only hold precision preserved with rational real number representation. It is practically guaranteed that the target customer will also use myriad of engineering and scientific functions such as logarithms or trigonometry destroying any finite machine precise representation. Those functions produce generally irrational numbers that can be only approximated. Surprise, surprise, such calculations not only are achieved the fastest in binary but they are also have the least amount of error when one uses binary coding for a given memory footprint. 6) I'm yet to see a single engineer or scientist who is using BCD libraries on their PC computers, supposedly because the binary libraries of Visual Basic, Visual C++ or Borland compilers must have a flaw or imprecisely representing decimal input. 7) I'm yet to see such scientist or engineer who will make a distinction between calculator and PC computer, and demand that the calculator must be more precise than his computer. 8) It is ridiculous to target students who will be surprised to get 0.99999... in certain examples of binary representation flaw instead of 1.0 as it should be with precise math. If such student do not understand why this is happening to him, he or she would be better off with the much more economical machine for the mathematically challenged. There is no difference in understanding such rare cases when 0.99999... is achieved instead of 1.0 as in the simples example of performing 1. 3. / 3. * on HP 48/49 which produce exactly the same surprising flaw of displaying 0.999999.... instead of 1.0 and proving that BCD is equally flawed as binary when scientific - engineering operations are concerned :-) Henry Ford was years ago oposing any change to the Ford model T which was produced for many years. It almost destroyed Ford at the end of that era because the car become very uncompetitive. and it did not matter that initially it was such a revolutionary, great vehicle. Only Ford son, that was not emotionally attched to the old design, finally managed to convince his father to change the desing and come up with completely new car, model A, totally redesigned and competitive again. See the pattern ? :-) > the world conspiracy theory :-) > I didn't say anything like that, > BUT > now that you mention it - there must be a cons_piracy Jack ==== > A few people have reported that some keys do not register when they have > clicked. I agree that this is a little annoying, but the keyboard is > still a great improvment over the 49g. A few people? As far as I can see, all those who have the new calculator seem to have that problem. Yup, it's only a few people who have it, but they all seem to have the problem. Or does anyone have a 49G+ with a working keyboard? So, great improvement? You replace a stiff keyboard with ugly rubber keys with one that has nice keys that work only sometimes? Great job, indeed... > Keep in mind that all these units are from the 'bleeding edge', and may > be fixed later. The _may_ be fixed? When? > To be specific, the bottom 2 lines of pixels on the screen flicker > occasionaly (maybe once or twice a minute? I have not measured it.). > This is a valid complaint - but not a major issue I think. It is a valid complaint, and nothing to be proud of. > The fine golden paint on the case comes off, and is usually scratched > off right out of the box. It's a beautiful calculator. > > The paint DOES look good. I have not seen this problem - it sounds like > a bad batch went through? I'm sure this will be fixed ASAP. Well, it seems that the paint comes off very easily, so if there is some vibration during shipping, the paint is off. If it isn't, it may well come off after some use, slipping the calculator into and out of its pouch. > Perhaps people give a statement of support for the calculator becase > despite the complaints above, it is still a very good machine? A machine with a broken keyboard and a flickering screen? Give me a break! > The keyboard is much improved over the '49G, See above. It had the potential to be much improved. Unfortunately, it's broken. > the screen is larger Wow, one more line. I'm in awe. It is still a far cry from the TI screens. > and clearer (I think the flicker is not very noticable), there is tons of > features and the whole thing is very fast. It seems to be fast, yes. > I think you should get your hands on one. HP have obviosuly tried to > address the issues people complained about in the past, and I think > they've suceeded. I don't see that at this point. I'll grant you, though, if the keyboard was not broken, and the screen did not flicker, it would seem like an o.k. calculator. As it is, if I had bought one, it would have gone right back once I had found out the keyboard is broken. I am not in the habit of paying for broken merchandise. > There are a few small QA problems common to all new > products, but they are fixable. I would not call those small QA problems. If I buy a $5-calculator in the checkout aisle of my grocery store, it will come with a working keyboard. If I buy any TI calculator, it will come with a working keyboard, too. In fact, I have never heard of any calculator from any reputable company that was manufactured with such a lousy quality. There's no paint coming off of any TIs for sure. Selling people this kind of quality for almost 200 bucks is a disgrace. Plus, this is from the company that once was HP, and that once made the best calculators to be had. -- Helen. ==== +----------------------------------------------+ | Thu, 18.9.03 4:22 p.m. +1200 (NZT) | +----------------------------------------------+ in message ID <1a8f5fe5.0309171835.5488e1d1@posting.google.com> : > A few people have reported that some keys do not register when they have > clicked. I agree that this is a little annoying, but the keyboard is > still a great improvment over the 49g. > > A few people? As far as I can see, all those who have > the new calculator seem to have that problem. Possibly not all people who have the calculator have posted a message here. > Yup, it's only a few people who have it, but they all seem > to have the problem. Yup my guess is possibly 100 folk have the calc. I don't criticise your hypothesis as such - possibly you are 99% correct. > Or does anyone have a 49G+ with a working keyboard? I seem to have one with a keyboard with all keys working fine. Possibly others do too, but haven't posted here. Maybe no-one will believe me, poor soul. However the keys do make quite a loud click, which cannot be silenced. I assume this crticism makes my report more credible. I like the curved shape of the gold top as well - looks a bit like a violin. Also I note than when I take the calc out of it's pouch the keys tend to catch on the top edge of the pouch. I have a work around for this though :) > So, great improvement? You replace a stiff > keyboard with ugly rubber keys with one that has nice keys > that work only sometimes? Great job, indeed... IMHO the keyboard is a significant improvement. [...] > > The fine golden paint on the case comes off, and is usually scratched > > off right out of the box. It's a beautiful calculator. > > The paint DOES look good. I have not seen this problem - it sounds like > a bad batch went through? I'm sure this will be fixed ASAP. There has been one report of this gold paint falling off in little flakes. I would like to say that mine hasn't, well my 49g+'s hasnt :) I have even rubbed it a bit and the paint adhesion seems fine. > Well, it seems that the paint comes off very easily, so > if there is some vibration during shipping, the paint is > off. If it isn't, it may well come off after some use, > slipping the calculator into and out of its pouch. In this case I think the paint job must have been bad at the manufacturing point. I received a calc from the same batch of 100. Mine travelled a lot further to the delivery point as well. > Perhaps people give a statement of support for the > calculator becase despite the complaints above, it is > still a very good machine? > > A machine with a broken keyboard and a flickering > screen? Give me a break! My screen doesn't even flicker. I'm still on the original OS. I must live in a dream-world. Possibly I am a lonely counter-example :) But, you haven't mentioned the battery problem. I do confirm that the AAA batteries I got with the package were not very good quality. Then I looked up the manual where the battery icon is referred to, but there is no picture of it (the icon). This battery thing to my mind is not minor, but it's not worth going on about - in fact it has been addressed I think. I could mention other minor problems as well, but as soon as I think of them they just fade away, and are not prpper food for a message here, which seems primarily a forum for problems. They can tend to get exaggerated as readers naturally assume by default that the whole is the sum of the parts - it's almost an inherent fractal assumption, that the shape of the part is reflected in the whole. [...] > I don't see that at this point. I'll grant you, though, if > the keyboard was not broken, and the screen did not flicker, > it would seem like an o.k. calculator. As it is, if I had > bought one, it would have gone right back once I had found > out the keyboard is broken. I am not in the habit of paying > for broken merchandise. Nor am I. Obligatory compliment?: It's a great calc!!! - really. The speed, and clarity of the display are top-notch. The display has come a long way from that of the HP48SX ;-) Oh, BTW - thanks for mentioning John Holland's MATHLIB ROM I will look out for one. Want to sell yours? ;-) -- Tony Hutchins Wellington New Zealand #284 Little things affect little minds. Benjamin Disraeli ==== X > Or does anyone have a 49G+ with a working keyboard? > > I seem to have one with a keyboard with all keys working fine. > Possibly others do too, but haven't posted here. I have tested one model with the radix [ . ] key not registering using a light touch and another model perfectly alright. BUT there is a problem with the first batch & the keyboard ==== X > A machine with a broken keyboard and a flickering > screen? Give me a break! > > My screen doesn't even flicker. I'm still on the original OS. > I must live in a dream-world. Possibly I am a lonely > counter-example :) Now that this is mentioned I stared at my screen and finally noticed that the menu row flickers slightly now and then. If *that* prevents someone from buying a calculator then that is solely her problem. PC: The flickering to be noticed depends on lightning conditions and contrast setting (and eyes :) ==== X > There has been one report of this gold paint falling off in > little flakes. > > I would like to say that mine hasn't, well my 49g+'s hasnt :) > I have even rubbed it a bit and the paint adhesion seems fine. X No flakes, but I dropped a loaned calculator and that scratched one corner: beneath the paint is dull white plastic. I will call this calculator the Golden Kid ==== I have better things to do then get into an argument over a calculator :-p So I will just add my comments and then let you have the last word. > >>A few people have reported that some keys do not register when they have >>clicked. I agree that this is a little annoying, but the keyboard is >>still a great improvment over the 49g. > > > A few people? As far as I can see, all those who have the new > calculator seem to have that problem. Yup, it's only a few people who > have it, but they all seem to have the problem. Or does anyone have a > 49G+ with a working keyboard? When I first recieved the g+, I noticed the cursor keys occasionally had the problem. However this took roughly 5 mins to get used to - I don't even notice it. I still think the keyboard is *much* better then the 49g. Then again, we only hear about those who wish to complain... You may be right about the number of units with issues, I don't know. So, great improvement? You replace a > stiff keyboard with ugly rubber keys with one that has nice keys that > work only sometimes? Great job, indeed... I think you are misinformed about the problem. The keys ALWAYS work, but occasionaly one or two keys will not register after the 'click' - a tiny bit more pressre is needed. It isn't like some keys never register at all or anything as bad as that. It just means you have to press a little harder then you first thought. Is it a problem? Yes. But hardly as bad as you make it out to be (btw, have you used this calculator? If not, you really should before complaining.) > > >>Keep in mind that all these units are from the 'bleeding edge', and may >>be fixed later. > > > The _may_ be fixed? When? Why would I know? It seems the other problems reported (Power drain and SD card) were fixed promptly. > > >>>The fine golden paint on the case comes off, and is usually scratched >>>off right out of the box. It's a beautiful calculator. >> >>The paint DOES look good. I have not seen this problem - it sounds like >>a bad batch went through? I'm sure this will be fixed ASAP. > > > Well, it seems that the paint comes off very easily, so if there is > some vibration during shipping, the paint is off. If it isn't, it may > well come off after some use, slipping the calculator into and out of > its pouch. As it said, maybe it was a bad batch. The paint on my unit is held on very securely - I have not managed to rub any off. I'll be extremely surprised if this isn't fixed ASAP. > > >>Perhaps people give a statement of support for the calculator becase >>despite the complaints above, it is still a very good machine? > > > A machine with a broken keyboard and a flickering screen? Give me a > break! Again, the keyboard is not 'broken', it is fully functional. Tactile feedback needs some tuning I think but otherwise is great. You only notice the screen flickering if you look for it - its only the bottom 2 lines of pixels. Again maybe a ROM update could fix it? > > >>The keyboard is much improved over the '49G, > > > See above. It had the potential to be much improved. Unfortunately, > it's broken. No its not. See above. > > >>the screen is larger > > > Wow, one more line. I'm in awe. It is still a far cry from the TI > screens. 2 lines. > > >>and clearer (I think the flicker is not very noticable), there is tons of >>features and the whole thing is very fast. > > > It seems to be fast, yes. No, it can't be! Surely you must be able to criticize this as well. Perhaps you could complain about games being too fast ;-) > >>There are a few small QA problems common to all new >>products, but they are fixable. > > Remember the calc has not yet been offically launched. Maybe we should wait a month and see. In the interest of peace, I will not reply to this thread again. Al ==== X > I don't deny this. That is why it is a challenge and cost if HP will ever > try to convert them to binary. On the other hand most modern CPU's > already have libraries of binary math very stable, precise and tested > in a numerous computers. like NAG, true... > BCD style is used in banking systems (and in languages like Cobol) > where binary math and binary to decimal errors are not tolerated. > > This is the second seriously flawed argument because it proves, > that people who are involved in HP calc design have no clue who is their > target customer. See the following reasons > > 1) I have yet to see a single real estate agent or car dealer that is trying to > sell me a loan using HP 48, HP 49 or TI 89. Those people are using > calculators specialized toward typical banking operations like HP17B. > The key is a letter B here :-). I don't particularly care what coding is used > in those machines :-) Yes and the HP 12C is the official Wall Street calculator. BUT also engineers need to sum up cost, etc. AND the 4x series have that TVM and other tools (like [+] :) to calculate also some financial stuff > 2) I have yet to see a single real estate agent or car dealer who is using > his calculator to write long multioperational programs with multiple > iterative loops where the iterated operation artificially magnifies > initial imprecise representation of the binary coding. Also because > he or she is not using lengthy programs, he or she really doesn't > care if his single math operation last one or hundred milliseconds. Right X > again. See the pattern ? :-) I see it, Jack. PS: Is there anything good in the HP calculators? Improvements so far (never praised by you?): SW: MASD build-in, compile and decompile of SysRPL & Assembler Algebraic mode added, RPL> and `back-quotas` to allow cross calling Fast EQW, INFORM, CHOOSE, etc Filer for ease of use, ports shown by type rather than by 128KB limit CAS & new commands infinite integers Symbolic Matrices Graphical Stack (EQW format in stack objects) Multiple font sizes including minifont Step-by-Step Fast 3D plot with 3d rotate and zoom More assignment levels by shift&hold HW: Flash to store programs & libraries permanently Alpha keys working together with cursor keys AND Now the + model has added speed, SD card, fast IrDA, fast USB, etc. Why always mainly complaining? That is the pattern I see... ==== BCD and binary have all their advantages. Binary is faster and easy to implement in hardware. This is why (to my knowledge) all numerical co-processor use binary. BCD is usually implemented in software (with some time hardware assist for basic operations like on the saturn) and is slower. now, we are only concerned here about floating point number obviously (for integers, there is no problem as both representation can be exact. In the case of the 49, BCD was choosen because faster to display (no binary to BCD translation to make all the time)) now, one of the big advantages of BCD is that the idiosyncraties are omre intuitive than in binary. everyone knows that 1/3 can not be represented exactly in BCD and can cause problems if re-multiplied, few peoples know that 0.6 can not be represented in binary and will cause problems similar to 1/3. Now as a calcualtor is mainly used by standard peoples that do not do number crunching, but add simple numbers, one at a time, BCD does make sence as it is more intuitive. ==== > Oh, BTW - thanks for mentioning John Holland's MATHLIB ROM > I will look out for one. Want to sell yours? ;-) I have two of them, and I remember that I paid about $130 for the first, and maybe $160 for the second. It looks like they are over $210 now. At this rate, I think I should keep those for a while longer... ;-) -- Helen. ==== > Oh, BTW - thanks for mentioning John Holland's MATHLIB ROM > I will look out for one. Want to sell yours? ;-) > > I have two of them, and I remember that I paid about $130 for the > first, and maybe $160 for the second. It looks like they are over $210 > now. At this rate, I think I should keep those for a while longer... How about giving us a list of all the available program names, Helen? Please! ==== >... few peoples know that 0.6 can not be represented > in binary and will cause problems similar to 1/3. >...