Wrong envelope for cubic segment

[byorgey]

This code:

{-# LANGUAGE NoMonomorphismRestriction #-}

import qualified Data.FingerTree                as FT
import           Diagrams.Backend.Cairo.CmdLine
import           Diagrams.Coordinates
import           Diagrams.Prelude

t :: Trail R2
t = Trail (Line (SegTree {getSegTree = FT.fromList [Cubic ((-0.3009523809523811) & 1.480952380952381) ((-1.2419047619047618) & 2.961904761904762) (OffsetClosed ((-1.9085714285714284) & 1.9285714285714288)),Cubic ((-0.8333333333333335) & (-1.291666666666667)) ((-1.2380952380952381) & (-6.511904761904763)) (OffsetClosed ((-1.0) & (-8.0))),Cubic (0.23809523809523814 & (-1.4880952380952377)) (1.119047619047619 & 0.7559523809523814) (OffsetClosed (2.0 & 3.0))]}))

main = defaultMain (strokeT t)

produces this (wrong) image:

Note how the top of the trail is cut off. Presumably the envelope is being computed incorrectly. One thing to work on short of fixing the bug is to produce a simpler trail which still exhibits the bug.

[byorgey]

Progress: I've whittled the code down to the following, which still exhibits a wrong envelope:

{-# LANGUAGE NoMonomorphismRestriction #-}

import qualified Data.FingerTree                as FT
import           Diagrams.Backend.Cairo.CmdLine
import           Diagrams.Coordinates
import           Diagrams.Prelude

t :: Trail R2
t = Trail (Line (SegTree {getSegTree = FT.fromList [Cubic (0 & 1.480952380952381) ((-1) & 2.961904761904762) (OffsetClosed ((-1) & 0))]}))

main = defaultMain (strokeT t # pad 1.1)

producing this image:

[byorgey]

More progress: this segment has a bogus envelope:

seg :: Segment Closed R2
seg = Cubic (0 & 1.480952380952381) ((-1) & 2.961904761904762) (OffsetClosed ((-1) & 0))

λ> let Just e = appEnvelope $ getEnvelope seg
λ> e unitY
0.0

[byorgey]

This results in a call to quadForm (-13.32857142857143) 0.0 4.442857142857143, i.e. solving the equation (-13.32857142857143) x^2 + 4.442857142857143 = 0. Note that 4.442857142857143 / 13.32857142857143 is (almost) exactly 1/3, so this should have plus or minus 1 / sqrt 3 as solutions. Instead, quadForm returns [0.0,-Infinity]. I think the problem is simply that we need a special case for b = 0, since the general case clearly does not handle that (when b = 0 we get q = 0 and hence [q/a,c/q] = [0, Infinity]). I'm kind of surprised we never ran into this before (or that the quickcheck property didn't catch it).