[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-191-gf38cbcd
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via f38cbcd651246fb5c1294705d29399f3cbfddaf5 (commit) via feed241b95f7dbd6294795b4afc2bcae41880c31 (commit) from 71803f13294618ddd3f19fd0d9871cc44023c155 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit f38cbcd651246fb5c1294705d29399f3cbfddaf5 Author: Jens Vollinga <jensv@nikhef.nl> Date: Fri Jul 10 15:01:04 2009 +0200 Changed the parser such that it understands all defined functions including the user defined ones. To this end a method has been added to class function to allow the modified get_default_reader() function to build up a complete prototype table. The autogen tool is no longer required. commit feed241b95f7dbd6294795b4afc2bcae41880c31 Author: Jens Vollinga <jensv@nikhef.nl> Date: Fri Jul 10 09:54:09 2009 +0200 Fixed manual to correctly explain return_type_tinfo(). ----------------------------------------------------------------------- Summary of changes: INSTALL | 3 +- configure.ac | 4 -- doc/tutorial/ginac.texi | 63 ++++++++++++++++----------- ginac/Makefile.am | 18 +------- ginac/function.pl | 1 + ginac/parser/builtin_fcns.def | 90 --------------------------------------- ginac/parser/default_reader.tpl | 50 --------------------- ginac/parser/parse_context.cpp | 20 +++++++++ ginac/parser/parse_context.h | 21 +++------ ginac/parser/parser.cpp | 3 +- 10 files changed, 69 insertions(+), 204 deletions(-) delete mode 100644 ginac/parser/builtin_fcns.def delete mode 100644 ginac/parser/default_reader.tpl hooks/post-receive -- GiNaC -- a C++ library for symbolic computations
Hello, On Fri, Jul 10, 2009 at 03:06:46PM +0200, Jens Vollinga wrote:
commit f38cbcd651246fb5c1294705d29399f3cbfddaf5 Author: Jens Vollinga <jensv@nikhef.nl> Date: Fri Jul 10 15:01:04 2009 +0200
Changed the parser such that it understands all defined functions including the user defined ones.
And it does not understand pow, sqrt, power, and user defined classes any more :(
diff --git a/ginac/parser/parse_context.h b/ginac/parser/parse_context.h index 15dfcd6..c7360dd 100644 --- a/ginac/parser/parse_context.h +++ b/ginac/parser/parse_context.h @@ -72,25 +72,18 @@ typedef ex (*reader_func)(const exvector& args); * foo(x+y, z^2, t)), it looks up such a table to find out which * function (or class) corresponds to the given name and has the given * number of the arguments. - * - * N.B. - * - * 1. The function don't have to return a (GiNaC) function or class, it - * can return any expression. - * 2. Overloaded functions/ctors are paritally supported, i.e. there might - * be several functions with the same name, but they should take different - * number of arguments. - * 3. User can extend the parser via custom prototype tables. It's possible - * to read user defined classes, create abbreviations, etc. */ -typedef std::map<prototype, reader_func> prototype_table; +typedef std::map<prototype, unsigned> prototype_table;
This breaks existing code (both GiNaC and `user code') and is not welcome. It's impossible (or at least difficult) to extend the parser now (i.e. to read `user defined' classes). Please revert. Also I dislike the idea. Being able to define function in such a way that parser knows nothing about it is a good thing. It is useful to make sure that input does NOT contain certain (auxiliary) functions. Previously this was very easy: don't tell the parser about those functions, and that's it. Now parser understands every auxiliary function (which is not supposed to appear in input or output expressions) so extra checks are necessary. Although it's possible to make a custom parser table (start from the default one and erase unwanted functions from it) this requires more (boilerplate) code. Best regards, Alexei
Hi Alexei, Alexei Sheplyakov schrieb:
And it does not understand pow, sqrt, power, and user defined classes any more :(
fixed now.
This breaks existing code (both GiNaC and `user code') and is not welcome.
It is _very_ welcome by some people that had their existing code broken by your new parser. I got quite some nasty complains about it. Now, I see the problem that it breaks _your_ existing code, but when thinking about whether I should hurt the other people's code or introduce a different parser behavior I opted for the first option, because the parser as it was violated the basic assumption (not only that of the people that complained but also mine!) that the parser, without any tweaking, should just read any expression containing any functions and classes defined at that moment.
It's impossible (or at least difficult) to extend the parser now (i.e. to read `user defined' classes). Please revert.
I extended it accordingly. Now it should work. Feel free to test it, I might have overlooked some issues again. The hack is dirty but only intended for 1.5.x. For future branches we have to do something better. This still needs to be done sooner or later.
Also I dislike the idea. Being able to define function in such a way that parser knows nothing about it is a good thing. It is useful to make sure that input does NOT contain certain (auxiliary) functions. Previously this
Useful for what? Your preferences here are very particular, probably because you are not a regular GiNaC user but also a developer. A user shouldn't be forced to define his own reader just to get a simple expression read in (just look at that stupid boilerplate code http://www.ginac.de/pipermail/ginac-list/2009-June/001540.html )
was very easy: don't tell the parser about those functions, and that's it. Now parser understands every auxiliary function (which is not supposed to appear in input or output expressions) so extra checks are necessary.
You are still free to define your own reader for that special purpose.
Although it's possible to make a custom parser table (start from the default one and erase unwanted functions from it) this requires more (boilerplate) code.
Yeah, more boilerplate code, right, but now only people with special needs have to go through this hassle and not the average user anymore. Regards, Jens
Dear Jens, On Fri, Jul 31, 2009 at 01:07:37PM +0200, Jens Vollinga wrote:
because the parser as it was violated the basic assumption (not only that of the people that complained but also mine!) that the parser, without any tweaking, should just read any expression containing any functions and classes defined at that moment.
I think this assumption is bogus. Just because you've defined a (C++) type (class) doesn't mean you can print and/or parse objects of that type. Anyway, the old (bison-generated) parser never 'just read any expression containing any functions and classes defined at that moment' (actually it didn't handle any user defined classes at all).
A user shouldn't be forced to define his own reader just to get a simple expression read in
Making a type printable/readable (and/or serializable) always requires some boilerplate code.
Yeah, more boilerplate code, right, but now only people with special needs have to go through this hassle and not the average user anymore.
"A million lemmings can't be wrong"-alike arguments do nothing useful and make some people (including myself) very angry. Best regards, Alexei
--- On Mon, 8/3/09, Alexei Sheplyakov <varg@metalica.kh.ua> wrote:
From: Alexei Sheplyakov <varg@metalica.kh.ua> Subject: Re: [GiNaC-devel] Parser breakage changes To: "GiNaC development list" <ginac-devel@ginac.de> Date: Monday, August 3, 2009, 12:11 AM
[snip]
"A million lemmings can't be wrong"-alike arguments do nothing useful and make some people (including myself) very angry.
Best regards, Alexei
And/or, as I typically put it, in the middle ages the vast majority of people used to think the Earth was flat. Regards, Sergei.
Hi Alexei, Alexei Sheplyakov schrieb:
I think this assumption is bogus. Just because you've defined a (C++) type (class) doesn't mean you can print and/or parse objects of that type. Anyway, the old (bison-generated) parser never 'just read any expression containing any functions and classes defined at that moment' (actually it didn't handle any user defined classes at all).
nothing has changed here. If you write your own type you still have to add extra read-in code. Ah yes, my sentence should not have included the word "classes", but you know the source code anyway. It makes sense to add another function to GiNaC, something like "get_builtin_reader()" or so. This function should return a reader that only knows about the official GiNaC approved functions and classes. Do you want to do this? Otherwise I'll it as soon as I find time. Regards, Jens
Hi Jens, On Tue, Aug 04, 2009 at 01:23:30AM +0200, Jens Vollinga wrote:
It makes sense to add another function to GiNaC, something like "get_builtin_reader()" or so. This function should return a reader that only knows about the official GiNaC approved functions and classes. Do you want to do this?
Yes (as soon as I find time). But I'll omit some (most?) classes (indexed expressions, non-commutative products, etc), at least at the first step (at the moment the parser can't handle them anyway). Best regards, Alexei
Hi Alexei, Alexei Sheplyakov schrieb:
On Tue, Aug 04, 2009 at 01:23:30AM +0200, Jens Vollinga wrote:
It makes sense to add another function to GiNaC, something like "get_builtin_reader()" or so. This function should return a reader that only knows about the official GiNaC approved functions and classes. Do you want to do this?
sorry, maybe I should have written it more clearly: that "get_builtin_reader()" should just do what your old (1.5.2) "get_default_reader()" did. Then one has the choice between two built-in readers that should satisfy most demands. So, actually there is not much new coding, just adopting the old code to the new hacked way of doing it. Regards, Jens
participants (4)
-
Alexei Sheplyakov
-
git＠ginac.de
-
Jens Vollinga
-
Sergei Steshenko