Is there somewhere a list on the functions that Compile can compile, or the cases in which a particular function can be compiled that I haven't found?
I'd be glad even with a list of some of them which surprisingly aren't compilable, and how to do without them.
I am not happy every time I have ...
Since it is somewhat misleading - Tr cannot be compiled, but appears in this list
Which I think is because, as Jagra's answer (http://mathematica.stackexchange.com/a/19194/13162) explains, "I don't think that is the correct interpretation of the list Sort[Compile`CompilerFunctions[]]. This list consists of those system functions that are pre-compiled."
a = 1;
Button["Print", a++]
Button["Print", Dynamic[a++]]
Button["Print", Dynamic[a++];]
Button["Print", {Dynamic[a++]}]
Dynamic @ a
The second Button is not supposed to change the value of a but it does.
Have I missed something or is it a bug?
Why it is not supposed to?
Button[labe...
@blochwave yes, I think you should certainly update it to mention that Tr is not compilable even though it appears in the list--well noticed. On the other hand, the information Jagra was given by support is indisputably wrong. I think that the appearance of Tr in the list (or the compiler's lack of support for Tr) may be a bug.
@blochwave what is even stranger, is that Tr is handled using the opcode 47 mechanism (supposed to be a jump straight to the entry point of the function code, no top-level interpretation, still fast). But unlike all other functions handled this way, the second part of the instruction contains not the function's name Tr but rather Tr[#1] &. This is like the normal and slow opcode 46 which copies data out of the VM into top-level symbols and invokes the full evaluator.
So, it seems that Tr does something special, or it's just someone's mistake not to handle it properly. I don't know if you will get any useful response if you raise this with support.
Bug introduced in 10.1
This bug was resolved in 10.2.0, but another bug was introduced in 10.3.0 persisting through 10.3.1 and finally resolved in 10.4
In Mathematica 10.1.0 and 10.3.0 BenchmarkPlot from the GeneralUtilities package doesn't work and we shall focus on the situation of 10.1.0...
Quick question: Is there a built-in function that inserts a space before each capital letter in a Pascal case string? e.g. StringInsert[#, " ", (StringPosition[#, ToUpperCase@Alphabet[]][[All, 1]] /. {1 -> Nothing})] &["MyPascalCaseString"] to give "My Pascal Case String"?
Any ideas for the future of PackageData? I'm open to making major changes.
People have been talking about Github-based models etc. I don't rule out anything. We now have a collection of packages, that doesn't mean we can't present it differently or store and update it differently.
@BobHanlon. Maybe an epiphany is just around the corner for me but why would including WorkingPrecision completely change the resulting value of a function? (I get the part about fixing round-off but doing so gives one the wrong answer: mathematica.stackexchange.com/questions/115916/…)
I am expecting the same Null behavior in TableForm[{{1, Null}, {Null, 2}}] that I get in Grid[{{1, Null}, {Null, 2}}]. Is this a bug or my misunderstanding?
a = 1;
Button["Print", a++]
Button["Print", Dynamic[a++]]
Button["Print", Dynamic[a++];]
Button["Print", {Dynamic[a++]}]
Dynamic @ a
The second Button is not supposed to change the value of a but it does.
Have I missed something or is it a bug?
Why it is not supposed to?
Button[labe...
Bug introduced in 10.1
This bug was resolved in 10.2.0, but another bug was introduced in 10.3.0 persisting through 10.3.1 and finally resolved in 10.4
In Mathematica 10.1.0 and 10.3.0 BenchmarkPlot from the GeneralUtilities package doesn't work and we shall focus on the situation of 10.1.0...
