5 ms·

> [?] QR: Afraid I'm not sure what you're referring to. > [+] Cholesky Decomposition: Trivial to implement How is it that you can judge Cholesky decomposition

> [?] QR: Afraid I'm not sure what you're referring to. > [+] Cholesky Decomposition: Trivial to implement How is it that you can judge Cholesky decomposition to be trivial to implement, while being unfamiliar with QR decomposition? Cholesky decomposition is not trivial to implement well. > Your post comes across to me as being rather cynical - but why not be supportive of the good work that's being done? I had a similar experience to what's happening here myself. I worked on a project that had some very specific requirements for a high performance simulation (described by a differential equation). I worked on a very specialized piece of code for a long time to optimize this differential equation solver, eventually writing a JIT compiler to generate specialized code for each simulation. I had a D advocate come along and rather vigorously argue that D can solve this problem, without really understanding it, and missing some key requirements. This sort of comes off the same way, "a numpy replacement". numpy is big and does a lot of stuff. Like Cholesky decomposition, many of these things have trivial implementations, and then they have good implementations. The trivial implementations will take a few hours to write. The good implementations will take a few months, or even longer. Sometimes "not good" means slow, sometimes "not good" means numerical stability issues, etc. If you don't have the right background, these things may not even be obvious. This is a bit of a pattern with D folks. Several times (this, my previous experience, and others), I've gotten the impression that a D fan comes along, invests a bit of time (a few weeks, months) in a particular domain, and starts making comparisons with other tools that they only scratch the surface of. It can rub people the wrong way. edit: The symbolic expression reference in this post is another example. Computer algebra is an incredibly difficult thing to implement. I don't know of anything that is harder to implement well than a computer algebra system. Yet, you link a single file under 1000 lines as partially checking the box in your list for symbolic expression manipulation. D might be a highly productive, but it's not that productive.

srean 11y ago
> This is a bit of a pattern with D folks Nothing D specific here. That's the pattern for every language, be it Haskell, Go, Common Lisp, JavaScript or Java ...
dallbee 11y ago
I should have provided a key. Where I listed a +, I basically meant that there was either work underway or it was something that could be done yourself without hindering a project too much. I did not intend to imply that symbolic expression was a solved problem, or anything of that sort. As for QR decomposition, I am actually rather familiar with it, my brain simply decided to fart on the symbols QR without being followed by decomposition. For Cholesky Decomposition, I'm sticking with "trivial to implement", and I'll even throw in "trivial to implement well": https://github.com/numpy/numpy/blob/v1.10.1/numpy/linalg/linalg.py#L532-L613 https://github.com/numpy/numpy/blob/v1.10.1/numpy/linalg/lin... You asked if D had code for a list of math capabilities that you use on a regular basis. My answer says "In many cases, no, but there's work being done toward that goal." No one is saying "we have a feature-complete math library!". There's much more needed than what you listed, and even the things you listed have many items with zero work done toward them. I am not attempting to say "D can do all these things!", and I don't think the author of the article was either.

srean 11y ago

> This is a bit of a pattern with D folks Nothing D specific here. That's the pattern for every language, be it Haskell, Go, Common Lisp, JavaScript or Java ...

dallbee 11y ago

I should have provided a key. Where I listed a +, I basically meant that there was either work underway or it was something that could be done yourself without hindering a project too much. I did not intend to imply that symbolic expression was a solved problem, or anything of that sort. As for QR decomposition, I am actually rather familiar with it, my brain simply decided to fart on the symbols QR without being followed by decomposition. For Cholesky Decomposition, I'm sticking with "trivial to implement", and I'll even throw in "trivial to implement well": https://github.com/numpy/numpy/blob/v1.10.1/numpy/linalg/linalg.py#L532-L613 https://github.com/numpy/numpy/blob/v1.10.1/numpy/linalg/lin... You asked if D had code for a list of math capabilities that you use on a regular basis. My answer says "In many cases, no, but there's work being done toward that goal." No one is saying "we have a feature-complete math library!". There's much more needed than what you listed, and even the things you listed have many items with zero work done toward them. I am not attempting to say "D can do all these things!", and I don't think the author of the article was either.