Hi,
I assume this is a known bug (or is it a feature), that the atan2-object takes its arguments twisted. like [3 2( --> [atan2] is not the same as [expr atan2(3,2)]. what lovely source of error...
marius.
hi marius,
the internal [atan2] just takes its inputs as "x y" (or you can read them "real imaginary") -- a bit more naturally, perhaps, than the C function, which is atan2(y, x).
Btw, there is a, `weird' as would IOhanness say, compatibility issue here too, bacause in max, [atan2] takes inputs as "y x". Same for sickles/atan2~... having Atan2 in hammer would clarify this incompatibility (although people tend to use cartopol rather than atan2?).
k
marius schebella wrote: ...
I assume this is a known bug (or is it a feature), that the atan2-object takes its arguments twisted. like [3 2( --> [atan2] is not the same as [expr atan2(3,2)]. what lovely source of error...
Oops, sounds like pd's 'native' atan2 simply has the inputs backward! I have no idea what I was thinking doing that - perhaps I thought the Max one was backward too. 'Traditionally' (since Fortran I think) atan2 has always been (y, x).
At this point, is it worse if I try to fix it or if I leave it alone???
cheers Miller
On Tue, Mar 23, 2004 at 10:41:44AM +0100, Krzysztof Czaja wrote:
hi marius,
the internal [atan2] just takes its inputs as "x y" (or you can read them "real imaginary") -- a bit more naturally, perhaps, than the C function, which is atan2(y, x).
Btw, there is a, `weird' as would IOhanness say, compatibility issue here too, bacause in max, [atan2] takes inputs as "y x". Same for sickles/atan2~... having Atan2 in hammer would clarify this incompatibility (although people tend to use cartopol rather than atan2?).
k
marius schebella wrote: ...
I assume this is a known bug (or is it a feature), that the atan2-object takes its arguments twisted. like [3 2( --> [atan2] is not the same as [expr atan2(3,2)]. what lovely source of error...
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Pd is still on version 0, so I say fix it. Maybe add a warning message to the console when it instantiates. How much would it break?
.hc
On Tuesday, Mar 23, 2004, at 11:53 America/New_York, Miller Puckette wrote:
Oops, sounds like pd's 'native' atan2 simply has the inputs backward!
I have no idea what I was thinking doing that - perhaps I thought the Max one was backward too. 'Traditionally' (since Fortran I think) atan2 has always been (y, x).At this point, is it worse if I try to fix it or if I leave it alone???
cheers Miller
On Tue, Mar 23, 2004 at 10:41:44AM +0100, Krzysztof Czaja wrote:
hi marius,
the internal [atan2] just takes its inputs as "x y" (or you can read them "real imaginary") -- a bit more naturally, perhaps, than the C function, which is atan2(y, x).
Btw, there is a, `weird' as would IOhanness say, compatibility issue here too, bacause in max, [atan2] takes inputs as "y x". Same for sickles/atan2~... having Atan2 in hammer would clarify this incompatibility (although people tend to use cartopol rather than atan2?).
k
marius schebella wrote: ...
I assume this is a known bug (or is it a feature), that the atan2-object takes its arguments twisted. like [3 2( --> [atan2] is not the same as [expr atan2(3,2)]. what lovely source of error...
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
hi, It would break all old patches using atan2. All documentation showing screenshots with atan2. (Also printed documentation of patches). Hmm, but how many people used the atan2 object??? I think there were already other "non-backward-compatible" changes. So I also could live with a change of behaviour... best thing would be to use old patches with old pd-versions. and the new patches with new pd-versions. on the other hand. all personal libraries with abstractions using atan2 ... better not think about that... I vote for fix. marius.
----- Original Message ----- From: "Hans-Christoph Steiner" hans@eds.org To: msp@ucsd.edu Cc: "Krzysztof Czaja" czaja@chopin.edu.pl; "marius schebella" marius.schebella@chello.at; pd-list@iem.at Sent: Thursday, March 25, 2004 10:20 PM Subject: Re: [PD] atan2
Pd is still on version 0, so I say fix it. Maybe add a warning message to the console when it instantiates. How much would it break?
.hc
On Tuesday, Mar 23, 2004, at 11:53 America/New_York, Miller Puckette wrote:
Oops, sounds like pd's 'native' atan2 simply has the inputs backward! I have no idea what I was thinking doing that - perhaps I thought the Max one was backward too. 'Traditionally' (since Fortran I think) atan2 has always been (y, x).
At this point, is it worse if I try to fix it or if I leave it alone???
cheers Miller
On Tue, Mar 23, 2004 at 10:41:44AM +0100, Krzysztof Czaja wrote:
hi marius,
the internal [atan2] just takes its inputs as "x y" (or you can read them "real imaginary") -- a bit more naturally, perhaps, than the C function, which is atan2(y, x).
Btw, there is a, `weird' as would IOhanness say, compatibility issue here too, bacause in max, [atan2] takes inputs as "y x". Same for sickles/atan2~... having Atan2 in hammer would clarify this incompatibility (although people tend to use cartopol rather than atan2?).
k
marius schebella wrote: ...
I assume this is a known bug (or is it a feature), that the atan2-object takes its arguments twisted. like [3 2( --> [atan2] is not the same as [expr atan2(3,2)]. what lovely source of error...
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list