- GiNaC-devel - ginac.de

Re: [GiNaC-list] Possible bug in algebraic substitution
by Vladimir V. Kisil 30 Aug '26

30 Aug '26

Dear Jan, Thank you for reporting the bug, I am attaching a patch which is fixing it. Best wishes, Vladimir -- Vladimir V. Kisil http://v-v-kisil.scienceontheweb.net Book: Geometry of Mobius Maps https://doi.org/10.1142/p835 Soft: Geometry of cycles http://moebinv.sourceforge.net/ Jupyter notebooks: https://github.com/vvkisil?tab=repositories >>>>> On Mon, 24 Aug 2026 18:37:23 +0200, Jan Rheinländer via GiNaC-list <ginac-list(a)ginac.de> said: JR> Hi, JR> maybe this is a bug, maybe combining "algebraic" and JR> "no_pattern" is just not allowed. Here is the program: JR> #include <iostream> #include <ginac.h> using namespace GiNaC; JR> int main() { symbol x("x"); symbol y("y"); symbol A("A"); ex JR> w(wild()); JR> exmap repl; repl[w] = A; ex expr(x/y + w); JR> ex result = expr.subs(repl, subs_options::algebraic | JR> subs_options::no_pattern); JR> std::cout << "Result: " << result << std::endl; JR> return 0; } JR> Expected output: x/y + A JR> Actual output: A/y + A JR> Apparently mul::algebraic_subs_mul() does not honour the JR> no_pattern flag. JR> ---------------- JR> The practical reason why this problem arose is to achieve JR> algebraic substitution in sums: JR> #include <iostream> #include <ginac.h> using namespace GiNaC; JR> int main() { symbol x("x"); symbol y("y"); symbol z("z"); symbol JR> A("A"); symbol B("B"); ex w(wild()); JR> exmap repl; repl[x + y + w] = A/B + w; JR> ex expr = x + y + z; JR> // Try to substitute x+y with A/B ex result = JR> expr.subs(repl, subs_options::algebraic); JR> std::cout << "Result: " << result << std::endl; JR> return 0; } JR> Expected output: A/B + z JR> Actual output: z/B + z JR> BTW, I noticed that expairseq::match() can do algebraic matching JR> in sums. Why can it not be implemented for add::subs(), too? JR> Regards, JR> Jan

1 0

Re: [GiNaC-list] Possible bug in algebraic substitution
by Vladimir V. Kisil 30 Aug '26

30 Aug '26

Dear Jan, Thank you for reporting the bug, I am attaching a patch which is fixing it. Best wishes, Vladimir -- Vladimir V. Kisil http://v-v-kisil.scienceontheweb.net Book: Geometry of Mobius Maps https://doi.org/10.1142/p835 Soft: Geometry of cycles http://moebinv.sourceforge.net/ Jupyter notebooks: https://github.com/vvkisil?tab=repositories >>>>> On Mon, 24 Aug 2026 18:37:23 +0200, Jan Rheinländer via GiNaC-list <ginac-list(a)ginac.de> said: JR> Hi, JR> maybe this is a bug, maybe combining "algebraic" and JR> "no_pattern" is just not allowed. Here is the program: JR> #include <iostream> #include <ginac.h> using namespace GiNaC; JR> int main() { symbol x("x"); symbol y("y"); symbol A("A"); ex JR> w(wild()); JR> exmap repl; repl[w] = A; ex expr(x/y + w); JR> ex result = expr.subs(repl, subs_options::algebraic | JR> subs_options::no_pattern); JR> std::cout << "Result: " << result << std::endl; JR> return 0; } JR> Expected output: x/y + A JR> Actual output: A/y + A JR> Apparently mul::algebraic_subs_mul() does not honour the JR> no_pattern flag. JR> ---------------- JR> The practical reason why this problem arose is to achieve JR> algebraic substitution in sums: JR> #include <iostream> #include <ginac.h> using namespace GiNaC; JR> int main() { symbol x("x"); symbol y("y"); symbol z("z"); symbol JR> A("A"); symbol B("B"); ex w(wild()); JR> exmap repl; repl[x + y + w] = A/B + w; JR> ex expr = x + y + z; JR> // Try to substitute x+y with A/B ex result = JR> expr.subs(repl, subs_options::algebraic); JR> std::cout << "Result: " << result << std::endl; JR> return 0; } JR> Expected output: A/B + z JR> Actual output: z/B + z JR> BTW, I noticed that expairseq::match() can do algebraic matching JR> in sums. Why can it not be implemented for add::subs(), too? JR> Regards, JR> Jan

1 0

Questions regarding decoupling the global state to allow independent execution contexts
by Patrick Jacobs 20 Feb '26

20 Feb '26

Hello! While a relatively new user of GiNaC, I've been following the long-standing discussions regarding multithreading and the inherent difficulties of implementing thread-safety in a library designed around global state and shared memory. Pardon my ignorance, as I am not yet fully versed on the library's internal implementation. I would like to ask a few conditional questions regarding the possibility of personally implementing a multi-state/context architecture for GiNaC. 1. Is it correct to say that the library currently relies on a single, global "environment" that acts as the sole gatekeeper for all symbolic state? Does this design effectively prevent multiple independent processes from referencing the library's logic (not process objects at runtime in the global thread; the actual GiNaC library) at the same time? 2. Is it possible to decouple the library's core algebraic logic from this singular global state? Could the library be structured so that its functions serve a context provided by the user, rather than relying on a hardcoded global one? 3. If the library were modified to support independent contexts could multiple such worlds coexist within the same program without interfering with one another? 4. Could this be implemented in a way where the current global state simply becomes a default context? Specifically, is it possible to ensure that users who do not need multiple contexts see no change in behavior or performance? 5. In a world of isolated contexts, how might we facilitate the "translation" or "importing" of an expression from one independent world into another? This may merely have to be copies of expressions, but that can be handled at the use-case level. 6. Where are the primary "anchors" of this global state located within the codebase? If I were to personally take on the challenge of implementing such a context-based architecture, what areas of the library should I study first? Again, I am not asking the GiNaC community to implement these changes. I am asking for guidance on whether this is even possible and, if so, how to possibly implement this myself. I believe that by permitting multiple independent instances of a state to exist, the multithreading problem can be solved through isolation rather than the complexity of locks. I appreciate you taking the time to read this. Patrick S. Jacobs

2 3

Primary repo moved to Codeberg.org
by Richard B. Kreckel 15 Feb '26

15 Feb '26

Hi! TL;DR: If you have cloned the GiNaC git repository, please do: $ git remote set-url origin https://codeberg.org/ginac/ginac.git So it's been decided to modernize the environment a bit... Several people have expressed interest in doing things with GiNaC and kindly suggested that it would be easier to have a fashionable forge-based workflow where they can clone the repository, make changes, send pull requests, etc. Another consideration was the ongoing surge of distributed AI scrapers aggressively crawling our Gitweb instance in millisecond intervals, blatantly ignoring robots.txt, and repeatedly overwhelming the poor server with web traffic. After having looked at several forge platforms, we (i.e. Bruno Haible and myself) have decided to move the primary repo of both GiNaC and CLN to Codeberg.org: <https://codeberg.org/ginac/ginac> Codeberg e.V. is a Berlin-based non-profit organization dedicated to build and maintain supporting infrastructure for the creation, collection, dissemination, and archiving of Free and Open Source Software. Their Forgejo software is a free git-based hosting platform with most of the bells and whistles known from GitHub, GitLab, etc. Modern hip hackers will feel right at home there! ;-) I've set us up as an Organization <https://codeberg.org/ginac/> hosting both the CLN and GiNaC repos. It should be pretty transparent. If you need something special, don't hesitate to contact me! Along the way, this acquits us from having to come up with lame excuses to the pesky question where our issue tracker is. It is now here: <https://codeberg.org/ginac/ginac/issues> For now, the web site <https://www.ginac.de/> and the mailing lists will remain as they are. Happy hacking! -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>

2 1

printing of class power
by Stefan Weinzierl 12 Feb '26

12 Feb '26

Dear all, happy new year to everybody and my apologies for coming up with a potential bug report shortly after a new release. The code snippet symbol x("x"); ex f = 2*x; ex g = pow(x,5); f.print(GiNaC::print_context(std::cout)); std::cout << std::endl; g.print(GiNaC::print_context(std::cout)); std::cout << std::endl; will print 2*x [power object] Is that really intentional? The behaviour is the same in GiNaC 1.8.7 and 1.8.8. Best wishes, Stefan

3 11

GiNaC 1.8.10 released
by Richard B. Kreckel 11 Feb '26

11 Feb '26

Hi, GiNaC 1.8.10 has been released. It includes a new class Gt for evaluating elliptic multiple polylogarithms with arbitrary arguments. (This is work by Claude Duhr, Florian Lorkowski, Robin Marzucca, Sofia Mauch, and Stefan Weinzierl.) The minimum C++ language standard level has been raised to C++14. This version is ABI-compatible to the previous version 1.8.9. Happy hacking! -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>

2 3

Compiler-dependent bug with nested lists
by Florian Lorkowski 09 Feb '26

09 Feb '26

Dear GiNaC developers, I noticed a strange bug, which only happens with some compiler versions. In some cases, nested lists collapse into a flat list. Consider the following program: > #include <iostream> > #include "ginac/ginac.h" > > using namespace GiNaC; > int main(int argc, const char** argv) { > std::cout << lst{lst{1}} << std::endl; > return 0; > } I tested this with GCC 11.4.0 and clang 21.1.0. With those compilers, it correctly prints > {{1}} But with clang 19.1.7, it instead yields > {1} I tested some other cases and it seems that the issue occurs whenever a list has a single element which is also a list. Best regards Florian

2 4

Re: [CLN-list] Re: Integer hash collision
by Richard B. Kreckel 28 Nov '25

28 Nov '25

Hi Florian, The idea is indeed to specialize std::hash<GiNaC::ex> around ex::gethash() which falls back to CLN's hashes for objects of numeric type. Is there anything wrong with this simple approach? Is it that size_t return value which is 64 bit on modern systems so that the 32 most significant bits remain unused? (How big do you expect your hash maps to get?) Have a look at ginac/hash_map.h remembering that std::unordered_map<> is basically a hash map! All my best, -richard. PS: CC'ing to the ginac-devel list. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/> On 11/27/25 9:23 AM, Florian Lorkowski wrote: > Dear Bruno, > > thank you for the detailed explanation. > > We were working on an algorithm that caches composite objects in GiNaC > by their hash value. We will implement a system to handle hash > collisions. In the long run this is safer anyway. Had we not caught this > issue at this stage, we might have run into some really hard to > investigate bugs later on. > > Best regards > Florian

1 0

Add methods constant::get_name
by Vladimir V. Kisil 14 Jul '25

14 Jul '25

Dear All, Following the suggestion https://lists.ginac.de/archives/list/ginac-list@ginac.de/thread/6HSODYN2NJT… and implementing the existing policy "constants behave pretty much like symbols" I am attaching a micro patch adding constant::get_name() and constant::get_TeX_name() methods. Best wishes, Vladimir -- Vladimir V. Kisil http://v-v-kisil.scienceontheweb.net Book: Geometry of Mobius Maps https://doi.org/10.1142/p835 Soft: Geometry of cycles http://moebinv.sourceforge.net/ Jupyter notebooks: https://github.com/vvkisil?tab=repositories

1 0

GiNaC::function resolution in tutorial
by Vladimir V. Kisil 03 Jul '25

03 Jul '25

Hello, Here is a tutorial's small patch addressing the issue pointed out by Warren Weckesser in https://lists.ginac.de/archives/list/ginac-list@ginac.de/thread/IPVLGB2E6ZC… Best wishes, Vladimir -- Vladimir V. Kisil http://v-v-kisil.scienceontheweb.net Book: Geometry of Mobius Maps https://doi.org/10.1142/p835 Soft: Geometry of cycles http://moebinv.sourceforge.net/ Jupyter notebooks: https://github.com/vvkisil?tab=repositories

1 0