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.

The form is undocumented, so I would not expect it to work. However, the documented form
works:Of course, that's accompanied by the warning

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.

Daniel Lichtblau - props for the calm response! I got angry just reading that post…

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.


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):
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 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...

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 support@wolfram.com, 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,
Peter

(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.

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.    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.