Peter Dalgaard <[EMAIL PROTECTED]> writes:
> Peter Dalgaard <[EMAIL PROTECTED]> writes:
>
> > Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> >
> > > I've seen many similar things in a report from valgrind. But they
> > > went away when compiled without optimization: it seems optimization
> > >
Peter Dalgaard <[EMAIL PROTECTED]> writes:
> Prof Brian Ripley <[EMAIL PROTECTED]> writes:
>
> > I've seen many similar things in a report from valgrind. But they
> > went away when compiled without optimization: it seems optimization
> > often does a fetch one element off the end of an array wh
Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> I've seen many similar things in a report from valgrind. But they
> went away when compiled without optimization: it seems optimization
> often does a fetch one element off the end of an array when attempting
> to keep the pipelines full.
> I'd st
I've seen many similar things in a report from valgrind. But they went
away when compiled without optimization: it seems optimization often does
a fetch one element off the end of an array when attempting to keep the
pipelines full.
I'd start by re-running the valgrind tests without optimizat
[EMAIL PROTECTED] writes:
> Full_Name: Benjamin Tyner
> Version: 2.1.0, 4/18/2005
> OS: i686-redhat-linux-gnu
> Submission from: (NULL) (4.64.8.220)
>
>
> # Just run my.test() below in a newly opened R session. Once too many models
> have been fit (~20 on my system), the computed standard error
Full_Name: Benjamin Tyner
Version: 2.1.0, 4/18/2005
OS: i686-redhat-linux-gnu
Submission from: (NULL) (4.64.8.220)
# Just run my.test() below in a newly opened R session. Once too many models
have been fit (~20 on my system), the computed standard error jumps to a
different value. This is (superf
