 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Any one think they (logical operators &,|) shoud be short-circuit logic
operators (like &&, || in C/++) so that the following would be possible
#if( defined(somevar) & somevar)
<some stuff>
#end
currently this is done like so
#ifdef(somevar)
#if(somevar)
<some stuff>
#end
#end
--
Bye
Pabs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A149BF8.C688E185@hotmail.com>, Pabs <pab### [at] hotmail com>
wrote:
> Any one think they (logical operators &,|) shoud be short-circuit logic
> operators (like &&, || in C/++) so that the following would be possible
POV already has & and | operators that behave as boolean logic
operators. What exactly do you want? Bit-level operators?
A "defined()" function would be useful though...I don't think it can be
done as a macro.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> In article <3A149BF8.C688E185@hotmail.com>, Pabs <pab### [at] hotmailcom>
> wrote:
>
> > Any one think they (logical operators &,|) shoud be short-circuit logic
> > operators (like &&, || in C/++) so that the following would be possible
>
> POV already has & and | operators that behave as boolean logic
> operators. What exactly do you want? Bit-level operators?
> A "defined()" function would be useful though...I don't think it can be
> done as a macro.
>
No, he wants the behavior the C compiler has when evaluating:
if ((divisor !=0)&&(amount/divisor ...
That is: if the divisor is 0, the division is not even performed
because the left part of the '&&' is false.
Sincerely, I'm against this idea for POV.
(it's ok in C).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jérôme Grimbert <jgr### [at] atos-groupcom> wrote:
> No, he wants the behavior the C compiler has when evaluating:
> if ((divisor !=0)&&(amount/divisor ...
> That is: if the divisor is 0, the division is not even performed
> because the left part of the '&&' is false.
> Sincerely, I'm against this idea for POV.
> (it's ok in C).
Oh, why? Why should POV do extra work when the result is going to be false
already? The reason it's done in C is to avoid that extra work. Why would
this be a bad thing? The only case I can think of is if there are side
effects to the second half of the equation (it calls a macro that creates an
object and returns a value), but that's so rarely necessary, plus needlessly
confusing (try figuring out code that has such side effects six months later
or which you didn't write) that it's not something that we really need.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Geoff Wedig wrote:
>
> Jérôme Grimbert <jgr### [at] atos-groupcom> wrote:
>
> > No, he wants the behavior the C compiler has when evaluating:
>
> > if ((divisor !=0)&&(amount/divisor ...
>
> > That is: if the divisor is 0, the division is not even performed
> > because the left part of the '&&' is false.
>
> > Sincerely, I'm against this idea for POV.
> > (it's ok in C).
>
> Oh, why? Why should POV do extra work when the result is going to be false
> already? The reason it's done in C is to avoid that extra work. Why would
> this be a bad thing? The only case I can think of is if there are side
> effects to the second half of the equation (it calls a macro that creates an
> object and returns a value), but that's so rarely necessary, plus needlessly
> confusing (try figuring out code that has such side effects six months later
> or which you didn't write) that it's not something that we really need.
You said it: it would open the door to needlessly confusing code.
The right way to write it is the current way:
#if (divisor <> 0.0)
#if (amount/divisor ...
There is no need to add confusion for the writer/reader of pov-script
with 'smart' browsing/evaluation of conditional expression.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jérôme Grimbert <jgr### [at] atos-groupcom> wrote:
> Geoff Wedig wrote:
>>
>> J?r?me Grimbert <jgr### [at] atos-groupcom> wrote:
>>
>> > No, he wants the behavior the C compiler has when evaluating:
>>
>> > if ((divisor !=0)&&(amount/divisor ...
>>
>> > That is: if the divisor is 0, the division is not even performed
>> > because the left part of the '&&' is false.
>>
>> > Sincerely, I'm against this idea for POV.
>> > (it's ok in C).
>>
>> Oh, why? Why should POV do extra work when the result is going to be false
>> already? The reason it's done in C is to avoid that extra work. Why would
>> this be a bad thing? The only case I can think of is if there are side
>> effects to the second half of the equation (it calls a macro that creates an
>> object and returns a value), but that's so rarely necessary, plus needlessly
>> confusing (try figuring out code that has such side effects six months later
>> or which you didn't write) that it's not something that we really need.
> You said it: it would open the door to needlessly confusing code.
No, my *counterexample* (ie, the only reason you want anything else) is
needlessly confusing, because of side effects. Having a pair of boolean
expressions that terminates if the first expression determines the whole
sequence is quite sensible.
I don't see why using two ifs is any clearer, it's just verbose, which is
its own kind of obtusification.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jérôme Grimbert <jgr### [at] atos-groupcom> wrote:
: You said it: it would open the door to needlessly confusing code.
Why it would be confusing code?
If I write: #if(a>0 & b>0)
does it matter whether the part "b>0" is evaluated or not as long as the
result is correct?
Actually, doing it C-like can produce faster parsing:
#if(a>0 & extremely_long_calculation(a)) ...
If a<=0 then the extremely_long_calculation() macro is not called, saving
potentially a lot of time.
Of course you can do it in the long way:
#if(a>0)
#if(extremely_long_calculation(a))
...
#end
#end
but why should you do it yourself when the povray parser can do it
automatically for you?
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
"The derivative of sin(2x) is cos(2x)" - Matt Giwer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 17 Nov 2000 10:01:13 -0500, Warp wrote...
> : You said it: it would open the door to needlessly confusing code.
>
> Why it would be confusing code?
Because not everybody on these groups, or indeed everybody who uses POV,
is experienced in, or capable of reading C style code.
I have enough trouble reading POV code as it is, and adding (more)
abstract symbols to the scene description language would kill my ability
to understand roughly what is happening in a scene file.
Sorry if I'm ranting, but I get a little fed up of seeing people trying
to turn POV into a programming language, when, in my opinion, it isn't
and shouldn't be.
Bye for now,
Jamie.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a154839@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Actually, doing it C-like can produce faster parsing:
>
> #if(a>0 & extremely_long_calculation(a)) ...
>
> If a<=0 then the extremely_long_calculation() macro is not called,
> saving potentially a lot of time.
If that extremely_long_calculation sets up some variables for later use,
not evaluating it could lead to obscure bugs in scene files. Having side
effects like this may be bad style, but having them be ignored sometimes
would lead to problems that are very difficult to track down when they
are done.
In other words, it is a minor optimization that can be done within the
scene language and produces the possibility for bugs that are extremely
difficult to track down(or code that is very vague because it relies on
this optimization). Not worth adding in my opinion.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Jérôme Grimbert <jgr### [at] atos-groupcom> wrote:
> : You said it: it would open the door to needlessly confusing code.
>
> Why it would be confusing code?
>
> If I write: #if(a>0 & b>0)
> does it matter whether the part "b>0" is evaluated or not as long as the
> result is correct?
Yes, and besides, this is much clearer to me than
#if(a>0)
#if(b>0)
It's especially more clear when limiting to a set:
#if(a>0 & a<10)
because you don't need to read ahead or look at indentation to see that you're
limiting a to an interval (0,10) (or is that [0,10]?). Same goes for a
non-contigous set:
#if((a>0 & a<10) | a>20 | a=15)
Imagine that coded as individual tests!
--
David Fontaine <dav### [at] faricynet> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jamie Davison wrote:
>
> Because not everybody on these groups, or indeed everybody who uses POV,
> is experienced in, or capable of reading C style code.
>
> I have enough trouble reading POV code as it is, and adding (more)
> abstract symbols to the scene description language would kill my ability
> to understand roughly what is happening in a scene file.
>
The proposed change would add nothing to the scene language; it would change the
way an existing operator is parsed.
Frankly, the way it works now initially caused more confusion for me, since I
did not see the point in evaluating the second part of the conditional, if the
whole condidtional was already bound to return "false".
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> If that extremely_long_calculation sets up some variables for later use,
> not evaluating it could lead to obscure bugs in scene files.
Hmm. Are there many likely scenarios of this happening?
Granted, a macro invoked in a conditional could #declare variables needed later
in the code; but creating necessary variables like this is very bad form IMO, as
is (generally) using #declare in a macro to set up global variables.
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A15CA5E.DC4C415C@peak.edu.ee>, Margus Ramst
<mar### [at] peakeduee> wrote:
> Hmm. Are there many likely scenarios of this happening?
Not a lot, but I see no reason to add something that can cause such
confusion and would only have a slight benefit.
> Granted, a macro invoked in a conditional could #declare variables
> needed later in the code; but creating necessary variables like this
> is very bad form IMO, as is (generally) using #declare in a macro to
> set up global variables.
It might be bad form, but it is possible and is sometimes the easiest
way to do things. Remember that not all POV users are programmers who
care about good form...this would just be considered a nuisance by them.
And I think it is "bad form" for a language to do this type of thing,
because there is no indication of what is happening when it occurs. It
can be done manually, and can cause problems when done automatically.
Maybe if there was a warning when a macro call was skipped, or if it
only skipped things other than macro calls...
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jamie Davison <jam### [at] dh70qdu-netcom> wrote:
: Sorry if I'm ranting, but I get a little fed up of seeing people trying
: to turn POV into a programming language, when, in my opinion, it isn't
: and shouldn't be.
But the povray scripting language IS a programming language (since it's
Turing-strong).
Making it a better programming language can make only good.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] maccom> wrote:
: Not a lot, but I see no reason to add something that can cause such
: confusion and would only have a slight benefit.
I see many reasons to add something that has so many benefits although
it might rarely sometimes cause some confusion.
Things can always be said in two ways :)
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Chris Huff <chr### [at] maccom> wrote:
> : Not a lot, but I see no reason to add something that can cause such
> : confusion and would only have a slight benefit.
>
> I see many reasons to add something that has so many benefits although
> it might rarely sometimes cause some confusion.
>
> Things can always be said in two ways :)
Now I'm confused !
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20 Nov 2000 05:22:15 -0500, Warp wrote...
> : Sorry if I'm ranting, but I get a little fed up of seeing people trying
> : to turn POV into a programming language, when, in my opinion, it isn't
> : and shouldn't be.
>
> But the povray scripting language IS a programming language (since it's
> Turing-strong).
> Making it a better programming language can make only good.
By better, I assume you mean more like other, established general purpose
programming languages, e.g. C, C++?
Personally, that doesn'y fit my definition of 'better' But that's
probably just me.
Of course it's entirely possible that I'm misinterpreting something
somewhere along the lines.
Bye for now,
Jamie.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 17 Nov 2000 17:56:05 -0600, David Fontaine wrote:
>because you don't need to read ahead or look at indentation to see that you're
>limiting a to an interval (0,10) (or is that [0,10]?). Same goes for a
(0,10)
>non-contigous set:
> #if((a>0 & a<10) | a>20 | a=15)
>Imagine that coded as individual tests!
I think you might be missing the important point here: we currently have and
and or operators, but they don't short-circuit. The result is that you
can't say things like
#if ( a != 0 and 5/a > 2 )
because the parser will puke on 5/a if a really is zero.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a18fc06@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> I see many reasons to add something that has so many benefits although
> it might rarely sometimes cause some confusion.
What benefits? A small parsing speedup every once in a while, and more
rarely a fairly large speed improvement. And this can already be
accomplished by using a slightly different structure with the current
language, by nesting the conditionals.
Oh, and it lets you write nicely obfuscated code that doesn't do what it
appears to do, like this:
#if(ACondition & DoSomething()) #end
which would really be the same as this:
#if(ACondition)
DoSomething()
#end
So, no real benefits, since what it does can easily be done manually
already, and it adds possible confusion.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> #if ( a != 0 and 5/a > 2 )
>
> because the parser will puke on 5/a if a really is zero.
Hmm, didn't think of that scenario...
--
David Fontaine <dav### [at] faricynet> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jamie Davison <jam### [at] dh70qdu-netcom> wrote:
: By better, I assume you mean more like other, established general purpose
: programming languages, e.g. C, C++?
Nope. I mean more modular and more intuitive and easy-to-use but powerful
features. Also more complicated but even more powerful features could be
good (two completely different examples of this: Perl and Prolog).
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] maccom> wrote:
: What benefits? A small parsing speedup every once in a while, and more
: rarely a fairly large speed improvement. And this can already be
: accomplished by using a slightly different structure with the current
: language, by nesting the conditionals.
Why should the user optimize by hand when povray could do it automatically?
: Oh, and it lets you write nicely obfuscated code that doesn't do what it
: appears to do, like this:
: #if(ACondition & DoSomething()) #end
But you can already make pretty obfuscated code with povray. Just consider
something like this:
#local L=array[4800] #local Y=-2; #local I=0;
#while(#local X=-2;
#while(#local Zr=X; #local Zi=Y; #local N=0;
#while(#local A=Zr*Zr; #local B=Zi*Zi;
#local Zi=2*Zr*Zi+Y; #local Zr=A-B+X;
#local N=N+1; N<20&A+B<2) #end
#local L[I]=<X,N/40,Y>;
#local X=X+.05; #local I=I+1; X<=1) #end
#local Y=Y+.05; Y<=2) #end
union
{ #local I=0; #while(I<4800) sphere{L[I],.05} #local I=I+1; #end
pigment { rgb x } finish { specular .5 }
}
camera { location <-2,2,-2> look_at 0 }
light_source { <0,20,-10>, 1 }
Avoiding a feature only because you CAN make obfuscated code with it is
not a good principle.
If that had been the principle in povray, its scripting language would not
be as versatile as it is now (and things like macros would have been had to
be implemented in a completely different way as it is now).
If povray can optimize the speed of the parsing, that's only a good thing.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jamie Davison <jam### [at] dh70qdu-netcom> wrote:
> On 20 Nov 2000 05:22:15 -0500, Warp wrote...
>> : Sorry if I'm ranting, but I get a little fed up of seeing people trying
>> : to turn POV into a programming language, when, in my opinion, it isn't
>> : and shouldn't be.
>>
>> But the povray scripting language IS a programming language (since it's
>> Turing-strong).
>> Making it a better programming language can make only good.
> By better, I assume you mean more like other, established general purpose
> programming languages, e.g. C, C++?
> Personally, that doesn'y fit my definition of 'better' But that's
> probably just me.
> Of course it's entirely possible that I'm misinterpreting something
> somewhere along the lines.
Or he could mean better as in making the obvious logical steps that can save
time and energy for everyone. Or maybe making the parsing of the syntax
smarter and not doing stupid, unnecessary operations.
But that's probably me.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a1a3c21@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Why should the user optimize by hand when povray could do it
> automatically?
Because it can't be done automatically without breaking certain things
or leading to odd behavior that isn't intuitive from reading the code...
> Avoiding a feature only because you CAN make obfuscated code with it is
> not a good principle.
I did not say that. I meant that the fact that you can make obfuscated
code with it is not a good reason to add it. It was intended as a joke,
because you seem to like doing that kind of thing. :-)
> If povray can optimize the speed of the parsing, that's only a good
> thing.
Not if it complicates things unnecessarily. If a user puts a call to a
macro with a side effect in the code, he will expect the macro to be
called. Note: users are not always programmers or software designers,
don't expect them to always avoid something that is "bad style". They
just want things to do what they are told. The error caused when this
optimization is done to a macro with a side effect is one that would be
extremely difficult to track down unless you already know where to look
for it.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote in message <3a1a3c21@news.povray.org>...
>
>#local L=array[4800] #local Y=-2; #local I=0;
>#while(#local X=-2;
>#while(#local Zr=X; #local Zi=Y; #local N=0;
>#while(#local A=Zr*Zr; #local B=Zi*Zi;
>#local Zi=2*Zr*Zi+Y; #local Zr=A-B+X;
>#local N=N+1; N<20&A+B<2) #end
>#local L[I]=<X,N/40,Y>;
>#local X=X+.05; #local I=I+1; X<=1) #end
>#local Y=Y+.05; Y<=2) #end
>union
>{ #local I=0; #while(I<4800) sphere{L[I],.05} #local I=I+1; #end
> pigment { rgb x } finish { specular .5 }
>}
>camera { location <-2,2,-2> look_at 0 }
>light_source { <0,20,-10>, 1 }
Nice mandelbroit.
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Fontaine wrote:
> Ron Parker wrote:
> > #if ( a != 0 and 5/a > 2 )
> > because the parser will puke on 5/a if a really is zero.
> Hmm, didn't think of that scenario...
It is the same kind of thing as my original example.
--
Bye
Pabs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] maccom> wrote:
: Not if it complicates things unnecessarily. If a user puts a call to a
: macro with a side effect in the code, he will expect the macro to be
: called.
If the user is so advanced that he knows how to make macros with side
effects and how to use them in complicated places (such as inside an
#if conditional), he has probably already very familiar with the povray
code (and he has probably read the documentation about all the commands).
If the behaviour is clearly and well documented, it shouldn't cause
problems.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote in message <3a1bce46@news.povray.org>...
>
> If the user is so advanced that he knows how to make macros with side
>effects and how to use them in complicated places (such as inside an
>#if conditional), he has probably already very familiar with the povray
>code (and he has probably read the documentation about all the commands).
> If the behaviour is clearly and well documented, it shouldn't cause
>problems.
Are you offering to handle tech support for this new feature?
--
Mark
"The derivative of sin(2x) is cos(2x)" - Matt Giwer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner <mar### [at] gtenet> wrote:
: Are you offering to handle tech support for this new feature?
Does this mean that if someone suggests a new feature, he should also
offer tech support for that feature?
Does it mean that if the person who has the suggestion doesn't want to
do it, he should not make the suggestion?
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 23 Nov 2000 02:57:27 -0500, Mark Wagner wrote:
>Warp wrote in message <3a1bce46@news.povray.org>...
>>
>> If the user is so advanced that he knows how to make macros with side
>>effects and how to use them in complicated places (such as inside an
>>#if conditional), he has probably already very familiar with the povray
>>code (and he has probably read the documentation about all the commands).
>> If the behaviour is clearly and well documented, it shouldn't cause
>>problems.
>
>
>Are you offering to handle tech support for this new feature?
Isn't that why we hired him? :)
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
: Isn't that why we hired him? :)
Well, if you put it that way... :)
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"David Fontaine" <dav### [at] faricynet> wrote :
>
> Same goes for a
> non-contigous set:
> #if((a>0 & a<10) | a>20 | a=15)
> Imagine that coded as individual tests!
If it were, there is a chance that I -would- be able to imagine it. As
it is, those of us who do not have a mathematical mind need to break it down
in to steps to be able to understand it at all. When I see example code like
this it takes me hours to turn it into nested statements so that I can
absorb it in bite sized chunks.
If pov is just for programmers and mathematicians then I should just
give up now. I mean when guy like Warp...
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
...says something is "easier and more intutive", I know that I will get
lost right away. My skills are in other areas.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bill DeWitt <the### [at] earthlinknet> wrote:
: I mean when guy like Warp...
: ...says something is "easier and more intutive", I know that I will get
: lost right away. My skills are in other areas.
That was an insult.
For your information, I have studied computer science (software) for 5 years
in the Tampere University of Technology. I have been working in the Software
Systems Laboratory here for more than 2 years now, programming actively.
My intention is to make my doctoral thesis here.
I know what an easy and intuitive programming language is. I know what
good programming is. I have been preaching about modularity and high-quality
programming in this news-server so long that most people probably just hate
me for that.
So please don't underestimate my knowledge.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
