search for: longdouble

Dear Tanya: > You also have a few CBE failures that I am not seeing. What version > of xcode do you have installed? Xcode 2.4.1 > Can you send me the following files? > SingleSource/Regression/C/Output/2008-01-07-LongDouble.* > SingleSource/Regression/C/Output/PR1386.* OK, I attached those files (llvm-2.2-test-output.tar.gz) Best regards, 2008/1/30, Tanya Lattner <tonic at nondot.org>: > Thanks for testing the release. Overall the test results look decent > with a couple exceptions. > > You als...

Thanks for testing the release. Overall the test results look decent with a couple exceptions. You also have a few CBE failures that I am not seeing. What version of xcode do you have installed? Can you send me the following files? SingleSource/Regression/C/Output/2008-01-07-LongDouble.* SingleSource/Regression/C/Output/PR1386.* Thanks, Tanya On Jan 26, 2008, at 6:43 AM, Takanori Ishikawa wrote: > My test results for the LLVM 2.2 prerelease. > > === Q. Target === > > * Mac OS X 10.4.11 > * 2 GHz Intel Core 2 Duo > * MacBook > > % uname -a > Darw...

...Likewise. * m4/intltool.m4: Likewise. * m4/inttypes-pri.m4: Likewise. * m4/inttypes.m4: Likewise. * m4/inttypes_h.m4: Likewise. * m4/isc-posix.m4: Likewise. * m4/lcmessage.m4: Likewise. * m4/lib-ld.m4: Likewise. * m4/lib-link.m4: Likewise. * m4/lib-prefix.m4: Likewise. * m4/lock.m4: Likewise. * m4/longdouble.m4: Likewise. * m4/longlong.m4: Likewise. * m4/nls.m4: Likewise. * m4/po.m4: Likewise. * m4/printf-posix.m4: Likewise. * m4/progtest.m4: Likewise. * m4/signed.m4: Likewise. * m4/size_max.m4: Likewise. * m4/stdint_h.m4: Likewise. * m4/uintmax_t.m4: Likewise. * m4/ulonglong.m4: Likewise. * m4/visibil...

...inline below: > > On Sun, 19 Jan 2020, Spencer Graves wrote: > >> On my Mac: >> >> >> str(.Machine) >> ... >> $ integer.max????????? : int 2147483647 >> ?$ sizeof.long????????? : int 8 >> ?$ sizeof.longlong????? : int 8 >> ?$ sizeof.longdouble??? : int 16 >> ?$ sizeof.pointer?????? : int 8 >> >> >> ????? On a Windows 10 machine I have, $ sizeof.long : int 4; otherwise >> the same as on my Mac. > One of many annoyances of Windows -- done for compatibility with > ancient Window apps. > >> ???...

...ed they should return > (integer-valued) double instead of NA_integer_ and for that > reason should always return double: > Even if we have (hopefully) a native 64bit integer in R, > 2^64 is still teeny tiny compared .Machine$double.max > > (and then maybe we'd have .Machine$longdouble.max which would > be considerably larger than double.max unless on Windows, where > the wise men at Microsoft decided to keep their workload simple > by defining "long double := double" - as 'long double' > unfortunately is not well defined by C standards) &gt...

Hello Everybody in order to get some needed results out of my function i need to get my besselI function evaluated at some values which normally gave Inf or 0 (expon.scaled NAN) back. So I would like to increase the range in R from approxamittly 1e+320 to aabout 1e+500 or something like that. Is there any possibility or pacckage to do this easily? Thank You Sebastian Kaiser Institut for Statistics

On my Mac: str(.Machine) ... $ integer.max????????? : int 2147483647 ?$ sizeof.long????????? : int 8 ?$ sizeof.longlong????? : int 8 ?$ sizeof.longdouble??? : int 16 ?$ sizeof.pointer?????? : int 8 ????? On a Windows 10 machine I have, $ sizeof.long : int 4; otherwise the same as on my Mac. ????? Am I correct that $ sizeof.long = 4 means 4 bytes = 32 bits? log2(.Machine$integer.max) = 31.? Then 8 bytes is what used to be called double prec...

...nteger_ and for that > >> reason should always return double: > >> Even if we have (hopefully) a native 64bit integer in R, > >> 2^64 is still teeny tiny compared .Machine$double.max > >> > >> (and then maybe we'd have .Machine$longdouble.max which would > >> be considerably larger than double.max unless on Windows, where > >> the wise men at Microsoft decided to keep their workload simple > >> by defining "long double := double" - as 'long double' > >> unfortuna...

...39;m actually pretty convinced they should return (integer-valued) double instead of NA_integer_ and for that reason should always return double: Even if we have (hopefully) a native 64bit integer in R, 2^64 is still teeny tiny compared .Machine$double.max (and then maybe we'd have .Machine$longdouble.max which would be considerably larger than double.max unless on Windows, where the wise men at Microsoft decided to keep their workload simple by defining "long double := double" - as 'long double' unfortunately is not well defined by C standards) Martin > On 2020-...

...>> reason should always return double: >>> >> Even if we have (hopefully) a native 64bit integer in R, >>> >> 2^64 is still teeny tiny compared .Machine$double.max >>> >> >>> >> (and then maybe we'd have .Machine$longdouble.max which would >>> >> be considerably larger than double.max unless on Windows, where >>> >> the wise men at Microsoft decided to keep their workload simple >>> >> by defining "long double := double" - as 'long double'...

....0 this year, but 2021 may be possible. I few notes inline below: On Sun, 19 Jan 2020, Spencer Graves wrote: > On my Mac: > > > str(.Machine) > ... > $ integer.max????????? : int 2147483647 > ?$ sizeof.long????????? : int 8 > ?$ sizeof.longlong????? : int 8 > ?$ sizeof.longdouble??? : int 16 > ?$ sizeof.pointer?????? : int 8 > > > ????? On a Windows 10 machine I have, $ sizeof.long : int 4; otherwise > the same as on my Mac. One of many annoyances of Windows -- done for compatibility with ancient Window apps. > ????? Am I correct that $ sizeof.long = 4 m...

...d) double instead of NA_integer_ and for that >> reason should always return double: >> Even if we have (hopefully) a native 64bit integer in R, >> 2^64 is still teeny tiny compared .Machine$double.max >> >> (and then maybe we'd have .Machine$longdouble.max which would >> be considerably larger than double.max unless on Windows, where >> the wise men at Microsoft decided to keep their workload simple >> by defining "long double := double" - as 'long double' >> unfortunately is not well def...

...at >> >> reason should always return double: >> >> Even if we have (hopefully) a native 64bit integer in R, >> >> 2^64 is still teeny tiny compared .Machine$double.max >> >> >> >> (and then maybe we'd have .Machine$longdouble.max which would >> >> be considerably larger than double.max unless on Windows, where >> >> the wise men at Microsoft decided to keep their workload simple >> >> by defining "long double := double" - as 'long double' >> &g...

...patch. * Fix parallel::mclapply(..., mc.preschedule=FALSE) to handle raw vector results correctly. PR#17779 * Computing the base value, i.e., 2, "everywhere", now uses FLT_RADIX, as the original machar code looped indefinitely on the ppc64 architecture for the longdouble case. * In R 4.0.0, sort.list(x) when is.object(x) was true, e.g., for x <- I(letters), was accidentally using method = "radix". Consequently, e.g., merge(<data.frame>) was much slower than previously; reported in PR#17794. * plot(y ~ x, ylab = quote(y...

...patch. * Fix parallel::mclapply(..., mc.preschedule=FALSE) to handle raw vector results correctly. PR#17779 * Computing the base value, i.e., 2, "everywhere", now uses FLT_RADIX, as the original machar code looped indefinitely on the ppc64 architecture for the longdouble case. * In R 4.0.0, sort.list(x) when is.object(x) was true, e.g., for x <- I(letters), was accidentally using method = "radix". Consequently, e.g., merge(<data.frame>) was much slower than previously; reported in PR#17794. * plot(y ~ x, ylab = quote(y...

...patch. * Fix parallel::mclapply(..., mc.preschedule=FALSE) to handle raw vector results correctly. PR#17779 * Computing the base value, i.e., 2, "everywhere", now uses FLT_RADIX, as the original machar code looped indefinitely on the ppc64 architecture for the longdouble case. * In R 4.0.0, sort.list(x) when is.object(x) was true, e.g., for x <- I(letters), was accidentally using method = "radix". Consequently, e.g., merge(<data.frame>) was much slower than previously; reported in PR#17794. * plot(y ~ x, ylab = quote(y...

...4 /__inline.m4 /intlmacosx.m4 @@ -103,13 +83,9 @@ /inttypes.m4 /inttypes-pri.m4 /ioctl.m4 -/i-ring.m4 -/isatty.m4 /isblank.m4 -/isc-posix.m4 /langinfo_h.m4 /largefile.m4 -/lchown.m4 /lcmessage.m4 /lib-ld.m4 /lib-link.m4 @@ -125,7 +101,6 @@ /locale-zh.m4 /localtime-buffer.m4 /lock.m4 -/longdouble.m4 /longlong.m4 /lseek.m4 /lstat.m4 @@ -143,7 +118,6 @@ /memmem.m4 /mempcpy.m4 /memrchr.m4 -/mgetgroups.m4 /minmax.m4 /mkdir.m4 /mkdtemp.m4 @@ -175,7 +149,6 @@ /pthread_rwlock_rdlock.m4 /pthread_sigmask.m4 /pthread-thread.m4 -/ptsname_r.m4 /putenv.m4 /quotearg.m4 /quote.m4 @@ -194,7...

...always return double: > >>> >> Even if we have (hopefully) a native 64bit integer in R, > >>> >> 2^64 is still teeny tiny compared .Machine$double.max > >>> >> > >>> >> (and then maybe we'd have .Machine$longdouble.max which would > >>> >> be considerably larger than double.max unless on Windows, where > >>> >> the wise men at Microsoft decided to keep their workload simple > >>> >> by defining "long double := double" - as 'lo...

On 2020-01-19 13:01, Avraham Adler wrote: > Crazy thought, but being that a sum of Poissons is Poisson in the sum, > can you break your ?big? simulation into the sum of a few smaller > ones? Or is the order of magnitude difference just too great? ????? I don't perceive that as feasible.? Once I found what was generating NAs, it was easy to code a function to return pseudo-random

...urce/Regression/C++/2003-09-29-NonPODsByValue SingleSource/Regression/C/2003-10-12-GlobalVarInitializers SingleSource/Regression/C/2004-02-03-AggregateCopy SingleSource/Regression/C/2004-03-15-IndirectGoto SingleSource/Regression/C/2005-05-06-LongLongSignedShift SingleSource/Regression/C/2008-01-07-LongDouble SingleSource/Regression/C++/2008-01-29-ParamAliasesReturn SingleSource/Regression/C++/2011-03-28-Bitfield SingleSource/Regression/C/badidx SingleSource/Regression/C/bigstack SingleSource/Regression/C++/BuiltinTypeInfo SingleSource/Regression/C/callargs SingleSource/Regression/C/casts SingleSource/R...