[Rd] What happened to Ross Ihaka's proposal for a Common Lisp based R successor?

[Andrew Judson]

I read this paper
 and
haven't been able to find out what happened - I have seen some sporadic
mention in message groups but nothing definitive. Does anyone know?

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] What happened to Ross Ihaka's proposal for a Common Lisp based R successor?

[peter dalgaard]

On 05 Aug 2016, at 06:41 , Andrew Judson  wrote:

> I read this paper
>  and
> haven't been able to find out what happened - I have seen some sporadic
> mention in message groups but nothing definitive. Does anyone know?

Presumably Ross does...

You get a hint if you go one level up and look for the newest file:

https://www.stat.auckland.ac.nz/~ihaka/downloads/New-System.pdf


-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] What happened to Ross Ihaka's proposal for a Common Lisp based R successor?

[Kenny Bell]

Why is the described system preferable to Julia?

On Fri, Aug 5, 2016, 4:50 AM peter dalgaard  wrote:

>
> On 05 Aug 2016, at 06:41 , Andrew Judson  wrote:
>
> > I read this paper
> >  and
> > haven't been able to find out what happened - I have seen some sporadic
> > mention in message groups but nothing definitive. Does anyone know?
>
> Presumably Ross does...
>
> You get a hint if you go one level up and look for the newest file:
>
> https://www.stat.auckland.ac.nz/~ihaka/downloads/New-System.pdf
>
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk  Priv: pda...@gmail.com
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] findInterval(all.inside=TRUE) for degenerate 'vec' arguments

[Martin Maechler]

> William Dunlap via R-devel 
> on Thu, 4 Aug 2016 15:20:57 -0700 writes:

> What should findInterval(x,vec,all.inside=TRUE) return when 
length(vec)<=1,
> so there are no inside intervals?

> R-3.3.0 gives a decreasing map of x->output when length(vec)==1 and -1's
> when length(vec)==0.  Would '0' in all those cases be better?

Yes.  '0' would be according to the documentation,
and if you dig all the way down to the C part
(originally created via f2c (!)),
you'll notice that the -1
are really  from  'n - 1'  where n == 0 here ... a case that was
not even possible in the very original (Fortran!) code.

I'll commit a fix to the source
Martin

--
Martin Maechler
ETH Zurich /  R Core Team


>> findInterval(x=c(10, 11, 12), vec=11, all.inside=TRUE,
> rightmost.closed=FALSE, left.open=FALSE)
> [1] 1 0 0
>> findInterval(x=c(10, 11, 12), vec=11, all.inside=TRUE,
> rightmost.closed=FALSE, left.open=TRUE)
> [1] 1 1 0
>> findInterval(x=c(10, 11, 12), vec=11, all.inside=TRUE,
> rightmost.closed=TRUE, left.open=FALSE)
> [1] 1 0 0
>> findInterval(x=c(10, 11, 12), vec=11, all.inside=TRUE,
> rightmost.closed=TRUE, left.open=TRUE)
> [1] 1 1 0
>> 
>> findInterval(x=c(10, 11, 12), vec=numeric(), all.inside=TRUE,
> rightmost.closed=FALSE, left.open=FALSE)
> [1] -1 -1 -1
>> findInterval(x=c(10, 11, 12), vec=numeric(), all.inside=TRUE,
> rightmost.closed=FALSE, left.open=TRUE)
> [1] -1 -1 -1
>> findInterval(x=c(10, 11, 12), vec=numeric(), all.inside=TRUE,
> rightmost.closed=TRUE, left.open=FALSE)
> [1] -1 -1 -1
>> findInterval(x=c(10, 11, 12), vec=numeric(), all.inside=TRUE,
> rightmost.closed=TRUE, left.open=TRUE)
> [1] -1 -1 -1

> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com

> [[alternative HTML version deleted]]

> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] What happened to Ross Ihaka's proposal for a Common Lisp based R successor?

[Hadley Wickham]

When it was being actively worked on, it had the advantage of existing.

Hadley

On Fri, Aug 5, 2016 at 10:48 AM, Kenny Bell  wrote:
> Why is the described system preferable to Julia?
>
> On Fri, Aug 5, 2016, 4:50 AM peter dalgaard  wrote:
>
>>
>> On 05 Aug 2016, at 06:41 , Andrew Judson  wrote:
>>
>> > I read this paper
>> >  and
>> > haven't been able to find out what happened - I have seen some sporadic
>> > mention in message groups but nothing definitive. Does anyone know?
>>
>> Presumably Ross does...
>>
>> You get a hint if you go one level up and look for the newest file:
>>
>> https://www.stat.auckland.ac.nz/~ihaka/downloads/New-System.pdf
>>
>>
>> --
>> Peter Dalgaard, Professor,
>> Center for Statistics, Copenhagen Business School
>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
>> Phone: (+45)38153501
>> Office: A 4.23
>> Email: pd@cbs.dk  Priv: pda...@gmail.com
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
http://hadley.nz

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] What happened to Ross Ihaka's proposal for a Common Lisp based R successor?

[Kenny Bell]

Is it conceivable that Julia could be ported to use R syntax in a way that
would allow the vastly larger numbers of R programmers to seamlessly
switch? Or equivalently, could an iteration of R itself do this?

On Fri, Aug 5, 2016, 9:00 AM Hadley Wickham  wrote:

> When it was being actively worked on, it had the advantage of existing.
>
> Hadley
>
> On Fri, Aug 5, 2016 at 10:48 AM, Kenny Bell  wrote:
> > Why is the described system preferable to Julia?
> >
> > On Fri, Aug 5, 2016, 4:50 AM peter dalgaard  wrote:
> >
> >>
> >> On 05 Aug 2016, at 06:41 , Andrew Judson  wrote:
> >>
> >> > I read this paper
> >> > 
> and
> >> > haven't been able to find out what happened - I have seen some
> sporadic
> >> > mention in message groups but nothing definitive. Does anyone know?
> >>
> >> Presumably Ross does...
> >>
> >> You get a hint if you go one level up and look for the newest file:
> >>
> >> https://www.stat.auckland.ac.nz/~ihaka/downloads/New-System.pdf
> >>
> >>
> >> --
> >> Peter Dalgaard, Professor,
> >> Center for Statistics, Copenhagen Business School
> >> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> >> Phone: (+45)38153501
> >> Office: A 4.23
> >> Email: pd@cbs.dk  Priv: pda...@gmail.com
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
> http://hadley.nz
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Extra copies of objects in environments when using $ operator?

[Winston Chang]

My understanding is that R will not make copies of lists if there is
only one reference to the object. However, I've encountered a case
where R does make copies, even though (I think) there should be only
one reference to the object. I hope that someone could shed some light
on why this is happening.

I'll start with a simple example. Below, x is a list with one element,
and changing that element doesn't result in a copy. (We know this
because nothing is printed when we do the assignment after the
tracemem call.) This is as expected.
  x <- list(1)
  tracemem(x)
  # [1] "<0x1149e08f8>"
  x[[1]] <- 2
  # (No output)

Similarly, modifying a list contained in a list doesn't result in a copy:
  e <- list(x = list(1))
  tracemem(e$x)
  # [1] "<0x11b3a4b38>"
  e$x[[1]] <- 2
  # (No output)

However, modifying a list contained in an environment *does* result in
a copy -- tracemem prints out some info when we do the assignment:
  e <- new.env(parent = emptyenv())
  e$x <- list(1)
  tracemem(e$x)
  # [1] "<0x1148c1708>"
  e$x[[1]] <- 2
  # tracemem[0x1148c1708 -> 0x11b2fc1b8]:


This is surprising to me. Why is a copy made in this case? It also
results in slower performance for these situations.

The most that I've been able to figure out is that it probably has
something to do with how the $ operator works with environments (but
not with lists). If you do the same operations without the $ operator,
by evaluating code in environment e, then no copy is made:

  e <- new.env(parent = globalenv())
  eval(quote({
x <- list(1)
tracemem(x)
x[[1]] <- 2
  }), envir = e)
  # (No output)


I'd appreciate it if someone could shed light on this. And if it's a
bug, that would be good to know too.

-Winston

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Extra copies of objects in environments when using $ operator?

[luke-tierney]

On Fri, 5 Aug 2016, Winston Chang wrote:


My understanding is that R will not make copies of lists if there is
only one reference to the object. However, I've encountered a case
where R does make copies, even though (I think) there should be only
one reference to the object. I hope that someone could shed some light
on why this is happening.

I'll start with a simple example. Below, x is a list with one element,
and changing that element doesn't result in a copy. (We know this
because nothing is printed when we do the assignment after the
tracemem call.) This is as expected.
 x <- list(1)
 tracemem(x)
 # [1] "<0x1149e08f8>"
 x[[1]] <- 2
 # (No output)

Similarly, modifying a list contained in a list doesn't result in a copy:
 e <- list(x = list(1))
 tracemem(e$x)
 # [1] "<0x11b3a4b38>"
 e$x[[1]] <- 2
 # (No output)

However, modifying a list contained in an environment *does* result in
a copy -- tracemem prints out some info when we do the assignment:
 e <- new.env(parent = emptyenv())
 e$x <- list(1)
 tracemem(e$x)
 # [1] "<0x1148c1708>"
 e$x[[1]] <- 2
 # tracemem[0x1148c1708 -> 0x11b2fc1b8]:


Currently e$x marks values as immutable if they have any references by
setting NAMED to 2. You can see this with


e <- new.env(parent = emptyenv())
e$x <- list(1)
.Internal(inspect(e))

@30b2498 04 ENVSXP g0c0 [NAM(1)] <0x30b2498>
ENCLOS:
  @2600e98 04 ENVSXP g0c0 [MARK,NAM(2)] 
HASHTAB:
  @2e41540 19 VECSXP g0c7 [] (len=29, tl=1)
@25c9628 00 NILSXP g0c0 [MARK,NAM(2)]
@25c9628 00 NILSXP g0c0 [MARK,NAM(2)]
@25c9628 00 NILSXP g0c0 [MARK,NAM(2)]
@25c9628 00 NILSXP g0c0 [MARK,NAM(2)]
@30b3370 02 LISTSXP g0c0 []
  TAG: @2637870 01 SYMSXP g0c0 [MARK,NAM(2)] "x"
  @3569488 19 VECSXP g0c1 [NAM(1)] (len=1, tl=0)   ## <--- NAM = 1
  @35694e8 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 1
...

e$x

[[1]]
[1] 1


.Internal(inspect(e))

@30b2498 04 ENVSXP g0c0 [NAM(1)] <0x30b2498>
ENCLOS:
  @2600e98 04 ENVSXP g0c0 [MARK,NAM(2)] 
HASHTAB:
  @2e41540 19 VECSXP g0c7 [] (len=29, tl=1)
@25c9628 00 NILSXP g0c0 [MARK,NAM(2)]
@25c9628 00 NILSXP g0c0 [MARK,NAM(2)]
@25c9628 00 NILSXP g0c0 [MARK,NAM(2)]
@25c9628 00 NILSXP g0c0 [MARK,NAM(2)]
@30b3370 02 LISTSXP g0c0 []
  TAG: @2637870 01 SYMSXP g0c0 [MARK,NAM(2)] "x"
  @3569488 19 VECSXP g0c1 [NAM(2)] (len=1, tl=0)   ## <--- NAM = 2
  @35694e8 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 1
...

It is not clear if this is needed or just done in an abundance of
caution. If R is built to use reference counting for determining
sharing information this does not happen, so this is likely to change
and not force a copy by 3.4.0.

Best,

luke


This is surprising to me. Why is a copy made in this case? It also
results in slower performance for these situations.

The most that I've been able to figure out is that it probably has
something to do with how the $ operator works with environments (but
not with lists). If you do the same operations without the $ operator,
by evaluating code in environment e, then no copy is made:

 e <- new.env(parent = globalenv())
 eval(quote({
   x <- list(1)
   tracemem(x)
   x[[1]] <- 2
 }), envir = e)
 # (No output)


I'd appreciate it if someone could shed light on this. And if it's a
bug, that would be good to know too.

-Winston

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
   Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] What happened to Ross Ihaka's proposal for a Common Lisp based R successor?

[Hadley Wickham]

No.

Hadley

On Fri, Aug 5, 2016 at 11:12 AM, Kenny Bell  wrote:
> Is it conceivable that Julia could be ported to use R syntax in a way that
> would allow the vastly larger numbers of R programmers to seamlessly switch?
> Or equivalently, could an iteration of R itself do this?
>
>
> On Fri, Aug 5, 2016, 9:00 AM Hadley Wickham  wrote:
>>
>> When it was being actively worked on, it had the advantage of existing.
>>
>> Hadley
>>
>> On Fri, Aug 5, 2016 at 10:48 AM, Kenny Bell  wrote:
>> > Why is the described system preferable to Julia?
>> >
>> > On Fri, Aug 5, 2016, 4:50 AM peter dalgaard  wrote:
>> >
>> >>
>> >> On 05 Aug 2016, at 06:41 , Andrew Judson  wrote:
>> >>
>> >> > I read this paper
>> >> > 
>> >> > and
>> >> > haven't been able to find out what happened - I have seen some
>> >> > sporadic
>> >> > mention in message groups but nothing definitive. Does anyone know?
>> >>
>> >> Presumably Ross does...
>> >>
>> >> You get a hint if you go one level up and look for the newest file:
>> >>
>> >> https://www.stat.auckland.ac.nz/~ihaka/downloads/New-System.pdf
>> >>
>> >>
>> >> --
>> >> Peter Dalgaard, Professor,
>> >> Center for Statistics, Copenhagen Business School
>> >> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
>> >> Phone: (+45)38153501
>> >> Office: A 4.23
>> >> Email: pd@cbs.dk  Priv: pda...@gmail.com
>> >>
>> >> __
>> >> R-devel@r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>> >>
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>
>> --
>> http://hadley.nz



-- 
http://hadley.nz

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Extra copies of objects in environments when using $ operator?

[Winston Chang]

>
>
>> However, modifying a list contained in an environment *does* result in
>> a copy -- tracemem prints out some info when we do the assignment:
>>  e <- new.env(parent = emptyenv())
>>  e$x <- list(1)
>>  tracemem(e$x)
>>  # [1] "<0x1148c1708>"
>>  e$x[[1]] <- 2
>>  # tracemem[0x1148c1708 -> 0x11b2fc1b8]:
>>
>
> Currently e$x marks values as immutable if they have any references by
> setting NAMED to 2. You can see this with
>
> e <- new.env(parent = emptyenv())
>> e$x <- list(1)
>> .Internal(inspect(e))
>>
> @30b2498 04 ENVSXP g0c0 [NAM(1)] <0x30b2498>
> ENCLOS:
>   @2600e98 04 ENVSXP g0c0 [MARK,NAM(2)] 
> HASHTAB:
>   @2e41540 19 VECSXP g0c7 [] (len=29, tl=1)
> @25c9628 00 NILSXP g0c0 [MARK,NAM(2)]
> @25c9628 00 NILSXP g0c0 [MARK,NAM(2)]
> @25c9628 00 NILSXP g0c0 [MARK,NAM(2)]
> @25c9628 00 NILSXP g0c0 [MARK,NAM(2)]
> @30b3370 02 LISTSXP g0c0 []
>   TAG: @2637870 01 SYMSXP g0c0 [MARK,NAM(2)] "x"
>   @3569488 19 VECSXP g0c1 [NAM(1)] (len=1, tl=0)   ## <--- NAM = 1
>   @35694e8 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 1
> ...
>
>> e$x
>>
> [[1]]
> [1] 1
>
> .Internal(inspect(e))
>>
> @30b2498 04 ENVSXP g0c0 [NAM(1)] <0x30b2498>
> ENCLOS:
>   @2600e98 04 ENVSXP g0c0 [MARK,NAM(2)] 
> HASHTAB:
>   @2e41540 19 VECSXP g0c7 [] (len=29, tl=1)
> @25c9628 00 NILSXP g0c0 [MARK,NAM(2)]
> @25c9628 00 NILSXP g0c0 [MARK,NAM(2)]
> @25c9628 00 NILSXP g0c0 [MARK,NAM(2)]
> @25c9628 00 NILSXP g0c0 [MARK,NAM(2)]
> @30b3370 02 LISTSXP g0c0 []
>   TAG: @2637870 01 SYMSXP g0c0 [MARK,NAM(2)] "x"
>   @3569488 19 VECSXP g0c1 [NAM(2)] (len=1, tl=0)   ## <--- NAM = 2
>   @35694e8 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 1
> ...
>
> It is not clear if this is needed or just done in an abundance of
> caution. If R is built to use reference counting for determining
> sharing information this does not happen, so this is likely to change
> and not force a copy by 3.4.0.
>

Excellent, that's great to hear!

-Winston

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] What happened to Ross Ihaka's proposal for a Common Lisp based R successor?

[Ista Zahn]

But you can easily fall back to R from within Julia; see
http://juliastats.github.io/RCall.jl/latest/

On Aug 5, 2016 1:27 PM, "Hadley Wickham"  wrote:

> No.
>
> Hadley
>
> On Fri, Aug 5, 2016 at 11:12 AM, Kenny Bell  wrote:
> > Is it conceivable that Julia could be ported to use R syntax in a way
> that
> > would allow the vastly larger numbers of R programmers to seamlessly
> switch?
> > Or equivalently, could an iteration of R itself do this?
> >
> >
> > On Fri, Aug 5, 2016, 9:00 AM Hadley Wickham  wrote:
> >>
> >> When it was being actively worked on, it had the advantage of existing.
> >>
> >> Hadley
> >>
> >> On Fri, Aug 5, 2016 at 10:48 AM, Kenny Bell  wrote:
> >> > Why is the described system preferable to Julia?
> >> >
> >> > On Fri, Aug 5, 2016, 4:50 AM peter dalgaard  wrote:
> >> >
> >> >>
> >> >> On 05 Aug 2016, at 06:41 , Andrew Judson  wrote:
> >> >>
> >> >> > I read this paper
> >> >> >  2008.pdf>
> >> >> > and
> >> >> > haven't been able to find out what happened - I have seen some
> >> >> > sporadic
> >> >> > mention in message groups but nothing definitive. Does anyone know?
> >> >>
> >> >> Presumably Ross does...
> >> >>
> >> >> You get a hint if you go one level up and look for the newest file:
> >> >>
> >> >> https://www.stat.auckland.ac.nz/~ihaka/downloads/New-System.pdf
> >> >>
> >> >>
> >> >> --
> >> >> Peter Dalgaard, Professor,
> >> >> Center for Statistics, Copenhagen Business School
> >> >> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> >> >> Phone: (+45)38153501
> >> >> Office: A 4.23
> >> >> Email: pd@cbs.dk  Priv: pda...@gmail.com
> >> >>
> >> >> __
> >> >> R-devel@r-project.org mailing list
> >> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >> >>
> >> >
> >> > [[alternative HTML version deleted]]
> >> >
> >> > __
> >> > R-devel@r-project.org mailing list
> >> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >>
> >>
> >> --
> >> http://hadley.nz
>
>
>
> --
> http://hadley.nz
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] What happened to Ross Ihaka's proposal for a Common Lisp based R successor?

[Tim Keitt]

My latest project in R + Rcpp + RcppParallel + RcppEigen ran so fast when I
tested it, I thought it was a short-circuit. Not as clean as pure Julia but
if you like C++ its a pretty sweet environment.

(Incidentally, several of the ideas in Julia came from a discussion about
rewriting R I had with Viral many years ago. Its nice to see them come to
life.)

THK

On Fri, Aug 5, 2016 at 12:41 PM Ista Zahn  wrote:

> But you can easily fall back to R from within Julia; see
> http://juliastats.github.io/RCall.jl/latest/
>
> On Aug 5, 2016 1:27 PM, "Hadley Wickham"  wrote:
>
> > No.
> >
> > Hadley
> >
> > On Fri, Aug 5, 2016 at 11:12 AM, Kenny Bell  wrote:
> > > Is it conceivable that Julia could be ported to use R syntax in a way
> > that
> > > would allow the vastly larger numbers of R programmers to seamlessly
> > switch?
> > > Or equivalently, could an iteration of R itself do this?
> > >
> > >
> > > On Fri, Aug 5, 2016, 9:00 AM Hadley Wickham 
> wrote:
> > >>
> > >> When it was being actively worked on, it had the advantage of
> existing.
> > >>
> > >> Hadley
> > >>
> > >> On Fri, Aug 5, 2016 at 10:48 AM, Kenny Bell 
> wrote:
> > >> > Why is the described system preferable to Julia?
> > >> >
> > >> > On Fri, Aug 5, 2016, 4:50 AM peter dalgaard 
> wrote:
> > >> >
> > >> >>
> > >> >> On 05 Aug 2016, at 06:41 , Andrew Judson  wrote:
> > >> >>
> > >> >> > I read this paper
> > >> >> >  > 2008.pdf>
> > >> >> > and
> > >> >> > haven't been able to find out what happened - I have seen some
> > >> >> > sporadic
> > >> >> > mention in message groups but nothing definitive. Does anyone
> know?
> > >> >>
> > >> >> Presumably Ross does...
> > >> >>
> > >> >> You get a hint if you go one level up and look for the newest file:
> > >> >>
> > >> >> https://www.stat.auckland.ac.nz/~ihaka/downloads/New-System.pdf
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Peter Dalgaard, Professor,
> > >> >> Center for Statistics, Copenhagen Business School
> > >> >> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> > >> >> Phone: (+45)38153501
> > >> >> Office: A 4.23
> > >> >> Email: pd@cbs.dk  Priv: pda...@gmail.com
> > >> >>
> > >> >> __
> > >> >> R-devel@r-project.org mailing list
> > >> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> > >> >>
> > >> >
> > >> > [[alternative HTML version deleted]]
> > >> >
> > >> > __
> > >> > R-devel@r-project.org mailing list
> > >> > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >>
> > >>
> > >>
> > >> --
> > >> http://hadley.nz
> >
> >
> >
> > --
> > http://hadley.nz
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Will there be 2016 issues of The R Journal?

[Gordon K Smyth]

The R Journal home page doesn't make any promises about how frequently the 
journal will be published.  Historically, though, there have been issues in 
June and December of each year.  The June issue has always appeared by this 
time (6 August) in previous years.


Has there been a change in the publication schedule?  Are there still plans 
for a June 2016 issue?


Thanks
Gordon

-
Professor Gordon K Smyth,
Head, Bioinformatics Division,
Walter and Eliza Hall Institute of Medical Research,
http://www.statsci.org/smyth
__

The information in this email is confidential and intended solely for the 
addressee.
You must not disclose, forward, print or use it without the permission of the 
sender.
__
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Will there be 2016 issues of The R Journal?

[Achim Zeileis]

On Sat, 6 Aug 2016, Gordon K Smyth wrote:

The R Journal home page doesn't make any promises about how frequently 
the journal will be published.  Historically, though, there have been 
issues in June and December of each year.  The June issue has always 
appeared by this time (6 August) in previous years.


Has there been a change in the publication schedule?  Are there still 
plans for a June 2016 issue?


As far as I know there has been no change and the first 2016 issue is 
planned to come out later this month. But for more details it would 
probably be best to contact the editors: 
https://journal.R-project.org/board.html


Best,
Z


Thanks
Gordon

-
Professor Gordon K Smyth,
Head, Bioinformatics Division,
Walter and Eliza Hall Institute of Medical Research,
http://www.statsci.org/smyth
__

The information in this email is confidential and intended solely for the 
addressee.
You must not disclose, forward, print or use it without the permission of the 
sender.

__
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] vector finalizers

[frederik]

Dear R Devel,

In a thread this morning Luke Tierney mentioned that R's way of
garbage collecting is going to change soon in 3.4.0. I couldn't find
this info on Google but I wanted to share what I had been discussing
in another forum, in case now is not too late to raise considerations
which could affect the design of planned changes to R's garbage
collection facilities.

I ran into a problem when trying to get R to quickly load some vectors
from disk. R should be able to do this efficiently using memory
mapping. There is a package 'ff' which implements efficient loading of
disk-based vectors using memory mapping. It works pretty well, but the
problem is that it creates a separate data type - the vectors are not
"native" R vectors. There are some wrapper functions in a package
'ffbase' which allow people to use common functions like 'sum' on
these 'ff' vectors. However, a new wrapper has to be written for every
such function, and I guess the 'ffbase' authors do not have time to
write wrappers that are as efficient as the native R functions - in my
testing, there was a 10x slow-down for 'sum'.

The situation is a bit wistful because an 'ff' vector and a native R
vector are basically the same data type, they both store elements
contiguously in memory. Apparently, what prevents 'ffbase' and 'ff'
from creating native R vectors is the fact that it is impossible to
assign a "finalizer" to a native R vector. We need a finalizer so that
R can tell us when a vector is being freed, so we can unmap the
associated memory/file. Ffbase maintainer Edwin de Jonge was even
skeptical that CRAN would accept a package implementing the hack I had
proposed to simulate native R vectors from mmap'ed 'ff' vectors. The
issue is discussed here:

https://github.com/edwindj/ffbase/issues/52

Of course, weak references and external pointers allow finalizers to
be assigned to objects, but as I understand it, such objects are
separate types from vectors - there is no way in R to synthesize a
native vector endowed with a finalizer - something which could be
passed directly to built-in functions like 'sum'.

I think a finalizer facility for vectors would be useful because it
would allow us to take advantage of the memory mapping architecture
present in all modern processors, to do fast copy-free operations on
large disk-based data structures, without having to re-implement
internal functions like 'sum' which are essentially the same algorithm
no matter where the data is stored.

Thank you,

Frederick

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel