hi,
because of the problems i had with calculations using floating point math,
and following Roman's advice, i changed to integer math.
however that's easier said then done.
i'm running again into an unexpected limitation:
32-bits can represent signed integers upto 2.147...billion.
however, as soon as a number is greater then binary 27 bits the last byte stays 0.( after 134217727 )
e.g. 134200000 + 25000 = 134224992 (should be 134225000).
what am i missing?
rolf
Le 25/05/2021 à 23:16, rolfm@dds.nl a écrit :
hi,
because of the problems i had with calculations using floating point math,
and following Roman's advice, i changed to integer math.
however that's easier said then done.
i'm running again into an unexpected limitation:
32-bits can represent signed integers upto 2.147...billion.
however, as soon as a number is greater then binary 27 bits the last byte stays 0.( after 134217727 )
e.g. 134200000 + 25000 = 134224992 (should be 134225000).
what am i missing?
there are no integer in pd. All number are float. cheers c
rolf
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
rolfm@dds.nl schreef op 25-05-2021 23:16:
hi,
because of the problems i had with calculations using floating point math,
and following Roman's advice, i changed to integer math.
however that's easier said then done.
i'm running again into an unexpected limitation:
32-bits can represent signed integers upto 2.147...billion.
however, as soon as a number is greater then binary 27 bits the last byte stays 0.( after 134217727 )
e.g. 134200000 + 25000 = 134224992 (should be 134225000).
what am i missing?
rolf
correction: the difference is 8, so it's the last 4 bits that are involved.
The higher the number, the more lower bits will be 0, because the floating point mantissa is too small to store them. It becomes more clear if you use binary notation.
Am 26. Mai 2021, 10:39, um 10:39, rolfm@dds.nl schrieb:
rolfm@dds.nl schreef op 25-05-2021 23:16:
hi,
because of the problems i had with calculations using floating point
math,
and following Roman's advice, i changed to integer math.
however that's easier said then done.
i'm running again into an unexpected limitation:
32-bits can represent signed integers upto 2.147...billion.
however, as soon as a number is greater then binary 27 bits the last
byte stays 0.( after 134217727 )
e.g. 134200000 + 25000 = 134224992 (should be 134225000).
what am i missing?
rolf
correction: the difference is 8, so it's the last 4 bits that are involved.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Greetings. Is there a fix to get a camera input to work in Pd with GEM on the Mac? Thank you! -Dana
Hi Dana,
I am on Mojave and pix_video works. What os version do you have?
best,
Fede
fdch.github.io
On May 28, 2021, at 7:13 PM, Dana Moser rosalux@curiousart.org wrote:
Greetings. Is there a fix to get a camera input to work in Pd with GEM on the Mac? Thank you! -Dana
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Fede- Yes, you are right! My apologies to the list. Camera works in Mojave. I have a colleague who reports that it doesn't work in Big Sur (latest OS) on the Mac. Thank you for your reply! -Dana
On 5/28/21 8:37 PM, Fede Camara Halac wrote:
Hi Dana, I am on Mojave and pix_video works. What os version do you have? best, Fede
fdch.github.io
-
Christof Ressi -
cyrille henry -
Dana Moser -
Fede Camara Halac -
rolfm＠dds.nl