[ANN] Smallapack for Dolphin - first port

Smallapack is the Smalltalk interface to LAPACK, the famous linear
algebra library (Matrix).

I have developped on VW, ported to Squeak (not fully working yet) and
also tried Dolphin (5.1 and 6).

More information at: <a
href="http://ncellier.ifrance.com/Smallapack/">http://ncellier.ifrance.com/Smallapack/</a>

I've also created my version of linear algebra objects & probability
related objects.
I like it because it is always Refactoring opened, and easy to
understand.

Hello Howard
Thank for your interest.
Your feedback raise these questions:
- did your implementation rely on an external library or is it 100%
pure Smalltalk juice?
- did you publish something public?
Refactoring is of course opened in Smallapack at least for these
reasons:
- it is too big
- it could be faster (use proxy instead of evaluation untill operations
better match BLAS primitive)
- cross dialects compatibility could be better handled
If you have further comments, suggestions or ideas to share/exchange,
welcome

Nicolas

Howard Oh a écrit :
> I've also created my version of linear algebra objects & probability
> related objects.
> I like it because it is always Refactoring opened, and easy to
> understand.

nicolas cellier,

> Your feedback raise these questions:
> - did your implementation rely on an external library or is it 100%
> pure Smalltalk juice?

Yes, It is written all in pure Smalltalk. It is because it is easy to
extend all combinations of mathematical objects like:

- Matrix of Fractions
- Matrix of Reals and Complex Numbers
- Polynomial of Complex coefficients
- Vector of Polynomials
- Vector of Complex number



> - did you publish something public?

No, I have not.


> Refactoring is of course opened in Smallapack at least for these
> reasons:
> - it is too big
> - it could be faster (use proxy instead of evaluation untill operations
> better match BLAS primitive)
> - cross dialects compatibility could be better handled
> If you have further comments, suggestions or ideas to share/exchange,
> welcome

One thing more for the list:  - It is not accurate enough.

I once used Dhb package for solving n-th order polynomial which gave me
answers of wide errors to the true solution.
I designed my version which is accurate and capable of giving roots of
real or complex numbers.

> Nicolas
>
> Howard Oh a écrit :
> > I've also created my version of linear algebra objects & probability
> > related objects.
> > I like it because it is always Refactoring opened, and easy to
> > understand.

Howard Oh a écrit :

Interesting. I also had the same with Matrix of SymbolicExpression like
a*b+1, (a multivariate polynomial over integers in this example, but
not only polynomials, lot of other expressions).

>
> > - did you publish something public?
>
> No, I have not.
>

Will you ?

I see... But we should all know that past a certain degree, a single
bit in a coefficient can move computed roots by a huge amount, even
with your carefully crafted code... And don't we look for an extended
precision: the accuracy required on polynomial coeffs is exponential
wrt polynomial degree (with quadruple precision, you would go maybe 3
or four degrees further), unless your polynomial have some specific
properties (like all roots having norm < 1).

Note that routine CPEVL from SLATEC also provide you some error bounds
on computed polynomial roots (complex case). This is really something
you should inquire (usefull like a bell ringing: hey, the problem is
ill posed).

In term of numerical accuracy, LAPACK algorithms are quite robust. They
control accuracy at least to avoid overflow/underflow, and some
routines can also provide you error bounds.

LAPACK is the state of the art used in the kernel of Matlab, Octave,
Scilab, R-Lab and in a lot of serious work...
That's not a proof but a clue about its quality.

Goldies FORTRAN... We should better not forget all this knowledge base
from elder...

Nicolas

Nicolas,

Nice to meet a math-guy in Smalltalk community. ^^  I may not be so
well trained math man, but I have a lot of interest in implementing
them in Smalltalk.

> Interesting. I also had the same with Matrix of SymbolicExpression like
> a*b+1, (a multivariate polynomial over integers in this example, but
> not only polynomials, lot of other expressions).

Very interesting! I have ArithmeticExpression objects that forms parse
tree like reference tree. That can evaluate or derivate.

> >
> > > - did you publish something public?
> >
> > No, I have not.
> >
>
> Will you ?

I'm not sure. To me publishing is seems challenging. Many things to
consider...
Not that I'm telling I've never thought of publishing but all the
responsibilities that I have to take by doing it.
I love to refactor things severly. But If I know someone is using it, I
cannot be free to change them as I did before.
Maybe this falls into a category "Refactoring against Open source
Project".
Sorry to say about LAPACK while I do not know it so well, but it seems
quite traditional which means it won't change so radically than other
untraditional ones.
Could you tell your Smallapack publishing stories that might help me
out?


I can see how famous & mature LAPACK is, but not quite sure if they are
designed in OO. I've started my math objects from the pure math books,
defining and creating classes and methods as the math book defines,
rather than algorithm reference book like "RECIPIES IN C" which is
procedural language oriented.

I found math and Smalltalk beautiful, because they are so flexible and
so capabe of intermixing objects.

        -1 sqrt    "Complex(0,1)"

        (Matrix ofColumnSize: 2 data: #(0 -1 1 0)) eigenValues "Complex(0,1)
and Complex(0,-1)"

        (Polynomial coeffient: #(1 0 1)) roots  "Compex(0,1) and
Complex(0,-1)"


Best Regards,
Howard

Hello

Howard Oh a écrit :
> Nicolas,
>
> Nice to meet a math-guy in Smalltalk community. ^^  I may not be so
> well trained math man, but I have a lot of interest in implementing
> them in Smalltalk.
>

Neither am i that trained, I know only of a few problems i encountered
in my engineer's job.

> > Interesting. I also had the same with Matrix of SymbolicExpression like
> > a*b+1, (a multivariate polynomial over integers in this example, but
> > not only polynomials, lot of other expressions).
>
> Very interesting! I have ArithmeticExpression objects that forms parse
> tree like reference tree. That can evaluate or derivate.
>

That's a natural way. And i think several implementations must exist
inSmalltalk. Then you will have other operations like evaluating,
substitution, pattern matching, simplifying, factoring... I did first
implement some of these features as messages in individual node class,
but then used more and more a TreeIterator pattern. This way it is
possible to better factor code (See StParseNodeVisitor for an example
of TreeIterator).

Also i could translate these parse trees in Smalltalk Block of code
with positional arguments, so as to evaluate fast when doing parameter
sweeping. However, i feel lisp a little superior conceptually at this
task: no difference between lisp code and parse tree...

Note that i also had translation of my SymbolicExpression in target
languages like C/FORTRAN/ADA or in LaTeX. I used this to build
Simulations ran by external code or to generate code for solving
optimization problems, and also to generate automatic documentation:
equations in these documents were less false than usual, because at
least, the same equations have really been used in programs.

It's good to work on symbolic equations, given the derivation, you can
linearize some parts, or do plenty other interesting work...

Unfortunately, all this code is not available. It's the property of my
previous employer.

I am quite new in publishing code. I simply used good tools from Cincom
VW (public store) as an easy start. Then i tried a Squeak port
(unfinished) to deal with a larger community, and then inquired
Dolphin. BTW, i am not aware of some Dolphin public repository as
Cincom public store or squeak source. Is there any?

I'd like to push Smalltalk in Math/Engineering fields because i know of
its power.
So far, i have not much feedback and not known Smallapack user. I'm
developing alone in my spare time.

Smallapack is not a standalone application, it's just a library... If
no one use Smalltalk for such tasks, I do not know if this is usefull
at all.

But i want to believe that this could change. Number crunching and
linear algebra can be used in financial domain also. A market were
Smalltalk is used...

If you ever have users or contributors, well that may be a little more
work, but you can potentially benefit by feedback...
Anyway, you can still decide to make a version 2, breaking some
compatibility.

Not at all. Pure old FORTRAN with procedural decomposition...
For linear algebra, you have some interesting things done in C++ (ublas
is a good example) and Java i think, but not that much in Smalltalk.
None i know is at the level of LAPACK. Most advanced are in fact LAPACK
interfaces...

There are two reasons why i did not use Smalltalk implementation:
- efficiency: Smalltalk is not efficient in Number crunching. It should
be used for higher tasks
- volume: LAPACK library is so huge that you will need an army of
Numerical Algorithm specialist to reprogram it in any other language
with same level of quality (accuracy, bug free, ...), even with a good
job of refactoring... This is really a teddious job.

Yes, AFAIK, computer algebra system were all written in LISP, or with
some LISP-like code.
That is understandable easily since we have to handle expression trees.
But I feel that with Smalltalk, you loose nothing in openess and
reflexivity, and you gain in structuring.

>
> Best Regards,
> Howard

Same.
Nicolas