similar to: [LLVMdev] NaNs and Infinities

I forgot to forward to the rest of the list... -------- Original Message -------- Subject: Re: [LLVMdev] NaNs and Infinities Date: Mon, 19 Apr 2010 23:41:43 -0700 From: Javier Martinez <javier at jmartinez.org> To: lost <lostfreeman at gmail.com> Hi, If it's an immediate you can cast the SDValue to a ConstantFP and use the isNaN() or isInfinity() member functions (see below).

I've got comments on the code change. The test cases look ok, but I haven't fully checked the math on the half-values. I checked with reference to trunk top-of-tree at revision 156617. I have not compiled the code. lib/AsmParser/LLLexer.cpp Adds support to parse format: 0xH<hexdigits> Tha 0xH format should be described in LangRef.html alongside 0xK<hex> and

Hi David, Many thanks for the comments! > Tha 0xH format should be described in LangRef.html alongside > 0xK<hex> and 0xM<hex> Done. > Declaration of "int shiftcount" should be moved to smallest nesting > possible, right after "if ( const ConstantFP ..." at line 710 > > (The code makes a lot more sense with a good comment on the

looks good here. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Anton Lokhmotov > Sent: Thursday, May 17, 2012 4:51 AM > To: 'David Neto' > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] [PATCH] OpenCL half support > > Hi David, > > Many thanks for the comments! > >

Hi, Object.isNumber() returns true on NaN. I don''t think that''s true.... NaN is Not a Number so it''s not a number... right? By the way, I''m using Prototype 1.6.0.2. Satoru --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this

Hi, i need to check if an overflow of an floating-point arithmetic operation occured. Currently I'm doing something like this (for addition): (LHS > 0 && RHS > 0 && sum <= 0) || (LHS < 0 && RHS < 0 && sum >= 0) This is checked for every addition. Is there a more efficient way like the intrisic for int overflow? How is it possible to raise a

Hi, I’d like to re-propose adding intrinsics for fmin / fmax. These can be used to implement the equivalent libm functions as defined in C99 and OpenCL, which R600 and AArch64 at least have instructions with the same semantics. This is not equivalent to a simple fcmp + select due to its handling of NaNs. This has been proposed before, but never delivered

Hi, I have some code which relies on the floating point rounding mode to be set to round-to-negative-infinity. This means that there are some floating point optimizations which are legal with the default round-to- nearest mode but not with rounding to negative infinity. Does LLVM reorder or otherwise optimize floating point operations? I've looked at the options for

I expect that atan(1i) = (0 + infinity i) and that atan(1i)/5 = (0 + infinity i)/5 = (0 + infinity i). Here's what I get in C: (0,1) = (0, 1) atan((0,1)) = (0, inf) atan((0,1))/5 = (0, inf) Note the difference between I*infinity = (0,1)*infinity = (0*infinity,1*infinity) = (NaN,infinity) and (0,infinity)/5 = (0/5,infinity/5) = (0,infinity). The former involves multiplying 0 by infinity, which

Ok, I had forgotten about sNaNs. Doesn't the same caveat apply to 0-sNaN then though or does that not signal? Does that mean we need a separate way to handle negate in the IR? Funnily enough, historically I believe we were using the multiplication by -1.0 because it was a more reliable negation that 0-x (from 3.0 until 3.3 at least). Is there a good reason why multiplication by NaN should kill

In r187314, APFloat multiplication by with NaNs was made to always yield a positive NaN. I am wondering whether that was the correct decision. It is of course true that the result of a multiplication is undefined in IEEE, however, we were using multiplication by -1.0 to implement IEEE negate, which is defined to preserve the sign bit. r210428 made 0-NaN have IEEE negate behavior, which is good

On 2024-09-06 12:44 a.m., Richard O'Keefe wrote: > I expect that atan(1i) = (0 + infinity i) and that atan(1i)/5 = (0 + > infinity i)/5 = (0 + infinity i). > Here's what I get in C: > (0,1) = (0, 1) > atan((0,1)) = (0, inf) > atan((0,1))/5 = (0, inf) > > Note the difference between I*infinity = (0,1)*infinity = > (0*infinity,1*infinity) = (NaN,infinity) > and

Le 2 juin 2010 à 12:21, Eli Friedman a écrit : > On Wed, Jun 2, 2010 at 2:59 AM, Stéphane Letz <letz at free.fr> wrote: >> Hi, >> >> We need to generate "Floating point constants" in our code. In http://llvm.org/docs/LangRef.html it is explained that FP has to follow special encoding rules to be handled by LLVM later one (hexadecimal coding...) >>

On Jun 2, 2010, at 3:28 AMPDT, Stéphane Letz wrote: > > Le 2 juin 2010 à 12:21, Eli Friedman a écrit : > >> On Wed, Jun 2, 2010 at 2:59 AM, Stéphane Letz <letz at free.fr> wrote: >>> Hi, >>> >>> We need to generate "Floating point constants" in our code. In http://llvm.org/docs/LangRef.html it is explained that FP has to follow special

Ok. That you for clarifying the point for me. I was primed for a regression because this behavior changed over llvm versions and was causing my tests to fail ;). I'm now doing bitcasting to int, xoring with the signbit and bitcasting back. On Thu, Aug 7, 2014 at 2:59 AM, Owen Anderson <resistor at mac.com> wrote: > Subtraction is also not a correct implementation of negation, for

sorry the integration was from -Inf to 1.96 The integrate function in R is not taking Inf (infinity). How do you use infinity in R. I was doing: integrate(dnorm,- Inf, 1.96) and I was getting Error: NA/NaN/Inf in foreign function call (arg 2). Obviously this should be equal to pnorm(1.96)= 0.9750021. How do you get around the infinity problem in R?

Hi R-devel, I have a question about the differentiation between NA and NaN values as implemented in R. In arithmetic.c, we have int R_IsNA(double x) { if (isnan(x)) { ieee_double y; y.value = x; return (y.word[lw] == 1954); } return 0; } ieee_double is just used for type punning so we can check the final bits and see if they're equal to 1954; if they are, x is NA, if they're

Vince Carey found this (thank you!). Since the fix to the problem is not entirely obvious, I post this to R-devel as RFC: help(dist) says: >> Missing values are allowed, and are excluded from all computations >> involving the rows within which they occur. If some columns are >> excluded in calculating a Euclidean, Manhattan or Canberra >> distance, the sum is

>>>>> Richard O'Keefe >>>>> on Fri, 6 Sep 2024 17:24:07 +1200 writes: > The thing is that real*complex, complex*real, and complex/real are not > "complex arithmetic" in the requisite sense. > The complex numbers are a vector space over the reals, Yes, but they _also_ are field (and as others have argued mathematically only

G.5.1 para 2 can be found in the C17 standard -- I actually have the final draft not the published standard. It's in earlier standards, I just didn't check earlier standards. Complex arithmetic was not in the first C standard (C89) but was in C99. The complex numbers do indeed form a field, and Z*W invokes an operation in that field when Z and W are both complex numbers. Z*R and R*Z,