Hello,

PoD wrote:
> 
> Axel Baune wrote:
> >
> >[Snip]
> >Another problem will be the
> > 'dirty' programming for people without programming-knowledge. The
> > example given by PoD is one of them:
> 
> dirty programming?

Sorry, I didn't wanted to say that the given example incorporates dirty
programming. What I've meant to say was, that from the given example
could dirty programming easily derived (see my desciption of problems
and the following)   

> > No I think not that this would make life easier for all. Problem one:
> > what will be the value of the variables outside the for-loop?
> 
> The same as it would be using a while loop?

No, I don't think so. In most programming languages the state of the
variables used in a for-loop are undefined outside the loop, but most
programmers ignores this and use the mostly undocomented feature, that
after the for-loop the variable has the value of the variable in the
last loop incremented by the specified step. Whereas after a while loop
the variable has the value obtained by the last user operation on the
variable. The problem derives, because in a for loop the variable
belongs sytactically to the for command. From the viewpoint of a
computer scientist  (I'm one) the variable in a for-loop should _never_
be changeable by a user and should have only one variable, but most
compiler of programming languages ignores this, beause it is to
complicated to prove this. Threrfore while-constructs show a more well
defined behaviour and should always be used.

> >Problem
> > two: What if you want to increment the variable in non deterministic
> > steps, e.g. different steps width in each loop or you didn't want to
> > increment in each loop. Than you will need the old while-construct, and
> > why blowing up Pov-Script with higly specialised commands if you already
> > have flexibler and more general commends for them? As a more skilled
> > programmer you can always write macros for specialised problems. 

> Then use a while loop and nothing is lost, except that you've made your
> script hard to read.  There's probably an easier way to do it using
> for()

No, you couldn't do everything with a for-loop what you could do with a
while-loop. The while-loop is far more flexible, beacuse the for-loop is
a special case of the while-loop for cases where _one_ variable is
looped through a range of values with a constant step width. 

> >Problem
> > three: What if somebody changes the variable explicitly inside the
> > loop-body. I think these problems complicates the life of PoV-people
> > without programming-knowledge, especially if some of these persons want
> > to understand code from other people with more skilled
> > programming-knowledge (especially if those people used 'dirty' and
> > mostly undocumented programming constructs).
> 
> See answer to 2

See answer to 1

Yours Axel Baune

Post a reply to this message

Hello,

Johannes Hubert wrote:
> 
> "PoD" <pod### [at] merlinnetau> wrote in message
> news:38C7EEA3.D0EE7FF1@merlin.net.au...
> > Axel Baune wrote:
> 
> > >Problem
> > > two: What if you want to increment the variable in non deterministic
> > > steps, e.g. different steps width in each loop or you didn't want to
> > > increment in each loop. Than you will need the old while-construct,
> and
> > > why blowing up Pov-Script with higly specialised commands if you
> already
> > > have flexibler and more general commends for them? As a more skilled
> > > programmer you can always write macros for specialised problems.
> >
> > Then use a while loop and nothing is lost, except that you've made
> your
> > script hard to read.  There's probably an easier way to do it using
> > for()
> 
> For example:
> 
> for (I = 1; I <= something; ) {
>     // loop body here
>     I += non_deterministic_increment;
> }
> 
> Johannes

This a an example of dirty programming!

From the viewpoint of a computer scientist (I'm one) this is a not a
syntactically correct defiend for-loop. The variable of a for-loop
belongs to the for-command and should be never _changable_ by the user. 

Sorry for flaming, but this are the programming styles, which make
software packages difficult to maintain, debug, readable and
understandable by other programmers.

Yours Axel Baune

Post a reply to this message

Ken wrote:
> 
> Johannes Hubert wrote:
> >
Hello,

> > "ingo" <ing### [at] homenl> wrote in message
> > news:8EF2B8E07seed7@204.213.191.228...
> > > Nieminen Juha wrote:
> > >
> > > >#declare A += B;
> > > >#declare A -= B;
> > >
> > > What does it mean?
> >
> > the same as
> >
> > #declare A = A + B;
> > #declare A = A - B;
> 
> So the way I see it by adding this you would save yourself the effort
> of typing one character. The question the potential patch writer must
> ask himself then is if it be worth the effort to patch the program to
> accept this new style of arguement just to save the user from having
> to type one more character into their scene file. Reduced to this it
> would seem a petty feature.
> 
> --
> Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
> http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

I agree.

The variant

> > #declare A = A + B;
> > #declare A = A - B;

is far more readable than the other. Besides this it would comlicate the
parser of PoV if the other variant should be maintained. This will lead
to a new type of possible parser bugs.  

Yours Axel Baune

Post a reply to this message

Hello,

For a good programming style you should declare your 'big complicated
expression' beforehand, like:

#declare big_complicated_expression = <some complicated expressions>;
#declare [big_complicated_expression] = [big_complicated_expression]+3;

because an array desciptors with complicated expressions are very
unreadable.

Yuors Axel Baune

Post a reply to this message

In article <38c8834b@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> Either way, WASTE was not designed as an editor. It does a good job, 
> but adding such features as auto-completion is either done by a lot 
> of working around it or by some inside modifications and hooks.  It 
> is possible with reasonable work, but not a free feature :-(

Ah, thanks for clarifying that.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38C816BE.35E35A1C@hotmail.com>, Tor Olav Kristensen 
<tor### [at] hotmailcom> wrote:

> But what if the loop control variable is a vector that is shared
> between several nested loops? (See my example macro below.)
> 
> Would this be possible with nested for-loops?

It would be possible, but not necessarily the best way to do it. 
Something like this:


#macro ObjectSplit(Thing, Point1, Point2, nnv)
// Cuts an object into several "box"-parts
// Result is returned in an array of such parts

  //#local nnv = <nx, ny, nz>;
  #local ThingArray = array[nnv.x][nnv.y][nnv.z]
  #local dPoint = (Point2 - Point1)/nnv;

  #for(Cntv = <0,0,0>; Cntv.z < nnv.z; Cntv.z += 1)
    #for(Cntv.y = 0; Cntv.y < nnv.y; Cntv.y += 1)
      #for(Cntv.x = 0; Cntv.x < nnv.x; Cntv.x += 1)
        #local ThingArray[Cntv.x][Cntv.y][Cntv.z] =
          intersection {
            object { Thing }
            box { Point1 + dPoint*Cntv, Point1 + dPoint*(Cntv+Unitv) }
          }
      #end // for
    #end // for
  #end // for

  ThingArray

#end // macro ObjectSplit

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Axel Baune <aba### [at] neuroinformatikuni-ulmde> wrote:
: The variant

:> > #declare A = A + B;
:> > #declare A = A - B;

: is far more readable than the other.

  In this case yes. But what about a longer identifier, like something
already suggested:

#declare ColorArray[ColorIndex][ColorSubIndex].red =
  ColorArray[ColorIndex][ColorSubIndex].red + 1;

or:

#declare ColorArray[ColorIndex][ColorSubIndex].red += 1;

  Note also that if one of the indices is a complex mathematical operation,
it would have to be calculated twice, instead of just once.
  Also if you have to modify the line, you would have to do it in two places
in the line instead of just one place.
  And you don't have to use the feature if you don't want to. The existance
of a feature doesn't make it mandatory to use it. I don't make a quartic
to get a torus although this possibility exists and is an inherent feature
in povray.

: Besides this it would comlicate the
: parser of PoV if the other variant should be maintained.

  Was this only a guess or do you really know that it will be conclusively
more complicated?

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

Post a reply to this message

On 10 Mar 2000 07:58:40 -0500, Nieminen Juha wrote:
>Axel Baune <aba### [at] neuroinformatikuni-ulmde> wrote:
>: Besides this it would comlicate the
>: parser of PoV if the other variant should be maintained.
>
>  Was this only a guess or do you really know that it will be conclusively
>more complicated?

It had to have been a guess.  It wouldn't be that complicated to do.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Hello,

Ron Parker wrote:
> 
> On 10 Mar 2000 07:58:40 -0500, Nieminen Juha wrote:
> >Axel Baune <aba### [at] neuroinformatikuni-ulmde> wrote:
> >: Besides this it would comlicate the
> >: parser of PoV if the other variant should be maintained.
> >
> >  Was this only a guess or do you really know that it will be conclusively
> >more complicated?
> 
> It had to have been a guess.  It wouldn't be that complicated to do.

As I've never looked into the Code for the PoV-Parser I' did"t know
exactly, but I've already written a parser of my own for my programms,
and therefore I know what effects it would have on my own parser if I
wish to include the new syntax. From this knowledge I've extrapolated to
the PoV-Parser.

Yours Axel Baune

Post a reply to this message

Ken wrote:

> Would you have difficulty re-learning POV-Ray if it's language format
> changed ?
> Would you resent it or maybe even quit using the program completely ?

I believe that the first purpose of POV is to allow a large number
of people from very different educational backgrounds to make excellent
pictures for free. I'm also aware that an important part of the POV
community does not see POV as a mean to obtain pictures (i.e.
they don't see the resulting picture as a primary goal), but as a mean to
derive pleasure from the intellectual game of programming the pictures. In
fact, a good number of people enjoy programming POV itself rather
than doing images  : think for instance that some patches were
never documented until recently, as if the sole purpose of
the patch was its programming and not having other people using it.
Of course, the fact that some people are primarily interested in
programming POV is very fortunate otherwise there would be
no POV at all !

However, I'd like to point out that whatever faults programmers
can find in the current scene description language, it is also
because it is "faulty" that non-programmers can learn it,
enjoy it, and make pov popular. So there's a potential conflict
here, since programmers may differ from non programmers about
what a "good" feature is, and what "faulty" means.

One interesting comparison can be made with BMRT : BMRT is free,
it uses an industry standard (RIB), it is (supposedly) immensely
powerful and its output,as far as I know, is very good.
But you won't find many BMRT pictures around (just look at the
IRTC) and the ones I've seen so far are of the "impressive feature
demonstration" kind. I guess that's because BRMT's
quality is obtained at the expense of it being programmer-oriented.

Now everyone can download POV, and run immediately a demo
scene which is written in something understandable for the non-programmer
type (in the Windows version this is automatic).
In a couple of seconds, you can change something in the code
without looking at the manuel and lo, here's your first scene.
It's not 100% intuitive, but it's not difficult either.
That's how I got started, and I supposed lots of people got
hooked like that. I'd like to keep this "philosophy" alive with POV,
because this is what makes it unique.

Of course I don't want to be conservative : POV can (should) evolve.
But my personal wish list is made of features that would make the
user's life easier in terms of creation (like a really

support of some popular mesh formats, or a simple way to make
patina and cracks, or built-in "fur" and "tree" engines etc.).
I have to recognize that some programming features (like arrays
or macros) that seemed complex at the beginning (yes, for a
non-programmer, even arrays are complex !) proved themselves
very useful. My current concern, which I seem to share with
Ken Tyler, is that many of features I've seen on programmers'
"wish lists" looked like they would surely improve the lives
of programmers and possibly make pov faster, or more flexible,
but that they would also make a few non-programmers cringe.
For instance, some people may have fun browsing a 500-page
long manual on OO programming, some others don't.

Would there be better pictures ? In many cases, theoretically yes.
But the people who advocate these changes should think about
the potential risk of reducing POV's user basis, since
the probability of having talented users using the new
advanced features, or using POV at all, would also be reduced,
what I'd call the "BMRT syndroma". In some cases, I'm under
the impression that the proposed changes are for the
sake of "proper" programming only, or for POV becoming closer
to the C language, with no real concern about the way
non-programmers actually use POV. I'm not sure that
maintaining several forms of the language (the regular and the new
one) would be very practical, both for users and POV developpers
(is backward compatibility really fun to maintain ?). Having
several ways to express the same idea/object/whatever would
make things very confusing for many users (and a larger manual
harder to read and maintain).

To answer Ken's questions, I surely would experience trouble if
the language changed completely. I've got my own legacy of scenes
(which already hard to maintain due to version changes and
immoderate patch use), and I'm able to work fast because I
know my way in POV (provided the help file is open !).
So having a new language format would be like using a
new software : I would take the trouble to learn it only if
it was clearly "competitive", in terms of user-friendliness
and features, over the current POV implementation.

Gilles Tran

Post a reply to this message