|
 |
"Bald Eagle" <cre### [at] netscape net> wrote:
> So, I was working on a bit of code, it was late, and I thought perhaps that
> mod() would take a negative number and wrap it around to the "top", but it of
> course does not. Then I got a "negative subscript" error when trying to address
> an array element.
>
> I was wondering if it might be sufficiently helpful so as to warrant an array
> type that would automatically wrap in either direction - perhaps with a warning
> that could be disabled.
>
> So an array with 5 elements (#declare array = array [5]) would yield Array[0] if
> Array[5] were addressed. And likewise Array[-1] would yield Array [4].
>
> Something like carray for "cyclic array" or marray for "modulo array"...
>
> Perhaps a spiral array would find use in navigating data as well - a 2
> dimensional array where overrun in either direction in one dimension would shift
> over to the edge element in the next dimension.
Hi again Bill,
Here is my suggestion for how to do what (I believe) you want or need:
#version 3.7;
#declare Size = 5;
#declare Array1A = array[Size] { 4, 2, 5, 3, 7 };
#declare WrapFn = function(I) { mod(I + Size, Size) };
#debug "\n"
#debug "\n"
#debug concat("Array1A[0]: ", str(Array1A[WrapFn(0)], 0, 0))
#debug "\n"
#debug concat("Array1A[5]: ", str(Array1A[WrapFn(5)], 0, 0))
#debug "\n"
#debug concat("Array1A[4]: ", str(Array1A[WrapFn(4)], 0, 0))
#debug "\n"
#debug concat("Array1A[-1]: ", str(Array1A[WrapFn(-1)], 0, 0))
#debug "\n"
#debug "\n"
#error "To stop rendering"
So by wrapping array indices into function calls (or macro calls) you can remap
the the way arrays are indexed.
For 2D arrays you can do it like this:
#version 3.7;
#declare Size1 = 4;
#declare Size2 = 5;
#declare Array2A =
array[Size1][Size2] {
{ 14, 2, 5, 13, 7 },
{ 0, 19, 11, 6, 15 },
{ 18, 4, 10, 8, 12 },
{ 16, 3, 9, 17, 1 }
}
;
#declare Dim1Fn = function(I) { mod(I + Size1, Size1) };
#declare Dim2Fn = function(J) { mod(J + Size2, Size2) };
#debug "\n"
#debug concat("Array2A[2][3]: ", str(Array2A[Dim1Fn(2)][Dim2Fn(3)], 0, 0))
#debug "\n"
#debug concat("Array2A[6][-2]: ", str(Array2A[Dim1Fn(6)][Dim2Fn(-2)], 0, 0))
#debug "\n"
/*
// To get the spiralling behaviour you describe, you can insert your mapping
// magic into these two functions. The expressions for each of these may
// involve I, J, Size1 and Size2.
#declare Dim1_Fn = function(I, J) { };
#declare Dim2_Fn = function(I, J) { };
#debug "\n"
#debug concat("Array2A[2][3]: ", str(Array2A[Dim1_Fn(2, 3)][Dim2_Fn(2, 3)], 0,
0))
#debug "\n"
#debug concat("Array2A[6][-2]: ", str(Array2A[Dim1_Fn(6, -2)][Dim2_Fn(6, -2)],
0, 0))
#debug "\n"
*/
#debug "\n"
#error "To stop rendering"
BTW:
This may be relevant reading:
https://stackoverflow.com/questions/11720656/modulo-operation-with-negative-numbers
I recommend that you look at how indexing of lists works in Python. I think that
you will like it...
--
Tor Olav
http://subcube.com
https://github.com/t-o-k
Post a reply to this message
|
|
|
|
"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
Thanks for the code and the link :)
I do like that we have a lot of people who design and write include files and
code snippets, however much of what I'm musing about are additions to the source
code.
And that's for several reasons:
1. It will be well-established, working, tested, reliable code to perform a
specific task in "the right way".
2. and therefore, the [new] user, or experienced user who just doesn't have the
desire to write or track down such code will have it embedded into POV-Ray
already
3. and it follows along with the concept of "inseparability" - detachable things
like scene and include files get lost, forgotten, and even deleted.
4. Sometimes certain things are faster, because they are compiled code, and SDL
can be slow
So, I definitely think that plenty of scenes and macros and functions and
include files ought to be written and developed - but my wish is to see them
constantly being looked at for inclusion into subsequent versions.
Post a reply to this message
|
|
