[GiNaC-list] Bug with evalm()?
correaa at berkeley.edu
Mon Feb 12 12:04:29 CET 2007
after all the difference between a expansion series and a polynomial
is basically that the series contains, at the end, some information
about the order of the error (i.e. O(x^n) )
In general, the error term, can not be evaluated to anything
meaningful (for x!=0) (but have some properties, for example can be
derived respect to x, or that O(x) - O(x) = O(x) -hey, just for
curiosity: can something like this be possibly ever implemented?-).
Because of the existence of the error term, in my opinion evalm must
either fail or evaluate to something that holds the error term in some
kind of new type (e.g. error_order type).
If to fail (i.e. throw) is the choice, the 'principle of less
surprise' can be honored by raising a meaningful exception (with some
I must admit that I have almost no experience with ginac and that I
don't fully understand the philosophy of the current developers, but,
in my opinion, making every method available (or evaluable) for every
type is not the way to solve this kind of problems because in many
cases the possible returns could be ambiguous depending on the
interpretation and this is more dangerous than throwing exception and
tell the user to be more specific in the syntax.
On 2/12/07, Chris Dams <Chris.Dams at mi.infn.it> wrote:
> Dear Alexei and others,
> On Mon, 12 Feb 2007, Sheplyakov Alexei wrote:
> > First of all, this violates principle of least surprise. For all other
> > classes map() operates on each term, why pseries should be different?
> Okay, then I think it is best to create a method pseries::evalm and have
> evalm act on every coefficient in the power series. The variable and
> expansion piont shoulnt' be matrix value anyway, as far as I know. Any
> objections against that?
> Best wishes,
> GiNaC-list mailing list
> GiNaC-list at ginac.de
More information about the GiNaC-list