9

Bug introduced in 7.0 or earlier and persisting through 11.0

While looking at A question about conditional replacement I think I discovered a bug in the Front End that affects both 7.0.1 and 10.0.1 under Windows.

If I copy and paste this line into a new Cell in a Notebook:

{g[x, y, z], h[x, y], f[]} /. (f_[t___] /; f != List) :> Plus[t]

then select ≠ (auto-converted to single character) and type over it =!= and evaluate I get:

{g[x, y, z], h[x, y], f[]}

Rather than the expected:

{x + y + z, x + y, 0}

If I use menu Cell > Convert To > InputForm the input cell is converted to:

{g[x, y, z], h[x, y], f[]} /. ((f_)[t___] /; f) =!= List :> Plus[t]

Note the parentheses: ((f_)[t___] /; f) is grouped separately from =!= List. The RHS therefore evaluates to:

True :> +t

Does this problem affect all recent versions on all platforms or is it more localized?

Community
  • 1
Mr.Wizard
  • 271,378
  • 34
  • 587
  • 1,371
  • reproduced in V9.0.1.0 (windows 8) – kglr Nov 02 '14 at 05:02
  • Reproduces in versions 8.0.4 and 10.0.1 under Win7 x64. Instead of converting the Cell to InputForm I just add //Hold at the end of the expression and evaluate it again. – Alexey Popkov Nov 02 '14 at 05:03
  • Strangely enough, if you add a space anywhere before or after =!=, or edit anything else inside the parantheses, it gives the expected output. – kglr Nov 02 '14 at 05:14
  • 1
    After you substituted =!= you can simply go left of the f and press Ctrl+. for expand selection. You see that the front-end parses it incorrectly because /; seems to have a higher precedence. Weird. Btw, M8.0.4 on OSX. – halirutan Nov 02 '14 at 05:49
  • Yep. Reproduced 10.0.1.0 on Mac OS X. – Mark Adler Nov 02 '14 at 06:18
  • @halirutan As I think you know I am well aware of that method. I chose Shift+Ctrl+I in this case because the result was easier to display in my question, and because the actual insertion of parentheses indicates that grouping is non-standard. Thanks for the report, BTW. ;) – Mr.Wizard Nov 02 '14 at 08:00
  • Persists in 10.4.1 – vapor May 13 '16 at 10:20
  • Do you think http://i.stack.imgur.com/smo9Z.gif is the same bug or would it be worth opening a separate post for this? (Looking at InputForm, in the first line there's actually a (a/*b)@*c.) This was on Mathematica 11.0. – Martin Ender Sep 23 '16 at 15:31

1 Answers1

6

I think when you press = over ≠, the underlying RowBox-es got re-grouped (which is a correct move), but somehow didn't re-group again when finishing input =!=. I don't know if the FrontEnd is supposed to re-parse code every 1/n second, but it does look like a bug to me.

One possible workaround: Select the cell, from the Edit menu, Copy As Plain Text, paste in to an empty Input Cell. This should enforce re-parsing the code.

Silvia
  • 27,556
  • 3
  • 84
  • 164
  • 1
    ... yet another work-around: type =!= in the order !=+ backspace + backspace = :) – kglr Nov 02 '14 at 07:06
  • @kguler Or can we enforce an in-place re-parsing on the Cell? :) – Silvia Nov 02 '14 at 07:08
  • Actually, retyping of any character to the left of =!= inside (f_ ... List) seems to force re-parsing. – kglr Nov 02 '14 at 07:20
  • @kguler Yes I saw your comment :) Off topic: sometimes I wonder why human write code in plain text and ask for a parser to analyse/formalize it. It's unnatural ... – Silvia Nov 02 '14 at 07:30