euclidOff \neq euclidOffBool

Innards
1

I was surprised that these don't have the same structure:

"1(3.8)" :: Pattern Int
-- 3 events, value 1, at times 0, 3/8, 3/4

"1(3,8)" :: Pattern Bool 
-- 8 events, values True, False, False, True ..

I found that the parser (argh, again, semantics hidden in the parser (*)) uses euclidOffBool in the first case, but euclidOff in the second. https://github.com/tidalcycles/Tidal/blob/1.10-dev/src/Sound/Tidal/ParseBP.hs#L272

Now, the API doc for euclidOffBool claims "As euclidOff, but specialized to Bool - which is wrong:

euclidOff     3 8 0 (pure True)  -- three events (values are True)
euclidOffBool 3 8 0 (pure True)  -- eight events (one at each tick)

Bug or feature?

API doc also claims "May be more efficient than euclidOff." Has this been benchmarked? I am actually getting the reverse relation

tidal> :set +s

tidal> length $ flip queryArc (Arc 0 1) $ euclidOff     54321 56789 0 $ pure True
54321
(1.86 secs, 447,929,936 bytes)

tidal> length $ flip queryArc (Arc 0 1) $ euclidOffBool 54321 56789 0 $ pure True
56789
(2.03 secs, 622,937,856 bytes)

But the method of evaluation may be too simple.

Does anyone need high performance of this function? Seems a bit esoteric. But - there was 4096 bpm at Solstice 23 ...

[EDIT] speaking of efficiency .. The following implementation is shorter and faster, but

bjorked (k, n) =
  if k == 0 then replicate n False
  else let (d,m) = divMod n k
       in  bjorked (m, k) >>= \ b ->
             True : replicate (if b then d else d-1) False

tidal> length $ filter id $ bjorklund (832040, 1346269)
832040
(1.56 secs, 1,385,597,184 bytes)

tidal> length $ filter id $ bjorked (832040, 1346269)
832040
(0.77 secs, 736,101,088 bytes)

but (huge BUT) it's wrong: it produces an evenly spaced pattern with the correct number of events, but in some different rotation. I wonder if there's a way to fix this.

[EDIT] of course (?) a more efficient "wrong" answer is

bjork (k, n) =
  let go x = if x < 0 then True : go (x+n-k) else False : go (x-k)
  in  take n $ go (negate k)

ghci> length $ filter id $ bjork (832040, 1346269)
832040
(0.43 secs, 561,463,216 bytes)

but again, it's not quite the right rotation.