Segmentation fault when using high coordinate values about noise

[caseman]

Interesting. This doesn't crash on macos, but does on Linux. I'll take a look

[caseman]

It looks like the (my) code naively presumes that the base is in the range of 0..255, although other values can accidentally work they may read from outside the lookup table. Actually it's worse than that and even values in that range can result in reading garbage. Reading garbage will result in seemingly ok results on some platforms (it is a pseudo-random function after all), but on others with stricter memory access it crashes as you noted.

Anyway it's fixable but the internal api will need an adjustment. For some reason base is currently an integer, which only makes sense if you subscribe to the rather insane presumptions of the present code. It would be better for it to be a float and have it interact with the coordinates before they are mapped to the lookup table.

I'll work on a fix, but for now you can workaround by adding the base value to the input coordinates yourself, and leaving base at zero, which should not crash. The base value concept is a bit dubious anyway, and the implementation doubly so. Some self flagellation is possibly in order as well.

[Shtong]

Yeah, actually I started working assuming the base was a float, which is actually what the method signature in the help pages hints at: "base=0.0". Thankfully the error message was relatively explicit :)

I'll manually add the base as you suggest.