akcs.scotty@hpcvbbs.UUCP (SCOTTY THOMPSON) (12/08/90)
I need help. Using binary numbers on my 48SX and trying to raise 2 to the nth power to test a flag has become a difficult and unneccessary chore. When I have large binary numbers and I want to test a bit in that number using the binary AND command, from within a loop or controled from a variable (so I can't just have a big list and pick, enter and choose), I can't get a number that big with floating point because the mantissa is only 32 bits. There are large differences in errors. I could shift the original #, but the overhead is rediculous and slows down my "thought" processes considerably, since I have to test 'i' and figure-out what to shift and the like. Does anyone out there have any work-arounds to a 32 bit mantissa when you need to get a very large (try comparing a large binary number converted to REAL with a REAL generated with the x^y function) binary number from a REAL? I don't really think anyone has really addressed this, 'cause it's easy to get an accurate real from a binary but not the inverse. Any help ASAP would be greatly appreciated, since I am now at a standstill and don't really want to find a million work-arounds until I hear if there is an easy and expedient method for doing the same thing. Thanks...Scotty (213) 539-3611 (Wk), 539-9780 (Hm)
umapd51@cc.ic.ac.uk (W.A.C. Mier-Jedrzejowicz) (12/10/90)
If you need really BIG binary numbers like this then an HP-16C is THE way to go! Of course, if you are using these BIG binary numbers as part of some other HP48SX operation then this is not much help :-( Another :-( is that HP stopped making the HP-16C over a year ago. Everyone (including HP) agreed it was THE best calculator for this kind of work, and especially for even more complicated binary/logical/extended precision operations - but HP decided they were not making enough profit on this product to keep it going. So - if you need it then try to find a store with some left in stock - then try looking for someone with a spare - after that ask around the user clubs. Wlodek Mier-Jedrzejowicz, Space & Atmospheric Physics, Imperial College, London. The above does not necessarily represent any views or undertakings by HP or my employers.
bgribble@jarthur.Claremont.EDU (Bill Gribble) (12/10/90)
In article <1990Dec10.034626.27415@cc.ic.ac.uk> umapd51@cc.ic.ac.uk (W.A.C. Mier-Jedrzejowicz) writes: > >If you need really BIG binary numbers like this then an HP-16C is THE >way to go! Of course, if you are using these BIG binary numbers as part >of some other HP48SX operation then this is not much help :-( It might be an interesting (if overly complex) project to try to implement extended-precision math functions in machine language. You would have to hack a new type for entry and display - say, a string with the first character a # or somesuch. But you could do arbitrarily high precision math. Left as an exercise for the reader :-) >Wlodek Mier-Jedrzejowicz, Space & Atmospheric Physics, Imperial College, >London. ***************************************************************************** ** Bill Gribble Harvey Mudd College, Claremont, CA ** ** bgribble@jarthur.claremont.edu Never heard of it? You're stupid. ** *****************************************************************************
jurjen@cwi.nl (Jurjen NE Bos) (12/10/90)
akcs.scotty@hpcvbbs.UUCP (SCOTTY THOMPSON) writes: >I need help. Using binary numbers on my 48SX and trying to raise 2 >to the nth power to test a flag has become a difficult and unneccessary >chore. There is a simple trick: store the binary in your user flags (from memory: do RCLF 1 ROT PUT STOF), test and set flags to taste, and do RCLF 1 GET. No powering, no problems, gives you the full set of test instructions.
jurjen@cwi.nl (Jurjen NE Bos) (12/10/90)
bgribble@jarthur.Claremont.EDU (Bill Gribble) writes: >In article <1990Dec10.034626.27415@cc.ic.ac.uk> umapd51@cc.ic.ac.uk (W.A.C. Mier-Jedrzejowicz) writes: >> >It might be an interesting (if overly complex) project to try to implement > extended-precision math functions in machine language. You would > have to hack a new type for entry and display - say, a string with the > first character a # or somesuch. But you could do arbitrarily high > precision math. Left as an exercise for the reader :-) No! You don't! The 48SX already has arbitrary-large binaries--except that it cannot do computations with them. The display routines can show binaries of any size in the style C# <number of digits> <digits in reverse order hex> but you cannot enter them. If you want to see some of those numbers, look in the hidden directory (the one with the empty name) and look in your alarm catalog. Alarms are stored like { B E } where B is a 24 nibble binary storing the date, time and repeat interval, and E is the EXEC. (For the nosy ones: this binary stores the value of TICKS of the time and date of the alarm, prepeded by the number of ticks between to repetitions of the alarm. Funny format. This list {B E} can be converted to RCLALARM format with #E1D8 SYSEVAL, if I'm not mistaken.) If only someone would write input and calculation routines for those long binaries...
bson@rice-chex.ai.mit.edu (Jan Brittenson) (12/11/90)
In article <2667@charon.cwi.nl> jurjen@cwi.nl (Jurjen NE Bos) writes: > The 48SX already has arbitrary-large binaries--except that it cannot > do computations with them. ... If only someone would write input and > calculation routines for those long binaries... The HP-48 performs logical operations on strings, and since binary numbers essentially are strings with a different type prefix, all we have to do for AND, OR, XOR, NOT, is to bypass the type check: #188e6 SYSEVAL AND strings #188f5 SYSEVAL OR strings #18904 SYSEVAL XOR strings #18961 SYSEVAL NOT string In fact, these routines can be appled to any object that is a "vector" object, i.e. a type prefix followed by a 20-bit length counting the length itself - Library data, GROB, String, and Binary. So I guess what need are +, -, *, /, and a few shift operations, and we're all set!
frank@grep.co.uk (Frank Wales) (12/11/90)
In article <276057f4:1381comp.sys.handhelds@hpcvbbs.UUCP> akcs.scotty@hpcvbbs.UUCP (SCOTTY THOMPSON) writes: >I need help. Using binary numbers on my 48SX and trying to raise 2 >to the nth power to test a flag has become a difficult and unneccessary >chore. There are more direct ways to diddle bits in binary numbers; off the top of my head, one way is to use the flag operations(*). For example: << RCLF DUP 1 GET 4 ROLL 2 ->LIST STOF SWAP FS? SWAP STOF >> with the binary number to be tested in level two and the bit to test (1..64) in level one returns 0 or 1 as appropriate. Adjust for bits in 0..63 if desired. Being able to set or clear the bits comes free; you could perform several tests or manipulations while the value is in the flags, if that's appropriate to what you're doing. Note that this code scribbles on your User flags if interrupted (by, say, ATTN) or given defective arguments. A more elaborate version could be concocted to avoid these problems by using IFERR, if necessary. Note also that it could be rewritten shorter if use were made of the system flags, as in: << RCLF ROT STOF SWAP NEG FS? SWAP STOF >> but having the system in an arbitrary state might be confusing if this version is elaborated. [(*) Since I've only thought about this for two minutes, no doubt there is a better way. However, using the PICT-based graphics operations to do the bit manipulations is left as an exercise in creative craziness.] >When I have large binary numbers and I want to test a bit in that number >using the binary AND command, from within a loop or controled from a >variable (so I can't just have a big list and pick, enter and choose), >I can't get a number that big with floating point because the mantissa >is only 32 bits. There are large differences in errors. The mantissa isn't 32 bits, it's twelve decimal digits. Since 2^39 is about 5.5e11, you could exponentiate up to 39 before losing precision. -- Frank Wales, Grep Limited, [frank@grep.co.uk<->uunet!grep!frank] Kirkfields Business Centre, Kirk Lane, LEEDS, UK, LS19 7LX. (+44) 532 500303