similar to: Possible bug in apply()

Hi, I am trying to create a table with information from Shapiro Wilk's test of normality. However, it fails due to lack of sample size, it says, but the way I see it, this is not a problem. (See the table of sample sizes (almost) at the bottom). Applying a different function using a similar ftable call is not a problem (See the bottom table). This is R 2.1.0 on Linux (Gentoo). /Fredrik

On Wed, 2008-03-26 at 23:48 +0100, Óscar Fuentes wrote: > "Jonathan S. Shapiro" <shap at eros-os.com> writes: > My front-end is very similar to yours in the feature of the multiple > instantiations on demand, etc. Oscar: after you have a chance to read my recent reply to Gordon, would you be kind enough to let me know whether you still believe the situations are similar.

Owen: Can you clarify what kinds of dynamic linker issues you are seeing? I speculate that cross-library dependency resolution is high on the list, but what else? shap On Tue, 2008-05-13 at 21:44 -0500, Owen Anderson wrote: > On May 13, 2008, at 9:22 PM, Jonathan S. Shapiro wrote: > > Owen: > > > > This is not correct. As the API stabilizes, it will become > >

On May 13, 2008, at 10:12 PM, Jonathan S. Shapiro wrote: > Owen: > > Can you clarify what kinds of dynamic linker issues you are seeing? I > speculate that cross-library dependency resolution is high on the > list, > but what else? > > shap Others could probably answer it better (this was before my time), but my understanding was that certain versions of certain

On Wed, 2008-03-26 at 11:02 -0700, Chris Lattner wrote: > On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > > I want to background process this for a bit, but it would be helpful to > > discuss some approaches first. > > > > There would appear to be three approaches: > > > > 1. Introduce a CC register class into the IR. This seems to be a > >

On Wed, 2008-03-26 at 14:11 -0700, Chris Lattner wrote: > On Wed, 26 Mar 2008, Jonathan S. Shapiro wrote: > >> Why not define an "add with overflow" intrinsic that returns its value and > >> overflow bit as an i1? > > > > Chris: > > > > I understand several simple ways to implement add with carry. Your > > suggestion is one of them. What

"Jonathan S. Shapiro" <shap at eros-os.com> writes: [snip] > 4. Is there a better/cleaner approach? What other options should I > consider? My front-end is very similar to yours in the feature of the multiple instantiations on demand, etc. One thing I learnt about LLVM is that it's philosophy is to be a friendly backend for frontends, but whatever your frontend

On Apr 4, 2008, at 11:58 AM, Jonathan S. Shapiro wrote: > In general, it is not possible to know jitted code size without > emitting. You can suppress the actual write of the instructions > themselves, but you have to do all of the work prior to that point. That's not true. llvm targets which support JIT have all the information necessary to calculate the size of every

> Message: 5 > Date: Mon, 26 Jan 2009 21:47:12 -0500 > From: "Jonathan S. Shapiro" <shap at eros-os.com> > Subject: [LLVMdev] PPC calling convention -- how to provide an > environment pointer? > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Message-ID: <1233024432.24380.11.camel at vmx> > Content-Type: text/plain > > This is

I was re-reading the specification for extractelement and friends, and I notice that the index is restricted to i32. Since vectors might clearly have a larger number of elements on 64-bit platforms, I wonder if I am misunderstanding the intended use of these instructions. Is this indeed intended for vector and structure access in general, or is intended to support (only) more specialized SIMD

On Thu, 2008-04-17 at 10:49 -0700, Chris Lattner wrote: > On Thu, 17 Apr 2008, guan mailist wrote: > > Does anyone have good ideas to dynamically measure the stack size of a > > program by using LLVM. > > I am trying to add some new intrinsic functions after each "alloca" in > > bitcode. Is it a good way to do it? > > Any existing tools can help me to do

On Wed, 7 May 2008, Jonathan S. Shapiro wrote: > On Wed, 2008-05-07 at 16:09 -0700, Chris Lattner wrote: >> On Wed, 7 May 2008, Jonathan S. Shapiro wrote: >>>> >>>> i64 should be big enough for this. Just use i64. >>> >>> On a 32-bit platform, doesn't one want to use i32? >> >> Why? What is wrong with i64? > > On its face,

On May 14, 2008, at 10:46 AM, Jonathan S. Shapiro wrote: > On Wed, 2008-05-14 at 23:23 +0900, Neil Booth wrote: >> Jonathan S. Shapiro wrote:- >>> Is there a requirement somewhere in the C *Language* Specification >>> that >>> ties all of this together in the required way? >> >> Reserved identifiers and header inclusion. >> >> Neil.

On Wed, 2008-05-14 at 13:26 -0400, David Vandevoorde wrote: > On May 14, 2008, at 10:46 AM, Jonathan S. Shapiro wrote: > > On Wed, 2008-05-14 at 23:23 +0900, Neil Booth wrote: > >> Jonathan S. Shapiro wrote:- > >>> Is there a requirement somewhere in the C *Language* Specification > >>> that > >>> ties all of this together in the required

On Wed, 2008-05-14 at 23:23 +0900, Neil Booth wrote: > Jonathan S. Shapiro wrote:- > > Is there a requirement somewhere in the C *Language* Specification that > > ties all of this together in the required way? > > Reserved identifiers and header inclusion. > > Neil. What section of the C standard do I need to refresh myself on here?

On Thu, 2008-03-27 at 21:39 +0200, Pertti Kellomäki wrote: > Except that some aspects of the host platform leak through > to .bc files. This may or may not be a problem. A question about this occurred to me last night. BitC has only one machine-dependent type: word. The current runtime.h file typedef's this in a machine-dependent way, but all of the C code emitted by our current back

In alloca, is it required that NumElements be a literal integer, or can it be a computed result? The real question is whether the current IR can support a one-stack implementation of Ada's dynamically sized stack frames. shap

On Wed, 2008-05-07 at 16:09 -0700, Chris Lattner wrote: > On Wed, 7 May 2008, Jonathan S. Shapiro wrote: > >> > >> i64 should be big enough for this. Just use i64. > > > > On a 32-bit platform, doesn't one want to use i32? > > Why? What is wrong with i64? On its face, the problem is that it doesn't fit in a native register... or is there something

In general, it is not possible to know jitted code size without emitting. You can suppress the actual write of the instructions themselves, but you have to do all of the work prior to that point. The reason is that on many architectures there are span-dependent branches. The final instruction size depends on the branch span. The span depends on the code size, and the code size depends on the

I have a client who might well make use of an AVR32 port, but I suspect that machine is very different than the one you are currently examining. shap On Mon, 2008-05-19 at 12:38 -0600, John Regehr wrote: > Anyone else interested in an AVR backend? > > If so, for what members of the AVR family? If we do a port, likely it'll > support only the ATmegas. > > John >