Hi folks!

I've seen this kind of syntax here and there:

    	scale x + z + y*0.03

I don't like it as it is not clear what it does without having to analyse
it for a moment 


From what I gathered and from normal operator precedence this is the same
as:
    	scale x*1 + z*1 + y*0.03
    	    	or
    	scale <1,0.03,1>

I figured the syntax not so clear syntax is to avoid the "cannot scale by
0 warning" when one uses this syntax: 

    	scale y*0.03

I'm not saying it's good or bad, I just don't like when I have to ponder
on such a simple statement in order to figure out what it's doing. 

Would it not be wise for the scale statement to assume 1 instead of 0 for
those vectors that are not specified. 

I may not realise what other impact this may have on the system as a
whole. 

Just thought I would mention it.

Thanks

-- 
Marc Champagne
marcch.AT.videotron.DOT.ca
Montreal, CANADA

Post a reply to this message

> Would it not be wise for the scale statement to assume 1 instead of 0 for
> those vectors that are not specified.

Not without giving a warning, as it does, IMO. Scaling by zero is illegal
and the program should not fail to let the user know that they've done
something wrong.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

"Marc Champagne" <marcch.AT.videotron.DOT.ca> wrote in message
news:Xns### [at] 204213191226...
>
> Would it not be wise for the scale statement to assume 1 instead of 0 for
> those vectors that are not specified.
>

A common request. I *think* the problem is that If the default for an
unspecified vector was changed to 1, this would have an impact on translate and
rotate vectors (where defaulting to 0 is desired).

In the end, you are only getting a warning, which you may ignore.

Post a reply to this message

Marc Champagne <marcch.AT.videotron.DOT.ca> wrote:
> Would it not be wise for the scale statement to assume 1 instead of 0 for
> those vectors that are not specified. 

  Certainly not. That would seriously break things like translate x*5
or box { 0,1 }

  It could be thinkable that the 'scale' command would be a special
case, where an element value of 0 is converted to 1. However, this is
what it already does. The only question is whether the warning is
relevant or not.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Tom Melly" <tom### [at] tomandlucouk> wrote in
news:3f603bce$1@news.povray.org: 

> "Marc Champagne" <marcch.AT.videotron.DOT.ca> wrote in message
> news:Xns### [at] 204213191226...
>>
>> Would it not be wise for the scale statement to assume 1 instead of 0
>> for those vectors that are not specified.
>>
> 
> A common request. I *think* the problem is that If the default for an
> unspecified vector was changed to 1, this would have an impact on
> translate and rotate vectors (where defaulting to 0 is desired).

Defaulting to 1 would only be for scale of course as it ends up being 1
in the end anyways... 
 
> In the end, you are only getting a warning, which you may ignore.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote in news:3f60674b@news.povray.org:

> Marc Champagne <marcch.AT.videotron.DOT.ca> wrote:
>> Would it not be wise for the scale statement to assume 1 instead of 0
>> for those vectors that are not specified. 
> 
>   Certainly not. That would seriously break things like translate x*5
> or box { 0,1 }

I don't mention translate or box do I!


>   It could be thinkable that the 'scale' command would be a special
> case, where an element value of 0 is converted to 1. However, this is
> what it already does. The only question is whether the warning is
> relevant or not.

Bingo

Post a reply to this message

Well, relying on default values for just
specific functions (in this case, defaulting
to 1 just for scale) is quiet unpleasing
IMHO. This way, I can always expect
that 2 = <2,2,2>, and x*2 is <2,0,0>.

If you begin with scale to do
x*2 = <2,1,1>, then where do you want
to stop for "special default cases"?

Its just a useful warning after all! There
are simple rules for floats and vectors
and they simply apply everywhere, which
makes them easy to handle and interpret,
even in obfuscated code.

So, IMHO, let the warning be.

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: no_lights (@) digitaltwilight.de


>
> > Marc Champagne <marcch.AT.videotron.DOT.ca> wrote:
> >> Would it not be wise for the scale statement to assume 1 instead of 0
> >> for those vectors that are not specified.
> >
> >   Certainly not. That would seriously break things like translate x*5
> > or box { 0,1 }
>
> I don't mention translate or box do I!
>
>
> >   It could be thinkable that the 'scale' command would be a special
> > case, where an element value of 0 is converted to 1. However, this is
> > what it already does. The only question is whether the warning is
> > relevant or not.
>
> Bingo
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 01.09.2003

Post a reply to this message

Marc Champagne wrote:
> Would it not be wise for the scale statement
> to assume 1 instead of 0 for those vectors
> that are not specified.

The following may sound like nitpicking, but I think it's worth
mentioning.

When you scale by x*2 then you are not just specifying the x-scaling,
you are also specifying the y-scaling and z-scaling. These you have set
to 0.

This is not because 0 is any kind of default. It is simply because the
meaning of the build-in variable "x" is exactly <1,0,0>. That is, "x" is
a full vector in itself, not some kind of float that only applies to the
x value. So when you are specifying scale x*2 then it is exactly the
same as specifying scale <1,0,0>*2 and this is a full vector definition,
without any defaults being assumed.

I still think it's a good idea that POV-Ray corrects the incorrect
scaling specifications, but the warning definitely should be there.

My main point I guess, is to make clear that no default are being
assumed, since there are no vectors that are "not being specified", and
thus it doesn't make sense to request that the defaults should be
different.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Jul 25**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

"Rune" <run### [at] runevisioncom> wrote in news:3f60a3af@news.povray.org:

> Marc Champagne wrote:
>> Would it not be wise for the scale statement
>> to assume 1 instead of 0 for those vectors
>> that are not specified.
> 
> The following may sound like nitpicking, but I think it's worth
> mentioning.
> 
> When you scale by x*2 then you are not just specifying the x-scaling,
> you are also specifying the y-scaling and z-scaling. These you have set
> to 0.
> 
> This is not because 0 is any kind of default. It is simply because the
> meaning of the build-in variable "x" is exactly <1,0,0>. That is, "x" is
> a full vector in itself, not some kind of float that only applies to the
> x value. So when you are specifying scale x*2 then it is exactly the
> same as specifying scale <1,0,0>*2 and this is a full vector definition,
> without any defaults being assumed.
> 
> I still think it's a good idea that POV-Ray corrects the incorrect
> scaling specifications, but the warning definitely should be there.
> 
> My main point I guess, is to make clear that no default are being
> assumed, since there are no vectors that are "not being specified", and
> thus it doesn't make sense to request that the defaults should be
> different.

Well your nitpicking :) makes a whole lot of sense, I better understand
now! 

What frustrates me the most are sequences that are not so obvious without
mentaly breaking it down, such as 
    	
    	scale x * 2 + y + 15 * z

I still believe for this case that

    	scale (x * 2) + (y * 1) + (15 * z)

or even better

    	scale <2,1,15>

would be faster to digest by humans (more readable)


Thanks

-- 
Marc Champagne
marcch.AT.videotron.DOT.ca
Montreal, CANADA

Post a reply to this message

Program ended abnormally on 11/09/2003 18:02, Due to a catastrophic Marc
Champagne error:

> 
> What frustrates me the most are sequences that are not so obvious without
> mentaly breaking it down, such as 
>     	
>     	scale x * 2 + y + 15 * z
> 
> I still believe for this case that
> 
>     	scale (x * 2) + (y * 1) + (15 * z)
> 
> or even better
> 
>     	scale <2,1,15>
> 
> would be faster to digest by humans (more readable)
> 

Absolutely.  I do not think there are lots of people who will write:

      scale x*2 + y + 15*z

as it does nothing more that waste characters and slow down the parser for a few 
cycles.  Statements like this will only show up (in my pov scenes, at least) in 
the development phase when I'm usually not thinking straight, or inside my .sig.

I have had to use complex statements to generate scale, translate or rotate 
vectors, but I usually try to make it easier to read and understand 6 months 
down the road.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   videotron.ca  */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message