BLAS: dgemm
in [Fortran]
|
Prev: SLATEC
Next: pictures as comments
From: Bart Vandewoestyne on 13 Feb 2007 08:34 On 2007-02-12, Thomas Koenig <Thomas.Koenig(a)online.de> wrote: > > You could also use gfortran, use matmul and specify the > -fexternal-blas option :-) Thanks for this tip! Very interesting option to let my students play with :-) Regards, Bart -- "Share what you know. Learn what you don't."
From: Bart Vandewoestyne on 13 Feb 2007 08:43 On 2007-02-12, Richard Maine <nospam(a)see.signature> wrote: > > Is not the "d" in dgemm for double precision? You are calling it with > single precision data - both the arrays and the literal constants. > > [...] > > That sounds very typical of getting the precision of real arguments > wrong. OK. A good night's rest did a wonderfull job with me :-) The problem was indeed that I was passing single precision data to dgemm which requires double precision data. I have made a small testprogram to see if it was that what was causing me trouble: http://www.cs.kuleuven.be/~bartv/stuff/example_blas.f95 Using the 'dp' all is OK, but using the 'sp' kind i get faulty results. 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'. I have made a little test-program again: http://www.cs.kuleuven.be/~bartv/stuff/example_sp_for_dp.f95 And now I experienced with my own eyes that when single precision data is passed to a procedure requiring double precision data, the program won't even compile! Can somebody explain to me why it is necessary that the program doesn't compile? Intuitively, i had thought that my program would compile if i pass sp-arguments to f(x), and I expected that the result of f(x) in my program would have been 'single precision correct', but apparently this is not the case. Why is this so? What is the danger of passing sp instead of dp arguments? Thanks for explaining, Bart -- "Share what you know. Learn what you don't."
From: Herman D. Knoble on 13 Feb 2007 09:21 Lahey LF95 output results: f(3.0_dp) gives 11.00000000000000 Skip Knoble On Tue, 13 Feb 2007 13:43:53 GMT, Bart Vandewoestyne <MyFirstName.MyLastName(a)telenet.be> wrote: -|I have made a little test-program again: -| -|http://www.cs.kuleuven.be/~bartv/stuff/example_sp_for_dp.f95 -| -|And now I experienced with my own eyes that when single precision -|data is passed to a procedure requiring double precision data, -|the program won't even compile! -| -|Can somebody explain to me why it is necessary that the program -|doesn't compile? Intuitively, i had thought that my program -|would compile if i pass sp-arguments to f(x), and I expected -|that the result of f(x) in my program would have been 'single -|precision correct', but apparently this is not the case. Why is -|this so? What is the danger of passing sp instead of dp -|arguments? -| -|Thanks for explaining, -|Bart
From: Gordon Sande on 13 Feb 2007 09:32 On 2007-02-13 09:43:53 -0400, Bart Vandewoestyne <MyFirstName.MyLastName(a)telenet.be> said: > On 2007-02-12, Richard Maine <nospam(a)see.signature> wrote: >> >> Is not the "d" in dgemm for double precision? You are calling it with >> single precision data - both the arrays and the literal constants. >> >> [...] >> >> That sounds very typical of getting the precision of real arguments >> wrong. > > OK. A good night's rest did a wonderfull job with me :-) > > The problem was indeed that I was passing single precision data > to dgemm which requires double precision data. > > I have made a small testprogram to see if it was that what was > causing me trouble: > > http://www.cs.kuleuven.be/~bartv/stuff/example_blas.f95 > > Using the 'dp' all is OK, but using the 'sp' kind i get faulty > results. > > > 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'. To the electronics of the computer there is no connection between the (typically) four byte data that YOU call a real and the (typically) eight byte date that YOU call double precision. There are some computers in which the first four of the eight bytes of the double precision are a real but not all do this. Of course there are conversion instructions. (In some computers at one time the longer form was for bankers and such so was in a decimal format so they were really different. Not common anymore but it might come back!) You managed to not tell the computer (by separate compilation) that you were associating some real data with some double precision data. So by this cheat you asked the electonics to do its four byte operation on the eight byte data. And even more alarming the recipe for finding the next four byte chunk of data will not match the rule for the eight byte data. If you then used modules (of some other F90 safety feature) the compiler would not help you in your effort to supply "wrong" data to the electronics. The compiler is helping you be self consistent. At a logical level there is no connection between a character string of all digits and an integer even if both contain the same information for the purposes of the programmer. Same notion as above but more readily grasped by some. Something with common sense, like a graduate student, will recognize the difference between 1.2 and 1.23456789 and (on occasion) act suitably. But that is a big stretch for the electronics. Fancy programming might hide this is some circumstances. The great joy of a computer is that it enables you to make mistakes at a GigaHertz rate if you care to to! Computers have no common sense. > I have made a little test-program again: > > http://www.cs.kuleuven.be/~bartv/stuff/example_sp_for_dp.f95 > > And now I experienced with my own eyes that when single precision > data is passed to a procedure requiring double precision data, > the program won't even compile! > > Can somebody explain to me why it is necessary that the program > doesn't compile? Intuitively, i had thought that my program > would compile if i pass sp-arguments to f(x), and I expected > that the result of f(x) in my program would have been 'single > precision correct', but apparently this is not the case. Why is > this so? What is the danger of passing sp instead of dp > arguments? See above for rude remarks about dumb computers. They expect you to be correct and self consistent. Be glad when the compiler catches you failures. Back when the "Computing Section" was a room full of (mostly) ladies with mechanical calculators this might have been a reasonable hope. But there has been "progress" since then. > Thanks for explaining, > Bart
From: Walter Spector on 13 Feb 2007 10:08
Bart Vandewoestyne wrote: > ... Intuitively, i had thought that my program > would compile if i pass sp-arguments to f(x), and I expected > that the result of f(x) in my program would have been 'single > precision correct', but apparently this is not the case. Why is > this so? Because Fortran is not C. Actual args do not get 'coerced' to some default size. What you pass is what the callee gets. > What is the danger of passing sp instead of dp > arguments? Bad answers. (As you've discovered.) The caller and callee must match. But since you were relying on pre-F90 style 'implicit interfacing', your compiler could not tell you in advance that there was a problem. Depending on whose BLAS you were using, there may be a module that you can USE with interface blocks for the calls. This would allow the compiler to check the call at compile time. W. |