dlangscience / scid Goto Github PK

scid is one of two projects causing a Jenkins CI failure for DMD (dlang/dmd#8241) and preventing us from moving forward with a deprecation. Looking through the code in scid's master branch, it appears the fix has already been made, but it needs to be tagged and released for DMD's CI to pick it up.

Hello!

I post here because this repository seems to be the only one watched by all people concerned with scid.

I want to add some modules containing scientific constants and coefficients for unit conversion.
The main difficulty is the names of the constants.

In my opinion names like "CONST_CGS_PLANCKS_CONSTANT_HBAR" are bulky and not convenient.
On the other hand, short names are less informative.

I would suggest the following:

1. Put information about the system of units to module name
2. Group similar constants like Planck's h and h with bar inside one enum, e.g. in CGS PLANCK.H = 6.6...e-27, PLANCK.HBAR = = 1.0...e-27
3. Uncertainty value (if any) should have the same name as the magnitude has with a special prefix/postfix (what should it be?)
4. Group constants in the following modules:
   • fundamental - universal constants like Planck's constant, speed of light, elementary charge etc. and combinations of them like fine-structure constant
   • additional - constants like Bohr radius that are not pure combination of fundamental constants (e.g. depend on mass of electron) but are usually not considered as characteristics of particles or unit conversion coefficients
   • particles - characteristics of elementary particles: masses, magnetic moments etc.
   • what else?
5. Add separate modules containing constants in different systems of units (SI, CGS, ...) i.e. the full module name would be scid.constants.cgs.fundamental
6. Add a module containing coefficients to convert magnitudes between different measuring units
   • The module would consist of enum's which names would be the names of units and members - values of the units in terms of other units e.g. METER.ANGSTROM = 1e+10

By the way, should the names of constants be in CAPITAL letters?

What do you think about this?

I have created the ScientificD "organisation" here on GitHub. I hope that, in time, it will become a nexus for D's scientific programming community, and a natural place to host code related to numerics and science – like D-Programming-Language is for the core language and D-Programming-Deimos is for C library bindings.

I don't have a clear opinion on how best to organise this, but I think it is a good idea if each library gets its own repository. That way someone can associate their library with ScientificD, yet have full control over the code that gets committed to it. Personally, I intend to split the current SciD into several libraries (one for quadrature, one for differentiation, one for nonlinear equations, etc.) and host them all at ScientificD.

Some functionality will most likely be useful for several libraries, yet still too niche for Phobos. For those things, a "core" repository should be made, upon which the other libraries can depend. (Of course, the maintainer(s) of such a library should be very careful about keeping backwards compatibility as much as possible, so they don't break a bunch of other libraries with a commit.)

Opinions, anyone? Ideas about organisation? Is the "one repo per library" idea a good one? If so, should there still be a common build system?

As it currently stands, the MatrixView struct in scid.matrix only provides the functionality to access elements with the opIndex and opIndexAssign overloaded operators.

It would be nice to have the arithmetic operators overloaded to provide elementwise operations. This would allow code like:

auto matrix_3 = 2 * matrix_1 - 1.5 * matrix_2^^2

Also I couldn't find any dot product for matrices. Following the nomenclature in std.numeric we could call this function dotProduct, so we could have code like:

auto Z = dotProduct(X, Y)

Is there any reason I overlooked why this has not been included? If it is just a lack of contributors, I'm already developing some of this stuff, and I will open a pull request so others can improve or point out possible errors in my code. When it is ready, it would be nice to merge it into the main repo.

...as soon as it actually gets included in Phobos, that is.

Thanks for sharing SciD, it looks like exactly what I would need! Unfortunately, I have been unable to compile/link a simple test example. I am not sure I got it right from installation to compilation/linking, though. I didn't find detailed instructions for those. Perhaps I did something wrong - this is what I did:

1. upgraded to dmd v2.066.1
2. built and installed https://github.com/9il/cblas, i.e.
   2.1 dub build => libcblas.a
   2.2. mv libcblas.a /usr/local/lib/ (where libphobos2.a lives for me)
3. built and installed scid, i.e.
   3.1 unzip, then cd source/scid/bindings/blas
   3.2 symlink to cblas.d: ln -s path/to/cblas-master/source/cblas/cblas.d
   3.3 rdmd build -O [switch -inline made compilation fail with errors]
   => generated/libscid.a
   => generated/headers/... (including source/scid/bindings/blas/cblas.di, so I am guessing cblas worked)
   3.4 mv generated/headers/source/scid /usr/local/include/dmd2/ (where phobos & druntime live)
   mv generated/libscid.a /usr/local/lib/ (where libphobos2.a lives)
   3.5 added flags "-I/usr/local/include/dmd2" and "-L/usr/local/lib" to DFLAGS in dmd.conf so that dmd finds /usr/local/include/dmd2/scid and the libraries.
4. In a source file main.d, used:
   import scid.linalg;
   import scid.matrix;
   ...
   auto m = matrix!double(2, 2);
   // filling it m[0,0]=1.0; etc.
   auto d = det(m);
5. compiled with:
   dmd -L-lscid -L-llapack main.d

But while dmd (or rather ld) clearly finds most symbols in libscid.a and liblapack it fails to find the following one:
Undefined symbols for architecture x86_64:
"_D4scid6linalg35__T4det_TdVE4scid6matrix7Storagei0Z4det_FS4scid6matrix68__T10MatrixViewTdVE4scid6matrix7Storagei0VE4scid6matrix8Trianglei85Z10MatrixViewZ3mulMFdZv", referenced from:
_D4scid6linalg35__T4det_TdVE4scid6matrix7Storagei0Z4det_FS4scid6matrix68__T10MatrixViewTdVE4scid6matrix7Storagei0VE4scid6matrix8Trianglei85Z10MatrixViewZd in main.o

In case that matters, I am on Mac OS X 10.9.5.
Many thanks for your help!

There is probably a case for the lapack bindings to exist independently of this package

If I understand correctly, the current build script hardcodes in dmd as the compiler. This is undesirable for a couple of reasons.

• gdc produces much faster code, so if you're in a position to compile with gdc this is preferable :-)
• Some Linux distros (e.g. Debian) have strict rules about proprietary dependencies; a reliance on dmd will block packaging of SciD. Of course, it's trivial to manually tweak the build script, but nicer to make it so they don't have to.
• ... related: it's not clear to me that the build script allows you to set optimization flags. This would be nice to have as well.

I see that invert is "Currently only defined for general real matrices". I don't have a good linear algebra intuition, and I can't see why the invert() function in linalg.d isn't capable of handling complex arguments. Everything I've seen suggests that ZGETRF and ZGETRI should invert a complex matrix. Is there something I'm missing?

dub test --compiler=ldc2 failed.

See https://travis-ci.org/9il/scid/jobs/46697648
or https://travis-ci.org/kyllingstad/scid/jobs/46697692

A couple of notes:

MatrixView has opIndex return by ref in order to allow array[i,j] op= v;. The should be done with opIndexOpAssign instead.

With the new extended semantics of opIndex and opSlice, a proper NDArray type can be implemented, with multi-dimensional slicing.

http://dlang.org/operatoroverloading.html

build pushes turned off?

This will allow people to use SciD in proprietary applications, while preventing them from releasing proprietary versions of the library itself.

Requested by Jordi Sayol. See issue #4 for details.

when running dub build --build=DSddox I get

Error: unterminated character constant
Error: unterminated character constant
Error: unterminated character constant
source/scid/calculus.d(1505): Warning: Ddoc: parameter count mismatch
source/scid/ports/minpack/dogleg.d(46): Warning: Ddoc: parameter count mismatch
source/scid/types.d(207): Warning: Ddoc: Stray '('. This may cause incorrect Ddoc output. Use $(LPAREN) instead for unpaired left parentheses.

Please update README after #22. I think few words about building with dub, Travis CI shield and link to the documentation http://ddocs.org/scid/latest/scid/functions.html can help users.

scid deb packages available on:

https://code.google.com/p/d-apt/wiki/APT_Repository#APT_Repository_for_D

"d-apt" is an ATP repository to easily install/upgrade D binary packages on systems like Debian, Ubuntu, Linuxmint, etc.

Enjoy it!

...because in that case, the return value of the function is never actually used. See line 102 of nonlinear.d.

See ldc-developers/ldc#820

SciD doesn't have any build in multidimensional minimization routines, which I (and probably others) could use. Because of this I recently wrote a library implementing differential evolution (BlackEdder/minimized). The API of this library is a bit simplistic, but it works. Would it be an idea to incorporate this into SciD? Maybe we should define a general interface for all minimization routines and have my library as one of the implementations?

interface Minimization(RANGE)
{
  RANGE minimize(size_t maxIterations); // Perform minimization
  void setFunction(double delegate(RANGE parameters) ; // Function to minimize
}