Comments for omino pixel blog http://omino.com/pixelblog pixels, motion, and scripting Thu, 20 Nov 2008 10:25:50 +0000 http://wordpress.org/?v=2.6.3 Comment on Pixel Bender: Fun With Cubes 2 (a Dicing Sphere) by Kerry http://omino.com/pixelblog/2008/10/22/pixel-bender-a-dicing-sphere/#comment-2249 Kerry Thu, 30 Oct 2008 15:25:45 +0000 http://omino.com/pixelblog/?p=150#comment-2249 SecurityError: Error #2152: Full screen mode is not allowed. at flash.display::Stage/set displayState() at cubes03/goFullScreen() at cubes03/__bigButton_click() SecurityError: Error #2152: Full screen mode is not allowed.
at flash.display::Stage/set displayState()
at cubes03/goFullScreen()
at cubes03/__bigButton_click()

]]> Comment on Pixel Bender: A Gradient… and Some Math by david van brink http://omino.com/pixelblog/2008/10/20/pixel-bender-a-gradient-and-some-math/#comment-2202 david van brink Tue, 28 Oct 2008 00:52:03 +0000 http://omino.com/pixelblog/?p=123#comment-2202 Hahaha Thanks aron. I knew it had to be there somewhere. Oh well, I figured out some math along the way. And seriously -- two lines for the math, really, taht's pretty simple, isn't it? :) Hahaha Thanks aron. I knew it had to be there somewhere. Oh well, I figured out some math along the way. And seriously — two lines for the math, really, taht’s pretty simple, isn’t it? :)

]]> Comment on Pixel Bender: A Gradient… and Some Math by aron http://omino.com/pixelblog/2008/10/20/pixel-bender-a-gradient-and-some-math/#comment-2190 aron Mon, 27 Oct 2008 07:40:47 +0000 http://omino.com/pixelblog/?p=123#comment-2190 "Very often I need a simple linear-gradient in After Effects, and end up sing the four-color gradient because that’s all I can find." hmm, haven't you ever noticed Generate---> ramp? that's what linear gradient is called in ae. A bit simpler than this code :) but anyway, good job! “Very often I need a simple linear-gradient in After Effects, and end up sing the four-color gradient because that’s all I can find.”
hmm, haven’t you ever noticed Generate—> ramp? that’s what linear gradient is called in ae.
A bit simpler than this code :) but anyway, good job!

]]> Comment on Pixel Bender: A Gradient… and Some Math by david van brink http://omino.com/pixelblog/2008/10/20/pixel-bender-a-gradient-and-some-math/#comment-2097 david van brink Wed, 22 Oct 2008 18:11:42 +0000 http://omino.com/pixelblog/?p=123#comment-2097 Hi Ron -- I remember meeting you briefly in the lobby of I think DA2, because Qarin knew you. I don't remember which color badge you were using that day. Anyhow, yep, I use GC pretty often for thinking about stuff. Also, for fast cool graphics, like on the side of the "space house" in http://omino.com/gata/. Thanks for a great product! Hi Ron — I remember meeting you briefly in the lobby of I think DA2, because Qarin knew you. I don’t remember which color badge you were using that day. Anyhow, yep, I use GC pretty often for thinking about stuff. Also, for fast cool graphics, like on the side of the “space house” in http://omino.com/gata/.

Thanks for a great product!

]]> Comment on Pixel Bender: A Gradient… and Some Math by Ron Avitzur http://omino.com/pixelblog/2008/10/20/pixel-bender-a-gradient-and-some-math/#comment-2096 Ron Avitzur Wed, 22 Oct 2008 17:57:53 +0000 http://omino.com/pixelblog/?p=123#comment-2096 You can express max(min(x,1),0) more concisely in GC as clamp(x,0,1). <i>less well known is that it’s actually a very powerful and useful tool.</i> Thank you! (I find it deeply ironic that after so many years working to improve math education, the story is way better known than the software.) You can express max(min(x,1),0) more concisely in GC as clamp(x,0,1).

less well known is that it’s actually a very powerful and useful tool.

Thank you! (I find it deeply ironic that after so many years working to improve math education, the story is way better known than the software.)

]]> Comment on Pixel Bender: mod() bug by Kerry http://omino.com/pixelblog/2008/10/06/pixel-bender-mod-bug/#comment-2052 Kerry Mon, 20 Oct 2008 01:12:32 +0000 http://omino.com/pixelblog/?p=77#comment-2052 And BTW, if the gradual-underflow issue can be dealt with, it's likely that *floats* will give the same result on Intel and PowerPC. This is because rounding to 64 bits first and then to 23 bits (as Intel does) gives the same result as rounding to 23 bits directly (as PowerPC does). I never found the proof, but I remember that rounding to 2x (or more) bits before rounding to x bits does not change the result of the final rounding. And BTW, if the gradual-underflow issue can be dealt with, it’s likely that *floats* will give the same result on Intel and PowerPC. This is because rounding to 64 bits first and then to 23 bits (as Intel does) gives the same result as rounding to 23 bits directly (as PowerPC does). I never found the proof, but I remember that rounding to 2x (or more) bits before rounding to x bits does not change the result of the final rounding.

]]> Comment on Pixel Bender: mod() bug by Kerry Veenstra http://omino.com/pixelblog/2008/10/06/pixel-bender-mod-bug/#comment-2047 Kerry Veenstra Sun, 19 Oct 2008 22:56:26 +0000 http://omino.com/pixelblog/?p=77#comment-2047 Hee hee! A history of floating-point computer arithmetic would fill a book. PowerPC's floating point is pure IEEE Std 754, but none of Intel's floating point is. (And that's pure irony! Kahan's work on the 8087 is what makes IEEE Std 754 so good.) The original 8087 used 10-byte numbers with 64-bit mantissas, but IEEE doubles use 8-byte numbers with 53 bit mantissas. To get results on an 8087 that are close to those of 8-byte IEEE doubles, one rounds the Intel 64-bit mantissas to 53 bits. Unfortunately, rounding first to 64 bits (as the 8087 does) and then rounding to 53 bits is not the same as rounding straight to 53 bits (as PowerPC does). So the results on PowerPC and on 8087 are slightly different. ("8087" means all x86 CPUs through the Pentium III.) Then, with Pentium 4, Intel changed its floating-point strategy and implementation. First, Intel's own compilers avoided the 8087-compatibility registers and instead used the processor's SIMD media instructions for scalar computations. Since the SIMD instructions support 8-byte floating point numbers but not 10-byte 8087-like numbers, it sounds like one will get results that are the same as on the PowerPC. Unfortunately, Intel also went away from IEEE Std 754's "gradual underflow." Gradual underflow lets the CPU represent numbers between 2^(-1022) and 2^(-1074) without underflowing straight to zero. As unlikely as their appearance may seem, these values will show up occasionally. And unfortunately the Pentium 4 emulates gradual underflow in software. By default such emulation is turned off--and for a good reason. Once a computation starts underflowing gradually, subsequent computations that use the gradually underflowed result also underflow. One sees a noticable hit in performance as a thread of execution drags repeatedly through the emulation library routines. In media processing, such a hit is unacceptable. So on the Pentium 4 gradual underflow emulation is disabled by default, and you get a different floating-point result than you would get on a PowerPC. Hee hee! A history of floating-point computer arithmetic would fill a book. PowerPC’s floating point is pure IEEE Std 754, but none of Intel’s floating point is. (And that’s pure irony! Kahan’s work on the 8087 is what makes IEEE Std 754 so good.) The original 8087 used 10-byte numbers with 64-bit mantissas, but IEEE doubles use 8-byte numbers with 53 bit mantissas. To get results on an 8087 that are close to those of 8-byte IEEE doubles, one rounds the Intel 64-bit mantissas to 53 bits. Unfortunately, rounding first to 64 bits (as the 8087 does) and then rounding to 53 bits is not the same as rounding straight to 53 bits (as PowerPC does). So the results on PowerPC and on 8087 are slightly different. (”8087″ means all x86 CPUs through the Pentium III.)

Then, with Pentium 4, Intel changed its floating-point strategy and implementation. First, Intel’s own compilers avoided the 8087-compatibility registers and instead used the processor’s SIMD media instructions for scalar computations. Since the SIMD instructions support 8-byte floating point numbers but not 10-byte 8087-like numbers, it sounds like one will get results that are the same as on the PowerPC. Unfortunately, Intel also went away from IEEE Std 754’s “gradual underflow.” Gradual underflow lets the CPU represent numbers between 2^(-1022) and 2^(-1074) without underflowing straight to zero.

As unlikely as their appearance may seem, these values will show up occasionally. And unfortunately the Pentium 4 emulates gradual underflow in software. By default such emulation is turned off–and for a good reason. Once a computation starts underflowing gradually, subsequent computations that use the gradually underflowed result also underflow. One sees a noticable hit in performance as a thread of execution drags repeatedly through the emulation library routines. In media processing, such a hit is unacceptable. So on the Pentium 4 gradual underflow emulation is disabled by default, and you get a different floating-point result than you would get on a PowerPC.

]]> Comment on Pixel Bender: mod() bug by david van brink http://omino.com/pixelblog/2008/10/06/pixel-bender-mod-bug/#comment-2042 david van brink Sun, 19 Oct 2008 20:32:58 +0000 http://omino.com/pixelblog/?p=77#comment-2042 Yes! Even more distressing is that the default arithmetic results using doubles (doubles!) under GNU-C can produce different results on Power PC and Intel. (Presumably there's a hi-fi compiler option someplace.) Yes!

Even more distressing is that the default arithmetic results using doubles (doubles!) under GNU-C can produce different results on Power PC and Intel. (Presumably there’s a hi-fi compiler option someplace.)

]]> Comment on Pixel Bender: mod() bug by Kerry http://omino.com/pixelblog/2008/10/06/pixel-bender-mod-bug/#comment-2022 Kerry Sun, 19 Oct 2008 05:10:07 +0000 http://omino.com/pixelblog/?p=77#comment-2022 > Notice that some of the CPU rendering’s lines are quite a bit smoother than the GPU rendering’s. Subtly different arithmetics. Yes. The GPU's computations are using a floating-point scheme that is inferior to the CPU's for improved performance. (It uses fewer bits and a faster but less well behaved rounding method.) As stated by William Kahan, who architected IEEE Std 768, "Gresham’s Law for Computing: The Fast drives out the Slow even if the Fast is Wrong." > Notice that some of the CPU rendering’s lines are quite a bit smoother than the GPU rendering’s. Subtly different arithmetics.

Yes. The GPU’s computations are using a floating-point scheme that is inferior to the CPU’s for improved performance. (It uses fewer bits and a faster but less well behaved rounding method.)

As stated by William Kahan, who architected IEEE Std 768,
“Gresham’s Law for Computing:
The Fast drives out the Slow even if the Fast is Wrong.”

]]> Comment on Teaser by Darrin Massena http://omino.com/pixelblog/2008/10/04/teaser/#comment-1662 Darrin Massena Sat, 04 Oct 2008 20:58:12 +0000 http://omino.com/pixelblog/?p=70#comment-1662 Cool! I'd like to try it out inside of Picnik.com (Pixel Bender effects are in beta). Cool! I’d like to try it out inside of Picnik.com (Pixel Bender effects are in beta).

]]>