The following problem is an exploration of what causes the error "Input is not an ordinary differential equation" in Mathematica as it seems to have changed from version 8 to version 9.
Specifically I have found that in Mathematica 9 I have come across the issue that
NDSolve[{x'[t] == 5, C'[t] == 5, x[0] == 1, C[0] == 1}, {x, C}, {t, 0, 100}]
gives the error, whereas in version 8 it does not. So something is up, but my question has more to do with if this is a bug in v8 or a bug in v9, that is, I get that C is a built in symbol: so is this error a correct catching of an input mistake? If so then
NDSolve[{C'[t] == 5, C[0] == 1}, C, {t, 0, 100}]
Should also give an error and it does not.
I really want to understand what is possibly going on, since as an ecologist I have to deal with equations that have C in them for "consumer" and I am forced to troubleshoot any issues that might come up with people not understanding the shadowing issue.
Clarification
It has been pointed out that it is bad coding style to use user defined symbols that start with a capital letter, as this will avoid clashes with Mathematica built-in definitions. That is fine, but does that matter?
What I am trying to ask more generally is whether the issue is that Mathematica is specifically checking for C and related symbols in NDSolve? Because I have no problems using symbols that have existing UpValues/DownValues as variable names (upper or lowercase) and even Protected in the exact same context.
What I want to try and understand is are there semantic reasons that this fails, ie could I cause the same error with user generated code? Or is this just a hard coded one off that Wolfram is doing for this case?
Further Clarification
If this is just an issue of using built-ins why can I use C in Solve and even DSolve! if it is an error in NDSolve? Again seems more and more like a specific check in NDSolve. For example
DSolve[{x'[t] == 5, C'[t] == 5, x[0] == 1, C[0] == 1}, {x, C}, t]
Gives back an answer ... so suddenly this same input string is valid ODE again?
Now there are other built-ins that have this behavior such as K and Slot. As a challenge to all that would just tell me to code differently (which I do ... this is a question of why Mathematica works this way) can you use any of the reasons that you given to make a user defined symbol that will trigger the same error? If not then I will conclude that Mathematica is specifically checking for such symbols and move on. But I want to be totally clear that this is not just a question about coding style but if there are differences between system symbols and user defined symbols in this context. What if I make a package that has defined symbols in it, will I ever be able to cause the same problem if a naive user shadows some of my imported symbols into their global context?
One interesting suggestion is that somehow NDSolve is introducing C or K or Slot when it processes the input and that is causing errors. If so then I should never be able to create this problem with user defined symbols, but I do not yet know if this is the correct idea.
Answer
From @Szabolcs comment we see that we can recreate this issue using an arbitrary System symbol so it is not an issue of some kind of functionality of the built in symbol, though he mentions that he can find models that it will still work for so it seems to be a bug, not a check.
Comments
Post a Comment