barry@pico.math.ucla.edu (Barry Merriman) (03/03/91)
I have found a nasty, basic bug in NeXT Mathematica
(Mathematica 1.2, running on a 2.0 Slab---but copied from
a 1.0a 030 cube, though).
The bug: Tanh[x] is not computed correctly. To _see_ if you have
it, do
Plot[Tanh[x],{x,-3,3}]
and see if there is an obvious discontinuity in the graph. Or,
do
Tanh[-1.8]
and see if you get a number < -1 (note Range of tanh is (-1,1)).
The consensus of the mathematica mailing list is that this bug is
a byproduct of the interaction between M'ma 1.2 and NeXTStep 2.0
(although one fellow claims the above crashes his SparcStation!?)
Hopefully it will be fixed in M'ma 2.0---since Wolfram is on
tour and will be at UCLA next week, I'll ask him :-).
However, if you write your own tanh[x] in terms of exponentials,
it works fine.
--
Barry Merriman
UCLA Dept. of Math
UCLA Inst. for Fusion and Plasma Research
barry@math.ucla.edu (Internet)bchen@eeyore.caltech.edu (Bing-Qing Chen) (03/03/91)
In article <1991Mar3.053006.2986@math.ucla.edu> barry@pico.math.ucla.edu (Barry Merriman) writes: > >The bug: Tanh[x] is not computed correctly. To _see_ if you have >it, do > >Plot[Tanh[x],{x,-3,3}] > >and see if there is an obvious discontinuity in the graph. Or, >do > >Tanh[-1.8] > >and see if you get a number < -1 (note Range of tanh is (-1,1)). > It seems that only Mathematica on 040 NeXT failed to compute Tanh[-1.8] correctly. Mathematica on 030 NeXT gives the correct result. I have run into such problems before. I believe it is because Mathematica was compiled under 1.0. - Bing Chen bchen@pooh.caltech.edu
charlie@wam.umd.edu (Charles William Fletcher) (03/04/91)
In article <1991Mar3.053006.2986@math.ucla.edu> barry@pico.math.ucla.edu (Barry Merriman) writes: >I have found a nasty, basic bug in NeXT Mathematica >(Mathematica 1.2, running on a 2.0 Slab---but copied from >a 1.0a 030 cube, though). > >The bug: Tanh[x] is not computed correctly. To _see_ if you have >it, do > >Plot[Tanh[x],{x,-3,3}] > >and see if there is an obvious discontinuity in the graph. Or, >do > >Tanh[-1.8] > >and see if you get a number < -1 (note Range of tanh is (-1,1)). > >The consensus of the mathematica mailing list is that this bug is >a byproduct of the interaction between M'ma 1.2 and NeXTStep 2.0 >(although one fellow claims the above crashes his SparcStation!?) >Hopefully it will be fixed in M'ma 2.0---since Wolfram is on >tour and will be at UCLA next week, I'll ask him :-). > >However, if you write your own tanh[x] in terms of exponentials, >it works fine. > >-- >Barry Merriman >UCLA Dept. of Math >UCLA Inst. for Fusion and Plasma Research >barry@math.ucla.edu (Internet) Wolfram left a message on the math net that a minimal C program *compiled* on an 040 NeXT returned an incorrect value for the TANH. His conclusion is to blame the math (C) library on the NeXT which is used by Mma. Cameron Smith (formally of WRI) concurs after running Mma several places. Anyone out there want to try this and post results? Is this a NeXT bug or an 040 bug? -Charlie
smithw@hamblin.math.byu.edu (Dr. William V. Smith) (03/04/91)
In article <1991Mar3.053006.2986@math.ucla.edu> barry@pico.math.ucla.edu (BarryMerriman) writes: >I have found a nasty, basic bug in NeXT Mathematica >(Mathematica 1.2, running on a 2.0 Slab---but copied from >a 1.0a 030 cube, though). This bug is apparently not a MMA kernel bug. The function is correctly evaluated and plotted with an '030 NeXT MMA 1.2 (Jan. 1990 version), but the same version running on an '040 NeXTcube shows the problem (both cubes running 2.0 NeXT software(extended)). The '030 - 1.0a software does not seem to have this problem. So. . . This may be a hardware based (or perhaps hardware related) problem. It does not seem to show up on other MMA platforms (which also have their own bugs with regard to MMA graphics). Someone has also noted a problem with C and the hyperbolic tangent function ('040 NeXTs). It's quite possible these are the same difficulty. The problem goes away if instead of calling tanh, you use the explicit definition of tanh in terms of the exponential function, so this may be a problem with the 68040 itself. The rather interesting thing is that the problem only seems to manifest itself over a rather narrow range of negative values (apparently) as doing Plot[Tanh[x], {x,-3,3}] shows. I might note in the same vein that tan also seems to have some plot problems in MMA over certain ranges (maybe it was arctan- can't remember now) on the NeXT, but I have not tried to duplicate these on other platforms or other NeXT configs. -Bill -- EMail: smithw@hamblin.math.byu.edu or uunet!hamblin.math.byu.edu!smithw SMail: Math Dept. -- 314 TMCB; BYU; Provo, UT 84602 (USA) NeXTmail: smithw@mathnx.math.byu.edu Phone: +1 801 378 2061 FAX: +1 801 378 2800
madler@kanga.caltech.edu (Mark Adler) (03/04/91)
The following program:
#include <stdio.h>
#include <math.h>
void main(void)
{
printf("%g %g\n", tanh(-1.73287), tanh(-1.73288));
}
when compiled and run under 2.0, gives the result:
-0.939394 -0.939395
(correct) on a 68030 NeXT running 2.0, but incorrectly gives:
-0.939394 -1.060605
on a 68040 NeXT, using the very same binary executable. Wolfram's
comment was: "Mathematica (apparently mistakenly) relies on built-in
math functions." Gee, I guess so.
This is not the only problem with math on the 68040 (see Bing Chen's
quick-and-easy-way-to-completely-hang-your-NeXT-so-that-not-even-command-
alternate-*-works-using-only-simple-floating-point-division-operations).
I have absolutely no confidence in any numerical results my newly upgraded
NeXT gives me, and I have complained mightily in a message to bug_next@
next.com. I think I may call them tommorrow and ask for my 030 board
back and see if that gets their attention.
I sure do hope that all of the math problems can be handled simply
by a software upgrade ...
Mark Adler
madler@pooh.caltech.edumcguire@cs.tamu.edu (Tim McGuire) (03/06/91)
NeXTologist smithw@hamblin.math.byu.edu (Dr. William V. Smith) writes: >barry@pico.math.ucla.edu (BarryMerriman) writes: >>I have found a nasty, basic bug in NeXT Mathematica >>(Mathematica 1.2, running on a 2.0 Slab---but copied from >>a 1.0a 030 cube, though). >This bug is apparently not a MMA kernel bug. The function is correctly >evaluated and plotted with an '030 NeXT MMA 1.2 (Jan. 1990 version), but the >same version running on an '040 NeXTcube shows the problem (both cubes >running 2.0 NeXT software(extended)). The '030 - 1.0a software does not >seem to have this problem. So. . . >.... The problem goes away if instead of calling tanh, you use >the explicit definition of tanh in terms of the exponential function, >so this may be a problem with the 68040 itself. The problem is apparently not with the 68040. Some helpful person on the Mathematica mailing list (whose name slips me) reports the problem occurs when the #include <math.h> directive is omitted, but disappears when it is put in in a minimal C program calling the tanh function. It seems the 030 version of the kernel didn't care. Tim McGuire mcguire@cs.tamu.edu
smithw@hamblin.math.byu.edu (Dr. William V. Smith) (03/06/91)
mcguire@cs.tamu.edu (Tim McGuire): writes: >The problem is apparently not with the 68040. Some helpful person on the >Mathematica mailing list (whose name slips me) reports the problem >occurs when the #include <math.h> directive is omitted, but disappears The test was done on an '030 cube (2.0 software, 1.2 mma). It is true that when math.h is not included there appears to be a problem on '030 and the "problem" goes away when you insert #include <math.h>. However, when math.h is included *on the '040 NeXT* there is still a real discontinuity in tanh(). Since tanh() is trapped and computed in software, this is a software fix (hope, hope, hope). There is a code error which gives the correct asymptotic value of tanh(x) as x-> minus infinity, but switches formulas for computing tanh at about x=-1.8. Witness: (this file "test2.c") #include <math.h> main() { printf("%g %g\n", tanh(-1.73287), tanh(-1.73288)); } yields the result (this is on *the '040 cube*) ^^^^^^^^^^^^^ Venus%% cc test2.c -o mathtest Venus%% mathtest -0.939394 -1.060605 -1.060605 is NOT the correct value for tanh(-1.73288) which is in fact this is the result of the same program on an '030 cube: ^^^^^^^^ zuni$ cc test2.c -o mathtest zuni$ mathtest -0.939394 -0.939395 -0.939395 *is* (approximately of course) the correct value of tanh(-1.73288). This is an '040 specific problem, and has nothing to do with mathematica except that mathematica does use machine coded functions to do numerical work with elementary functions. (If the #include <math.h> is left out, then both platforms yield errors since this function is called as a double, and the compiler doesn't know what to do with it without math.h) So, NeXT, please include the fix in 2.1 ok??? -Bill -- EMail: smithw@hamblin.math.byu.edu or uunet!hamblin.math.byu.edu!smithw SMail: Math Dept. -- 314 TMCB; BYU; Provo, UT 84602 (USA) NeXTmail: smithw@mathnx.math.byu.edu Phone: +1 801 378 2061 FAX: +1 801 378 2800
smithw@hamblin.math.byu.edu (Dr. William V. Smith) (03/06/91)
finn@theory.tn.cornell.edu (Lee Samuel Finn)writes: >As a second note, I have compiled and (attempted) to run the Cody & Waite >elementary functions test suite on the NeXT '040 cube. These are FORTRAN >programs that test elementary functions in single and double precision >against identities, special values, and in some cases coded approximations >in various argument ranges. I compiled these puppies with both f2c/cc and >Absoft FORTRAN, and found quite a few of them would toast my cube so bad >that I had to yank the power cord: I couldn't get too the monitor, the power >key wouldn't respond, the mouse and keyboard were dead --- life, as we know >it, was extinguished in a flash of bits. Damn! -- EMail: smithw@hamblin.math.byu.edu or uunet!hamblin.math.byu.edu!smithw SMail: Math Dept. -- 314 TMCB; BYU; Provo, UT 84602 (USA) NeXTmail: smithw@mathnx.math.byu.edu Phone: +1 801 378 2061 FAX: +1 801 378 2800
charlie@wam.umd.edu (Charles William Fletcher) (03/06/91)
Hopefully I can finish what I started. I was informed by NeXT the the bug associated with the Tanh[x] is in the Motorola software and will be fixed in 2.1. Related-I plotted tanh(x) using Gnuplot 2.02 compiled under 1.0. There was no problem-it correctly plotted. I'm not sure why this happens unless Gnuplot keeps all its math functions internal. Mark ....? -Charlie cwf@math.umd.edu
smithw@hamblin.math.byu.edu (Dr. William V. Smith) (03/06/91)
mcguire@cs.tamu.edu (Tim McGuire): writes: >The problem is apparently not with the 68040. Some helpful person on the >Mathematica mailing list (whose name slips me) reports the problem >occurs when the #include <math.h> directive is omitted, but disappears The test was done on an '030 cube (2.0 software, 1.2 mma). It is true that when math.h is not included there appears to be a problem on '030 and the "problem" goes away when you insert #include <math.h>. However, when math.h is included *on the '040 NeXT* there is still a real discontinuity in tanh(). Since tanh() is trapped and computed in software, this is a software fix (hope, hope, hope). There is a code error which gives the correct asymptotic value of tanh(x) as x-> minus infinity, but switches formulas for computing tanh at about x=-1.8. Witness: (this file "test2.c") #include <math.h> main() { printf("%g %g\n", tanh(-1.73287), tanh(-1.73288)); } yields the result (this is on *the '040 cube*) ^^^^^^^^^^^^^ Venus%% cc test2.c -o mathtest Venus%% mathtest -0.939394 -1.060605 -1.060605 is NOT the correct value for tanh(-1.73288) which is in fact this is the result of the same program on an '030 cube: ^^^^^^^^ zuni$ cc test2.c -o mathtest zuni$ mathtest -0.939394 -0.939395 -0.939395 *is* (approximately of course) the correct value of tanh(-1.73288). This is an '040 specific problem, and has nothing to do with mathematica except that mathematica does use machine coded functions to do numerical work with elementary functions. (If the #include <math.h> is left out, then both platforms yield errors since this function is called as a double, and the compiler doesn't know what to do with it without math.h) So, NeXT, please include the fix in 2.1 ok??? -Bill -- EMail: smithw@hamblin.math.byu.edu or uunet!hamblin.math.byu.edu!smithw SMail: Math Dept. -- 314 TMCB; BYU; Provo, UT 84602 (USA) NeXTmail: smithw@mathnx.math.byu.edu Phone: +1 801 378 2061 FAX: +1 801 378 2800
finn@theory.tn.cornell.edu (Lee Samuel Finn) (03/06/91)
In article <13048@helios.TAMU.EDU> mcguire@cs.tamu.edu (Tim McGuire) writes: >NeXTologist smithw@hamblin.math.byu.edu (Dr. William V. Smith) writes: > >barry@pico.math.ucla.edu (BarryMerriman) writes: > >>I have found a nasty, basic bug in NeXT Mathematica > >>(Mathematica 1.2, running on a 2.0 Slab---but copied from > >>a 1.0a 030 cube, though). > >This bug is apparently not a MMA kernel bug. The function is correctly > >evaluated and plotted with an '030 NeXT MMA 1.2 (Jan. 1990 version), but the > >same version running on an '040 NeXTcube shows the problem (both cubes > >running 2.0 NeXT software(extended)). The '030 - 1.0a software does not > >seem to have this problem. So. . . > >.... The problem goes away if instead of calling tanh, you use > >the explicit definition of tanh in terms of the exponential function, > >so this may be a problem with the 68040 itself. > > The problem is apparently not with the 68040. Some helpful person on the > Mathematica mailing list (whose name slips me) reports the problem > occurs when the #include <math.h> directive is omitted, but disappears > when it is put in in a minimal C program calling the tanh function. It > seems the 030 version of the kernel didn't care. > > Tim McGuire > mcguire@cs.tamu.edu No, No, No. Red herring. The problem is with the software emulation of FTANH in 040 NeXT boxes. It has nothing to do with the presence or absence of #include <math.h>. To verify, run it yourself and see. It's really not that hard :-). As a second note, I have compiled and (attempted) to run the Cody & Waite elementary functions test suite on the NeXT '040 cube. These are FORTRAN programs that test elementary functions in single and double precision against identities, special values, and in some cases coded approximations in various argument ranges. I compiled these puppies with both f2c/cc and Absoft FORTRAN, and found quite a few of them would toast my cube so bad that I had to yank the power cord: I couldn't get to the monitor, the power key wouldn't respond, the mouse and keyboard were dead --- life, as we know it, was extinguished in a flash of bits. Now, given that inexcusable is the verb of choice to describe bad standard math libraries (and I don't know if Motorola or NeXT is to blame on that score --- and I really don't care either, I just want it fixed), what can one possibly say about an OS that goes catatonic at the sight of random user programs? Sam Finn
madler@pooh.caltech.edu (Mark Adler) (03/06/91)
>> the helpful person is Cameron Smith, who lives in Middlebury, VT and >> is quite the Mma expert. Except that, about the tanh() bug, he incorrectly interpreted the problem, and seems to have fooled a lot of other people into thinking the same silly thing about the problem having to do with leaving out the necessary include directive. Mark Adler madler@pooh.caltech.edu
madler@pooh.caltech.edu (Mark Adler) (03/06/91)
In article <1991Mar5.181203.11715@wam.umd.edu> charlie@wam.umd.edu (Charles William Fletcher) writes: >Related-I plotted tanh(x) using Gnuplot 2.02 compiled under 1.0. >There was no problem-it correctly plotted. I'm not sure why this >happens unless Gnuplot keeps all its math functions internal. Mark ....? Hi. Yeah, it's because gnuplot uses sinh() and cosh() to compute tanh(), and that bypasses the FTANH bug in 2.0. Why do they use sinh() and cosh() you ask? (I knew you would.) Because the operations in gnuplot work on complex numbers as well, and it is easiest to write tanh(z) in terms of the real functions sinh(), cosh(), sin(), and cos(). Mark Adler madler@pooh.caltech.edu
bennett@mp.cs.niu.edu (Scott Bennett) (03/06/91)
In article <1991Mar5.181203.11715@wam.umd.edu> charlie@wam.umd.edu (Charles William Fletcher) writes: >Hopefully I can finish what I started. I was informed by NeXT the >the bug associated with the Tanh[x] is in the Motorola software >and will be fixed in 2.1. > >Related-I plotted tanh(x) using Gnuplot 2.02 compiled under 1.0. >There was no problem-it correctly plotted. I'm not sure why this >happens unless Gnuplot keeps all its math functions internal. Mark ....? If you built gnuplot with the Makefile that comes with it, that would explain it. If memory serves me, that Makefile does its compiles and linkedits with a -lm, so the BSD math library is available to resolve the function references. The sources do not #include <math.h>, so no in-line transcendental instructions get generated. > >-Charlie >cwf@math.umd.edu Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "I, however, place economy among the first and most important * * of republican virtues, and public debt as the greatest of the * * dangers to be feared." --Thomas Jefferson * **********************************************************************
rca@cs.brown.edu (Ronald C.F. Antony) (03/06/91)
>>As a second note, I have compiled and (attempted) to run the Cody & Waite >>elementary functions test suite on the NeXT '040 cube. These are FORTRAN [...] >>Absoft FORTRAN, and found quite a few of them would toast my cube so bad >>that I had to yank the power cord: I couldn't get too the monitor, the power >>key wouldn't respond, the mouse and keyboard were dead --- life, as we know >>it, was extinguished in a flash of bits. > >Damn! It's good to mention these things here, it is a lot better though to send an exact description of what happened + code to bug-next@next.com this will certainly interest NeXT and also speed up the process of bug fixing. Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rca@cs.brown.edu or antony@browncog.bitnet
madler@eeyore.caltech.edu (Mark Adler) (03/07/91)
A side note on the 68040 FTANH bug saga ... A fellow on the Mathematica mailing list, Cameron Smith, had guessed, in a posting to that list, that the problem with Stephen Wolfram's code fragment that showed the discontinuity in tanh() was due to a missing #include <math.h> directive. This was not the case, however. Unbeknownst to him, this conclusion was repeated on comp.sys.next, several times even. He saw a posting of mine calling this conclusion "silly", and, being unable to post directly to comp.sys.next himself, sent me a message that included this request: > I have no problem with what you wrote. You were right; my comment > *was* silly. But, if nothing else, this tells me that (1) you > were interested in this topic and (2) you can post. So I'm asking > you as a favor to me to post a message on my behalf to comp.sys.next, > saying the following things: > > a) apologies to WRI and Stephen Wolfram for misplaced blame, > b) apologies to the net at large for confusion I caused, > c) thanks to the (many) people who emailed me to point out > and explain my misunderstanding, and to give me facts > about what was really happening. > > Thanks for your help. > --Cameron Smith And by including his request, I have thusly satisfied it. (Cut and paste sure is handy!) Mark Adler madler@pooh.caltech.edu