similar to: matrix() can't handle NaN (PR#193)

On 21/03/2005, at 10:09 PM, David Firth wrote: > I am sorry that I wasn't clear. All that I meant was that *this* > problem can result in different behaviour in "ordinary" statistical > applications. For example, if the objective function in a call to > optim() involves calling one of these linear algebra routines, the > result may be NaN (on systems other than Mac

As a side note, Splus makes sin(x) NA, with a warning, for abs(x)>1.6*2^48 (about 4.51e+14) because more than half the digits are incorrect in sin(x) for such x. E.g., in R we get: > options(digits=16) > library(Rmpfr) > sin(4.6e14) [1] -0.792253849684354 > sin(mpfr(4.6e14, precBits=500)) 1 'mpfr' number of precision 500 bits [1]

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

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

I'm having trouble grokking complex NaN's. This first set examples using complex(re=NaN,im=NaN) give what I expect > Re(complex(re=NaN, im=NaN)) [1] NaN > Im(complex(re=NaN, im=NaN)) [1] NaN > Arg(complex(re=NaN, im=NaN)) [1] NaN > Mod(complex(re=NaN, im=NaN)) [1] NaN > abs(complex(re=NaN, im=NaN)) [1] NaN and so do the following > Re(complex(re=1,

This question is more out of curiosity than a complaint or suggestion, but I'm just wondering. The behavior of R on calculations that result in NaN seems a bit inconsistent. # this is expected: > 0/0 [1] NaN # but this gives a warning > sin(Inf) [1] NaN Warning message: In sin(Inf) : NaNs produced # and this again does not > exp(NaN) [1] NaN Conceptually, I like to think that R

Hi All, I have some data where I am doing fairly simple calculations, nothing more than adding, subtracting, multiplying and dividing. I’m running into a problem when I divide one variable by another and when they’re both 0 I get NaN. I realize that if you divide a non-zero by 0 then you get Inf, which is, of course, correct. But in my case I never get Inf, just NaN because of the structure

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

Hello, What is the best way to turn a matrix into a list removing NaN's? I'm new to R... Start: > mt = matrix(c(1,4,NaN,5,3,6),2,3) > mt [,1] [,2] [,3] [1,] 1 NaN 3 [2,] 4 5 6 Desired result: > lst [[1]] [1] 1 3 [[2]] [1] 4 5 6 Thanks! Ben [[alternative HTML version deleted]]

Full_Name: cajo ter Braak Version: 2.1.1 OS: Windows Submission from: (NULL) (137.224.10.105) # I would like to attach the matrix C in the Rdata file; it is 50x50 and comes from a geostatistical problem (spherical covariogram) > rm(list=ls(all=TRUE)) > load(file= "test.eigen.Rdata") > ls() [1] "C" "eW" > > sym.check = max(abs(C - t(C))) # should

Hi Oleg, On 01/09/14 18:46, Oleg Ranevskyy wrote: > Hi Duncan, > > I looked through the IEEE standard and here is what I found: > > *6.2 Operations with NaNs* > /"For an operation with quiet NaN inputs, other than maximum and minimum > operations, if a floating-point result is to be delivered the result shall be a > quiet NaN which should be one of the input

Hi, The specification for the llvm.minnum/llvm.maxnum intrinsics is too unclear right now to usefully optimize. There are two problems. First the expected behavior for signaling NaNs needs to be clarified. Second, whether the returned value is expected to be canonicalized (as if by llvm.canonicalize). Currently according to the LangRef: Follows the IEEE-754 semantics for minNum, which also

As far as I know, LLVM does not try very hard to guarantee constant folded NaN payloads that match exactly what the target would generate. —Owen > On Sep 16, 2014, at 10:30 AM, Oleg Ranevskyy <llvm.mail.list at gmail.com> wrote: > > Hi Duncan, > > I reread everything we've discussed so far and would like to pay closer attention to the the ARM's FPSCR register

Hi Carter, I would strongly advise you against this direction. I’m aware of two directions that existing languages go in defining min/max operations: - IEEE 754, C, Fortran, Matlab, OpenCL, and HLSL all define it not to propagate NaNs - C++ (std::min/std::max) and OpenGL define it in the trinary operator manner: (a < b) ? a : b What you’re proposing does not match any existing languages

Hi Oleg, On 01/09/14 15:42, Oleg Ranevskyy wrote: > Hi, > > Thank you for your comment, Owen. > My LLVM expertise is certainly not enough to make such decisions yet. > Duncan, do you have any comments on this or do you know anyone else who can > decide about preserving NaN payloads? my take is that the first thing to do is to see what the IEEE standard says about NaNs.

Hi, Thank you for all your helpful comments. To sum up, below is the list of correct folding examples for fadd: (1) fadd %x, -0.0 -> %x (2) fadd undef, undef -> undef (3) fadd %x, undef -> NaN (undef is a NaN which is propagated) Looking through the code I found the "NoNaNs" flag accessed through an instance of

Hi Duncan, On 17.09.2014 21:10, Duncan Sands wrote: > Hi Oleg, > > On 17/09/14 18:45, Oleg Ranevskyy wrote: >> Hi, >> >> Thank you for all your helpful comments. >> >> To sum up, below is the list of correct folding examples for fadd: >> (1) fadd %x, -0.0 -> %x >> (2) fadd undef, undef -> undef

> On Sep 12, 2014, at 10:27 AM, Dan Gohman <dan433584 at gmail.com> wrote: > > > More generally, I don’t see a compelling reason for LLVM to add intrinsic support for the version you’re proposing. Your choice can easily be expanded into IR, and does not have the wide hardware support (particularly in GPUs) that the IEEE version does. > > The IEEE version can also be

>>>>> 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

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