Message Boards Message Boards

16 Replies
10 Total Likes
View groups...
Share this post:

Why is it OK for low-precision Solve to work like this?

Posted 11 years ago
Consider the following.
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? *)
{elem,Solve[{reqn,gramsPerAtom atomsPerUnitCell/volumeOfUnitCell==density},{a,r},Reals]}
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.
16 Replies
I'll address what I can.

(1) Entering input and formatting as such does have issues. I believe they are receiving some attention but, as you might guess, people hereabouts get put on multiple projects and sometimes some have to wait for others.

(2) I stand corrected, it is Edit > Copy As > Input Text. Also Plain Text might work.

(3) The notebook you attached is fine insofar as I, and others, can run the calculations therein without retyping. Basically any form of input that can be run without retyping is just fine.

(4) I ran into a separate issue when testing it, which I sent to the relevant person. As best i can tell modulo that issue, the actual Solve precision problem seems to be fixed.

(5) I am not familiar with the correspondence that went to Support. All I can say is there was a bug showing in the original post from 6 months ago. You raise the issue of how something like that can go undetected. It's because, unlike NSolve, Solve was never really intended for approximate numerical computation. Of late, with the Quantity support now in place, Solve, Integrate, and others do more frequently get used with approximate values. So unforseen problerms do appear, and we fix them when we find them.

(6) The resources that go into updates are considerable. One can certainly take the position that we should put more into that. I will point out that it would happen at the expense of regular releases (which come with both new/extended functionality, and a considerable number of fixes).

(7) Solving over reals is, for some classes of problem (especially multiple equations and unknowns), much harder than solving over complexes. I don't dispute what you stated about slowness in the paragraph titled "Solve and inequalities", just pointing out that there are technical reasons for the slowness. As for the issue of "nonsensical answers", if you are referiing to what you found in the original post, then yes, it's far from what we'd want. All I can say is it was not by intent. If you had in mind something else then I would need to know what it is in order to comment.
POSTED BY: Daniel Lichtblau
Daniel Lichtblau - props for the calm response! I got angry just reading that post…
POSTED BY: Patrick Stevens
Posted 11 years ago
Just some random thoughts.

. I am done with this.  If you want to fix the problem -- or it's fixed in some development line -- fine.  I will do my bug workarounds and will do my best to keep out of the forum and Support.  For this problem, IT APPEARS I always get a ridiculous-looking answer when the problem presents, so the workaround approach can work.

. The paramount issue here (ahem, not the only one) is not just a new example of Mma not computing correct output: it is that Wolfram knows about the problem and doesn't consider it a serious enough problem to issue a stability update and/or to inform users (I'm a user and have not been informed via an e-mail, etc.).  And there's the now-rhetorical question of whether I'm being unreasonable.

. I'm sorry, but considering the HOURS and HOURS I have wasted on this problem (in the two forms you see in this thread and many others and practically begging Support to look at the problem again and again after they repreatedly insisted it wasn't a bug; almost immediately here someone said it was a bug and was in fact a regression from Mma 8), I don't consider asking you to enter a few simple lines of Mma code -- I gave you all you needed -- a hardship.  I tried to enter the text, and the interface made it look bizarre.  The closest thing to decent-looking output I could find was an image.  I have subsequently uploaded a .NB file, which I believe is usable.

. I do not have COPY AS InputForm, but I do have "copy as input text," which makes a mess of the screen when I enter it and label it MCode.

. Solve and inequalities.  emoticon  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.

. If Solve[] cannot do something, it should tell me it can't do it -- not serve up a nonsensical answer.

. If you don't use the /.vals (which I don't until, usually, the end, because I want to study the formulaic output), and then /.vals the closed-form solution that Solve[] generates, I have been able to get it to work, even in Mma 9.  Don't ask me the internals of why/how.  But if you get a closed-form solution, you may be able to bypass the computational problem.

. I used the equivalent of QuantityMagnitude[UnitConvert[#]]& to get vals in a format suitable for input to Mma 8, which I actually own also.  When I do that, I get the right answer in Mma 8.  But I don't know if this is a fair test.  So I did the same thing in Mma 9.  And then it said height=0.  So I give up.  I don't care anymore.  Wolfram, do what you want.

. To repeat: this is my last entry on this subject, this thread, whatever.  Wolfram has worn me out for the last time.  Call me unreasonable if you want.  I don't care.  I will watch to see if anyone says it's a user error (and I'm missing something).  Otherwise, good bye.
Solve is basically for infinite precision problems.   NSolve has an option, "WorkingPrecision".
Solve also has that option, but I believe it is for situations involving inequalities.  The default value
is Infinity.
POSTED BY: Frank Kampas
the original source, Solve[SetPrecision[1234,4]/x==1], is of course simple to enter or to cut/paste. I tried it prior to responding. It seems fine in the development version of Mathematica.

The source in the follow-up nb is not something I would care to retype. Nor would I go to the trouble of locating OCR software (or trying to code it in Mathematica). That would be very much an assymetry in our relative efforts to look into this issue. Now that I have the notebook I'll see what I can find out.

As for entering input in a way that can be cut-and-pasted, I recommend as a first attempt simply copying from nb to here. Copy should convert to Mathematica's InputForm. If that fails, use Edit > Copy As > InputForm. Entering the output that way is often fine, or it can be done as an image if you prefer.
POSTED BY: Daniel Lichtblau
Posted 11 years ago
I thought the source was simple enough that you could just enter it.  OCR could've been used.  Regardless, I've attached a notebook (I believe).  I also got rid of the use of my functions, to make clear what the Mma code is.  And I used a fresh kernel.  It appears to be the same basic thing as the original post.  In this case, I would like to think that 8-digit precision is "not too low."  Clearly there's something wrong with Mma, and Wolfram's agreed (based on the original post).  What I cannot fathom is why Wolfram hasn't fixed it in a timely manner nor alerted the user community.  Imagine you bought a calculator and it didn't always work?  Remember when the Intel chip had difficulty doing floating-point operations?  Am I being unreasonable?  I realize no one has  to answer me.  But can anyone explain why I think this is important and Wolfram apparently doesn't?

The image below should be in the attached as a notebook.  If not, please advise, and this time tell me how you want me to upload the source.  I do know I can copy as text, and just paste that in here.  It would look like a mess, based on my experience.  I'll do that if you want me to do that.

(1) It would be helpful if this were posted in plain cut-and-pastable text. As it stands I cannot do anything to test it.

(2) I do not know of any release in the past 6 months. The problems you reported might have been addressed for the next release.
POSTED BY: Daniel Lichtblau
Posted 11 years ago
It's been about six months since I submitted this "bug report," and Mathematica still isn't fixed.  While mostly everyone's been polite, and I've been assured that this "bug" is recognized as a regression, the bottom line is it still isn't fixed!

I run into this problem routinely!  The only reason I know when the problem hits again is the absurd answers I get.  Here is just the latest example.  (The function definitions should be obvious to anyone.)  NOTE: after wasting a bunch of time trying to simply upload the text, I gave up and uploaded the image.  GRATUITOUS COMMENT: Yeah, only on the order of 300 lines of input: the kernel crapped out on me again recently.

This is a simple computation.  It computes the (approximate, I'm sure) height above the earth for a satellite to attain a geosynchronous orbit.  As you can see, the Earth's mass's precision (8) is what's "causing the  problem."

I didn't bother to see if this works in Mma 8 because I didn't want to go through the trouble of defining the constants.  sol2 is the only correct answer.  It switches M's precision to MachinePrecision.

I am sorry, but Wolfram (the company, not the man) should be ashamed of itself. How you could be allowing all sorts of computations to be faulty for so long (now that you know your regression testing did not properly check your code changes in Mma 9) is beyond me.  I wonder what serious (professional) calculations are wrong out there because of this terrible bug (regression).  (I call it a regression because of one of the above comments -- it worked in Mma 8.  I also assume this current example is basically the same bug as in my original report, the content of which I am not even reviewing.  But I seem to recall the "bad precision" was 4.  Here it's 8.  The mind reels.)

I recently bought the student version of MATLAB for $99 (1/3 the cost of Mma Home Edition).  MATLAB has many aggravating features, but it's never given me the wrong numeric output (that I know of).  I have yet to find any "bugs" in it, just aggravating features.  Compared to Mma, it is easier to learn to use.  But I still prefer Mma.  But it's aggravating as hell when I have to search for why an answer doesn't make sense.  How many times have I rejected a "correct" approach only because Mma can't do arithmetic properly?  And don't get me started on the ability of Mma to compute simple solutions to simple sets of equations.  Reminds me of one of the comments above (which I am not re-reading now): DO NOT GET RID OF the second set of variables (see this post's examples): we need them; we cannot get the same functionality using the new option (MaxExtraConditions or whatever it's called).
Posted 11 years ago
Dear robv,

my name is Peter Fleck, I'm heading the Wolfram Technology Group which among other services also provides Technical Support to our valued customers.

Thank you very much for sending us your issue reports to, and particularly for boiling the issue down to a simple one-line evaluation. We respond to most support requests within 3 business days, but cannot guarantee this turnaround time in all cases.
You should be receiving the reply to your most recent report, the one alerting us to the Solve[SetPrecision[1234,4]/x==1] example, very soon.

Thank you,
POSTED BY: Peter Fleck
Posted 11 years ago
Thanks for the heads-up on MaxExtraConditions.  I modified my "solve" function to use it.  I find the only way to productively use MaxExtraConditions is to start at zero (0), and increment by 1 until a solution is found.  This is subject to change.  This (so far) allows me to specify the variables I want, and not have to worry about how many variables Solve needs to actually solve the equations.  I currently throw away the "condition" in ConditionalExpression, but I might someday check its format to make sure I'm not throwing away anything important (so far it seems to list the values of the variables I don't care about).  My "solve" function now runs quicker than it used to run.

We had no way of knowing whether the incorrect-result problem and extra-variable problem were related.  All we could determine was things weren't quite right, and there were lots of variations on the theme.  It sounds like there are at least two problems that need to be fixed.  Please note: In the above example, the extra-variable problem "fails" only when "Reals" is added to the Solve.

Regarding the (original) "incorrect-result problem," if what I read here is to be believed (why wouldn't it be?), I would expect to formally hear back from Mathematica Support.  I submitted the first in a series of "bug" reports on this problem while my 30-day Home Edition support period was in force.  (I have since stopped submitting "bug" reports.)  Whether and when a "fix" is issued, it remains unclear to me how it will be distributed and documented to the Mathematica user community.  (I have submitted at least one "bug" report that was acknowledged -- obviously not this one -- and I was told a fix would be issued, but that was the last I heard.)  I can only hope someone will determine whether research results, directions, etc. could have been affected.  Needless to say, when/if I gain access to a newer version of Mathematica, I will check this problem.  I doubt I'll do extensive regression testing, however; I'll leave that up to Wolfram.  For reference purposes, the last e-mail I sent to Mathematica Support had the subject line: "RE: [CASE:379797] Feedback, [CASE:379560] Question about solution from Solve".  In it I practically begged Mathematica Support to take another look at the "problem"...
The results for In[51] and In[60]  come from an overhaul of Solve for Mathematica 8.0.
Extra, unused variables are not treated the same now.

Boilerplate I had:
The difference between 7.0 and 8.0 output is that 7.0 Solve was
treating equations that involved only variables as assumptions.
This functionality was not precisely defined or consistently
implemented and has been removed in 8.0.  Instead there is a
new option MaxExtraConditions which provides a well-defined and
extended version of the functionality. 

MaxExtraConditions is given a number at least as big as the number of unused variables.
 In[2]:= Solve[{r==x,1234`4/x==1},x, Method->"Legacy" ]                                 
 Out[2]= {}
 In[3]:= Solve[{r==x,1234`4/x==1},x, MaxExtraConditions->1]                             
 Solve::ratnz: Solve was unable to solve the system with inexact coefficients. The answer
     was obtained by solving a corresponding exact system and numericizing the result.
 Out[3]= {{x -> ConditionalExpression[1234., r == 1234.]}}

p.s., None of the previous repliers in this thread are in the Technical Support Group.

p.p.s. The incorrect-result problem in
is different than the extra-variable issue in
POSTED BY: Bruce Miller
Posted 11 years ago
I've tried to reply to specific messages, but the Reply button doesn't always work.  I think I am replying to the whole discussion now.  I would like to address some issues.

My buddy and I are aware of workarounds.  MachinePrecision and Rationalize[xxx,0] seem to work pretty well.

Regarding the Solve syntax error: if that's truly the case, Mathematica should warn us.  Consider the following two examples.

In[47]:= Sin[1,2]
During evaluation of In[47]:= Sin::argx: Sin called with 2 arguments; 1 argument is expected. >>
Out[47]= Sin[1,2]

In[48]:= SetPrecision[5]
During evaluation of In[48]:= SetPrecision::argr: SetPrecision called with 1 argument; 2 arguments are expected. >>
Out[48]= SetPrecision[5]

The much-valued online help in Mathematica does not exactly use BNF in its syntax templates, but they get the message across.  But I would like to call your attention to a feature of Solve that is not (no longer?) documented.  Parameter 3 is a list of variables you do not want to show up in the solution.    For example (NOTE: if I convert this to Code, it automatically deletes the other Code example below, so I have not converted to Code format):
In[50]:= Solve[{x+y+z==1,x+2y+3z==2,x+4y+9z==3}]
Out[50]= {{x->-(1/2),y->2,z->-(1/2)}}
In[51]:= Solve[{x+y+z==1,x+2y+3z==2,x+4y+9z==3},{x}]
Out[51]= {}
In[52]:= Solve[{x+y+z==1,x+2y+3z==2,x+4y+9z==3},{x},{y,z}]
Out[52]= {{x->-(1/2)}}
The phenomenon at "line 51" was maddening until I wrote a function to search for solutions I wanted.  Anyway, that was a case of a parameter that is not documented.  You can tell Solve what variables not to include in its solutions.

I don't remember if we noticed that the problem "seemed to go away" when we added the ",x" to the Solve.  However, that does not solve the problem in general.  Consider the following sequence, which is closer to what was going on when I discovered the "problem."
 In[58]:= Solve[1234`4/x==1]
 Out[58]= {{x->1.000}}
 In[59]:= Solve[1234`4/x==1,x]
 During evaluation of In[59]:= Solve::ratnz: Solve was unable to solve the system with inexact coefficients. The answer was obtained by solving a corresponding exact system and numericizing the result. >>
 Out[59]= {{x->1234.}}
 In[60]:= Solve[{r==x,1234`4/x==1},x]
 Out[60]= {}
 In[61]:= Solve[{r==x,1234`4/x==1},{r,x}]
 During evaluation of In[61]:= Solve::ratnz: Solve was unable to solve the system with inexact coefficients. The answer was obtained by solving a corresponding exact system and numericizing the result. >>
Out[61]= {{r->1234.,x->1234.}}
In[62]:= Solve[{r==x,1234`4/x==1},{r,x},Reals]
Out[62]= {{r->1.000000000000000,x->1.000000000000000}}
In other words, adding "Reals" results in the "problem."  We have found all sorts of ways to get weird results, but thought we boiled it down to the leading example.

Finally, we (I) submitted multiple "bug" reports on this to no avail.  Mathematica Support kept telling me it was not a problem.  If Mathematica Support is now claiming there is a problem, what did I do wrong?

Sorry for the sloppy exposition, but sometimes Reply doesn't work, sometimes converting to Code deletes other lines, etc.  However, publishing and then editing allowed me to "format" the Code.  Go figure...
Let's say it is implicitly documented. Besides, this exact example used to work just fine in previous versions. The appropriate developers are now aware of this issue and will be looking into it.

POSTED BY: Ilian Gachevski
The form
is undocumented, so I would not expect it to work. However, the documented form
Solve[eqns, vars]
Solve[1234`4/x == 1., x]
(* {{x -> 1234.}} *)
Of course, that's accompanied by the warning
Solve::ratnz: Solve was unable to solve the system with inexact coefficients.
  The answer was obtained by solving a corresponding exact system and numericizing the result.
POSTED BY: Robert Collyer
Also I am curious that why NDSolve seems to work ok with the low precision: 

The last value also shows that the working precision is just around 4. 
POSTED BY: Shenghui Yang
No, this is definitely not OK. Thank you for bringing this issue to our attention. For now, I would suggest using a workaround along the lines of
Solve[SetPrecision[{reqn, gramsPerAtom atomsPerUnitCell/volumeOfUnitCell == density}, 20], {a, r}, Reals]

(* Out[22]=

Pb    {{a->4.951026479623944*10^-10 m,r->1.750452198788126*10^-10 m}}
Ag    {{a->4.087668466298753*10^-10 m,r->1.445209045881131*10^-10 m}}
Ni    {{a->3.524028160167008*10^-10 m,r->1.245932104573222*10^-10 m}}
Au    {{a->4.077382180171091*10^-10 m,r->1.441572294544084*10^-10 m}} *)
POSTED BY: Ilian Gachevski
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
or Discard

Group Abstract Group Abstract