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 :
> 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 > > 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 ? > > > 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. > 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 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... > 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. > > > > > > > - 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 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. > > > 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... > > > > 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. > 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. > 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)" > 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 |
Free forum by Nabble | Edit this page |