POV-Ray : Newsgroups : povray.programming : language design (was Re: hash marks) Server Time
28 Jul 2024 16:24:31 EDT (-0400)
  language design (was Re: hash marks) (Message 21 to 30 of 33)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 3 Messages >>>
From: Thorsten Froehlich
Subject: Re: language design (was Re: hash marks)
Date: 14 Mar 2002 12:37:05
Message: <3c90dfc1@news.povray.org>
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

From: Vadim Sytnikov
Subject: Re: language design (was Re: hash marks)
Date: 14 Mar 2002 14:49:02
Message: <3c90feae@news.povray.org>
> > #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

From: Vadim Sytnikov
Subject: Re: language design (was Re: hash marks)
Date: 15 Mar 2002 04:06:56
Message: <3c91b9b0$1@news.povray.org>
> 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

From: Thorsten Froehlich
Subject: Re: language design (was Re: hash marks)
Date: 15 Mar 2002 04:53:39
Message: <3c91c4a3@news.povray.org>
"Vadim Sytnikov" <syt### [at] rucom> schrieb im Newsbeitrag
news:3c90feae@news.povray.org...
> > > #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.

I am sorry, but I am unable to follow you.  Given the example he gave is not
pre-processes but would be allowed by the language, where exactly would be
the problem?  The example is fictional and thus there cannot be the problem
you describe, at least assuming I understood what problem you are talking
about...

    Thorsten


Post a reply to this message

From:
Subject: Re: language design (was Re: hash marks)
Date: 15 Mar 2002 05:07:56
Message: <hfh39ukd7a4pernugq2trhcssrjv16hp3g@4ax.com>
On Fri, 15 Mar 2002 10:55:25 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> The example is fictional

That's it. I've connected keyword and features of "if" with "select"
application as he suggested (or at least as I understand his suggestions). And
it clearly showed how it can confuse. Loosing features of current "if"
(spliitting closed statements) could be of course possible but completly
useless imo. Directives _with features_ state power of L in SDL whatever
syntax they have.

And btw Thorsten, thanks for "select" extraction. It helped me a lot in my
current #switch work :-)

ABX


Post a reply to this message

From: Vadim Sytnikov
Subject: Re: language design (was Re: hash marks)
Date: 15 Mar 2002 10:12:47
Message: <3c920f6f$1@news.povray.org>
> Given the example he gave is not
> pre-processes but would be allowed by the language, where exactly would be
> the problem?

The example that ABX gave us would *not* work in a language that has normal
scope rules (which even BASIC and Fortran have these days -- to some
extent). Below, left (opening) parenthesis opens scope for the 'sphere'
statement. If the 'if' and 'else' keywords were true language statements,
and not merely pre-processor directives, then it would be necessary to have
a right (closing) parenthesis before the 'else' statement.

>   if(z>0)
>      sphere{0 1
>                ^-------- (A)
>   else

That is, if we had a consistent language, the example should have looked
like this (extra parentheses added to just make scopes more clear; I do not
insist language syntax should necessarily require that):

if( z>0) {
  sphere {
    // sphere definition goes here
  }
} else {
  // another shape definition
}

In other words, the 'sphere' scope should have been closed before the 'else'
keyword. Therefore, transform definition should have been specified before
the 'else' keyword as well. Therefore, the only way to avoid duplicating
transform definition would be to declare it beforehand, and then reference
from within sphere definition, etc. (as I wrote earlier).


Post a reply to this message

From: Jérôme Grimbert
Subject: Re: language design (was Re: hash marks)
Date: 15 Mar 2002 10:32:19
Message: <3C921403.2821705A@atosorigin.com>
Vadim Sytnikov wrote:

>   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 you want something different from:

union {
 intersection {
   sphere { 0,1 }
   plane { -z,0}
   }
 intersection {
  box {-1,1}
  plane { z,0}
 }
 rotate ....
}

then you are doomed to work with mesh or rewrite the whole pov-engine.
Especially if you absolutlely want the non-linear transform from the second if.
Then you could make your own SDL, without preprocessor visible level if you wish.

-- 
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,






Post a reply to this message

From:
Subject: Re: language design (was Re: hash marks)
Date: 15 Mar 2002 11:19:21
Message: <9g649uo3vk0dmqnklkvl6fsa1ed1kd3qrd@4ax.com>
On Fri, 15 Mar 2002 18:12:46 +0300, "Vadim Sytnikov" <syt### [at] rucom> wrote:
> The example that ABX gave us would *not* work in a language that has normal
> scope rules (which even BASIC and Fortran have these days -- to some
> extent).

But POV-SDL isn't normal language. It's mix of language and description so it
don't have to have "normal" _language_ scope rules. Again going back to
HTML/script example. Did you use php ? You can open HTML tag inside php
condition statement and close it outside. Something like:
    <?php if (a>3) { ?>
      <p align="left" style="color:#123456">
    <?php } else { ?>
      <p align="right">
    <?php } ?>
      important text
    </p>
is valid and php works like preprocesor for webserver. There are probably some
leyers in processing but they are invisible for both: surfer and designer. The
same is valid for other server-side scripts. So POV-SDL works typically for
such combinations - just  all-in-one.

ABX


Post a reply to this message

From:
Subject: Re: language design (was Re: hash marks)
Date: 15 Mar 2002 11:36:07
Message: <ol849u8lrhhf1ua7hvdk04phba2ku8dq12@4ax.com>
On Thu, 14 Mar 2002 22:50:01 +0300, "Vadim Sytnikov" <syt### [at] rucom> wrote:
> The interpreter would *not* allow you break pairs of
> parentheses like that. And guess what? I think that that would be right!

BTW: I think You will not convince me but I can't say You are or are not right
at all. Mainly becouse my opinion is subjective - I like power which appear in
ability to write short scripts like for example sigs :-)

ABX


Post a reply to this message

From: Vadim Sytnikov
Subject: Re: language design (was Re: hash marks)
Date: 15 Mar 2002 11:39:05
Message: <3c9223a9@news.povray.org>

> But POV-SDL isn't normal language. It's mix of language and description so
it
> don't have to have "normal" _language_ scope rules.

You have to have well-defined scope rules to just cope with the complexity.
To make your scenes editable by someone else -- that is, to share code
(models etc.) Have you been using someone else's POV-Ray model recently?
Were you able to edit it?

> Did you use php ? You can open HTML tag inside php
> condition statement and close it outside.

Have you been editing someone else's php code recently? Were that easy?

I'm not talking about what is possible (has precedents etc.) and what isn't.
I'm talking about what's better (== easier, more reliable).


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 3 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.