Dear GiNaC developer, I'm using GiNaC version 1.6.2 with compiler gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2 When working with the parser to read in user defined functions from strings I noticed 3 things: 1) parsing a user defined function (declared to have 1 argument) from a string does not throw an exception when the string contains this function with zero arguments. 2) parsing products of user defined non-commutative functions returns a commutative product 3) The parser accepts userdefined functions with zero arguments and parsing such a function does not throw when there is 1 argument. I have attached a small file "main.cpp" such that you can reproduce this behavior. I'm using these user defined functions with zero arguments but it looks to me like a hack and I would like to know if you are going to allow them ( e.g. with macro definition) or if you completely suppress them in future releases of GiNaC. Thank you very much! Cedric Studerus
Hello, On Sun, Dec 04, 2011 at 12:59:53PM +0100, Cedric Studerus wrote:
When working with the parser to read in user defined functions from strings I noticed 3 things:
1) parsing a user defined function (declared to have 1 argument) from a string does not throw an exception when the string contains this function with zero arguments.
This looks like a bug.
2) parsing products of user defined non-commutative functions returns a commutative product
Built-in GiNaC parser does not handle non-commutative products. You can either 1) Transform all non-commutative products into some dummy function(s), and explain the parser how to handle them (i.e. define and set the custom prototype table). 2) Use the archiving facility to (de)serialize expressions.
3) The parser accepts userdefined functions with zero arguments and parsing such a function does not throw when there is 1 argument.
I have attached a small file "main.cpp" such that you can reproduce this behavior.
I'm using these user defined functions with zero arguments but it looks to me like a hack and I would like to know if you are going to allow them ( e.g. with macro definition) or if you completely suppress them in future releases of GiNaC.
Zero-argument functions sound a bit strange (why don't you use symbols instead?), and I doubt we actually support them (they might work by accident). I don't think we will disable defining zero-arguments functions on purpose: preventing users from doing silly things typically prevents them from doing smart things, too. However I doubt zero-argument functions will be supported properly (unless someone sends a patch). Best regards, Alexei
participants (2)
-
Alexei Sheplyakov
-
Cedric Studerus