Squeak-dev February 1999

squeak-dev@lists.squeakfoundation.org

148 participants
356 discussions

RE: That Linux Squeak 2.3 float error again
by Florin Mateoc 24 Feb '99

24 Feb '99

It is perfectly reasonable to expect external libraries to behave properly, but they only have to behave properly over the domain where they were defined. log is only defined for 0<x<Infinity (since we don't have complex numbers, but even if we do, it is not defined for 0). I don't think we could (or should) rely on log(0) returning -Infinity and then exp() to handle normal numbers as well as Infinities (and having portable code at the same time). I just checked the VisualWorks 2.5 code and their Number>>raisedTo: is similar to what I proposed earlier (their Float>>raisedTo: is a primitive, when it fails it executes the Number>>raisedTo: code), except they don't check thoroughly enough (grin:-) and 0 raisedTo: -1.5 -> 0 0.0 raisedTo: -1.5 -> 0.0 In VisualAge 4.5, even less checks, only one method #raisedTo: (in Number) and 0 raisedTo: -1.5 -> 0 0.0 raisedTo: -1.5 -> 0 (SmallInteger!) In Squeak/NT/x86 0 raisedTo: -1.5 -> -0.0 0.0 raisedTo: -1.5 -> -0.0 which are the same results as for 0 raisedTo: 0.75 (but in this case even further from reality) And IMHO 0 raised to 0 should also raise an exception as undefined, even though all Smalltalks consistently return 1. Just because it's widespread doesn't make it right. Florin -----Original Message----- From: David T. Lewis [mailto:lewis@mail.msen.com] Sent: Tuesday, February 23, 1999 8:42 PM To: squeak(a)cs.uiuc.edu Subject: Re: That Linux Squeak 2.3 float error again > > "Richard L. Peskin" <rlpcon(a)vermontel.net> wrote: > > Has anyone verified the float error in Squeak 2.3 Linux, that is the > error: > > 0.0 raisedTo: 0.75 ==> NaN ? > > On linux it seems to be the C library exp() which is at fault. > > log(0.0) = -Inf > log(0.0)*0.75 = -Inf > exp(log(0.0)*0.75) = NaN > Some further explanation of the behavior of Float>>exp in Squeak: The Float>>exp method in Squeak is based on the behavior of exp() in the C runtime library. The Squeak VM (at least on Unix) assumes that the underlying C library behaves reasonably for the boundary conditions of negative infinity and positive infinity. In fact, however, implementations of the C library vary. On my Intel Linux system, the exp() function returns NaN when passed either negative infinity or infinity as an argument. On an Intel BSDI system (Berkeley derived system), the exp() function returns zero and Inf respectively, which I presume to be the "correct" results. As far as I know, all Squeak VMs will rely on the underlying C library, as they are all built on the C code generated from the Interpreter class>>translate:doInlining: method. Therefore, I would expect Mac, Windows, and other systems to have Float>>exp methods which behave only as well as their underlying C libraries. Certainly it is possible to add tests for the boundary conditions in the Squeak VM code, albeit at some cost of complexity and performance. But first the question would be, what is the "right thing to do" here? Should Squeak expect the underlying system libraries to be correct, or should it attempt to compensate for behavior of the runtime libraries in the interest of consistent Squeak behavior? My own inclination would be to leave Squeak well enough alone, but possibly document the dependency on the underlying libraries in the class documentation. For reference, here is the output of a test program (derived from Lex's earlier post) run first on Linux, then on BSDI. Following the output is a copy of the C test program. ------- Linux output ----------- show behavior of C library exp() function at boundary conditions for Linux dtlewis 2.0.35 #3 Fri Jan 1 17:22:57 EST 1999 i586 unknown negative infinity: log(0.0) = -Inf (ff f0 00 00 00 00 00 00 ) negative infinity again: log(0.0)*0.75 = -Inf (ff f0 00 00 00 00 00 00 ) exp of negative infinity: exp(log(0.0)*0.75) = NaN (ff f8 00 00 00 00 00 00 ) positive infinity: exp(1.0e100)) = Inf (7f f0 00 00 00 00 00 00 ) exp of positive infinity: exp(exp(1.0e100))) = NaN (ff f8 00 00 00 00 00 00 ) ------- BSDI output ------------ show behavior of C library exp() function at boundary conditions for BSD/OS conch.msen.com 2.1 BSDI BSD/OS 2.1 Kernel #0: Fri Jan 16 18:51:12 EST 1998 wayne@ww2.msen.com:/msen/sys/compile/CONCH.gated i386 negative infinity: log(0.0) = -Inf (ff f0 00 00 00 00 00 00 ) negative infinity again: log(0.0)*0.75 = -Inf (ff f0 00 00 00 00 00 00 ) exp of negative infinity: exp(log(0.0)*0.75) = 0.000000 (00 00 00 00 00 00 00 00 ) positive infinity: exp(1.0e100)) = Inf (7f f0 00 00 00 00 00 00 ) exp of positive infinity: exp(exp(1.0e100))) = Inf (7f f0 00 00 00 00 00 00 ) ------- Test program ----------- #include <math.h> #include <stdio.h> void ddump (unsigned char *d) { int i; d += (sizeof (double) - 1); printf ("("); for (i = 0; i < sizeof (double); i++) { printf ("%02x ", *d); d--; } printf (")\n"); } int main (void) { union { unsigned char c[sizeof (double)]; double d; } v; printf ("show behavior of C library exp() function at boundary conditions for\n"); fflush (stdout); system ("uname -a"); printf ("\nnegative infinity:\n"); v.d = log (0.0); printf ("log(0.0) = %f ", v.d); ddump (v.c); printf ("\nnegative infinity again:\n"); v.d = log (0.0) * 0.75; printf ("log(0.0)*0.75 = %f ", v.d); ddump (v.c); printf ("\nexp of negative infinity:\n"); v.d = exp (log (0.0) * 0.75); printf ("exp(log(0.0)*0.75) = %f ", v.d); ddump (v.c); printf ("\npositive infinity:\n"); v.d = exp (1.0e100); printf ("exp(1.0e100)) = %f ", v.d); ddump (v.c); printf ("\nexp of positive infinity:\n"); v.d = exp (exp (1.0e100)); printf ("exp(exp(1.0e100))) = %f ", v.d); ddump (v.c); return 0; }

1 0

Re: That Linux Squeak 2.3 float error again
by Tim Olson 24 Feb '99

24 Feb '99

>Should Squeak expect the underlying system >libraries to be correct, or should it attempt to compensate for >behavior of the runtime libraries in the interest of consistent >Squeak behavior? My own inclination would be to leave Squeak >well enough alone, but possibly document the dependency on the >underlying libraries in the class documentation. I agree with this direction -- the right thing to do is get the libraries fixed. For the x86 Linux environments that are broken, it should be a quick fix that will also benefit more than the Squeak project. FYI, this isn't a generic Linux problem -- my Mac running Red-Hat release 5 gets the "correct" answers from your test program: Linux version 2.1.125 (paulus(a)cargo.anu.edu.au) (gcc version egcs-2.90.25 980302 (egcs-1.0.2 prerelease)) #25 Wed Oct 14 13:40:58 EST 1998 show behavior of C library exp() function at boundary conditions for Linux megalith.localdomain 2.1.125 #25 Wed Oct 14 13:40:58 EST 1998 ppc unknown negative infinity: log(0.0) = -Inf (00 00 00 00 00 00 f0 ff ) negative infinity again: log(0.0)*0.75 = -Inf (00 00 00 00 00 00 f0 ff ) exp of negative infinity: exp(log(0.0)*0.75) = 0.000000 (00 00 00 00 00 00 00 00 ) positive infinity: exp(1.0e100)) = Inf (00 00 00 00 00 00 f0 7f ) exp of positive infinity: exp(exp(1.0e100))) = Inf (00 00 00 00 00 00 f0 7f ) -- tim

2 1

Re: That Linux Squeak 2.3 float error again
by R. A. Harmon 24 Feb '99

24 Feb '99

At 08:41 PM 2/23/99 -0500, David T. Lewis wrote: >Some further explanation of the behavior of Float>>exp in Squeak: > >The Float>>exp method in Squeak is based on the behavior of exp() in >the C runtime library. The Squeak VM (at least on Unix) assumes that >the underlying C library behaves reasonably for the boundary conditions >of negative infinity and positive infinity. In fact, however, >implementations of the C library vary. [snip] That seems to be a receipt for endless errors without resolution. I wonder if a useful approach in Squeak might be to leverage off the work of another body of user supported code so that their improvements are automatically gained by Squeak. What comes to mind is GNU or Linux C or C++, or even Lisp. There might be licensing problems with this. Another approach might be to have a Squeak C interface library that uses the C runtime library but corrects for anomalies between the interface and the C runtime. One could fairly easily determine once what the anomalies are with a C runtime, and then handle them. With a library test suite, I think the anomalies with a C runtime could be quickly identified and easily handled. I have no experience programming on UNIX. I seem to remember seeing this same problem in almost every UNIX application I ported to DOS, and in portable implementations of other languages (CLisp is the one I remember). I suspect a good starting point for a solution is to see how others have handled it. Could those of you who have experience with portability problems comment on what solution you've seen that was most effective? The macros that implemented this consistency were horrendously ugly stuff, but once you saw the pattern, adding a new configuration was pretty straight forward and there didn't appear to be any runtime costs. >Certainly it is possible to add tests for the boundary conditions >in the Squeak VM code, albeit at some cost of complexity and >performance. But first the question would be, what is the "right >thing to do" here? Should Squeak expect the underlying system >libraries to be correct, or should it attempt to compensate for >behavior of the runtime libraries in the interest of consistent >Squeak behavior? My own inclination would be to leave Squeak >well enough alone, but possibly document the dependency on the >underlying libraries in the class documentation. [snip] I think this just moves the problem to the documentation. -- Richard A. Harmon "The only good zombie is a dead zombie" harmonra(a)webname.com E. G. McCarthy

1 0

Re: getting started
by JArchibald＠aol.com 24 Feb '99

24 Feb '99

In a message dated 2/23/99 2:34:33 PM Eastern Standard Time, lex(a)cc.gatech.edu writes: << - a three button mouse >> Does Squeak actually use a three button mouse in a Windoze framework? Do you need specific device drivers to make this happen? (I ask this because a couple of years back I was doing a project in VisualWorks, had several different three button mice (mouses, ? moose) available to me, and couldn't get any to work in the original red,yellow,blue configuration. I had to resort to the (now) normal use of Alt- (or other) with mouse button combinations.) Jerry Archibald System Objectives Inc.

2 1

Re: Optimizing Squeak
by Tim Olson 24 Feb '99

24 Feb '99

Greg wrote: [good summary of BTAC & BTIC operation on bytecode dispatch] >The BTIC used in the PPC 750 has a different purpose. By caching the >branch target instructions, these instructions can be decoded on the >cycle following the decode of a branch instruction rather than two >cycles afterwards. However, it doesn't help predict addresses of >indirect branches, so you always get a branch misprediction on any >indirect branch. You are correct that the BTIC on the PPC 750 doesn't help predict the address for indirect branches. However, in PowerPC, indirect branches are handled by moving the address to either the link or count register, then branching indirect on one of those. If the move to the link or count register is performed sufficiently ahead of the indirect branch on the PPC 750 (say, in threaded code where the dispatch of the next instruction is handled by the tail end of the previous instruction), then no stall will occur, as there will be no prediction (the address is known when the branch is seen). >I believe BHTs came before BTACs or BTICs... The first BTIC I'm aware of is on the AMD 29K (ca 1987), while BHTs came to microprocessors later. -- tim

1 0

Re: That Linux Squeak 2.3 float error again
by Lex Spoon 24 Feb '99

24 Feb '99

"Richard L. Peskin" <rlpcon(a)vermontel.net> wrote: > Has anyone verified the float error in Squeak 2.3 Linux, that is the error: > 0.0 raisedTo: 0.75 ==> NaN ? > > I am trying to see if it is my system or a primitive error. > > thanks, > --dick peskin > On linux it seems to be the C library exp() which is at fault. log(0.0) = -Inf log(0.0)*0.75 = -Inf exp(log(0.0)*0.75) = NaN The test program is appended. In cas somebody else's linux box is better, here's my computer's stats: Linux 2.2.1 AMD K6-2/300Mhz libc 5.4.23 libm 5.0.8 I tried this program on a Solaris box, by the way, and the last answer was 0. Lex #include <math.h> #include <stdio.h> int main(void) { printf("log(0.0) = %f\n", log(0.0)); printf("log(0.0)*0.75 = %f\n", log(0.0) * 0.75); printf("exp(log(0.0)*0.75) = %f\n", exp(log(0.0) * 0.75)); return 0; }

4 3

Building Squeak for Solaris 5.6 [was: Re: Need help building 2.3 VM.]
by Bill Cattey 24 Feb '99

24 Feb '99

I saw the messages from Juan Cires Martinez <jcm(a)mat.upm.es>, and Andrew C. Greenberg <werdna(a)gate.net> but I still don't have enough information to set my Solaris 2.6 VM build right. How come Ian's works on 2.5.1 and mine does not? (I'm building with gcc version 2.8.1, if that matters). -wdc

2 2

New SGI Squeak binary available from MIT.
by Bill Cattey 24 Feb '99

24 Feb '99

Doug Way reported a simple benchmark to me: Time millisecondsToRun: [100 factorial] and pointed out that his 2.2VM on his 180MHz O2 ran it twice as fast. (~50 vs ~95). On my 200 MHz O2, I was getting ~50, but on my 300 MHz Sparc, I was getting ~20.) This was sufficient information for me to try setting "-OPT:Olimit=4000" to force the global optimizer in the MIPS C compiler to act on interp.c. It took a couple minutes to compile, but the resulting binary is now giving me ~40 miliseconds. I expect, then, that others would find the speed greater with optimization forced. I've replaced the binary. Find it in: http://web.mit.edu/squeak/arch/sgi_63/bin/SqueakVM-2.3-SGI-irix-6.3 I've modified http://web.mit.edu/squeak/src/2.3/src/GNUmakefile.conf for those interested in the source. -wdc

1 0

RE: shift-cmd keys [BUG][FIX]
by Norton, Chris 24 Feb '99

24 Feb '99

Hi Folks. Since I have access to a PC (and not to a Mac, UNIX box, Acorn or to some other interesting platform), I have also struggled somewhat with the key configuration. I miss my delete key! I'm basically a Squeak newbie, but I'm gaining ground every day. So rather than volunteer at this point to design and implement a solution to this problem, I'll politely ask if anyone has considered creating a Squeak "preferences" file that could be configured and would not be overwritten whenever we download the latest & greatest versions of Squeak. Thus, if the (programmable?) keyboard issue is resolved, we could configure our systems & save such configuration info into our preferences file. I have already overwritten my preferences settings several times and it is a bit inconvenient to have to go back and reload my chosen color settings, author initials, font selections, etc.. Just an idea. :-) ---==> Chris > -----Original Message----- > From: Tim Rowledge [SMTP:rowledge@interval.com] > Sent: Saturday, February 20, 1999 12:27 PM > To: Squeak mailinglist > Subject: Re: shift-cmd keys [BUG][FIX] > > On Fri 19 Feb, William O. Dargel wrote: > > > This all seems to point out the need for a more general overhaul of how > keys get mappe > > d to > > commands. We should be able to handle all the platforms _and_ user > preferences for key > > mappings by at most plugging in a new (or modifying the current) table > of key-bindings > > . And > > it would of course want to interface cleanly with getting events from > the OS rather th > > an the > > current polling method, and be dynamically reconfigurable ala menu > accelerator keys as > > your > > context changes, and... But perhaps I digress. > > I thought it would probably be something like that which caused your > changes. Yes, you're right, key input needs an overhaul to be more > platform > portable. At the moment, everyone except Mac has complicated code to > translate from native to 'best I can work out what is needed to match'. > > An idea Eliot came up with a _long_ time ago was to pass in the raw native > key values and have a small hierarchy of SystemDescription classes that > had > nice intelligable code to translate to Smalltalk events. It had the big > advantage that no VM fixing was needed, that new keymappings could be > added > and so on. IIRC the classes also encapsulated which file related classes > needed to be active, how external calls where done etc. Very useful. > > Now if you mix that with the startup file idea where a file is looked for > and if found, filed in to do some startup work, we could simply have > platform specific files with the SystemDescription (and maybe even > personal > preference settings?). And it should probably be binary streamed through > FrootLoop :-) > > tim > > -- > Useful random insult:- A prime candidate for natural deselection. > Tim Rowledge: rowledge(a)interval.com (w) +1 (650) 842-6110 (w) > tim(a)sumeru.stanford.edu (h) <http://sumeru.stanford.edu/tim>

3 2

Re: Type inference (was: Classical Applications)
by Leandro Caniglia 23 Feb '99

23 Feb '99

Markus Denker wrote: >>http://www.sunlabs.com/techrep/1996/abstract-52.html >> >> Concrete Type Inference: Delivering Object-Oriented Applications >> Ole Agesen >> TR-96-52 (January 1996) >> >>| Abstract >>| ..... >>| We have designed, implemented, and evaluated an algorithm, .... , that >>| can infer concrete types of object oriented programs. ... >>| Our implementation handles most of the dynamically-typed Self >>| language,... >> I want something like this in Squeak! And Joachim Durchhols responded: >This relies heavily on static typing. I've read the (really interesting) dissertation by Ole Agesen and don't think so. The work has nothing to do with static typing. In the context of Agesen's research, type inference refers to the analysis of normal Self (or Smalltalk) programs; i.e., without the aid of any kind of type declaration. In fact we are trying to do "something like this in Squeak", and have written some code implementing the ideas of the author (namely his cartesian product algorithm). Leandro

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
36
Older →

Jump to page: