I'm not a programmer myself and used D for a project in computational
electromagnetics. While I had to implement numerical integration and a bit
of linear algebra which was annoying (would be really useful in phobos), it
was a joy to work with and the resulting program was incredibly fast.
Most others used matlab and the difference in speed was more than a factor
100. Not only that, prototyping went quicker in D.

I've also written a simulation of the dual slit experiment which I'll drop somewhere on github once the code is presentable.

So, if you don't mind having to implement a few algorithms that are already available in numpy, D will be pleasant and fast.

2015-08-04 11:48 GMT+02:00 Chris via Digitalmars-d < digitalmars-d@puremagic.com>:

> On Sunday, 2 August 2015 at 16:25:18 UTC, Yura wrote:
>
>> Dear D coders/developers,
>>
>> I am just thinking on one project in computational chemistry, and it is sort of difficult for me to pick up the right language this project to be written. The project is going to deal with the generation of the molecular structures and will resemble to some extent some bio-informatic stuff. Personally I code in two languages - Python, and a little bit in C (just started to learn this language).
>>
>> While it is easy to code in Python there are two things I do not like:
>>
>> 1) Python is slow for nested loops (much slower comparing to C)
>> 2) Python is not compiled. However, I want to work with a code which can
>> be compiled and distributed as binaries (at least at the beginning).
>>
>> When it comes to C, it is very difficult to code (I am a chemist rather than computer scientist). The pointers, memory allocation, absence of the truly dynamically allocated arrays, etc, etc make the coding very long. C is too low level I believe.
>>
>> I just wander how D would be suitable for my purpose? Please, correct me if I am wrong, but in D the need of pointers is minimal, there is a garbage collector, the arrays can be dynamically allocated, the arrays can be sliced, ~=, etc which makes it similar to python at some extent. I tried to write a little code in D and it was very much intuitive and similar to what I did both in Python and C.
>>
>> Any hints/thoughts/advises?
>>
>> With kind regards,
>> Yury
>>
>
> I agree with bachmeier. You cannot go wrong. You mentioned nested loops. D allows you to concatenate (or "pipe") loops. So instead of
>
> foreach
> {
>   foreach
>   {
>     foreach
>     {
>     }
>   }
> }
>
> you have something like
>
> int[] numbers = [-2, 1, 6, -3, 10];
> foreach (ref n; numbers
>   .map!(a => a * 5)  // multiply each value by 5
>   .filter!(a => a > 0))  // filter values that are 0 or less
> {
>   //  Do something
> }
>
> or just write
>
> auto result = numbers.map!(a => a * 5).filter!(a => a > 0);
> // ==> result = [5, 30, 50]
>
> You'd probably want to have a look at:
>
> http://dlang.org/phobos/std_algorithm.html
>
> and ranges (a very important concept in D):
>
> http://ddili.org/ders/d.en/ranges.html http://wiki.dlang.org/Component_programming_with_ranges
>
> Excessive use of nested loops is not necessary in D nor is it very common. This makes the code easier to maintain and less buggy in the end.
>

On Tuesday, 4 August 2015 at 13:25:22 UTC, maarten van damme wrote:
> I'm not a programmer myself and used D for a project in computational
> electromagnetics. While I had to implement numerical integration and a bit
> of linear algebra which was annoying (would be really useful in phobos), it
> was a joy to work with and the resulting program was incredibly fast.
> Most others used matlab and the difference in speed was more than a factor
> 100. Not only that, prototyping went quicker in D.

Good that you point that out. Most people I know claim that it's easier to develop/prototype in with Matlab. Apart from execution speed and fast prototyping, Matlab is proprietary. This alone is a deal breaker.

> I've also written a simulation of the dual slit experiment which I'll drop somewhere on github once the code is presentable.
>
> So, if you don't mind having to implement a few algorithms that are already available in numpy, D will be pleasant and fast.
>

On Tuesday, 4 August 2015 at 13:42:15 UTC, Chris wrote:

> Good that you point that out. Most people I know claim that it's easier to develop/prototype in with Matlab. Apart from execution speed and fast prototyping, Matlab is proprietary. This alone is a deal breaker.

I can only imagine it being faster to prototype in Matlab if there are additional libraries available. D's just a way better language - Matlab was designed as a replacement for FORTRAN 77 - and static typing means the compiler catches a lot of bugs that you don't want to think about while prototyping.

On Tuesday, 4 August 2015 at 13:42:15 UTC, Chris wrote:
> On Tuesday, 4 August 2015 at 13:25:22 UTC, maarten van damme wrote:
>> I'm not a programmer myself and used D for a project in computational
>> electromagnetics. While I had to implement numerical integration and a bit
>> of linear algebra which was annoying (would be really useful in phobos), it
>> was a joy to work with and the resulting program was incredibly fast.
>> Most others used matlab and the difference in speed was more than a factor
>> 100. Not only that, prototyping went quicker in D.
>
> Good that you point that out. Most people I know claim that it's easier to develop/prototype in with Matlab. Apart from execution speed and fast prototyping, Matlab is proprietary. This alone is a deal breaker.

Matlab is a linear algebra DSL with a general purpose mathematical programming language caked on to it, held in place purely by money and consumer lock-in.

On Tuesday, 4 August 2015 at 13:58:02 UTC, bachmeier wrote:
> On Tuesday, 4 August 2015 at 13:42:15 UTC, Chris wrote:
>
>> Good that you point that out. Most people I know claim that it's easier to develop/prototype in with Matlab. Apart from execution speed and fast prototyping, Matlab is proprietary. This alone is a deal breaker.
>
> I can only imagine it being faster to prototype in Matlab if there are additional libraries available. D's just a way better language - Matlab was designed as a replacement for FORTRAN 77 - and static typing means the compiler catches a lot of bugs that you don't want to think about while prototyping.

I think it's a myth that Matlab is better for prototyping. A lot of people don't want to learn D (or any other language) and say that prototyping in Matlab is faster (which it is, of course, if you don't know D at all).

Have you ever seen any of those quickly written Matlab programs? Oh deary me!

On Tuesday, 4 August 2015 at 09:48:07 UTC, Chris wrote:
> I agree with bachmeier. You cannot go wrong. You mentioned nested loops. D allows you to concatenate (or "pipe") loops. So instead of
>
> foreach
> {
>   foreach
>   {
>     foreach
>     {
>     }
>   }
> }
>
> you have something like
>
> int[] numbers = [-2, 1, 6, -3, 10];
> foreach (ref n; numbers
>   .map!(a => a * 5)  // multiply each value by 5
>   .filter!(a => a > 0))  // filter values that are 0 or less
> {
>   //  Do something
> }
>

I don't think I had seen an example like this before (though it is obvious in retrospect). Is there any advantage in terms of performance?

On Tuesday, 4 August 2015 at 18:56:20 UTC, jmh530 wrote:

> I don't think I had seen an example like this before (though it is obvious in retrospect). Is there any advantage in terms of performance?

The big win is in terms of being able to write complicated, correct code easily. However, there was a recent thread on the topic: http://forum.dlang.org/post/mailman.4829.1434623275.7663.digitalmars-d@puremagic.com

Walter said, "I expect that at the moment, range+algorithms code will likely be somewhat slower than old fashioned loops. This is because code generators have been tuned for decades to do a great job with loops.

There's no intrinsic reason why ranges must do worse, so I expect they'll achieve parity.

Ranges can move ahead because they can reduce the algorithmic complexity, whereas user written loops tend to be suboptimal."

On Tuesday, 4 August 2015 at 13:58:02 UTC, bachmeier wrote:
> I can only imagine it being faster to prototype in Matlab if there are additional libraries available. D's just a way better language - Matlab was designed as a replacement for FORTRAN 77 - and static typing means the compiler catches a lot of bugs that you don't want to think about while prototyping.

It depends on what you need to do. I typically use Matlab/R/Python for statistics, matrix math, and optimization. Because all the libraries are either part of the language or readily available, I can do what I need to easily...much easier than in D.

Wrt static typing, I don't think the issue is about catching bugs in Matlab. I just haven't had much an issue with mixing up types in Matlab. I can see the arguments about static typing and ahead of time compilation for performance, but that's less important for prototyping. One good thing about dynamic typing is that it allows for easier manipulation of matrices.

On Tuesday, 4 August 2015 at 19:40:30 UTC, jmh530 wrote:

> Wrt static typing, I don't think the issue is about catching bugs in Matlab. I just haven't had much an issue with mixing up types in Matlab. I can see the arguments about static typing and ahead of time compilation for performance, but that's less important for prototyping. One good thing about dynamic typing is that it allows for easier manipulation of matrices.

For me, the big win in prototyping comes from the ability to easily make significant changes to my program. With D, I am able to give the compiler a bunch of information about the types of data I'm working with, and the compiler handles all the details for me, better than a good research assistant. If I change the function to take different input or return different output, I don't have to look through 500 lines of code to make sure I'm keeping everything consistent.

A couple of things that might make D more pleasant for me are:
- I do a lot of simulation-related things, where the inputs and outputs can change a lot as I figure out how I want to do things, and
- I use R. R was invented down the hall from C, and AFAICT, the C and R guys were believers that silent casting and undefined behavior are the foundation of a good programming language.

On Tuesday, 4 August 2015 at 20:37:18 UTC, bachmeier wrote:
> A couple of things that might make D more pleasant for me are:
> - I do a lot of simulation-related things, where the inputs and outputs can change a lot as I figure out how I want to do things, and
> - I use R. R was invented down the hall from C, and AFAICT, the C and R guys were believers that silent casting and undefined behavior are the foundation of a good programming language.

We should talk. I work in a research group with a lot of simulation work going on, your perspectives on D for simulations could be useful to me. If you're interested, drop me an email: john dot loughran dot colvin at gmail dot com