9

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:)
Ajasja
  • 13,634
  • 2
  • 46
  • 104

2 Answers2

8

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.

Mr.Wizard
  • 271,378
  • 34
  • 587
  • 1,371
  • 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
  • 1
    @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. –  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
  • @celtschk I'd consider this a missing feature rather than a bug (such as a valid looking but incorrect result). I described here in a bit more detail why I thought a [bug] tag was a good idea: http://meta.mathematica.stackexchange.com/a/355/12 – Szabolcs Apr 18 '12 at 13:12
  • @Szabolcs Actually the licence prohibits any sort of modification even if you don't distribute the result. However, practically speaking, we probably have to apply some common sense when interpreting the ridiculously strict Mathematica licence agreement. For example, some countries have provisions in their copyright law that would allow modifications if they're to correct problems in the original code, which would render that clause invalid (for copyright purposes, at least). – Oleksandr R. Apr 18 '12 at 16:50
  • @OleksandrR. You're right, I just found "c. modifying the Software in any manner, except those portions written in the Mathematica language and included as examples". It also has "b. decompiling, disassembling, or reverse engineering the Software". That's a surprise given the culture of reverse engineering or "spelunking" the Mathematica community has. There's even a doc page titles "Low-Level System Spelunking". – Szabolcs Apr 18 '12 at 16:54
  • I would also tag this as a bug. I spent quite some time going through the uncompiled expression in order to figure out from where a None symbol was coming from. – Ajasja Apr 18 '12 at 20:42
  • @Szabolcs Ahh, but then this should also apply to files like KeyEventTranslation.tr, but nobody was raising the point there:) – Ajasja Apr 18 '12 at 20:50
7

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.

celtschk
  • 19,133
  • 1
  • 51
  • 106
  • 1
    +1. Well it's not that obvious, especially as it reminds of the symbol None:) – Ajasja Apr 18 '12 at 12:29
  • 1
    @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 != –  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
  • 1
    Interesting: CompilePrint[Compile[{a, b}, a > b]] produces "None" while CompilePrint[Compile[{a, b}, a < b]] produces "<" – Ajasja Apr 18 '12 at 12:40
  • 1
    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
  • @Ajasja Infact "!=" and ">" produce the same code ... – Dr. belisarius Apr 18 '12 at 12:43
  • @belisarius I think the code is correct, just the display is wrong – Ajasja Apr 18 '12 at 12:48
  • @belisarius: No, they do not produce the same code, as you can see by looking at the FullForm: At one position, != produces an 8 while > produces a 7. Only the disassembly looks the same. – celtschk Apr 18 '12 at 12:59
  • @celtschk Sorry, I was trying to say that. – Dr. belisarius Apr 18 '12 at 13:18