P5.js: Odd rendering when passing string width/height values to ellipse()

[LeKerss]

Hello,

When passing a string argument for width and/or height, the ellipse() method interprets the string as a very high value, instead of parsing it to an integer.

Here is an example with a comparison to the rect() method, which does not have this problem :

[joecridge]

Interesting…

I imagine that this is because in JavaScript '50' + 25 === '5025' but '50' - 25 === 25, so the left-hand side is drawn correctly but the right-hand side (with the +) is nonsense.

I’ll add some tests to make sure that the mode adjust functions convert strings to numbers, which should fix the problem.

[lmccart]

@joecridge thanks for working on this. after looking at it again and reviewing your solution, my concern is that adding this helper here sets up an expectation that every function that takes numbers should also take strings too. for example fill("255", "0", "0") does not currently work.
while I realize that some do just work because of other manipulations that happen in the code, I suggest we make it the policy to support what is listed in the signatures. inputing other types of arguments can result in unexpected behavior.

additionally, we have the int() and float() methods for converting numbers to strings, so it seems reasonable to suggest in cases like the one above, that the input is first converted to a number using one of these.

[joecridge]

@lmccart I’m inclined to agree with you, but I also think that quietly handling some string inputs (whilst unpredictably processing others) contributes to that expectation (and makes issues like this one difficult for users to debug). Because beginners might not know that they need to convert text input to a number, I think that (ideally) each public function should either handle string arguments correctly, or throw a friendly error when strings are passed. (For me at least, consistency between functions is the cherry on top of individually predictable functions.)

[lmccart]

@joecridge I definitely hear that! @almchung is working this summer to get friendly error system to a point where it is ready to fully deploy. I think checking that argument inputs match valid signatures should be an essential part of that, and I hope that this will solve issues like these across the library.

[joecridge]

Okay, that sounds great. Happy to close #1793 then if it’s soon to be obsoleted! 🙂

[lmccart]

ok, sounds good. more soon on the friendly error front! we kick off at the end of this month (it's part of the google summer of code projects)

[aferriss]

Hey, I just came across this bug as well. What was eventually decided upon? It still seems to haunt the rendering of ellipses, though no other shapes seem to be affected as far as I can tell. Here's an example

http://alpha.editor.p5js.org/aferriss/sketches/BykDvC2VQ

[lmccart]

@aferriss this should be caught by the friendly errors, updated in the forthcoming release