On 5/29/2019 11:52 AM, Matthew Flatt wrote:
Does anyone use single-flonums in Racket? I don't mean `_float` or `f32vector`s, which convert C `float`s or 32-bit array elements into regular double-precision Racket flonums. I mean literals like `3.0f0` or functions like `real->single-flonum`, which produce a Racket number that uses only 32 bits for arithmetic. Chez Scheme doesn't support single-precision floating-point numbers, and adding them would be a lot of work --- for no benefit, if it turns out that no one is using those kinds of numbers. My guess is that no one uses them currently, because it's rare that you'd want to trade speed for *im*precision. Single-flonums in Racket are significantly slower than regular flonums, because they're not treated as a common case. The only use I can think of, and the one that inspired the original experiment, is to try to faithfully replicate a C `float` calculation in Racket, but even that possibility has issues. If no one uses single-precision floats, then I will suggest that we remove them from Racket by making numbers like `3.0f0` parse as flonums and making `real->single-flonum` raise `exn:fail:unsupported`. Obviously, this would be a backward-incompatible change. But if it causes little enough trouble, then it could be a good trade to avoid problems for Racket CS and future platforms.
Question: does/will Chez support converting to/from 32-bit floats for C libraries? It probably doesn't matter too much if Chez itself only *operates* on 64-bit values. But being able to pass 32-bit values I think is important.
Machine learning is a hot topic now, and ANN often are implemented using matrix multiplication. A typical net involves a lot of mulitplications, so, at least on regular CPUs, it usually IS done with 32-bit for speed. [On some GPUs it is done with 16-bit FP values, and Google has an 8-bit FP chip. But no CPUs support these small FP values, and doing it with fixed point is a complex PITA (at least if you try to do it using SIMD ops)].
Aside: coming from a C/C++ image processing background, I've occasionally missed having SIMD ops native in Racket. FFI works fine, but calling out to a C library "feels" less natural [a bit like being forced to use intrinsics or drop into ASM in a C program]. It would be nice if Racket's array ops went SIMD at some point.
YMMV, George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/2e9df4a6-da50-7ac2-1bb5-2d0195a44b3a%40comcast.net. For more options, visit https://groups.google.com/d/optout.