Known issues with copying code from Mathematica to other platforms?

Question

I just noticed that if you have this in MMA (8.0.1 / win7-64):

and you copy it to SO (just ctrl-c ctrl-v), you get this:

(maxY - minY)/stepy/(maxX - minX)/stepx  

which is not mathematically equivalent. It should be this:

((maxY - minY)/stepy)/((maxX - minX)/stepx)

or this (the InputForm of the above):

((maxY - minY)*stepx)/((maxX - minX)*stepy)

It's not caused by StackOverflow's internals as the same happens with a copy to NotePad.

Are there more issues like this (especially when working with SO, but also in general) that we should be aware of?

What causes this, can it be fixed on our side, and if not, what is the best work-around?

Aloysia

How are you entering the expression? I had to enter the LHS and RHS, and then paste into a x / y form. This may create an unanticipated situation. – Julianjuliana

Just ctrl-/ maxY - minY tab stepy ctrl-space / ctrl-/ maxX - minX tab stepx ctrl-space. If you evaluate this you get the (correct) code that's in the 4th code line above. – Aloysia

Thanks for the correction. I was trying Ctrl+/ for the middle, why I don't know. – Julianjuliana

I am trying to figure out how copy works at a low level, e.g. MakeBoxes, MakeExpression, etc. Is there a page on this somewhere? – Julianjuliana

@Julianjuliana - Copy doesn't use MakeExpression. It's not a ridiculous idea to do so for Input Text copy, where the mission is to preserve evaluation semantics. But doing so would require waiting for a kernel evaluation for every copy and would only work for semantically complete expressions (unlike, e.g., RowBox[{"a", "+"}]). So, a series of heuristics are used to translate to a sensible and readable linear version where possible, and devolve to linear syntax elsewhere. The original question exposes a minor bug in the heuristics, which will be fixed in future versions. – Monohydric

@John Fultz, I did not know you were on StackOverflow. Thanks for the explanation. Is there a way to use an alternate routine, using the kernel, to get around this bug? – Julianjuliana

Answer 1

Copying Mathematica code to the Usenet Mathematica group sometimes scatters all kinds of weird characters throughout your code (you never knew when it would happen to you). The workaround would be either:

1. Cell > Convert To > InputForm and then do a copy

2. Edit > Copy As > Plain Text or Input Text

The latter doesn't work in this case. It's still a mathematically incorrect conversion that you'll get. The former does seem to work.

Update
If you ever encounter strange characters in posts in the Mathematica newsgroup (e.g., as in here) the following function will decode it (in all the cases that I tested).

translateQuotedPrintable[str_String] := 
  StringReplace[str, {"=" ~~ c1:HexadecimalCharacter~~c2:HexadecimalCharacter :> 
    FromCharacterCode[FromDigits[c1 <> c2, 16], "Math1"],"=" ~~ EndOfLine -> ""}]

Just paste the whole posting between quotes in translateQuotedPrintable[" ... "] and the post will be cleaned up.

For the curious: the encoding that you may see in these usenet postings is called Quoted Printable. It is used to convert character encodings that differ from the standard 7-bit ASCII set to ASCII. Many common MMA symbols, like the Rule symbol, are encoded this way if not previously converted to ASCII by InputForm cs. To decode a code one needs to know the original character set because QP only yields the hexadecimal position in the character set. In MMA's case this will most commonly be Math1.

Aloysia

Answer 2

Copying the example to e-mail ALSO fails, and that -- if it carries over to other examples -- seems very bad for Mathgroup, SO, and any other text-based discussion forum. Copy As>Plain Text and Copy As>Input Form both work properly, but I've done it the easy way thousands of times, and never knew it could fail this way, WITHOUT strange hexadecimal characters.

Implosive

Hello Bobby Treat, welcome to StackOverflow. What version / platform are you using on which the Copy As method works? It fails for Sjoerd on v8, and for me on v7. – Julianjuliana

Hi DrMajorBob, welcome to the other side! I don't think we'll find many examples like this. We should have noticed somewhere the last few years. But I got bitten here (https://mcmap.net/q/1166046/-adaptive-gridlines/…), where my own code, when copied back to Mathematica, yielded erroneous results. – Aloysia

Answer 3

This is a good example of how MMA is set up to resolve mathematical ambiguity introduced in typesetting. (+1)

The reason it fails is that you've not yet evaluated the original expression. When you evaluate, Mathematica correctly parses the "/" between the two chunks and the output can be copied and pasted (correctly).

Perhaps WRI should make it so that 'Copy' forces the parsing mechanism to occur prior to clip-boarding the expression --- i.e., some sort of 'soft' evaluation. Thoughts?

Eleazar

The expression above is part of a module definition that has been evaluated quite often. Of course, this doesn't change the original code. The goal of evaluating a definition (especially when done with SetDelayed) is not to produce a parsed version of this input as output, and usually it doesn't. One should be able to copy the code (especially when it is not in ambiguous TraditionalForm) and paste it elsewhere. – Aloysia

There is no mathematical ambiguity in StandardForm (it was designed precisely to remove all such ambiguities). The front end has exactly the information required to reproduce the correct text when copied. The problem is merely a bug which had gone unnoticed until this report. – Monohydric