I ran into this when writing the particle system patch. The vector V1 is 
modified by the function, which normalizes it for internal use. The 
function starts off like this:


void Compute_Axis_Rotation_Transform (TRANSFORM *transform, VECTOR V1, 
DBL angle)
{
  DBL l, cosx, sinx;

  VLength(l, V1);
  VInverseScaleEq(V1, l);
...


I deleted the VLength and VInverseScaleEq, and rewrote it like this:

void Compute_Axis_Rotation_Transform (TRANSFORM *transform, VECTOR 
AxisVect, DBL angle)
{
  DBL cosx, sinx;
  VECTOR V1;

  VNormalize(V1, Vect);
...

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

On Fri, 30 Jun 2000 17:39:40 -0500, Chris Huff wrote:
>I ran into this when writing the particle system patch. The vector V1 is 
>modified by the function, which normalizes it for internal use. The 
>function starts off like this:

Not so much a bug, but a bit roundabout.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <slr### [at] linuxparkerrfwicom>, 
ron### [at] povrayorg wrote:

> Not so much a bug, but a bit roundabout.

The use of VLength and VInverseScaleEq instead of VNormalize wasn't the 
bug I was talking about...the vector passed to the function is being 
normalized, when the function should create it's own copy. Since a 
vector is an array, it can be modified from within a function it is 
passed to.

I was using this function in some calculations for randomly changing the 
particle direction, passing it the emission direction directly. Since 
the direction vector in my patch specifies the speed as well as the 
direction, all the particles ended up travelling at a speed of 1, 
ignoring the length of the direction vector.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

On Fri, 30 Jun 2000 18:41:22 -0500, Chris Huff wrote:
>I was using this function in some calculations for randomly changing the 
>particle direction, passing it the emission direction directly. Since 
>the direction vector in my patch specifies the speed as well as the 
>direction, all the particles ended up travelling at a speed of 1, 
>ignoring the length of the direction vector.

Ah, yes, that's a bug.  Please send it to .bugreports, if you would.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Chris Huff wrote:
> 
> The use of VLength and VInverseScaleEq instead of VNormalize wasn't the
> bug I was talking about...the vector passed to the function is being
> normalized, when the function should create it's own copy. Since a

As far as my understanding of C and the workings of the POV-type
VECTOR go, this should *not* modify the "real" V1, since the value is
passed on the stack. The V1 in the function gets modified, but *not*
the parameter that is passed, example:

int ParamFunction(int i)
{
   i = i/2;	// modify parameter
   return i;	// and return the result
}

void TestParam(void)
{
   int x;

   x = 5;
   printf("%d\n",ParamFunction(x));  // prints "2"
   printf("%d\n",x);                 // prints "5", i.e. "x"
}

This prints:
   2    5

i.e. internal to the function, the parameter "i" gets modified,
but this does *not* modify the "calling" parameter x.

This is guaranteed by the C standard.

Or is the "VECTOR" type some hidden pointer?

Markus

Post a reply to this message

Markus Becker wrote:
> 
> 
> Or is the "VECTOR" type some hidden pointer?
> 
Vector is actually array of 3 doubles, so its contents could be
modified.

Post a reply to this message

In article <3960661E.A3C7871A@student.uni-siegen.de>, Markus Becker 
<mar### [at] studentuni-siegende> wrote:

> As far as my understanding of C and the workings of the POV-type
> VECTOR go, this should *not* modify the "real" V1, since the value is
> passed on the stack. The V1 in the function gets modified, but *not*
> the parameter that is passed, example:

The type VECTOR is an array of three doubles. The name of an array is 
the same as a pointer to the first element, so a function can modify a 
VECTOR passed to it. The same goes for colors.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Chris Huff wrote:
> 
> The type VECTOR is an array of three doubles. The name of an array is
> the same as a pointer to the first element, so a function can modify a
> VECTOR passed to it. The same goes for colors.

OK, I stand corrected. Then it is a bug ;-)

Markus

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: The type VECTOR is an array of three doubles.

  Well, strictly speaking there's no such a thing as an array in C.
  What is passed to the function is a pointer-to-double. This pointer points
to a memory location containing one (or more) double-type values. There's
no way of knowing whether the pointer points to just one double or to a
series of them, and if the latter, how many of them. You just have to trust.
  There is a pass-by-value parameter here, so the value is copied for the
function. But since the value is just a pointer, it will point to the same
place as the original one.

  Even a local "array" (like this:

void f(void)
{ double array_of_doubles[3];
}

) is not really an array, but just a pointer to a static memory location
which (ie. the pointer) can't be modified.

-- 
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