# tol and None in output of CompilePrint

A bit of background:

I'm trying to fit a very complicated symbolic function. By compiling the function I got about 100x speedup, but I would need another 10. Therefore I'm trying to understand if the function is correctly compiled (I allready checked that there are no calls to MainEvaluate).

The problem:

While scanning through the output of CompilePrint I see the following snippet repeating a lot

12  B0 = R39 None R38 (tol R42)
13  if[ !B0] goto 46


The question:

What does line 12 do? Is this R39 * None * R38? What is (tol R42)?

Here is some more context:

    33 arguments
1 Boolean register
1 Integer register
123 Real registers
Underflow checking off
Overflow checking off
Integer overflow checking off
RuntimeAttributes -> {}

R0 = A1
R1 = A2
...
Result = R64

1   R38 = Reciprocal[ R2]
2   R39 = R37 * R38
3   R38 = R36 + R39
4   R39 = Reciprocal[ R38]
5   R38 = - R39
6   R39 = - R2
7   R41 = R40 + R39
8   R39 = Reciprocal[ R2]
9   R41 = R41 * R39
10  R39 = R36 + R38 + R41
11  R38 = I0
12  B0 = R39 None R38 (tol R42)
13  if[ !B0] goto 46
....
19k something lines:)

-
Can you try to come up with a much smaller function that produces a similar output? –  Szabolcs Apr 18 '12 at 12:30

Without seeing the code that generated the above this is only a guess. If you look in:

FileNameJoin[{\$InstallationDirectory, "AddOns", "Applications",
"CompiledFunctionTools", "PrintCode.m"}]


you'll find a line:

toInfixForm[_] := None


All infix form conversions not known (i.e. in that list in that file) are replaced by None.

It would be good to find out which expr is not mentioned in the toInfixForm such that it can be added. Presumably this is some compare function. In that same file you will also find tol.

-
The missing operations are (at least): Unequal, Greater, GreaterEqual. Is it safe just to add them to the file? –  Ajasja Apr 18 '12 at 12:50
@Ajasja, yes, I'd think that adding this is safe. You could make a backup of the modified file, just in case you want to go back to it later. –  user21 Apr 18 '12 at 12:53
+1. Everything appears to be working correctly. None was in fact ">=" (in my case) . –  Ajasja Apr 18 '12 at 12:58
@Ajasja I'm wondering if the license permits modifying that file and sharing it publicly. In any case, sharing just a patch (the diff) is probably safe. –  Szabolcs Apr 18 '12 at 13:07
Maybe the question should be tagged [bug], then? –  celtschk Apr 18 '12 at 13:08

None stands for an operation for which Wolfram has forgotten to implement a specific name in output, and tol probably stands for "tolerance". For example, see

CompilePrint[Compile[{a,b},a!=b]]
(*
==>
1 Boolean register
3 Real registers
Underflow checking off
Overflow checking off
Integer overflow checking on
RuntimeAttributes -> {}

R0 = A1
R1 = A2
R2 = 7.
Result = B0

1   B0 = R0 None R1 (tol R2)
2   Return
*)


Note that you get the same result when using > instead of !=. Unfortunately that means that the information in the decompiled code is incomplete.

-
+1. Well it's not that obvious, especially as it reminds of the symbol None:) –  Ajasja Apr 18 '12 at 12:29
@celtschk, as I have shown above, None is inserted for any symbol that is not mentioned in the toInfixForm It could be other things than != –  user21 Apr 18 '12 at 12:32
@Ajasja: I didn't mean "obviously" as "it should be obvious to you" but as "it seems obvious to me" (i.e. it's not something I know from any source, so there's still a small chance that I'm wrong). –  celtschk Apr 18 '12 at 12:34
Interesting: CompilePrint[Compile[{a, b}, a > b]] produces "None" while CompilePrint[Compile[{a, b}, a < b]] produces "<" –  Ajasja Apr 18 '12 at 12:40
I see, so my conclusion was indeed wrong. I'll update my answer to reflect my new knowledge. –  celtschk Apr 18 '12 at 12:42