A549 === Subject: Re: SIGN BUG > IMHO, 'X' SIGN being 1 (with 'X' undefined) is a bug > (with VER 4.20060918 and flags as last posted). >> Where did you get VER 4.20060918? I'd thought that I had the most >> recent ROM revision, 2.09, or VERSION: 04.01 BUILD NUMBER:0092, >> but VER tells me 4.20060602. >> >> Anyway, for me, with 'X' undefined and my current flags, 'X' SIGN >> (or 'SIGN(X)' EVAL) returns 'X/ABS(X)', which, if 'X' is later >> defined to be a zint or a positive or negative real number, works >> out to be correct, but if 'X' is later defined to be the real >> number 0., results in an Undefined Result error instead of the >> 0. which results from 'SIGN(0.)', in my opinion a bug. >> >> Yes, I agree that returning 1 (or -1, '?', 1., -1., or 0.) would >> also be a bug for for executing SIGN on any expression with an >> undefined variable. >> >> To me, the obvious and simple correct result for 'X' SIGN (or >> 'SIGN(X)' EVAL) with 'X' undefined would be 'SIGN(X)'. >> >> with either VER, it seems to me that there's a bug here. > > Not only that, but at least with my VER, both '1-1' SIGN and > '1.-1.' SIGN return 1, instead of the '?' and 0. that I'd > expected. > > What do these do with your later VER? Looking a little deeper, it depends on whether I'm using SIGN as a function within an algebraic or as an RPN command, and also on whether it's in exact mode or approximate mode. In exact mode: 0 SIGN returns '?'. 'SIGN(0)' EVAL returns '?'. 0. SIGN returns 0. (real). 'SIGN(0.)' EVAL returns 0. (real). '1-1' SIGN returns 1 (zint). 'SIGN(1-1)' EVAL returns '?'. '1.-1.' SIGN returns 1 (zint). 'SIGN(1.-1.)' EVAL returns 0. (real). 'X' SIGN returns 'X/ABS(X)'. 'SIGN(X)' EVAL returns 'X/ABS(X)'. In approximate mode: 0 SIGN returns '?'. 'SIGN(0)' EVAL returns 0. (real). 0. SIGN returns 0. (real). 'SIGN(0.)' EVAL returns 0. (real). '1-1' SIGN returns '(1-1)/ABS(1-1)'. 'SIGN(1-1)' EVAL returns 0. (real). '1.-1.' SIGN returns '(1.-1.)/ABS(1.-1.)'. 'SIGN(1.-1.)' EVAL returns 0. (real). 'X' SIGN returns 'X/ABS(X)'. 'SIGN(X)' EVAL returns 'X/ABS(X)'. Whether this (mis)behaviour depends on any other modes, I don't know. -- James === Subject: TI WINS CALC WARS!!! Here it is HP are dead in the water now. Victory!! Hurrah, Hurrah, Hurrah! === Subject: InFormBuilder updated to version 1.81 Hi. After numerous requests I have updated IFB to use IfMain instead of DoInputForm for creating input forms, thus enabling labels to display on the lower portion of the displays on the big Apples. The fix was trivial, was it not for the fact that I didn't have the original development framework for IFB anymore, and the lib is a SysRPL wrapped self-unpacking BZ'ed code object. But I managed to find the 45 minutes it took to pack it all out, change two lines of code, pack it all up again, update the docs and re-submit it to www.hpcalc.org. 1 years of nagging by scores of people made me do it, so sometimes it helps to complain :-) So, for those who use it, IFB v1.81 on hpcalc.org shortly. Some have already gotten this update by email btw. Steen === Subject: Re: InFormBuilder updated to version 1.81 > Hello Steen, your others projects (Special funcs, etc.) You're very welcome Luis. === Subject: Re: Need help please.... > I was gifted an 48G; it seems that the undo function doesnt work > because when I hit it every time, it says error: disabled stack Read the manual. Steen === Subject: Re: Need help please.... > > Read the manual. Of life? How do you know that a manual came with a gift > of an old, long out-of-production 48G? The manuals are available online. A product like the HP48G deserves that the user reads its manual. You could ask questions from now till doomsday without scratching the surface of what the 48G is. If you only read one manual in your life, let it be the one for your HP calculator. Steen === Subject: Re: Solver on HP48GX vs HP48GII > So, where is a list of > (1) all the nice held and non-held key combinations (e.g., p 3-9 of the > users' manual says that |-> down displays the text of the current menus > - I did not know that); > (2) mapping between menus and menu numbers. That would be appendix sections G and H of the Advanced Users Reference at HPs manual page, or a better one with internal links at hpcalc.org TW === Subject: Re: are wombats good? > It looks just like you, isnt it... > Obese, obscene, greasy. Im not hiding my IP, whats your problem, > little one? >>I'm not really sure whether Wombats are any good. >> >>The picture on Wikipedia looks like a horrid little Pig. >> >>Quite Obscene. >> >>Just not English. >> >>372 >> >> >>-- >> > Is he indeed a hairy arsed wombat, eats, roots and then leaves? lol Mick C === Subject: Re: {OT} AGP Graphic Card question Just a quick comment: Impropperly seated graphics cards can cause ALL SORTS of wierd compooter behavior seemingly not related to the graphics card. If you start to see some bizzare stuff happening, all of a sudden, that would be my first place to look. Other than that, as long as it is seated properly, you shouldn't have any issues. I have had occurences where I have had to provide a significant percentage of my body weight on a card to get it into the slot, seated correctly. It should be fine...... -- Grumpy Aero Guy > While installing a new graphics card in my HP > Pavilion I broke off the spring tab that holds the graphics card to > the motherboard on the end of the AGP slot opposite the end that one > plugs the monitor into, Is this spring tab absolutely necessary for a > good mechanical connection? Will the screw that holds the card in > place at the opposite end be enough? If not, any alternatives ideas > most appreciated, > Harold A. Climer > Dept,Of Physics,Geology & Astronomy > U.T.Chattanooga > Room 318 Grote Hall > 615 McCallie Ave > Chattanooga TN 37403 > 423-425-4546 === Subject: Re: where's the speed ?? > Now you have a SysRPL program -- > actually, it's just the SysRPL syntax > for your original program, as a string; > modify it any way you like, > then recompile using ASM. > > Don't be surprised if you see more stuff > within your UserRPL program than you knew was there, > because the UserRPL compiler adds things for you > that normally are not displayed, > which are the hidden things that make UserRPL work, > whereas with SysRPL it's up to you > to supply every detail yourself. John this is where i start to get lost. all i did was change the algebraic conditionals like 'X==Y' to X Y == in IF THEN END and DO loops. without changing anything else all the speed i could want is there. i don't even know what RPL means and didn't know there was a user type and sys type. with this simple change i've got what i need and don't want to try anything else that could screw things up. === Subject: Re: where's the speed ?? > i've got what i need and don't want to try anything else > that could screw things up. Fine; you had also asked about SysRPL, so that was your answer. Glad you are happy with UserRPL now working at expected higher speed (with algebraics eliminated). All's well that ends well, I suppose http://www.oldielyrics.com/lyrics/the_kingston_trio/the_unfortunate_miss_bai ley.html http://users2.ev1.net/~smyth/linernotes/thesongs/UnfortunateMiss.htm === Subject: Re: where's the speed ?? > i also just received my 50s recently and one of the first things > i wanted to do was compare calculation speed against my 48s. with CAS features set as follows; > indep var: 'X' > modulo: 13 > and the following items only check marked- approx, rigorous and simp. also in calc. modes i've got rpn, fix 6, fm not checked, angle degrees, > coords rect, > beep checked, key click not checked and last stack checked. speed of a loop > calculation as follows; << 80 1 -> A B << 6 FIX TIME DO 1 'B' STO+ UNTIL 'B==A' END TIME SWAP > HMS- >> >> where A & B are local variables and the program calculates the time > interval it takes > to add 1 to B 79 times ( B starts off as 1 and ends as 80 ). the identical program in my 48gx yeilds 2.08 seconds but the 50g set as > described > above yeilds 5.82 seconds. i checked very carfully that the programs > were identical, > i tried this time interval program in just > about every cas configuration possible and it always took about 5.82 > secs on the 50 > (did this on both 50s with same results). i also tried different > numbers of loops (other > than 79) and the 50 was always almost 3 times longer. one thing working with calculators has taught me is that there is > always a reason- > it's not just a personal curse playing out. WHERE'S THE SPEED ?? > The 50G is also slower in simutaneous equations. my old 48G did 29 equations with 29 unknowns each in 30 seconds, where my 50G does the same problem in 46 seconds. Aprox mode on, Rigorous tunred off. By the way, 29 equations is the infamous problem that the ABC pioneering computer was designed for. === Subject: Re: where's the speed ?? -------------------- > > The 50G is also slower in simutaneous equations. > > my old 48G did 29 equations with 29 unknowns each in 30 seconds, where > my 50G does the same problem in 46 seconds. > Aprox mode on, Rigorous tunred off. > > By the way, 29 equations is the infamous problem that the ABC > pioneering computer was designed for. For linear algebra with real matrixes, I have some hpgcc versions solving a system of 29x29 is done in about 1.5 seconds. Solving eigenvector / (eigenvalues) of real 29x29 matrix is about 2 ( 5) seconds. Singular values SVL and (SDV) of real 29x29 matrix is about 2 (3) seconds The transition into arm has a large overhead, thats why timings are fairly equal. Anyone like to do some betatesting, send me an email gjermund skailand yahoo.no The algorithms are ports from eispack and other codes. Gjermund Skailand === Subject: Re: 0 SIZE returns 0.; bug? >> Analogically : >> Is the string with 1 space, or zero char (0 CHR), and string 0 of the >> same >> length ? > That seems like a bad analogy to me. Of course the above are the > same length or size, as they all have a length field of 7 > (nibbles) with 1 byte following the length field, and SIZE > appropriately returns 1 for them. But we can also have the empty > string with a length field of 5 and nothing following the length > field, which SIZE appropriately returns zero for. >> Exactly! >> >> You need a number with no digits at all !! >> Think 567 as { 5 6 7} >> and three or zero as { 3 } or { 0 } >> { } has SIZE zero, buit not { 0 } >> So here is the number which SIZE is zero: > > Where ? Where did you put it ? > :-) is it a bird ? > > No, seriously, > I agree with most or some of Mr.Jameses thoughts and VPN of course, with > other thoughts to some degree. > > the point is -what i wanted to note in my previous posts and this time again > : > Mr.James noted himself that it would be nice if SIGN of ZINT0 was zero (for > consistency with reals) Yes, and perhaps more importantly, because a zint 0 can be used as a false for a conditional such as THEN. With '?', I have to > although i'm not sure if some other work in CAS may relate to this and cause > issues. That could be; I expect that even if so, he probably could've used a zint 0 instead of '?' as the SIGN of the zint 0 right from the start, but changing things now may be difficult. And of course, by now, probably plenty of user programs depend on the '?'. But I sure hope that no programs depend on SIGN working with names or expressions. And I still wonder about the signed zint zeros with a size of 1 that can be made. Do these ever result from any normal operations? Would they be useful for anything? > Back to SIZE: > I understand the principle of hidden bit in floating point and the analogy > of using the similar principle to leading zeros to ZINTS. > since zero is only a zero and with leading zero removed -what remains is : > <- it's right there VPN :-) > Still it does seams natural to me that if 1 is of size 1. then 0 is of > size1. as well since this has been noted > by other people too, and that's what i first expected in this case. So did I, but I changed my opinion. > In this case i belive i should not bother how long is the number formatted > in the register or memory. > And even if i would BYTES would be more suited for that. > > Also i would like to propose that size of real is a number of digits before > decimal point (signifficant digits) rather than 1. > This way it may be easier to arrange output in nicer (more graphic) way. In > that case size of real would be usefull number, where currently it is not. But as John noted, it's been that way for a long time (since the 48SX), and changing it now might break some existing programs. But what use is always returning 1 for some object types? For object types that it always returns 1 for, it tells me nothing about the value, and if I don't know the type of an argument, returning 1 doesn't tell me anything about the type. I wonder why they didn't just have it result in a Bad Argument Type error for those types. But I can imagine some use for it, as a code-saving trick. Suppose that I know that at some point I'll have some type of object for which SIZE always returns on the stack, and want to discard it and put a 1 on the stack. I could use SIZE instead of DROP 1, saving 2.5 bytes. Returning a more useful result for SIZE on a real is an interesting idea, but for all nonzero reals and zints, we do have the XPON command, which can give you information about how many digits would be before the decimal point in standard notation. I don't know why XPON should cause an Infinite Result for a zero, but it does. It looks to me as though it's doing ABS LOG ->NUM FLOOR. > Another proposal regarding leading zeros: > As a programmer very often i would like to have leading zeros displayed for > binary HXS numbers (easier to read, identify the bits/bytes/nibbles) > leading zeros could be displayed based on word size and flag setting. I agree. > I do understand that SIZE probably has no more room in ROM so updates like > this are very tricky and based on use > of SIZE on numbers it's most likely not even worth the effort... Well, there's the matter of finding room in ROM, making sure that something that's changed in ROM wouldn't cause a bug if used by something else in ROM, and maintaining backward compatibility. Of course, for anything that changes the way the calculator is supposed to work, there's also a matter of updating the documentation. > Anyway... > it's interesting for me to take considerations about such details to allow > more consitent products in the future (as if ... :-) > actualy it's more like a meditation or mental exercise :-) Well, I still hope to see a new RPL model, even if it's just a renamed 50g with the various enhancement and fixes for the various faults noted in the newsgroup. And if it has a new model name, some loss of backward compatibility is more acceptable as a trade-off for the enhanced features. -- James === Subject: B->I and I->B programs (was: 0 SIZE returns 0.; bug?) > Another proposal : I->B and B->I For zints that can be represented as reals exactly, we can accomplish these conversions with R->B and B->R, but these doesn't work correctly with zints that have a nonzero beyond the 12th digit. For zints too large to be represented as 64-bit binary integers, convert them to the maximum 64-bit binary (#18446744073709551615d), and for negative zints, convert them to a #0, much as is currently done with the R->B command. An alternative would be to force zints to values that can be represented in the current wordsize. Yet another alternative would be to error out with Bad Argument Value. Should an I->B command accept a real, analogous to R->B accepting zints? If so, how should a real with a fractional part be treated? We can always make our own programs, with the advantage of deciding for ourselves how to handle special cases. John's programs amazed me; that approach didn't occur to me. Here are my shots at some programs: %%HP: T(3)F(.); @ B->I program. @ Argument: binary integer. @ Restricted to current wordsize. @ Execution time about .099 second. @ Download or enter in exact mode. @ # 7C5Bh @ 58. << RL RR PUSH DEC -105 CF ->STR 3. OVER SIZE 1. - SUB STR-> POP >> 'B->I1' STO %%HP: T(3)F(.); @ I->B program. @ Argument: zint or integer-valued real. @ Forced to 64-bit value. @ Execution time about .079 second.. @ Download or enter in exact mode. @ # CB7Eh @ 57.5 << R->I 0 MAX 18446744073709551615 MIN # SWAP + d + STR-> >> 'I->B1' STO %%HP: T(3)F(.); @ I->B program. @ Argument: zint or integer-valued real. @ Forced to current wordsize. @ Execution time about .106 second. @ Download or enter in exact mode. @ # 93B5h @ 57. << R->I 0 MAX 2 RCWS R->I ^ 1 - MIN # SWAP + d + STR-> >> 'I->B2' STO %%HP: T(3)F(.); @ I->B program. @ Argument: zint or integer-valued real. @ Error if not representable as 64-bit binary. @ Execution time about .112 second. @ Download or enter in exact mode. @ # 3955h @ 87. << R->I IF DUP 0 < OVER 18446744073709551615 > OR THEN 515 DOERR END # SWAP + d + STR-> >> 'I->B3' STO %%HP: T(3)F(.); @ I->B program. @ Argument: zint or integer-valued real. @ Error if not representable in current wordsize. @ Execution time about .137 second. @ Download or enter in exact mode. @ # EDD8h @ 86.5 << R->I IF DUP 0 < OVER 2 RCWS R->I ^ 1 - > OR THEN 515 DOERR END # SWAP + d + STR-> >> 'I->B4' STO At first I thought that I understood John's programs, but looking at them more closely, I find that I don't really understand the reasons for parts of them. Starting from my idea of what they were doing, the following are what I came up with. %%HP: T(3)F(.); @ B->I program. @ Argument: binary integer. @ Restricted to current wordsize. @ Execution time about .021 second. @ Download or enter in exact mode. @ # AC52h @ 45.5 << RL RR DUP B->R R->I DUP R->B ROT SWAP - B->R R->I ADD >> 'B->I2' STO %%HP: T(3)F(.); @ I->B program. @ Argument: zint or integer-valued real. @ Forced to 64-bit value. @ Execution time about .129 second. @ Download or enter in exact mode. @ # F9D3h @ 83.5 << R->I PUSH 64 STWS 0 MAX 18446744073709551615 MIN DUP R->B DUP B->R R->I ROT SWAP - R->B ADD POP >> 'I->B5' STO %%HP: T(3)F(.); @ I->B program. @ Argument: zint or integer-valued real. @ Forced to current wordsize. @ Execution time about .082 second. @ Download or enter in exact mode. @ # C6D5h @ 63. << R->I 0 MAX 2 RCWS R->I ^ 1 - MIN DUP R->B DUP B->R R->I ROT SWAP - R->B ADD >> 'I->B6' STO %%HP: T(3)F(.); @ I->B program. @ Argument: zint or integer-valued real. @ Error if not representable as 64-bit binary. @ Execution time about .189 second. @ Download or enter in exact mode. @ # 99B2h @ 136. << R->I IF DUP 0 < OVER 18446744073709551615 > OR THEN 515 DOERR END PUSH 64 STWS 0 MAX 18446744073709551615 MIN DUP R->B DUP B->R R->I ROT SWAP - R->B ADD POP >> 'I->B7' STO %%HP: T(3)F(.); @ I->B program. @ Argument: zint or integer-valued real. @ Error if not representable in current wordsize. @ Execution time about .152 second. @ Download or enter in exact mode. @ # FCCCh @ 115.5 << R->I IF DUP 0 < OVER 2 RCWS R->I ^ 1 - > OR THEN 515 DOERR END 0 MAX 18446744073709551615 MIN DUP R->B DUP B->R R->I ROT SWAP - R->B ADD >> 'I->B8' STO -- James === Subject: Re: B->I and I->B programs (was: 0 SIZE returns 0.; bug?) On Wed, 29 Nov 2006 09:55:48 -0600: > 'I->B8' STO How do I convert thee? Let me count the ways... http://www.bartleby.com/41/620.html === Subject: Re: B->I and I->B programs (was: 0 SIZE returns 0.; bug?) I->B (integer to binary) should wrap around 64bit, BUT set some flag to indicate carry/error -this way you could actualy manipulate 65-bit numbers in 64 bit user binaries (note HXS can be longer than 16 nibbles -but let's leave those to the dark side :-) When given a real number it would take integer part (command name alows that) -that's expected B->I (binary to integer) should always work accurately even with 65-bit numbers (wrap around 64 + one carry flag) R->B (real to binary) Doesn't do exactly what's expected -since it takes only integer part. What it should do is to make the first step of converting real in to the floating point binary (display integer part and decimals correctly without moving the decimal point and no hidden bits and stuff) Example: 32.13671875 = #20.23h Let's call this 'floating point user binary' and make it a bit more than 64 bit size maybe 84, 96 or 128... this way user binary would allow excellent accuracy too :-) all compatible with exsting object types. BACK TO REALITY: Since this wouldn't produce a standard user binary and it would break a LOT of programs... better not mess with this :-) B->R (binary to real) -as is :-) only in dreams it would work with 'floating point user binary' manjo === Subject: Re: B->I and I->B programs (was: 0 SIZE returns 0.; bug?) > I->B (integer to binary) should wrap around 64bit And not detect range overflow? And not respect the user-assignable binary word size? If you want a MOD effect, why not employ MOD before I->B ? I'm not in favor of combining functions for special purposes, because then it's much harder to uncombine them than for the proper use of separate functions by those who want both. > note HXS can be longer than 16 nibbles Since binary integers can be more compact than decimal-based (although no provision was made for a sign in binary), some might find use for conversion to binary base, but since the processor registers were 64-bit, that was reasonably defined as the limiting word size for user-level binary functions, beyond which it would take new development (and much slower operation, just as experienced with Integer type) to extend arithmetic functions. > When given a real number it would take integer part Note that 1.5 R->B results in #2 (R->B rounds), while 1.5 R->I gives Error: Bad Argument Value, which brings to mind: http://www.bartleby.com/59/3/foolishconsi.html The programs I posted accept reals and round, except sometimes anomalously at exactly .5 e.g. { 1.51 1.5 1.49 } I->B ==> { #2h #1h #1h } That's probably curable with a little tweaking (which I'm not interested in looking into today, however :) For those who want to interpret binary strings as signed (two's complement), one can again add that capability by wrapping the unsigned (standard) version within another program, rather than by contradicting the existing underlying premise, e.g.: << DUP 0. >= { R->B } { NEG R->B NEG } IFTE >> 'SR->B' STO << DUP #1 RR < { B->R } { NEG B->R NEG } IFTE >> 'SB->R' STO Those who want one's complement (an available option in HP16C) can make their own programs :) [r->] [OFF] === Subject: Re: B->I and I->B programs (was: 0 SIZE returns 0.; bug?) >> I->B (integer to binary) should wrap around 64bit > And not detect range overflow? > And not respect the user-assignable binary word size? > If you want a MOD effect, why not employ MOD before I->B ? > I'm not in favor of combining functions for special purposes, > because then it's much harder to uncombine them > than for the proper use of separate functions > by those who want both. I'm not sure... maybe you didn't read my post entirely ? Again: By wraping around 64bits and having (indicating) a carry -what do i have ? MOD effect ? (naybe) 65 bit number ? (sure) If you read B->I section, you would notice the carry flag mentioned again ... so :-) Of corse we would detect overflow in a useful way too :-) manjo === Subject: Re: inconsistant sine problem > > > Trying to work some problems that involve sine or cosine. If I take > > 2pi and perform sine on it, I get 0. Which is what I'm expecting, but > > if I take 2pi and first->num to it so there is a numeric value on the > > stack I get a 4.13x10^-13 Is this just error from the number not being > > represented symbolically? > > > > I thought it used to be better than that, but solving for multiples of > > 2pi I get different numbers as well, not always 4.13x10^-13 > > What you are getting is the *correct* (and very accurate) answer > for the *numeric* input value that you supplied; the calculator > does not second guess what you meant, but uses the input provided, > and since what you provided was not *exactly* equal to any multiple of pi, > you got the correct, non-zero answer for the small difference > between your input value and the *true* value of some multiple of pi > > In performing these numeric calculations, the calculator uses > an internal value for pi which is correct to at least > 25 decimal places, to deliver results which are correct > to 12 significant digits; this is greater care than many > other calculators go to. > > Some calculators (perhaps Casio) may supply an answer of exactly zero, > which they do by saying, in effect, your input looks quite close > to a multiple of pi, so we'll assume that you meant *exactly* > that value, and therefore we'll give you the answer that you > probably would like to see, instead of an answer > that is faithful to your input. > > Such calculators give pleasing results in these few cases, > but often make wrong assumptions in other cases, > so you can't rely on their answers for other problems > which only accidentally come close to special input values. > > If you'd like results *rounded* to ten places, say, > then do 10 RND after SIN, and lo and behold, > your answers for values close to multiples of pi > will get rounded to zero. > > [r->] [OFF] === Subject: HP 50g and Linux Hi I recently got a HP 50g calculator, and since I've used Linux for almost 2 years now, I'd like my computer and my calculator to get along. either with CKermit or HPTalx. My problem at the moment is that when I plug the calculator in, my computer detects it, but doesn't create the ttyUSB node needed for connection. Can anyone help me with this? - Rene === Subject: Re: My involvement comes to an end... -Brandon Del Bel > Hi all. > > Just a quick note so people do not expect an answer from me regarding HP > calculators anymore. > > I've had enough so I will stop any involvement in the HP graphical > calculators development. > I just can't stand anymore the lack of gratitude nor the constant and > perpetual criticism and whining, the people dedicating their goodwill > and free time keep receiving. I just have better things to do. Ciao > Jean-Yves