All recent versions of Processing seem to include this error. According to the web
reference, arc() takes its starting and ending angle arguments in radians or degrees
(depending on the angle mode). The thing is, in radian mode, arc() does not
actually use radians - it seems to use negative radians. Radians start straight to the
right at zero, and increase counterclockwise. arc()'s angle arguments start straight to
the right at zero and increase clockwise.

this works exactly as expected for me:

size(200, 200);
arc(100, 100, 50, 50, 0, HALF_PI);

that it draws an arc starting from the right, and extends clockwise. are
you using the latest release?

(i've removed the reference to 'angle mode' from the reference, that's long
since been removed.)

But radians increase counterclockwise. HALF_PI should be straight up.

hm, i'll have to check into that.

(In reply to comment #3)
> Additional Comment #3 From fry 2009-06-11 06:10 [reply] hm, i'll have to check
into that.

fwiw, y axis is inverted wrt trig on a true cartesian grid, causing rotations to appear
counter, rotate itself has same issue, been like that for a long time (forever?)

translate(width/2,height/2);
rotateZ(HALF_PI);
line(0,0,1000,0); // draws a line "down", not "up"

if you were to "fix" this i think it could break a lot of existing sketches. perhaps
better to just "explain" it somewhere as a side effect of the coordinate system?

yeah, i don't see us being able to change it at this point, since it would
break anything that uses angles. and for our audience, it's questionable
whether angles increasing counter-clockwise is a good idea at all. (using
PI and friends is weird enough for them, having to work backwards might
make them punch their professors.) i think it makes more sense for arc() to
work like rotate() and the rest anyway.