Doug Kelly <KELLYDK@QUCDN.QueensU.CA> (08/21/90)
I'm porting some numerical code from a PC to an IBM RS/6000 and, since I hate telnet, I 'ANSI'd' the program on my Amiga, and then recompiled it on the 6000. Here's the problem - the Amiga version gives the wrong results!! The program compiles fine, runs to completion with no errors, but the results are wrong. THE SAME CODE runs on both the pc (Turbo) and the 6000. I'm using Lattice 5.02 (I know it's old). I've tried all three math formats - ffp, ieee and inline 881 and none of them come out right. My first instinct wat to run it through CPR, but CPR doesn't seem to like the command line and the program doesn't get the proper file arguements, and so won't run. I don't have time to thoroughly trace without a debugger, so I'm asking for tips. If anyone knows what may be causing this, please send me email. thanx in advance (benchmarks? 17 hours on an 8Mhz XT; about 25 min on my A1000/Lucas 1.25 minutes on the 6000)
baker@wbc.enet.dec.com (08/22/90)
>Many of the examples from Numerical recipies don't work either. >The explanation I got for it is that a lot of numerical work in C >makes undue assumptions about the treatment of floats and doubles >in functions. You could try #define double float to get a rough idea >of what's going on. I gave up and hand coded. I've done a number of serious numerical projects on the Amiga (some orbital mechanics stuff for modeling planetary motion, an ODE solver, finite element stuff for PDE's, etc) using the FFP, IEEE double precision, and the '882 IEEE libraries. My results were rock-solid when compared against the same code on other machines (VAXen). I'm running Lattice 5.04. It's true that the C version of Numerical Recipes has some funny code in it; best to develop an understanding of the specific algorithm, then make sure their code is doing what it says it is... Regards, Art Baker | "Whatever happened to Fay Wrey -- (usual disclaimers) | that delicate, satin-draped frame..." =========================================================================
BAXTER_A@wehi.dn.mu.oz (08/22/90)
> > My first instinct wat to run it through CPR, but CPR doesn't seem > to like the command line and the program doesn't get the proper > file arguements, and so won't run. I don't have time to thoroughly > trace without a debugger, so I'm asking for tips. > If anyone knows what may be causing this, please send me email. Many of the examples from Numerical recipies don't work either. The explanation I got for it is that a lot of numerical work in C makes undue assumptions about the treatment of floats and doubles in functions. You could try #define double float to get a rough idea of what's going on. I gave up and hand coded. Regards Alan
mwm@raven.pa.dec.com (Mike (Real Amigas have keyboard garages) Meyer) (08/22/90)
In article <11700@wehi.dn.mu.oz> BAXTER_A@wehi.dn.mu.oz writes:
Many of the examples from Numerical recipies don't work either.
The explanation I got for it is that a lot of numerical work in C
makes undue assumptions about the treatment of floats and doubles
in functions. You could try #define double float to get a rough idea
of what's going on. I gave up and hand coded.
You can thank ANSI for this. K&R specified that all floating point
arithmetic was done using doubles. ANSI changed that to allow the
compiler to use the longest precision in the expression. Most
compilers have a switch to force the old behavior, Lattice being among
them - for some of it's math modes.
<mike
--
So this is where the future lies Mike Meyer
In a beer gut belly; In an open fly mwm@relay.pa.dec.com
Brilcreamed, acrylic, mindless boys decwrl!mwm
Punching, kicking, making noiseBAXTER_A@wehi.dn.mu.oz (08/23/90)
In article <3249@decuac.DEC.COM>, baker@wbc.enet.dec.com writes: >>Many of the examples from Numerical recipies don't work either. >>The explanation I got for it is that a lot of numerical work in C >>makes undue assumptions about the treatment of floats and doubles >>in functions. You could try #define double float to get a rough idea >>of what's going on. I gave up and hand coded. > > I've done a number of serious numerical projects on the Amiga > (some orbital mechanics stuff for modeling planetary motion, an > ODE solver, finite element stuff for PDE's, etc) using the FFP, > IEEE double precision, and the '882 IEEE libraries. My results > were rock-solid when compared against the same code on other > machines (VAXen). > > I'm running Lattice 5.04. > > It's true that the C version of Numerical Recipes has some funny > code in it; best to develop an understanding of the specific algorithm, > then make sure their code is doing what it says it is... > > Regards, > Art Baker | "Whatever happened to Fay Wrey -- > (usual disclaimers) | that delicate, satin-draped frame..." > ========================================================================= I didn't mean to imply that there was anything wrong with the amiga compilers, just that there was something wrong in assuming they do the same things with storage of variables as msdos compilers. And I'm not to sure that that's what the problem is! Regards Alan
dillon@overload.Berkeley.CA.US (Matthew Dillon) (08/24/90)
In article <90233.133801KELLYDK@QUCDN.BITNET> KELLYDK@QUCDN.QueensU.CA (Doug Kelly) writes: > >I'm porting some numerical code from a PC to an IBM RS/6000 and, >since I hate telnet, I 'ANSI'd' the program on my Amiga, and then >recompiled it on the 6000. Here's the problem - the Amiga version >gives the wrong results!! The program compiles fine, runs to >completion with no errors, but the results are wrong. THE SAME CODE >runs on both the pc (Turbo) and the 6000. >I'm using Lattice 5.02 (I know it's old). I've tried all three >math formats - ffp, ieee and inline 881 and none of them come out right. Use the strict prototype checking option under Lattice. These kinds of problems are usually related to forgetting to prototype *every* instance of the function and/or forgetting to prototype the function itself. Unprototyped functions/calls that take floats actually take doubles. prototyped functions/calls take the appropriate type, float or double. It depends on the compiler, perhaps the PC's do not implement this aspect of prototyping completely (which isn't wrong, just not efficient). -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
jcs@crash.cts.com (John Schultz) (08/25/90)
In article <3249@decuac.DEC.COM> baker@wbc.enet.dec.com writes: > (Stuff about Lattice 5.02 math not working properly deleted) 5.02 had some major bugs with floating point (FPU), where registers were loaded wrong, etc. From 5.04 and on, these bugs seem to have been fixed. Upgrade to 5.10 and you should have no more problems... John
walker@unx.sas.com (Doug Walker) (08/28/90)
In article <90233.133801KELLYDK@QUCDN.BITNET> KELLYDK@QUCDN.QueensU.CA (Doug Kelly) writes: > >I'm porting some numerical code from a PC to an IBM RS/6000 and, >since I hate telnet, I 'ANSI'd' the program on my Amiga, and then >recompiled it on the 6000. Here's the problem - the Amiga version >gives the wrong results!! The program compiles fine, runs to >completion with no errors, but the results are wrong. THE SAME CODE >runs on both the pc (Turbo) and the 6000. >I'm using Lattice 5.02 (I know it's old). I've tried all three >math formats - ffp, ieee and inline 881 and none of them come out right. 5.02 had some bugs related to pushing and popping floats. If your functions have float parameters, you might want to call SAS Institute and ask for the (free) 5.05 upgrade. Or you could just go ahead and get the (not free) 5.10 upgrade for $40. If you want to try to fix it with 5.02, make sure you have a prototype in scope for all functions, both when you call them and when they are defined; and use new-style ANSI function definitions instead of old-style definitions. If you are 100% ANSI, the bug does not show up. ***** =*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 = *|. o.| || | o |// For all you do, this bug's for you! ====== usenet: ...mcnc!rti!sas!walker plink: dwalker bix: djwalker
Doug Kelly <KELLYDK@QUCDN.QueensU.CA> (08/28/90)
Thanx for all the replies. I managed to get the problems with IEEE libraries to go away and they now work. The inline 881 code, however, does not. This appears to be a bug with 5.02, so (thanks to SAS customer support) the 5.10 upgrade is on the way. So, if anyone really cares how well a 24MHz 881 compares to an IBM PowerStation320, let me know :-) Doug Kelly kellydk@qucdn.queensu.ca ewsg