<div class="gmail_extra"><br><div class="gmail_quote">On 24 April 2012 08:32, Jens Mueller <span dir="ltr"><<a href="mailto:jens.k.mueller@gmx.de" target="_blank">jens.k.mueller@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Cristi Cobzarenco wrote:<br>
> Unfortunately, my proposal was not picked up this year. I might try to work<br>
> on these ideas this summer anyway so I would still be very much interested<br>
> in ideas and feedback, but I will probably have much less time if I'll be<br>
> working somewhere else.<br>
<br>
</div>I'm less familiar with your SciD code base but I have used Eigen<br>
regularly. Maybe you can answer my questions right away:<br>
1. How are expression evaluated? Eigen uses no BLAS backend. All<br>
code is generated by themselves.<br>
Do you plan for such an option?<br></blockquote><div><br></div><div>The expressions are built in a similar way to how they are in Eigen (any many other linear algebra libraries), using expression templates that build, essentially, abstract syntax trees which get evaluated on assignment (or with the eval() function). The back-end for evaluation can be specified using a version flag. Specifying "version=nodeps" results in code being generated by the library with no external dependencies - this is much slower, as it doesn't use SIMD operations or anything of the sort.</div>
<div><br></div><div>In the current state of the library, this is done by essentially providing naive implementations of the BLAS functions. In the revamped version, I plan this to be done in slightly different way (more similar to the way Eigen works) which removes the need for temporaries in some cases where using BLAS/LAPACK makes temporary allocation inevitable. In the immediate future I do not plan to include SIMD operations for the version=nodeps version and the library will be the most efficient when using BLAS & LAPACK.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. What is your goal for SciD? Do you want to have an Eigen in D? Are<br>
there places where a D solution may improved over the Eigen?<br></blockquote><div><br></div><div>These are really two questions:</div><div>> 2.1. What is your goal for SciD? Do you want to have an Eigen in D?</div>
<div><br></div><div>Short anwer: no. We already have a working library, it's mostly the interface that's getting a face-lift. Some of the design decisions we made early on (such as support for views) and compiler bugs (such as a clash between templated opAssign and postblit constructor) forced us to make some unfortunate interface decisions. In the long run it became obvious that views are pretty much useless and a lot of the compiler bugs that were hindering progress were fixed - so I thought I would improve the library's interface.</div>
<div><br></div><div>The more I worked on it, the more obvious it became I was converging onto Eigen's interface, with bits from MATLAB.</div><div><br></div><div>> 2.2. Are there places where a D solution may improved over the Eigen?</div>
<div><br></div><div>I'm not entirely sure. There's the obvious stuff like more natural slicing syntax which D allows us to do. Easily swappable backends is another thing - I'm writing everything to allow custom backends for the matrices (the backend will be a template parameter in the new version). This would in theory, allow GPU matrices to be easily written if anyone wanted (particularly if someone wrapped something like CUBLAS).</div>
<div><br></div><div>I am actually very interested in hearing from other people if they think there's stuff which we could do better thanks to D.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. I'm not so sure about the array() stuff. I never liked in Eigen.<br>
Being able to call std.algorithm on the raw memory may be sufficient<br>
for the time being.<br></blockquote><div><br></div><div>I am starting to lean against array myself. I wanted mostly to allow for arbitrary typed, higher-dimensional matrices with element-wise operations. But having worked a bit on the changes already, I realised that it's very easy to disallow certain matrix operations on types which do not support multiplication for example. Also I think I found an elegant way of supporting higher-dimensional matrices using the same type, but I have to do a bit more research into that.</div>
<div><br></div><div>In terms of running std.algorihtm on raw memory, that is and will be possible. Matrices provide two properties .data and .cdata, which provide a pointer to the raw memory (.cdata provides a constant one which may point to memory shared by multiple matrices, while .data makes sure the memory is unique).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4. How about a sparse storage backend for sparse matrices? I'm missing<br>
sparse matrices in Eigen even though the situation is improving but<br>
they're not fully integrated yet.<br></blockquote><div><br></div><div>Definitely. Sparse storage is a long term goal for the library, but not in the first iteration. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'd like to support your efforts for including your work in Phobos. How<br>
about you clone Phobos and gradually move your work into a work in<br>
progress branch? Really little steps. This allows me to follow you<br>
closely. To familiarize myself with the code and I would then fill in<br>
unittest, documentation and benchmarking code where missing as we go.<br></blockquote><div><br></div><div>That is actually a better idea than what I had in mind. I will do that. I am really glad you're interested in the project, but unfortunately I won't be able to start work on the library until the beginning of June. Also the proposal for the project was meant as my full-time job this summer, but since I'll probably be working somewhere else now you should take into account that I probably won't be able to stick to the schedule I gave in the proposal.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Jens<br>
</font></span><br>
PS<br>
It's great to hear that you plan for including your work in Phobos.<br></blockquote><div><br></div><div>Not trying to include it into Phobos was a mistake that we made last year. It should have been this way from the beginning. Thanks for showing interest and I'll keep you posted once I start working, I hope I answered your questions satisfactorily, if not let me know.</div>
<div><br class="Apple-interchange-newline"><br></div><div>---</div>Cristi Cobzarenco<div>BSc in Artificial Intelligence and Computer Science</div><div>University of Edinburgh<br>Profile: <a href="http://www.google.com/profiles/cristi.cobzarenco" target="_blank">http://www.google.com/profiles/cristi.cobzarenco</a></div>
<br><br class="Apple-interchange-newline"><div> </div></div><br></div>