processing / processing-website

Repository for the processing.org website
https://processing.org
GNU General Public License v2.0
64 stars 95 forks source link

noiseSeed() wrong seed value type #414

Closed johhnry closed 1 year ago

johhnry commented 1 year ago

Hi,

I just found that the documentation for the noiseSeed(seed) function tells that it accepts an int value which is not correct since it accepts a long primitive data type:

https://github.com/processing/processing4/blob/main/core/src/processing/core/PApplet.java#L5077

Is this intentional? This might be confusing because I get an error in the Processing IDE about a type mismatch.

Thanks!

SableRaf commented 1 year ago

Hi @johhnry and thanks for posting this issue! Would you be able to share a minimal example showing this type mismatch error? I was unable to reproduce it.

johhnry commented 1 year ago

Hi @SableRaf,

Thanks for the follow up, this is a bit weird since it works when passing an int but not a float:

float seed = 0;
noiseSeed(seed);

// -> The method noiseSeed(long) in the type PApplet is not applicable for the arguments (float)

I suppose that Java can implicitly convert between int to long but not float to long.

SableRaf commented 1 year ago

Hi @johhnry. I investigated this further and the parameters should be handled automatically by the script that generates the reference (this function specifically).

Please note that we are having an issue right now where the Doclet script needs to be updated (help needed) before we can update the reference. Once the script is fixed, we can look at this issue again as the parameter type mismatch may be a holdover from the old reference.

johhnry commented 1 year ago

Hi @SableRaf, thank you for investigating and linking this issue. I'll look at that repo if I have time ;)

REAS commented 1 year ago

@benfry please check this, where do you think the issue lies?

benfry commented 1 year ago

This applies to both noiseSeed() and randomSeed(). Both in fact take a long as an argument, though an int will work fine as well. We don't use long in any other API, so I suspect that the reference may have just been written to say int for sake of simplicity.

Further, passing an int won't show an error, because an int can safely be upgraded to a long without any loss of data (as opposed to float to int or long). I think it probably falls in the range of an acceptable white lie… if someone knows what a long is, then they can pass it, but the vast majority of our users can safely use it with an int, and it would probably be more confusing to write an example that used long just for the formality of it.

SableRaf commented 1 year ago

Thanks @johhnry for bringing this up and thanks @benfry for the clarification! Closing this as "acceptable white lie" ;)