June 2023 - GiNaC-list

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

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