"Ben Chambers" <bdc### [at] yahoocom> wrote>
> The explicitness of a preprocessing stage has nothing to do with the
> language itself.  For instance, MSVC will automatically, preprocess,
compile
> and link objects all in one step.  gcc on the other hand, has separate
tools
> for preprocessing, compiling, assembling, and linking (though you have a
> common 'control' file to do it all at once).  In one of them, it is very
> explicit; in the other, it is implicit.  But they both work.

Exactly. I would add that, long ago, there was such a thing as Zortec C
compiler (that product was first named Datalight Optimum C, then Zortec
C/C++, then Symantec C/C++; highly regarded; written by Walter Bright) that
had separate parsing (parse tree generation), optimization, and code
generation stages; with intermediate files, of course :-) But does that
prove anything?

I do think that if a language *defines* distinct pre-processing stage, that
*unnecessary* limits it, to a great extent (more on this in another
message). In C, many things could have been rectified if 'const' were
defined properly (not as a mere storage class specifier, but in a way it was
done in C++), and 'inline' were timely introduced in standard (and not
merely provided as extensions by vistually every compiler vendor).

> That being said, I think it's important to maintain the distinction
between
> the preprocessing and the processing.  In fact, it might be useful to have
> an option for outputting a preprocessed file, in case someone needs to see
> exactly how their loops are unrolling or something like that.

I do not think this would be useful at all... How often do you look at the
output of C preprocessor? As to me, I have a definit answer: about a dozen
times -- when I was tweaking Decus CPP (freeware C preprocessor) to my needs
:-)

Post a reply to this message

"Christopher James Huff" <chr### [at] maccom> wrote
> I don't think the mere presence of a preprocessor is a flaw in a
> language. And in this case, it is rather unavoidable...unless you want
> to re-evaluate the entire scene for each ray cast.

Using functions instead of some macros is effectively the replacement of
preprocessor features with the language features. Does this lead to
re-evaluation of entire scene for each ray cast?

Of course, some things must be 'const'... But even this requirement can be
lifted if an object is to be used solely in the 'object' pattern, right?

Post a reply to this message

On Thu, 14 Mar 2002 12:39:35 +0300, "Vadim Sytnikov" <syt### [at] rucom> wrote:
> Using functions instead of some macros is effectively the replacement of
> preprocessor features with the language features. Does this lead to
> re-evaluation of entire scene for each ray cast?

Using functions() in parsing time is the same as using trace() for further
parsing.

ABX

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote
> In section 6.2 you mention that the Intel compiler will turn multiple
> divisions by the same number into one division and then uses
multiplications
> for floating-point numbers.  Do you know if in its current version the
Intel
> compiler still does this?

I don't know -- I did not use Intel compiler for several years now. What I
do know is that neither Visual C 6.0 nor GCC 2.95 (the compilers I'm
currently using) can do this...

Post a reply to this message

> If you actually use the
> language as it is for complex tasks, you will find the separation between
> scene description and (programming) language very natural and essential
for
> the flexibility that is simply impossible otherwise.

Ironically, what I'm talking about is that same flexibility... Say, what
about using loops and switches in functions? Although I did not see the code
yet, I can only guess why, but pretty reliably -- based on the fact that you
used select() instead of simple 'arithmetic if'...

I'm sure that one day we will see functions as complex as shaders in
RenderMan. By the way, I do not think that there exist any fundamental
difficulty for that -- I know that many have branded that not feasible on
portability grounds. But -- that only applies to the solution that was
implemented in POVMan (based on POV-Ray 2.2, IIRC), which employed bytecode
compiler built with Flex/Bison. If you look at how it was done in BMRT, you
will find quite different solution, less powerful, but more portable (SL
files are not even compiled, they are, err... preprocessed :-)

So my point is -- we should not have, say, two different if's, for parse and
rendering time, but rather a single statement. If its control expression
does evaluate to a constant -- OK, it works like present #if. If it does
not -- well, it depends. If context does allow the use of functions (say, in
a height_field or an image_map), then, if we are not inside a function body
already, then that 'if' should be implicitly wrapped by the automatically
generated function (and should thus work as 'if' in Algol -- that is, return
a value). If the context does not allow that -- signal an error.

These may probably be tomorrow's solutions, but we must not render them
theoretically impossible today...

Post a reply to this message

Vadim Sytnikov wrote:
> 
> [...]
> 
> I'm sure that one day we will see functions as complex as shaders in
> RenderMan. By the way, I do not think that there exist any fundamental
> difficulty for that -- I know that many have branded that not feasible on
> portability grounds. But -- that only applies to the solution that was
> implemented in POVMan (based on POV-Ray 2.2, IIRC), which employed bytecode
> compiler built with Flex/Bison. If you look at how it was done in BMRT, you
> will find quite different solution, less powerful, but more portable (SL
> files are not even compiled, they are, err... preprocessed :-)

One major concern about functions is speed.  Although PovMan can be very
useful, the performance of shaders compared to Povray 3.5 functions is
rather bad i think.  I have not worked with BMRT, but i doubt it is
faster.

> So my point is -- we should not have, say, two different if's, for parse and
> rendering time, but rather a single statement. If its control expression
> does evaluate to a constant -- OK, it works like present #if. If it does
> not -- well, it depends. If context does allow the use of functions (say, in
> a height_field or an image_map), then, if we are not inside a function body
> already, then that 'if' should be implicitly wrapped by the automatically
> generated function (and should thus work as 'if' in Algol -- that is, return
> a value). If the context does not allow that -- signal an error.

From how i understand this you want to mix up the parse time and render
time level.  Note this is quite different from the previosly discussed
directives and scene description layers during parsing.  I don't know how
much you have worked with Povray 3.5 functions, but to distinguish between
those two levels is quite essential for scene design.

For example have a look at:
http://www-public.tu-bs.de:8080/~y0013390/pov/water/water_inc.html

for a scene efficiently using directives in functions.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Mar. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Thu, 14 Mar 2002 15:06:32 +0300, "Vadim Sytnikov" <syt### [at] rucom> wrote:
> Ironically, what I'm talking about is that same flexibility... 

All thigs you described lead you to reevaluation for every ray. "#If"
statement is used to return part of code at time of calling this "#if".
"select" statement is used to return float at time of calling this "select".
If we join them then for every call it should be reevaluated. Imagine such
example:

pigment{
  function{
    if(y>0)
     pattern{object{
       if(z>0)
         sphere{0 1
       else
         box{-1 1
       end
         rotate x* if ( vlength(<x,y,z> > 1 )  30 else (2+x+y+z) end
       }}}
    else
      x+y+z
   end
  }
}

Of course everybody wants local variables in functions and more programing
features in functions but creation of function should be separated with runing
it. Note you could use loop: to create short function with loop started for
each call, or long function with loop started by preprocesor and called
unrolled but efficient. How can parser know what you want if you don't specify
this with different name for each loop keyword ?

ABX

Post a reply to this message

> If we join them then for every call it should be reevaluated. Imagine such
> example:
>
> pigment{
>   function{
>     if(y>0)
>      pattern{object{
>        if(z>0)
>          sphere{0 1
>        else
>          box{-1 1
>        end
>          rotate x* if ( vlength(<x,y,z> > 1 )  30 else (2+x+y+z) end
>        }}}
>     else
>       x+y+z
>    end
>   }
> }

Thanks a lot -- you have given me a perfect illustration why (in a good
language) there must be no such thing as pre-processor. Let's rip short
piece out of it and have a closer look:

object{
   if(z>0)
     sphere{0 1
   else
     box{-1 1
    end
    rotate x* if ( vlength(<x,y,z> > 1 )  30 else (2+x+y+z) end
}

This code fragment is only possible since it is fed to pre-processor, not to
SDL interpreter... Otherwise, you would *have* to write something like this:

#local Rotate = transform { rotate ... }
object { ... Rotate }

(for obvious reasons), that is both more reliable, and... more elegant. A
language with that powerful pre-processor is at risk to quickly become a
"write-only" language, you know... (Perl had succeeded at that w/o
preprocessor at all, but nevertheless... :-)

Post a reply to this message

On Thu, 14 Mar 2002 17:12:26 +0300, "Vadim Sytnikov" <syt### [at] rucom> wrote:
> Thanks a lot -- you have given me a perfect illustration why (in a good
> language) there must be no such thing as pre-processor. 

I think you missed important part of this example, it is written inside of
function so this means it should be evaluated for every intersection point as
showed used x,y,z variables.

> This code fragment is only possible since it is fed to pre-processor, not to
> SDL interpreter... Otherwise, you would *have* to write something like this:
>
> #local Rotate = transform { rotate ... }
> object { ... Rotate }

I don't understand your answer at all. And I feel that it is becouse you don't
understand existence of function{}. (Note above two-line-script contains
error)

> (for obvious reasons), that is both more reliable, and... more elegant.

It is elegant separating "if"s with different behaviour IMO

ABX

Post a reply to this message

Vadim Sytnikov wrote:
> I'm sure that one day we will see functions as complex as shaders in
> RenderMan. By the way, I do not think that there exist any fundamental
> difficulty for that -- I know that many have branded that not feasible on
> portability grounds. But -- that only applies to the solution that was
> implemented in POVMan (based on POV-Ray 2.2, IIRC), which employed bytecode
> compiler built with Flex/Bison. If you look at how it was done in BMRT, you
> will find quite different solution, less powerful, but more portable (SL
> files are not even compiled, they are, err... preprocessed :-)
> 
POVMan's SL compiler output should be quite portable: bytecode is 
written as text byte-by-byte and there shouldn't be problems with endian 
  or word length.
To me BMRT's SL compiler output reminds more assembly language, than 
preprocessed statements. And POVMan's SLC is capable of similar output, 
only problem is that POVMan itself can't read this output (for this 'SL 
assembly' parsing should be implemented, but bytecode reading is much 
more easier).
One problem with using SL from POV is its complexity: one should deal 
with multiple files, compile them, learn new language etc. Additionally 
there could be legal considerations as well.

Post a reply to this message