Re: [Rd] RFC: make as.difftime more consistent or convenient

2018-07-31 Thread dietmar.schindler
Hello!

you, Emil Bode , wrote on Tuesday, July 31, 2018 1:55 
PM:
> Some of the changes you're proposing could be made (with effort), but note 
> that you're not
> restricted to providing strings with a format.
> What you're trying to do can be accomplished with as.difftime(12, 
> units='weeks'), see also
> ?as.difftime
>
> Or if you're stuck with the strings: as.difftime(as.numeric(substring('12 w', 
> 1, 2)),
> units='weeks')
> That also seems clearer, because in your script, the last part of your string 
> simply gets
> ignored: as.difftime("12 h", "%H") reads your string for something that 
> satisfies %H (which
> 12 does), then stops:
> as.difftime("12 hours and 17 minutes", "%H") gives 12 hours. If you wanted to 
> check, you
> could have used as.difftime("12 h", "%H h")

Thank you for your comments! But, what you wrote is known. What do you want to 
express with regard to my questions?

I wrote:
> … there is no appropriate format ...,
> although "weeks" is a legitimate unit of 'difftime':
>
> > as.difftime("12 w", "%...")
>
> 1. What do you think about making the behavior of 'as.difftime' more 
> consistent by
> accepting also formats for "days" and "weeks"?
>
> 2. Even more convenient it could be if 'as.difftime' accepted strings 
> containing
> magnitude and unit; how about:
>
> > as.difftime("12 weeks")
> Time difference of 12 weeks

I'm asking for comments in order to get feedback whether it would be 
well-received if I proposed or provided the former or the latter change on 
Bugzilla.
--
Best regards,
Dietmar Schindler

manroland web systems NewCo GmbH | Managing Director: Alexander Wassermann
Registered Office: Augsburg | Trade Register: AG Augsburg | HRB-No.: 32609 | 
VAT: DE815764857

Confidentiality note:
This eMail and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the intended recipient, you are hereby notified that any use or 
dissemination of this communication is strictly prohibited. If you have 
received this eMail in error, then please delete this eMail.

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


Re: [Rd] help building very old R

2018-07-31 Thread peter dalgaard
[Oops, I seem to have managed not to send this yesterday...]

Not sure how to fix, but note that configure is not lying to you:

> configure:13319: /usr/include/tk8.3/tk.h: No such file or directory

tk8.3, not tcl8.3

-pd

> On 30 Jul 2018, at 06:35 , David Hugh-Jones  wrote:
> 
> Hi guys,
> 
> Perhaps someone here can help.
> 
> I am trying to build versions of R 1 for the rcheology package (just
> arrived on CRAN).
> 
> For R prior to 1.5.0, I cannot configure support for tcl-tk.
> 
> I am building on Debian Woody (provided by Docker debian/eol) and have the
> following packages installed:
> r-base-dev tclx8.3-dev tk8.3-dev xvfb xbase-clients x-window-system-core
> 
> I download R source from http://cran.r-project.org/src/base/R-1 and run
> 
> ./configure --with-tcl-tk=yes
> --with-tcl-config=/usr/lib/tcl8.3/tclConfig.sh
>  --with-tk-config=/usr/lib/tk8.3/tkConfig.sh
> 
> These are the locations for the relevant tkConfig.sh and tclConfig.sh files.
> This gives output as follows:
> 
> R is now configured for x86_64-unknown-linux-gnu
> 
>  Source directory:  .
>  Installation directory:/usr/local
> 
>  C compiler:gcc  -g -O2
>  C++ compiler:  c++  -g -O2
>  FORTRAN compiler:  g77  -g -O2
>  X11 support:   yes
>  Gnome support: no
>  Tcl/Tk support:no
>  R profiling support:   yes
>  R as a shared library: no
> 
> And config.log reveals:
> configure:13099: checking for /usr/lib/tcl8.3/tclConfig.sh
> configure:13134: checking for /usr/lib/tk8.3/tkConfig.sh
> configure:13204: checking for /usr/include/tcl8.3/tcl.h
> configure:13214: gcc -E -I/usr/local/include conftest.c >/dev/null
> 2>conftest.out
> configure:13313: checking for /usr/include/tk8.3/tk.h
> configure:13323: gcc -E -I/usr/local/include -I/usr/X11R6/include
> -I/usr/include
> /tcl8.3 conftest.c >/dev/null 2>conftest.out
> configure:13319: /usr/include/tk8.3/tk.h: No such file or directory
> configure: failed program was:
> #line 13318 "configure"
> #include "confdefs.h"
> #include 
> configure:13348: checking for /usr/include/tk.h
> configure:13358: gcc -E -I/usr/local/include -I/usr/X11R6/include
> -I/usr/include
> /tcl8.3 conftest.c >/dev/null 2>conftest.out
> configure:13354: /usr/include/tk.h: No such file or directory
> configure: failed program was:
> #line 13353 "configure"
> #include "confdefs.h"
> #include 
> configure:13385: checking for tk.h
> configure:13389: tk.h: No such file or directory
> 
> In fact, tk.h is in  /usr/include/tcl8.3/ , despite the failed program
> compilation report.
> 
> R 1.5.0 and above work fine. Can anyone remember far back, if something
> changed in the configure script?
> 
> Alternatively, those who are feeling brave can download the Docker image
> creation scripts from github.com/hughjonesd/rcheology .
> 
> Cheers,
> 
> David
> -- 
> Sent from Gmail Mobile
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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


[Rd] RFC: make as.difftime more consistent or convenient

2018-07-31 Thread dietmar.schindler
Hello!

I notice I can convert strings containing hour, minute or second specifications 
to a 'difftime':

> as.difftime("12 h", "%H")
Time difference of 12 hours
> as.difftime("12 m", "%M")
Time difference of 12 mins
> as.difftime("12 s", "%S")
Time difference of 12 secs

But I can't do so with a week specification, because there is no appropriate 
format ..., although "weeks" is a legitimate unit of 'difftime':

> as.difftime("12 w", "%...")

1. What do you think about making the behavior of 'as.difftime' more consistent 
by accepting also formats for "days" and "weeks"?

2. Even more convenient it could be if 'as.difftime' accepted strings 
containing magnitude and unit; how about:

> as.difftime("12 weeks")
Time difference of 12 weeks

--
Regards,
Dietmar Schindler

manroland web systems NewCo GmbH | Managing Director: Alexander Wassermann
Registered Office: Augsburg | Trade Register: AG Augsburg | HRB-No.: 32609 | 
VAT: DE815764857

Confidentiality note:
This eMail and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the intended recipient, you are hereby notified that any use or 
dissemination of this communication is strictly prohibited. If you have 
received this eMail in error, then please delete this eMail.

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


Re: [Rd] Code Optimization: print.data.frame + as.data.frame(head(x, n = options("max.print")))

2018-07-31 Thread Martin Maechler
> Juan Telleria Ruiz de Aguirre 
> on Tue, 31 Jul 2018 08:19:33 +0200 writes:

> I polished a little bit more the function:
> * Used:  getOption("max.print")
> * Added comment at the end:  cat('[ reached getOption("max.print") --
> omitted ', omitted,' rows ]')

> I polished a little bit more the function:

> * Used:  getOption("max.print")
> * Added comment at the end:  cat('[ reached getOption("max.print") --
> omitted ', omitted,' rows ]')

and before

 > I would like to propose a simple optimization for print.data.frame
 > base function:
 > 
 > To add: x <- as.data.frame(head(x, n = options("max.print")))
 > 
 > This would prevent that, if for example, we have a 10GB data.frame
 > (e.g.: Instead of a data.table), and we accidentally print it, the R
 > Session does not "collapse", forcing us to press ESC or kill the
 > RSession.

Thank you, Juan.
You are right: The whole idea of introducing the 'max.print'
option (and the corresponding 'max' argument in print.default()
   {and print.Date() currently })
was that print() ing should not use too much resources.

and you are also right to use 'max.print' .. but R should be as
functional a language as sensible, and hence print()
should be getting an argument 'max' which by default is equal to
the "max.print" option.

Also, any good citizen print() method *must* return its argument invisibly.
==> you are not supposed to change 'x' here.

But I entirely agree with your basic intuition for the problem
resolution.  Very good, thank you, indeed!

I'm currently running 'make check-all'  with the following change
to the source code (aka "patch") :

===
--- src/library/base/R/dataframe.R  (revision 75016)
+++ src/library/base/R/dataframe.R  (working copy)
@@ -1477,7 +1477,7 @@
 
 print.data.frame <-
 function(x, ..., digits = NULL, quote = FALSE, right = TRUE,
-row.names = TRUE)
+row.names = TRUE, max = NULL)
 {
 n <- length(row.names(x))
 if(length(x) == 0L) {
@@ -1489,12 +1489,19 @@
print.default(names(x), quote = FALSE)
cat(gettext("<0 rows> (or 0-length row.names)\n"))
 } else {
+   if(is.null(max)) max <- getOption("max.print", 9L)
## format.<*>() : avoiding picking up e.g. format.AsIs
-   m <- as.matrix(format.data.frame(x, digits = digits, na.encode = FALSE))
+   omit <- (n0 <- max %/% length(x)) < n
+   m <- as.matrix(
+   format.data.frame(if(omit) x[seq_len(n0), , drop=FALSE] else x,
+ digits = digits, na.encode = FALSE))
if(!isTRUE(row.names))
dimnames(m)[[1L]] <-
if(isFALSE(row.names)) rep.int("", n) else row.names
print(m, ..., quote = quote, right = right)
+   if(omit)
+   cat(" [ reached 'max' / getOption(\"max.print\") -- omitted",
+   n - n0, "rows ]\n")
 }
 invisible(x)
 }

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