Actually, the following at least seems to work.  Of course, I have not checked
if it doesn't corrupt any internal data:

    #declare foo = array[40];

    #declare foo[1] = array[10];
    #declare foo[2] = array[5];

    #declare foo[1][5] = 5.0;

As far as I can tell this is, together with the ability to undef arrays
sufficient to build linked structures...


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Mon, 25 Mar 2002 10:45:41 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> Actually, this implies it isn't possible to make an array (of arbitrary size,
> of course) an element of another array, or is this possible?  I have to admit
> I never tried, but from the code I cannot really see a reason why it shouldn't
> be possible other than as being a yet another parser limitation...

something related
http://news.povray.org/6lpkut0vdh0h6gljr7u2v4mip6olddkmel%404ax.com

ABX

Post a reply to this message

In article <3c9ef692@news.povray.org> , "Thorsten Froehlich" <tho### [at] trfde>
wrote:

> Actually, the following at least seems to work.  Of course, I have not checked
> if it doesn't corrupt any internal data:
>
>     #declare foo = array[40];
>
>     #declare foo[1] = array[10];
>     #declare foo[2] = array[5];
>
>     #declare foo[1][5] = 5.0;
>
> As far as I can tell this is, together with the ability to undef arrays
> sufficient to build linked structures...

For example:

#declare treeroot = array[3];

#declare rd = seed(1);

#macro randfilltree(node, i)
 #declare node[2] = array[1];
 #declare node[2][0] = rand(rd) * 1000 + 10;
 #if(i > 0)
  #if(rand(rd) > 0.1)
   #declare node[0] = array[3];
   randfilltree(node[0], i - 1)
  #end
  #if(rand(rd) > 0.1)
   #declare node[1] = array[3];
   randfilltree(node[1], i - 1)
  #end
 #end
#end

#macro dumptree(node)
 #debug " ("
 #debug str(node[2][0], 0, 0)
 #if(defined(node[0]))
  dumptree(node[0])
 #end
 #if(defined(node[1]))
  dumptree(node[1])
 #end
 #debug ")"
#end

#macro findmaxtree(node)
 #if(defined(node[0]) & defined(node[1]))
  max(node[2][0], findmaxtree(node[0]), findmaxtree(node[1]))
 #else
  #if(defined(node[0]))
   max(node[2][0], findmaxtree(node[0]))
  #else
   #if(defined(node[1]))
    max(node[2][0], findmaxtree(node[1]))
   #else
    0
   #end
  #end
 #end
#end

randfilltree(treeroot, 6)

#debug str(findmaxtree(treeroot), 0, 0)

dumptree(treeroot)

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Skiba <abx### [at] babilonorg>  wrote:

>> Actually, this implies it isn't possible to make an array (of arbitrary size,
>> of course) an element of another array, or is this possible?  I have to admit
>> I never tried, but from the code I cannot really see a reason why it
>> shouldn't be possible other than as being a yet another parser limitation...
>
> something related
> <http://news.povray.org/6lpkut0vdh0h6gljr7u2v4mip6olddkmel%404ax.com>

Yes, exactly!  I was sure it couldn't be a new idea, but somehow few people
have discovered everything possible with arrays yet.


BTW, when building trees recursively there is always the macro recursion
limit, but trees with a height of 98 are either very big or not well balanced
anyway...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Mon, 25 Mar 2002 11:52:53 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> BTW, when building trees recursively there is always the macro recursion
> limit, but trees with a height of 98 are either very big or not well balanced
> anyway...

But even then there is a workaround - iteration instead of recursion with
stack placed in another array. Operations on stack can be realised via
Resize_Array macro. This method works fine in my recent implementation in
IC_Text addition for iso_csg library.

ABX

Post a reply to this message

Skiba <abx### [at] babilonorg>  wrote:

> But even then there is a workaround - iteration instead of recursion with
> stack placed in another array. Operations on stack can be realised via
> Resize_Array macro. This method works fine in my recent implementation in
> IC_Text addition for iso_csg library.

Yes, but I am not sure it is possible to access an array with an arbitrary
number of dimensions this way.  Take a look at the example macros I posted.
They all depend on passing of array elements that are arrays...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Mon, 25 Mar 2002 10:45:41 +0100, Thorsten Froehlich wrote:
> In article <slr### [at] fwicom> , Ron Parker 
><ron### [at] povrayorg>  wrote:
> 
>> It wouldn't be any slower than a regular binary tree, but it would have a
>> limit on the maximum depth, it would take up more storage than absolutely
>> necessary, and it couldn't be balanced.
> 
> Actually, this implies it isn't possible to make an array (of arbitrary size,
> of course) an element of another array, or is this possible?  I have to admit

I didn't mean to imply that.  What I was saying was that using an array to
represent the tree directly using the scheme I mentioned limits the depth
to a maximum, unless you want to spend lots of time enlarging the array.

However, I think perhaps we could add a few lines to Parse_Array_Declare to
allow syntax like this to enlarge an array more quickly:

#declare A=array[5] {1, 2, 3, 4, 5}
#declare B=array[10] A

or maybe something a little more attractive...

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

Post a reply to this message

On 25 Mar 2002 08:28:30 -0500, Ron Parker <ron### [at] povrayorg> wrote:
> However, I think perhaps we could add a few lines to Parse_Array_Declare to
> allow syntax like this to enlarge an array more quickly:

That's not fair for other feature requests ;-)

( there are lines

  //#macro Insert_In_Array(Item, DestArray, Index)
  //#macro Insert_Array_In_Array(ItemArray, DestArray, Index)
  //#macro Append_To_Array(Item, DestArray, Index)
  //#macro Append_Array_To_Array(ItemArray, DestArray, Index)

in arrays.inc I'm working on)

ABX

Post a reply to this message

> On 25 Mar 2002 08:28:30 -0500, Ron Parker <ron### [at] povrayorg> wrote:
>> However, I think perhaps we could add a few lines to Parse_Array_Declare to
>> allow syntax like this to enlarge an array more quickly:
> 
> That's not fair for other feature requests ;-)

Don't worry; it's not likely to happen anyway.  I haven't even had time 
lately to work on the bugs I've agreed to take on.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

> Operations on stack can be realised via
> Resize_Array macro.

  The problem with using Resize_Array() is that it defies the whole purpose
of using binary trees. The main reason of using trees is that adding,
removing and searching values are all O(log n) operations, which makes it
awesomely fast.
  However, if you have to recurr to Resize_Array(), you are making it O(n),
which effectively destroys its speed benefits.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message