When POV parses, does it directly parse the text file? If so, perhaps it
could load a compressed version into memory: replace keywords with
binary code, so no tedious text searching slows down a big parse; when
using loops and such, give #end statements an address refering to the
beginning, etc
For all I know, POV could already do this, but I know text parses much
slower than binary...

Perhaps it is asking too much...

Also, perhaps, different variable types. I don't know how many times
I've stored integers between 0 and 10 in an array of doubles...

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

In article <39AB5302.A39A21D7@faricy.net> , David Fontaine 
<dav### [at] faricynet>  wrote:

> When POV parses, does it directly parse the text file? If so, perhaps it
> could load a compressed version into memory: replace keywords with
> binary code, so no tedious text searching slows down a big parse; when
> using loops and such, give #end statements an address refering to the
> beginning, etc

POV-Ray already does what you are suggesting.  in general, your suggestions
are necessary to get any working parser.  POV-Ray does not do massive string
searches, there are much better ways of finding them and they don't require
a binary file format or something.

> For all I know, POV could already do this, but I know text parses much
> slower than binary...

No, the reason for the slow parsing of POV-Ray scenes are mostly related to
memory allocation.  Please note that this topic has been discussed for an
endless time before, just go back far enough in either povray.general or
povray.programming .

> Perhaps it is asking too much...

Why this remark?

> Also, perhaps, different variable types. I don't know how many times
> I've stored integers between 0 and 10 in an array of doubles...

What is wrong with this in POV-Ray, it will store the integers in the array
just fine?  And they should also work just like any other numbers, after
all, "real" math doesn't really make a difference between 'doubles' and
'integers' either (for the functions POV-Ray offers).


     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

In article <39AB5302.A39A21D7@faricy.net>, David Fontaine 
<dav### [at] faricynet> wrote:

> Also, perhaps, different variable types. I don't know how many times
> I've stored integers between 0 and 10 in an array of doubles...

This is harder than you think...the POV language (and a good chunk of 
the parser) would have to be redesigned to allow different types to be 
specified manually and to allow different types of scalars to exist with 
each other. And the only benefit would be lower memory usage, which is 
really only relevant if you are storing huge arrays.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

David Fontaine <dav### [at] faricynet> wrote:
: When POV parses, does it directly parse the text file? If so, perhaps it
: could load a compressed version into memory

  This is exactly what I have suggested some time ago. However, it's not
a simple task and I think the pov-team has more important things to do right
now :)

  Byte-compiled code will be faster to parse only when you have big loops
(I mean "big" in number of iterations), macros and so on. Reading a regular
file without them will only slow the parsing (because it has to first parse
it, as it does now, byte-compile it and then interpret that byte code).

  One advantage of byte-compiling is that you could save the binary data
to a file and then read it afterwards, saving the parsing and compilation
steps.
  A disadvantage of writing byte-coded binary data is that it's
system-specific and something written in one system may not work in another
system (because of different endianess, different floating point number
formats and so on). This, however, shouldn't matter when you are only
working for yourself. You can always give the source code in plain ascii
to others.

  By the way, as far as I know perl uses this tactique, that is, it first
parses the source script, byte-compiles it and then interprets this byte code.
This makes perl one of the fastest scripting languages in existence.
  And since perl "compiles" in the background, hidden from the user, the user
doesn't have to worry about the compilation step (as happens with java).
  But as I said, byte-compiling is beneficial only when there are loops and
other similar things in the code.

: I've stored integers between 0 and 10 in an array of doubles...

  Usually a bad idea :)
  (Well, for integer values between 0 and 10 it's ok, but don't use much
larger or smaller values... :) )

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: POV-Ray does not do massive string
: searches, there are much better ways of finding them and they don't require
: a binary file format or something.

  Yes, parsing doesn't need repetitive string search (even if we have
several keywords with identical beginnings), but what about interpreting
the string?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: And the only benefit would be lower memory usage, which is 
: really only relevant if you are storing huge arrays.

  It's not the only benefit. The other benefit would be precision. If you
use very large integers, floats may lose information.
  This may be important when making mathematical operations. For example:

25^7/1953125  ( = 3125 )

may give a different result if we use integers or if we use floats.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:
> 
> Chris Huff <chr### [at] maccom> wrote:
> : And the only benefit would be lower memory usage, which is
> : really only relevant if you are storing huge arrays.
> 
>   It's not the only benefit. The other benefit would be precision. If you
> use very large integers, floats may lose information.
>   This may be important when making mathematical operations. For example:
> 
> 25^7/1953125  ( = 3125 )
> 
> may give a different result if we use integers or if we use floats.

... and this is why one should never check equality between two floats!

-- 
François DISPOT  --  http://www.wozzeck.net
      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

Post a reply to this message

Warp wrote:

>   Byte-compiled code will be faster to parse only when you have big loops
> (I mean "big" in number of iterations), macros and so on. Reading a regular
> file without them will only slow the parsing (because it has to first parse
> it, as it does now, byte-compile it and then interpret that byte code).

I frequently find myself making the cimputer do the work, as in the research
outpost I just posted, my spiral forest, my crystal macro, my polyhedral
snowflakes.

>   One advantage of byte-compiling is that you could save the binary data
> to a file and then read it afterwards, saving the parsing and compilation
> steps.

Yup!

>   A disadvantage of writing byte-coded binary data is that it's
> system-specific and something written in one system may not work in another
> system (because of different endianess, different floating point number
> formats and so on). This, however, shouldn't matter when you are only
> working for yourself. You can always give the source code in plain ascii
> to others.

I was thinking, not compiling it to machine code, but compressing the text. Ie,
have a one or two byte code for each keyword. Searching through that would be
instantaneous compared to text searching. But word seems to have it POV already
does this type of thing to some extent.

>   By the way, as far as I know perl uses this tactique, that is, it first
> parses the source script, byte-compiles it and then interprets this byte code.
> This makes perl one of the fastest scripting languages in existence.
>   And since perl "compiles" in the background, hidden from the user, the user
> doesn't have to worry about the compilation step (as happens with java).
>   But as I said, byte-compiling is beneficial only when there are loops and
> other similar things in the code.

I don't think it would add much to parse time for non-cpu-intensive-parsing
scenes, which usualy parse fast anyway. My big LEGO scenes parse in a matter of
minutes if not seconds, compared to half an hour or an hour for cpu-intensive
parses.

> : I've stored integers between 0 and 10 in an array of doubles...
>
>   Usually a bad idea :)

Yes, but it's the only option in POV-script!

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

Thorsten Froehlich wrote:

> POV-Ray already does what you are suggesting.  in general, your suggestions
> are necessary to get any working parser.  POV-Ray does not do massive string
> searches, there are much better ways of finding them and they don't require
> a binary file format or something.

Ooh, good.

> No, the reason for the slow parsing of POV-Ray scenes are mostly related to
> memory allocation.  Please note that this topic has been discussed for an
> endless time before, just go back far enough in either povray.general or
> povray.programming .

Hmm, it takes 30 seconds to generate one layer of my dome, but each layer has
<300 pieces.

> > Perhaps it is asking too much...
>
> Why this remark?

Parsers are kinda tedious to write, no?

> > Also, perhaps, different variable types. I don't know how many times
> > I've stored integers between 0 and 10 in an array of doubles...
>
> What is wrong with this in POV-Ray, it will store the integers in the array
> just fine?  And they should also work just like any other numbers, after
> all, "real" math doesn't really make a difference between 'doubles' and
> 'integers' either (for the functions POV-Ray offers).

Accuracy and calculation speed.

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

On 29 Aug 2000 11:56:31 -0400, Warp wrote:
>Chris Huff <chr### [at] maccom> wrote:
>: And the only benefit would be lower memory usage, which is 
>: really only relevant if you are storing huge arrays.
>
>  It's not the only benefit. The other benefit would be precision. If you
>use very large integers, floats may lose information.
>  This may be important when making mathematical operations. For example:
>
>25^7/1953125  ( = 3125 )
>
>may give a different result if we use integers or if we use floats.

Indeed. If you compute this with standard 32 bit integer arithmetic, the
result is 925. Probably not what you had in mind. 

        hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

In article <39abdd2e@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   It's not the only benefit. The other benefit would be precision. If you
> use very large integers, floats may lose information.

Just like integer precision decreases the smaller the numbers get.  Try 3/2
for example ;-)

You should also consider that POV-Ray uses floats/doubles for nearly every
internal calculation, so the use of integers does not make sense for a lot
of things.  Only as counters and array indices they would be really useful,
but within the common ranges (those that don't blow the memory limits) of
for example +-1000000 the precision limit of doubles should be far (enough)
behind the comma even after several calculations with it.


     Thorsten

Post a reply to this message

In article <39abd881@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

> Thorsten Froehlich <tho### [at] trfde> wrote:
> : POV-Ray does not do massive string
> : searches, there are much better ways of finding them and they don't require
> : a binary file format or something.
>
>   Yes, parsing doesn't need repetitive string search (even if we have
> several keywords with identical beginnings), but what about interpreting
> the string?

I agree, POV-Ray should really use a DFA for this...


     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

In article <39A### [at] faricynet> , David Fontaine 
<dav### [at] faricynet>  wrote:

> Hmm, it takes 30 seconds to generate one layer of my dome, but each layer has
> <300 pieces.

Memory consumption is not directly related to the number of objects to
generate...

> Accuracy and calculation speed.

Accuracy maybe, but speed no.  All modern processors used in personal
computers (and better) have floating-point unit(s) which will be able to
perform basic mathematical operations in the same (if not less, i.e. for
divisions) time as the integer unit(s) do.


      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

Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
: Indeed. If you compute this with standard 32 bit integer arithmetic, the
: result is 925. Probably not what you had in mind. 

  I didn't check if the values would fit into a 32-bit integer, but you get
the idea.
  And if integers are ever implemented in povray, there should be a very long
integer type (at least 64 bits) anyways :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

David Fontaine <dav### [at] faricynet> wrote:
: I was thinking, not compiling it to machine code, but compressing the text.

  Machine code and byte-code are different things.
  Well, yes, they are very similar. The difference is that machine code is
the one that the processor reads directly (the textual representation of
machine code is called assembler (or assembly, I'm not sure)). Byte-code is
similar to machine code, but it's interpreted by the program. Byte-code has
more freedom on what commands you can implement and what things it can do.
You can put support for very application-specific commands in your byte-code
interpreter; this is not usually possible with machine code. The avantage
of byte-code over interpreted source code is speed.

  Compressing the text has little effect in speed. It may have some minor
speed improvement since you don't have to compare 8 characters but just 2,
but in the average the speed improvement will probably be very small. The
length of the keywords, identifier names and so on is not so important.
  Parsing and interpreting a file doesn't need string search. Even when
you are looking for several keywords which have an identical beginning
(such as int, interior, interpolate, intersection, intervals) you only have
to go through the text once, without having to go back and forth.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:

> No, the reason for the slow parsing of POV-Ray scenes are mostly related to
> memory allocation.  Please note that this topic has been discussed for an
> endless time before, just go back far enough in either povray.general or
> povray.programming .

I've kind of wondered about that.  I have a scene that parses in 15 minutes,
or rather, all the *code* is read in in 15 minutes.  All the #render lines
are printed, but it's another 2.5 hours before it gets around to setting up
the scene.  Why is this?  Does it do a preparse, where it checks the code,
then allocates memory?  The scene is memory intensive, so that would make
sense.

However, it's really annoying.  I use the #render messages to know how far
it's gotten in the parse, but it's useless if it only tells how far it is in
the parse and not how far along it is towards actually starting on the
scene.

The other question I have is, why does memory allocation take so long
compared to the inital parse?

Geoff

Post a reply to this message

In article <39ad151a@news.povray.org> , Geoff Wedig 
<wed### [at] darwinepbicwruedu>  wrote:

> I've kind of wondered about that.  I have a scene that parses in 15 minutes,
> or rather, all the *code* is read in in 15 minutes.  All the #render lines
> are printed, but it's another 2.5 hours before it gets around to setting up
> the scene.  Why is this?  Does it do a preparse, where it checks the code,
> then allocates memory?  The scene is memory intensive, so that would make
> sense.
>
> However, it's really annoying.  I use the #render messages to know how far
> it's gotten in the parse, but it's useless if it only tells how far it is in
> the parse and not how far along it is towards actually starting on the
> scene.

Once parsing is done, POV-Ray generates bounding boxes.  This will take
additional memory, and if at this time your system runs out of physical
memory, it will cause a significant slowdown due to swapping.

You can turn off building of bounding boxes which will make this stage
faster at the expense of rendering speed.  As building the bounding boxes in
an internal process that happens after parsing, you can't see anything.

> The other question I have is, why does memory allocation take so long
> compared to the inital parse?

Memory is managed by the operating system and in general requires more or
less advanced algorithms (depending on whether you expect lots of small or a
few big blocks, average number expected per application, and millions of
other small issues).


     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

Thorsten Froehlich wrote:

> > Hmm, it takes 30 seconds to generate one layer of my dome, but each layer has
> > <300 pieces.
>
> Memory consumption is not directly related to the number of objects to
> generate...

Each layer takes just over 5 megs. 30 seconds to alocate that?? I've done scenes
where 10 megs are allocated in five seconds, because there is no CPU-intensive
parsing. Of course, comparing, say, POV to C, wouldn't be remotely fair, but I'd be
willing to bet even interpreted BASIC could run my code faster.

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

Warp wrote:

>   Machine code and byte-code are different things.
>   Well, yes, they are very similar. The difference is that machine code is
> the one that the processor reads directly (the textual representation of
> machine code is called assembler (or assembly, I'm not sure)). Byte-code is
> similar to machine code, but it's interpreted by the program. Byte-code has
> more freedom on what commands you can implement and what things it can do.
> You can put support for very application-specific commands in your byte-code
> interpreter; this is not usually possible with machine code. The avantage
> of byte-code over interpreted source code is speed.

Okay, but how can byte-code be platform dependant then?

>   Compressing the text has little effect in speed. It may have some minor
> speed improvement since you don't have to compare 8 characters but just 2,
> but in the average the speed improvement will probably be very small. The
> length of the keywords, identifier names and so on is not so important.
>   Parsing and interpreting a file doesn't need string search. Even when
> you are looking for several keywords which have an identical beginning
> (such as int, interior, interpolate, intersection, intervals) you only have
> to go through the text once, without having to go back and forth.

What about control aids? They would process much faster in byte-code. Thorsten
says it already does something like this though...

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: Once parsing is done, POV-Ray generates bounding boxes.  This will take
: additional memory, and if at this time your system runs out of physical
: memory, it will cause a significant slowdown due to swapping.

  I think that the light buffers also take a considerable amount of memory
and time when you have a lot of light sources.
  I have run out of memory due to light buffers caused by excessive amount
of light sources.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

David Fontaine <dav### [at] faricynet> wrote:
: Okay, but how can byte-code be platform dependant then?

  Well, it depends how you make your byte code.

  The most efficient way of storing numbers (integers and floats) is to
write their byte values in memory directly to the file as raw binary data.
In this way they will take the least space and they can be read very fast
(you don't have to parse it, you just read that binary data directly into
the memory location that represents your variable).

  This is, however, very system-dependant. Some systems use big-endian
numbers while others use low-endian numbers. If you try to read a big-endian
number directly into a variable, as described above, but the system uses
low-endian numbers, the value assigned to the variable will be little less
than rubbish.

  You could of course change the endianess of the number while reading if
you know that you have to, but that destroys the point why we are making
this in the first place: Speed.

  Endianess, however, is not the only problem. Some systems can use a
different floating point number format than other systems. Even when using
the same format (usually the IEEE standard format), the size (in bytes) of
the numbers may differ.
  When we are dealing with integers, there might be some systems that do
not use a complement-of-2 format for them, as most systems do. Again, if
we try to read raw binary data of the wrong format, we get just rubbish.

  Another way of storing the numbers is to use a povray-specific and
platform-independent format and then for each specific system parse this
number and convert it to the native format.
  The ascii representation of a number (the one we use in povray code) is,
in fact, this kind of platform-independent coding.
  The ascii representation as one drawback: It's long and inefficient.
  A more compact and efficient representation could be designed, but still
we have to problem of slow parsing and conversion between formats.

: What about control aids? They would process much faster in byte-code. Thorsten
: says it already does something like this though...

  I don't know how isosurface functions are implemented in megapov, but I
wouldn't be surprised if they were converted to byte-code (which uses
stack arithmetic) which is interpreted while rendering. And we all know
how fast isosurfaces are (they are incredibly fast).
  Someone who knows could tell us how it is done.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39ad99dd@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   The most efficient way of storing numbers (integers and floats) is to
> write their byte values in memory directly to the file as raw binary 
> data.
> In this way they will take the least space and they can be read very fast
> (you don't have to parse it, you just read that binary data directly into
> the memory location that represents your variable).
...snip...

This only applies to *saving* the byte code data. And as you mentioned, 
it is possible to save/read the data on platforms of both endianness. 
While this is slower, it isn't as slow as reading ASCII.
But this doesn't really matter, since you don't need to save the byte 
code to a file that will go to another system. At most, a temporary file 
will be needed. Most or all of it can reside in RAM, and be processed 
much faster than POV can parse now. Since you can always use the 
original source file, there isn't any need for the byte codes to be 
saved to their own format.


> : What about control aids? They would process much faster in byte-code.

What are "control aids"?


>   I don't know how isosurface functions are implemented in megapov, but I
> wouldn't be surprised if they were converted to byte-code (which uses
> stack arithmetic) which is interpreted while rendering. And we all know
> how fast isosurfaces are (they are incredibly fast).
>   Someone who knows could tell us how it is done.

I think the isosurface functions do use byte codes or a similar 
technique. I don't understand either one of them well enough to say for 
sure, though.
And I wouldn't call them "incredibly fast"...well, if you compare them 
to the POV-Script parser...and they are surprisingly fast. Just not 
"incredibly" fast. :-)

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: And I wouldn't call them "incredibly fast"...well, if you compare them 
: to the POV-Script parser...and they are surprisingly fast. Just not 
: "incredibly" fast. :-)

  Well, since isosurfaces are faster than many builtin primitives, like
polys or superellipsoids, I'd say that isosurfaces are incredibly fast.
  Polys and superellipsoids don't have to parse anything the user has written.
Only the numeric values are stored at parse time into variables (which don't
differ in any way of any other variable used by the machine code) and at
render time a fixed-type code is run to test intersections etc.
  Isosurface functions, however, have to be somehow interpreted each time you
want a value. The function is not coded in a native machine code, but it's
a byte code (or whatever) that has to be interpreted (much like java byte
code, for example).
  Moreover, you need to get several values from the function for each
intersection test, which makes its speed even more incredible.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39AD60A7.E24533EC@faricy.net> , David Fontaine 
<dav### [at] faricynet>  wrote:

> What about control aids? They would process much faster in byte-code. Thorsten
> says it already does something like this though...

No, I didn't say it uses byte-code.  I said that it does what you were
suggesting, and that was "binary code" :-)

I interpreted "binary code" as using "hash value"...

A hash table is basically a binary shortcut for a string, so all you need to
do is generate the hash value and then compare two integers.  Of course
there will be duplicate hash values, so you then compare just a few strings
(or use another method - there are textbooks full of it).


    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

Chris Huff wrote:

> What are "control aids"?

do while for next if then elseif endif
switch case call goto gosub break
teehee           ^^^^
                 EVIL


--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

Thorsten Froehlich wrote:

> No, I didn't say it uses byte-code.  I said that it does what you were
> suggesting, and that was "binary code" :-)
>
> I interpreted "binary code" as using "hash value"...
>
> A hash table is basically a binary shortcut for a string, so all you need to
> do is generate the hash value and then compare two integers.  Of course
> there will be duplicate hash values, so you then compare just a few strings
> (or use another method - there are textbooks full of it).

Oh, well then I demand byte-code! :-)

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

In article <39ADE0D3.BE78C21D@faricy.net>, David Fontaine 
<dav### [at] faricynet> wrote:

> Chris Huff wrote:
> 
> > What are "control aids"?
> 
> do while for next if then elseif endif
> switch case call goto gosub break
> teehee           ^^^^
>                  EVIL

Oh...I always called those "flow control keywords". I've never heard 
them called "control aids"...
And I agree about goto, I have never used it. In fact, I barely ever use 
"break" outside of a switch statement...I think the first time was just 
yesterday, in the #set patch...and even there I considered using a while 
loop instead.
I don't recognize some of those keywords(elseif, endif, call, teehee), 
are they from a BASIC variant?
Hmm, the POV-Script list would be:
#while, #if, #else, #switch, #case, #range, #macro, #end, #break...did I 
miss any?
Oh, #include, I guess...and MegaPOV functions.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <39adaae1@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Well, since isosurfaces are faster than many builtin primitives, like
> polys or superellipsoids, I'd say that isosurfaces are incredibly fast.
...snip...
>   Moreover, you need to get several values from the function for each
> intersection test, which makes its speed even more incredible.

Ok, ok...isosurfaces are incredibly fast, especially when you consider 
what they have to do. But I think most of this advantage is in the 
solving method, not in the functions themselves. I have always wondered 
how much faster it would be if the same functions were written in C and 
called directly.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:

> #while, #if, #else, #switch, #case, #range, #macro, #end, #break...did I
> miss any?
> Oh, #include,

#local

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <39AE849E.C1C91C82@pacbell.net>, lin### [at] povrayorg 
wrote:

> Chris Huff wrote:
> 
> > #while, #if, #else, #switch, #case, #range, #macro, #end, #break...did I
> > miss any?
> > Oh, #include,
> 
> #local

I wouldn't call #local and #declare flow control keywords/control aids, 
sorry. :-)
Though they certainly are necessary for any useful amount of work to be 
done.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:

> Oh...I always called those "flow control keywords". I've never heard
> them called "control aids"...
> And I agree about goto, I have never used it. In fact, I barely ever use
> "break" outside of a switch statement...I think the first time was just
> yesterday, in the #set patch...and even there I considered using a while
> loop instead.

Yup...

> I don't recognize some of those keywords(elseif, endif, call, teehee),
> are they from a BASIC variant?

Yup, in BASIC you use endif to end an if and elseif instead of
else-if-endif, and call calls a function. BASIC is kinda stupid anyway...

> Hmm, the POV-Script list would be:
> #while, #if, #else, #switch, #case, #range, #macro, #end, #break...did I
> miss any?
> Oh, #include, I guess...and MegaPOV functions.

I suppose in POV #include can redirect flow like anything else, but not in
C.

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: miss any?

  ?:

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39aedd8c@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   ?:

Yuck.
I did't think this was supported by POV, but I found a reference in the 
documentation(though it took searching for all ? marks...). Oh, 
well...it might be considered equivalent to the #if-#else-#end group, or 
it might be considered a separate one.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
:>   ?:

: Yuck.
: I did't think this was supported by POV

  Even a very advanced user doesn't know every single feature of povray :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:

> Chris Huff <chr### [at] maccom> wrote:
> : miss any?
>
>   ?:

Yup! Now why would they put that in POV but not things like +=, -=, *=, /=,
++, --? And where's the stinkin' #for? :)
Will 3.5 have operators instead of functions for modulo and/or powers?

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

In article <39AF1FCD.4B0CE825@faricy.net>, David Fontaine 
<dav### [at] faricynet> wrote:

> Yup! Now why would they put that in POV but not things like +=, -=, 
> *=, /=, ++, --?

Don't ask me...though I will look to see how difficult it would be to 
add them.


> And where's the stinkin' #for? :)

Now, *this* I have no idea how to implement, though I would use a 
C/Java-like syntax instead of the BASIC-like syntax.


> Will 3.5 have operators instead of functions for modulo and/or powers?

Unknown. I have written a patch which adds a ^ operator for 
exponentiation, but it may not be included. The modulo operator would be 
just as easy...but the best operator to use for it would be %, and that 
is already used in MegaPOV as a shortcut for #local. Both of these 
operators are useable in functions, however.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-BA3801.11085731082000@news.povray.org...
| Hmm, the POV-Script list would be:
| #while, #if, #else, #switch, #case, #range, #macro, #end, #break...did I
| miss any?
| Oh, #include, I guess...and MegaPOV functions.

Also #ifdef, #ifndef.

That's all the Conditional Directives I think.    #else, #end, #case, #break
aren't actually "conditional" I guess.

In the Doc it lists Language Directives like this:

#break #case #debug #declare
#default #else #end #fclose
#fopen #local #macro #read
#render #statistics #switch #undef
#version #warning #write

#error is mentioned elsewhere and yet not shown in the list.  Maybe a
mistake in the Doc, it's called "Fatal" in the Text Stream section.

Bob

Post a reply to this message

Chris Huff wrote:

> > And where's the stinkin' #for? :)
>
> Now, *this* I have no idea how to implement, though I would use a
> C/Java-like syntax instead of the BASIC-like syntax.

From a preprocessor perspective,
   #for(init, test, increment)
      ...
   #end
would be changed to
   init
   #while (test)
      ...
      increment
   #end
but I don't know how easily that applies to POV parsing, probably not at
all.

> Unknown. I have written a patch which adds a ^ operator for
> exponentiation, but it may not be included. The modulo operator would be
> just as easy...but the best operator to use for it would be %, and that
> is already used in MegaPOV as a shortcut for #local. Both of these
> operators are useable in functions, however.

Yeah! No typing '#local' anymore! I'll probably do it anyway...

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message

In article <39B### [at] faricynet>, David Fontaine 
<dav### [at] faricynet> wrote:

> From a preprocessor perspective,
>    #for(init, test, increment)
>       ...
>    #end
> would be changed to
>    init
>    #while (test)
>       ...
>       increment
>    #end
> but I don't know how easily that applies to POV parsing, probably not at
> all.

I don't think it would be very easy, if at all possible, to convert a 
#for loop to a #while loop. It would probably be best to implement a 
completely separate loop. However, I don't know that part of the 
source(yet), so I could easily be wrong.


> Yeah! No typing '#local' anymore! I'll probably do it anyway...

Do what? Type #local?
BTW, those shortcuts won't make it into 3.5, since they don't work quite 
right, so maybe % *can* eventually be used as a modulus operator.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On 30 Aug 2000 09:51:17 -0400, Warp wrote:
>Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
>: Indeed. If you compute this with standard 32 bit integer arithmetic, the
>: result is 925. Probably not what you had in mind. 
>
>  I didn't check if the values would fit into a 32-bit integer, but you get
>the idea.
>  And if integers are ever implemented in povray, there should be a very long
>integer type (at least 64 bits) anyways :)

In which case the space advantage of integers would vanish. 
They would only have a slight accuracy advantage (63 instead of 53 bits
"mantissa"). The speed difference is probably negligible.

I really don't see any advantage in introducing integers in povray. 

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

On Thu, 31 Aug 2000 23:20:44 -0500, Chris Huff wrote:
>In article <39AF1FCD.4B0CE825@faricy.net>, David Fontaine 
><dav### [at] faricynet> wrote:
>
>> And where's the stinkin' #for? :)
>
>Now, *this* I have no idea how to implement, though I would use a 
>C/Java-like syntax instead of the BASIC-like syntax.

Since a C for loop:

for (A; B; C) {
    D;
}

is just an abbreviation for

A;
while(B) {
    D;
    C;
}

(well, if you ignore continue, anyway)
and we already have a while loop in Povray, that shouldn't be too hard.

>The modulo operator would be just as easy...but the best operator
>to use for it would be %, and that is already used in MegaPOV as a
>shortcut for #local.

Oh. I didn't notice that. Cool! I always thought that redeclaring a
variable at every assignment is somewhat inelegant.

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

In article <slr### [at] tealhhjpat>, 
hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:

> Since a C for loop:
...
> is just an abbreviation for
...
> (well, if you ignore continue, anyway)
> and we already have a while loop in Povray, that shouldn't be too hard.

It might not be easy to internally convert a for loop to a while loop, 
it may require a completely separate loop.


> Oh. I didn't notice that. Cool! I always thought that redeclaring a
> variable at every assignment is somewhat inelegant.

That shortcut still redeclares the variable, it is just a typing 
shortcut, but I agree that it is inelegant to redeclare a variable just 
to assign to it. That is the exact reason I added a #set keyword in my 
patch, so you can use a separate keyword for modifying variables.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
:>  And if integers are ever implemented in povray, there should be a very long
:>integer type (at least 64 bits) anyways :)

: In which case the space advantage of integers would vanish. 

  I said "there should be *A* very long integer type".
  I did NOT say "the integer type of povray should be very long".

  The first statement doesn't imply there could not be a shorter integer
as well.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

David Fontaine <dav### [at] faricynet> wrote:
: And where's the stinkin' #for? :)

  I don't miss a #for in povray. It would be just a little shortcut, and
that's it.
  What I really miss is a #do...#while (or for practical resons better
yet #do...#until).
  You can achieve the same effect with a regular #while, but not without
repeating code.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39b27663@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   I don't miss a #for in povray. It would be just a little shortcut, and
> that's it.

Well, it could make some things more readable...but I agree that it 
isn't very necessary.


>   What I really miss is a #do...#while (or for practical resons better
> yet #do...#until).
>   You can achieve the same effect with a regular #while, but not without
> repeating code.

Yes, I see why having these implemented natively would be better than 
"emulating" them with a #while loop...but I think I have only used one 
do...while loop in C. They aren't often used...but if #for loops are 
implemented, I think either #do...while() or #do...until() loops should 
be. Probably #do...#until, since using #while could confuse the parser.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On 3 Sep 2000 12:01:19 -0400, Warp wrote:
>Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
>:>  And if integers are ever implemented in povray, there should be a very long
>:>integer type (at least 64 bits) anyways :)
>
>: In which case the space advantage of integers would vanish. 
>
>  I said "there should be *A* very long integer type".
>  I did NOT say "the integer type of povray should be very long".
>
>  The first statement doesn't imply there could not be a shorter integer
>as well.

Sorry, I misread that. But I disagree. Types of different size are fine
for low-level languages like C (<flamebait>or Java</flamebait>), but I
don't think they are very useful for Povray. 

Basically, I think using double for everything (like it is now) is the
best solution: It has a reasonable range, accuracy and speed as an FP
number. It can be used as a perfectly accurate 54-bit integer number. 
There is only one type, so the user doesn't have to think about whether
automatic type conversion will do the right thing or whether he must
insert casts. 

Integers smaller than a double have an advantage (memory- and speedwise)
mainly if there are a lot of them. Maybe adding an element type (single
(32-bit float), int_32, int_16, int_8, int_1 (aka boolean)) to arrays
would make sense. Same might be true for some builtin types (e.g.,
meshes). Are height fields stored internally as mesh of
3d-double-precision vectors or as a 2D-array of integer numbers?

But I'm not too sure of that. Does anybody here have scenes with really
large arrays, where the parsing overhead is *not* the bottleneck?

For some applications a double FP isn't precise enough. int_64 and long
double (80 bit on Intel, up to 128 bit on some other architectures) have
good HW support, but also finite precision and range. An arbitrary
precision type would be nice, but I think it would be really bad on
performance, since it would probably have to be used everywhere to avoid
nasty surprises.

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

On Sun, 03 Sep 2000 10:06:17 -0500, Chris Huff wrote:
>In article <slr### [at] tealhhjpat>, 
>hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:
>> Oh. I didn't notice that. Cool! I always thought that redeclaring a
>> variable at every assignment is somewhat inelegant.
>
>That shortcut still redeclares the variable, it is just a typing 
>shortcut,

Yes. But as far as "elegance" goes, I am more concerned about my POV
Scripts than what POV internally does with them.

    % a = a + 1

really looks much more like an ordinary assignment than

    #local a = a + 1


>but I agree that it is inelegant to redeclare a variable just 
>to assign to it. That is the exact reason I added a #set keyword in my 
>patch, so you can use a separate keyword for modifying variables.

Saw it just after my reply.  #set somewhat reminds me of BASIC or some
shells, but that's ok.

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
: There is only one type, so the user doesn't have to think about whether
: automatic type conversion will do the right thing or whether he must
: insert casts. 

  Not exactly.
  Yes, the user defined numbers can only be doubles, but povray handles these
numbers as integers in some places. When you give povray a non-integer value
in one of these places, povray just converts it to an integer.
  This might have undesired results sometimes. For example, if you for one
reason or another give it a value of, eg. 1.5 povray will round it (I don't
know if it just rounds it to 1 or to the nearest integer value; if the latter,
the result is even worse since it may depend on the system whether it rounds
it to 1 or to 2). If you want to be absolutely sure that povray will get
the right value, you'll have to "cast" the value :)

: For some applications a double FP isn't precise enough. int_64 and long
: double (80 bit on Intel, up to 128 bit on some other architectures) have
: good HW support, but also finite precision and range.

  It's not possible to define a hardware-supported int_64 in ANSI C if the
default value of int is 32 bits long. In some 64-bit systems the long int
type is 64 bits, but not in any 32-bit system (at least not any I know).
  Some systems (such as linux and solaris) support the type long long, which
makes a 64-bit variable. However, this type is not part of the ANSI C.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 3 Sep 2000 12:03:48 -0400, Warp wrote:
>David Fontaine <dav### [at] faricynet> wrote:
>: And where's the stinkin' #for? :)
>
>  I don't miss a #for in povray. It would be just a little shortcut, and
>that's it.
>  What I really miss is a #do...#while (or for practical resons better
>yet #do...#until).
>  You can achieve the same effect with a regular #while, but not without
>repeating code.

#declare FirstTime = 1;
#while ( FirstTime | (<condition>))
  <code>
  #declare FirstTime = 0;
#end


-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker wrote:

> >  You can achieve the same effect with a regular #while, but not without
> >repeating code.
>
> #declare FirstTime = 1;
> #while ( FirstTime | (<condition>))
>   <code>
>   #declare FirstTime = 0;
> #end

Either way you need an extra comparison...

--
David Fontaine   <dav### [at] faricynet>   ICQ 55354965
Please visit my website:  http://davidf.faricy.net/

Post a reply to this message