[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guile-user Digest, Vol 193, Issue 30
From: |
Zelphir Kaltstahl |
Subject: |
Re: guile-user Digest, Vol 193, Issue 30 |
Date: |
Wed, 26 Dec 2018 18:33:22 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 |
On 26.12.18 18:00, address@hidden wrote:
> Hello,
>
>> Is there some library, that enables high performance matrix operations
>> or even n-dimensional array operations? I am thinking of something like
>> NumPy in the Python ecosystem. I think NumPy in turn also uses some
>> lower level thing to do what it does. I think OpenBLAS or MKL, depending
>> on the architecture. I wonder if there is any wrapper around OpenBLAS
>> for Guile or something similar.
>> ...
> There are quite a few libs you might look at before you start to code your
> own:
>
> https://notabug.org/lloda
> ...
> guile-newra
> guile-ffi-cblas
> ...
> guile-ploy
> ...
>
> AIscm
> http://wedesoft.github.io/aiscm
>
> I also wrote a set of n-dim array math ops (including matrix ops) for
> Guile-CV:
>
> https://www.gnu.org/software/guile-cv/
> the manual is available online, math and matrix ops are
> described in
> the 'Processing' section
>
> mentioning Guile-CV because images are just a collection of n-dim
> arrays.
> (see 'Image Structure and Accessors' in the manual).
>
> in Guile-CV, all (almost all) arrays are f32vectors - see (srfi srfi-4)
> in
> the Guile manual - math and matrix ops are written in C (but memory
> allocation entirely kept in scheme). multi channel ops are
> multi-threaded
>
> some of these math and matrix ops also work on s32 and f64
> (undocumented so
> far): it would not take much to actually fully generalize all guile-cv
> math
> and matrix ops for the full set of (srfi srfi-4 ) types.
>
> Cheers,
> David
Thanks David,
I've added these to my notes for further investigation : )
In SciPy and if I am not mistaken in the Python bindings for OpenCV they
also use NumPy ndarray to represent images and it feels quite natural,
so it makes sense to me to use n-dimensional arrays for this.
It seems the "uniform numeric vectors" of Guile are an implementation of
the vectors in SRFI-4 as per:
https://www.gnu.org/software/guile/manual/html_node/Uniform-Numeric-Vectors.html#Uniform-Numeric-Vectors.
So far I have a very naive but working matrix operation implementation
here (WIP):
https://gitlab.com/ZelphirKaltstahl/neural-network/blob/dev/matrix.scm
(I know, it's not something no one has ever seen before :D)
I think, once I have a good idea about how to use a fitting library or
how to interface with a library of another programming language, I
should be able to switch how the data abstraction procedures work and
should directly gain the speed advantage for that. It is possible I
should structure my code more, for example by putting the tests in a
separate file etc. Or I should add another layer of abstraction between
the matrix operations and the data abstraction layer, maybe some kind of
"package of data abstraction" that I give the program as a parameter or
something. For now all that it is, is a hacky thing, with which I am
trying to reimplement some Python tutorial for neural networks, trying
to use matrix multiplication at the right places, after understanding
what those places are.
Yesterday I tried to use my transpose procedure and it turns out I
sooner run out of RAM (8GB) than the thing slows down. Once I run out of
RAM of course my machine hangs and I need to try to squeeze in some
Ctrl+C etc. Transposing a 1000x1000 was no issue, but going up to
1000x10000 exploded in my face :D Well, transposing is not the most
computationally expensive operation, so not a good measure and as I read
in the NumPy internals, there are way cleverer ways to handle
transposing, compared to the naive way I implemented it.
Regards,
Zelphir
- Re: guile-user Digest, Vol 193, Issue 30,
Zelphir Kaltstahl <=