A #collatz step count visualization. Th… by taupelink

function u(t) {

c.width=1920 // clear the canvas
for(i=0;i<9;i++)
x.fillRect(400+i*100+S(t)*300,400,50,200) // draw 50x200 rects

} // 122/140

Please log in (or register) to post a dweet (copy-paste the code somewhere safe to save it meanwhile)


    u(t) is called 60 times per second.
    t: Elapsed time in seconds.
    S: Shorthand for Math.sin.
    C: Shorthand for Math.cos.
    T: Shorthand for Math.tan.
    R: Function that generates rgba-strings, usage ex.: R(255, 255, 255, 0.5)
    c: A 1920x1080 canvas.
    x: A 2D context for that canvas.

show FPS hide FPS share 1 remix fullscreen

taupelink

function u(t) {

f=(N,o)=>N-1?f(N%2?3*N+1:N/2,o+1):o;for(i=1e3;i--;x.fillRect(z%1920,z/1920|0,1,1))z=Math.random()*3e6|0,x.fillStyle=`hsl(${f(z,0)},99%,50%)`

May 10 2020 11:42 PM UTC

}// 140/140

Please log in (or register) to post as a new dweet (copy-paste code somewhere safe to save it meanwhile).

A #collatz step count visualization. The hue at (X,Y) is the steps needed for X+1920*Y to reach 1, or rather it's that step count modulo 360.

u/taupelink

See also d/1711, although that one clears the screen every time (change to Dwitter engine?)
u/pavel

Setting canvas width clears the screen
u/taupelink

Yup...dunno whether it was that way back in 2017
u/taupelink

I mean, just to be clear, d/1711 sets the canvas width every time. That causes the screen to clear. I'm not sure why d/1711 was coded that way...I'm speculating that one possibility is, when it was coded, the Dwitter engine didn't clear the screen when you set the width. Not something I'm all that curious about, to be honest. Carry on! :)


      u(t) is called 60 times per second.
      t: elapsed time in seconds.
      c: A 1920x1080 canvas.
      x: A 2D context for that canvas.
      S: Math.sin
      C: Math.cos
      T: Math.tan
      R: Generates rgba-strings, ex.: R(255, 255, 255, 0.5)

dwitter.net