very odd failure of Solve

[Alan]

Setting an irrelevant parameter to 0 baffles Solve. Why?
Thanks,
Alan Isaac

$Assumptions =.
ClearAll[f1]
f1[x_] := s*x^\[Alpha] - (a + b + c)*x
Solve[f1[x] == 0, x] (* Solve works *)
Solve[(f1[x] /. {b -> 0}) == 0, x] (* Solve fails *)

(* adding these assumptions does not change things *)
f1assume = (1 > s > 0 && k >= 0 && 1 > \[Alpha] > 0 && a >= 0 && b >= 0 &&
1 > c > 0);
Assuming[f1assume, Solve[f1[x] == 0, x]] (* Solve works *)
Assuming[f1assume, Solve[(f1[x] /. {b -> 0}) == 0, x]] (* Solve fails *)

[Richard Fateman]

On 9/15/2013 4:03 AM, Alan wrote:
> Setting an irrelevant parameter to 0 baffles Solve. Why?
> Thanks,
> Alan Isaac
>
> $Assumptions =.
> ClearAll[f1]
> f1[x_] := s*x^\[Alpha] - (a + b + c)*x
> Solve[f1[x] == 0, x] (* Solve works *)
> Solve[(f1[x] /. {b -> 0}) == 0, x] (* Solve fails *)

<snip>

Running Reduce[ {%==0}, {x} ] on either equation seems to go into
an infinite loop. That maybe be an independent bug, though.

I expected that somehow fiddling with the variable names would
do something, and that the ordering of a,b,c, alpha was critical.
Out of curiosity I tried a few variants to generate a better
hypothesis, but ran out of, um, curiosity.

[Dr. Wolfgang Hintze]

Still a bit curious I tried

1) the number miracle

Solve[s*x^\[Alpha] - (a + b + c)*x, x] (* Solve works *)
Solve[s*x^\[Alpha] - (a + b )*x, x] (* Solve fails *)
Solve[s*x^\[Alpha] - (a )*x, x] (* Solve works *)

oops, size matters (1 and 3 is okay, 2 not)

2) the simplest case

The most simple case of this type in which Solve fails seems to be

Solve[x^E - 2*x == 0, x]

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

You can safely replace the irrational E by the algebraic Sqrt[2] or other constants apart from rationals. Solve will fail as well.

Competition is open to find the simplest case Solve can't do with.

Best regards,
Wolfgang

[Richard Fateman]

On 9/17/2013 6:30 PM, Dr. Wolfgang Hintze wrote:

....

Reduce[{x^a-x==0},x]
FullSimplify[%]

[da...@wolfram.com]

It does seem to involve ordering. If instead of "a+c" one has "y+c" then Solve handles it. The underlying issue is some simplifying that produces, or not, a "nice" form of intermediate expression. This was also recently reported in the Mathematica stackexchange forum.

http://mathematica.stackexchange.com/questions/25182/variable-naming-changes-everything

I hope to find time to investigate further, some day.

Daniel Lichtblau
Wolfram Research

[Alan]

On Wednesday, September 18, 2013 6:12:34 AM UTC-4, da...@wolfram.com wrote:
> It does seem to involve ordering. If instead of "a+c" one has "y+c" then Solve handles it. The underlying issue is some simplifying that produces, or not, a "nice" form of intermediate expression. This was also recently reported in the Mathematica stackexchange forum.
>
> http://mathematica.stackexchange.com/questions/25182/variable-naming-changes-everything
>
> I hope to find time to investigate further, some day.

Thanks for the link. Looking forward to a resolution.
Alan Isaac

[Itai Seggev]

> On Wednesday, September 18, 2013 6:12:34 AM UTC-4, da...@wolfram.com wrote:

> > It does seem to involve ordering. If instead of "a+c" one has "y+c" then
> > Solve handles it. The underlying issue is some simplifying that produces,
> > or not, a "nice" form of intermediate expression. This was also recently
> > reported in the Mathematica stackexchange forum.
> >
> > http://mathematica.stackexchange.com/questions/25182/variable-naming-chan
> >ges-everything
> >
> > I hope to find time to investigate further, some day.
>

> Thanks for the link. Looking forward to a resolution.
> Alan Isaac

I'm please to report that this particular issue is fixed in our internal build,
so the next release will resolve it.

--
Itai

Itai Seggev
Software Technology