search for: reciprocality

Does R graphics have a way to easily label the horizontal axis by the reciprocal of the scaled value? -- View this message in context: http://r.789695.n4.nabble.com/Graphics-Reciprocal-labeling-tp3949054p3949054.html Sent from the R help mailing list archive at Nabble.com.

Hi all, In a mailing-list post last November: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html I raised some concerns that having the IR-level fast-math-flag 'fast' act as an "umbrella" to implicitly turn on all the lower-level fast-math-flags, causes some fundamental problems. Those fundamental problems are related to situations where a user wants to

On Thu, Aug 8, 2013 at 2:07 PM, Chad Rosier <chad.rosier at gmail.com> wrote: > On Thu, Aug 8, 2013 at 1:56 PM, Mark Lacey <mark.lacey at apple.com> wrote: > >> >> On Aug 8, 2013, at 9:56 AM, Jim Grosbach <grosbach at apple.com> wrote: >> >> Hi Chad, >> >> This is a great transform to do, but you’re right that it’s only safe >>

I believe that this may be more appropriate here in r-devel than in r-help. The normal hazard function, or reciprocal Mill's Ratio, may be obtained in R as dnorm(z)/(1 - pnorm(z)) or, better, as dnorm(z)/pnorm(-z) for small values of z. The latter formula breaks dowm numerically for me (running R 2.4.1 under Windows XP 5.1 SP 2) for values of z near 37.4 or greater. Looking at the pnorm

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

--- On Thu, 9/20/12, Jim Grosbach <grosbach at apple.com> wrote: From: Jim Grosbach <grosbach at apple.com> Subject: Re: [LLVMdev] Proposal: New DAG node type for reciprocal operation To: "Weiming Zhao" <weimingz at codeaurora.org> Cc: llvmdev at cs.uiuc.edu Date: Thursday, September 20, 2012, 3:32 PM Sounds like a reasonable fit for a target-specific DAG combine. I

Yes, what I mean is a target independent node in the ISD::NodeType enum. I already did the node transformation DAGCombiner and target-specific lowering in the first place. It worked. But introducing a specific node will make the logic more clear. For example, in ARM, FDIV is a scalar operation. So, after DAGCombiner and Vector Type legalize, vectorized FDIV has been expanded into scalar versions,

On the plus side, I'm glad to see the conclusions of the last couple of posts. From Mehdi: > Hope this clarify where I see the direction going, and even if you don’t agree with my > reasoning, the conclusion should be satisfactory on your side :) I'd say that summarizes my thoughts on this well. And from Nicolai: > Right. I'm not fundamentally opposed to having these

Hi folks, I know, this is a fairly common question and I am really disappointed that I could not find a solution. I am trying to calculate Mahanalobis distances in a data frame, where I have several hundreds groups and several hundreds of variables. Whatever I do, however I subset it I get the "system is computationally singular: reciprocal condition number" error. I know what it means

Hi uRsers, when inverting a 2 by 2 matrix using solve, I encountered a error message: solve.default(sigma, tol = 1e-07) : system is computationally singular: reciprocal condition number = 1.7671e-017 and then I test the determinant of this matrix: 6.341393e-06. In my program, I have a condition block that whether a matrix is invertible like this: if(det(sigma)<1e-7) return NULL;

> On Nov 17, 2016, at 1:44 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Nov 17, 2016, at 1:24 PM, Ristow, Warren <warren.ristow at sony.com> wrote: >> >> On the plus side, I'm glad to see the conclusions of the last couple of posts. >> >> From Mehdi: >> >>> Hope this clarify where I see the

> On Nov 16, 2016, at 6:22 PM, Ristow, Warren <warren.ristow at sony.com> wrote: > > > ... except that Warren’s proposal that started this discussion seems to imply that he > > has a use case that requires reciprocals to be turned off separately. > > Just to close this loose end, yes I have a use case. > > Specifically, we have a customer that turns on

Hi, In relaxed/fast math mode, if we can convert a/b to a * (1/b), we may get more performance when (1) "b" is loop invariant or (2) arch has faster reciprocal instruction (e.g. recipe/recips on ARM) or (3) arch has no vector div, but has vector mul and recip. So ,with this node type, a div node can be converted to a mul and a recip when desired. Then, each arch can further

Sounds like a reasonable fit for a target-specific DAG combine. I suspect a target specific node wouldn't be necessary and the patterns could be matched directly. -Jim On Sep 20, 2012, at 3:26 PM, Weiming Zhao <weimingz at codeaurora.org> wrote: > Hi, > > In relaxed/fast math mode, if we can convert a/b to a * (1/b), we may get more performance when (1) “b” is loop

>All that said, I think we (the company I work for, Sony) will have to implement support >for these switches. It comes down to GCC has these switches (e.g., -fno-reciprocal-math >and -fno-associative-math), and they do suppress the transformations for our customers. >They switch to Clang/LLVM, they use the same switches, and it doesn't "work". So as a >practical

Hi there, I would like to draw a scatter plot and fit a smooth line by loess. Below is the data. However, the curve line started from 0, which my "resid" list doesn't consist of 0 value. It returned some warnings which I don't know if this is the reason affecting such problem. Here I also attached the warning messages. Please let me know if there is a solution to fix this. Thank

Point #1 makes sense to me. For point #2, wouldn't that be somewhat orthogonal to the discussion, as it has/needs no knowledge that an IR-level transformation happened? Also, reciprocal-multiply will be the preferred option for many (most) backends if the IR says to do that. But, I suppose some backend might want to be allowed to do the reverse transformation if allowed by fast-math flags in

> On Nov 16, 2016, at 10:04 PM, Ristow, Warren <warren.ristow at sony.com> wrote: > > > Can you elaborate what kind of runtime failure is the reciprocal transformation triggering? > > Yes. It was along the lines of: > > { > float x = a / c; > float y = b / c; > > if (y == 1.0f) { > // do some processing for when

Hi all, This is about https://reviews.llvm.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'):

I don’t really like the idea of updating checks of UnsafeAlgebra() to depend on all of the other flags. It seems like it would be preferable to look at each optimization and figure out which flags it actually requires. I suspect that in many cases the “new” flag (i.e. allowing reassociation, etc.) will be what is actually needed anyway. I would be inclined to agree with Niolai’s suggestion of