Thanks for your help Nathan. I have added a bugzilla account for you.
Martyn
On Tue, 2017-05-23 at 21:02 +, Nathan Sosnovske via R-devel wrote:
> Hi All,
>
> I have a fix to this bug ( https://bugs.r-project.org/bugzilla3/show_
> bug.cgi?id=16454) and would like to submit a patch to the bug
Hi All,
I have a fix to this bug (
https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16454) and would like to
submit a patch to the bug report on Bugzilla. I'd also like to start going
through some of the other Windows-specific issues and start fixing those. The
bug submission instructions
Feature request:
I want to use update.formula to subtract an intercept (or other) term from a
formula with a dot on the RHS. However, as this causes an error, I propose a
patch below.
Thus, I want:
> update.formula(y ~ ., ~ . -1)
[1] y ~ . - 1
Instead I get this error:
Error in terms.formula(t
On 23/05/2017 11:47 AM, Sahil Kang wrote:
Hi Duncan,
Would you merge this patch?
I'm planning on sending larger patches in the next few days that fix other
macros I've seen, but I figured​ it'd be best to start with a smaller patch.
No, I generally try to leave the macro stuff to others.
Dun
Yes, what Joris posts about is exactly what I noted in my March 9th post to
R-devel. The behaviour is sort of documented, but not in the clearest
manner (in my opinion). Like I say, my ultimate conclusion was that the
silent coercion of numerics to integers by sprintf() was a handy
convenience, but
https://github.com/Rdatatable/data.table/issues/2171
The fix was easy, it's just surprising to see the behavior change almost on
a whim. Just wanted to point it out in case this is unknown behavior, but
Evan seems to have found this as well.
On Tue, May 23, 2017 at 12:00 PM, Michael Chirico wrot
Astute observation. And of course we should be passing integer when we use
%d. It's an edge case in how we printed ITime objects in data.table:
On Tue, May 23, 2017 at 11:53 AM, Joris Meys wrote:
> I initially thought this is "documented behaviour". ?sprintf says:
>
> Numeric variables with __e
I initially thought this is "documented behaviour". ?sprintf says:
Numeric variables with __exactly integer__ values will be coerced to
integer. (emphasis mine).
Turns out this only works when the first value is numeric and not NA, as
shown by the following example:
> sprintf("%d", as.numeric(c(
Hi Duncan,
Would you merge this patch?
I'm planning on sending larger patches in the next few days that fix other
macros I've seen, but I figured​ it'd be best to start with a smaller patch.
Thanks,
Sahil
__
R-devel@r-project.org mailing list
https://
Hi Michael,
I posted something on this topic to R-devel several weeks ago, but never
got a response. My ultimate conclusion is that sprintf() isn't super
consistent in how it handles coercion: sometimes it'll coerce real to
integer without complaint, other times it won't. (My particular email had
> On 23 May 2017, at 15:56 , Joris Meys wrote:
>
> Hi Duncan,
>
> that explains, thank you. If nobody finds the time to fix that, I might
> give it a shot myself this summer. Barbeque is overrated.
I beg to differ! Chances of rain are underestimated, though (in .be as in .dk,
I suspect).
;-
Hi Duncan,
that explains, thank you. If nobody finds the time to fix that, I might
give it a shot myself this summer. Barbeque is overrated.
Cheers
Joris
On Tue, May 23, 2017 at 3:10 PM, Duncan Murdoch
wrote:
> On 23/05/2017 8:39 AM, Joris Meys wrote:
>
>> Hi all,
>>
>> Don't know if this is a
On 23/05/2017 8:39 AM, Joris Meys wrote:
Hi all,
Don't know if this is a known issue, but I couldn't find anything so I
report anyway. When checking eg ?qr in both RStudio and the naked R IDE,
the help page is rendered incorrectly. More specifically, any use of
\bold{...} is printed as is, rathe
Hi all,
Don't know if this is a known issue, but I couldn't find anything so I
report anyway. When checking eg ?qr in both RStudio and the naked R IDE,
the help page is rendered incorrectly. More specifically, any use of
\bold{...} is printed as is, rather than interpreted as bold. Same happens
on
14 matches
Mail list logo
