On Tuesday, 24 June 2014 at 03:29:52 UTC, H. S. Teoh via
Digitalmars-d wrote:
Using lapack/blas as the backend would guarantee good
performance,
though I'm not sure if the Phobos maintainers would be too
thrilled at
the idea, after the fiasco with libcurl.
It is straightforward with
I have implemented a couple of matrices which may be of interest.
One is heap allocated with garbage collection, another is based
on 2D static arrays. I didn't implement a spare matrix.
https://github.com/w0rp/dstruct/blob/master/source/dstruct/matrix.d
There's very little which can be shared
On Tuesday, 24 June 2014 at 04:36:04 UTC, ed wrote:
On Monday, 23 June 2014 at 21:08:03 UTC, Mason McGill wrote:
[snip]
Concepts:
InputGrid: anything with a size (size_t[n]) and n-dimensional
opIndex.
OutputGrid: anything with a size (size_t[n]) and
n-dimensional opIndexAssign.
[snip]
David Bregman:
I didn't read the linked paper, but the performance quoted in
the abstract comparable (from 48% to 100%) to that of
lower-level Java programs sounds pretty underwhelming.
The design I've suggested is not that virtual/indirect, so the
performance is better.
Bye,
bearophile
David Bregman:
I think this approach would also be good for D, at least if the
idea is to target numeric computing people.
I am thinking about something slightly different, and with a
semantics more similar to that Haskell library. I don't think D
is going to compete with Julia and its high
On Tuesday, 24 June 2014 at 07:01:14 UTC, Mason McGill wrote:
On Tuesday, 24 June 2014 at 04:36:04 UTC, ed wrote:
On Monday, 23 June 2014 at 21:08:03 UTC, Mason McGill wrote:
[snip]
Concepts:
InputGrid: anything with a size (size_t[n]) and n-dimensional
opIndex.
OutputGrid: anything with a
On 6/23/14, 8:46 PM, Tofu Ninja wrote:
On Tuesday, 24 June 2014 at 03:29:52 UTC, H. S. Teoh via Digitalmars-d
wrote:
a compile-time DSL instead of hack tricks like expression
That sounds like a it will be very odd to use and most likely have very
little benefit. I think most people would
I'd like a matrix library for D, able to handle sparse matrices
too. But first I'd like to discuss its API and general design a
bit.
---
I think a starting point for the design is visible in this paper,
Optimizing Array Accesses in High Productivity Languages by
Mackale
On Mon, Jun 23, 2014 at 04:45:27PM +, bearophile via Digitalmars-d wrote:
I'd like a matrix library for D, able to handle sparse matrices
too. But first I'd like to discuss its API and general design a
bit.
When it comes to libraries that need to handle diverse concrete types
(e.g. compact
H. S. Teoh:
Operations like intersections, subarrays, etc., should be done
via wrapper types
A Region is not an array of data, it's more like a
[(x1,x2),(y1,y2)]. You can allocate an array given a Region, you
can iterate a Region, etc.
A.distribution ::= distribution of array A
What's
On Monday, 23 June 2014 at 16:45:28 UTC, bearophile wrote:
I'd like a matrix library for D, able to handle sparse matrices
too. But first I'd like to discuss its API and general design a
bit.
This all reminds me, I was thinking I'd like to try adding some
array language features to D at some
H. S. Teoh:
The key to success, then, lies in how we design the generic
matrix API. If we do it right, then it should be easy to
implement features like compile-time size verifications,
etc.. Otherwise it can be very painful.
One point of my post was to see if it could be useful to extend
On Monday, 23 June 2014 at 16:45:28 UTC, bearophile wrote:
I'm glad to hear there's interest in this! I've actually been
working on a generic multidimensional array library myself (on
and off) for the past few months (I'm hoping to have a
well-documented dub package by the end of the summer).
On Mon, Jun 23, 2014 at 09:08:02PM +, Mason McGill via Digitalmars-d wrote:
On Monday, 23 June 2014 at 16:45:28 UTC, bearophile wrote:
I'm glad to hear there's interest in this! I've actually been working
on a generic multidimensional array library myself (on and off) for
the past few
On Mon, Jun 23, 2014 at 09:09:03PM +, bearophile via Digitalmars-d wrote:
H. S. Teoh:
The key to success, then, lies in how we design the generic matrix
API. If we do it right, then it should be easy to implement features
like compile-time size verifications, etc.. Otherwise it can be
On Monday, 23 June 2014 at 21:33:40 UTC, H. S. Teoh via
Digitalmars-d wrote:
You are far from the first one to write a multidimensional
array library
in D. Denis has already done this some time ago, and I have,
too.
I've seen Denis' library. It seems nice, but it's a lot more
concrete that
Have you looked at armadillo for inspiration?
http://arma.sourceforge.net/
It's a C++ matrix/linear algebra library which has:
-expression templates for high level optimizations (could be done
even better in D of course, moving more stuff to compile time)
-high performance via lapack/blas
On Tue, Jun 24, 2014 at 03:04:53AM +, David Bregman via Digitalmars-d wrote:
Have you looked at armadillo for inspiration? http://arma.sourceforge.net/
It's a C++ matrix/linear algebra library which has:
-expression templates for high level optimizations (could be done even
better in D
On Tuesday, 24 June 2014 at 03:29:52 UTC, H. S. Teoh via
Digitalmars-d wrote:
a compile-time DSL instead of hack tricks like expression
That sounds like a it will be very odd to use and most likely
have very little benefit. I think most people would agree that
matrix math is a good use
On Monday, 23 June 2014 at 21:08:03 UTC, Mason McGill wrote:
[snip]
Concepts:
InputGrid: anything with a size (size_t[n]) and n-dimensional
opIndex.
OutputGrid: anything with a size (size_t[n]) and
n-dimensional opIndexAssign.
[snip]
Cheers,
Mason
I don't think 'Grid' is not a good
On Tue, Jun 24, 2014 at 03:46:09AM +, Tofu Ninja via Digitalmars-d wrote:
On Tuesday, 24 June 2014 at 03:29:52 UTC, H. S. Teoh via Digitalmars-d
wrote:
a compile-time DSL instead of hack tricks like expression
That sounds like a it will be very odd to use and most likely have
very
21 matches
Mail list logo