Re: [gforth] Gforth's fsl-util.*

[David Kuehling]

>>>>> "Bernd" == Bernd Paysan <address@hidden> writes:

> Am Montag, 26. November 2012, 00:04:23 schrieb David Kuehling:
>> I am aware that } and }} are suboptimal for various reasons.
>> However, From the standponit of a person who just wants to quickly
>> implement some readable math code, using concepts and semantics not
>> too different from Octave (MatLab) or Fortran, they do their job very
>> well.

> Unlike Fortran, MatLab/Octave have a number of nice higher order
> functions to deal with things like matrix multiplication and
> row/column vectors of these.  And they build on LAPACK/BLAS, which
> gives them high-performance implementations of these.

I probably would have ended up using Octave if I wanted to deal with
floating point types, but the math I currently do is over finite fields.
Blas nor Lapack help neither.

>> No, people hacking math algorithms usually don't want to think about
>> iterators and data-flow, or about vector-multiplication factors.  At
>> least not for the first version.  Ideally the syntax in Forth doesn't
>> look too different from the math formulas used on paper to derive the
>> algorithm in the first place.

> Hm, have you actually looked at math formulas for matrix
> multiplication on paper?  The wikipedia article contains several
> expressions, and the one with the dot product of rows/colums is part
> of it:
[..]

I once wrote a diploma thesis full of these kind of formulas for matrix
pseudoinverse and related problems, so in fact *do* know the pleasure of
having slices.  But I won't bother (at least not for now) with adding
something like that to Gforth, when fsl-util is immediately available,
sufficient and even somewhat standardized, while Gforth lacks most of
the facilities that'd be required to properly implement a transparent
slice type anyways.

>> If you want to optimize, you'll usually have to think about block
>> matrix algorithms, at which point your code will lose all its
>> mathematical clearness anyway.

> It's not really that awful.  Block matrix multiplication is actually
> the same equation as elementary matrix multiplication, just that you
> use submatrices as elements.  Actually, what you esentially do on a
> block matrix multiplication is to change the evaluation order within
> the three nested loops.

Yeah block matrix *multiplication* is the same as normal multiplication,
but try to think about something less basic.  Give me a block matrix
*pfaffian*, please :)

>> So here is a person very happy with } and }} asking for as much
>> performance as possible for his non-optimized (but readable)
>> script-language-style math code.

> I simply see a considerable amount of improvement.  One is that most
> of these vectors are arrays of float (fixed size, known at compile
> time), and yet, they have to multiply by a variable in memory each
> time.  Well, FSL was deliberately created to translate Fortran code
> 1:1 to Forth, so I see your point.

Who said floats?  FSL arrays are very nice in that they allow any kind
of data-type.  I'd even be using them if I hat to work on bignums.

> I just would strongly discourage to use FSL's arrays outside FSL
> itself.

I'd appreciate any alternative that's readily available and comes with
at least the same features and minimalism.  There's no that I can see.

cheers,

David
-- 
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40

pgpjObE1KC0su.pgp
Description: PGP signature