Talk:Perlin noise
Correctness
The D implementation generates exactly the same outputs of the Java version. I have used the D code to generate this image (with the grayscale code visible in the D entry): http://oi62.tinypic.com/2pt9flx.jpg
Is such image correct? Isn't a correct Perlin noise image without sharp borders, like this?
http://4.bp.blogspot.com/-u4wfD21sIvU/UsI85U78XYI/AAAAAAAAAx8/NG2fEzYjTUA/s1600/perlin2.png -bearophile (talk)
- Your image is not correct. The perlin noise has a range between -1 and 1, and you use this to convert it into an unsigned byte:
Gray(cast(ubyte)(p * 256))
- Try this:
Gray(cast(ubyte)((p+1)/2 * 256))
- Also, your image will look smoother than the example you found on blogspot.com, since this imag is made with several octaves.
- OK, I have added a post-condition and a comment in the opCall function in the D code. The image now looks smooth and nice, thank you. Do you also want to tell me what's the pre-condition of the "noise(double x, double y, double z)" Java method (this means, what's the allowed input range for those arguments x y z)? (Generally the more semantics you put in the code, then less likely is for people like me to use it wrongly). -bearophile (talk)
- x, y and z can be any real numbers. Notice that the noise will be zero if they are all integers, though.--Grondilu (talk) 18:19, 5 March 2014 (UTC)
- I'm not 100% sure the result is guaranteed to be between -1 and 1. It's an interpolation from the gradients on the grid points so sometimes it can exceed, but whether or not it can is not obvious. So instead of putting a post-condition I think it's better to cap the output with noise = min(+1, max(-1, noise)); or something like that.--Grondilu (talk) 18:24, 5 March 2014 (UTC)
- OK, I have added a post-condition and a comment in the opCall function in the D code. The image now looks smooth and nice, thank you. Do you also want to tell me what's the pre-condition of the "noise(double x, double y, double z)" Java method (this means, what's the allowed input range for those arguments x y z)? (Generally the more semantics you put in the code, then less likely is for people like me to use it wrongly). -bearophile (talk)
exactitudeness
In this Rosetta Code task, it states:
... show that the Perlin noise ... of a point in 3D-space with coordinates 3.14, 42, 7 is 0.13691995878400012.
Is that number cast in stone, or is it a result of particular type of binary floating point arithmetic?
REXX uses decimal floating point (not binary) and the results are very close.
It doesn't matter how many "extra" decimal digits are specified in REXX, the result is the same (exactly 12 decimal digits):
- 0.136919958784 and not
- 0.13691995878400012
So it would be impossible to show that this example (for the REXX entry), using decimal floating point, that the Perlin noise for that particular 3D point has that exact value.
Perhaps the wording could be tweaked a bit to reflect a value that (essentially) is approximated, depending on what form of floating point is being used: IEEE 754 (binary format), IEEE-2008 (IBM hexadecimal format), Cray, decimal float, and/or a host of others. -- Gerard Schildberger (talk) 00:36, 7 September 2015 (UTC)
It would be interesting to see a PL/I entry that does both, binary floating point and decimal floating point. -- Gerard Schildberger (talk) 00:40, 7 September 2015 (UTC)
- That result was achieved using numbers represented in the 64 bit IEEE-754 format. --Rdm (talk) 13:26, 7 September 2015 (UTC)
- Yes, but the exact value is 0.136919958784 when computed via (true) floating point decimal (with no rounding). This should've been noted in the task's preamble. For other 3D points, more decimal precision may be needed. For the 3D point specified in this task, only 12 decimal digits are needed to calculate the exact result. -- Gerard Schildberger (talk) 20:47, 16 June 2016 (UTC)