The subject kind of says it. I would like to see dynamic arrays (size not
predefined) in POV, since there are always situations where one can't predict
the size of an array.
Comments, anybody?

Margus

Post a reply to this message

Margus Ramst <mar### [at] peakeduee> wrote:
: The subject kind of says it. I would like to see dynamic arrays (size not
: predefined) in POV, since there are always situations where one can't predict
: the size of an array.
: Comments, anybody?

  I think it's perfectly possible to make dynamic arrays with pov language.
  In pseudocode something like this:

// want to convert an array A with dimensions [2][3] to dimensions [4][5]
copy the array A to a temporary array B
undefine A
declare A as an array of [4][5]
copy the contents of array B to array A (#while-loops etc...)
undefine B

  A resize_array()-macro should be quite easy to make this way...

  It's slow, I know, but at least it's not impossible.

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

In article <366C1A35.DF1EDDB8@peak.edu.ee> , Margus Ramst <mar### [at] peakeduee> 
wrote:

>The subject kind of says it. I would like to see dynamic arrays (size not
>predefined) in POV, since there are always situations where one can't predict
>the size of an array.
>Comments, anybody?

Making something "dynamic" always sounds good, but the fact is that the arrays in
POV-Ray are simple data structures in memory, allocated as *one* block. In order to
change this, its memory would have to be extended (which is no problem) each time the
size is changed, which would add significant overhead in a simple C implementation
like POV-Ray. Of course the nice vector templatein the C++ standard library (former
STL) would be helpful in this case...


    Thorsten

Post a reply to this message

I wouldn't really call this a dynamic array.
For example, I recently created a macro that sampled an object (with
Superpatch) and stored the resulting points in an array. Since changing
the fineness of sampling and the sampled object varied the point count
substantially, but unpredictably, I could not easily choose a good
relationship between any sampling parameter and initial array size.
I would have to check constantly if the array has been filled; if it
has, I would have to do the array resize you described. Since I don't
know how many more points are generated, how large would the resizing
be? I would either have to add a very large chunk and consume a lot of
memory - or add a smaller chunk, potentially requiring many more (slow)
resizings.
The bottom line is: it's possible, yes, but rather inflexible.

Margus

Nieminen Mika wrote:
> 
>   I think it's perfectly possible to make dynamic arrays with pov language.
>   In pseudocode something like this:
> 
> // want to convert an array A with dimensions [2][3] to dimensions [4][5]
> copy the array A to a temporary array B
> undefine A
> declare A as an array of [4][5]
> copy the contents of array B to array A (#while-loops etc...)
> undefine B
> 
>   A resize_array()-macro should be quite easy to make this way...
> 
>   It's slow, I know, but at least it's not impossible.
> 
> --
> main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
> *_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Margus Ramst wrote:
> 
> I wouldn't really call this a dynamic array.
> For example, I recently created a macro that sampled an object (with
> Superpatch) and stored the resulting points in an array. Since changing
> the fineness of sampling and the sampled object varied the point count
> substantially, but unpredictably, I could not easily choose a good
> relationship between any sampling parameter and initial array size.
> I would have to check constantly if the array has been filled; if it
> has, I would have to do the array resize you described. Since I don't
> know how many more points are generated, how large would the resizing
> be? I would either have to add a very large chunk and consume a lot of
> memory - or add a smaller chunk, potentially requiring many more (slow)
> resizings.
> The bottom line is: it's possible, yes, but rather inflexible.
> 
> Margus

I'd suggest an array of subarrays each of which would have a definite
predetermined size, but you'd still not know how many subarrays it would
take, so you're back to square one. Could you write all your samples to
a file and then be able to retrieve element [a] [b] by reading the Nth
value from the file by something like N = a x b?

Just an idea....

Post a reply to this message

2 problems: first and foremost, POV's #read function doesn't let you specify the
offset of the read (i.e. it just reads from the start). I wish that would
change...
And secondly, in the script I mentioned, I have to read a number of previous
values for each sample for proximity testing. Swapping to disk would make it
uncomfortably slow (it is slow enough with arrays)

Margus

Wayne Gordon wrote:
> 
> I'd suggest an array of subarrays each of which would have a definite
> predetermined size, but you'd still not know how many subarrays it would
> take, so you're back to square one. Could you write all your samples to
> a file and then be able to retrieve element [a] [b] by reading the Nth
> value from the file by something like N = a x b?
> 
> Just an idea....

Post a reply to this message

Margus Ramst wrote:
> 
> 2 problems: first and foremost, POV's #read function doesn't let you specify the
> offset of the read (i.e. it just reads from the start). I wish that would
> change...

Absolutely. You should be able to read the Nth data element in a file,
period.
That way you could skip over unneeded stuff as well as go back to the
beginning
of the file without having to close it. Appending should be more robust
as well.

> And secondly, in the script I mentioned, I have to read a number of previous
> values for each sample for proximity testing. Swapping to disk would make it
> uncomfortably slow (it is slow enough with arrays)
> 
> Margus

Maybe you are SOL. Next suggestion....hack the source, write a patch!
8-)

Post a reply to this message