Bug with g77 and -mieee on Alpha Linux

[Martin Kahlert]

Quoting Toon Moene (toon@moene.indiv.nluug.nl):
> craig@jcb-sc.com wrote:
> 
> > >> Perhaps, but, as I pointed out earlier, almost *any* program can generate
> > >> denormals if it is compiled to randomly spill 80-bit values as 32-bit
> > >> or 64-bit values and tries to compare them to (nearly) identically
> > >> computed results to see if they're approximately equal.
> 
> > >I'm pretty sure that ours don't - in spite of the fact that they perform
> > >somewhere between 10^10 and 10^11 floating point operations per run.
> 
> > But *yours* isn't the only code on the planet, correct?
> 
> No, but our code runs 7 x 24 hours in 7 operational meteorological sites
> in Europe - if I knew how, I would immediately enable
> "trap-on-denormals", like we would run with -fbounds-check [too large a
> performance dip for operational use] on, because it would point us at
> problems in our algorithms.
Please correct my if i am wrong, but meteorological simulation
usually deals with elliptic partial differential equations in each time
step (i don't think you have shocks). Since there is the maximum principle,
i assume, you can theoretically prove that all of your floating point values
are within good boundaries.

Electrical circuit simulation is by a big amount more nasty thing than this!
Each transistor has about 3 operation modes: One, where it doesn't do a lot,
since the voltages are a bit too low, one rather linear part in the voltage-
current graph (where amplification happens) and a saturation part.
This graph has rather sharp edges and you don't know anything about, where
the designer wants the transistor to work - and this has not neccessarily
anything to do with where they actually work ;-).
This might be rather simple to solve in the case of toy problems with less then 100
transistors, but our simulation tool is inteded more in the range between
10000 and 100000 of them. Unfortunatly transient time simulation is the simpler
part. A great deal of effort (and computation time)
is put into finding an initial consistent solution.

> 
> > I mean, c'mon, you *constantly* write about how people *shouldn't* (or
> > "don't", despite substantial evidence on these lists to the contrary)
> > write floating-point code, as if it applied to the entire planet's
> > past, present, *and* future use of Fortran.
> 
> The evidence on these lists prove that people are still forced to write
> programs without getting a decent course in numerical analysis.
> 
> Why do you think I quote "Numerical Recipes" ?  This stuff is so well
> known that it is equivalent to pointing out an error in gcc wrt to the
> Dragon Book.
> 
> Why do you think I put a $200 / hour premium on this ?  If people are
> forced to deal with badly written software in such large IT firms like
> Siemens, they'd better be prepared to pay up, or shut up.

Do you really think, that at Siemens people with no numerical skills
are allowed to spend their time writing analog circuit simulators?
This (inhouse) simulation tool has been developed during 10 years, where an average
of 5 people (all numerical focused mathematicians) tried to improve the solver
for a large (>100000) set of highly nonlinear equations (among other tasks of course).

While in meteorological simulations the linear sets of equations are so well
behaved, that usually iterative solvers converge, i don't know of any successful
use of an iterative linear solver in analog circuit simulation.
Thus i think, that analog cicuit simulation belongs to the most nasty parts of numerics
in DAEs.


I think, you didn't read Num. Rec. exactly: Can you tell me any globally convergent
method for nonlinear methods, which can be coded to not produce FPEs?
The rather trivial improvements of newton's method in NR, all suggest to calculate
F(x_new) first (to ensure quadratical convergence near the solution).
But this is not possible, if x_new has bad values inside it. Even something
like if(x_new(i) .GT. 1D10) can throw an exception! The only thing you can 
savely do with these values is to not use them.

Bye,
Martin.

-- 
esa$ gcc -Wall -o ariane5 ariane5.c
ariane5.c: 666: warning: long float implicitly truncated to unsigned type
esa$ ariane5