Hi Christoph,

I would use #asFloat64Array. You can use #asFloatArray with 64-bit floats, but you'll lose precision when you subsequently access them via #at:. It's possible that #asFloatArray prefers 32 bits for backward compatibility. Squeak was 32-bit only for a long time.

Best, Chris

On Sun, Jul 2, 2023 at 6:50 PM christoph.thiede@student.hpi.uni-potsdam.de wrote:

Hi all,

simple question: Is it accurate to store SmallFloat64s in a Float32Array as SequenceableCollection>>#asFloatArray does or should I explicitly use #asFloat64Array? If the latter, why does #asFloatArray prefer 32 bits?

Best, Christoph

---

Sent from Squeak Inbox Talk

Hi Christoph,

On Jul 2, 2023, at 4:50 PM, christoph.thiede@student.hpi.uni-potsdam.de wrote:

Hi all,

simple question: Is it accurate to store SmallFloat64s in a Float32Array as SequenceableCollection>>#asFloatArray does or should I explicitly use #asFloat64Array? If the latter, why does #asFloatArray prefer 32 bits?

Chris & Nicolas have answered your main question. I just wanted to point out that SmallFloat64s are still 64-bit IEEE double-precision values, peers of BoxedFloat64; they take less space because they encode those whose exponent can be encoded in 8 bits, saving 3 bits for a tag, and hence squeezing them into a single machine word, just like SmallInteger. So the Small in SmallFloat64 refers to space saving in the representation, nothing else.

While this implies one will always be able to store a SmallFloat64 in a Float32Array, because the exponent range is the same as the IEEE 32-bit exponent range, in doing so one will lose 29 bits of precision in the mantissa.

HTH

Best, Christoph

Eliot _,,,^..^,,,_ (phone)