cloos@acsu.buffalo.edu (James H. Cloos) (02/12/91)
In article <1991Feb9.185644.17146@nntp-server.caltech.edu> anderson@truebalt.caltech.edu (Eric R. Anderson) writes: > > I was debugging a program last night when I ran into what seems to be >strange behavior between binary numbers and SAME. If I add two binary >numbers, then place their sum on the stack, SAME returns 0 if the word >size is less than 61, but 1 if the word size is 61 or greater. Using >== returns 1 for all values of word size. For example, the sequence > > #5d #10d + #15d SAME > >returns different values depending on the word size, while the same >sequence with == replacing SAME always returns 1. It behaves the same >way for subtraction, multiplication, and division, and for hex, oct, and >bin modes. According to the manual, SAME should work the same as == in >this case, since I'm not comparing strings or algebraics. It depends >on what the word size was when the calculation was made, not when SAME >was executed, so > > 61 STWS #5d #10d + #15d 60 STWS SAME > >returns 1. > Is this a bug, a feature, or the way it should work? Any explanations? >The calculator is an E version, by the way. >-- >Eric Anderson eanderso@caltech.bitnet I don't know if this would/should be considered a bug, but I'm not sure if the manual explains this at all. I'll explain what is happening (empiracally, btw ;) and you can draw your own conclusions. First of all, binary integers (a.k.a. Hex Strings) are stored exactly like Strings (a.k.a. Character Strings); only the prolog differs. Second of all, whenever you enter a binary via the command line, regardless of the word size setting, it is created using 64 bits of storage (plus 5 nybbles for teh prolog, plus five nybbles for the size). The problem is that when calculations are done on binaries, the result is created using only as many nybbles as are required for the current wordsize. (Ie, \<< WORDSIZE 4 / 0 RND 4 * \>> will return the number of nybbles needed for WORDSIZE bits.) The result of all this is that, if the wordsize is less than 61, the results of any calculations on binary integers will be less than 16 nybbles long (excluding the prolog and size fields), and SAME will not recognize it as being the SAME as a binary that was entered via the command line. The way around this is to add #0 (or even 0) to the binaries that a) haven't had any calculations done on them, & b) are to be used as arguments for SAME. Or, you can just add binaries to the list of strings and algebraics for those data types for which SAME and == are not the same. (Bill MIGHT have mentioned something along this line in _28_Insights._) -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@ACSU.Buffalo.EDU Snail: PersonalZipCode: 14048-0772, USA cloos@ub.UUCP Quote: <>
sburke@jarthur.Claremont.EDU (Scott Burke) (02/12/91)
But how do you deal with the analogous problem with unit objects, namely:
1_m DUP UBASE SAME yields a 0, not a 1, because for some reason the UBASE
argument is different. I'm not into internals, but the same behavior is
occuring here, I think. My (clumsy) solution was to do something along the
lines of { "'1_m'" } blah blah UBASE \->STR POS to check if I had the
appropriate or desired unit.
Ideas on how to convert 1_m to 1_m? ;-)
Scott.
sburke@jarthur.claremont.educloos@acsu.buffalo.edu (James H. Cloos) (02/12/91)
In article <10768@jarthur.Claremont.EDU> sburke@jarthur.Claremont.EDU (Scott Burke) writes: > >But how do you deal with the analogous problem with unit objects, namely: > >1_m DUP UBASE SAME yields a 0, not a 1, because for some reason the UBASE >argument is different. I'm not into internals, but the same behavior is >occuring here, I think. My (clumsy) solution was to do something along the >lines of { "'1_m'" } blah blah UBASE \->STR POS to check if I had the >appropriate or desired unit. > >Ideas on how to convert 1_m to 1_m? ;-) > >Scott. >sburke@jarthur.claremont.edu Hmmm. This is apparently in response to my response. About the unit objects, in my previous articel where I explained (I hope) everything that I discovered about how they are put together, I mentioned that there is a list at #FA53h (in version A, at least) that contains { 1_kg 1_m 1_A 1_s 1_K 1_cd 1_mol 1_? } and that the output from UBASE uses pointers to each of the strings and the Character 'k' w/in the unit objects w/in that list in place of inline, RAM copies of those elements. I would presume taht this is done either for code-size or execution-speed related efficiency. The end result is that you have to UBASE any unit objects that you want to compare with a UBASEd unit object via SAME. So, to compare 100_cm with 1_m, using SAME, use: 100_cm UBASE 1_m UBASE SAME, for instance. Please excuse any typo's, etc in this article. I'm getting an unexplained profusion of \377's (octal) in my EMACS mode line and whatever is causing it is also causing otehr problems, including a HUGE performance loss. -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@ACSU.Buffalo.EDU Snail: PersonalZipCode: 14048-0772, USA cloos@ub.UUCP Quote: <>