[R-pkg-devel] Use of long double in configuration

Tim Taylor t|m@t@y|or @end|ng |rom h|ddene|eph@nt@@co@uk
Wed Apr 30 10:43:24 CEST 2025


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 using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
> Attachments:
> * smime.p7s



More information about the R-package-devel mailing list