search for: 1e16

I am sorry to not make my question clear. My question is how this value is calculated without having fadd and fsub in IR? On Sat, Aug 11, 2018 at 4:06 PM, Craig Topper <craig.topper at gmail.com> wrote: > Neither 1e16 or 1e16+1 can be accurately represented in a double. The > largest integer than be accurately represented is 2^53. As the number gets > larger floating sacrifices precision in the lower digits. Because of this > 1e16 and 1e16+1 end up having the same representation. So the result of > s...

Hi, I have below code in C - int main() { double x,y; x = 1e16; y = (x + 1) - x; printf("y:%e\n", y); return 0; } llvm bitcode looks like this for this function - ; Function Attrs: nounwind uwtable define dso_local i32 @main() local_unnamed_addr #0 { entry: %call = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8...

...ge.mode(seq(from=1L,to=2.5)) => integer --------------------------------- On the other hand, according to ? seq Currently, the default method returns a result of type '"integer"' if 'from' is (numerically equal to an) integer This is not correct: > seq(1e16,1e16+10) [1] 1e+16 1e+16 1e+16 1e+16 1e+16 1e+16 1e+16 1e+16 1e+16 1e+16 1e+16 > seq(1e16,1e16+10)-1e16 [1] 0 0 2 4 4 4 6 8 8 8 10 # not enough precision to represent all the distinct integers, OK > storage.mode(seq(1e16,1e16+10)) [1] "double" In this case, the ? : do...

Hi All, I've been digging around in src/nmath and have discovered that there are two sets of "machine constants" in bessel_l.c and bessel_j.c which have different values: bessel_i.c: static double ensig = 1e16; bessel_i.c: static double rtnsig = 1e-4; bessel_i.c: static double enmten = 8.9e-308; bessel_i.c: static double enten = 1e308; bessel_j.c: static double ensig = 1e17; bessel_j.c: static double rtnsig = 1e-4; bessel_j.c: static double enmten = 1.2e-37; bessel_j.c: static doubl...

...: R devel <r-devel@stat.math.ethz.ch> Subject: bessel_?.c constants Hi All, I've been digging around in src/nmath and have discovered that there are two sets of "machine constants" in bessel_l.c and bessel_j.c which have different values: bessel_i.c: static double ensig = 1e16; bessel_i.c: static double rtnsig = 1e-4; bessel_i.c: static double enmten = 8.9e-308; bessel_i.c: static double enten = 1e308; bessel_j.c: static double ensig = 1e17; bessel_j.c: static double rtnsig = 1e-4; bessel_j.c: static double enmten = 1.2e-37; bessel_j.c: static doubl...

at lines 651 & 653 (integer_binary function): if (code == DIVOP || code == POWOP) ans = allocVector(REALSXP, n); else ans = allocVector(INTSXP, n); There are calls to warningcall() later in the function, which can trigger garbbage collection. Looks like the typical scenario where it seemed pretty safe to not PROTECT in the original version of the function but

...0 and R-3.0.2): v <- c(1,2) m <- matrix(c(3,4),1,2) print(t(m)%*%v) print(crossprod(m,v)) in which crossprod gave an error rather than produce the answer for the corresponding use of %*%. o Raising -Inf to a large value (eg, (-Inf)^(1e16)) no longer produces an incomprehensible warning. As before, the value returned is Inf, because (due to their limited-precision floating-point representation) all such large numbers are even integers. o Fixed a bug (also present in R-2.15.0 and R-3.0.1) illustrated by...

...hen they are implicitly generated via model.matrix()). o anova.mlm had a scoping issue (PR#7898) o pf() with infinite df is allowed again. It is now more accurate for extreme ratios of dfs, especially when there is a non-centrality parameter. o df() was inaccurate for large df (1e16 or greater). o dt() was inaccurate for large df (1e9 or greater) with a non-centrality parameter. o runmed(*, algorithm="Turlach") seg.faulted in rare cases. o strwrap() now makes a reasonable job of text that is invalid in the current locale. o Reading with encoding...

...hen they are implicitly generated via model.matrix()). o anova.mlm had a scoping issue (PR#7898) o pf() with infinite df is allowed again. It is now more accurate for extreme ratios of dfs, especially when there is a non-centrality parameter. o df() was inaccurate for large df (1e16 or greater). o dt() was inaccurate for large df (1e9 or greater) with a non-centrality parameter. o runmed(*, algorithm="Turlach") seg.faulted in rare cases. o strwrap() now makes a reasonable job of text that is invalid in the current locale. o Reading with encoding...

Hey Richard, Could you share the following informations please? 1. gluster volume info <volname> 2. getfattr output of that file from all the bricks getfattr -d -e hex -m . <brickpath/filepath> 3. glustershd & glfsheal logs Regards, Karthik On Thu, Oct 26, 2017 at 10:21 AM, Amar Tumballi <atumball at redhat.com> wrote: > On a side note, try recently released health

On a side note, try recently released health report tool, and see if it does diagnose any issues in setup. Currently you may have to run it in all the three machines. On 26-Oct-2017 6:50 AM, "Amar Tumballi" <atumball at redhat.com> wrote: > Thanks for this report. This week many of the developers are at Gluster > Summit in Prague, will be checking this and respond next

...al-common.c:1327:afr_log_selfheal] 0-home-replicate-0: Completed entry selfheal on 7b708ed3-4530-42e0-a7a8-1e11ac642961. sources=0 [2] sinks=1 [2017-10-25 11:09:13.984209] I [MSGID: 108026] [afr-self-heal-entry.c:847:afr_selfheal_entry_do] 0-home-replicate-0: performing entry selfheal on c053fc9b-1e16-4f78-8e7b-2d892c1d7ae2 [2017-10-25 11:09:13.988713] I [MSGID: 108026] [afr-self-heal-common.c:1327:afr_log_selfheal] 0-home-replicate-0: Completed entry selfheal on c053fc9b-1e16-4f78-8e7b-2d892c1d7ae2. sources=0 [2] sinks=1 [2017-10-25 11:09:13.990468] I [MSGID: 108026] [afr-self-heal-metadata.c...