[PD] atan2

[marius schebella]

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 at eds.org>
To: <msp at ucsd.edu>
Cc: "Krzysztof Czaja" <czaja at chopin.edu.pl>; "marius schebella"
<marius.schebella at chello.at>; <pd-list at 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 at iem.at
> >> http://iem.at/cgi-bin/mailman/listinfo/pd-list
> >
> > _______________________________________________
> > PD-list mailing list
> > PD-list at iem.at
> > http://iem.at/cgi-bin/mailman/listinfo/pd-list
>
>
> _______________________________________________
> PD-list mailing list
> PD-list at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>