LaTeX LaTeX Bug: Identical Pictures with Different Code | Physics Forums

[Borek]

See https://www.physicsforums.com/showthread.php?t=486869

Both pictures identical, but when you click on them code is different.

 

[tiny-tim]

Hi Borek!

I think it's the % symbol that wrecks the LaTeX …

* 100%

3SnF_{2}_{(aq)} + 2K_{3}PO_{4}_{(aq)} \rightarrow Sn(PO_{4})_{2}_{(s)} + 6KF_{(aq)}

(Actual yield)/(Theoretical yield) * 100%

(Actual yield)/(Theoretical yield) * 100

(Actual yield)/(Theoretical yield)

* 100%

* 100​

 

[I like Serena]

I found this in the online help of LaTeX (howtolatex.pdf) on PF:

"Special characters. The following symbols have special meaning in L TEX: # $ % _ { } ~ ^ \
You can print the first seven of these by using \# \$ \% \_ \{ \} ."

So:

(Actual yield)/(Theoretical yield) * 100\%

[edit]Not a bug![/edit]

 

[Borek]

By my book it is a bug - if the code is invalid it should not yield correct, but different image.

I guess image was first generated OK, then message was edited and wrong code was entered, so new image was not generated, but old one WAS NOT DELETED.

 

[I like Serena]

By my book it is a bug - if the code is invalid it should not yield correct, but different image.

I guess image was first generated OK, then message was edited and wrong code was entered, so new image was not generated, but old one WAS NOT DELETED.

So this would be a bug in the PF web server?

 

[Borek]

In the PF script preparing LaTeX images.

 

[D H]

By my book it is a bug - if the code is invalid it should not yield correct, but different image.

There is a subtle misfeature here; it is the same one that forces us to refresh while generating a post that contains [ tex ] blocks. Whether this is a bug worthy of correction is a matter of opinion. Your book is not the same book that the owner of this site uses to make that distinction.

Making software do the right thing given proper input is hard. For the most part, this site does do just that. (Occasionally we do get some weird database errors; those truly are bugs.) Making software do the right thing given improper input is extremely hard, an order of magnitude harder / more time-consuming compared to making software merely do the right thing given proper input.

The right thing to do here is to make one of those "LaTeX generation failed" images such as those seen in post #2.


Is the correction offered by I like Serena in post #3 "correct"?

(Actual yield)/(Theoretical yield) * 100\%

My opinion: Yech. No space before yield, and the spacing in actualyield looks a lot more like the product of a, c, t, u, a, l, ... rather than words. Much better is

\mbox{(Actual yield)}/\mbox{(Theoretical yield)} * 100\%

Or just (Actual yield)(Theoretical yield)} * 100%.

 

[I like Serena]

Making software do the right thing given proper input is hard. For the most part, this site does do just that. (Occasionally we do get some weird database errors; those truly are bugs.) Making software do the right thing given improper input is extremely hard, an order of magnitude harder / more time-consuming compared to making software merely do the right thing given proper input.

In 1979 (quite some time ago), the 6th commandment of Lint was formulated:

"6. If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest ``it cannot happen to me'', the gods shall surely punish thee for thy arrogance."

In short, it takes 2-3 times as much code to handle improper input.
I believe it usually is well worth the effort!
As I see it, the software of the TEX converter does handle improper input, yielding invalid-input images.
However the web server side script does not.

Is the correction offered by I like Serena in post #3 "correct"?

(Actual yield)/(Theoretical yield) * 100\%

My opinion: Yech. No space before yield, and the spacing in actualyield looks a lot more like the product of a, c, t, u, a, l, ... rather than words. Much better is

\mbox{(Actual yield)}/\mbox{(Theoretical yield)} * 100\%

Or just (Actual yield)(Theoretical yield)} * 100%.

No argument there - I agree!
[edit]Minus the misplaced '/' and '}' ;-)[/edit]

 

[D H]

In short, it takes 2-3 times as much code to handle improper input.

If only it were that simple. Even if it was that simple, that still represents a huge cost overhead.

There are times when the even recognizing that the input is improper is extremely hard, if not downright impossible. Some examples:

• Having the compiler determine whether a program halts. First off, there's the halting problem that makes answering this question a bit more than problematic. Secondly, what if the program isn't supposed to halt? Is halting an error? (In many cases, yes it is.)
• Having the compiler determine whether a variable is assigned a value before the variable is accessed. This is equivalent to the halting problem.
• Having a C compiler make sense of i = 5; printf ("%d\n", (i++)*i); The result might be to print 36. Or it might print 25, or 30, or 1234567890. Then it might result in a call reformat_hard_drive() or even eject_nasal_demons(). All are valid responses to such nonsense.

There is no way to anticipate all the goofy ways users can get things wrong. We can try, and trying is a "good thing", but there are no guarantees.

 

[Borek]

Making software do the right thing given proper input is hard. For the most part, this site does do just that. (Occasionally we do get some weird database errors; those truly are bugs.) Making software do the right thing given improper input is extremely hard, an order of magnitude harder / more time-consuming compared to making software merely do the right thing given proper input.

To put things in a perspective - I am earning my living selling software I wrote. I know it is difficult to make completely foolproof software, I never claimed my software is 100% foolproof (quite the opposite - now and then I am shown it is not). Still, it doesn't stop me from trying to make it as foolproof as possible.

 

[D H]

Right, but you are doing it for profit. I also write scientific software, and I do do my best to make it foolproof. There is however a huge cost in doing so -- and even then I care a whole lot more about whether our software works correctly given correct input than I care about how our software works in the face of goofy input.

Greg is doing this for fun, and mostly for free. If physicsforums.com did generate all of or even a significant fraction of Greg's income we would have a significantly increased case here.

 

[Borek]

Right, but you are doing it for profit. I also write scientific software, and I do do my best to make it foolproof. There is however a huge cost in doing so -- and even then I care a whole lot more about whether our software works correctly given correct input than I care about how our software works in the face of goofy input.

Allocation of resources devoted to making program foolproof probably depends on the intended audience and their expected level of computer competence. I must assume I wrote for complete idiots Even then I am sometimes overestimating their knowledge - https://www.physicsforums.com/showthread.php?p=3184107#post3184107

Greg is doing this for fun, and mostly for free. If physicsforums.com did generate all of or even a significant fraction of Greg's income we would have a significantly increased case here.

Totally agreed. But it shouldn't stop us from pointing out errors

 

[I like Serena]

If only it were that simple. Even if it was that simple, that still represents a huge cost overhead.

There are times when the even recognizing that the input is improper is extremely hard, if not downright impossible. Some examples:

• Having the compiler determine whether a program halts. First off, there's the halting problem that makes answering this question a bit more than problematic. Secondly, what if the program isn't supposed to halt? Is halting an error? (In many cases, yes it is.)
• Having the compiler determine whether a variable is assigned a value before the variable is accessed. This is equivalent to the halting problem.
• Having a C compiler make sense of i = 5; printf ("%d\n", (i++)*i); The result might be to print 36. Or it might print 25, or 30, or 1234567890. Then it might result in a call reformat_hard_drive() or even eject_nasal_demons(). All are valid responses to such nonsense.

There is no way to anticipate all the goofy ways users can get things wrong. We can try, and trying is a "good thing", but there are no guarantees.

These are exactly the reasons why programs like Lint were invented, and why compilers have advanced warning capabilities.
The points you mention are reported by Lint as warnings, and I believe modern compilers will report them too.

It is up to the programmer to ignore these warnings, but if he doesn't, his program will become mostly foolproof.

Furthermore we have coding standards.
Afaik the http://www.codingstandard.com/HICPPCM/index.html" is fast becoming the de facto standard for C++.
Again your program will become mostly foolproof-er if you abide by this standard.
And you'll need a code checker tool to tell you if you do.

Current safety-engineering standards (SIL) require that you adhere to such a standard and have tools in place to verify it.

 

[I like Serena]

Allocation of resources devoted to making program foolproof probably depends on the intended audience and their expected level of computer competence. I must assume I wrote for complete idiots Even then I am sometimes overestimating their knowledge - https://www.physicsforums.com/showthread.php?p=3184107#post3184107

Nice one .

So did the customer get his money back?

 

[Borek]

Nice one .

So did the customer get his money back?

Yes. It is much faster and easier to swallow the loss than to argue with people who have no idea what they are doing.