- GiNaC-list - ginac.de

Re: ginac parsing from string issue
by Richard B. Kreckel 10 Jul '06

10 Jul '06

Francesco Biscani wrote: >I'm using ginac 1.3.4 and trying to transform from std::string to ex. I'm >using the small test program present in the FAQ: > >--------------------------------------------------------- > #include <iostream> > #include <string> > #include <stdexcept> > #include <ginac/ginac.h> > using namespace std; > using namespace GiNaC; > > int main() > { > symbol x("x"); > string s; > > cout << "Enter an expression containing 'x': "; > getline(cin, s); > > try { > ex e(s, lst(x)); > cout << "The derivative of " << e << " with respect to x is "; > cout << e.diff(x) << ".\n"; > } catch (exception &p) { > cerr << p.what() << endl; > } > } >--------------------------------------------------------- > >The problem is that it does not work at all. Example output: > >Enter an expression containing 'x': 5+x >The derivative of x with respect to x is 1 > >I.e., "5+x" is parsed simply as x. With different expressions I get other >wierd errors, like: > >Enter an expression containing 'x': 5+3*x^2 >The derivative of 2 with respect to x is 0. > >syntax error, unexpected T_EOF, expecting ']' or ',' at > >As strange as it sounds, ginsh seems not to have these problems > >Type ?? for a list of help topics. > > >>diff(x^2+sin(x),x); >> >> >2*x+cos(x) > > >> >> >> > >I'm using gcc 4.1.1 on Gentoo. ginac was compiled with "-O2" c(xx)flag. > >Thanks very much for ginac! I'm writing an algebraic manipulator software for >Poisson series (celestial mechanics), and ginac would really help me >manipulate the series' coefficients (instead of writing some ad-hoc >representation for them). I hope this issue can be resolved. > > I'm unable to reproduce your problem using either Debian/testing (gcc 4.1.2-prerelease) or Debian/stable (gcc 3.3.5). Over here, it works as expected. I'm CCing ginac-list, maybe someone there has a similar system and can reproduce your problem? The behavior you describe sounds too weird to be true. I recommend first using another system or compiler version in order to get a clue where it is coming from. Luck -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

3 5

GiNaC and malloc()
by Igor Khavkine 28 Jun '06

28 Jun '06

I'm trying to use the GiNaC library as a drop-in replacement for the native floating point arithmetic between C types. Namely, I have code which #ifdef's between `typedef double dbl' and `typedef GiNaC::ex dbl', but keeps actual arithmetic expressions involving dbl's the same between the different preprocessor paths. The biggest problem I've run into is memory management. I need to allocate arrays of type dbl for caching purposes. Since, when not using GiNaC, the code has to work with a C compiler, I'm constrained to use malloc() for the allocation. If the GiNaC::ex class had an initialization routine that could be called on a block of memory, I would be extremely happy. Because then, I would be able to do something like: GiNaC::ex *expr; expr = malloc(sizeof(GiNaC::ex)); init_ex(expr); /* Or something similar. */ /* ... Use *expr as a properly constructed instance of GiNaC::ex... */ Since nothing that I could find in the library does what I'd like init_ex() to do, I tried different ways of implementing it myself. However, each of the following has prevented me from getting it to work: - GiNaC::ex overloads the = operator, which expectes the lhs to be properly constructed. - the GiNaC::ex constructor stores references to dynamically allocated memory which are freed by the destructor, therefore simply copying the class contents to another memory location is not safe. - GiNaC::ex, as far as I can tell, lacks a "duplicate" or "deep copy" routine. My current best solution, is something like: GiNaC::ex *expr, *expr_lost = new GiNaC::ex(); expr = malloc(sizeof(GiNaC::ex)); memcpy (expr, expr_lost, sizeof(GiNaC::ex)); Unfortunately, unless I take extra steps to keep track of memory pointed to by expr_lost, it gets leaked. If there is a Right Way (tm) or even just a better way to implement something like init_ex(), your advice would be much appreciated. Thanks in advance. Igor

2 3

Complexity bounds on expression expansion
by Federico Fernandez 12 May '06

12 May '06

Hi! I'm really new to the list, but I've been using GiNaC for 1 year aprox. in a scientific application. But now, we've to guarantee some bounds over the temporal complexity of some parts of the algorithm, and well, GiNaC is involved. In resume, we've to calculate the complexity bound (at least in a general manner) of some expressions expansion. The type of expresion is a sum of a_is, like a1 + a2 + ... + a_n, powered to the m-th. Is there any bound on the complexity of this operation in GiNaC? Thanks a lot!! Fede

2 1

[patch] fix template template declarations [GCC 4.2 compilation fix]
by varg＠theor.jinr.ru 11 May '06

11 May '06

Hello! The attached patch corrects template template declarations, so GiNaC can be compiled with G++ 4.2. Without this patch compilation fails, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=362220 for details. Note that `make check' still fails with G++ 4.2. Basically, ex e("-1 + 2*I", symbol()); triggers an exception. My patch *does not* fix this error. Best regards, Alexei. -- All science is either physics or stamp collecting.

2 4

Announcement: SyFi 0.3.0
by Kent-Andre Mardal 19 Apr '06

19 Apr '06

Dear GiNaC users, I would like to announce the 0.3.0 version of SyFi (syfi.sf.net) which is a finite element library based on GiNaC. At present, we have implemented several finite elements, like e.g., Lagrangian, Raviart-Thomas, and Nedelec elements of arbitrary order in both 2D and 3D. The latest release adds several examples with code generation which demonstrate the use of libraries like e.g. the Dolfin (www.fenics.org) PyCC (heim.ifi.uio.no/~skavhaug/heart_simulations.html) and Trilinos (software.sandia.gov/trilinos) The name SyFi stands for Symbolic Finite Elements. The package provides polygonal domains, polynomial spaces, and degrees of freedom as symbolic expressions that are easily manipulated. This makes it easy to define finite elements. SyFi is open source. Thanks for GiNaC!! Regards, Kent-Andre Mardal Simula Research Laboratory

1 0

GiNaC 1.3.4 released
by Jens Vollinga 13 Apr '06

13 Apr '06

Hi everybody, GiNaC 1.3.4 is out and available. The changes are: - More general index dimensions are now possible. - Improved algebraic substitutions. - Fixed wrong matching in .has(). - Fixed bug in differentiation of a power. - collect_common_factors also works with negative powers of common factors now. - Code clean-up and preparations for upcoming cln 1.2. As always, this release can be downloaded from http://www.ginac.de/Download.html Best wishes, Jens

1 0

Rot, div, grad operator will be implemented in feelfem FEM code generator
by Fujio Hidehiro 10 Apr '06

10 Apr '06

Dear GiNaC developers, This is Hidehiro Fujio of NEC Corp. Japan. At first, I would like to say thank you very much for your significant contribution to the formula manipulation area by GiNaC library in the world, and I also have to say that thank you very much for your link to my small document in the Related Software page. (My system is feelfem, an FEM code generator.) Yesterday, I met my supervisor, and got his advice. I wll expand my feelfem system to deal with 3D Maxwell equation, and introduce the differential operator 'rot' and 'div' and 'grad' (rotation, divergence, gradient, respectively), and my professors suggestion is it may be possible to expand these differential operators into just a set of basic differential operators (like dx,dy,dz) inside GiNaC. I would like to investigate your documentation agaian, and I would like to make a reort, how to make an FEM code generator by GiNaC. Again, thank you very much for GiNaC. And I'm afraid it is not an appropriate mail............ Best regards, Hidehiro Fujio # mail to both ( h-fujio(a)ab.jp.nec.com , oimo(a)world.email.ne.jp ,if needed)

2 1

[patch] small improvement of collect_common_factors
by varg＠theor.jinr.ru 04 Apr '06

04 Apr '06

Hello! This ginsh code snippet: collect_common_factors(x/y + z/y^2); returns the original expression unchanged: z*y^(-2)+x*y^(-1) The patch below makes it return (x+z*y^(-1))*y^(-1) Index: normal.cpp =================================================================== RCS file: /home/cvs/GiNaC/ginac/normal.cpp,v retrieving revision 1.94.2.8 diff -u -r1.94.2.8 normal.cpp --- normal.cpp 30 Jun 2005 14:03:16 -0000 1.94.2.8 +++ normal.cpp 10 Mar 2006 13:40:26 -0000 @@ -2388,6 +2388,8 @@ { if (exponent.info(info_flags::posint)) return power(basis.to_rational(repl), exponent); + else if (exponent.info(info_flags::negint)) + return power(replace_with_symbol(power(basis, _ex_1), repl), -exponent); else return replace_with_symbol(*this, repl); } Best regards, Alexei. -- All science is either physics or stamp collecting.

2 1

[[1]]!=1 ??
by Javier Ros Ganuza 18 Mar '06

18 Mar '06

I suppose that it is a feature... (matrix(3,1,lst(0,0,1)).transpose()*matrix(3,1,lst(0,0,1))).evalm() gives a 1,1 matrix [[1]]. To convert it to a number or to a expression not containing a matrix, I have to take directly the 0,0 element of the matrix. Is there a more direct method? If not I'm facing errors like (in ginsh notation) > a=[[0,0,1]]*[[0],[0],[1]]; > a=evalm(a); [[1]] > 1+cos(a); add::eval(): sum of non-commutative objects has non-zero numeric term Thank you Javier Ros

2 1

(no subject)
by Javier Ros Ganuza 09 Mar '06

09 Mar '06

Hello! :) When performing matrix multiplications expressions get expanded like in the following Example. Is there a way to avoid expansion, that is to leave the parenthesis Thanks Javier Ros Example: ----------------- matrix aux1 [[-d331*sin(q3)*dq3-d332*cos(q3)*dq3],[d331*cos(q3)*dq3-d332*sin(q3)*dq3],[0]] matrix R23 [[cos(q3),-sin(q3),0],[sin(q3),cos(q3),0],[0,0,1]] matrix R12.mul(aux1) [[d332*sin(q2)*sin(q3)*dq3-d331*cos(q2)*sin(q3)*dq3-d332*cos(q3)*cos(q2)*dq3-d331*sin(q2)*cos(q3)*dq3],[-d332*cos(q2)*sin(q3)*dq3-d331*sin(q2)*sin(q3)*dq3+d331*cos(q3)*cos(q2)*dq3-d332*sin(q2)*cos(q3)*dq3],[0]] ----------------- What I want is to obtain something like cos(q3)*(-d331*sin(q3)*dq3-d332*cos(q3)*dq3)+.... and so on for the first (0,0) matrix element.

3 4