# Variable naming changes everything

I am having a rather unusual problem I do not understand with Mathematica where renaming one of the variables of my function causes the function to stop "working". Here is the example of the code doing what it should:

F[t_, a_, b_, l_] = x[t] /. First@
DSolve[{x'[t] == a*x[t]*(1 - (x[t]/b)) - l*x[t], x[0] == 0.4}, x[t], t];


Changing one variable name causes the code to throw out error messages. The non-working code is

F[t_, r_, b_, l_] = x[t] /. First@ DSolve[{x'[t] == r*x[t]*(1 -
(x[t]/b)) - l*x[t], x[0] == 0.4}, x[t], t];

-
A very peculiar bug. It works if r is replaced by any of a, c, d, or e, but chokes for the other letters. What version and OS are you using, for reference? –  Ｊ. Ｍ. May 14 '13 at 12:53
It seems that only variables that begin with a c d e will work (something like aaa is also OK)… very strange! –  xzczd May 14 '13 at 12:53
@J.M. I'm thinking about something to do with the lexicographical order of E –  belisarius May 14 '13 at 12:53
@5xum Did you report this to support@wolfram.com as bug? Please do if you haven't yet and link back to this question. –  Szabolcs May 14 '13 at 17:13
@Szabolcs I reported it, will report when anything happens. It's CASE:134234 by the way –  5xum May 16 '13 at 9:15

A little bit more. Still not fully diagnosed, but the problem isn't due to DSolve ... :

s1 = DSolve[{x'[t] == f*x[t] (1 - (x[t]/b)) - l x[t]}, x[t], t];
s2 = DSolve[{x'[t] == e*x[t] (1 - (x[t]/b)) - l x[t]}, x[t], t];


And the problem shows up when matching the initial condition:

Solve[(x[t] /. s2[[1]] /. t -> 0) == 4/10, C[1]]
(*
{{C[1] -> -(Log[1/2 (2 e - 5 b e + 5 b l)]/(b (e - l)))}}
*)


but

Solve[(x[t] /. s1[[1]] /. t -> 0) == 4/10, C[1]]


Solve::nsmet: This system cannot be solved with the methods available to Solve. >>

BTW,

Solve[(x[t] /. s1[[1]] /. t -> 0) == 4/10, C[1], Reals]


can be solved without any problem

Edit

I was able to track down the problem to:

Solve[E^(a w) (f - e) == E^(b w), {w}]


and

Solve[E^(a w) (f - g) == E^(b w), {w}]


only the first one gives a result!

-
Wow. I was sure I was missing something completely obvious, but the chaotic behavior makes me think this is just a very bizzare bug... –  5xum May 14 '13 at 14:00
@5xum Not obvious at all ... –  belisarius May 14 '13 at 14:03
@5xum An apparent bug indeed, and one that has persisted at least from version 7 through version 9. I'm surprised this hasn't been found and addressed in that time. –  Mr.Wizard May 15 '13 at 4:36
I guess this is a plain bug, a pattern matching messup that makes MMA think it can solve one expression and not the other. It's funny how it can solve the last example only if at least one of the two variables you add or subtract is sorted before the letter E (or whatever you put as base to that power) –  Rojo May 16 '13 at 16:58
@Silvia Try the Solve[] with MaxExtraConditions -> All –  belisarius May 17 '13 at 1:24

The problem can be reduced to the DSolve expressions:

DSolve[{x'[t] == a*x[t]*(1 - (x[t]/b)) - l*x[t], x[0] == 0.4}, x[t], t]

DSolve[{x'[t] == h*x[t]*(1 - (x[t]/b)) - l*x[t], x[0] == 0.4}, x[t], t]


One can see that alphabetical order appears important:

With[{a = Symbol@#},
Shallow @ DSolve[{x'[t] == a*x[t]*(1 - (x[t]/b)) - l*x[t], x[0] == 0.4}, x[t], t]
] & /@ DeleteCases[CharacterRange["a", "z"], "b" | "l" | "t" | "x"]

{{{Rule[<<2>>]}}, {{Rule[<<2>>]}}, {{Rule[<<2>>]}}, {{Rule[<<2>>]}}, {}, {}, {},
{}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}}


I suspect that this may be related to: Why does Simplify ignore an assumption?
Unfortunately I cannot think of a robust way to address the problem.

-
Interesting. Definitely, interesting. –  rcollyer May 14 '13 at 12:59
Finally I have a justifiable reason for using aardvark as a variable name :-) –  Simon Woods May 14 '13 at 13:21
@SimonWoods You might then be interested in AAAAAAAAAAAAAAAAA! :D –  rm -rf May 14 '13 at 13:35
@SimonWoods DSolve[{ax'[at] == ah*ax[at]*(1 - (ax[at]/ab)) - l*ax[at], ax[0] == 0.4}, ax[at], at] seems to work... –  geordie May 14 '13 at 22:29
If you want to "address" the problem in a robust way (as opposed to "diagnosing" the cause of the bug), I think that SetOptions[Solve,MaxExtraConditions -> All] may help –  belisarius May 17 '13 at 5:16