Re: porting arapck code to octave

[Jaroslav Hajek]

On Sat, Dec 20, 2008 at 5:23 PM, David Bateman <address@hidden> wrote:
> Jaroslav Hajek wrote:
>>
>> 1. rather than your MY_LOCAL_BUFFER, you can use the pre-defined
>> OCTAVE_LOCAL_BUFFER_INIT.
>>
>> 2. the following snippet:
>>                  for (octave_idx_type i = 0; i < n; i++)
>>                    workd[i+ipntr[1]-1] = static_cast<double>(i) *
>> workd[i+ipntr[0]-1];
>> is obviously not multiplying by diag(1:100), but by diag(0:99).
>>
>> 3.
>>              retval(1) = eig_val;
>>              retval(2) = eig_vec;
>>
>> should read
>>
>>              retval(0) = eig_val;
>>              retval(1) = eig_vec;
>>
>> after correcting these problems, I get the correct answer:
>> ans =
>>
>>    97.000
>>    98.000
>>    99.000
>>   100.000
>>
>> regards
>>
>>
>>
>
> Unfortunately, that doesn't work for me as it never gets to point 3) and in
> any case point 2) would just mean the eigenvalues that are found should be
> [99, 98, 97, 96]... The code has an internal error in the arpack function
> dsaupd (error number -9999).. However, as it seems to work for you the
> question is why it works for you and not me...
>
> Basically, I can only see compiler/linker issues as a reason at the moment..
> I compiled with gfortran version 4.3.2 and the flags
>
> FFLAGS  = -O2 -fPIC
>
> and linked dssimp.oct against the shared version of the library. What did
> you do differently?
>

I used Intel Fortran with -O -fPIC, and I only built a static library
(where did you get export symbols table? or did you export
everything?), though I was not sure whether the linking will work
correctly (note that ARPACK should be linked to LAPACK v2 routines).
I can try with gfortran, but no sooner than after new year's eve.
In any case, if we include ARPACK, my suggestion is to work on things
a bit to investigate and remove the dependency on LAPACK v2, because
it is, IMHO, almost bound to cause trouble if ARPACK is included
within libcruft. Of course I'm up for the job, otherwise such a
suggestion would be pretty moot.
I'm not sure whether ARPACK is maintained anymore (yes, I know there
has been a license change recently, but maybe it was just because the
authors have no plans for further development).

Why it doesn't work for you is a good question. Maybe there's a buffer
overrun that in my case doesn't do any damage by chance? (Just a wild
guess).

regards

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz