www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Linear algebra library

reply "Maksim Zholudev" <maximzms gmail.com> writes:
Hello!

It looks like SciD [1] is obsolete and work on its reincarnation 
[2] have not been started yet.

Here is yet another linear algebra library for D:
https://github.com/MaksimZh/linalg/wiki

It was inspired by proposal [2] but has some differences:

1) Support of immutable data and pure functions.

2) No reference counting, no copy-on-write.
- It looks completely incompatible with immutable matrices.
- Unpredictable GC allocations make people sad [3].
So matrices act like built-in D arrays: slice is a view, copying 
is forced with `.dup` etc.

3) Support of backends that can be enabled with compiler options 
(e.g. -version=linalg_backend_lapack) and add optimization and 
new features.
The library works even without any backend.
In current (pre-alpha) version this feature is just outlined: 
enabling LAPACK adds evaluation of eigenvalues for 
`Complex!double` matrices and activates corresponding unittests.


The library now looks inconsistent because I focus mainly on the 
features needed in my work. Probably I've made some bad 
design/implementation decisions due to lack of experience.

Any ideas and advices are welcome.


References:
[1] https://github.com/kyllingstad/scid
[2] https://github.com/cristicbz/scid/wiki/GSoC-2012-Proposal
[3] http://forum.dlang.org/thread/kjo7id$22jk$1 digitalmars.com
Apr 09 2013
next sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
09.04.2013 17:52, Maksim Zholudev пишет:

 Hello!

 It looks like SciD [1] is obsolete and work on its reincarnation [2]
 have not been started yet.

 Here is yet another linear algebra library for D:
 https://github.com/MaksimZh/linalg/wiki

 It was inspired by proposal [2] but has some differences:

 1) Support of immutable data and pure functions.

 2) No reference counting, no copy-on-write.
 - It looks completely incompatible with immutable matrices.
 - Unpredictable GC allocations make people sad [3].
 So matrices act like built-in D arrays: slice is a view, copying is
 forced with `.dup` etc.

 3) Support of backends that can be enabled with compiler options (e.g.
 -version=linalg_backend_lapack) and add optimization and new features.
 The library works even without any backend.
 In current (pre-alpha) version this feature is just outlined: enabling
 LAPACK adds evaluation of eigenvalues for `Complex!double` matrices and
 activates corresponding unittests.


 The library now looks inconsistent because I focus mainly on the
 features needed in my work. Probably I've made some bad
 design/implementation decisions due to lack of experience.

 Any ideas and advices are welcome.


 References:
 [1] https://github.com/kyllingstad/scid
 [2] https://github.com/cristicbz/scid/wiki/GSoC-2012-Proposal
 [3] http://forum.dlang.org/thread/kjo7id$22jk$1 digitalmars.com


What about to post such a good news also in digitalmars.D.announce?

Also, if we are talking about matrices, very sad a solution for 
enhancement 6798 [1] isn't merged yet.

[1] http://d.puremagic.com/issues/show_bug.cgi?id=6798

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 09 2013
parent reply "Maksim Zholudev" <maximzms gmail.com> writes:
On Tuesday, 9 April 2013 at 14:41:09 UTC, Denis Shelomovskij 
wrote:

 What about to post such a good news also in 
 digitalmars.D.announce?


It was hard to choose the forum because the previous SciD topic 
[2] is also here.
I'm afraid posting same topic in two forums would split the 
discussion.


 Also, if we are talking about matrices, very sad a solution for 
 enhancement 6798 [1] isn't merged yet.

 [1] http://d.puremagic.com/issues/show_bug.cgi?id=6798


Yes, I know about this. At the beginning I tried to implement 
multidimensional slices putting them into different bracket pairs 
like `a[1..2][3..4]`. It was hell.

There is pull request [2] that adds everything but strides.
My code relies on it. It still compiles even without these 
features but one have to construct slices manually: 
`a[Slice(1,2), Slice(3,4)]`.

Let's hope work on linear algebra support will legitimate the new 
features.


[1] 
http://forum.dlang.org/thread/CABvqKjioJzOO4pZ98VhPX-p9UKpVN7KhcQ63jUgEj1eTNSh30A mail.gmail.com
[2] https://github.com/D-Programming-Language/dmd/pull/443
Apr 09 2013
next sibling parent "Maksim Zholudev" <maximzms gmail.com> writes:
Correction:

Should be


 It was hard to choose the forum because the previous SciD topic 
 [1] is also here.


where


 [1] 
 http://forum.dlang.org/thread/CABvqKjioJzOO4pZ98VhPX-p9UKpVN7KhcQ63jUgEj1eTNSh30A mail.gmail.com
Apr 09 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Apr 09, 2013 at 06:57:08PM +0200, Maksim Zholudev wrote:

 On Tuesday, 9 April 2013 at 14:41:09 UTC, Denis Shelomovskij wrote:


[...]

Also, if we are talking about matrices, very sad a solution for
enhancement 6798 [1] isn't merged yet.

[1] http://d.puremagic.com/issues/show_bug.cgi?id=6798


 
 Yes, I know about this. At the beginning I tried to implement
 multidimensional slices putting them into different bracket pairs
 like `a[1..2][3..4]`. It was hell.


I worked around that in my own multidimensional array implementation by
using a helper struct for encapsulating a range of indices:

	struct IndexRange {
		int start, end;
	}

Since opSlice couldn't take more than one range, I decided to overload
opIndex instead, so you could write:

	auto arr = Array!(3,int)([3, 4, 5]);

	// Index single element:
	arr[0, 1, 2] = ...;

	// Subdimensional slicing:
	auto brr = arr[IndexRange(0,2), 2, IndexRange(3,4)];

	// opDollar works correctly in all dimensions, even inside
	// IndexRange!
	auto crr = arr[$-1, IndexRange(0,$), IndexRange($-2, $-1)];
	// equivalent to arr[2, IndexRange(0,4), IndexRange(3,4)]

This is implemented by using variadics since int differs from
IndexRange:

	auto opIndex(A...)(A args) {
		foreach (i; args) {
			static if (is(typeof(i) == int)) {
				...
			} else static if (is(typeof(i) == IndexRange)) {
				...
			}
		}
		return result;
	}

No temporaries are created, unlike the chained opSlice approach, you can
make subdimensional slices in a single opIndex call. (The disadvantage,
though, is that it has template bloat if you do a lot of this.)



 There is pull request [2] that adds everything but strides.
 My code relies on it. It still compiles even without these features
 but one have to construct slices manually: `a[Slice(1,2),
 Slice(3,4)]`.
 
 Let's hope work on linear algebra support will legitimate the new
 features.


[...]

Yeah, I'm hoping for solid support for linear algebra eventually. D's
generics makes it possible to write generic linear algebra algorithms
that don't depend on exact matrix representation, which in C++ makes it
a pain to interface two different algebra libraries together (you have
to keep converting between representations).


T

-- 
If you look at a thing nine hundred and ninety-nine times, you are
perfectly safe; if you look at it the thousandth time, you are in
frightful danger of seeing it for the first time. -- G. K. Chesterton
Apr 09 2013
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 04/09/2013 03:52 PM, Maksim Zholudev wrote:

 It looks like SciD [1] is obsolete


Is that really true?  How does your work compare with Cristi Cobzarenco's
updated version <https://github.com/cristicbz/scid> ... ?

(I ask because you reference the proposal but not the work that was actually
done.)
Apr 09 2013
parent "Maksim Zholudev" <maximzms gmail.com> writes:
On Tuesday, 9 April 2013 at 20:14:43 UTC, Joseph Rushton Wakeling 
wrote:

 On 04/09/2013 03:52 PM, Maksim Zholudev wrote:

 It looks like SciD [1] is obsolete


 Is that really true?  How does your work compare with Cristi 
 Cobzarenco's
 updated version <https://github.com/cristicbz/scid> ... ?

 (I ask because you reference the proposal but not the work that 
 was actually done.)


Well, that sentence is not clear (my fault) it was about linear 
algebra part of SciD.
Actually both versions of linear algebra are "obsolete" since the 
GSoC-2012 proposal looks like announce of another rewriting from 
scratch.
Apr 10 2013
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Tuesday, 9 April 2013 at 13:52:58 UTC, Maksim Zholudev wrote:

 Hello!

 It looks like SciD [1] is obsolete [...]


"Obsolete" is the wrong word here.  SciD is currently not 
actively developed (I'm sorry to say), but it's not like Gaussian 
quadrature no longer works...

The library does suffer from some bit rot due to compiler 
modifications, though, which I was not aware of until now.  I'll 
get that sorted out shortly.  When that is done, SciD will still 
work the way it always has.  It just won't be getting any new 
functionality in the foreseeable future.

And I've said this before, but I'll say it again:

Cristi Cobzarenco's "SciD" is not a "new" or "updated" version of 
SciD.  The reason it retains that name is that he started his 
work by forking my library.  However, he removed all 
non-linear-algebra functionality, and then rewrote the entire 
linear algebra modules from scratch, so there really isn't much 
left of SciD in there AFAIK.

Lars.
Apr 09 2013
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 04/09/2013 10:23 PM, Lars T. Kyllingstad wrote:

 Cristi Cobzarenco's "SciD" is not a "new" or "updated" version of SciD.  The
 reason it retains that name is that he started his work by forking my library. 
 However, he removed all non-linear-algebra functionality, and then rewrote the
 entire linear algebra modules from scratch, so there really isn't much left of
 SciD in there AFAIK.


Apologies if I mischaracterized the situation.  My impression had been that this
was a cooperative work (or a conscious handing of the baton).
Apr 09 2013
parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Tuesday, 9 April 2013 at 20:29:51 UTC, Joseph Rushton Wakeling 
wrote:

 On 04/09/2013 10:23 PM, Lars T. Kyllingstad wrote:

 Cristi Cobzarenco's "SciD" is not a "new" or "updated" version 
 of SciD.  The
 reason it retains that name is that he started his work by 
 forking my library. However, he removed all non-linear-algebra 
 functionality, and then rewrote the
 entire linear algebra modules from scratch, so there really 
 isn't much left of
 SciD in there AFAIK.


 Apologies if I mischaracterized the situation.  My impression 
 had been that this
 was a cooperative work (or a conscious handing of the baton).



No need to apologise!  Your impression wasn't far off. As I 
remember it, Cristi's intention was to either submit the library 
for inclusion in Phobos, or if that failed, to fold it back into 
SciD.  That never happened, however, but the name stuck, and that 
has created some confusion.

Lars
Apr 09 2013
prev sibling parent "Maksim Zholudev" <maximzms gmail.com> writes:
On Tuesday, 9 April 2013 at 20:23:54 UTC, Lars T. Kyllingstad 
wrote:

 The library does suffer from some bit rot due to compiler 
 modifications, though, which I was not aware of until now.  
 I'll get that sorted out shortly.  When that is done, SciD will 
 still work the way it always has.  It just won't be getting any 
 new functionality in the foreseeable future.


What about ScientificD organization?
https://github.com/kyllingstad/scid/issues/3
Apr 10 2013