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

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.

If you use my full example, then using Reduce[] the answer should be False for 0 <= ? <= ArcTan[2/5]. It Should be a positive number otherwise. If you use Solve[] then the answer should be Undefined for the same range and positive number otherwise.

Thanks

I’m not sure that you understand the problem. Physics don’t limit the value of F. It can be whatever the experimenter chooses it to be, >0, =0, <0, in any direction.

Please refer to the bookshelf figure below.

Computed F value is actually an advice to experimenter that with given choice of ? he should apply at least force F if he wants the bookshelf to start gliding over the floor. Therefore F = {Undefined} for 0 <= ? <= ArcTan[Subscript[[Mu], S] – the bookshelf will newer glide in this ? range. F should be Subscript[[Mu], S] Subscript[F, N] for ArcTan[Subscript[[Mu], S] < ? <= 90°.

Physics do limit value of Subscript[F, F]. It must be non-negative. It is the friction force and as such it cannot be negative. The lowest value it can have is 0. The condition is:

Subscript[F, F] := If[Subscript[\[Mu], S] Subscript[F, N] >= 0, Subscript[\[Mu], S] Subscript[F, N], 0] 

where Subscript[[Mu], S] is friction coefficient and Subscript[F, N] is normal force:

Subscript[F, N] := Subscript[F, V] + W := 1500 + F Cos[\[Degree] \[Theta]]

in this particular experiment. Whenever Subscript[F, N] gets negative because of Cos[?] or because of F (the bookshelf could be pushed instead of dragged) then Subscript[F, F] shall be 0 and F should be {Undefined}

If you look at the solution produced by Solve[] in my original post then you can see the condition for F to be computed:

(Sin[?] > 2/5 Cos[?] && Cos[?] > 0) || 
(Sin[?] < 0 && Cos[?] > 0) || 
(Sin[?] < 2/5 Cos[?] && Cos[?] < 0) || 
(Cos[?] < 0 && Sin[?] > 0)

The first and the second test should test for Cos[?] >= 0 then the solution would be flawless.

In my opinion there is a bug somewhere in Mathematica.

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.