Consider the following.
Solve[SetPrecision[1234,4]/x==1]
{{x->1.000}}
x=1234, not x=1. I brought this to the attention of Mathematica Support a number of times in a number of ways (I think they’re sick of hearing from me), and each time they said Mathematica was functioning fine. Mathematica Support also gave me various workarounds, e.g., use of Rationalize for use with low-precision numbers. I’m a Home Edition user.
It seems to me that Mathematica is giving the wrong answer, and it issues no warning.
I showed this to a friend, and he agreed with me: something is wrong. Would anyone else out there like to comment?
We weren’t just trying to find ways to make Mathematica produce questionable results. I certainly depend on Mathematica’s numeric results, and never questioned Mathematica output until I ran across a situation where it returned a negative number for a lattice constant. This is shown in the artificial example below. ElementData can return low-precision (measured) numbers. In some cases, Mathematica can compute “weird” numeric outputs. Mathematic Support said Mathematica is working fine, and it us up to me to make sure I avoid problems like this. (Until I spotted the negative number, I didn’t know there were problems like this to avoid! That’s part of the “problem”: Mathematica issues no warning, as it does under other conditions in other contexts!)
(* here's how I came upon this (what I call) weirdness: computing the so-called lattice constant (a) and atomic radius (r) for an atom in an FCC crystal; in the simplified example below, the lattice constant is the distance between selected atoms in a crystal *)
(* the following artificial example is for one atom at an FCC lattice point; under limited testing, until I ran into Ni, I had no reason to doubt Mathematica's output; I did not notice Ni was "weird" because of its magnitude; I noticed it was "weird" because of its sign; so, are [Pb] and Ag wrong? how do I know? *)
elemar[elem_String]:=Module[
{gramsPerAtom,atomsPerUnitCell,volumeOfUnitCell,reqn,density},
gramsPerAtom=Quantity[ElementData[elem,"AtomicWeight"],"g/mol"]/Quantity[1,"AvogadroNumber/mol"];
atomsPerUnitCell=4;
volumeOfUnitCell=a^3;
reqn=4r==Sqrt[2]a;
density=Quantity[ElementData[elem,"Density"],"kg/m^3"];
{elem,Solve[{reqn,gramsPerAtom atomsPerUnitCell/volumeOfUnitCell==density},{a,r},Reals]}
];
Grid[Map[elemar,{"Pb","Ag","Ni","Au"}],Alignment->Left]
Pb {{a->0.0445 m,r->0.01573683247679559 m}}
Ag {{a->4.088*10^-10 m,r->1.445209045881131*10^-10 m}}
Ni {{a->-7.31*10^-9 m,r->-2.582782168919389*10^-9 m}}
Au {{a->-1.09*10^-8 m,r->0 m}}
EDIT: “Pg” above has been edited to “Pb”. Clearly the Pb values are wrong (by orders of magnitude). And they’re positive.
Have you ever had a series of equations that, when solved, give you all sorts of theoretical answers (imaginary, etc.), so you throw in something like x>0&&y>0? It then just sits there and hangs. Very annoying. Anyone working with Solve must have run into this, so I’m not going to elucidate. You throw in Reals, and then you might get Root[] stuff or I’m not sure what. Solve[] is powerful, but sometimes aggravating.