did you look at wrap from zexy?
.b.
Dafydd Hughes wrote:
I wish it was something as noble as gravitation, but it's just a clock which counts seconds from about 30000BC to now. It's easier to do using [mod] on the counters, but the way it's animated means it makes a smooth transition around the dial then jumps back to 0 instead of smoothly moving on. Just letting the rotation get bigger and bigger without modulo eliminates this problem, but does nasty things once the numbers get too long.
Luckily, Python can deal with much longer numbers. My solution is to do the counting and splitting in python, then have 2 clocks in Gem which are out of phase so one is rewinding with the gemhead off while the other goes smoothly to 0, then they switch. There's probably a much simpler solution.
Is any of this making sense? I'm pretty tired and I've had a couple of beers:)
Thanks everybody for the help.
cheers dafydd
On Dec 21, 2007 10:16 PM, Patrice Colet pat@mamalala.org wrote:
Mathieu Bouchard a écrit :
On Fri, 21 Dec 2007, B. Bogart wrote:
I always wonder when you say large numbers and rotation...
Do you really need large numbers? I never checked if its slower to rotateXYZ to 360*100 compared to rotation to 360.
I really wonder why Dafydd wants large numbers for rotation. I thought that it was for something that really needs large numbers. For all you can see on a display, float32 is already much more than necessary.
float32 is not enough for avoiding round off errors with astronomical values, for example if we would like to use the Newton universal gravitation formula,
F = G(m1*m2)/r^2
the radius would exceed the range of affordable numbers into this computation, and then the result wouldn't be accurate, so we can not simulate Newton laws with using pd arithmetic objects only.
Cheerfull xmas and NYear.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list