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