I use my own implementation of the wrap function in kinematics and kinetics (robotics). Solutions beyond [0, 2pi] or [-pi, pi] can cause some problems when combined with learning algorithms, so we wrap them.
Interestingly, today I reviewed code for a teammate. He had the exact same problem, but did not think much about it and solved it with if-else statements. But yes, maybe this is too specific and trivial for a Numpy function. Thanks for taking the time to look into it! On Tue, 24 Nov 2020 at 15:47, Ralf Gommers <ralf.gomm...@gmail.com> wrote: > > > On Tue, Nov 24, 2020 at 11:37 AM Daniele Nicolodi <dani...@grinta.net> > wrote: > >> On 24/11/2020 10:25, Thomas wrote: >> > Like Nathaniel said, it would not improve much when compared to the >> > modulo operator. >> > >> > It could handle the edge cases better, but really the biggest benefit >> > would be that it is more convenient. >> >> Which edge cases? Better how? >> >> > And as the "unwrap" function already exists, >> >> The unwrap() function exists because it is not as trivial. >> > > I agree, we prefer not to add trivial functions like this. To help those > few people that may need this, maybe just add the one-liner Daniele gave to > the Notes section of unwrap()? > > Cheers, > Ralf > > > >> > people would expect that >> > and look for a function for the inverse operation (at least I did). >> >> What is your use of a wrap() function? I cannot think of any. >> >> Cheers, >> Dan >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion@python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
