Re: BLAS: dgemm

Bart Vandewoestyne <MyFirstName.MyLastName@xxxxxxxxxx> wrote:

So my problem is solved, but I have one more question: before my
experiment, i thought that when single precision data was passed
to a procedure requiring double precision data, the results would
be 'single precision correct' instead of 'double precision correct'.

For the most part, you just thought wrong. With separate compileation,
which is typical of f77-style implicit interfaces, and which is what you
are using, the compiler doesn't even know that the procedure requires
double precision. The procedure might not have even been written yet
when the main program is compiled. Where is the compiler supposed to get
this information that doesn't yet even exist? When using implicit
interfaces, it is very, very important to understand that the compiler
in general knows nothing about the procedure other than what it can
deduce from looking at the call. If the call has single precision actual
arguments, then the deduction is that the procedure expects single
precision actual arguments. If that deduction is incorrect, you will get
garbage answers.

With modules, the USE provides information about the procedure, allowing
the compiler to check that it is being called correctly. Thus you will
get error messages. There still won't be automatic conversion. that
would break more things than I care to discuss; I'll just leave it at
"won't happen". Sometimes compilers will similarly check implicit
interfaces when the information happens to be available, such as when
the procedure called is in the same file. This seems more common in
recent compilers, but you can't count on it, and there are plenty of
cases where the information isn't available anyway. This is still just a
check - not a correction.

I have worked on a system where passing double actuals to single dummies
would (sort of) work in some cases. I even worked with code where people
took advantage of this and mistakenly thought that the compiler was
doing something special and "smart" about it. Instead, the compiler
didn't even notice and the bit patterns happened to work. That relies on
properties of the bit patterns for single and double - properties that
are quite rare in today's machines. You aren't on one of the rare
machines that has the properties needed. If I recall correctly, the code
in question was on a Gould/SEL, which did have those properties. the
practice caused problems when the code was ported elsewhere.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • Re: Constant expressions and mathematical functions
    ... Fortran standard that guarantees that. ... But I would be very unhappy with a Fortran compiler that made ... single precision, but that in higher precisions some of those using ...
    (comp.lang.fortran)
  • Re: BLAS: dgemm
    ... single precision data - both the arrays and the literal constants. ... (In some computers at one time the longer form was for bankers and such ... The compiler is helping you be self consistent. ...
    (comp.lang.fortran)
  • Re: Precision of literal real constants, parameters, and Fortran ??standard
    ... variables a compiler was allowed to supply extra precision ... for what looked like single precision constants. ... double precision constant and, effectively, use all the digits ...
    (comp.lang.fortran)
  • Re: Need Help with Precision!!
    ... Fortran 90 provides more control and flexibility in such matters. ... Double precision ought to be adequate for values of that magnitude on ... and *EXACTLY* what does the compiler say about it. ... still single precision. ...
    (comp.lang.fortran)
  • Re: converting float to double
    ... compiler is broken, and I wouldn't go anywhere near it. ... to single precision, the multiplication by 1000.0 and division by ... are one hundred percent required to be done in double precision, ... and turn "strict floating point arithmetic" ...
    (comp.lang.c)