Cheers for the quick response. To clarify my question: Is it correct to say that as long as packages do not assume the greater precision provided by 'double' there is no reason they cannot use 'long double' to get *possible* advantages (e.g. in summations). AFAICT 'long double' is (and has always been) part of the C standard so it's use as a type should be unproblematic (this is the query relevant to matrixStats).
Apologies if this does not make much sense. Tim On Wed, 30 Apr 2025, at 9:33 AM, Uwe Ligges wrote: > On 30.04.2025 10:25, Tim Taylor wrote: >> Is it correct to say that R's conditional use of long double is around >> ensuring things work on platforms which have 'long double' identical to >> 'double' types, as opposed to there being an odd compiler targeted that does >> not even have any concept of 'long double' type? > > a double is 64 bit and stored that way on all platforms, the concept of > long doubles is CPU specific. x86 chips have 80bit in the floating point > units for calculations before rounding (and normalizing) to a regular > double. > > Some chips, e.g. those ARM chips used in current M[123]Macs (hence very > relevant topic), do not support long doubles. And compilers offer to > compile without support for long doubles which e.g. CRAN uses to check > in an additional (issues) check. > > Best, > Uwe Ligges > >> >> As background this was motivated by a query raised in the matrixStats >> package: >> https://github.com/HenrikBengtsson/matrixStats/issues/278 >> >> ______________________________________________ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > Attachments: > * smime.p7s ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
