Marius Gedminas wrote:
On Tue, Apr 28, 2009 at 06:32:12PM +0200, Lorenz Quack wrote:1.5.4.1 v.isNormalized() -> bool 1.5.4.2 v.normalize() -> None # normalizes inplace 1.5.4.3 v1.normalized() -> v2 # returns normalized vectorIn my opinion normalize() and normalized() are far too ambiguous. We might should use something like ip_XXX() for inplace operations: v.ip_normalize () -> None v.normalize () -> v2 We do that naming already for Rect objects and should take care of doing that anywhere where inplace operations happen. The same then applies to the rest of your inplace methods.hm. ok. but the ip is after the name: v.normalize_ip()When I see 'ip', I cannot stop thinking about IP addresses. I think .normalize() vs .normalized() is clear enough, and also follows the convention set by Python builtins (list.sort() vs sorted()).
I personally also prefer .normalize() and .normalized() but if there is also a precedence like with rect in this case I prefer consistency over my personal taste.
And if vectors are immutable, this question becomes moot.
true. So we probably should come to an agreement on this point some time in the near future.
well. I thought you rarely want to twiddle with this so I marked it private. I thought the normal user doesn't want to be bothered with this and the pro can access it.1.7 comparison operations ========================= 1.7.0 the "==" and "!=" and "bool" operater compare the differences against the attribute v._epsilon. this way the user can adjust the accuracy. 1.7.1.1 v == s -> bool # true if all component differ at most by v._epsilonHow am I as user supposed to manipulate _epsilon? It should be made public.I'm kind of expecting some expert to pop in and explain how this breaks mathematical properties of equality (v1 == v2 and v2 == v3 no longer implies v1 == v3) and how this could result in bugs and pain in real life code.
true but those guys should have poped in when IEEE 754 was written. It's a bit late now. well I guess to be precise IEEE754 doesn't break the property of transitivity explicitly but it does break associativity, and distributivity. In face of those does loss of transitivity really matter? and if it does you can set epsilon to 0 and be done with it :)
with repr I wanted to make explicitly clear that this is not a list but I thought that the normal str() would look nicer that way. what would you suggest? "[x, y, z]" for both (or "(x, y, z)" if we choose to make vectors immutable) or "Vector3d<x, y, z>"?1.8 misc ====================== 1.8.1 support iter protocol 1.8.2 str(v) -> "[x, y, z]" 1.8.3 repr(v) -> "Vec<x, y, z>"Most objects have the same output for str() and repr(). Why do you differ here?I'm +0.95 for distinct __str__ and __repr__. str is what you show your users and should be short and clear, while repr is what you give the programmers who're debugging and therefore exact types matter.
that was my line of though only worded much better. //Lorenz