<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Javier, All,<br><br>I think what we need can be done with two print functions, as described below. It seems straightforward enough that I can implement this myself, but I wonder if it already exists somewhere? Is this something the developers would consider adding to Ginac?<br><br>Thanks,<br>Doug<br><br>---------------------<br><br>Perhaps this is a clean solution. One could write a print function that outputs C++ code that explicitly names and declares sub-expressions. You also have a companion print function that just emits the name of the top-level expression. Call them print_declarations() and print_variable_name(). <br><br>For example, suppose you have an expression like this: <br> ex myex = a + b*pow(c+d+e,2.0) + f/(g*h + i*j);<br>For simplicity's sake, let each symbol just be a variable (e.g. symbol
a("my_a")), but of course they can be anything. print_declarations() can emit these declarations below during a post-order traversal of the expression tree. <br><br>// Symbols<br>
double a = my_a;<br>
double b = my_b; <br>
[...]<br>
double j = my_j;<br>
// Expressions<br>
double e1 = a;<br>
double e2 = b;<br>
double e3 = c;<br>
double e4 = d;<br>
double e5 = e;<br>
double e6 = e3 + e4 + e5;<br>
double e7 = pow(e6, 2.0);<br>
double e8 = e2 * e7;<br>
double e9 = f;<br>
double e10 = g; <br>
double e11 = h;<br>
double e12 = e10*e11;<br>
double e13 = i;<br>
double e14 = j;<br>
double e15 = e13*e14;<br>
double e16 = e12 + e15;<br>
double e17 = e9 / e16;<br>
double e18 = e1 + e8 + e17;<br>
<br>print_variable_name() can then just emit e18 for the example expression, to be used however you would normally use C++ code that you print.<br><br>Then, assuming ginac is smart about not having separate expression tree nodes for duplicated sub-expressions, you will declare each sub-expression just once. The order ginac uses for expressions does not matter at all.<br><br>Support NPR 20 seconds at a time. www.twentysecondsatatime.org<br><br>--- On <b>Thu, 5/13/10, jros <i><jros@unavarra.es></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: jros <jros@unavarra.es><br>Subject: Re: [GiNaC-list] Term ordering and compiling C++ code<br>To: "GiNaC discussion list" <ginac-list@ginac.de><br>Date: Thursday, May 13, 2010, 10:31 AM<br><br><div id="yiv1062453658">
Hello,<br>
<br>
Although I don't have a solution for your problem, as I'm myself addressing similar problems<br>
matching common subexpressions to variables, in down top manner, I think that such a functionality<br>
is implicitly implemented in GiNaC.<br>
<br>
If I understand GiNaC internal structure correctly, subexpressions common to two expresions,<br>
are frequently shared internally, to save memory.<br>
<br>
So it must be possible to write a print algorithm that goes trough an/some expression/s tree, and that replaces<br>
every shared subexpression (let say sum product) with a variable, that again is assigned a expression that would be printed<br>
in the same way using recursion. <br>
<br>
Probably allowing/disallowing some kind automatic simplifications (so that subexpression sharing expected value increases) can probably help to obtain improved results.<br>
<br>
I wonder what do the developers think about this.<br>
<br>
Cheers,<br>
<br>
Javier<br>
<br>
<br>
On Thu, 2010-05-13 at 07:11 -0700, Doug wrote:<br>
<blockquote type="CITE">
<table cellpadding="0" cellspacing="0">
<tbody><tr>
<td valign="top">
Hi,<br>
<br>
I'm running into a term ordering problem like the one mentioned in this post.<br>
http://permalink.gmane.org/gmane.comp.mathematics.ginac.general/1107<br>
<br>
Relevant details about my application are below, for the curious. The short of it, though, is that the C++ code I am generating with ginac is so large (50MB) that the compiler can't handle it, and moreover, the values being represented by ginac symbols are array accesses that the compiler can't optimize away. So I need to create temporary values and do sub-expression elimination on the C++ code just so the compiler can have a chance. I have successfully done this using search-and-replace on the C++ code for other applications, but I guess I was just lucky that ginac printed terms in a consistent order.<br>
<br>
Is this a problem other ginac users have confronted? From the answer to the above post, it sounds like I need to write my own print function that can ensure expressions are printed in a predictable order. It looks like I can also inspect the expression tree and possibly do a proper job of common sub-expression elimination. But if there is an easier approach, I'd be very grateful for a pointer or two.<br>
<br>
Thanks,<br>
Doug Baker<br>
<br>
-------------------<br>
Background Details<br>
-------------------<br>
<br>
My application is related to visual odometry. I am computing the gradient and hessian for a function of 10 variables that involves converting quaternions to rotation matrices, applying those matrices to 3D points and projecting those points onto a 2D plane.<br>
<br>
I am generating code with ginac that is initially 50MB of C++ code. (And thank you for ginac being able to handle that monstrosity with such grace.) The input symbols are all array elements (e.g. symbol x("state[t+X]")) or function calls (e.g. symbol rTi11("rTi.getValue<1,1>()")).<br>
<br>
If I take the printed output from ginac as is, the C++ compiler can't properly optimize it because it doesn't know that state[t+X] is a constant or that getValue is constant. Moreover, the expressions have huge repeated expressions, and these bog the compiler down, too.<br>
<br>
I've been able to use a simple search-and-replace approach in other problems, and on this one that same approach has gotten me from 50MB to 6MB or so, but the term ordering issue is biting me now. For example, I have one sum (a+b+c+d) that occurs 232608 times. But there are 4! = 24 permutations of that sum that I'd have to replace. It's worse than that, though, because that's not the only expression like it. Some are bigger, like this: (-2.0*sK/sKSIJ+4.0*sK*sS2/pKSIJ2+-4.0*sI*sJ*sS/pKSIJ2). This has something like 72 permutations, not even counting the permutations of pKSIJ and pKSIJ2, which are themselves expressions like (a+b+c+d). And not only are there variations on this due to term ordering, similar expressions occur with different variables (e.g. with sJ instead of sK, etc.) So when all these expressions can be output in various orders, it's no longer feasible to generate all the permutations for
search-and-replace.<br>
<br>
<br>
Support NPR 20 seconds at a time. www.twentysecondsatatime.org
</td>
</tr>
</tbody></table>
<br>
<pre>_______________________________________________<br>GiNaC-list mailing list<br><a rel="nofollow" ymailto="mailto:GiNaC-list@ginac.de" target="_blank" href="mailto:GiNaC-list@ginac.de">GiNaC-list@ginac.de</a><br><a rel="nofollow" target="_blank" href="https://www.cebix.net/mailman/listinfo/ginac-list">https://www.cebix.net/mailman/listinfo/ginac-list</a><br></pre>
</blockquote>
</div><br>-----Inline Attachment Follows-----<br><br><div class="plainMail">_______________________________________________<br>GiNaC-list mailing list<br><a ymailto="mailto:GiNaC-list@ginac.de" href="/mc/compose?to=GiNaC-list@ginac.de">GiNaC-list@ginac.de</a><br><a href="https://www.cebix.net/mailman/listinfo/ginac-list" target="_blank">https://www.cebix.net/mailman/listinfo/ginac-list</a><br></div></blockquote></td></tr></table><br>