rust-GSL
rust-GSL copied to clipboard
GuillaumeGomez
multifit_solver example broken: covariance matrix must be square and match second dimension of jacobian
I am trying out the GSL bindings, and wanted to run/build the multifit_solver example. Right off the bat I am getting the following error (following the other stdout at the beginning). Any idea what's going on?
% cargo run --example multifit_solver
Finished dev [unoptimized + debuginfo] target(s) in 0.02s
Running `target/debug/examples/multifit_solver`
data: 0 6.01339 0.10000
data: 1 5.51538 0.10000
data: 2 5.26109 0.10000
data: 3 4.77746 0.10000
data: 4 4.45135 0.10000
data: 5 3.90490 0.10000
data: 6 3.50439 0.10000
data: 7 3.41500 0.10000
data: 8 3.24274 0.10000
data: 9 3.12220 0.10000
data: 10 2.83763 0.10000
data: 11 2.53470 0.10000
data: 12 2.43917 0.10000
data: 13 2.38083 0.10000
data: 14 2.31609 0.10000
data: 15 2.06083 0.10000
data: 16 1.94568 0.10000
data: 17 1.91413 0.10000
data: 18 1.75951 0.10000
data: 19 1.66507 0.10000
data: 20 1.73793 0.10000
data: 21 1.57552 0.10000
data: 22 1.52507 0.10000
data: 23 1.40961 0.10000
data: 24 1.39521 0.10000
data: 25 1.41689 0.10000
data: 26 1.37604 0.10000
data: 27 1.26095 0.10000
data: 28 1.28963 0.10000
data: 29 1.42267 0.10000
data: 30 1.22829 0.10000
data: 31 1.19918 0.10000
data: 32 1.18999 0.10000
data: 33 0.93008 0.10000
data: 34 1.22461 0.10000
data: 35 1.14738 0.10000
data: 36 1.11400 0.10000
data: 37 1.19512 0.10000
data: 38 1.26958 0.10000
data: 39 1.06198 0.10000
iter: 0 x = 1 0 0 |f(x)| = 117.34877131716345
status = Success
iter: 1 x = 1.6465626049841333 0.018145550177925462 0.6465626049841325 |f(x)| = 76.45936553723283
gsl: covar.c:52: ERROR: covariance matrix must be square and match second dimension of jacobian
Default GSL error handler invoked.
zsh: abort (core dumped) cargo run --example multifit_solver
This is what happens when printing covar and s.J() right before the call to rgsl::multifit::covar(&s.J(), 0f64, &mut covar):
covar: [0, 0, 0]
[0, 0, 0]
[0, 0, 0]
s.J(): [0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000015]
zsh: segmentation fault (core dumped) cargo run --example multifit_solver
Segfault on J.
That's surprising... I'll have to take a look and see what's failing.
In case it's relevant, I am on Arch Linux using gsl 2.5.
I also encountered an error with integration:
./integration
=== integration::qng ===
Result 1.8390715290764525 +/- 0.000000000009921183292055902 from 21 evaluations
=== IntegrationWorkspace.qag ===
gsl: src/types/integration.rs:3430: ERROR: a maximum of one iteration was insufficient
Default GSL error handler invoked.
zsh: abort (core dumped) ./integration
@GuillaumeGomez Did you solve this issue? I have the same problem with the example as well. And the optimization seems weird as well. It only run one iteration and then exit.
@GuillaumeGomez What is the version of gsl are you using? I am using gsl 2.4. Is that old? I saw the newest version is 2.6.
I removed GSL libs last time so I can't tell. Maybe it changed in the meantime in the repositories... If I have time and motivation, I'll try to take a look.
Don't hesitate to ping me in a month or so if you see no changes here. :)
Same problem here. The first, it makes only one iteration, because s.dx() is all zeros (but s.x() changes during the only iteration). The second, I see the same error about covariant matrix.
I use macOS and GSL 2.6.
Also I can reproduce it in rust Docker container (GSL 2.5) both on AMD64 and ARM64:
docker run --rm -ti rust:buster
apt update && apt install -y libgsl-dev
git clone https://github.com/GuillaumeGomez/rust-GSL && cd rust-GSL
cargo run --example multifit_solver
Can reproduce this also on Ubuntu 20.04 & GSL 2.5. That is, the s.iterate() loop stops after first iteration and dimensitons mismatch. I don't see any segfault error as described by SuperFluffy. For this example, J turns out to be 3x1 but GSL expects 1x3 I guess. While finishing during the first iteration as others described seems suspect, that shouldn't affect the shape of J, so we might be looking at more than one issue?
@SebastianSchafer see #82, we have UB here because of inconsistent binding with GSL 2.x