DIP80: phobos additions

Ilya Yaroshenko via Digitalmars-d digitalmars-d at puremagic.com
Sun Jun 14 04:43:45 PDT 2015


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.


More information about the Digitalmars-d mailing list