7
$\begingroup$

I'd quite like to be able to automatically generate C++ versions of certain mathematical expressions that I've manipulated in Mathematica. The resultant C++ code fragment is then going to be used independently of Mathematica.

Mathematica provides a CForm function, which almost seems like what I want, but I can't get it to do basic conversions nor tell it how to convert Mathematica symbols into my C++ identifiers.

For example, I would like the output from CForm[x[0]^2] or ToString[x[0]^2, CForm] to be "std::pow(obj.x_[0], 2)". This can be a string; it doesn't need to be usable in Mathematica any more. Of course, my actual expressions of interest are a lot more complicated than this.

But:

  • I don't have a way of telling Mathematica that symbol x is to be renamed to obj.x_ (not a valid symbol name in Mathematica so can't use it directly). String manipulation after conversion is too unreliable for this so a more direct method is preferred.
  • I can't tell Mathematica that x is an array, not a function, so it gives me x(0) instead of obj.x_[0].
  • Mathematica thinks I want to use its own Power function, but I'd really like to use std::pow.

Perhaps CForm isn't suited to this task, but I would still appreciate a solution using any other available method if possible. I really think that Mathematica should be able to help me here, because it knows where I need brackets and so on.

I've tried:

Format[x[a_], CForm] :=
    "obj.x_[" <> ToString[a, CForm] <> "]"

Format[Power[a_, b_], CForm] := 
    "std::pow(" <> ToString[a, CForm] <> ", " <> ToString[b, CForm] <> ")"

ToString[x[0]^2, CForm]

but of course Power is protected so the second SetDelayed gives me an error, and my ToString[x[0]^2, CForm] output is really weird (Power("obj.x_[0]",2)) because I've tried to use strings in the Format.

$\endgroup$
  • $\begingroup$ Use SymbolicC instead of CForm. Have a look here. Would've been a dupe but is on SO, not here. It does not cover C++, but you can extend SymbolicC to cover the parts of C++ syntax you need. In general, this is a more robust solution. $\endgroup$ – Leonid Shifrin Apr 26 '14 at 22:05
  • $\begingroup$ @LeonidShifrin: Thanks, but still isn't solved. I guess I would go for CExpression rather than the getCFormNoPowersSymC function there, but CExpression doesn't convert an expression to SymbolicC, so all I can do with it is pass to ToCCodeString. This means I can't change the identifiers, and I'm still stuck with Power instead of std::pow (assuming I don't want to convert into repeated multiplication). $\endgroup$ – cyberSingularity Apr 26 '14 at 22:20
  • $\begingroup$ See my answer, I did address this issue. $\endgroup$ – Leonid Shifrin Apr 26 '14 at 23:10
  • 2
    $\begingroup$ CForm has always seemed to be one of those cases where somebody at Wolfram Research once said "this design we came up with for output formatting is so general, it would be easy to make it generate C, or TeX, or Fortran, so let's go ahead and document it!" -- and after a few years they realized that it's a lot harder problem than it looks, and quietly let it drop. (Another example would be the idea that users can write their own Front End and hook it up to the Mathematica kernel by using standard, documented MathLink calls.) $\endgroup$ – librik Apr 27 '14 at 6:30
  • $\begingroup$ Not a mathematica answer, but actually, it better to produce pow and enable that call by a namespace declaration using std::pow in a proceeding line. $\endgroup$ – alfC Dec 29 '15 at 10:26
7
$\begingroup$

Using SymbolicC`

I suggest to use SymbolicC. It is a very flexible and robust way to generate C (or C++) code.

It is in fact pretty easy to override the standard rules for code generation. There is a GenerateCode function in SymbolicC` package, and if you inspect it, it has a number of definitions. The one relevant here is:

GenerateCode[CExpression[SymbolicC`Private`arg_], SymbolicC`Private`opts : OptionsPattern[]] := 
 ToString[CForm[HoldForm[SymbolicC`Private`arg]]]

Since symbols like CExpression are inert (have no definitions), nothing prevents you from adding UpValues to them (but do it at your own risk, all the usual warnings about redefining some built-in functionality is in order. In particular, I would not recommend to use this simultaneously with compilation to C - but see below for the better version of this method):

CExpression /: GenerateCode[CExpression[Power[arg_, pow_]]] := 
   "std::pow(" <> ToString[arg, CForm] <> ", " <> ToString[pow, CForm] <> ")"

Now, if you call

ToCCodeString[CExpression[a^2]]

you get

(* "std::pow(a, 2)" *)

This is, of course, a rather simplistic rule, and the rule can be much more complex, but this can be a start.

ClearAll[CExpression]

Making it safer

Now, let us see what can be done to make this redefinition safer / more local. My suggestion is to construct a dynamic environment for C++ code generation:

withModifiedCCodeGenerate = 
    Function[code,
       Block[{CExpression},
           CExpression /: GenerateCode[CExpression[Power[arg_, pow_]]] := 
              StringJoin[
                 "std::pow(",
                 ToString[arg, CForm],
                  ", ",
                 ToString[pow, CForm],
                 ")"
              ];
           code
       ]
       ,
       HoldAll
    ];

Now, when you need to generate your C++ code, you call your code-generation routine within this environment:

withModifiedCCodeGenerate @ ToCCodeString[CExpression[a^2]]

This is much safer since the changes to CExpression are now localized to the execution stack of the code you run inside this environment, while the global definitions are not affected.

$\endgroup$
  • $\begingroup$ Great, many thanks. In this case, using GenerateCode[CExpression[arg]] in the modified GenerateCode is better than ToString[arg, CForm] as it then obeys my variable replacement which I can define similarly. Also, I have just found another post that shows the start of a definition of toSymbolicC, which is apparently a function that Mathematica otherwise lacks and may be useful to those interested in this question. $\endgroup$ – cyberSingularity Apr 27 '14 at 9:03
  • $\begingroup$ I don't understand this answer. The last code line produces "std::pow(a, 2)" as desired, but if the a^2 is changed to, say, 1+a^2, it reverts to behaviour of the form "1 + Power(a,2)". Is this what was intended? It feels pretty underpowered if it cannot reach inside expressions to perform this kind of change. $\endgroup$ – Emilio Pisanty Mar 3 '17 at 15:09
  • $\begingroup$ @EmilioPisanty I have this sentence in the answer: "This is, of course, a rather simplistic rule, and the rule can be much more complex, but this can be a start.". So, yes, this was just showing how one can start, not implementing a complete thing. You will have to add more rules to get it to work with wider range of expressions (in your example, another rule for Plus will be needed). This isn't too hard to do for any particular case, although if one wants to have a complete expression parser, this would take some work. $\endgroup$ – Leonid Shifrin Mar 3 '17 at 15:53
  • $\begingroup$ Then maybe I don't understand the question. As I understand it, this method would require the user to design a new rule for every single situation that the atom of interest (i.e. Power to pow) will find itself in, which is bound to break. I think it's reasonable to say "Plus and Sin and Cos and so on are doing fine, but this here Power isn't really there, so change all the Powers in this way", without needing to specify every possible combination of wrappers around the atom. $\endgroup$ – Emilio Pisanty Mar 3 '17 at 16:00
  • $\begingroup$ @EmilioPisanty You don't need to specify every possible combination. If the rules are correct, they will combine automatically. But you do need to specify the cases where the original GenerateCode doesn't work as desired. In this particular case, it looks like for the case of Plus, GenerateCode does not really call itself on CExpression[1] and then on CExpression[Power[a, 2]], but does something else. So in some sense, we have to make up for the code generator behavior, which in general calls itself on sub-parts of larger expression, but for some reason not in this case. $\endgroup$ – Leonid Shifrin Mar 3 '17 at 20:26
1
$\begingroup$

This should do it:

StringReplace[ToString[x[0]^2, CForm], {"\"" -> "", "Power" -> "std::pow"}]

"std::pow(obj.x_[0], 2)"

In response to comments:-

StringReplace[ToString[xToThePower2[0]^2, CForm],
 {"\"" -> "", StartOfString ~~ "Power(" -> "std::pow("}]

"std::pow(xToThePower2(0), 2)"

StringReplace[ToString[a + xToSomePower*b^2 +
   someOtherFunctionEndingInPower[z], CForm],
 {"\"" -> "", StartOfString ~~ "Power(" -> "std::pow(",
  " Power(" -> " std::pow("}]

"a + std::pow(b, 2)*xToSomePower + someOtherFunctionEndingInPower(z)"

$\endgroup$
  • $\begingroup$ Thanks, but I'm concerned that the string replacement could be unsafe for my real application. For example, I might have a variable called xToThePower2 and the string replacement suggested would cause more problems than it solves. $\endgroup$ – cyberSingularity Apr 26 '14 at 22:24
  • $\begingroup$ @cyberSingularity - I've added a work-around. $\endgroup$ – Chris Degnen Apr 26 '14 at 22:35
  • $\begingroup$ Sorry, I haven't expressed my general problem sufficiently well. If the expression that I want to convert were a + xToSomePower*b^2 + someOtherFunctionEndingInPower[z], then the string replacement method would be much harder to make convincing than if I can persuade Mathematica to directly handle the structural expression. $\endgroup$ – cyberSingularity Apr 26 '14 at 22:41
  • $\begingroup$ @cyberSingularity - Also handled that case. I don't know if all your cases could be covered like this, but maybe. $\endgroup$ – Chris Degnen Apr 26 '14 at 22:53
  • $\begingroup$ Okay, thanks. I might be able to make this work for my real expressions. I'm still hoping that some other approaches may come to light, but if I haven't had any better solutions within a week say, I'll accept yours. $\endgroup$ – cyberSingularity Apr 26 '14 at 22:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.