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 toobj.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 mex(0)
instead ofobj.x_[0]
. - Mathematica thinks I want to use its own
Power
function, but I'd really like to usestd::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
.
Answer
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.
Comments
Post a Comment