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 vector >> >> In 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()). And if vectors are immutable, this question becomes moot. >>> 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. I used to think that way. Then I read _What Every Computer Scientist Should Know About Floating Point Arithmetic_ and understood that floats are very predictable if you understand them. (I still don't understand them. *wink*) >>> 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._epsilon >> >> How am I as user supposed to manipulate _epsilon? It should be made public. > > 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. 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. >>> 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? > > 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>"? 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. >>> 1.10 open questions (in no particular order) >>> ============================================ >>> 1.10.1 a) use radians for all angles >>> b) use degrees for all angles >> >> Degrees, I'd say. The api should be easy to use and letting users >> calculate the rad values before is not that intuitive. math.radians(180) is not intuitive? Well, maybe. You have to know it's there. (Can I mention math.hypot? Nobody knows about math.hypot. It's a modest little function that deserves more fame than it gets.) > I just checked: unfortunately pygame seems to be inconsistent: > transform.rotate use degrees and draw.arc uses radians. Does transform.rotate rotate clockwise or counter-clockwise? Pydoc doesn't say. >>> * __abs__ >>> pyeuclid returns the magnitude. >>> 3DVectorType returns vec3d(abs(x), abs(y), abs(z)) >>> vectypes and this proposal don't implement __abs__ to avoid confusion >> >> I'd expect abs() to get the magnitude/length, too. > > I don't so to avoid confusion I wouldn't implement it at all. how do > other people feel about this? I'd expect len(v) to return its length, but (1) that would be a horrible abuse of the sequence protocol, and (2) Python doesn't allow __len__ to return a non-integer value, thankfully. I didn't even know/had forgotten all about __abs__. > thanks again for the quite thorough feedback. Thanks for the comprehensive proposal. Marius Gedminas -- User n.: A programmer who will believe anything you tell him.
Attachment:
signature.asc
Description: Digital signature