I think there might be a disconnection in this thread. D only, or D frontend?

There are hardware vendor and commercial libraries that are heavily optimized for particular hardware configurations. There is no way a D-only solution can beat those. As an example Apple provides various implementations for their own machines, so an old program on a new machine can run faster than a static D-only library solution.

What D can provide is a unifying abstraction, but to get there one need to analyze what exists. Like Apple's Accelerate framework:

https://developer.apple.com/library/prerelease/ios/documentation/Accelerate/Reference/AccelerateFWRef/index.html#//apple_ref/doc/uid/TP40009465

That goes beyond BLAS. We also need to look at vDSP etc. You'll find similar things for Microsoft/Intel/AMD/ARM etc…

On Sunday, 14 June 2015 at 10:15:08 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 14 June 2015 at 09:59:22 UTC, Ilya Yaroshenko wrote:
>> We need D own BLAS implementation to do it.
>
> Why can't you use "version" for those that want to use a BLAS library for the implementation?
>
> Those who want replications of LAPACK/LINPACK APIs can use separate bindings? And those who want to use BLAS directly would not use phobos anyway, but a direct binding so they can switch implementation?
>
> I think a good generic higher level linear algebra library for D should aim to be equally useful for 2D Graphics, 3D/4D GPU graphics, CAD solid modelling, robotics, 3D raytracing, higher dimensional fractals, physics sims, image processing, signal processing, scientific computing (which is pretty wide) and more.
>
> The Phobos API should be user-level, not library-level like BLAS. IMO. You really want an API that look like this in Phobos?
>
> http://www.netlib.org/blas/
>
> BLAS/LAPACK/LINPACK all originate in Fortran with a particular scientific tradition in mind, so I think one should rethink how D goes about this. Fortran has very primitive abstraction mechanisms. This stuff is stuck in the 80s…

I am really don't understand what you mean with "generic" keyword.

Do you want one matrix type that includes all cases???
I hope you does not.

If not, yes it should be generic like all other Phobos. But we will have one module for 3D/4D geometric and 3D/4D matrix/vector multiplications, another module for general matrix (std.container.matrix) and another module with generic BLAS (std.numeric.blas) for general purpose matrixes. After all of that we can think about scripting like "m0 = m1*v*m2" features.

I think LAPACK would not be implemented in Phobos, but we can use SciD instead.

On Sunday, 14 June 2015 at 10:43:24 UTC, Ola Fosheim Grøstad wrote:
> I think there might be a disconnection in this thread. D only, or D frontend?
>
> There are hardware vendor and commercial libraries that are heavily optimized for particular hardware configurations. There is no way a D-only solution can beat those. As an example Apple provides various implementations for their own machines, so an old program on a new machine can run faster than a static D-only library solution.
>
> What D can provide is a unifying abstraction, but to get there one need to analyze what exists. Like Apple's Accelerate framework:
>
> https://developer.apple.com/library/prerelease/ios/documentation/Accelerate/Reference/AccelerateFWRef/index.html#//apple_ref/doc/uid/TP40009465
>
> That goes beyond BLAS. We also need to look at vDSP etc. You'll find similar things for Microsoft/Intel/AMD/ARM etc…

+1

On Sunday, 14 June 2015 at 11:43:46 UTC, Ilya Yaroshenko wrote:
> I am really don't understand what you mean with "generic" keyword.
>
> Do you want one matrix type that includes all cases???
> I hope you does not.

Yes, that is what generic programming is about. The type should signify the semantics, not exact representation.

Then you alias common types "float4x4" etc.

It does take a lot of abstraction design work. I've done some of it in C++ for sliced views over memory and arrays and I'd say you need many iterations to get it right.

> If not, yes it should be generic like all other Phobos. But we will have one module for 3D/4D geometric and 3D/4D matrix/vector multiplications, another module for general matrix (std.container.matrix) and another module with generic BLAS (std.numeric.blas) for general purpose matrixes. After all of that we can think about scripting like "m0 = m1*v*m2" features.

All I can say is that  I have a strong incentive to avoid using Phobos features if D does not automatically utilize the best OS/CPU vendor provided libraries in a portable manner and with easy-to-read high level abstractions.

D's strength compared to C++/Rust is that D can evolve to be easier to use than those languages. C++/Rust are hard to use by nature. But usability takes a lot of API design effort, so it won't come easy.

D's strength compared to Go is that it can better take advantage of hardware and provide better library abstractions, Go appears to deliberately avoid it. They probably want to stay nimble with very limited hardware-interfacing so that you can easily move it around in the cloud.

On Sunday, 14 June 2015 at 12:01:47 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 14 June 2015 at 11:43:46 UTC, Ilya Yaroshenko wrote:
>> I am really don't understand what you mean with "generic" keyword.
>>
>> Do you want one matrix type that includes all cases???
>> I hope you does not.
>
> Yes, that is what generic programming is about. The type should signify the semantics, not exact representation.
>
> Then you alias common types "float4x4" etc.

std.range has a lot of types + D arrays.
The power in unified API (structural type system).

For matrixes this API is very simple: operations like m1[] += m2, transposed, etc.

Ilya

On Sunday, 14 June 2015 at 12:18:39 UTC, Ilya Yaroshenko wrote:
> std.range has a lot of types + D arrays.
> The power in unified API (structural type system).

Yeah, I agree that templates in C++/D more or less makes those type systems structural-like, even though C is using nominal typing.

I've also found that although the combinatorial explosion is a possibility, most applications I write have a "types.h" file that define the subset I want to use for that application. So the combinatorial explosion is not such a big deal after all.

But one need to be patient and add lots of static_asserts… since the template type system is weak.

> For matrixes this API is very simple: operations like m1[] += m2, transposed, etc.

I think it is a bit more complicated than that. You also need to think about alignment, padding, strides, convolutions, identiy matrices, invertible matrices, windows on a stream, higher order matrices etc…

On Sunday, 14 June 2015 at 12:52:52 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 14 June 2015 at 12:18:39 UTC, Ilya Yaroshenko wrote:
>> std.range has a lot of types + D arrays.
>> The power in unified API (structural type system).
>
> Yeah, I agree that templates in C++/D more or less makes those type systems structural-like, even though C is using nominal typing.
>
> I've also found that although the combinatorial explosion is a possibility, most applications I write have a "types.h" file that define the subset I want to use for that application. So the combinatorial explosion is not such a big deal after all.
>
> But one need to be patient and add lots of static_asserts… since the template type system is weak.
>
>> For matrixes this API is very simple: operations like m1[] += m2, transposed, etc.
>
> I think it is a bit more complicated than that. You also need to think about alignment, padding, strides, convolutions, identiy matrices, invertible matrices, windows on a stream, higher order matrices etc…

Alignment, strides (windows on a stream - I understand it like Sliding Windows) are not a problem.

Convolutions, identiy matrices, invertible matrices are stuff I don't want to see in Phobos. They are about "MathD" not about (big) standard library.

For hight order slices see https://github.com/D-Programming-Language/phobos/pull/3397

On Sunday, 14 June 2015 at 13:48:23 UTC, Ilya Yaroshenko wrote:
> Alignment, strides (windows on a stream - I understand it like Sliding Windows) are not a problem.

It isn't a problem if you use the best possible abstraction from the start. It is a problem if you don't focus on it from the start.

> Convolutions, identiy matrices, invertible matrices are stuff I don't want to see in Phobos. They are about "MathD" not about (big) standard library.

I don't see how you can get good performance without special casing identity matrices, transposed matrices and so on. You surely need to support matrix inversion, Gauss-Jordan elimination (or the equivalent)  etc?

On Sunday, 14 June 2015 at 14:02:59 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 14 June 2015 at 13:48:23 UTC, Ilya Yaroshenko wrote:
>> Alignment, strides (windows on a stream - I understand it like Sliding Windows) are not a problem.
>
> It isn't a problem if you use the best possible abstraction from the start. It is a problem if you don't focus on it from the start.

I am sorry for this trolling:
Lisp is the best abstraction, thought.

Sometimes I find very cool abstract libraries, with relatively small number of users.
For example many programmers don't want to use Boost only because it's abstractions makes them crazy.

>> Convolutions, identiy matrices, invertible matrices are stuff I don't want to see in Phobos. They are about "MathD" not about (big) standard library.
>
> I don't see how you can get good performance without special casing identity matrices, transposed matrices and so on. You surely need to support matrix inversion, Gauss-Jordan elimination (or the equivalent)  etc?

For daily scientific purposes - yes.
For R/Matlab like mathematical library - yes.
For real world application - no. Engineer can achieve best performance without special cases by lowering "abstraction" down. Simplicity and transparency ("how it works") is more important in this case.

On Sunday, 14 June 2015 at 14:25:11 UTC, Ilya Yaroshenko wrote:
> I am sorry for this trolling:
> Lisp is the best abstraction, thought.

Even it if was, it does not provide the meta info and alignment type constraints that makes it possible to hardware/SIMD optimize it behind the scenes.

> For example many programmers don't want to use Boost only because it's abstractions makes them crazy.

Yes, C++ templates are a hard nut to crack, if D had added excellent pattern matching to its meta programming repertoire the I think this would be enough to put D in a different league.

Application programmers should not have to deal with lots of type parameters, they can use the simplified version (aliases). That's what I do in my C++ libs, using templated aliasing to make a complicated type composition easy to use while still getting the benefits generic pattern matching and generic programming.

>>> Convolutions, identiy matrices, invertible matrices are stuff
> For daily scientific purposes - yes.
> For R/Matlab like mathematical library - yes.
> For real world application - no. Engineer can achieve best performance without special cases by lowering "abstraction" down. Simplicity and transparency ("how it works") is more important in this case.

Getting platform optimized versions of frequently used heavy operations is the primary reason for why I would use a builtin library over rolling my own. Especially if the compiler has builtin high-level optimizations for the algebra.

A naive basic matrix library is simple to write, I don't need standard library support for that + I get it to work the way I want by using SIMD registers directly... => I probably would not use it if I could implement it in less than 10 hours.