[GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-659-gfa1ffcfd
Alexey Sheplyakov
asheplyakov at yandex.ru
Wed Jun 17 22:27:33 CEST 2020
Vladimir,
17.06.2020, 22:58, "Vladimir V. Kisil" <v.kisil at leeds.ac.uk>:
> I think the statement 'no way to "patch" math' is too strong:
> there are many examples of such patches. Say, the singular integral of
> f(x)/(x-t) over the real line is divergent, but is meaningful (and
> useful) for "the Cauchy's principal value". Cesàro summation, Abel
> summation, and many others summations are examples of patches
> for divergent series.
Not really. They are *different* mathematical entities.
> (Not even speaking about examples like: 1+2+3+4+5+... = -1/12 .)
>
> Similarly it is quite legitimate (and useful in some circumstances) in
> some cases to regularise a piece-wise differential function by assigning
> the derivative to be the mean of the left and the right derivatives.
There's nothing wrong with that. As long as the user (not GiNaC) is in control
which definition is being used. So if the user asks for a plain derivative, and it
does not exist, GiNaC should prominently report that (throw an exception) instead
of trying to choose a different definition of the derivative to "fix" the problem.
It's OK to define an extra method (`regularised_diff', whatever).
But "smart" adjustments of plain `diff' are not OK.
Such "smartness" is the major reasons why I dislike "real" computer algebra systems.
> The possible argument is that sometimes this regularisation may be
> misleading (I do no have a sound example in my head for this but can
> admit it potential existence).
In high energy physics (the original domain of GiNaC) expressions (Green functions,
scattering amplitudes) are often divergent. I guess nothing will get wrong due to
"improved" abs.diff(). Until someone decides to "improve" tgamma(x) at x = 0
in a similar manner.
That said, these days (high energy) physics is a hobby for me.
I rarely compute Feynman diagrams, and I've got no deadlines.
So I don't care that much. If GiNaC will become too "flexible and smart" I can switch
to a different library (or even roll another one from the scratch).
Best regards,
Alexey
More information about the GiNaC-devel
mailing list