The above result walks thru the case for when theta is 0 and demonstrates that result should be F <= -1500. This is also the result Reduce returns.

If this isn't the result you want, then the problem probably isn't being specified correctly. For example, if negative values of F are unphysical, you might need to add that as a condition.

But either way, Reduce and Solve aren't doing anything incorrect. Even if (and I'd agree) it'd be preferable that Cos[theta] == 0 wasn't a separate case in Reduce's output and Solve handled that case.

Using a floating point value for input is probably inadvisable. But you can intentionally insert small amounts of error into your calculations and that will usually prevent you from hitting spots where Solve's generic inequality is problematic.

I received an answer from Chris Degen via Stackoverflow. He points out that specifying ? = 90.0 (note the decimal point) solves the problem. This is because Cos[90.0 Degrees] is 6.123233995736766E-17 whereas Cos[90 Degrees] is 0. The solution is the same but we are fooling it with finite machine precision. If I ask me, I would say that this is a bug in equation solver in Mathematica.

The solution produced by Solve[] should test for Cos[] >= 0. Now it tests for Cos[] > 0 which is not true for Cos[90°].

Thanks

My example is non-physical. It's just a simpler version of your same math problem.

If we use your full example with reduce and set theta = 0, we can only deduce that F <= -1500. That seems reasonable. What should it be giving? If we follow it's logic, you're asking Reduce to look at this:

0 == If[(2 (1500 + F))/5 >= 0, 2/5 (1500 + F Cos[0]), 0]

Which is just this:

Reduce[0 == If[F >= -1500, 2/5 (1500 + F ), 0], F]

Or more simply:

Reduce[0 == If[F >= -1500, (1500 + F ), 0], F]

It seems reasonable that the answer to this is F <= -1500. What would you expect it to be?

No, you are using wrong condition! My condition says that the friction force must be >= 0. This is what physics says. Your condition says that the vertical component of F must be >= -1 which is something different and there is no such limit in physics.

If I use Reduce[] as you propose then I get error when ? = 0 but right when ? = 90. There is a problem somewhere when Mathematica computes functions at a boundary (0 or 90 in this case).

The original question is not answered and original problem is not solved.

Thanks.

tl;dr Try using Reduce.

Consider the equation:

3(x-1)/(x-1) 

Is this equal to 3? We'd normally say so, but there is a difference between the two. They don't agree at a certain point (x->1). So we say that they are "generically equal". This means you can expect them to agree except at specific points. Normally, humans don't worry about the difference when we're doing math on a chalkboard because we're very co-operative and anticipate what is needed. But algorithms can't do this. They obey very strict rules instead of being co-operative while doing algebra.

Generic equality produces all sorts of confusion. It's not a topic taught in Math classes. There's a short tutorial on it: https://reference.wolfram.com/language/tutorial/GenericAndNonGenericSolutions.html

But the moral of the story is that you shouldn't be too surprised when there are specific points at which two "equal" equations don't agree.

Now to look at your specific example, let's first create a simplified version of your problem:

Solve[F Sin[theta] == Piecewise[{{1, F*Cos[theta] >= -1}}, 0], F, Reals]

ConditionalExpression[
Csc[theta], 
(Cos[theta] > 0 && Sin[theta] > 0) || (Cos[theta] > 0 && 
Cos[theta] + Sin[theta] < 0) || (Cos[theta] < 0 && 
Sin[theta] < 0) || (Cos[theta] < 0 && 
Cos[theta] + Sin[theta] > 0)]

Anytime you see a problem like this, please try to create a simpler version of the problem like the one above. It's often very instructive.

If we check this ConditionalExpression for when theta is equal to Pi/2, we'll see it's not defined. Just like in your example.

We can plot the values of theta when this has a solution using NumberLinePlot. It is clear then that this doesn't give a solution for plus or minus Pi/2 or 90 degrees. Some algebra happened where this part of the solution was ignored. That happens with Solve.

But according to the documentation we can use Reduce instead of Solve. Reduce doesn't use generic equality.

mySolution = 
 Reduce[F Sin[theta] == Piecewise[{{1, F*Cos[theta] >= -1}}, 0], F, Reals]

(Cos[theta] < 
    0 && ((Sin[theta] < 0 && F == Csc[theta]) || (Sin[theta] == 0 && 
       F > -Sec[theta]) || (Sin[theta] == -Cos[theta] && 
       F == -Sec[theta]) || (Sin[theta] > -Cos[theta] && 
       F == Csc[theta]))) || (Cos[theta] == 
    0 && ((Sin[theta] < 0 && F == Csc[theta]) || (Sin[theta] > 0 && 
       F == Csc[theta]))) || (Cos[theta] > 
    0 && ((Sin[theta] < -Cos[theta] && 
       F == Csc[theta]) || (Sin[theta] == -Cos[theta] && 
       F == -Sec[theta]) || (Sin[theta] == 0 && 
       F < -Sec[theta]) || (Sin[theta] > 0 && F == Csc[theta])))

That's some very complicated output, but let's see what happens when we set theta to Pi/2

mySolution /. theta -> Pi/2

F == 1

Which is what we were looking for.