Dear all,
Just for interest/since you provided me with excellent help the last time even if I only had a vague problem description:
Maxima, an open-source computer Algebra system comes with an optional lapack package that was generated from the original fortran source using a fortran-2-lisp utility.
The Lapack package runs fine on gcl, clisp, ccl, allegro cl and - if sbcl is given enough memory to be able to compile it - on sbcl, too.
On ECL it compiles just fine. But trying to actually use it results in
(ARRAY DOUBLE-FLOAT (*)) is not a valid type specifier.
Do you again have a magic idea on what we are doing wrong?
The sourcecode of our lapack implementation would be here: https://sourceforge.net/p/maxima/code/ci/master/tree/share/lapack/
...but it is quite a beast and - as it doesn't count as a "minimal example" I wouldn't expect you to look into it if the problem isn't clear from the error message.
My hope is that we somehow need to make an alias for some variable type and everything starts working.
Thanks in advance,
and kind regards,
Gunter.
Dear Gunter,
Looking into your problem, I found that this is most certainly an ECL bug, probably triggered by the definition of the MAXIMA package, which shadows the array symbol from the COMMON-LISP package. If you add an
(in-package #:common-lisp)
statement before the
(mk:oos "lapack-interface" :compile)
line in load-lapack.lisp everything works fine.
Best regards, Marius
Am 12.11.18 um 08:09 schrieb Gunter Königsmann:
Dear all,
Just for interest/since you provided me with excellent help the last time even if I only had a vague problem description:
Maxima, an open-source computer Algebra system comes with an optional lapack package that was generated from the original fortran source using a fortran-2-lisp utility.
The Lapack package runs fine on gcl, clisp, ccl, allegro cl and - if sbcl is given enough memory to be able to compile it - on sbcl, too.
On ECL it compiles just fine. But trying to actually use it results in
(ARRAY DOUBLE-FLOAT (*)) is not a valid type specifier.
Do you again have a magic idea on what we are doing wrong?
The sourcecode of our lapack implementation would be here: https://sourceforge.net/p/maxima/code/ci/master/tree/share/lapack/
...but it is quite a beast and - as it doesn't count as a "minimal example" I wouldn't expect you to look into it if the problem isn't clear from the error message.
My hope is that we somehow need to make an alias for some variable type and everything starts working.
Thanks in advance,
and kind regards,
Gunter.
Wow...
...that is exactly what I needed to know: Now it works fine - and odepack, too, which suffered from the same problem:
No unexpected errors found out of 4,016 tests. Evaluation took: 223.060 seconds of real time 221.782261 seconds of total run time (219.698866 user, 2.083395 system) [ Run times consist of 6.347 seconds GC time, and 215.436 seconds non-GC time. ] 99.43% CPU 310,065 forms interpreted 307,339 lambdas converted 533,987,307,561 processor cycles 68,844,353,376 bytes consed
Thanks a lot!
Gunter.
On 13.11.18 00:03, Marius Gerbershagen wrote:
Dear Gunter,
Looking into your problem, I found that this is most certainly an ECL bug, probably triggered by the definition of the MAXIMA package, which shadows the array symbol from the COMMON-LISP package. If you add an
(in-package #:common-lisp)
statement before the
(mk:oos "lapack-interface" :compile)
line in load-lapack.lisp everything works fine.
Best regards, Marius
Am 12.11.18 um 08:09 schrieb Gunter Königsmann:
Dear all,
Just for interest/since you provided me with excellent help the last time even if I only had a vague problem description:
Maxima, an open-source computer Algebra system comes with an optional lapack package that was generated from the original fortran source using a fortran-2-lisp utility.
The Lapack package runs fine on gcl, clisp, ccl, allegro cl and - if sbcl is given enough memory to be able to compile it - on sbcl, too.
On ECL it compiles just fine. But trying to actually use it results in
(ARRAY DOUBLE-FLOAT (*)) is not a valid type specifier.
Do you again have a magic idea on what we are doing wrong?
The sourcecode of our lapack implementation would be here: https://sourceforge.net/p/maxima/code/ci/master/tree/share/lapack/
...but it is quite a beast and - as it doesn't count as a "minimal example" I wouldn't expect you to look into it if the problem isn't clear from the error message.
My hope is that we somehow need to make an alias for some variable type and everything starts working.
Thanks in advance,
and kind regards,
Gunter.
-
Gunter Königsmann -
Marius Gerbershagen