Skip to main content

programming - NDSolve and {C, K, Slot} and other built-ins as a variable name


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

Popular posts from this blog

mathematical optimization - Minimizing using indices, error: Part::pkspec1: The expression cannot be used as a part specification

I want to use Minimize where the variables to minimize are indices pointing into an array. Here a MWE that hopefully shows what my problem is. vars = u@# & /@ Range[3]; cons = Flatten@ { Table[(u[j] != #) & /@ vars[[j + 1 ;; -1]], {j, 1, 3 - 1}], 1 vec1 = {1, 2, 3}; vec2 = {1, 2, 3}; Minimize[{Total@((vec1[[#]] - vec2[[u[#]]])^2 & /@ Range[1, 3]), cons}, vars, Integers] The error I get: Part::pkspec1: The expression u[1] cannot be used as a part specification. >> Answer Ok, it seems that one can get around Mathematica trying to evaluate vec2[[u[1]]] too early by using the function Indexed[vec2,u[1]] . The working MWE would then look like the following: vars = u@# & /@ Range[3]; cons = Flatten@{ Table[(u[j] != #) & /@ vars[[j + 1 ;; -1]], {j, 1, 3 - 1}], 1 vec1 = {1, 2, 3}; vec2 = {1, 2, 3}; NMinimize[ {Total@((vec1[[#]] - Indexed[vec2, u[#]])^2 & /@ R...
Post a Comment
Read more

functions - Get leading series expansion term?

Given a function f[x] , I would like to have a function leadingSeries that returns just the leading term in the series around x=0 . For example: leadingSeries[(1/x + 2)/(4 + 1/x^2 + x)] x and leadingSeries[(1/x + 2 + (1 - 1/x^3)/4)/(4 + x)] -(1/(16 x^3)) Is there such a function in Mathematica? Or maybe one can implement it efficiently? EDIT I finally went with the following implementation, based on Carl Woll 's answer: lds[ex_,x_]:=( (ex/.x->(x+O[x]^2))/.SeriesData[U_,Z_,L_List,Mi_,Ma_,De_]:>SeriesData[U,Z,{L[[1]]},Mi,Mi+1,De]//Quiet//Normal) The advantage is, that this one also properly works with functions whose leading term is a constant: lds[Exp[x],x] 1 Answer Update 1 Updated to eliminate SeriesData and to not return additional terms Perhaps you could use: leadingSeries[expr_, x_] := Normal[expr /. x->(x+O[x]^2) /. a_List :> Take[a, 1]] Then for your examples: leadingSeries[(1/x + 2)/(4 + 1/x^2 + x), x] leadingSeries[Exp[x], x] leadingSeries[(1/x + 2 + (1 - 1/x...
Post a Comment
Read more

What is and isn't a valid variable specification for Manipulate?

I have an expression whose terms have arguments (representing subscripts), like this: myExpr = A[0] + V[1,T] I would like to put it inside a Manipulate to see its value as I move around the parameters. (The goal is eventually to plot it wrt one of the variables inside.) However, Mathematica complains when I set V[1,T] as a manipulated variable: Manipulate[Evaluate[myExpr], {A[0], 0, 1}, {V[1, T], 0, 1}] (*Manipulate::vsform: Manipulate argument {V[1,T],0,1} does not have the correct form for a variable specification. >> *) As a workaround, if I get rid of the symbol T inside the argument, it works fine: Manipulate[ Evaluate[myExpr /. T -> 15], {A[0], 0, 1}, {V[1, 15], 0, 1}] Why this behavior? Can anyone point me to the documentation that says what counts as a valid variable? And is there a way to get Manpiulate to accept an expression with a symbolic argument as a variable? Investigations I've done so far: I tried using variableQ from this answer , but it says V[1...
Post a Comment
Read more