为何类型推断为Double而非Float？Primitive32与64数组工厂的差异

嘿，这个问题问得很到位！咱们来一步步搞清楚这两个点：

先看你的代码：

final Array1D<Double> doubles = Array1D.factory(Primitive32Array.FACTORY).makeFilled(10, new Uniform());

这里有两个关键原因：

1. 显式的变量类型声明：你直接把变量指定为Array1D<Double>，编译器会优先适配这个目标类型——哪怕Primitive32Array.FACTORY是为32位数值设计的，库也会自动做类型转换（把float转成double）来满足你的声明，当然这种跨类型使用可能带来不必要的性能开销。
2. Uniform生成器的默认行为：你传入的Uniform随机数生成器，默认大概率是输出Double类型的数值。结合你显式指定的变量类型，方法的泛型参数就被推断为Double，最终生成了对应类型的数组。

另外提一句：按照这类数值库（比如EJML）的常规设计，Primitive32Array.FACTORY本来应该和Array1D<Float>配对使用，你这样跨类型其实不太规范，还可能出现精度损失。如果想要Float类型数组，把变量声明改成Array1D<Float>就可以了。

这两个工厂本质是为不同精度的原始数值数组服务的，核心差异包括：

• 底层存储类型：
  • Primitive32Array.FACTORY：创建的数组底层用**32位单精度浮点数（float）**存储，每个元素占4字节。
  • Primitive64Array.FACTORY：创建的数组底层用**64位双精度浮点数（double）**存储，每个元素占8字节。
• 精度与数值范围：
  • float的有效精度约为6-7位十进制数字，能表示的数值范围较小；
  • double的有效精度可达15-17位，数值范围大得多，适合需要高精度计算的场景。
• 内存与性能：
  • 32位数组的内存占用是64位的一半，在内存紧张的嵌入式系统或大数据场景下更有优势；
  • 现代CPU对两种类型的运算支持都很好，但在部分老旧架构上，float运算可能略快一点。
• 配套泛型类型：
  • 通常Primitive32Array.FACTORY对应Array1D<Float>，Primitive64Array.FACTORY对应Array1D<Double>，使用匹配的泛型可以避免自动装箱/拆箱或类型转换的额外开销。

内容的提问来源于stack exchange，提问作者user482745