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