arxt@tank.uchicago.edu (patrick palmer) (03/24/90)
I finally received my copy of Manx5.0, and I have been testing it out
by recompiling and rerunning some old programs. Results have been
worrisome. With one small program, I get the correct answer with
Manx3.4 (checked by hand and checked by compiling the same code on an
Elexsi and a Sun 3), but an answer that is precisely a factor of 100
smaller with Manx5.0. How can this be???
By the way, the code is almost exactly a factor of 2 larger with
Manx5.0; even though the version with 3.4 was compiled with +L option
and linked to -lm32 -lc32. (The Manx5.0 version is about 40% larger
than the Elexsi version.) What is happening here? Are we to conclude
that 5.0 gives larger code and wrong answers?
I append a copy of the test program in case anyone wants to look at
it. The compiler and linker options are included in the comments.
(If you actually want to try yourself, plausible numerical values to
enter are 5. and 1.e4.)
Comments on the c coding style are probably wasted one me, but one obvious
clumsy point results from following the 3.4 recommendations about avoiding
scanf().
Pat Palmer (email: reply or ppalmer@oddjob.uchicago.edu)
----------------------------------
/* Manx5.0 version (declaration of atof() commented out, include <stdlib.h> */
/* compile: cc tau.c */
/* link: ln +q tau.o -lm -lc */
/* You seem to need all of these includes */
#include <stdio.h>
#include <math.h>
#include <stdlib.h>
main()
{
/* float atof(); */
float tau,nu,onu,te,g,em,tthree,nusq;
char inp_buf[10];
em=1.e7;
/* read in numbers */
printf("Input frequency(GHz) and T \n");
nu=atof(gets(inp_buf));
printf("%f \n",nu);
te=atof(gets(inp_buf));
printf("%f \n",te);
/* evaluate expression */
while (nu > 0.) {
g=log(4.95e-2*te*sqrt(te)/nu);
tthree=te*sqrt(te);
nusq=nu*nu;
tau=3.009e-2*em/tthree/nusq*g;
printf("tau= %e\n",tau);
onu=nu;
printf("Enter a new frequency (0 to quit, -1 to change Te) \n");
nu=atof(gets(inp_buf));
if(nu==-1.) {
printf("Input New T \n");
te=atof(gets(inp_buf));
nu=onu;
}
}
}martin@cbmvax.commodore.com (Martin Hunt) (03/25/90)
> I finally received my copy of Manx5.0, and I have been testing it out > by recompiling and rerunning some old programs. Results have been > worrisome. With one small program, I get the correct answer with > Manx3.4 (checked by hand and checked by compiling the same code on an > Elexsi and a Sun 3), but an answer that is precisely a factor of 100 > smaller with Manx5.0. How can this be??? I had not yet checked out floating point on Manx 5.0, so I compiled your program with it and with Lattice 5.05. Both compilers gave correct answers. > By the way, the code is almost exactly a factor of 2 larger with > Manx5.0; even though the version with 3.4 was compiled with +L option >and linked to -lm32 -lc32. (The Manx5.0 version is about 40% larger >than the Elexsi version.) What is happening here? Are we to conclude >that 5.0 gives larger code and wrong answers? By default, Manx 5.0 uses Manx IEEE format which includes support for long doubles. This porbably accounts for the size increase. Here are my results. Compiler Math library Executable size Manx IEEE 9492 Manx Manx IEEE 14068 Manx 68881 8712 Lattice IEEE 11256 Lattice 68881 12020 Lattice FFP 10236 Nothing unusual here. If you don't want large executables and you're only using floating point, don't use the Manx IEEE library. Sorry this wasn't much help. Are you sure you compiled and linked with the correct floating point options? Martin -- Martin Hunt martin@cbmvax.commodore.com Commodore-Amiga Engineering {uunet|pyramid|rutgers}!cbmvax!martin