search for: ulp

...a better way to do this, we are open to that as well. Thanks, charlie taylor uf hpc center ======================================================================== =========================================================== gcc -Wp,-MD,/root/lustre/1.6.4.2/ofa_kernel-1.2/drivers/infiniband/ ulp/ipoib/.ipoib_fs.o.d -nostdinc -isystem /usr/lib/gcc/x86_64- redhat-linux/4.1.1/include -D__KERNEL__ \ -I/root/lustre/1.6.4.2/ofa_kernel-1.2/kernel_addons/backport/2.6.18/ include/ \ -I/root/lustre/1.6.4.2/ofa_kernel-1.2/include \ -I/root/lustre/1.6.4.2/ofa_kernel-1.2/drivers/infiniband/include \...

...ire that this be the default pow( ) function. [Note: it was not actually shown until quite late in the IEEE 754 revision process that it was even possible to have a reasonably efficient correctly-rounded pow( ) function, and such a function is at minimum an order of magnitude slower than a good sub-ulp-accurate-but-not-correctly-rounded implementation. Most 754 committee members would recommend that the default pow( ) function *not* be correctly rounded.] In a good math library, however, pow( ) should absolutely be sub-ulp accurate, which means that it should *not* be implemented via log( ) and...

...ppreciated. ------------------------------------------------------------------------ Specification ------------- The metadata attribute is named "fpaccuracy", and contains a single integer parameter which specifies the maximum relative error of the operation to which it is attached, in ULPs. For the definition of ULPs we follow the definition given in the OpenCL 1.1 specification (section 7.4): If x is a real number that lies between two finite consecutive floating-point numbers a and b, without being equal to one of them, then ulp(x) = |b - a|, otherwise ulp(x) is the distance...

In InstCombineCompares.cpp, routine InstCombiner::FoldFCmp_IntToFP_Cst, there are these lines: // Comparisons with zero are a special case where we know we won't lose // information. bool IsCmpZero = RHS.isPosZero(); // If the conversion would lose info, don't hack on this. if ((int)InputSize > MantissaWidth && !IsCmpZero) return nullptr; Why check for positive

Hi Peter, This sounds like I really good idea. One thing that did occur to me though from an OpenCL point of view is that ULP accuracy requirements can differ for embedded and full profile so that may need to be handled somehow. Thanks, Rob On Wed, 2011-09-07 at 21:55 +0100, Peter Collingbourne wrote: > Hi, > > This is my proposal to add floating point accuracy support to LLVM. > The intention is that the...

...arguments as more settings become available). Note that as the current option isn't actually connected to any optimizations, there is nothing much to argue about for the moment. My plan is to introduce a few simple optimizations (x + 0.0 -> x for example) that introduce a finite number of ULPs of error, and hook them up. Thus this does not include things like x * 0.0 -> 0.0 (infinite ULPs of error), reassociation (infinite ULPs of error) or any other scary things. which mostly boil down to the fact that this is a very C-centric view of the world. And, since C compilers are not...

...ire that this be the default pow( ) function. [Note: it was not actually shown until quite late in the IEEE 754 revision process that it was even possible to have a reasonably efficient correctly-rounded pow( ) function, and such a function is at minimum an order of magnitude slower than a good sub-ulp-accurate-but-not-correctly-rounded implementation. Most 754 committee members would recommend that the default pow( ) function *not* be correctly rounded.] > > So we should use x*x*x even without fast-math... > >> In a good math library, however, pow( ) should absolutely be sub-ulp...

On Tue, Jun 17, 2014 at 10:11 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > If we require the host to have sse2 or other IEEE 754 conformant > implementation, would it be possible to use hardware float? > I don't think that IEEE 754 actually guarantees bit-exact results in all cases. -- Sean Silva > > Sent from my iPhone > > > On

...LTO). Functionality of the library: For each elementary function, the library contains subroutines for evaluation in single precision and double precision. Different accuracy of the results can be chosen for a subset of the elementary functions; for this subset there are versions with up to 1 ulp error and versions with a few ulp error. Obviously, less accurate versions are faster. Please note that we have 0.5 ulp maximum error when we convert a real number into a floating point number. In Hal's bgclang port, the less accurate versions are used with -ffast-math, and the more-accurat...

> On Jan 12, 2017, at 5:03 AM, Antoine Pitrou via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, 9 Jan 2017 11:43:17 -0600 > Wei Ding via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Hi, >> >> I want an efficient way to implement function pow in LLVM instead of >> invoking pow() math built-in. For algorithm part, I am clear for the

...h can be > used to signal that reduced precision is OK for a floating point operation, eg > > %z = fmul float %x, %y, !fpmath !0 > ... > !0 = metadata !{double 2.5} > > indicates that the multiplication can be done in any way that doesn't introduce > more than 2.5 ULPs of error. > > The first observation is that !fpmath can be extended with additional operands > in the future: operands that say things like whether it is OK to assume that > there are no NaNs and so forth. > > This patch doesn't add additional operands though. It just allo...

Many DRM drivers implement an encoder with an empty implementation. This patchset adds drm_simple_encoder_init() and drm_simple_encoder_create(), which can be used by drivers instead. Except for the destroy callback, the simple encoder's implementation is empty. The patchset also converts 4 encoder instances to use the simple-encoder helpers. But there are at least 11 other drivers which can

...cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] [cfe-dev] Proposal: floating point accuracy > metadata (OpenCL related) > > Hi Peter, > > This sounds like I really good idea. One thing that did occur to me > though from an OpenCL point of view is that ULP accuracy requirements > can differ for embedded and full profile so that may need to be handled > somehow. > > Thanks, > Rob > > On Wed, 2011-09-07 at 21:55 +0100, Peter Collingbourne wrote: > > Hi, > > > > This is my proposal to add floating point accuracy...

...ot;fpmath" metadata type which can be used to signal that reduced precision is OK for a floating point operation, eg %z = fmul float %x, %y, !fpmath !0 ... !0 = metadata !{double 2.5} indicates that the multiplication can be done in any way that doesn't introduce more than 2.5 ULPs of error. The first observation is that !fpmath can be extended with additional operands in the future: operands that say things like whether it is OK to assume that there are no NaNs and so forth. This patch doesn't add additional operands though. It just allows the existing accuracy opera...

Hi Duncan, I'm not an expert in fp accuracy question, but I had quite a few experience dealing with fp accuracy problems during compiler transformations. I think you have a step in the right direction, walking away from ULPs, which are pretty useless for the purpose of describing allowed fp optimizations IMHO. But using just "fast" keyword (or whatever else will be added in the future) is not enough without strict definition of this keyword in terms of IR transformations. For example, particular transformati...

...are set to zero. This problem applies also to other distribution functions like pnorm() and others. For your information I would also like to quote the relevant part of the R manual on .Machine$double.eps: "the smallest positive floating-point number x such that 1 + x != 1. It equals base^ulp.digits if either base is 2 or rounding is 0; otherwise, it is (base^ulp.digits)/ 2. Normally 2.220446e-16." Although different opinions were expressed on whether it makes sense to differentiate p-values below the machine epsilon, in my opinion different effect sizes should correspond with...

...not an expert in fp accuracy question, but I had quite a > few experience dealing with fp accuracy problems during compiler transformations. I agree that it's a minefield which is why I intend to proceed conservatively. > I think you have a step in the right direction, walking away from ULPs, which > are pretty useless for the purpose of describing allowed fp optimizations IMHO. > But using just "fast" keyword (or whatever else will be added in the future) is > not enough without strict definition of this keyword in terms of IR > transformations. For example, par...

On Sat, Apr 14, 2012 at 11:44 PM, Duncan Sands <baldrick at free.fr> wrote: > > I think you have a step in the right direction, walking away from ULPs, >> which >> are pretty useless for the purpose of describing allowed fp optimizations >> IMHO. >> But using just "fast" keyword (or whatever else will be added in the >> future) is >> not enough without strict definition of this keyword in terms of IR...

I am a french student and I want to make an histogram with R.But I have a problem: I cant' change the frequencies in percent and I can't change the number of classes or intervals of my variable.Can you help me please,in french if it's possible? My mail is : fhenge at ulp.u-strasbg.fr Thanks a lot. HENGE FREDERIQUE

Hi Given a real number x, I want to know how accurately R can represent numbers near x. In particular, I want to know the infinum of exactly representable numbers greater than x, and the supremum of exactly representable numbers less than x. And then the interesting thing is the difference between these two. I have a little function that does some of this: f <-