- GiNaC-list - ginac.de

bug in ex::ex(const std::string&, const ex&)
by Diego Conti 05 Apr '24

05 Apr '24

Hi, I think there is a bug in the functions that convert strings to ex. I attach a minimal program that segfaults on my machine. I am using gcc 13.2.0 on Ubuntu 23.10, x86_64, CPU Intel i9-12900H. The problem only arises if I compile GiNaC using the CMake script. The same program works if I compile with configure && make. The problem appears to be in parser/default_reader.cpp, where conversions between pointers to functions and integers are used. The code assumes that the integer underlylng a pointer to function is even, relying on the fact that functions are aligned; this latter condition appears to fail on my system when compiling with CMake. Indeed, inserting a pragma command inside parser/default_reader.cpp (see attached patch) fixes the problem. I do not know if this can be made portable across compilers; maybe it would be easier to modify the code by replacing reader_func with a class that handles the conversion in a type-safe way? Diego Conti

3 5

Can GiNaC Solve Nonlinear Equations?
by Marius Einstein 10 Feb '24

10 Feb '24

Hi! I am solving a problem that requires to solve nonlinear equations like {x1^2+x2^2=u1, x1+x2=u2}. Can GiNaC solve nonlinear equations like this? Thanks, Erick Farestveit

2 1

Usage of designated initializer in factor.cpp forces c++20 on GiNaC
by Igor Machado 28 Oct '23

28 Oct '23

Dear all, congratulations for this amazing software. I was struggling a little bit to make it work in CMake, with many linking errors in windows (for linux it was easy, but I need both working) so I recently created a simple Bazel build file for the projects CLN and GINAC, to debug the error. In the end, I managed to find and fix the error, so I wanted you to know that the file factor.cpp from GiNaC is using designated initializers, which is only part of c++20... and when I activated c++20 here, the linking was broken on windows! So, a solution was to change (around line 2344): factorization_ctx ctx = {.poly = poly, .x = x, .syms_wox = syms_wox}; And transform into this: factorization_ctx ctx{poly, x, syms_wox}; After that, I can enable c++17 and it works on GCC, Clang and MSVC! For GCC and Clang, they don't complain on designated initializers, even if it's c++17 standard... So, since it's the only thing from c++20, you should consider if it's work activating a whole new standard just because of this, or to consider that the project is already c++20. I personally love c++20, but it's important to notice that some fundamental things change... for example, I just discovered that the code works in c++20 in windows, but with /permissive flag, otherwise it gives crazy LNK2019 linking errors. I believe some ABI has changed after c++17, but it was hard to understand and fix the error. So, best regards and I hope this information is useful! Igor

2 2

Polynomial Zeros
by Charles White 11 Oct '23

11 Oct '23

Hi GiNaC! Is there a built-in method to find all zeros of a polynomial? I'm trying to find symbolic zeros if possible and numeric zeros for all other cases. Thanks! Charles

3 2

series((x+x^2)^2,x,0) is broken
by Vitaly Magerya 15 Aug '23

15 Aug '23

Hi, all. I'm trying to expand expressions into series, and I've run into a case which looks broken (with the latest GiNaC): ginsh> series((x+x^2)^2,x,0); (Order(1)^2)*x^(-2)+Order(1) What I expect is Order(1) here, because the expression starts at O(x^2). Same problem with e.g. (x+sin(x))^2, and lots of other expressions. It seems that any non-trivial expression that starts at O(x) or higher to a power expands into this sort of an unhelpful result. Note that trying to remove the Order() parts does not work: ginsh> series_to_poly(series((x+x^2)^2,x,0)); x^(-2)*Order(1)^2 What I expect here is "0" instead. Any ideas on what's going on and how to fix it?

3 19

GiNaC 1.8.7 released
by Richard B. Kreckel 12 Aug '23

12 Aug '23

Hi, GiNaC 1.8.7 has been released. Here're the news: * Fix series expansion of polynomial(x)^n for small and large n. Previously, this could return two Order terms or an Order term even though the series was terminating at a lower order. * Fix bugs in internal parser from strings. The operator precedence of the internal parser was inconsistent and has now been harmonized with that of ginsh. * Make ginsh evaluate line-by-line in non-interactive mode. This helps programs invoking ginsh as a sub-program. * Several build fixes. Happy hacking! -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>

1 0

Floating to Rational
by Charles White 19 Jul '23

19 Jul '23

Hi GiNaC! Is there a way to convert floating point numbers to rational numbers? And, expressions with floating point numbers to expressions with rational numbers? wxmaxima has the function "rationalize"; I did notice there is a rationalize <https://www.ginac.de/CLN/cln.html#Conversion-to-rational-numbers> function in the CLN library; is that what I should work with? Thanks! Charles

2 2

linking problem using Cygwin + cl compiler
by Piotr 26 Jun '23

26 Jun '23

Hello, I am trying to compile ginac and cln on Windows. For compilation I used Cygwin env, cl compiler (MSVC v142). Version I use: -cln 1.3.6 -ginac 1.8.6, but with this fix: I following this instruction mainly: https://ooo-imath.sourceforge.io/wiki/index.php/Compiling_under_Windows Cln is compiled successfully. For GINAC compilation I have some errors not desribed in instruction above: 1. ./configure required: /std:c++20 parameter as it is complaining during compilation 2. symbol differences that I am not able to solve. They are related to Cln: ginac.lib(libginac_la-numeric.obj) : error LNK2019: nierozpoznany symbol zewnętrzny "struct cln::cl_heap_string * __cdecl cl_make_heap_string(char const *)" (?cl_make_heap_string@@YAPEAUcl_heap_string@cln@@PEBD@Z) przywołany w funkcji "public: __cdecl cln::cl_string::cl_string(char const *)" (??0cl_string@cln@@QEAA@PEBD@Z) Wskazówki dla symboli, które są zdefiniowane i mogą potencjalnie pasować: "struct cln::cl_heap_string * __cdecl cln::cl_make_heap_string(char const *)" (?cl_make_heap_string@cln@@YAPEAUcl_heap_string@1@PEBD@Z) .libs\viewgar.exe : fatal error LNK1120: liczba nierozpoznanych elementów zewnętrznych: 1 It can be seen that both symbols differs only with class prefix at the beginning ::cln (it is in existing symbol in cln lib but not in looked one in ginac) Do anybody knows how to solve this link issue? Thank you in advance, Best regards, Piotr -- Ta wiadomość e-mail została sprawdzona pod kątem wirusów przez oprogramowanie antywirusowe Avast. www.avast.com

1 0

Making ginsh interactive when the input is not a TTY
by Vitaly Magerya 21 Jun '23

21 Jun '23

Hi, all. I've been trying to use ginsh as a subprocess: send some input to it, have it evaluate it, read the result back, repeat. I've found that this is impossible: in ginsh/ginsh_lexer.lpp:161 if yy_is_interactive (=isatty(0)) is false, ginsh uses fread() to read the input, which means it will not stop after end of the line -- it will instead wait until the whole buffer is filled, and will only proceed to parse and evaluate afterwards. This means I can not send "1+2\n" and expect an answer, ginsh will wait for more input. This of course is unlike the interactive mode (yy_is_interactive == 1), where the input is read character-by-character until the end of line. So, basically, I'd like ginsh to use the interactive(-ish) mode even when the input stream is not a TTY. Now, just forcing yy_is_interactive to 1 will work, but is not a good solution: the interactive mode prints the prompt after each line, so using it when the input stream is not a TTY will break backward compatibility. Instead, something like this will work for me: diff --git a/ginsh/ginsh_lexer.lpp b/ginsh/ginsh_lexer.lpp index 8692b1ac..a8d571dd 100644 --- a/ginsh/ginsh_lexer.lpp +++ b/ginsh/ginsh_lexer.lpp @@ -203,9 +203,16 @@ static int ginsh_input(char *buf, int max_size) YY_FATAL_ERROR("input in flex scanner failed"); result = n; #endif - } else if (((result = fread(buf, 1, max_size, yyin)) == 0) && ferror(yyin)) - YY_FATAL_ERROR("input in flex scanner failed"); - + } else { + int c = '*', n; + for (n = 0; n < max_size && (c = getc(yyin)) != EOF && c != '\n'; ++n) + buf[n] = (char)c; + if (c == '\n') + buf[n++] = (char)c; + if (c == EOF && ferror(yyin)) + YY_FATAL_ERROR("input in flex scanner failed"); + result = n; + } return result; } This will preserve backward compatibility. There is however a concern that such a change will affect the parsing performance, so I've run tests: when evaluating some of my multi-MB expression files with mixed arithmetic, there is no statistically visible performance difference. For a synthetic test of a product of 10^6 of single-digit numbers with 6 white-space characters per digit per -- no change. For a sum of 10^6 single-digit integers with 6 spaces per integer I see a 9% runtime regression; if the whitespace is removed, the regression disappears. In short, I think the performance impact in practice is zero. Can I ask for this change to be applied?

2 3

Re: [GiNaC-list] GiNaC::parser parses unary operators in the wrong order
by Vitaly Magerya 20 Jun '23

20 Jun '23

On 20/02/2023, I wrote: > Hi, all. When parsing expressions with sign in the exponent, GiNaC's > parses confuses the priorities somehow. Here are some examples: > > 3^2+1 is parsed as (3^2)+1, which is correct; > 3^+2+1 is parsed as 3^(+2+1), which is wrong; > 3^-2+1 is parsed as 3^(-2+1), which is wrong; > 3^+2/3 is parsed as 3^(+2/3), which is wrong; > etc. So after some more testing I found that GiNaC doesn't only misparse the exponentiation this way, but multiplication too. Things like "3*+2+1" are parsed wrong too. The handling of the unary operators is broken if they appear after other operators. As a separate problem, parsing nested exponentiation, like "2^3^4", results in GiNaC throwing an exception, saying that "power should have exactly 2 operands", which is false: for example ginsh handles "2^3^4" easily and correctly. So, with some work I was able to fix both of these problems. I'm attaching a proposed solution, with tests included. Would it be possible to commit this? I would additionally like to request a point release after this fix; this parsing problem potentially affects our usage of GiNaC, and we'd rather stay with a release version than build our own release tarballs.

2 1