search for: ninf

Estimada Comunidad, hice un Anova (SS III) usando la biblioteca CAR y necesito obtener los residuos del ajuste ... el argumento de Anova fue un modelo ajustado con glm(), como indica el siguiente codigo: inf.ninf.glm <- glm(CH ~ pa.+lam+ps.+age+area+expo+inf+P+ppacum1mes, data=hum[hum$CH < 45,]) inf.ninf.Aov <- Anova(inf.ninf.aov, type=3, error.estimate="pearson") mi pregunta ahora, es como extraigo los residuos desde inf.ninf.Aov, para no hacer calculos manuales estimando y calcula...

Hi Hal, >> 4. To fix this, I think that additional fast-math-flags are likely >> needed in the IR. Instead of the following set: >> >> 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' >> >> something like this: >> >> 'reassoc' + 'libm' + 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' >> >> would be more useful. Related to this, th...

Hi, Warren, Thanks for writing all of this up. In short, regarding your suggested solution: > 4. To fix this, I think that additional fast-math-flags are likely > needed in > > the IR. Instead of the following set: > > 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' > > something like this: > > 'reassoc' + 'libm' + 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' > > would be more useful. Related to this, the current 'fast'...

....llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hi Hal, > > >> 4. To fix this, I think that additional fast-math-flags are likely > >> needed in the IR. Instead of the following set: > >> > >> 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' > >> > >> something like this: > >> > >> 'reassoc' + 'libm' + 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' > >> >...

...IR that implies all the other FMF makes sense? I'm not seeing a good reason for it, but since this is very new to me, I can easily imagine I'm missing the big picture. For example, in the LLVM IR (http://llvm.org/docs/LangRef.html#fast-math-flags) the fast-math flags 'nnan', 'ninf', 'nsz', 'arcp' and 'fast’ are defined. Except for 'fast', each of these has a fairly specific definition of what they mean. For example, for 'arcp': arcp => "Allow optimizations to use the reciprocal of an argument rather than per...

...6 PM, Ristow, Warren via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi Hal, >> 4. To fix this, I think that additional fast-math-flags are likely >> needed in the IR. Instead of the following set: >> >> 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' >> >> something like this: >> >> 'reassoc' + 'libm' + 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' >> >> would be more useful. Related to this, th...

...cases now ends up disabling almost all the fast-math transformations. This causes a performance hit for people that have been doing this. 4. To fix this, I think that additional fast-math-flags are likely needed in the IR. Instead of the following set: 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' something like this: 'reassoc' + 'libm' + 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' would be more useful. Related to this, the current 'fast' flag whic...

.../D39304> / r317488 we got rid of the umbrella UnsafeMath flag and introduced 3 more flags that better represent the different things that happen under fast-math. From a bitcode perspective, this change looks like this: Before r317488 we had 6 bits that respectively represented: UnsafeMath nnan ninf nsz arcp contract *unset* (The order may not match what is exactly in the bitcode.) After r317488 we had 7 bits that respectively represented: reassoc (-UnsafeMath- is gone) nnan ninf nsz arcp contract *afn* (new bit) Before r317488, fast-math was true if UnsafeMath was true (this should also im...

...IR that implies all the other FMF makes sense? I'm not seeing a good reason for it, but since this is very new to me, I can easily imagine I'm missing the big picture. For example, in the LLVM IR (http://llvm.org/docs/LangRef.html#fast-math-flags) the fast-math flags 'nnan', 'ninf', 'nsz', 'arcp' and 'fast’ are defined. Except for 'fast', each of these has a fairly specific definition of what they mean. For example, for 'arcp': arcp => "Allow optimizations to use the reciprocal of an argument rather than per...

...the umbrella UnsafeMath flag and introduced 3 more flags that better represent the different things that happen under fast-math. > > From a bitcode perspective, this change looks like this: > Before r317488 we had 6 bits that respectively represented: > > UnsafeMath > nnan > ninf > nsz > arcp > contract > *unset* > > (The order may not match what is exactly in the bitcode.) > > After r317488 we had 7 bits that respectively represented: > reassoc (-UnsafeMath- is gone) > nnan > ninf > nsz > arcp > contract > *afn* (new bit) >...

...rella > UnsafeMath flag and introduced 3 more flags that better represent the > different things that happen under fast-math. > > From a bitcode perspective, this change looks like this: > Before r317488 we had 6 bits that respectively represented: > > UnsafeMath > nnan > ninf > nsz > arcp > contract > *unset* > > (The order may not match what is exactly in the bitcode.) > > After r317488 we had 7 bits that respectively represented: > reassoc (-UnsafeMath- is gone) > nnan > ninf > nsz > arcp > contract > *afn* (new bit) > &...

...rella > UnsafeMath flag and introduced 3 more flags that better represent the > different things that happen under fast-math. > > From a bitcode perspective, this change looks like this: > Before r317488 we had 6 bits that respectively represented: > > UnsafeMath > nnan > ninf > nsz > arcp > contract > *unset* > > (The order may not match what is exactly in the bitcode.) > > After r317488 we had 7 bits that respectively represented: > reassoc (-UnsafeMath- is gone) > nnan > ninf > nsz > arcp > contract > *afn* (new bit) > &...

...think I agree, but this needs clarification. My view is that we don't want to reassociate constrained operations when `-fp-model=strict`. When `-fp-model=fast`, we should reassociate and do pretty much all the reasonably safe FMF transformations, with the caveat that I don't think NNAN and NINF make sense for any trap-safe mode. We may want to trap on those NaNs and Infs we'd optimize away.

...good reason for it, but since this is very new to me, I can easily imagine I'm missing the big picture. > > For example, in the LLVM IR (http://llvm.org/docs/LangRef.html#fast-math-flags <http://llvm.org/docs/LangRef.html#fast-math-flags>) the fast-math flags 'nnan', 'ninf', 'nsz', 'arcp' and 'fast’ are defined. Except for 'fast', each of these has a fairly specific definition of what they mean. For example, for 'arcp': > > arcp => "Allow optimizations to use the reciprocal of an argument rather >...

...the umbrella UnsafeMath flag and introduced 3 more flags that better represent the different things that happen under fast-math. > > From a bitcode perspective, this change looks like this: > Before r317488 we had 6 bits that respectively represented: > > UnsafeMath > nnan > ninf > nsz > arcp > contract > *unset* > > (The order may not match what is exactly in the bitcode.) > > After r317488 we had 7 bits that respectively represented: > reassoc (-UnsafeMath- is gone) > nnan > ninf > nsz > arcp > contract > *afn* (new bit) >...

...g NEON intrinsics, > Clang *always* emit the "fast" attribute for all FP operations, and > that such scalarisation phase would split *all* non-fast FP > operations > if the target has non-IEEE-754 compliant SIMD. To be clear, I'm recommending that you add flags like nnan, ninf and nsz. However, I think that I've changed my mind: This won't work for the intrinsics. The flags are defined as: nsz No Signed Zeros - Allow optimizations to treat the sign of a zero argument or result as insignificant. nnan No NaNs - Allow optimizations to assume the arguments...

...g and introduced 3 more flags that better represent the different things that happen under fast-math. >> >> From a bitcode perspective, this change looks like this: >> Before r317488 we had 6 bits that respectively represented: >> >> UnsafeMath >> nnan >> ninf >> nsz >> arcp >> contract >> *unset* >> >> (The order may not match what is exactly in the bitcode.) >> >> After r317488 we had 7 bits that respectively represented: >> reassoc (-UnsafeMath- is gone) >> nnan >> ninf >> nsz &...

...er represent >>> the different things that happen under fast-math. >>> >>> From a bitcode perspective, this change looks like this: >>> Before r317488 we had 6 bits that respectively represented: >>> >>> UnsafeMath >>> nnan >>> ninf >>> nsz >>> arcp >>> contract >>> *unset* >>> >>> (The order may not match what is exactly in the bitcode.) >>> >>> After r317488 we had 7 bits that respectively represented: >>> reassoc (-UnsafeMath- is gone) >>...

...m.org/D26708 Currently when the command-line switch '-ffast-math' is specified, the IR-level fast-math-flag 'fast' gets attached to appropriate FP math instructions. That flag acts as an "umbrella" to implicitly turn on all the other fast-math-flags ('nnan', 'ninf', 'nsz' and 'arcp'): http://llvm.org/docs/LangRef.html#fast-math-flags This approach has the shortcoming that when there is a desire to disable one of these fast-math-flags, if the 'fast' flag remains, it implicitly re-enables the one being disabled. For example, comp...

...ntroduced 3 more flags that better represent >> the different things that happen under fast-math. >> >> From a bitcode perspective, this change looks like this: >> Before r317488 we had 6 bits that respectively represented: >> >> UnsafeMath >> nnan >> ninf >> nsz >> arcp >> contract >> *unset* >> >> (The order may not match what is exactly in the bitcode.) >> >> After r317488 we had 7 bits that respectively represented: >> reassoc (-UnsafeMath- is gone) >> nnan >> ninf >> nsz &gt...