to any fortran developers: one thing that needs to be done
Eric Hilton Jones
multiprocessor digital alpha machine and (god forbid) bunches of new NT
machines because they consider linux to be just "too security prone."
I have some ancient code here for maximum entropy calculations which
compiles fine on the ibm and gives excellent results in quadruple
precision. However, the code blows up after a few iterations when compiled
with the DU compiler. Note that there are lots of matrix operations that
consist of "bigfrikkinnumber - really really small number", and error
accrues rather quickly at other precisions.
So, what needs to be done? _Please_ work on an aftermarket quadruple
precision compiler for the alpha.
Eric.
--
To unsubscribe: send e-mail to axp-list...@redhat.com with
'unsubscribe' as the subject. Do not send it to axp-...@redhat.com
Paul Tomblin
> Our school is migrating from an old risc 6000 ibm machine to a
> multiprocessor digital alpha machine and (god forbid) bunches of new NT
> machines because they consider linux to be just "too security prone."
You mean it's too prone to be secure and not have all the security holes that
are rampant in NT? Yes, I totally agree with that analysis, but I don't see
why they consider that a bad thing. Oh well, tell us the machine's name so we
can do a real time demonstration of the inadequacies of NT security.
--
Paul Tomblin, ptom...@xcski.com.
"An appointment is an engagement to see someone, while a morningstar is a
large lump of metal used for viciously crushing skulls. It is important not
to confuse the two, isn't it, Mr. --?" - Terry Pratchett
Wes Bauske
>
> Our school is migrating from an old risc 6000 ibm machine to a
> multiprocessor digital alpha machine and (god forbid) bunches of new NT
> machines because they consider linux to be just "too security prone."
> compiles fine on the ibm and gives excellent results in quadruple
> precision. However, the code blows up after a few iterations when compiled
> with the DU compiler. Note that there are lots of matrix operations that
> consist of "bigfrikkinnumber - really really small number", and error
> accrues rather quickly at other precisions.
> So, what needs to be done? _Please_ work on an aftermarket quadruple
> precision compiler for the alpha.
>
If you have the source, I found some long precision C
routines on netlib. Might be able to switch to those??
Check the archives from the past month or so.
One other thing. You probably know this but I usually
order my arithmetic to collect as many small exponent
numbers together as possible before adding/subtracting
it from a 'large' (exponent wise) number. Keeps an
algorithm more stable usually. Haven't had to use
larger than real*8 for stuff I work on but then
again, I'm working on signal processing in the
Seismic industry and only a few of the algorithms
have this problem. Course, this is also one of
the reasons you pay a vendor for their work.
I just scanned the DEC Visual FORTRAN info and
it appears there is no support for REAL*16.
The DEC UNIX FORTRAN compiler mentions support
for REAL*16. So, you might install DEC UNIX or
you may need to keep that old RS/6000 around
if you can't modify the code to work at REAL*8.
Just found a subroutine library for Visual FORTRAN
at:
http://www.ozemail.com.au/~milleraj/quad/quad_df.f90
It's F90 though, not F77.
Good luck.
Wes