search for: indeterminate

...ke to use to form this interval. This is what I have now: ID Age DaysEnrolled HAZ WAZ WHZ Food onARV HIVStatus LTFUp 1 71622 0.008 0 NA NA NA NA 0 HIV exposed, status indeterminate 0 2 71622 0.085 28 NA NA NA NA 0 HIV exposed, status indeterminate 0 3 71622 0.123 42 NA NA NA NA 0 HIV exposed, status indeterminate 0 4 71622 0.277 98...

...0.003000000 0.002081666 0.009865766 0.015716234 0.040253364 0.017691806 0.013868429 0.007234178 I use the command: plotCI(OD600, cellconc, uiw=stdev) And I receive a graph that looks correct but without any error bars. I also receive these warnings: 1: In arrows(...) : zero-length arrow is of indeterminate angle and so skipped 2: In arrows(...) : zero-length arrow is of indeterminate angle and so skipped 3: In arrows(...) : zero-length arrow is of indeterminate angle and so skipped 4: In arrows(...) : zero-length arrow is of indeterminate angle and so skipped 5: In arrows(...) : zero-length arrow is...

Hi, I have imported some data to R from stata and my factor variables have an Indeterminate level which I don't really want. For example the variable sex has the levels Male, Female and Indeterminate. There are no 'Indeterminate' values in the data. Can somebody tell me how to get rid of this level as it restricting my cox ph model. Thanks Neil

Andy, This is less of a question but rather a status quo verification. We currently have certain indeterminism in MI scheduler DAG construction - it is introduces by the use of std::map/std::set during edge traversal. Result - a random variation in SUnit edge order (which will remain fixed thereafter). Logically, it is the same DAG, but topologically it is a slightly different one,

On Oct 16, 2012, at 1:43 PM, Sergei Larin <slarin at codeaurora.org> wrote: > > Andy, > > This is less of a question but rather a status quo verification… > > We currently have certain indeterminism in MI scheduler DAG construction – it is introduces by the use of std::map/std::set during edge traversal. > Result – a random variation in SUnit edge order

Andy, So if it is not a feature. then couple questions: First, I also do not see an easy way to restructure work sets in this case - so let's assume std::map is needed here. Then the way I understand it, there are five objects that cause the indeterminism: std::map<const Value *, SUnit *> AliasMemDefs, NonAliasMemDefs; std::map<const Value *, std::vector<SUnit

Is there a test case that you can share ? On Jan 29, 2013, at 9:24 AM, Sergei Larin <slarin at codeaurora.org> wrote: > Nadav, > > Thanks for the quick response. By now I am convinced that the given loop > ends up vectorized with enough difference to cause bad things later on, but > I have not found the exact cause yet. To continue with my work I'll have to >

Nadav, Thanks for the quick response. By now I am convinced that the given loop ends up vectorized with enough difference to cause bad things later on, but I have not found the exact cause yet. To continue with my work I'll have to simply turn off vectorization for now, but I will come back and investigate. Again, there is some indeterminism in order of PHIs processing somewhere. I'll

...calculation is repeated on the remaining rows in A. Therefore a smaller and smaller amount of data is analysed as the loop proceeds, since A is losing rows each time. The results of the calculation change as less data is used, but not in a predictable way, therefore the end point of the loop is indeterminate. The script is long and the datasets big, but a simplified example where 'A' and 'B' are datasets, and the function 'ndist2' calculates 'x' is... for (i in 1:100) { C <- data.frame(ndist2(B,A)) C1 <- subset(C, x = min(C$x)) B <- rbind(B, C1) A <- subse...

Hi Sergei, "addRuntimeCheck" inserts code that checks that two or more arrays are disjoint. I looked at the code and it looks fine. We generate PHIs in the order that they appear in a vector. The values are inserted in 'canVectorizeMemory', which also looks fine. Please let me know if you think I missed something. Thanks, Nadav On Jan 29, 2013, at 8:48 AM, Sergei Larin

Has anyone read anything about register allocation being indeterminate? I have seen much literature about "optimal register allocation," but does anyone know a case where it is not? Thanks, Jeff Kunkel

On 9/14/20 9:30 AM, James Y Knight via llvm-dev wrote: > On Mon, Sep 14, 2020 at 3:19 AM László Radnai via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> A problem arises, and I am not sure if it is really a problem or just >> weird C-compliant behavior. >> >> int a; // or, equally, int a=0; >> >> int main(){ >> int b; >> if

...nitialized to poison at object creation. >> p = alloca {i8, i32} // p[0], p[4~7] are poison >> p[0] is an i8, so it shouldn't be poison? > > My interpretation of standard is that reading uninitialized char can also yield trap representation. If uninitialized, char variable has indeterminate value, and C/C++ does not seem to forbid reading trap representation from it. C++14 explicitly has an example that shows it is indeterminate value at 3.3.2.1 : ``` The point of declaration for a name is immediately after its complete declarator (Clause 8) and before its initializer (if any), except...

Nadav, As I peel this onion, it looks like you might know something about InnerLoopVectorizer::addRuntimeCheck. What does it do, and can it be causing the below described issue? Could resuming somehow (indeterministically) switch the order of PHIs in the original code? Thanks a lot. Sergei. --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Hello everybody, I have a case of suspected indeterminism and I would like to verify that it is not a known issue before I dig deep into it. It seems to happen during PreVerifier pass ("Preliminary module verification"). The little I understand/assume about it, a verifier pass is not supposed to change the code (or is it?) but in debug stream I see the following: Common predecessor:

...;unsigned char' > > (doesn't have a trap representation)? > > Nah, C's pretty explicit that using uninitialized locals is undefined > behaviour, regardless of type. From C11 J.2: > > The value of an object with automatic storage duration is used while > it is indeterminate (6.2.4, 6.7.9, 6.8). > > It's also stated in 6.2.4 that "the initial value of the object is > indeterminate." > Reading an indeterminate value isn't UB in C. Even branching on it isn't. > _______________________________________________ > LLVM Developers ma...

Although I tried to find an answer in the manuals and archives, I cannot solve this (please excuse that my English and/or R programming skills are not good enough to state my problem more clearly): I want to write a function with an indeterminate (not pre-defined) number of arguments and think that I should use the "..." construct and the match.call() function. The goal is to write a function that (among other things) uses cbind() to combine a not pre-defined number of vectors specified in the function call. For example, if my...

Dear r-list folks, I have a problem which has been bugging me for a while now and I was hoping someone out there might be able to help. If I have a user-defined function with an indeterminate number of arguments, using the well-known "..." construct, how can I get the function to return the names of the items which were the arguments of the function as part of the function's output? This is easily done where there is a fixed number of arguments: e.g: aa<-c(1,2,3,4,5) b...

...= alloca {i8, i32} // p[0], p[4~7] are poison >>>> p[0] is an i8, so it shouldn't be poison? >>> >>> >> My interpretation of standard is that reading uninitialized char can also >> yield trap representation. >> If uninitialized, char variable has indeterminate value, and C/C++ does >> not seem to forbid reading trap representation from it. >> > Okay, it's just not immediately undefined behaviour. The C model has more > issues because of the problem with how "trap representation" is defined > (which precludes trap repres...

To test some recent changes, I need to verify that seven instructions are generated. However, the order of those instructions doesn't matter (they are all independent loads from memory). Is there a way to tell FileCheck to reset its scan position rather than assuming all CHECK: instructions must be in the given order? My initial version of the test was to use -O0, attempting to ensure that