On Sun, 3 Dec 2017 01:54:14 +0100, robens <robens@pa.msu.edu> said:
TR> thanks. Are there any efforts to change this ?? I think it might TR> be useful (in general) for future users/ developments/ etc My understanding: for automated simplifications GiNaC produces a large amount of dynamically created objects and they are internally indexed by consecutive numbers. If parts of an expression are transformed in parallel threads, then there will be inconsistency between different objects with the same index. This cannot be changed by gradual improvements, a significant part of code (and probably some ideology) need to be replaced in one move---an ambitious task requiring a dedicated (team of) developer(s). See also the thread of discussion started at: https://www.ginac.de/pipermail/ginac-list/2010-August/001719.html May be, certain algorithms can be written thread-safe through some kind of wrappers for GiNaC expressions, but their computational cost possibly absorbs all gain from multi-treading. -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/