search for: behaviors

Hello all, I have a question which I have been struggling with for several weeks now, that I think might be easy for more proficient coders than myself. I have a large behavioral dataset, with behaviors and the times (milliseconds) that they occurred. Each subject has a separate file, and a sample subject file can be generated using the following syntax: Time <- c(1000, 1050, 1100, 1500, 2500, 5000, 6500, 6600, 7000) Behavior <- c("g", "a", "s", "5",...

Hi, I'm trying to execute the same R code on multiple data frames listed in a single directory. The code works fine if I use the code (below) for each file. However, I have several files and it becomes tedious to run each one, name it and then aggregate into a single dataframe. Name 0.0           1 21.15       2 2400.26   1 3222.14   2 name = read.table(file.choose(),header=F) #

On Sun, Jul 31, 2011 at 3:04 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > The current memory model section ends with the following discussions: > > "Note that in cases where none of the atomic intrinsics are used, this > model places only one restriction on IR transformations on top of what > is required for single-threaded execution: introducing a store to a

Chris Lattner wrote: > On Feb 8, 2009, at 5:54 PM, Paul Schlie wrote: >> Are overflow behavior tags meant to enable the specification of a >> particular instruction's required or presumed overflow behavior? > > I'm not sure what you mean. The overflow tags specify what happens if > overflow happens (defined wrapping, defined saturating, or undefined > behavior),

...'t > depend on the value of a load, it's okay if it is undef.  This allows, > for example, hoisting loads which are conditionally executed out of > loops. In C++0x, if a program has a data race, then its behavior is undefined. Does the LLVM memory model design define programs' behaviors in the similar ideas? If so, hosting additional loads out of a loop that may not execute at runtime --- say the loop counter is 0, can turn a program from defined to undefined, which makes the later compilations transform the program arbitrarily, since their input programs are undefined. Is it expe...

On 05/30/2013 06:12 AM, Pete Couperus wrote: > Hello, > > This is an interesting example. Whenever I see strange things like > this, I use opt's -lint. > In this case, opt -lint reports: > Undefined behavior: Call return type mismatches callee return type > %call = call float @alias_f32(float %tmp2) #1 > > You'll get a similar report when the parameter types

...bmenu) >> RIGHT ARROW: Enter submenu (or no action if not on a submenu entry) > Considering that there is no "new" proposed action, breaking the > current behavior would be questionable for users that are already > taking advantage of it. > I am not against changing behaviors (sometimes, it is worth), but > IMHO breaking a current behavior has to bring a very _clear_ gain, > while such change should be as less traumatic as possible for current > users. In my opinion, this would be better addressed with a conditional directive than an outright change in current...

...action if not on a submenu entry) >> >> > Considering that there is no "new" proposed action, breaking the >> > current behavior would be questionable for users that are already >> > taking advantage of it. >> >> > I am not against changing behaviors (sometimes, it is worth), but >> > IMHO breaking a current behavior has to bring a very _clear_ gain, >> > while such change should be as less traumatic as possible for current >> > users. >> >> In my opinion, this would be better addressed with a conditional...

...l. Anna. On Aug 10, 2012, at 7:48 PM, Richard Smith wrote: > Hi, > > There are three different (and mostly orthogonal, design-wise) areas where I would like to make improvements to Clang's undefined behavior checking: > > 1) Completeness of checks. There are integer undefined behaviors which -ftrapv and -fcatch-undefined-behavior don't catch, and there is almost no checking available for any other undefined behaviors outside of those and the ones caught by {Address,Thread,Memory} Sanitizer. > > I would like to add support for checking the following additional undefined...

...: Enter submenu (or no action if not on a submenu entry) > > > Considering that there is no "new" proposed action, breaking the > > current behavior would be questionable for users that are already > > taking advantage of it. > > > I am not against changing behaviors (sometimes, it is worth), but > > IMHO breaking a current behavior has to bring a very _clear_ gain, > > while such change should be as less traumatic as possible for current > > users. > > In my opinion, this would be better addressed with a conditional > directive than...

Hi, In our backend, we currently emit add operations that trap on overflow if the IR operation has the nsw flag set. Is this allowed? According to the documentation about poison values, overflowing a nsw add is undefined behavior. However I didn't find a formal definition of undefined behavior in LLVM. Judging from previous discussions on the mailing list, there seems to be a vague

On 2/28/16, Linus Torvalds <torvalds at linux-foundation.org> wrote: > The fact is, undefined compiler behavior is never a good idea. Not for > serious projects. Actually, undefined behavior is essential for serious projects, but not for the reasons mentioned. If the language has no undefined behavior, then from the compiler's view, there is no such thing as a bad program. All

On Dec 16, 2011, at 2:41 PM, John Criswell wrote: > On 12/16/11 4:14 PM, Chris Lattner wrote: >> >> On Dec 16, 2011, at 12:39 PM, Kostya Serebryany wrote: >>> > Do we consider the above transformation legal? >> >> Yes, the transformation is perfectly legal for the normal compiler. > > So how do you guarantee that the behavior is predictable

I would be interested in learning what the set of used semantics for float-to-int conversion is. If the only two used are 1) undefined behavior if unrepresentable and 2) saturate to int_{min,max} with NaN going to zero, then I think it makes sense to expose both of those natively in the IR. If the set is much larger, I think separate intrinsics for each behavior would make sense. It would be nice

Since keystrokes were brought up, this seems like a reasonable time to make the following seemingly simple-to-implement feature request: Navigating a multi-level menu structure seems to require use of UP/DOWN/ENTER/ESC. It would be easier to quickly search/navigate if it could be done with fingers stationed on the arrow keys so that the eyes can stay focused on the screen. Current

Are overflow behavior tags meant to enable the specification of a particular instruction's required or presumed overflow behavior? If a required overflow behavior, then it follows that the target must correspondingly implement the behavior; neither natively or emulated? If a presumed overflow behavior, is the target meant to preferably implement or emulate the same; or is it merely meant to

...ith separate >>> undefs? >> >> The intention is that they should have the same semantics. > > As for whether separating the sequential ``undef'' and the concurrent > ``undef'', there is an analogous problem that is why C defines > different undefined behaviors in term of contexts that result in > undefined behaviors. When designing any analysis tools for C to > prevent undefined behaviors,  we can reason about which kinds of > undefined behaviors can be eliminated. So classifying undefined > behaviors helps at the case. > > In the LLVM...

Hi John, It seems the dereferencing a NULL pointer is undefined behavior but Calling a function through a null pointer seems o.k. If so , for this place, we need comment out the check. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232 look at Notes from the October 2003 meeting. Yin From: John Criswell [mailto:criswell at illinois.edu] Sent: Wednesday,

On 12/16/11 4:45 PM, Chris Lattner wrote: > > On Dec 16, 2011, at 2:41 PM, John Criswell wrote: > >> On 12/16/11 4:14 PM, Chris Lattner wrote: >>> On Dec 16, 2011, at 12:39 PM, Kostya Serebryany wrote: >>>> >>>> > Do we consider the above transformation legal? >>>> >>> >>> Yes, the transformation is perfectly

...sing for some users if the result is "moving to the parent menu". Or at least more confusing than just "moving within the same (sub)menu", as the current behavior. I think that [Esc] is an adequate key to "move to the parent menu from a submenu" (one if its current behaviors), both because of its meaning and because its location on a typical keyboard. Yet, there are cases in which this behavior is less than ideal (to go to the CLI from a submenu, use [Tab] first and then [Esc]). As a workaround (specially when users might not know about the [Esc] behavior or when...