P5.js: PI as a number and as an unit of angle

[vipulrawat]

Nature of issue?

• [x] Found a bug
• [ ] Existing feature enhancement
• [ ] New feature request

Most appropriate sub-area of p5.js?

• [ ] Color
• [x] Core/Environment/Rendering
• [ ] Data
• [ ] Events
• [ ] Image
• [ ] IO
• [ ] Math
• [ ] Typography
• [ ] Utilities
• [ ] WebGL
• [ ] Other (specify if possible)

Which platform were you using when you encountered this?

• [x] Mobile/Tablet (touch devices)
• [x] Desktop/Laptop
• [ ] Others (specify if possible)

Details about the bug:

In src/core/constants.js PI = Math.PI which is 3.141592653589793 ( 15 digits precision )
And we are using this PI (3.141592653589793) all over the p5 library.

One of the common approach while using π is that one consider π = 180° and 180° = π to be true. Which is correct according to Wolframalpha too.
But there is a catch, π is just an irrational number and computers have their limitations as well when handling numbers.
Coming to p5.js specifically, there is a minute difference between π as a number and π as radians. The difference is :

    const PI = Math.PI; // 3.141592653589793
    ...
    const TWO_PI = 2 * PI; // 6.283185307179586

But when using PI as an angle in radians this may give irregular results reason being PI is number which is not always equals to PI as radians.
So, 1 radian = 57.2958 degrees and thus 6.283185307179586 radians = 360.00000000089301011 degrees (this is the TWO_PI constant in p5.js) mathematically all good and super correct.

_For humans, 360.00000000089301011° is equals to 360° but for the computer, it is not equal._

__Problem__

If I am able to explain the above scenario of PI as a number and PI as radians. Then you can see that the below code will never result in an 80x80 circle (Reference):

    // arc(x, y, w, h, start angle, stop angle, [mode])
    arc(50, 50, 80, 80, 0, TWO_PI);

Otherwise, it will be a very minute unvisible arc that starts from 0 radians and ends at 0.00000000089301011 radians. __The same case arises for PI, HALF_PI and QUARTER_PI when using them as a unit of angle. (The results are so infinitesimal that is barely visible in the p5 canvas)__

_Update_
_Only this is not rendering a circle arc(50, 50, 80, 80, 0, 6.283185307179586);_
_While arc(50, 50, 80, 80, 0, 6.283185307179587); is working fine._

__Solution__

Can be multiple ways to deal with it one that I can suggest as to round the PI to some lesser precision value may be to this 3.1415926 and letting the user use Math.PI whenever they want higher precision value. Another way can be to round the value of PI wherever we are using it as an angle (but this will be an odd process).

---

I can be completely wrong. Please correct me if I am taking wrong calculations.

[limzykenneth]

I believe this behaviour is intended. See this comment in the source.

I'm not entirely sure what the reasoning is, maybe it is something Processing did and got translated over or maybe there are other reasons. In other words, it isn't a floating point precision or canvas rendering issue, just a decision that was made to not draw the arc if the difference between them are TWO_PI.

See also this page and edit the startAngle and endAngle to 0 and 2*Math.PI respectively, it will draw a full circle.

[vipulrawat]

According to the source code, we are still unable to make a full circle using startAngle and endAngle to 0 and 2 * Math.PI respectively. As the difference between the two is still equal to the difference between 0 and TWO_PI. For now I changed the example of TWO_PI #3325

[limzykenneth]

According to the source code, we are still unable to make a full circle using startAngle and endAngle to 0 and 2 * Math.PI respectively.

Yes, that's what I'm saying, the underlying canvas API is able to handle 0 and 2*Math.PI (try the second link I shared) but the source disabled that.

[vipulrawat]

Yup, got it. Still figuring out the possible reasoning for this.
What do you think of changing example of TWO_PI for now in #3325 ?

[limzykenneth]

The existing example for TWO_PI is not compatible with this part of the library but I prefer the idea of the original TWO_PI example so maybe wait till we find out why there's that check in arc before changing the example for TWO_PI.

[vipulrawat]

Ok. Sounds good to me.

[vipulrawat]

I have seen processing (java) and processing.js
It is drawing full circle on passing value 0 to 2 * Math.PI.
https://github.com/processing/processing/blob/master/core/src/processing/core/PGraphics.java#L2850

https://github.com/processing-js/processing-js/blob/master/src/Processing.js#L8041

https://py.processing.org/reference/TWO_PI.html

[vipulrawat]

Ok this is an intentional choice at first place in p5.js #902. Then I think we should change documentation of TWO_PI to some meaningful way.

[limzykenneth]

@lmccart @joecridge Is there a decision about what to do about this in #2919? Shall we change the documentation example to match current behaviour or was there some proposed changed that wasn't yet implemented?

[joecridge]

Hey all. We could deal with the floating point issues by quantizing start and stop to a sensible number of decimal price places right as they enter into the arc function. We could change the behaviour when start and stop map to the same point on the circle to draw a full circle rather than nothing (nothing was the choice in the past – maybe it was the wrong one – but you can’t have it both ways).

At the moment, though, there are a few bandaids applied to the original arc implementation in 2d_primitives to deal with ‘special’ angles relating to pi. These angles needn’t be special (floating point errors and same-start-and-end issues occur just the same wherever you choose to start your arc), and it’s the bandaids that are actually creating the edge cases for the edge case behaviour.

I’ve checked the code on master and the comments I made over on #2919 still apply. I think the issues there need to be addressed first.

[joecridge]

I’m happy to make a PR for all of this over the weekend (removing bandaids, quantizing, full circle when start/end touch, updating docs) if there aren’t any strong feelings otherwise? It would be good to get arcs behaving themselves for a little while 😜

[lmccart]

@joecridge that would be great. if you want to take the lead on determining ideal arc functioning and implement it in a PR with documentation I think that would be a huge step forward.

[joecridge]

I didn’t get a chance last weekend, but I’ll hop on this shortly 🙂

[joecridge]

So I took some liberty with ‘shortly’ 😆, but I’m working on this now 🤓.