 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Matt Giwer" <jul### [at] ij net> wrote in message
news:38CC8966.A65A6022@ij.net...
> Nieminen Juha wrote:
> >
> > You are right.
> > However I think there are some places where the use of goto (at
least in
> > C and C++) is more or less reasonable:
>
> To rephrase Case 1
>
> > - Case 1:
>
> label1: for(cond1)
> label2 for(cond2)
> while(cond3)
> if(skip) goto end_loops elseif (cond1) goto label1
> then goto label2;
> end_loops:
>
> Real quick and I won't swear to it, that should be look for kbd
> 'L' and then 'ogin'
Brrrr. Is that an intentional or unintentional example of horrible
programming with the help of goto?
Johannes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Matt Giwer <jul### [at] ijnet> wrote:
: Everything in computing can be done with the minimalist set of
: micro-code which actually gets down to four or five instructions
: depending upon your side in the debate
Actually 2 instructions are enough.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner <mar### [at] gtenet> wrote:
: #do
: /* Do something */
: #if(1 = 2)
: #until(a = 3)
: #end
: or
: #do
: /* Do something */
: #if(1 = 1)
: #until(a = 3)
: #end
Both of those should issue an error.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart <nig### [at] nigelscom> wrote:
: An example of what code may look like?
: sphere {
: <0, 0, 0>, 1
: pigment { Blue }
: translate -0.5*x
: }
: Perhaps:
: <POVSCENE>
: <SPHERE>
: <POSITION> 0,0,0 </POSITION>
: <RADIUS> 1.0 </RADIUS>
: <PIGMENT>
: <COLOR> BLUE </COLOR>
: </PIGMENT>
: <TRANSLATE> -0.5*x </TRANSLATE>
: </SPHERE>
: </POVSCENE>
Looks horrible.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> Perhaps:
>
> <POVSCENE>
> <SPHERE>
> <POSITION> 0,0,0 </POSITION>
> <RADIUS> 1.0 </RADIUS>
> <PIGMENT>
> <COLOR> BLUE </COLOR>
> </PIGMENT>
> <TRANSLATE> -0.5*x </TRANSLATE>
> </SPHERE>
> </POVSCENE>
Please, NO!
--
Ken Tyler - 1300+ Povray, 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 <38CC8967.69CBD4F9@nigels.com>, nig### [at] eisanetau wrote:
> > In all seriousness, object oriented would work very well for POV-Ray,
> > since it
> > models... objects!
>
> Jon,
>
> You havn't raised XML in this thread - I think it is quite an
> appropriate opportunity to talk about it. People are used to
> the HTML idea generally, but HTML has evolved into a bit of a
> mess, so it may not be a great idea to suggest XML from this
> viewpoint... (sigh)
> ...
> sphere {
> <0, 0, 0>, 1
> pigment { Blue }
> translate -0.5*x
> }
>
> Perhaps:
>
> <POVSCENE>
> <SPHERE>
> <POSITION> 0,0,0 </POSITION>
> <RADIUS> 1.0 </RADIUS>
> <PIGMENT>
> <COLOR> BLUE </COLOR>
> </PIGMENT>
> <TRANSLATE> -0.5*x </TRANSLATE>
> </SPHERE>
> </POVSCENE>
Er, no offense, but that is extremely ugly syntax and just about
unreadable. Add in looping, conditionals, variables(with arrays), and
macros, and you have a real nightmare. It is going in the opposite
direction I would like to see POV go. I think if this replaced
POV-Script, people would go to other things instead, and if it was an
option along with POV-Script, very few people would use it(even
modellers would probably output in POV-Script for file size reasons).
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CC8493.A5135501@ij.net>, Matt Giwer <jul### [at] ijnet>
wrote:
> I mean implementation differences. On an i++ while you can get a
> debate started among purists as to while i < 5 should bail out or
> 4 or 5 in that should the < be checked before or after evaluating
> and changing the variables in the loop.
Implementation differences between POV and what? There is still only one
parser currently available.
And we are talking about for loops, not the ++ operator. The ++ operator
is well defined, no reason for debate over it, and most likely couldn't
be applied to POV syntax without completely redesigning the variable
syntax.
A #for(;;) loop is also well defined and quite possible with POV syntax.
> You can get another debate on permitting i to be both integer
> and float.
Huh...what? POV doesn't have integer types, everything is a floating
point number. And how would this be a debate?
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Xplo Eristotle wrote:
> Finally, it's my opinion that the POV language is *already* OO. I would
> love for anyone who disagrees to explain to me how
Ok, I agree that POV is already OO. I personnally prefer the current "braces"
syntax, but let's say that it's just because I was trained in procedural
programming and that "dot" syntaxes are better for POV (note : I agree that they
are in professional development environments).
Now, what a full pov scene would look like if it was coded like that ?
For example, could it be possible to have an ideal "dot" translation of something
like the following (extract of a scene I'm working on). Or of a large CSG
construct ? I'm just curious.
G.
#declare m=2;
#declare ry=1*m;
#declare a=degrees(m/ry);
#declare at=0;
#declare tr=80;
#declare Pave = object{ #include "pave.inc" translate y*0.5 scale m*0.5*1.6}
#declare Paves=array[8]
#declare Paves[0]=object{Pave}
#declare Paves[1]=object{Pave rotate y*90}
#declare Paves[2]=object{Pave rotate y*180}
#declare Paves[3]=object{Pave rotate y*270}
#declare Paves[4]=object{Pave scale <-1,1,1>}
#declare Paves[5]=object{Pave scale <-1,1,1> rotate y*90}
#declare Paves[6]=object{Pave scale <-1,1,1> rotate y*180}
#declare Paves[7]=object{Pave scale <-1,1,1> rotate y*270}
#declare rd=seed(0);
#declare finPave=finish{ambient 0 diffuse 0.6 specular 0.02 roughness 0.05}
#declare sc=0.1;
#declare colPave=colHouse1+<0,0.04,0.04>;
#declare Sol=union{
#while (at<360*tr)
#declare np=int(rand(rd)*8);
#declare vpos=vaxis_rotate(ry*x,y,at);
#declare vturb=vturbulence(3, 0.5, 6, vpos*0.008); // Thanks Chris Huff
!!!
#declare vturb2=vturbulence(3, 0.5, 6, vpos*0.08);
#declare coltmp=color colPave*(1+abs(vturb2.x));
object{Paves[np]
rotate (1-rand(rd))*20*y
scale <1,(1+vturb.y*2)*0.3,1>
translate <ry,(1+vturb.y*2)*0.3,0>
rotate y*at
texture{
pigment{granite color_map{[0 coltmp][0.4
coltmp][0.6 coltmp*0.8][1 coltmp*0.5]}}
finish{finPave}
scale 0.1
}
}
#declare ry=ry+ m*m/(pi*(2*ry+m));
#declare a=degrees(m/ry);
#declare at=at+a;
#end
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CCCE55.DBB148AD@inapg.inra.fr>, Gilles Tran
<tra### [at] inapginrafr> wrote:
> #declare vturb=vturbulence(3, 0.5, 6, vpos*0.008); // Thanks Chris Huff
Er, actually, I didn't write that function. I wrote the vtransform()
function. :-)
Can someone try a vwarp function? I attempted one, but didn't make much
progress.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I think if this replaced POV-Script, people would go to other things
> instead, and if it was an option along with POV-Script, very few
> people would use it(even modellers would probably output in
> POV-Script for file size reasons).
Hmmm...
A consistently negative reaction...
An idea before it's time?
Or a community behind the times?
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
