search for: behavioral

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", "...

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),

On Sun, Jul 31, 2011 at 7:11 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > 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

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

On Thu, Sep 11, 2014 at 4:09 PM, Ady <ady-sf at hotmail.com> wrote: >> 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 >>

On Sat, Sep 13, 2014 at 11:34 AM, Ady <ady-sf at hotmail.com> wrote: > >> On Thu, Sep 11, 2014 at 4:09 PM, Ady <ady-sf at hotmail.com> wrote: >> >> >> Since keystrokes were brought up, this seems like a reasonable time to >> >> make the following seemingly simple-to-implement feature request: >> >> >> >> Navigating a

Richard, I think adding the runtime undefined behavior checking and unifying the diagnostic output format is a great idea. This would probably be of interest to the LLVM Dev list as well. 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

> On Thu, Sep 11, 2014 at 4:09 PM, Ady <ady-sf at hotmail.com> wrote: > > >> 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

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

On Mon, Aug 22, 2011 at 8:46 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > On Mon, Aug 22, 2011 at 6:08 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Mon, Aug 22, 2011 at 2:49 PM, Santosh Nagarakatte >> <santosh.nagarakatte at gmail.com> wrote: >>> Hi all, >>> >>> I have been trying to understand the use of undef in

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

> 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