Many thanks to everyone, it turns out this was a false alarm.
The whole issue arose because a collaborator could not independently
reproduce some of my results. I just converted my own code to use a single
workspace and all results stay the same. Also, I asked the colleague to
take his fixed code and convert it back to use a single workspace, and the
earlier discrepancies were not reproduced. This must have been some human
error in the testing, possibly more changed in that code than the extra
workspace allocations.
Anyway, explicit confirmation that the workspace is reusable was very
useful. Not to mention that it is cleared by the gsl routines upon each
call. It would probably be helpful to include this information in the
manual (or have we missed it?).
Best regards, and thanks again,
Denes
Email from Rhys Ulerich on Dec 1, 2011 at 5:33pm:
Hi Denes,
Unfortunately our 'test' code is 400-500 lines. We may be able to reduce it
in the coming weeks. Apart from all the bells and whistles, the original
code allocated a single workspace and then used that in a loop to compute
billions of integrals (calls to gsl_integration_qags()) with stochastic
parameters. The results were really strange (and wrong) until we changed the
code to allocate a workspace for every single integration.
Any chance your test code is overwriting memory in places where it
shouldn't? If it trampled the gsl_integration_workspace I'd expect
similar behavior which might be resolved by allocating new workspaces
all the time. What does valgrind say? Do you see identical (or
identically strange) results across different compiler versions or
optimization levels?
400-500 lines isn't ideal but it'd be usable if you can reproduce the
issue with O(2) iterations instead of billions.
- Rhys
_______________________________________________
Help-gsl mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-gsl
