Home > Archive > Fortran > November 2005 > LAPACK & Intel 9.0: unexpected behaviour (bug?)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
LAPACK & Intel 9.0: unexpected behaviour (bug?)
|
|
|
| Hi,
I am encountering the following behaviour with LAPACK 3.0 and the Intel
compiler v.9.0 (Build 20050430Z Package ID: l_fc_p_9.0.021):
I try to pass a 1-D slice of the array cf(n,3) to the tridiagonal
solver dptsv as follows:
call dptsv(n-2,1,AD,AE,cf(2:n-1,2),n-2,ierr)
dptsv overwrites cf on output with the solution vector; however, the
result is written to cf(1:n-2,2) rather than cf(2:n-1,2). Is this
expected or is this a bug?
Of course one can easily work around this, but my understanding is that
the result should be on cf(2:n-1,2). Any comments?
Tom
| |
| robert.corbett@sun.com 2005-11-19, 3:57 am |
| What is the value of n? Is it ever 2?
Bob Corbett
| |
| Victor Eijkhout 2005-11-21, 3:58 am |
| Tom <flurboglarf@mailinator.com> wrote:
> call dptsv(n-2,1,AD,AE,cf(2:n-1,2),n-2,ierr)
Are you using F90 syntax with an F77 library?
Shouldn't that just be .....cf(2,2)..... ?
Victor.
--
Victor Eijkhout -- eijkhout at tacc utexas edu
ph: 512 471 5809
| |
| Ron Shepard 2005-11-21, 3:58 am |
| In article <1h6cncg.1sjz0ndxih2yoN%see@sig.for.address>,
see@sig.for.address (Victor Eijkhout) wrote:
>
> Are you using F90 syntax with an F77 library?
>
> Shouldn't that just be .....cf(2,2)..... ?
I think this is supposed to work. It might involve copy-in/copy-out
in some cases (hopefully not this one), but I think the f90+
conventions were designed in such a way to support that kind of
backward compatibility (e.g. new code calling old libraries with
either implicit or explicit interfaces). Your suggested change,
cf(2,2), should work too.
$.02 -Ron Shepard
| |
|
| robert.corb...@sun.com wrote on Nov 19, 5:42 am:
> What is the value of n? Is it ever 2?
In the test case it was 11, so what you probably suspect, namely that
the upper bound is <= the lower, is not the problem here.
Tom
| |
|
| Victor Eijkhout wrote on Nov 21, 6:46 am show options
> Are you using F90 syntax with an F77 library?
Yes, but I thought that kind of backwards compatibility is allowed, and
Ron's remark in this thread seems to support that.
> Shouldn't that just be .....cf(2,2)..... ?
As one would normally pass the whole array if one has a dedicated array
for these diagonal elements, I thought it is better to specify the
slice with the correct bounds rather than just the first element of it.
However, your suggestion actually produces the right result, although I
don't understand why.
Tom
| |
| Tim Prince 2005-11-21, 7:01 pm |
| Ron Shepard wrote:
> In article <1h6cncg.1sjz0ndxih2yoN%see@sig.for.address>,
> see@sig.for.address (Victor Eijkhout) wrote:
>
>
>
>
> I think this is supposed to work. It might involve copy-in/copy-out
> in some cases (hopefully not this one), but I think the f90+
> conventions were designed in such a way to support that kind of
> backward compatibility (e.g. new code calling old libraries with
> either implicit or explicit interfaces). Your suggested change,
> cf(2,2), should work too.
Victor makes a good point. If the f90 array section is done without an
interface block for the called function, it should make a stride 1 copy,
so the stride passed in the argument would have to be adjusted
accordingly. An interface block would be have to be compatible with the
assumed size array, but I don't see that it could catch an error in the
stride.
| |
|
| Hi,
and sorry for the delay in reacting.
Victor Eijkhout wrote on Nov 21, 6:46 am:
> Are you using F90 syntax with an F77 library?
Yes - I thought that should work, or is there no such backwards
compatibility? I understand Ron's response in this thread that there
should be.
> Shouldn't that just be .....cf(2,2)..... ?
Well, I thought the proper way would be to pass the complete slice of
the array needed by the LAPACK routine instead of only the first
element; after all, you would normally also pass the entire array.
However, your suggestion actually produces the correct result, although
I don't quite understand why.
Thanks anyway,
Tom
| |
| Jan Vorbrüggen 2005-11-21, 7:01 pm |
| > As one would normally pass the whole array if one has a dedicated array
> for these diagonal elements, I thought it is better to specify the
> slice with the correct bounds rather than just the first element of it.
> However, your suggestion actually produces the right result, although I
> don't understand why.
IIRC, you specified a slice with a non-unit stride. If it does work with
the unit stride, perhaps one of the other arguments is the stride, and the
routine applies it internally? You should then be getting strange results
because you initial version accesses memory way outside the array....
Jan
| |
| Richard E Maine 2005-11-21, 7:01 pm |
| Tom <flurboglarf@mailinator.com> wrote:
> Hi,
> and sorry for the delay in reacting.
> Victor Eijkhout wrote on Nov 21, 6:46 am:
> Yes - I thought that should work, or is there no such backwards
> compatibility? I understand Ron's response in this thread that there
> should be.
There is compatibility.... but you have to use it correctly. If I
understand other posts correctly (I didn't check the details of the
routine in question), you told the subroutine to use every 2nd element
of an array... and then you passed it an array that was already thinned
by two. That ends up using every 4th element.
In any case, you can pass an f90-syntax slice to an f77-style
subroutine, but you do have to pass the correct slice. Slicing it both
in the call and in the subroutine is wrong.
> Well, I thought the proper way would be to pass the complete slice of
> the array needed by the LAPACK routine instead of only the first
> element;
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Victor Eijkhout 2005-11-21, 7:01 pm |
| Tom <flurboglarf@mailinator.com> wrote:
[color=darkred]
> However, your suggestion actually produces the correct result, although
> I don't quite understand why.
Passing a single element is the same as passing the address of that
element, so the receiving subroutine will think it got an array starting
at that point.
Victor.
--
Victor Eijkhout -- eijkhout at tacc utexas edu
ph: 512 471 5809
| |
|
| I get the impression that there is a misunderstanding in Richard's and
Jan's responses, so let me try to clarify: I have a two-dimensional
array (N x 3 elements), and what I pass to the routine is the 1-D slice
cf(2:n-1,2), that is for N=7 (X marks the elements I pass)
0 0 0
0 X 0
0 X 0
0 X 0
0 X 0
0 X 0
0 0 0
I don't see where a problem with the stride arises; BTW, the stride is
not passed as an argument in the call. The stride is 1, and the only
further information passed to the subroutine is the length of the
array, n-2. The earlier erroneous result was definitely the result of a
shift in the returned array by one, not the result of a stride other
than 1.
Tom
| |
| Richard E Maine 2005-11-21, 7:01 pm |
| Tom <flurboglarf@mailinator.com> wrote:
[elided]
> I don't see where a problem with the stride arises; BTW, the stride is
> not passed as an argument in the call. The stride is 1,
Ah. I see and agree.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
|
|
|
|
|