On Apr 28, 2009, at 1:48 PM, Marcus von Appen wrote:
1.6 properties
==============
1.6.1.1 v.length -> a # gets the magnitude/length of the vector
1.6.1.2 v.length = a
# sets the length of the vector while preserving its
direction
The setter might be risky due to rounding issues.
true, but I think this can be very usefull. and I can live with the
fact that
v.length = 1.
v.length == 1. # -> false
when dealing with floating point variables you have to expect weird
behavior
like this.
As I said, it's risky. If I set v.length = 1, I expect v.length == 1
to
work. Any other behaviour is wrong for both, readability and behaviour
expectations, in my opinion.
How would you propose to make that true? I imagine you could store the
length as a vector attribute, but then it's either a lie or it means
the values must be scaled to it for every operation (i.e., x,y,z are
always stored in unit-form and the length is stored separately).
Also, if length is settable, what happens when I do this:
v.length = 0
v.length = 1
That would work with the unit-form approach, but would result in some
inconsistencies, i.e.:
v1 = Vector3(1,1,0)
v2 = Vector3(0,1,1)
v1 == v2
False
v1.length = v2.length = 0
v1 == v2
True? (I dunno, they are both null vectors)
v1.length = v2.length = 1
v1 == v2
False
Another option is to make length comparison epsilon-based to
compensate for rounding, however that implies length returns some new
number type that does that. Feels like a lot of effort for little
gain, though it might be able to be done by a relatively simple float
subclass, I dunno.
I kinda feel like a settable length is too magical. How about a
scale_to_length() or somesuch method that lets you scale the vector to
a given length (and raises an error for null vectors). I think that
would be more explicit less surprising in corner cases. And it would
be easy to document that scaling a vector to a given length does not
guarantee the resulting length will be precisely that value due to
rounding errors.
-Casey