В Tue, 29 Apr 2025 14:43:40 +0200
Nils Lüschow пишет:
> While we generally got this feature to work when Gecode is
> pre-installed on the system, we would like to spare the users this
> step and include it with the package
It's probably a good idea to try to achieve both. If a system copy of
the
Le 29/04/2025 à 14:43, Nils Lüschow a écrit :
Hello everybody,
as a new feature for the anticlust package (https://cran.r-project.org/
web/packages/anticlust/index.html) we are trying to include a constraint
programming model, written in C++ utilizing the Gecode solver. While we
generally got
Hello everybody,
as a new feature for the anticlust package
(https://cran.r-project.org/web/packages/anticlust/index.html) we are
trying to include a constraint programming model, written in C++
utilizing the Gecode solver. While we generally got this feature to work
when Gecode is pre-instal
As one of original 30-some members of 1985 IEEE 754, I find it discouraging that
we are treating long-double as the exception, when it is the introduction of
"short double" in M1 etc chips that have forced the issue. There are strong
commercial reasons, but they aren't computational ones.
JN
On
Thank you all!
Everything is clear.
Tim
On Wed, 30 Apr 2025, at 10:07 AM, Tomas Kalibera wrote:
> On 4/30/25 10:43, Tim Taylor wrote:
>> 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
On 4/30/25 10:43, Tim Taylor wrote:
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)
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 alwa
Tim,
no, and as far as I can tell some of the claims in that thread are incorrect.
Whether long double is identical to double is irrelevant and has nothing to do
with it.
R has a configuration option --enable-long-double which governs whether R
should use algorithms which can benefit from exte
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 'lon
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?
As background this was mot
10 matches
Mail list logo
