[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-659-gfa1ffcfd
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 fa1ffcfdc9da97a6fb7cc2c9c36fe1fc45c808a9 (commit) from 63453e8120d2e2eb9f1b836fc1b5651c2494ef1f (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 fa1ffcfdc9da97a6fb7cc2c9c36fe1fc45c808a9 Author: Pierangelo Masarati <pierangelo.masarati@polimi.it> Date: Wed Jun 17 19:52:49 2020 +0200 Improve diff(abs(x)) for real x. ----------------------------------------------------------------------- Summary of changes: ginac/inifcns.cpp | 2 ++ 1 file changed, 2 insertions(+) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations
Hello, 17.06.2020, 21:54, "Richard B. Kreckel via GiNaC-devel" <ginac-devel@ginac.de>:
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 fa1ffcfdc9da97a6fb7cc2c9c36fe1fc45c808a9 (commit) from 63453e8120d2e2eb9f1b836fc1b5651c2494ef1f (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 fa1ffcfdc9da97a6fb7cc2c9c36fe1fc45c808a9 Author: Pierangelo Masarati <pierangelo.masarati@polimi.it> Date: Wed Jun 17 19:52:49 2020 +0200
Improve diff(abs(x)) for real x.
I think this patch is wrong and should be reverted. diff(abs(x)) does not exist at x -> 0. Alternatively one can modify the definition of numeric::step() function [1] so it throws an exception when being evaluated at 0. [1] https://www.ginac.de/ginac.git/?p=ginac.git;a=blob;f=ginac/numeric.cpp;hb=HE... There's no way to "patch" math. Best regards, Alexey
Dear Alexey, 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 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. 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). Thus we may think about a mechanism which will allow a GiNaC's user to choose the behaviour diff(abs). Shall it be some global boolean variable or something smarter? Another question: shall it be rigidly linked to a user's choice for an alternative behaviour of step function (as can be derived from your suggestion): step(0) = 1/2 or step(0) = exception thrown. Thinking in this direction we can make GiNaC more flexible and useful. Best wishes, Vladimir -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/ Jupyter: https://github.com/vvkisil/MoebInv-notebooks
On Wed, 17 Jun 2020 22:13:26 +0400, Alexey Sheplyakov <asheplyakov@yandex.ru> said:
ASh> Hello, ASh> 17.06.2020, 21:54, "Richard B. Kreckel via GiNaC-devel" ASh> <ginac-devel@ginac.de>: >> 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 >> fa1ffcfdc9da97a6fb7cc2c9c36fe1fc45c808a9 (commit) from >> 63453e8120d2e2eb9f1b836fc1b5651c2494ef1f (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 fa1ffcfdc9da97a6fb7cc2c9c36fe1fc45c808a9 Author: >> Pierangelo Masarati <pierangelo.masarati@polimi.it> Date: Wed Jun >> 17 19:52:49 2020 +0200 >> >> Improve diff(abs(x)) for real x. ASh> I think this patch is wrong and should be reverted. ASh> diff(abs(x)) does not exist at x -> 0. Alternatively one can ASh> modify the definition of numeric::step() function [1] so it ASh> throws an exception when being evaluated at 0. ASh> [1] ASh> https://www.ginac.de/ginac.git/?p=ginac.git;a=blob;f=ginac/numeric.cpp;hb=HE... ASh> There's no way to "patch" math. ASh> Best regards, Alexey ASh> _______________________________________________ GiNaC-devel ASh> mailing list GiNaC-devel@ginac.de ASh> https://www.ginac.de/mailman/listinfo/ginac-devel
Vladimir, 17.06.2020, 22:58, "Vladimir V. Kisil" <v.kisil@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
Dear All, Alexey's proposition of an additional method for regularised derivative seems to be reasonable and shall not be difficult to implement. Actually we can have all of them: left_diff, right_diff and mean_diff. For many functions these will be the same as diff anyway. Best wishes, Vladimir -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/ Jupyter: https://github.com/vvkisil/MoebInv-notebooks
On Thu, 18 Jun 2020 00:27:33 +0400, Alexey Sheplyakov <asheplyakov@yandex.ru> said:
ASh> Vladimir, ASh> 17.06.2020, 22:58, "Vladimir V. Kisil" <v.kisil@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. ASh> 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. ASh> There's nothing wrong with that. As long as the user (not ASh> GiNaC) is in control which definition is being used. So if the ASh> user asks for a plain derivative, and it does not exist, GiNaC ASh> should prominently report that (throw an exception) instead of ASh> trying to choose a different definition of the derivative to ASh> "fix" the problem. It's OK to define an extra method ASh> (`regularised_diff', whatever). But "smart" adjustments of ASh> plain `diff' are not OK. ASh> Such "smartness" is the major reasons why I dislike "real" ASh> 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). ASh> In high energy physics (the original domain of GiNaC) ASh> expressions (Green functions, scattering amplitudes) are often ASh> divergent. I guess nothing will get wrong due to "improved" ASh> abs.diff(). Until someone decides to "improve" tgamma(x) at x = ASh> 0 in a similar manner. ASh> That said, these days (high energy) physics is a hobby for me. ASh> I rarely compute Feynman diagrams, and I've got no deadlines. ASh> So I don't care that much. If GiNaC will become too "flexible ASh> and smart" I can switch to a different library (or even roll ASh> another one from the scratch). ASh> Best regards, Alexey ASh> _______________________________________________ GiNaC-devel ASh> mailing list GiNaC-devel@ginac.de ASh> https://www.ginac.de/mailman/listinfo/ginac-devel
Hi! On 17.06.20 20:13, Alexey Sheplyakov wrote:
17.06.2020, 21:54, "Richard B. Kreckel via GiNaC-devel" <ginac-devel@ginac.de>:
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 fa1ffcfdc9da97a6fb7cc2c9c36fe1fc45c808a9 (commit) from 63453e8120d2e2eb9f1b836fc1b5651c2494ef1f (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 fa1ffcfdc9da97a6fb7cc2c9c36fe1fc45c808a9 Author: Pierangelo Masarati <pierangelo.masarati@polimi.it> Date: Wed Jun 17 19:52:49 2020 +0200
Improve diff(abs(x)) for real x.
I think this patch is wrong and should be reverted. diff(abs(x)) does not exist at x -> 0.
Hmm, I had read your remark [1] as consent. Without the patch, it evals |a|' → (a'*a)/|a| for real a. If, then, one substitutes a→0, then it throws division by zero. With the patch, it evals to a'*0. Okay, you do have a point. On the other hand, a later substitution of a variable by a special value is not always consistently handled; just consider x/x → 1 or variants thereof. How does that compare to our situation here?
Alternatively one can modify the definition of numeric::step() function [1] so it throws an exception when being evaluated at 0.
Well, remember that step(0)→½ is of course inspired from Fourier analysis and is tremendously useful in physics when doing contour integrals (principal value integration). Although this is not without alternatives [2], I'ld rather introduce another function than change step(). -richy. [1] https://www.ginac.de/pipermail/ginac-devel/2020-June/002464.html [2] https://en.wikipedia.org/wiki/Heaviside_step_function#Zero_argument
Hello! 18.06.2020, 01:40, "Richard B. Kreckel" <kreckel@in.terlu.de>:
Without the patch, it evals |a|' → (a'*a)/|a| for real a. If, then, one substitutes a→0, then it throws division by zero. With the patch, it evals to a'*0. Okay, you do have a point.
On the other hand, a later substitution of a variable by a special value is not always consistently handled; just consider x/x → 1 or variants thereof. How does that compare to our situation here?
Replacing x/x with 1 is OK in the sense of the limit when x -> 0. Being more strict would be nice. However that requires additional constraints on variables, and it's difficult to discover them in advance. The patch in question extends sloppiness even more. It replaces x/abs(x) with 1/2 when x -> 0 despite x/abs(x) having no limit at x -> 0. Best regards, Alexey
participants (4)
-
Alexey Sheplyakov
-
Richard B. Kreckel
-
Richard B. Kreckel
-
Vladimir V. Kisil