Hi, I discovered that clifford_moebius_map() function was ignorant of representative labels for Clifford numbers, which generates misbehaviour. I include the cumulative patch which this issue along with the previous one. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv@maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/ Index: doc/tutorial/ginac.texi =================================================================== RCS file: /home/cvs/GiNaC/doc/tutorial/ginac.texi,v retrieving revision 1.159 diff -r1.159 ginac.texi 3179,3180c3179,3181 < @samp{e~i e~j + e~j e~i = B(i, j)} for some symmetric matrix (@code{metric}) < @math{B(i, j)}. Such generators are created by the function ---
@samp{e~i e~j + e~j e~i = B(i, j)} for some matrix (@code{metric}) @math{B(i, j)}, which may be non-symmetric. Such generators are created by the function 3194a3196,3204 If the matrix @math{B(i, j)} is in fact symmetric you may prefer to create the Clifford algebra units with a call like that
@example ex e = clifford_unit(mu, indexed(B, sy_symm(), i, j)); @end example
since this may yield some further automatic simplifications.
3336c3346,3347 < const ex & d, const ex & v, const ex & G); ---
const ex & d, const ex & v, const ex & G, unsigned char rl = 0); ex clifford_moebius_map(const ex & M, const ex & v, const ex & G, unsigned char rl = 0);
3341c3352 < (av+b)/(cv+d)} defined by the matrix @samp{[[a, b], [c, d]]}. The last ---
(av+b)/(cv+d)} defined by the matrix @samp{M = [[a, b], [c, d]]}. The Index: ginac/clifford.h =================================================================== RCS file: /home/cvs/GiNaC/ginac/clifford.h,v retrieving revision 1.53 diff -r1.53 clifford.h 318,319c318,320 < * @param G Metric of the surrounding space */ < ex clifford_moebius_map(const ex & a, const ex & b, const ex & c, const ex & d, const ex & v, const ex & G);
* @param G Metric of the surrounding space * @param rl Representation label*/ ex clifford_moebius_map(const ex & a, const ex & b, const ex & c, const ex & d, const ex & v, const ex & G, unsigned char rl = 0); 326,327c327,329 < * @param G Metric of the surrounding space */ < ex clifford_moebius_map(const ex & M, const ex & v, const ex & G);
* @param G Metric of the surrounding space * @param rl Representation label*/ ex clifford_moebius_map(const ex & M, const ex & v, const ex & G, unsigned char rl = 0); Index: ginac/clifford.cpp =================================================================== RCS file: /home/cvs/GiNaC/ginac/clifford.cpp,v retrieving revision 1.82 diff -r1.82 clifford.cpp 1163c1163 < ex clifford_moebius_map(const ex & a, const ex & b, const ex & c, const ex & d, const ex & v, const ex & G)
ex clifford_moebius_map(const ex & a, const ex & b, const ex & c, const ex & d, const ex & v, const ex & G, unsigned char rl) 1178c1178 < x = lst_to_clifford(v, mu, G);
x = lst_to_clifford(v, mu, G, rl); 1184c1184 < ex clifford_moebius_map(const ex & M, const ex & v, const ex & G)
ex clifford_moebius_map(const ex & M, const ex & v, const ex & G,unsigned char rl) 1188c1188 < ex_to<matrix>(M)(1,0), ex_to<matrix>(M)(1,1), v, G);
ex_to<matrix>(M)(1,0), ex_to<matrix>(M)(1,1), v, G, rl);
Dear Vladimir, On Mon, 7 Feb 2005, Vladimir Kisil wrote:
I discovered that clifford_moebius_map() function was ignorant of representative labels for Clifford numbers, which generates misbehaviour. I include the cumulative patch which this issue along with the previous one.
Your patch introduces an additional integer parameter to the two free functions GiNaC::clifford_moebius_map(..). As such, it changes the signature of the two functions and also the mangled name, rendering the library binary-incompatible. For this reason, your patch cannot be applied to the GiNaC-1.3 tree, where we strive for binary compatibility. It can, however, be applied to the GiNaC-1.4 tree, where binary compatibility to GiaC-1.3 is not a goal. Notice, that the additional integer parameter is really part of the mangled name and there is only one mangled name. The default value is inserted by the compiler, not the linker. You can, however, prepare another equivalent patch for inclusion in the GiNaC-1.3 tree by providing an additional function that has the additional parameter (without default). That would just add another signature, and not break binary compatibility. The library would then provide both the function ex clifford_moebius_map(const ex&, const ex&, const ex&, const ex&, const ex&, const ex&) as well as ex clifford_moebius_map(const ex&, const ex&, const ex&, const ex&, const ex&, const ex&, unsigned char) and similar for the other signature. Internally, you may implement the first function by delegating to the second function, if that is what you want to do. If you agree, could you send such a patch to the list, please? Best wishes -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi, I afraid that did not understand everything from the Richard email (since my programming skill are very weak) but here is the new patch. How could I know when v1.4 is out in order to revert to the first more natural solution? Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv@maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/ Index: doc/tutorial/ginac.texi =================================================================== RCS file: /home/cvs/GiNaC/doc/tutorial/ginac.texi,v retrieving revision 1.159 diff -r1.159 ginac.texi 3179,3180c3179,3181 < @samp{e~i e~j + e~j e~i = B(i, j)} for some symmetric matrix (@code{metric}) < @math{B(i, j)}. Such generators are created by the function ---
@samp{e~i e~j + e~j e~i = B(i, j)} for some matrix (@code{metric}) @math{B(i, j)}, which may be non-symmetric. Such generators are created by the function 3194a3196,3204 If the matrix @math{B(i, j)} is in fact symmetric you may prefer to create the Clifford algebra units with a call like that
@example ex e = clifford_unit(mu, indexed(B, sy_symm(), i, j)); @end example
since this may yield some further automatic simplifications.
3336c3346,3347 < const ex & d, const ex & v, const ex & G); ---
const ex & d, const ex & v, const ex & G, unsigned char rl = 0); ex clifford_moebius_map(const ex & M, const ex & v, const ex & G, unsigned char rl = 0);
3341c3352 < (av+b)/(cv+d)} defined by the matrix @samp{[[a, b], [c, d]]}. The last ---
(av+b)/(cv+d)} defined by the matrix @samp{M = [[a, b], [c, d]]}. The Index: ginac/clifford.h =================================================================== RCS file: /home/cvs/GiNaC/ginac/clifford.h,v retrieving revision 1.53 diff -r1.53 clifford.h 318c318,320 < * @param G Metric of the surrounding space */
* @param G Metric of the surrounding space * @param rl Representation label*/ ex clifford_moebius_map(const ex & a, const ex & b, const ex & c, const ex & d, const ex & v, const ex & G, unsigned char rl); 326c328,330 < * @param G Metric of the surrounding space */
* @param G Metric of the surrounding space * @param rl Representation label*/ ex clifford_moebius_map(const ex & M, const ex & v, const ex & G, unsigned char rl); Index: ginac/clifford.cpp =================================================================== RCS file: /home/cvs/GiNaC/ginac/clifford.cpp,v retrieving revision 1.82 diff -r1.82 clifford.cpp 1163c1163 < ex clifford_moebius_map(const ex & a, const ex & b, const ex & c, const ex & d, const ex & v, const ex & G)
ex clifford_moebius_map(const ex & a, const ex & b, const ex & c, const ex & d, const ex & v, const ex & G, unsigned char rl) 1178c1178 < x = lst_to_clifford(v, mu, G);
x = lst_to_clifford(v, mu, G, rl); 1184c1184 < ex clifford_moebius_map(const ex & M, const ex & v, const ex & G)
ex clifford_moebius_map(const ex & M, const ex & v, const ex & G,unsigned char rl) 1188c1188 < ex_to<matrix>(M)(1,0), ex_to<matrix>(M)(1,1), v, G);
ex_to<matrix>(M)(1,0), ex_to<matrix>(M)(1,1), v, G, rl);
1191a1192,1196
ex clifford_moebius_map(const ex & M, const ex & v, const ex & G) { return clifford_moebius_map(M, v, G, 0); } ex clifford_moebius_map(const ex & a, const ex & b, const ex & c, const ex & d, const ex & v, const ex & G) { return clifford_moebius_map(a, b, c, d, v, G, 0); }
Hi, On Tue, 8 Feb 2005, Vladimir Kisil wrote:
I afraid that did not understand everything from the Richard email (since my programming skill are very weak) but here is the new patch.
That patch forgot to declare the functions without the representation labels, thus breaking the API: You won't be able to compile a program omitting rl. I've added the two signatures. This way, binary compatibility should be preserved.
How could I know when v1.4 is out in order to revert to the first more natural solution?
Don't worry. I've applied your original patch with rl = 0 to HEAD and the modified patch with the added signatures to the 1.3 branch. This way, the more natural solution will eventually be there when GiNaC-1.4 comes out while a simple recompile of applications should suffice, since the programming interface is the same. Oh, you'll know when 1.4 is out when you see a grand announcemnt. ;-) Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (2)
-
Richard B. Kreckel
-
Vladimir Kisil