7
$\begingroup$

This has got to be the weirdest Mathematica bug in my (not all that small) collection...

I'm using "10.4.0 for Linux x86 (64-bit) (February 26, 2016)".

Here's the code:

annotatedArrow[p_, q_, label_] := {
     Arrowheads[{{-0.05, 0},
                 {$MachineEpsilon, 0.5,
                  Graphics[Inset[Framed[Style[label, Medium],
                                        Background -> LightGray,
                                        FrameStyle -> Directive[Thickness[0], Opacity[0]]]]]},
                 { 0.05, 1}}],
      Arrow[{p, q}]
   }

Manipulate[
  Graphics[{annotatedArrow[{0, height}, {right, height}, "wannadance?"]},
           PlotRange -> {{0, 0.2}, {0, 0.25}}, ImageSize -> 200] // Framed,
  {{height, 0.2  }, 0, 0.24, LabeledSlider}, {{right , 0.136}, 0, 0.2 , LabeledSlider}
]

The annotatedArrow function is adapted from a similarly named function given in the documentation for Arrow.

This code produces a Manipulate widget, with two sliders on it, plus a Graphic featuring a labeled double-headed arrow. (See figures below.)

The "height" slider controls the vertical position of the arrow.

The "right" slider controls the position of the right arrowhead.

These behaviors are available "by design".

But, as a bonus, depending on the setting of these sliders, the label on the arrow will be tilted in one of three possible orientations:

Mathematica graphics

Mathematica graphics

Mathematica graphics

I have no idea why this happens, since the code I'm using does not mention rotations at all.

$\endgroup$
  • 3
    $\begingroup$ Possibly it's due to some internal manipulation of Arrowheads. Try to change that $MachineEpsilon to 0 and you can find it's position is shifting! So I strongly suspect when dealing with arrowheads' drawing, mma do some not-that-accurate evaluations which leads to some numerical error, and by some mechanisms determining Arrowhead's direction like ArcTan[ $MachineEpsilon,error introduced], the direction shifts. A simple solution shall be using 1.*^-10 instead of $MachineEpsilon ------ They are so risky and so easily interfered by internal not-that-precise evaluations. $\endgroup$ – Wjx Mar 26 '17 at 17:06
  • $\begingroup$ @Wjx: Your idea with using 1.*^-10 instead of $MachineEpsilon was an inspired one. Thanks! $\endgroup$ – kjo Mar 26 '17 at 17:49
  • 1
    $\begingroup$ Using $MachineEpsilon caught my eye as suspicious as well. This value is sometimes used as "a small number", but in relative terms it is huge compared to zero and negligible compared to numbers larger than unity. So while I agree with @Wjx that this is probably an effect of imprecise numerical evaluation, in choosing such a value that by its nature has equal magnitude to the discontinuity of the floating-point number line, you are almost asking for such effects to be emphasized. $\endgroup$ – Oleksandr R. Mar 26 '17 at 18:11
  • 3
    $\begingroup$ I know that this clearly looks like a bug, but it would still be good if in the future you could stick to protocol and not use the bugs tag on your own posts. Let someone else add it. If high rep users keep doing this, how can we tell newcomers not to do it? $\endgroup$ – Szabolcs Mar 26 '17 at 19:01
  • $\begingroup$ If I set the size to $MachineEpsilon/10^29, then often the "wannadance?" disappears (except sometimes for the top row of pixels) until I click somewhere or scroll. $\endgroup$ – Michael E2 Mar 26 '17 at 20:29
3
$\begingroup$

I wonder if this is the programmer breaking an unwritten rule about the numerics of graphics. I mean I would expect numerics issues in graphics, just like in other floating-point computing. For example, Cos[Pi/2.] != 0 returns True.

Some evidence for @Wjx's comment and the preceding cosine example:

Graphics[{
  Line[{{-1, 0}, {1, 0}}],
  Text[
   Framed[Style["wanndance?", Medium], Background -> LightGray, 
     FrameStyle -> Directive[Thickness[0], Opacity[0]]],
   {0, 0},
   {0, 0},
   Through[{Cos, Sin}[ArcTan[$MachineEpsilon, Cos[Pi/2.]]]]  (* direction vector *)
  }], 
 ImageSize -> Tiny]

Mathematica graphics

Looks like the same angle:

Mathematica graphics

I'm not sure it is fair to call this a bug in Mathematica.

$\endgroup$
  • $\begingroup$ The behavior of Arrowheads[{{x, ...}, ...}] is discontinuous at x = 0. (This motivated my in-retrospect-unwise fix with $MachineEpsilon). That discontinuity of behavior is a design bug, IMO. I see no justification for it, even if x = 0 is a corner case. $\endgroup$ – kjo Mar 26 '17 at 22:03
  • $\begingroup$ I see. That's a somewhat different issue. According to the docs, the scaling factor x is the ratio between a unit in one coordinate system and the width of the graphic. Thus it is supposed to be greater than zero by definition. Unless you set your unit to be zero. Could be done, but it won't have standard properties. E.g. a line from {a, b} to {c, d} becomes a line from {0, 0} to {0, 0} if you scale by zero. That's ok for drawing the scaled line, but no good if you need its direction. One might like to ship out the scaled coordinates and be done, but it won't work on your example. $\endgroup$ – Michael E2 Mar 26 '17 at 22:57
2
$\begingroup$

There is no reason to specify $MachineEpsilon in the definition of annotatedArrow. I believe a correct specification would be would Automatic. The following code which uses Automatic is entirely well-behaved.

annotatedArrow[p_, q_, label_] :=
  {Arrowheads[
     {{-0.05, 0},
      {Automatic, 0.5, 
         Graphics[
           Inset[Framed[Style[label, Medium], 
           Background -> LightGray, 
           FrameStyle -> Directive[Thickness[0], Opacity[0]]]]]},
      {0.05, 1}}],
   Arrow[{p, q}]}

I assert the bug demonstrated in the question is not a Mathematica bug, but a programming error on the part of the OP.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.