Hi, is there any reason not to define the derivative of the built-in abs() function as either abs(x)/x or csgn(x) ? Currently it has not derivative defined at all. Regards, Jan
Dear Jan,
On Tue, 08 Apr 2014 20:19:47 +0200, Jan <jrheinlaender@gmx.de> said:
Jan> Hi, is there any reason not to define the derivative of the Jan> built-in abs() function as either abs(x)/x or csgn(x) ? Jan> Currently it has not derivative defined at all. You formula does not work for abs(f) and complex values. I have proposed here http://www.ginac.de/pipermail/ginac-devel/2013-November/002053.html another formula: (abs(f))'=(f'*f.conjugate()+f*f'.conjugate())/2/abs(f) It requires some revision of function class and new method of derivation going beyond the chain rule. I proposed to do this job, but do not remember my email to be answered. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv@maths.leeds.ac.uk www: http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://www.worldscientific.com/worldscibooks/10.1142/p835
Dear Vladimir,
You formula does not work for abs(f) and complex values. I have proposed here
http://www.ginac.de/pipermail/ginac-devel/2013-November/002053.html
another formula:
(abs(f))'=(f'*f.conjugate()+f*f'.conjugate())/2/abs(f)
It requires some revision of function class and new method of derivation going beyond the chain rule. I proposed to do this job, but do not remember my email to be answered.
Best wishes, Vladimir -- I hadn't thought of complex numbers, but then I'm not much of a mathematician anyway.
About the responsiveness of the list, I made the same experience. A while ago I volunteered to contribute some code, but nobody ever answered to my suggestions. Greetings, Jan
Hi, here are some simple patches to allow the current version (from git) of GiNaC to be compiled with MS Visual C++: 1. Fix problem with min() and max() macros in MSVC: --- a/ginac/compiler.h +++ b/ginac/compiler.h @@ -34,6 +34,8 @@ #ifdef _MSC_VER #define __func__ __FUNCTION__ #define __alignof__ __alignof +#define NOMINMAX +#include <algorithm> #endif #endif // ndef GINAC_COMPILER_DEP_H --- a/check/exam_cra.cpp +++ b/check/exam_cra.cpp @@ -21,6 +21,7 @@ */ #include "polynomial/cra_garner.h" +#include "../ginac/compiler.h" #include <cln/integer.h> #include <cln/integer_io.h> 2. Fix ambiguous overload of log() (MSVC is more exact here than gcc): --- a/check/exam_inifcns.cpp +++ b/check/exam_inifcns.cpp @@ -312,7 +312,7 @@ static unsigned inifcns_consist_log() // a bit more complicated ex e1 = log(-7*p*pow(q,3)*a*pow(b,2)*z*w).expand(expand_options::expand_transcendental); - ex e2 = log(7)+log(p)+log(pow(q,3))+log(-z*a*w*pow(b,2)); + ex e2 = log(7.0)+log(p)+log(pow(q,3))+log(-z*a*w*pow(b,2)); if (!e1.is_equal(e2)) ++result;
Hi, Jan, I'm afraid your patch is not quite correct. - ex e2 = log(7)+log(p)+log(pow(q,3))+log(-z*a*w*pow(b,2)); + ex e2 = log(7.0)+log(p)+log(pow(q,3))+log(-z*a*w*pow(b,2)); log(7) is an exact quantity, and log(7.0) is not (it's a floating point number). In general GiNaC does not apply numerical evaluation automatically. Could you please try replacing log(7) with log(ex(7))? Best regards, Alexei On Mon, May 25, 2015 at 3:32 PM, Jan Rheinländer <jrheinlaender@gmx.de> wrote:
Hi,
here are some simple patches to allow the current version (from git) of GiNaC to be compiled with MS Visual C++:
1. Fix problem with min() and max() macros in MSVC:
--- a/ginac/compiler.h +++ b/ginac/compiler.h @@ -34,6 +34,8 @@ #ifdef _MSC_VER #define __func__ __FUNCTION__ #define __alignof__ __alignof +#define NOMINMAX +#include <algorithm> #endif
#endif // ndef GINAC_COMPILER_DEP_H
--- a/check/exam_cra.cpp +++ b/check/exam_cra.cpp @@ -21,6 +21,7 @@ */
#include "polynomial/cra_garner.h" +#include "../ginac/compiler.h"
#include <cln/integer.h> #include <cln/integer_io.h>
2. Fix ambiguous overload of log() (MSVC is more exact here than gcc):
--- a/check/exam_inifcns.cpp +++ b/check/exam_inifcns.cpp @@ -312,7 +312,7 @@ static unsigned inifcns_consist_log()
// a bit more complicated ex e1 = log(-7*p*pow(q,3)*a*pow(b,2)*z*w).expand(expand_options::expand_transcendental); - ex e2 = log(7)+log(p)+log(pow(q,3))+log(-z*a*w*pow(b,2)); + ex e2 = log(7.0)+log(p)+log(pow(q,3))+log(-z*a*w*pow(b,2)); if (!e1.is_equal(e2)) ++result;
_______________________________________________ GiNaC-devel mailing list GiNaC-devel@ginac.de https://www.cebix.net/mailman/listinfo/ginac-devel
Just curious - isn't the piece in question C++ code ? If yes, isn't the RHS of type double or complex, i.e. of a floating point opposed to integer type. If yes, won't log(7) be automatically promoted to log(7.0) by the C++ compiler ? I.e. does "GiNaC does not apply numerical evaluation automatically" apply ? --Sergei. From: Alexei Sheplyakov <alexei.sheplyakov@gmail.com> To: GiNaC development list <ginac-devel@ginac.de> Sent: Wednesday, June 3, 2015 6:01 PM Subject: Re: [GiNaC-devel] Patches for compilation with MSVC Hi, Jan, I'm afraid your patch is not quite correct. - ex e2 = log(7)+log(p)+log(pow(q,3))+log(-z*a*w*pow(b,2)); + ex e2 = log(7.0)+log(p)+log(pow(q,3))+log(-z*a*w*pow(b,2)); log(7) is an exact quantity, and log(7.0) is not (it's a floating point number). In general GiNaC does not apply numerical evaluation automatically. Could you please try replacing log(7) with log(ex(7))? Best regards, Alexei On Mon, May 25, 2015 at 3:32 PM, Jan Rheinländer <jrheinlaender@gmx.de> wrote:
Hi,
here are some simple patches to allow the current version (from git) of GiNaC to be compiled with MS Visual C++:
1. Fix problem with min() and max() macros in MSVC:
--- a/ginac/compiler.h +++ b/ginac/compiler.h @@ -34,6 +34,8 @@ #ifdef _MSC_VER #define __func__ __FUNCTION__ #define __alignof__ __alignof +#define NOMINMAX +#include <algorithm> #endif
#endif // ndef GINAC_COMPILER_DEP_H
--- a/check/exam_cra.cpp +++ b/check/exam_cra.cpp @@ -21,6 +21,7 @@ */
#include "polynomial/cra_garner.h" +#include "../ginac/compiler.h"
#include <cln/integer.h> #include <cln/integer_io.h>
2. Fix ambiguous overload of log() (MSVC is more exact here than gcc):
--- a/check/exam_inifcns.cpp +++ b/check/exam_inifcns.cpp @@ -312,7 +312,7 @@ static unsigned inifcns_consist_log()
// a bit more complicated ex e1 = log(-7*p*pow(q,3)*a*pow(b,2)*z*w).expand(expand_options::expand_transcendental); - ex e2 = log(7)+log(p)+log(pow(q,3))+log(-z*a*w*pow(b,2)); + ex e2 = log(7.0)+log(p)+log(pow(q,3))+log(-z*a*w*pow(b,2)); if (!e1.is_equal(e2)) ++result;
_______________________________________________ GiNaC-devel mailing list GiNaC-devel@ginac.de https://www.cebix.net/mailman/listinfo/ginac-devel
_______________________________________________ GiNaC-devel mailing list GiNaC-devel@ginac.de https://www.cebix.net/mailman/listinfo/ginac-devel
Hi, On Wed, Jun 3, 2015 at 8:32 PM, Sergei Steshenko <sergstesh@yahoo.com> wrote:
Just curious - isn't the piece in question C++ code ?
If yes, isn't the RHS of type double or complex, i.e. of a floating point opposed to integer type.
It's neither integer nor floating point, it's a symbolic expression. Hope this helps, Alexei
Hi Alexei, yes of course, I wasn't thinking. log(ex(7)) is correct. Regards, Jan
Dear Jan,
On Tue, 08 Apr 2014 20:19:47 +0200, Jan <jrheinlaender@gmx.de> said:
Jan> Hi, is there any reason not to define the derivative of the Jan> built-in abs() function as either abs(x)/x or csgn(x) ? Jan> Currently it has not derivative defined at all. You formula does not work for abs(f) and complex values. I have proposed here http://www.ginac.de/pipermail/ginac-devel/2013-November/002053.html another formula: (abs(f))'=(f'*f.conjugate()+f*f'.conjugate())/2/abs(f) It requires some revision of function class and new method of derivation going beyond the chain rule. I proposed to do this job, but do not remember my email to be answered. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv@maths.leeds.ac.uk www: http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://www.worldscientific.com/worldscibooks/10.1142/p835
participants (5)
-
Alexei Sheplyakov
-
Jan
-
Jan Rheinländer
-
Sergei Steshenko
-
Vladimir V. Kisil