[Rd] RFC: make as.difftime more consistent or convenient
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] RFC: make as.difftime more consistent or convenient
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
[Rd] Bug report: POSIX regular expression doesn't match for somewhat higher values of upper bound
Dear Sirs,
while
> regexpr('(.{1,2})\\1', 'foo')
[1] 2
attr(,"match.length")
[1] 2
attr(,"useBytes")
[1] TRUE
yields the correct match, an incremented upper bound in
> regexpr('(.{1,3})\\1', 'foo')
[1] -1
attr(,"match.length")
[1] -1
attr(,"useBytes")
[1] TRUE
incorrectly yields no match.
R versions tested:
2.11.1 on i486-pc-linux-gnu
2.15.1 on x86_64-pc-linux-gnu
3.2.1 on i386-w64-mingw32
3.2.1 on x86_64-w64-mingw32
3.3.3 on x86_64-w64-mingw32
--
Best regards,
Dietmar Schindler
manroland web systems GmbH -- Managing Director: Alexander Wassermann
Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No.: 26816 --
VAT: DE281389840
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] Bug report: POSIX regular expression doesn't match for somewhat higher values of upper bound
> Von: Martin Maechler [mailto:maech...@stat.math.ethz.ch]
> Gesendet: Mittwoch, 5. April 2017 11:15
>
> >
> > on Tue, 4 Apr 2017 08:45:30 + writes:
>
> > Dear Sirs,
> > while
>
> >> regexpr('(.{1,2})\\1', 'foo')
> > [1] 2
> > attr(,"match.length")
> > [1] 2
> > attr(,"useBytes")
> > [1] TRUE
>
> > yields the correct match, an incremented upper bound in
>
> >> regexpr('(.{1,3})\\1', 'foo')
> > [1] -1
> > attr(,"match.length")
> > [1] -1
> > attr(,"useBytes")
> > [1] TRUE
>
> > incorrectly yields no match.
>
> Hmm, yes, I would also say that this is incorrect
> (though I'm always cautious: The ?regex help page explicitly
> mentions greedy repetitions, and these can "bite you" ..)
>
> The behavior is also different from the perl=TRUE one which is
> correct (according to the above understanding).
>
> ...
Shouldn't this be submitted on R's Bugzilla then (which I as a non-member
can't)?
--
Best regards,
Dietmar Schindler
manroland web systems GmbH -- Managing Director: Alexander Wassermann
Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No.: 26816 --
VAT: DE281389840
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
