search for: correspondends

Hello everybody, Can anyone tell me how I could analyze data that are at a contigency table form? I already found function cfa in the cfa package but I still don't understand how I could use this function in order to elaborate a contigency table. Every answer is welcome! --------------------------------- ÁðïêôÞóôå ôçí äùñåÜí óáò@yahoo.gr [[alternative HTML version deleted]]

Moin, is there any possibility to choose the input variables which are involved in the analysis, " ..., and each column correspondends to a variable. ..." (R-Reference-Manual) or do I have to delete them from the data.frame? An then I'd like to get the original dataset with the classification of the cluster, at the moment i do it this way clusterFrame <- merge(claraResult$clustering,claraResult$data,by = 0, all.x = T...

On 5/28/19 3:31 PM, Philip Reames via cfe-dev wrote: > I generally like the idea of having support in IR for vectorization of > custom functions.  I have several use cases which would benefit from this. > > I'd suggest a couple of reframings to the IR representation though. > > First, this should probably be specified as metadata/attribute on a > function declaration. 

On 5/29/19 1:52 PM, Philip Reames wrote: > On 5/28/19 7:55 PM, Finkel, Hal J. wrote: >> On 5/28/19 3:31 PM, Philip Reames via cfe-dev wrote: >>> I generally like the idea of having support in IR for vectorization of >>> custom functions.  I have several use cases which would benefit from this. >>> >>> I'd suggest a couple of reframings to the IR

Dear all, This RFC is a proposal to provide auto-vectorization functionality for user provided vector functions. The proposal is a modification of an RFC that I have sent out a couple of months ago, with the title `[RFC] Re-implementing -fveclib with OpenMP` (see http://lists.llvm.org/pipermail/llvm-dev/2018-December/128426.html). The previous RFC is to be considered abandoned. The original RFC

On 5/30/19 9:05 AM, Doerfert, Johannes wrote: > On 05/29, Finkel, Hal J. via cfe-dev wrote: >> On 5/29/19 1:52 PM, Philip Reames wrote: >>> On 5/28/19 7:55 PM, Finkel, Hal J. wrote: >>>> On 5/28/19 3:31 PM, Philip Reames via cfe-dev wrote: >>>>> I generally like the idea of having support in IR for vectorization of >>>>> custom

Hi Francesco, did you think about adding the attribute instead of the pragma? It is a common way to express such constructs as function attributes in clang/GCC rather than as pragma. Best regards, Alexey Bataev > 31 мая 2019 г., в 12:18, Francesco Petrogalli via cfe-dev <cfe-dev at lists.llvm.org> написал(а): > > Hi All, > > Thank you for the feedback so far. > > I

Francesco, there won't be any duplication. Most of the declarative OpenMP directives are represented as attributes internally, so, I think, it will be natural to use an attribute here rather than pragma. Best regards, Alexey Bataev > 31 мая 2019 г., в 13:32, Francesco Petrogalli <Francesco.Petrogalli at arm.com> написал(а): > > > >> On May 31, 2019, at 12:00 PM,

You can define clang specific attribute and later add GCC alias for it. Best regards, Alexey Bataev > 31 мая 2019 г., в 13:46, Francesco Petrogalli <Francesco.Petrogalli at arm.com> написал(а): > > > >> On May 31, 2019, at 12:38 PM, Alexey Bataev <a.bataev at hotmail.com> wrote: >> >> Francesco, there won't be any duplication. Most of the

Yes, this is very similar, but only expressed in terms of clang attributes, which may have different spellings for clang, GCC, c++11 etc. I don't think GCC will implement this as pragma. They added simd attribute instead of pragma. Best regards, Alexey Bataev > 31 мая 2019 г., в 14:43, Francesco Petrogalli <Francesco.Petrogalli at arm.com> написал(а): > > > >> On

I think we should split this discussion: TOPIC 1 & 2 & 4: How do implement all use cases and OpenMP 5.X features, including compatibility with other compilers and cross module support. TOPIC 3b & 5: Interoperability with clang declare (system vs. user declares) TOPIC 3a & 3c: floating point issues? I inlined comments for

Hi all, I am submitting the following RFC [1] to re-implement -fveclib via OpenMP constructs. The RFC was discussed during a round table at the last LLVM developer meeting, and presented during the BoF [2]. The proposal is published on Phabricator, for the purpose of keeping track of the comments, and it now ready for a review from a wider audience after being polished by Hal Finkel and Hideki

On 05/31, Saito, Hideki wrote: > > >This works for variants that are created from definitions in the module but what about #omp declare simd declarations? > > I'm sorry that I haven't digested this thread in its entirety, but let me just deal with this one point for now. > Suppose #pragma omp declare simd is applied to foo(). I'd expect the corresponding Function

I think I did misunderstand what you want to do with attributes. This is my bad. Let me try to explain: It seems you want the "vector-variants" attributes (which I could not find with this name in trunk, correct?) to "remember" what vector versions can be created (wrt. validity), assuming a definition is available? Correct? What I was concerned with is the example I sketched

>VectorClone does more than just mapping a scalar version to a vector one. It builds also the vector version definition by auto-vectorizing the body of the scalar function. To be more precise: VecClone strictly deals with the callee side of the code. Caller side mapping happens in vectorizer (LoopVectorize for the most part, but I don't see why SLPVectorize can't, for example).

>Is this also the case if the user did require lock-step semantic for the code to be correct? Certainly not, but that part is actually beyond OpenMP specification. I suggest looking up ICC's "#pragma simd assert" description and see if the assert feature is something you may be interested in seeing as an extended part of LLVM implementation of OpenMP (declare) simd. Else,

Page 22 of OpenMP 5.0 specification (Lines 13/14): When any thread encounters a simd construct, the iterations of the loop associated with the construct may be executed concurrently using the SIMD lanes that are available to the thread This is the Execution Model. The word here is "may" i.e., not "must". Declare simd is not explicitly mentioned here, but requiring

Hi All, The original intend of this thread is to "Expose user provided vector function for auto-vectorization.” I originally proposed to use OpenMP `declare variant` for the sake of using something that is defined by a standard. The RFC itself is not about fully implementing the `declare variant` directive. In fact, given the amount of complication it is bringing, I would like to move the