I didn't know that.

This saves me a lot of work, as I see that most of the routines I 
actually need are there.

This should be added to the feature request:
https://sourceforge.net/tracker/index.php?func=detail&aid=2774886&group_id=612&atid=350612

I've run a short test, and was surprised to get a 4x4 matrix back from 
the msvd routine. I was expecting to have a 3x4 returned.

Do you know what is going on there ?

#short test
my $m=4;
my $n=3;
my $A = PDL->zeroes(double ,$n,$m);
$A .= ($A->yvals*$n)+($A->xvals+1);
$qmAt= pdl [
    [ 1,        2       ,3 ],   
    [ 4,        5       ,6      ],
    [ 7,        8       ,9      ],
    [ 10,       11,     12      ]];
print "$A <> $qmAt\n" if ! all approx $qmAt, $A;
  ($U, $S, $VT) = msvd($A);

$qmSt= pdl [    25.4624,        1.29066 ,2.21303e-15] ;
$qmVTt= pdl [
[    -0.140877, 0.824714,       0.540521        ],
[    -0.343946, 0.426264,       -0.654711       ],
[    -0.547016, 0.0278135,      -0.312142       ],
[    -0.750086, -0.370637,      0.426331        ] ] ;
$qmUt= pdl [
    [ -0.504533,        -0.574516       ,-0.644498]     ,
    [ -0.760776,        -0.0571405,     0.646495]       ,
    [ -0.408248,        0.816497        ,-0.4082481] ];

-------------

I've now more or less figured out how to do parse all .f files 
automatically. I was now starting the hard phase: figuring out how 
swapping arguments for arrays should be done.
PDL and FORTRAN use opposite ways to store the data: in PDL, the FIRST 
dimension is contiguous in memory, while  in FORTRAN, the LAST dimension 
steps by 1 through memory.

I see that I can now stop that effort

Is there somebody I can make happy with the parsing code ?
I'll feed some improvements I found for the lapack .f files back to the 
lapack development.

Gregory Vanuxem wrote:
> Hello Jan, hello all
> 
> Have you seen that :
> 
> http://search.cpan.org/~ellipse/PDL-LinearAlgebra-0.06
> 
> 
> This modules was built incrementally (implemented when needed and when
> time was available) but of course a better way is to do it automatically
> (I did it later in lisp). Beside the lot of disadvantage a manual way
> is, it's relatively well checked, practically checked to be more
> precise . Each routine was tested, but some bugs remains for sure. The
> x.t check for the « educational » LinearAlgebra.pm module is on my hard
> drive, if you want it drop me a mail.
> 
> Cheers,
> 
> Greg
> 
> 
> Le dimanche 31 mai 2009 à 23:30 +0200, Jan Hoogenraad a écrit :
>> Please help me with starting an interface to lapack.
>> Chris Marshall (marshallch) requested that I'll put my progress and 
>> questions onto this list.
>>
>> I've come as far as installing PDL and starting to use inlpp_link.pl as a 
>> template.
>>
>> I set up attached .pl file. This does not compile, as line 64 does not parse.
>> I've attached out.pdlpp, as this contains the error code: 
>>      Invalid pdl def int n (regex 
>> byte|short|ushort|int|longlong|float|double)  at (eval 16) line 7
>>      PDL::PP::PdlParObj::new('PDL::PP::PdlParObj', 'int n', 
>> 'PDL_UNDEF_NUMBER', 0) called at (eval 13) line 7
>>
>> I've tried to match what was done at Slatec, but there a different parser is 
>> included.
>>
>> The header for the specific function I am trying to call is:
>> extern void dgesv_(int *n, int *nrhs, double *a, int *lda,  int *ipiv, 
>> double *b, int *ldb, int *info);
>>
>>
>>
>> pièce jointe document texte brut (out.pdlpp)
>> Invalid pdl def int n (regex byte|short|ushort|int|longlong|float|double)
>>  at (eval 16) line 7
>>      PDL::PP::PdlParObj::new('PDL::PP::PdlParObj', 'int n', 
>> 'PDL_UNDEF_NUMBER', 0) called at (eval 13) line 7
>>      PDL::PP::Signature::parse('int n;int nrhs;double [o]a(lda,n);int 
>> lda;int [o]ipiv(n); dou...', 0) called at 
>> /home/jhh/linsrc/PDL/blib/lib/PDL/PP/Signature.pm line 31
>>      PDL::PP::Signature::new('PDL::PP::Signature', 'int n;int nrhs;double 
>> [o]a(lda,n);int lda;int [o]ipiv(n); dou...', undef) called at 
>> /home/jhh/linsrc/PDL/blib/lib/PDL/PP.pm line 1355
>>      PDL::PP::Pars_nft('int n;int nrhs;double [o]a(lda,n);int lda;int 
>> [o]ipiv(n); dou...', undef) called at 
>> /home/jhh/linsrc/PDL/blib/lib/PDL/PP.pm line 324
>>      PDL::PP::Rule::apply('PDL::PP::Rule=HASH(0x8d73a50)', 
>> 'HASH(0x8b56b20)') called at /home/jhh/linsrc/PDL/blib/lib/PDL/PP.pm line 
>> 3236
>>      PDL::PP::translate('HASH(0x8b56b20)', 'ARRAY(0x8d83a28)') called at 
>> /home/jhh/linsrc/PDL/blib/lib/PDL/PP.pm line 1038
>>      PDL::PP::pp_def('dgsev', 'Pars', 'int n;int nrhs;double [o]a(lda,n);int 
>> lda;int [o]ipiv(n); dou...', 'GenericTypes', 'ARRAY(0x8ab2880)', 'Code', 
>> 'dgesv_($P(n), $P(nrhs), $P(a), $P(lda), $P(ipiv), $P(b), $P(l...') called 
>> at lapack_link_pl_c24d.pd line 17
>> Inline running PDL::PP version 2.2...
>> _______________________________________________
>> Perldl mailing list
>> [email protected]
>> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
> 
> 



_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl

Reply via email to