Re: Vision document for H2 2016
On Thursday, 7 July 2016 at 19:56:29 UTC, Andrei Alexandrescu
wrote:
On 07/07/2016 03:55 PM, Andrei Alexandrescu wrote:
https://wiki.dlang.org/Vision/2016H2 -- Andrei
Please provide feedback. We'll make a couple more passes before
this is complete. Thanks! -- Andrei
This list is full of good and worthy stuff, but is very long.
Most of this won't be done in 2H16, so calling these "2H16
priorities" is misleading, and doesn't give a good impression.
For someone who really know where the language is headed, there's
no sense of what will really be done in the next six months, what
is in progress and might be done, and what stuff is just wishful
thinking. The fact that so much is just copied over from last
half says it all.
Some of these, especially the marketing, are evergreen tasks.
("Promote books and articles"). If there's something concrete you
have in mind for 2H16 say it, otherwise, it belongs somewhere
else.
This is a really good long-term vision list, and it might be
better labeled that, with different items slated for expected
realization (2H16, 1H17, "Who knows?"), etc. (Links to associated
bug reports would be useful too, so we know what's being worked
on.)
In general, I feel like a list like this should actually be
achievable. There's a silly, but still useful, business thing
called "S.M.A.R.T." goals: Specific, Measurable, Attainable,
Realistic, and Timely. This ain't that.
Re: matrix library
On Monday, 23 May 2016 at 07:28:20 UTC, Vlad Levenfeld wrote: https://github.com/evenex/linalg I've some heard people (including me) asking about matrix libraries for D, and while there is gl3n it only goes to 4x4 matrices and was written before all the multidimensional indexing stuff. So I was using gl3n for awhile until I needed some 6x6s and threw together a syntax-sugary sort of wrapper over std.experimental.ndslice and cblas for matrix math. You can slice submatrices, assign to them, and perform ops on them with other matrices or 2-dimensional array slices... though, for implementation-ish reasons, ops involving 2-d arrays are elementwise (you'll have to call the Matrix constructor to use matrix multiplication again). It was built in kind of an ad-hoc way and I will be adding stuff to it as the need arises, so there's nothing there yet beyond the bare basics and you should expect bugs. All the matrices hold static arrays because I don't want to mess with reference problems right now. A matrix past a certain size will be more efficient to store as a dynamic array, of course. But, right now, I need this to make writing linear algebra code comfortable for myself rather than try to win at benchmarks. Bugs/Pull/Feature requests welcome. This is nice! I recently found myself having to make ad hoc lightweight matrix classes that wrap some blas functions. Making the dims template/compile-time params is an interesting choice, but I wonder if it is unduly limiting. How does what you're doing compare to what's in https://github.com/DlangScience/scid/blob/master/source/scid/linalg.d ? While that project doesn't have a ton of manpower behind it, it does seem like it's actively maintained, and they have brought in a ton of the lapack/blas headers already. It would be nice, and I think do-able, to have a relatively complete and performant library for matrices/ndarrays, especially given the recent work on ndslice. (If there are plans or a roadmap for this sort of thing, I'd love to contribute, and it seems from this announcement that others are interested also.)
