Re: [Rd] FastR
Dear all, at UseR! 2013, the FastR project was announced by Tomas Kalibera, Petr Maj, and Jan Vitek. FastR is an implementation of the R programming language in Java using AST interpretation and specialisation for improved performance. Since, the implementation has been extended to support JIT compilation, leading to performance improvements. The goal of the project is to further the R community and its success by hoping to make the R language even higher-level and faster to meet continually evolving challenges. The implementation currently lacks many of R's features, such as data frames, S3/S4, packages, graphics, ..., but it is growing. At this time, FastR is a collaborative effort of Purdue University, Johannes-Kepler-University Linz, and Oracle Labs. Contributions in all possible forms - tests, code, bug fixes, design hints, criticism - are very welcome! I would like to point the R developers to the FastR project page, now on BitBucket: https://bitbucket.org/allr. The project mailing list is at https://groups.yahoo.com/neo/groups/fastr/info. Best regards, Michael Haupt -- Dr. Michael Haupt Principal Member of Technical Staff Phone: +49 331 200 7277, Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14, 14467 Potsdam, Germany __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] FastR
Hello, Am 13.02.2014 um 15:24 schrieb Qiang Kou : > It will be really wonderful if R can run on JVM. thank you. :-) There are actually two currently available execution models for FastR. 1. Run atop a stock JVM: the JVM will run FastR's Truffle-based AST interpreter like a normal Java application. 2. Run atop GraalVM, which is a HotSpot VM where the Graal dynamic compiler is employed instead of the usual C1/C2 JIT compilers. The advantage of running on GraalVM is that the VM knows about Truffle, and will partially evaluate Truffle ASTs and generate machine code from them, leading to much better performance. When built from the BitBucket repository, the default execution model is #2. > So you moved from github (https://github.com/allr/fastr) to BitBucket ? Yes, as the internal infrastructure we're using is 100 % Mercurial. Best regards, Michael Haupt -- Dr. Michael Haupt Principal Member of Technical Staff Phone: +49 331 200 7277, Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14, 14467 Potsdam, Germany __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] cummax / cummin for complex numbers
Dear all, in R 3.1.0, this is happening: > cummin(c(1+1i,2-3i,4+5i)) Error in cummin(c(1 + (0+1i), 2 - (0+3i), 4 + (0+5i))) : 'cummax' not defined for complex numbers > cummax(c(1+1i,2-3i,4+5i)) Error in cummax(c(1 + (0+1i), 2 - (0+3i), 4 + (0+5i))) : 'cummin' not defined for complex numbers It may be fixed in R-devel, but I thought I'd mention it to make sure ... Best, Michael -- Dr. Michael Haupt Principal Member of Technical Staff Phone: +49 331 200 7277, Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14, 14467 Potsdam, Germany __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cummax / cummin for complex numbers
.. spot on. :-) Apologies for not having been more "pointy" about the problem - this just confirms it *is* kind of subtle. :-) Best, Michael Am 14.07.2014 um 17:18 schrieb Duncan Temple Lang : > I believe Michael's point is that the error messages > are incorrect - referring to cunmax when cunmin was called > and vice verse. > > D. > > On 7/14/14, 8:14 AM, Ben Bolker wrote: >> Michael Haupt oracle.com> writes: >> >>> >>> Dear all, >>> >>> in R 3.1.0, this is happening: >>> >>>> cummin(c(1+1i,2-3i,4+5i)) >>> Error in cummin(c(1 + (0+1i), 2 - (0+3i), 4 + (0+5i))) : >>> 'cummax' not defined for complex numbers >>>> cummax(c(1+1i,2-3i,4+5i)) >>> Error in cummax(c(1 + (0+1i), 2 - (0+3i), 4 + (0+5i))) : >>> 'cummin' not defined for complex numbers >>> >>> It may be fixed in R-devel, but I thought I'd mention it to make sure ... >>> >>> Best, >>> >>> Michael >> >> Well, it is documented in the development version: >> >> x: a numeric or complex (not ‘cummin’ or ‘cummax’) object, or an >> object that can be coerced to one of these. >> >> I imagine the problem is in coming up with a good, consistent definition >> of the min/max for complex numbers: would you prefer min/max modulus, >> phase, real part, imaginary part ... ? max()/min() aren't even defined >> for complex numbers in R ... -- Dr. Michael Haupt Principal Member of Technical Staff Phone: +49 331 200 7277, Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14, 14467 Potsdam, Germany __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] `*tmp*`
Hello, given that `*tmp*` is removed after a replacement, how can code like this work? Is there some special handling for a variable named `*tmp*` when it comes to make element assignments? > x<-c(1,2) > x[1]<-42 > `*tmp*`[1]<-7 # I would expect this one to fail > `*tmp*` Error: object '*tmp*' not found Confused greetings, Michael -- Dr. Michael Haupt Principal Member of Technical Staff Phone: +49 331 200 7277, Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14, 14467 Potsdam, Germany __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] `*tmp*`
Hi Luke,
Am 14.08.2014 um 12:08 schrieb luke-tier...@uiowa.edu:
> This is a consequence of the tricks the interpreter implementation
> currently plays to do complex assignments. Compiled code works
> differently:
>
>> library(compiler)
>> cmpfun(function() {
> +x<-c(1,2)
> +x[1]<-42
> +`*tmp*`[1]<-7 # I would expect this one to fail
> + })()
> Error in cmpfun(function() { : object '*tmp*' not found
aha, thank you very much! So the behaviour of the AST and bytecode interpreters
differ. Which one is authoritative? Can I cherry-pick? (I'll pick the bytecode
interpreter's version if I may.)
Is there actually any code out there that *uses* `*tmp*` and would hence break
if the bytecode interpreter was used? Is it encouraged to not directly access
`*tmp*`?
I'm asking all these questions because, in FastR, we're currently quite closely
mirroring the AST interpreter's behaviour for complex assignments - if this is
not an absolute must-have, I'd be very happy about being able to apply a much
leaner implementation instead.
Best,
Michael
--
Dr. Michael Haupt
Principal Member of Technical Staff
Phone: +49 331 200 7277, Fax: +49 331 200 7561
Oracle Labs
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14, 14467 Potsdam, Germany
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] negative numerics in []
Hello, I'm a bit puzzled by what looks (to me) like a discrepancy between documentation and implementation. The documentation for [] says this about the indices: "Numeric values are coerced to integer as by as.integer (and hence truncated towards zero)." > as.integer(-3.1) [1] -3 Good. But: > x <- c(1,2,3) > x[-3.1] [1] 1 2 3 Given the documentation, I'd have expected a result of "[1] 1 2", because -3.1 should be coerced to -3 (by virtue of as.integer). What bit do I not get? (I'm using R 3.1.1, if that matters.) Best, Michael -- Dr. Michael Haupt Principal Member of Technical Staff Phone: +49 331 200 7277, Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14, 14467 Potsdam, Germany __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
