"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

In article <3c9071ba@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
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...

Which is a good thing because this change is an "illegal optimization", or
less friendly formulated a serious flaw in the compiler - at no point may a
compiler alter the result of a computation.  If it does alter the result of a
computation it has to be considered a bug.  Looks like whoever implemented
this didn't read the various articles and book chapters about floating-point
optimizations that are incorrect... :-(

    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

> > #local Rotate = transform { rotate ... }
> > object { ... Rotate }
>
> I don't understand your answer at all.

Sorry, I was probably unclear -- in that I have omitten several steps that
seemed obvious to me... I'll try once again. Here is your code with my
marks:

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

If 'if' statement were a real statement, and not merely a pre-processor
directive, then you would be unable to place parentheses like that (marks
(A) and (B)). Such placement is always considered dangerous -- you are
subdividing statement into pieces, AND pre-processor is unable to help you
to find any bugs, since it has no notion of what is between its
directives... Even if you have exceptional abilities and can maintain such a
code, other readers of your code may easily get confused with such grouping
(well, not with *that* example, but with a bit more complex...) That is why
such (once again, not this, but a more complicated code written in the same
manner) is often called a "write-only" code.

You are not to blame for that -- since 'if', 'switch' etc. keywords are
pre-processor directives rather than true language statements (that obey
some syntax rules), you are almost encoraged to write like that.

Now the part that confused you... In a well-designed language, you may
almost always gain good performance, but -- without hacks. I tried to draw
an example... To me, it was obvious that what you tried to do (with if-end
block containing marks (A) and (B)) was to supply a single transform to
variable shape definition -- so I just tried to illustrate that, if you were
dealing with an interpreter, and not mere pre-processor, you would be
*forced* to define transformation and then re-use that in several object
definitions. The interpreter would *not* allow you break pairs of
parentheses like that. And guess what? I think that that would be right!

Post a reply to this message

> at no point may a
> compiler alter the result of a computation.  If it does alter the result
of a
> computation it has to be considered a bug.

For the Intel compiler, that would only be true if intermediate result (of
the division of 1 by common divisor) would be stored in a 64-bit (double)
temporary variable. If it is kept in an fp register (80 bits), or in a 'long
double' temporary variable, then accuracy of the result would still be
*above* required by IEEE 754. Unfortunately, I can't remember whether that
(maintaining 80-bit accuracy across computations) was the case, but I
believe so...

Post a reply to this message