[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gforth] Gforth's fsl-util.*
From: |
David Kuehling |
Subject: |
Re: [gforth] Gforth's fsl-util.* |
Date: |
Mon, 26 Nov 2012 01:33:27 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) |
>>>>> "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