Hi! May every GiNaC user and developer have a good 2004. Here's a patch from GiNaC's RSI-prevention department. Reason for the patch: creating a real symbol is such a common operation that it should be as simple as possible. regards, Chris
Hi. Thanks again for your last complex conjugation patch, Chris. It has made its way into GiNaC almost unchanged ;-) On Mon, Jan 05, 2004 at 05:59:44PM +0000, Chris Dams wrote:
Here's a patch from GiNaC's RSI-prevention department. Reason for the patch: creating a real symbol is such a common operation that it should be as simple as possible.
Now I am wondering, whether a new GiNaC class realsymbol derived from symbol would be the best solution? (realsymbol will be no registered GiNaC class, but simply inherits from symbol, realsymbol is a friend of symbol, only ctors have to be rewritten, therefore all type infos are the same, the domain parameter is not needed anymore ...) Then you could simply (still enough stress?) write realsymbol x("x") or ex r = 3 * realsymbol("x"); It looks good to me, but maybe there are important concerns (speed, style, ...) ?!? -> rsync "main GiNaC developers" In case that it is a not so good idea, the new patch you sent seems to be the best solution. Bye, Jens
Hello, On Mon, 5 Jan 2004, Jens Vollinga wrote:
Then you could simply (still enough stress?) write realsymbol x("x") or ex r = 3 * realsymbol("x");
Could also be done. I do not strongly prefer one possibility over the other.
It looks good to me, but maybe there are important concerns (speed, style, ...) ?!? -> rsync "main GiNaC developers"
If you have that a realsymbol inherits from a symbol and not give it its own tinfo, is_exactly_a<realsymbol> will be true for complex symbols. IMO this is counter-intuitive. Bye, Chris
participants (2)
-
Chris Dams
-
Jens Vollinga