Scientific computing and parallel computing C++23/C++26

bachmeier no at
Tue Jan 18 22:00:42 UTC 2022

On Tuesday, 18 January 2022 at 21:22:11 UTC, H. S. Teoh wrote:
> On Tue, Jan 18, 2022 at 08:28:52PM +0000, bachmeier via 
> Digitalmars-d wrote:
>> On Tuesday, 18 January 2022 at 17:03:33 UTC, sfp wrote:
>> > You must also consider that the items that bioinfornatics 
>> > listed are all somewhat contingent on each other. In 
>> > isolation they aren't nearly as useful. You might have a 
>> > numpy/scipy clone, but if you don't also have a matplotlib 
>> > clone (or some other means of doing data visualization from 
>> > D) their utility is a bit limited.
>> To my knowledge pyd still works. There's not much to be gained 
>> from rewriting a plotting library from scratch. It's not 
>> common that you're plotting 100 million times for each run of 
>> your program.
>> I see too much NIH syndrome here. If you can call another 
>> language, all you need to do is write convenience wrappers on 
>> top of the many thousands of hours of work done in that 
>> language. You can replace the pieces where it makes sense to 
>> do so. The goal of the D program is whatever analysis you're 
>> doing on top of those libraries, not the libraries themselves.
> [...]
> +1.  Why do we need to reinvent numpy/scipy? One of the 
> advantages conferred by D's metaprogramming capabilities is 
> easier integration with other languages.  Adam Ruppe's jni.d is 
> one prime example of how metaprogramming can abstract away the 
> nasty amounts of boilerplate you're otherwise forced to write 
> when interfacing with Java via JNI. D's C ABI compatibility 
> also means you can leverage the tons of C libraries out there 
> right now, instead of waiting for somebody to reinvent the same 
> libraries in D years down the road.  D's capabilities makes it 
> very amenable to being a "glue" language for interfacing with 
> other languages.

The next release of my embedr library (which I've been able to do 
now that my work life is finally returning to normal) will make 
it trivial to call D functions from R. What I mean by that is 
that you write a file of D functions and by the magic of 
metaprogramming, you don't need to write any boilerplate at all.


import mir.random;
import mir.random.variable;

RVector rngexample(int n) {
	auto gen = Random(unpredictableSeed);
	auto rv = uniformVar(-10, 10); // [-10, 10]
	auto result = RVector(n);
	foreach(ii; 0..n) {
		result[ii] = rv(gen);
	return result;

The only way you can do better is if someone else writes the 
program for you. But then it doesn't make much difference which 
language is used.

More information about the Digitalmars-d mailing list