Lets say that I have an array of vectors, and that I wish to use its 
elements a variable number of times (which might be different for each 
element) and then remove the used element from the array.

The only thing that I can come up with would be to use a 3D array like this:

//      randVectorMMR Macro by [GDS|Entropy]
//      For element reuse capability
//------
#macro randVectorMMR(Array,ctr,Min,Max,rMin,rMax)
 #local i=0;
 #while (i<ctr)
  #declare Array[i][0][0] = <RRand(RsA, Min, Max),RRand(RsA, Min, 
Max),RRand(RsA, Min, Max)>;
  #declare Array[i][1][0] = <0,0,0>;
  #declare Array[i][1][1] = <0,RRand(RsA, rMin, rMax),0>;
 #set i=i+1;
 #end
#end
//------

//      RRand Macro by Chris Huff
#macro RRand(RS, Min, Max)
 (rand(RS)*(Max-Min) + Min)
#end

//      Round macro by [GDS|Entropy]
//      Adapted from Trevor G Quayle function
//------
#macro Round(Number,RoundTo)
 #if (Number >= 0)
  1*int(abs(Number)*pow(10,RoundTo)+0.5)/pow(10,RoundTo)
 #else
  -1*int(abs(Number)*pow(10,RoundTo)+0.5)/pow(10,RoundTo)
 #end
#end
//------

//      VRound macro by [GDS|Entropy]
#macro VRound(Vector,RoundTo)
 <Round(Vector.x,RoundTo),Round(Vector.y,RoundTo),Round(Vector.z,RoundTo)>
#end
//------

#declare ctr = 10;
#local maxReuse = 10;
#local minReuse = 1;

#declare myArray = array[ctr][2][2];
randVectorMMR(myArray,ctr,1,5,minReuse,maxReuse)

#local i = 0;
#while (i < dimension_size(myArray,1))
 #local pos = myArray[i][0][0];
 #local use = myArray[i][1][0];
 #local ass = VRound(myArray[i][1][1],0);

 #debug concat("Array Value: ", vstr(3,pos,",",3,3)," ")
 #debug concat("Assigned Reuse : ", vstr(3,ass,",",3,3)," ")
 #debug concat("Used: ", vstr(3,use,",",3,3)," times \n")

 #if (use.y < maxReuse & use.y < ass.y)
  object {
   foo
   translate pos
  }
  #declare myArray[i][1][0] = myArray[i][1][0] + 1;
  #local i = i;
 #else
  #local i = i + 1;
 #end

#end
#undef myArray

That way sucks, and it doesn't remove the element from the array.

Whats a better way of doing this?

ian

Post a reply to this message

"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> Lets say that I have an array of vectors, and that I wish to use its
> elements a variable number of times (which might be different for each
> element) and then remove the used element from the array.
>
> The only thing that I can come up with would be to use a 3D array like this:

Oh, those pesky OOP-spoilt greenhorns! ;)

When I was still young and handsome, such information would be stored in a
separate array, like this:

    10 DIM x(100),y(100),z,used%(100)
    20 FOR loop% = 1 TO 4711
    30   LET i% = RND(100) + 1
    40   LET used%(i%) = used%(i%) + 1
    50   PRINT "<";STR$(x(%i));",";STR$(y(%i));","STR$(z(%i));">"
    60 NEXT loop%
    70 END
    5 RANDOMIE TIME
    12 GOSUB 1000 : REM fill data
    50   PRINT "<";STR$(x(%i));",";STR$(y(%i));","STR$(z(%i));">";
    55   PRINT " used ";STR$(used%(i));" times"
    LIST -100
    5 RANDOMIE TIME
    10 DIM x(100),y(100),z,used%(100)
    12 GOSUB 1000 : REM fill data
    20 FOR loop% = 1 TO 4711
    30   LET i% = RND(100) + 1
    40   LET used%(i%) = used%(i%) + 1
    50   PRINT "<";STR$(x(%i));",";STR$(y(%i));","STR$(z(%i));">";
    55   PRINT " used ";STR$(used%(i));" times"
    60 NEXT loop%
    70 END
    READY
    RUN
    SYNTAX ERROR IN LINE 5
    READY
    LIST 5
    5 RANDOMIE TIME
    READY
    5 RANDOMIZE TIME
    RUN
    LINE DOES NOT EXIST IN LINE 12
    READY

(Yeah, those were the days! You just flipped the power switch, and your
programming IDE would be up and running in 5 seconds... ah, modern
technological advancement has deprived us of all that joy...)

.... then someone invented structs (oh, well, "records" for me back then, because
I went for Turbo Pascal)...

But I'm getting a bit off topic... so back to your problem:

First thing to know: No, POV SDL unfortunately doesn't have something like
structs. Nor does it have dynamic lists. Be happy and content that you don't
have to mess around with line numbers ;)

>   #declare Array[i][0][0] = <RRand(RsA, Min, Max),RRand(RsA, Min,
> Max),RRand(RsA, Min, Max)>;
>   #declare Array[i][1][0] = <0,0,0>;
>   #declare Array[i][1][1] = <0,RRand(RsA, rMin, rMax),0>;

Why use a 3-dimensional array when a 2-dimensional one will do the job?

#declare Array[i][0] = <...>;
#declare Array[i][1] = <0,0,0>;
#declare Array[i][2] = <0,RRand(RsA, rMin, rMax),0>;

Then, to get rid of an entry of such an array, you could use:

#undef Array[i][0]
#undef Array[i][1]
#undef Array[i][2]

and check for #ifdef(Array[i][0]) when you loop through the array.

I guess that's as close as you can get to what you want.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> Oh, those pesky OOP-spoilt greenhorns! ;)
>
> When I was still young and handsome, such information would be stored in a
> separate array, like this:
[snip nostalgia]
> (Yeah, those were the days! You just flipped the power switch, and your
> programming IDE would be up and running in 5 seconds... ah, modern
> technological advancement has deprived us of all that joy...)

Hmm, looks very much like Acorn BASIC. Although, 5 seconds? If that were a beeb
you'd be ready to go before your finger had even left the power button...

(GOSUB, eww. PROC was the only way forwards :-) )

Post a reply to this message

Bill Pragnell wrote:
> Hmm, looks very much like Acorn BASIC. Although, 5 seconds? If that were a beeb
> you'd be ready to go before your finger had even left the power button...

That included the time for the TV tube to warm up. ;-)

-- 
   Darren New, San Diego CA, USA (PST)
   My fortune cookie said, "You will soon be
   unable to read this, even at arm's length."

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> Hmm, looks very much like Acorn BASIC. Although, 5 seconds? If that were a beeb
> you'd be ready to go before your finger had even left the power button...
>
> (GOSUB, eww. PROC was the only way forwards :-) )

Not on the Amstrad CPC 6128 I was toying around with ;)

Locomotive Basic 1.1 ((C) 1985 if I remember correctly...)

The Sinix Basic I had to work with about 20 years later was a bit more
sophisticated... still I was glad it was only a few months' assignment ;) (Much
of the stuff I had to deal with was old-school code, with lots of GOTO
<line_number> in it >_<)

It was quite fun though: As the old Sinix machine was scheduled for ultimate
powerdown, the task was to port those programs... to VBA of course :P

I ended up writing a parser for the old Sinix Basic code that would
auto-generate a VBA module, and a library of subroutines that would simulate
the Sinix Basic's formatted input, output and file access functions with all
their peculiarities...

Why do a brain-dead job when you can write a brain-dead piece of software to do
it for you? Usually it costs about the same time it actually saves, but it sure
as hell is a good deal more fun ;) (plus, it tends to impress people)

Post a reply to this message

"clipka" <nomail@nomail> wrote in message 
news:web.49ca4fd59fb46029c1f399840@news.povray.org...
>
> Oh, those pesky OOP-spoilt greenhorns! ;)
>
> When I was still young and handsome, such information would be stored in a
> separate array, like this:
>
<SNIP>

o_O'

Eew...BASIC...I'd rather learn just get it over with and Assembly (its on 
the TODO list)..

> (Yeah, those were the days! You just flipped the power switch, and your
> programming IDE would be up and running in 5 seconds... ah, modern
> technological advancement has deprived us of all that joy...)

Ubuntu will boot on a very old machine I have from the liveCD in just over 6 
times that...not that bad considering that includes GNOME.

> .... then someone invented structs (oh, well, "records" for me back then, 
> because
> I went for Turbo Pascal)...

Structs rock.

> But I'm getting a bit off topic... so back to your problem:
>
> First thing to know: No, POV SDL unfortunately doesn't have something like
> structs. Nor does it have dynamic lists. Be happy and content that you 
> don't
> have to mess around with line numbers ;)

Dynamic lists also rock.
I did mess around with BASIC back in elementary school (early/mid 80's). 
That is when I decided that I didn't like it much, and chose to avoid any 
language with Basic in the name.

Damn...maybe it would be seriously worth the effort of tracking down 
whatever code handles structs and dynamic lists and etc.. in the language 
that pov was written, and integrating that into povray with some nice SDL 
implementation. I'm more than sick of needing and not having those kinds of 
things.

http://www.haskell.org/haskellwiki/POV-Ray_SDL_project

Someone has the right idea.
They said this too: "Endless flamewars have raged over the subject of 
whether the SDL should become object-oriented."
When did THAT happen?! O_o'

This newsgroup seems rife with thoughtful discourse and quite a high SNR, 
not "endless flamewars"...

>>   #declare Array[i][0][0] = <RRand(RsA, Min, Max),RRand(RsA, Min,
>> Max),RRand(RsA, Min, Max)>;
>>   #declare Array[i][1][0] = <0,0,0>;
>>   #declare Array[i][1][1] = <0,RRand(RsA, rMin, rMax),0>;
>
> Why use a 3-dimensional array when a 2-dimensional one will do the job?

Beyond being just something that I threw together to do something like what 
I wanted, I decided that I might want to add an absurd amount of 
functionality later and that this would be the most logical way to leave my 
options open. For example I might add other related things to each of the 
dimensions, and it might be best to keep each category of data seperate.

> #declare Array[i][0] = <...>;
> #declare Array[i][1] = <0,0,0>;
> #declare Array[i][2] = <0,RRand(RsA, rMin, rMax),0>;
>
> Then, to get rid of an entry of such an array, you could use:
>
> #undef Array[i][0]
> #undef Array[i][1]
> #undef Array[i][2]

I might be able to adapt such a thing to do what I wanted in the first 
place. I guess if the following (untested) macro works, I could just call it 
once the established number of "uses" has been reached to purge the elements 
I need to.

#macro 
undefElement(Array,dim1Element,dim2Element,dim3Element,dim4Element,dim5Element)
 #local numDimensions = dimensions(Array);
 #if (numDimensions = 1)
  #undef Array[dim1Element]
 #end
 #if (numDimensions = 2)
  #undef Array[dim1Element][dim2Element]
 #end
 #if (numDimensions = 3)
  #undef Array[dim1Element][dim2Element][dim3Element]
 #end
 #if (numDimensions = 4)
  #undef Array[dim1Element][dim2Element][dim3Element]][dim4Element]
 #end
 #if (numDimensions = 5)
  #undef 
Array[dim1Element]][dim2Element][dim3Element]][dim4Element][dim5Element]
 #end
#end

> and check for #ifdef(Array[i][0]) when you loop through the array.
>
> I guess that's as close as you can get to what you want.

So I wasn't too far off from what I was looking for. That is a good sign. 
:-)
I suppose I could just redefine the wiped element with interpolated 
vectors...or something...should I need to, by using the above macros 
functionally mirror image.

As a side note, why in the nine hells aren't there Round and VRound macros 
in pov to start with??
They seem kind of useful to just have been left out...then again...so do 
structs, enums, custom types, multi-datatype arrays, type casting, type 
conversion and list<T>'s...

More of a side note....it would be cool to create a set of macros which 
emulated basic circuit components, so that one could produce such an act of 
irony as a properly functioning raytraced circuit...
Hmm....to make a macro which can produce accurate semiconductor curves.... 
Gah! I need to finish this damn macro suite...no new projects! :-p

ian

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> > (GOSUB, eww. PROC was the only way forwards :-) )
>
> Not on the Amstrad CPC 6128 I was toying around with ;)
>
> Locomotive Basic 1.1 ((C) 1985 if I remember correctly...)

I suspected it probably wasn't Acorn BASIC. The interpreter didn't worry about
LETs, and didn't say Ready at every prompt. Definitely a contemporary though!

> I ended up writing a parser for the old Sinix Basic code that would
> auto-generate a VBA module, and a library of subroutines that would simulate
> the Sinix Basic's formatted input, output and file access functions with all
> their peculiarities...

Good job.

Whoops, this is veering a little off-topic now... :)

Post a reply to this message

"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> Damn...maybe it would be seriously worth the effort of tracking down
> whatever code handles structs and dynamic lists and etc.. in the language
> that pov was written, and integrating that into povray with some nice SDL
> implementation. I'm more than sick of needing and not having those kinds of
> things.

If I wasn't working on various other pieces of POV code, that's what I'd
probably be doing right now...

(Note however that "in the language that pov was written" would mean C until
only very recently, so nowhere close to dynamic lists whatsoever; and structs,
although C does have them, would have to be represented internally using
"arrays of members" as it were, because C can't create new structs at runtime.)

> http://www.haskell.org/haskellwiki/POV-Ray_SDL_project

Yargh! Vade! >_<

> Beyond being just something that I threw together to do something like what
> I wanted, I decided that I might want to add an absurd amount of
> functionality later and that this would be the most logical way to leave my
> options open. For example I might add other related things to each of the
> dimensions, and it might be best to keep each category of data seperate.

Again, too much OO thinking for POV SDL. You can't store separate things in the
multiple dimensions of such an array anyway; and if one of your "subsections"
would need more elements, you'd need to add more elements to the other
"subsections" as well... not too bright.

But what you might want to do is:

#declare POINT  = 0;
#declare COUNT  = 1;
#declare RANDOM = 2;

#declare Array[i][POINT]  = <...>;
#declare Array[i][COUNT]  = <0,0,0>;
#declare Array[i][RANDOM] = <0,RRand(RsA, rMin, rMax),0>;

(That's basically how struct support would have to be implemented in POV
internally - except that we'd need to be able to store different things in the
array elements)

or maybe

#macro GET_POINT(a,i)
  Array[i][0]
#end

#macro GET_COUNT(a,i)
  Array[i][1].x
#end

#macro GET_RANDOM(a,i)
  Array[i][2].y
#end

> As a side note, why in the nine hells aren't there Round and VRound macros
> in pov to start with??

You can round using "int(x+0.5)", so no problem writing your own macros...

Yes, maybe the standard include files could use an overhaul, too.

> They seem kind of useful to just have been left out...then again...so do
> structs, enums, custom types, multi-datatype arrays, type casting, type
> conversion and list<T>'s...

.... and a new SDL grammar, as we're on it.

For the job we're doing, octrees would come in handy, too.

I think one of the greatest current limitations is the inability of arrays to
store elements of different types. Otherwise, structs could easily be simulated
by using identifiers holding constants, e.g.

#declare FIELD_FOO = 0
#declare FIELD_BAR = 1

#declare MyArray[FIELD_FOO] = <0,0,0>;
#declare MyArray[FIELD_BAR] = pigment { ... };

which still wouldn't be ideal, but still quite an improvement.

Post a reply to this message

"clipka" <nomail@nomail> wrote in message 
news:web.49ca88269fb46029c1f399840@news.povray.org...
> If I wasn't working on various other pieces of POV code, that's what I'd
> probably be doing right now...
>
> (Note however that "in the language that pov was written" would mean C 
> until
> only very recently, so nowhere close to dynamic lists whatsoever; and 
> structs,
> although C does have them, would have to be represented internally using
> "arrays of members" as it were, because C can't create new structs at 
> runtime.)

I had a feeling it was C still; long ago I looked at the source when 
considering adding new media scattering methods...then quickly abandoned 
that idea when I discovered how much work would actually be involved with 
the implementation of a new (to pov) algo.. :-|

>> http://www.haskell.org/haskellwiki/POV-Ray_SDL_project
>
> Yargh! Vade! >_<

Hmm? Sounds like something a norseman might shout just after boarding your 
vessel and just before doing something awful with a large blade. ;-)

> Again, too much OO thinking for POV SDL.

OO is the crack of programming. :-)

> You can't store separate things in the multiple dimensions of such an 
> array anyway; and if one of your "subsections"
> would need more elements, you'd need to add more elements to the other
> "subsections" as well... not too bright.

All of the dim1 elements will have the same attributes, so in this case it 
isn't really an issue, as they are just flags really. I do wish I could 
store multiple datatypes though, as using vectors when all you want is a 
flag is somewhat like the programming equivalent of a nasty hacked up 
hairball; ugly, gross and not something you like having to deal with.

> But what you might want to do is:
>
> #declare POINT  = 0;
> #declare COUNT  = 1;
> #declare RANDOM = 2;
>
> #declare Array[i][POINT]  = <...>;
> #declare Array[i][COUNT]  = <0,0,0>;
> #declare Array[i][RANDOM] = <0,RRand(RsA, rMin, rMax),0>;

So using different placed in dim2 would be better than having related vector 
flags grouped in their own dimension?
It seems to me that it could become confusing and require code rewrites (for 
grouping of like flags/misc) if one uses only 2d when thy might have a set 
of flags in d2 for say, branching, child nodes, etc.. and more for 
interpolated vectors or the like. It also seems that using those additional 
attributes could become messy if they are just all over the place.

> (That's basically how struct support would have to be implemented in POV
> internally - except that we'd need to be able to store different things in 
> the
> array elements)

I'd say step one would be to implement vector and integer/double/long 
support in the same array, see what that took to do, and then fan out from 
there.

> or maybe
>
> #macro GET_POINT(a,i)
>  Array[i][0]
> #end
>
> #macro GET_COUNT(a,i)
>  Array[i][1].x
> #end
>
> #macro GET_RANDOM(a,i)
>  Array[i][2].y
> #end

I like that better, seems easier to use and keep track of. I still like the 
idea of using multiple dimensions for related flags for my specific purpose, 
as I won't have many categories. It isn't so much that it really matters, so 
long as whatever method used works and does so quickly. Even so, for general 
extensibility, get/set macros for the win. I'll need to try both using 
stupid amounts of elements, and then compare the stats.

> You can round using "int(x+0.5)", so no problem writing your own macros...

True, but sometimes you just want to use a thing, without having to go find 
math.h to write your own.
There are a lot of little things like that in pov.

> Yes, maybe the standard include files could use an overhaul, too.

Agreed. Especially the textures, a lot of them kinda suck...like the 
metals...and glasses...
I'd like to see a nice influx of textures created by the community. Waters, 
glasses, metals, stones....there are so very many great ones I've seen used 
here.
A lot of the more esoteric macros in povray need example files too.

Maybe once I get my macro suite to a good place, I could get the snowball 
rolling on this..assuming they would actually use any files I created.
Probably if they would, I'd not be alone in wanting to do this.

> .... and a new SDL grammar, as we're on it.

Yes. My vote is cast with using more common C-ish things, as those who 
program will quickly adapt, and those who don't will spend the same amount 
of time learning as before, but will also be familiar with java/c#/c++ ish 
languages without even knowing it. Good for everyone.

>
> For the job we're doing, octrees would come in handy, too.

And hash tables(with a good many hashing methods), and heaps(with a lot of 
heap types), and a proof of the riemann hypothesis, and and and ;-D

> I think one of the greatest current limitations is the inability of arrays 
> to
> store elements of different types. Otherwise, structs could easily be 
> simulated
> by using identifiers holding constants, e.g.
>
> #declare FIELD_FOO = 0
> #declare FIELD_BAR = 1
>
> #declare MyArray[FIELD_FOO] = <0,0,0>;
> #declare MyArray[FIELD_BAR] = pigment { ... };
>
> which still wouldn't be ideal, but still quite an improvement.
>

Indeed. I'd take any improvement at this point.
Any idea why they never did that?

*sigh* I might just have to track down the file(s) where they coded those 
things and have a look...maybe it won't be the massive PITA that I get the 
feeling it is...

ian

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Darren New wrote:
> Bill Pragnell wrote:
>> Hmm, looks very much like Acorn BASIC. Although, 5 seconds? If that
>> were a beeb
>> you'd be ready to go before your finger had even left the power button...
> 
> That included the time for the TV tube to warm up. ;-)
> 
	Guess what? Somebody did a benchmark of an old 1986 Mac against a
dual core AMD64. And the winner is..... the 1986 Mac! By 9 tests to
8 (including a whopping six times faster boot sequence):
http://hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins

		Jerome
- --
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknKozQACgkQd0kWM4JG3k8TCQCfQHSlH7oHl0sxvs/mLynEImeQ
dXUAnjCt3GBfJpePz2ACWYQUoTTHNuQJ
=79sN
-----END PGP SIGNATURE-----

Post a reply to this message