Re: [Rd] Bug in file.access on Windows when using network shares

[Nick Kennedy]

Dear Tomas,

Thanks for your email. This can be easily reproduced if there is access to
a shared folder. I've reproduced this behaviour on both Windows 7 and
Windows 10.

Steps to reproduce:

1. Ensure Offline Files is turned on within Windows
2. Using Windows Explorer, browse to a folder shared on a network using a
UNC path, e.g. \\mypc\myshare\
3. Create a test file, e.g. test.txt
4. Within R, try the following:

file.access("//mypc/myshare/test.txt",0)
# Returns 0
file.access("//mypc/myshare/test.txt",4)
# Returns -1 if the share is on a non-Windows host, 0 if it is on a Windows
host

5. Right click on the file within Windows Explorer and ensure 'always
available offline' is checked.
6. Wait for the sync to take place.
7. Disconnect from the network.
8. Within R, try the same commands again

file.access("//mypc/myshare/test.txt",0)
# Returns 0
file.access("//mypc/myshare/test.txt",4)
# Returns -1 regardless of whether the original host was Windows or
non-Windows

In all cases the file is actually readable.

I've created my own version of winAccessW in extra.c at
https://github.com/NikNakk/r-source/commit/0a82f6d23b8a2ace44e43a28cb6eb923145a13c8

Almost all of the code in here can be replaced with a simple call to
_waccess, other than the check for executable. This seems to work as
expected. Since _waccess exists as a system call within Windows and has the
same syntax (other than wide characters) as access in POSIX, why not use it?

BW

Nick

On 3 July 2018 at 09:21, Tomas Kalibera  wrote:

>
> Dear Nick,
>
> thank you for your report. In general one cannot know reliably in advance
> whether reading a file will work, if nothing else, there are possible race
> conditions with other applications and/or the system (e.g. a service may
> lock the file, move it away temporarily, etc). The only correct way to
> handle errors is try the read and catch errors. Please note there is a
> disclaimer in ?file.access to this effect.
>
> If you still want to report a bug in file.access, please provide an
> example that does not require a package, and provide more details (what do
> you think would be the correct behavior, etc). From looking at the code,
> when winAccessW/GetFileSecurityW fails to retrieve information about the
> file, file.access would signal an error, which seems to be a fine behavior
> for me. It is not surprising to me that in some cases (like working on a
> local copy of a file in a distributed file-system), the OS would not know
> whether a file is readable/writeable before trying out on/syncing the
> distributed version.
>
> Best
> Tomas
>
>
> On 07/03/2018 01:11 AM, Nick Kennedy wrote:
>
>> Dear R-Devel,
>>
>> I've run into an issue with a package (vcfR) that uses file.access to
>> check
>> a file is readable before opening it. The issue is actually in base R
>> though. I've looked into the package code, and it calls file.access(path,
>> mode = 4). I've created a minimal working example of the code in
>> winAccessW
>> from src/gnuwin32/extra.c, and the problem arises when GetFileSecurityW is
>> called on shared files under certain circumstances.
>>
>> One situation I've seen it in are when a file is shared from a non-Windows
>> host (e.g. Linux), which is similar to the situation documented at
>> https://social.msdn.microsoft.com/Forums/sqlserver/en-US/f57
>> 928d3-d89b-426d-a174-d06d97355afc/how-to-check-if-a-
>> filefolder-is-writable-or-not?forum=windowssdk
>> .
>>
>> The other situation arises when a file is cached offline by Windows
>> Offline
>> files feature. The call to GetFileSecurityW works fine when the network is
>> up (and so the file is being accessed from the share), but fails when the
>> network is down and the file is being accessed from the offline files
>> cache.
>>
>> Is there any reason that there is a custom function here? Windows supports
>> the use of access (as is used on other OSes), although the ISO C++
>> _waccess
>> would be preferred. This seems to work well even in situations where the
>> current code does not.
>>
>> BW
>>
>> Nick
>>
>> [[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

Re: [Bioc-devel] Bioconductor package update

[Nathan Lawlor]

Apologies, I meant to say July 2nd, not June 2nd.

On 7/3/18, 11:03 AM, "Nathan Lawlor"  wrote:

>Hi Ahrim,
>
>I forget exactly when the nightly build/check reports occur for
>Bioconductor packages but looking at the BiFET report: (BiFET:
>http://bioconductor.org/checkResults/devel/bioc-LATEST/BiFET/) it looks
>like the build for June 2nd has not yet been updated? So any changes you
>made on June 2nd won’t be reflected just yet
>
>Best,
>Nathan
>
>On 7/3/18, 10:28 AM, "Ahrim Youn"  wrote:
>
>>Dear Martin,
>>
>>Thank you for your answer. I updated the man/ files and bumped the
>>version
>>in the DESCRIPTION file yesterday, but the change is not reflected in the
>>manual of the package.
>>
>>Ahrim
>>
>>On 6/30/18, 11:32 AM, "Martin Morgan" 
>>wrote:
>>
>>>(cc'ing bioc-devel, where questions like this should be posted so other
>>>developers can benefit / contribute)
>>>
>>>I see
>>>
>>>commit 5fea2c1f2e0f3407cb6804db638b565e0a2ea5dd
>>>Author: Ahrim Youn 
>>>Date:   Fri Jun 22 16:34:02 2018 -0400
>>>
>>> update version number
>>>
>>>  DESCRIPTION  |  2 +-
>>>  R/library_function.r | 12 ++--
>>>  2 files changed, 7 insertions(+), 7 deletions(-)
>>>
>>>where you changed the R/ file roxygen comment but did not regenerate the
>>>documentation, I guess with
>>>
>>>   devtools::document()
>>>
>>>The build system does not do this for you. So Update the man/ files and
>>>bump the version.
>>>
>>>Martin
>>>
>>>On 06/30/2018 10:55 AM, Ahrim Youn wrote:
 Hi,
 
 I¹m a maintainer of the package BiFET and I¹m having a problem in
 changing the manual of the package :
 
 
http://bioconductor.org/packages/devel/bioc/manuals/BiFET/man/BiFET.pdf
 
 I changed the comments in the main R function which is linked to the
 manual, and updated it to both github and biocondutor, but the manual
 pdf file does not change.
   What is interesting is that the Vignette which I also updated is
 updating according to my change :
 
 
http://bioconductor.org/packages/devel/bioc/vignettes/BiFET/inst/doc/Bi
F
E
T.html
 
 
 Do you know why the manual pdf file does not update?
 
 Thanks for your help!
 
 Best,
 Ahrim
 ---
 
 The information in this email, including attachments, may be
 confidential and is intended solely for the addressee(s). If you
believe 
 you received this email by mistake, please notify the sender by return
 email as soon as possible.
>>>
>>>
>>>This email message may contain legally privileged and/or confidential
>>>information.  If you are not the intended recipient(s), or the employee
>>>or agent responsible for the delivery of this message to the intended
>>>recipient(s), you are hereby notified that any disclosure, copying,
>>>distribution, or use of this email message is prohibited.  If you have
>>>received this message in error, please notify the sender immediately by
>>>e-mail and delete this email message from your computer. Thank you.
>>
>

---

The information in this email, including attachments, may be confidential and 
is intended solely for the addressee(s). If you believe you received this email 
by mistake, please notify the sender by return email as soon as possible.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Bioconductor package update

[Nathan Lawlor]

Hi Ahrim,

I forget exactly when the nightly build/check reports occur for
Bioconductor packages but looking at the BiFET report: (BiFET:
http://bioconductor.org/checkResults/devel/bioc-LATEST/BiFET/) it looks
like the build for June 2nd has not yet been updated? So any changes you
made on June 2nd won’t be reflected just yet

Best,
Nathan

On 7/3/18, 10:28 AM, "Ahrim Youn"  wrote:

>Dear Martin,
>
>Thank you for your answer. I updated the man/ files and bumped the version
>in the DESCRIPTION file yesterday, but the change is not reflected in the
>manual of the package.
>
>Ahrim
>
>On 6/30/18, 11:32 AM, "Martin Morgan" 
>wrote:
>
>>(cc'ing bioc-devel, where questions like this should be posted so other
>>developers can benefit / contribute)
>>
>>I see
>>
>>commit 5fea2c1f2e0f3407cb6804db638b565e0a2ea5dd
>>Author: Ahrim Youn 
>>Date:   Fri Jun 22 16:34:02 2018 -0400
>>
>> update version number
>>
>>  DESCRIPTION  |  2 +-
>>  R/library_function.r | 12 ++--
>>  2 files changed, 7 insertions(+), 7 deletions(-)
>>
>>where you changed the R/ file roxygen comment but did not regenerate the
>>documentation, I guess with
>>
>>   devtools::document()
>>
>>The build system does not do this for you. So Update the man/ files and
>>bump the version.
>>
>>Martin
>>
>>On 06/30/2018 10:55 AM, Ahrim Youn wrote:
>>> Hi,
>>> 
>>> I¹m a maintainer of the package BiFET and I¹m having a problem in
>>> changing the manual of the package :
>>> 
>>> http://bioconductor.org/packages/devel/bioc/manuals/BiFET/man/BiFET.pdf
>>> 
>>> I changed the comments in the main R function which is linked to the
>>> manual, and updated it to both github and biocondutor, but the manual
>>> pdf file does not change.
>>>   What is interesting is that the Vignette which I also updated is
>>> updating according to my change :
>>> 
>>> 
>>>http://bioconductor.org/packages/devel/bioc/vignettes/BiFET/inst/doc/BiF
>>>E
>>>T.html
>>> 
>>> 
>>> Do you know why the manual pdf file does not update?
>>> 
>>> Thanks for your help!
>>> 
>>> Best,
>>> Ahrim
>>> ---
>>> 
>>> The information in this email, including attachments, may be
>>> confidential and is intended solely for the addressee(s). If you
>>>believe 
>>> you received this email by mistake, please notify the sender by return
>>> email as soon as possible.
>>
>>
>>This email message may contain legally privileged and/or confidential
>>information.  If you are not the intended recipient(s), or the employee
>>or agent responsible for the delivery of this message to the intended
>>recipient(s), you are hereby notified that any disclosure, copying,
>>distribution, or use of this email message is prohibited.  If you have
>>received this message in error, please notify the sender immediately by
>>e-mail and delete this email message from your computer. Thank you.
>

---

The information in this email, including attachments, may be confidential and 
is intended solely for the addressee(s). If you believe you received this email 
by mistake, please notify the sender by return email as soon as possible.
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Bioconductor package update

[Ahrim Youn]

Dear Martin,

Thank you for your answer. I updated the man/ files and bumped the version
in the DESCRIPTION file yesterday, but the change is not reflected in the
manual of the package.

Ahrim

On 6/30/18, 11:32 AM, "Martin Morgan" 
wrote:

>(cc'ing bioc-devel, where questions like this should be posted so other
>developers can benefit / contribute)
>
>I see
>
>commit 5fea2c1f2e0f3407cb6804db638b565e0a2ea5dd
>Author: Ahrim Youn 
>Date:   Fri Jun 22 16:34:02 2018 -0400
>
> update version number
>
>  DESCRIPTION  |  2 +-
>  R/library_function.r | 12 ++--
>  2 files changed, 7 insertions(+), 7 deletions(-)
>
>where you changed the R/ file roxygen comment but did not regenerate the
>documentation, I guess with
>
>   devtools::document()
>
>The build system does not do this for you. So Update the man/ files and
>bump the version.
>
>Martin
>
>On 06/30/2018 10:55 AM, Ahrim Youn wrote:
>> Hi,
>> 
>> I¹m a maintainer of the package BiFET and I¹m having a problem in
>> changing the manual of the package :
>> 
>> http://bioconductor.org/packages/devel/bioc/manuals/BiFET/man/BiFET.pdf
>> 
>> I changed the comments in the main R function which is linked to the
>> manual, and updated it to both github and biocondutor, but the manual
>> pdf file does not change.
>>   What is interesting is that the Vignette which I also updated is
>> updating according to my change :
>> 
>> 
>>http://bioconductor.org/packages/devel/bioc/vignettes/BiFET/inst/doc/BiFE
>>T.html
>> 
>> 
>> Do you know why the manual pdf file does not update?
>> 
>> Thanks for your help!
>> 
>> Best,
>> Ahrim
>> ---
>> 
>> The information in this email, including attachments, may be
>> confidential and is intended solely for the addressee(s). If you
>>believe 
>> you received this email by mistake, please notify the sender by return
>> email as soon as possible.
>
>
>This email message may contain legally privileged and/or confidential
>information.  If you are not the intended recipient(s), or the employee
>or agent responsible for the delivery of this message to the intended
>recipient(s), you are hereby notified that any disclosure, copying,
>distribution, or use of this email message is prohibited.  If you have
>received this message in error, please notify the sender immediately by
>e-mail and delete this email message from your computer. Thank you.

---

The information in this email, including attachments, may be confidential and 
is intended solely for the addressee(s). If you believe you received this email 
by mistake, please notify the sender by return email as soon as possible.

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Rd] Inconsistencies when extracting with non-integer numeric indices near zero

[Emil Bode]

Dear R-devel,

When I was playing around with different kind of indices when subsetting I 
noticed some unexpected behaviours when using non-integer numeric indices, 
especially near zero.
From the docs: “Numeric values are coerced to integer as by 
as.integer (and hence 
truncated towards zero).”
But some behaviour differs from that, and the behaviour also differs between [ 
and [[ :
c(1,2)[as.integer(.5)]   --> numeric(0) # As expected
c(1,2)[.5] --> numeric(0) # As expected
c(1,2)[[as.integer(.5)]]--> Error in c(1, 2)[[as.integer(0.5)]] : 
attempt to select less than one element in integerOneIndex # Also as expected
c(1,2)[[.5]]   --> [1] 1# Not so 
expected
c(1,2)[[1.5]] --> [1] 1# As expected, 
but this also means somevector[[n]] and somevector[[n+1]] give back the same 
element for 0 [1] 2# As would be expected, 
though negative subscript for [[ is of course sketchy
c(1,2)[[-1.5]]--> [1] 1# But coerced to 
-2 is the last thing I’d expect
c(1,2)[as.integer(-.5)] --> numeric(0) # As expected
c(1,2)[-.5]--> [1] 2# Coerced to 
-1?, this also means that length(union(c(1,2)[-n], c(1,2)[n])) != 2 for -1 [1] 2# Again as 
expected, but same problem as before: indexing with n and n+1 can give same 
element back.

I suspect most of this behaviour is due to the case of special treatment of 
zero, where first 0-indices are dropped, and only then the casting to integer 
is done, and when that returns zero some unforeseen behaviour occurs.
Along with using negative indices when extracting with [[, which in any case 
only succeeds with length-2 vectors (We need a length-one index resulting in 
the return of a single element). For the last case I’d think we’d do best in 
throwing an error whenever negative indices are used with [[, but for other 
cases I think we need to change the underlying code, or at the very least 
update documentation.
Any thoughts?

Best regards,
Emil Bode

Data-analyst

+31 6 43 83 89 33
emil.b...@dans.knaw.nl

DANS: Netherlands Institute for Permanent Access to Digital Research Resources
Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 | 
i...@dans.knaw.nl | 
dans.knaw.nl
DANS is an institute of the Dutch Academy KNAW and funding 
organisation NWO.

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Errors from Suggests or Enhances not in mainstream repositories

[Hadley Wickham]

On Tue, Jul 3, 2018 at 5:57 AM, Duncan Murdoch  wrote:
> On 02/07/2018 6:13 PM, Ben Bolker wrote:
>>
>> I got something similar.  I have a few thoughts:
>>
>> (1) you should use  "if (require(citrus)) { ... }" in your examples;
>> "Suggests" and "Enhances" packages are supposed to be *optional*, i.e.
>> examples and tests should be able to run even if they're not installed
>
>
> Nowadays 'if (requireNamespace("citrus")) { ... }' would be preferred in
> tests and examples, along with a 'citrus::' prefix on the objects from that
> package that are needed.  This has milder side effects than `require()`.

And requireNamespace("citrus", quietly = TRUE) is even slightly better
since it avoids one more side-effect ;)

Hadley

-- 
http://hadley.nz

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

Re: [Bioc-devel] About Adding SSH Keys to GitHub Account

[Martin Morgan]

Please be sure to 'reply all' so that others in similar situations can 
benefit.


If you incremented the version but the single package builder did not 
start a build, the most likely reason is because the webhook is not 
correct. See


https://github.com/Bioconductor/Contributions#adding-a-web-hook

See also the 'additional actions' section for hints on debugging the web 
hook.



Martin

On 07/02/2018 10:13 PM, 露崎 弘毅 wrote:

Hi, Martin


Sorry to keep bothering you.


The label "1. awaiting moderation" is changed into "2. review in progress".


bioc-issue-bot tell me that the build results were: "WARNINGS".


I confirm the build report page ( 
http://bioconductor.org/spb_reports/LRBaseDbi_buildreport_20180628070303.html 
), and understand the reason of WARNING, so I modified the part and 
bumped the version (v-0.99.0 → v-0.99.1).



By the way, how the "Bioconductor Single Package Builder" recognizes the 
version of package is updated?



I commited the new version of LRBaseDbi to the GitHub repository ( 
https://github.com/rikenbit/LRBaseDbi ), but it seems that the build 
won't re-run ( https://github.com/Bioconductor/Contributions/issues/787 ).




Thanks,


Koki



*差出人:* Bioc-devel  が 露崎 弘毅 
 の代理で送信

*送信日時:* 2018年6月28日 20:56
*宛先:* Martin Morgan; Bioc-devel@r-project.org
*件名:* Re: [Bioc-devel] About Adding SSH Keys to GitHub Account
Hi, Martin


Thanks for quick reply.

Ok, I'll wait for the review.


Thanks,


Koki



�: Martin Morgan 
: 2018Ҵ6��28�� 19:59
���:  ; Bioc-devel@r-project.org
��٣: Re: [Bioc-devel] About Adding SSH Keys to GitHub Account

Hi Koki --

The 'moderation' step requires a human to actually look at your
repository. Usually it is quick, but sometimes it can take up to a day.
Your package has been moderated and a reviewer assigned to it; further
instructions (basically, wait for up to two weeks while the reviewer
looks at your package in more detail) are in the comment posted to the
issue.

Martin

On 06/27/2018 10:38 PM,   wrote:

Hi, All


I'm trying to submit my R/Bioconductor package by Bioconductor/Contributions

https://github.com/Bioconductor/Contributions/issues/787



LRBaseDbi · Issue #787 · Bioconductor/Contributions 


github.com
Update the following URL to point to the GitHub repository of the 
package you wish to submit to Bioconductor Repository: 
https://github.com/rikenbit/LRBaseDbi Confirm the following by editing 
each ...




[https://avatars3.githubusercontent.com/u/2173745?s=400=4]

LRBaseDbi �� Issue #787 �� 
Bioconductor/Contributions

github.com
Update the following URL to point to the GitHub repository of the 
package you wish to submit to Bioconductor Repository: 
https://github.com/rikenbit/LRBaseDbi Confirm the following by editing 
each ...







The process looks properly going well,

but "1. awaiting moderation" label is added,

because the message says

"Add SSH keys to your GitHub account."



Actually, I still added some SSH keys to GitHub.


Is this caused by my some mistake,

or is this caused by the difference between organization account "rikenbit" and my 
account "kokitsuyuzaki"?


Or do I have to wait for the process for some hours?



Koki Tsuyuzaki


    [[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel




This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee 
or agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have 
received this message in error, please notify the sender immediately by 
e-mail and delete this email message from your computer. Thank you.


     [[alternative HTML version deleted]]




This email message may contain legally privileged and/or...{{dropped:2}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [R-pkg-devel] Errors from Suggests or Enhances not in mainstream repositories

[Duncan Murdoch]

On 02/07/2018 6:13 PM, Ben Bolker wrote:

I got something similar.  I have a few thoughts:

(1) you should use  "if (require(citrus)) { ... }" in your examples;
"Suggests" and "Enhances" packages are supposed to be *optional*, i.e.
examples and tests should be able to run even if they're not installed


Nowadays 'if (requireNamespace("citrus")) { ... }' would be preferred in 
tests and examples, along with a 'citrus::' prefix on the objects from 
that package that are needed.  This has milder side effects than 
`require()`.


Duncan Murdoch

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

Re: [R-pkg-devel] Errors from Suggests or Enhances not in mainstream repositories

[Duncan Murdoch]

On 02/07/2018 4:18 PM, Throm, Allison wrote:

Hi all,


I'm trying to submit a package to the CRAN that further examines results from the 
"citrus" package as done for an accepted publication (available on Github: 
).


I do not get any errors when using devtools::check() on my Mac, which already has the 
citrus package installed. However, I am getting errors during the CRAN submission 
check 
.


I've tried searching Stack Overload and other CRAN packages with 
Additional_repositories fields, but none of the applicable solutions have worked. I'm 
pretty sure it's the loading of the citrus package that is causing the error and have 
added the Additional_repositories field with a link the package on Github, but still 
haven't been able to resolve the issue. There are very specific installation 
instructions for the package 
, which may be 
contributing to issues.


How should I properly specify dependencies on the 
nolanlab/citrus Github package for my CRAN 
package?


I don't think you posted your DESCRIPTION file, but the likely problem 
based on the check log is that your "Additional_repositories" field 
points to something that CRAN doesn't recognize as an R package repository.


Probably the easiest way to create the right structure is to use the 
drat package; see  https://github.com/eddelbuettel/drat  for instructions.


Duncan Murdoch

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

Re: [Rd] base::mean not consistent about NA/NaN

[Barry Rowlingson]

On Tue, Jul 3, 2018 at 10:12 AM, Jan Gorecki  wrote:
> Thank you for interesting examples.
> I would find useful to document this behavior also in `?mean`, while `+`
> operator is also affected, the `sum` function is not.

`sum` is "affected" on my system, if you mean:

> sum(c(NA,NaN))
[1] NA
> sum(c(NaN,NA))
[1] NaN

oh, maybe you mean:

> sum(NaN, NA)
[1] NA
> sum(NA, NaN)
[1] NA

But whatever, no money back guarantee:

 Computations involving ‘NaN’ will return ‘NaN’ or perhaps ‘NA’:
 which of those two is not guaranteed and may depend on the R
 platform (since compilers may re-order computations).

> For mean, NA / NaN could be handled in loop in summary.c. I assume that
> performance penalty of fix is the reason why this inconsistency still
> exists.
> Jan
>
> On Mon, Jul 2, 2018 at 8:28 PM, Barry Rowlingson
>  wrote:
>>
>> And for a starker example of this (documented) inconsistency,
>> arithmetic addition is not commutative:
>>
>>  > NA + NaN
>>  [1] NA
>>  > NaN + NA
>>  [1] NaN
>>
>>
>>
>> On Mon, Jul 2, 2018 at 5:32 PM, Duncan Murdoch 
>> wrote:
>> > On 02/07/2018 11:25 AM, Jan Gorecki wrote:
>> >> Hi,
>> >> base::mean is not consistent in terms of handling NA/NaN.
>> >> Mean should not depend on order of its arguments while currently it is.
>> >
>> > The result of mean() can depend on the order even with regular numbers.
>> > For example,
>> >
>> >  > x <- rep(c(1, 10^(-15)), 100)
>> >  > mean(sort(x)) - 0.5
>> > [1] 5.551115e-16
>> >  > mean(rev(sort(x))) - 0.5
>> > [1] 0
>> >
>> >
>> >>
>> >>  mean(c(NA, NaN))
>> >>  #[1] NA
>> >>  mean(c(NaN, NA))
>> >>  #[1] NaN
>> >>
>> >> I created issue so in case of no replies here status of it can be
>> >> looked up
>> >> at:
>> >> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17441
>> >
>> > The help page for ?NaN says,
>> >
>> > "Computations involving NaN will return NaN or perhaps NA: which of
>> > those two is not guaranteed and may depend on the R platform (since
>> > compilers may re-order computations)."
>> >
>> > And ?NA says,
>> >
>> > "Numerical computations using NA will normally result in NA: a possible
>> > exception is where NaN is also involved, in which case either might
>> > result (which may depend on the R platform). "
>> >
>> > So I doubt if this inconsistency will be fixed.
>> >
>> > Duncan Murdoch
>> >
>> >>
>> >> Best,
>> >> Jan
>> >>
>> >>   [[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
>
>

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

Re: [Rd] base::mean not consistent about NA/NaN

[Jan Gorecki]

Thank you for interesting examples.
I would find useful to document this behavior also in `?mean`, while `+`
operator is also affected, the `sum` function is not.
For mean, NA / NaN could be handled in loop in summary.c. I assume that
performance penalty of fix is the reason why this inconsistency still
exists.
Jan

On Mon, Jul 2, 2018 at 8:28 PM, Barry Rowlingson <
b.rowling...@lancaster.ac.uk> wrote:

> And for a starker example of this (documented) inconsistency,
> arithmetic addition is not commutative:
>
>  > NA + NaN
>  [1] NA
>  > NaN + NA
>  [1] NaN
>
>
>
> On Mon, Jul 2, 2018 at 5:32 PM, Duncan Murdoch 
> wrote:
> > On 02/07/2018 11:25 AM, Jan Gorecki wrote:
> >> Hi,
> >> base::mean is not consistent in terms of handling NA/NaN.
> >> Mean should not depend on order of its arguments while currently it is.
> >
> > The result of mean() can depend on the order even with regular numbers.
> > For example,
> >
> >  > x <- rep(c(1, 10^(-15)), 100)
> >  > mean(sort(x)) - 0.5
> > [1] 5.551115e-16
> >  > mean(rev(sort(x))) - 0.5
> > [1] 0
> >
> >
> >>
> >>  mean(c(NA, NaN))
> >>  #[1] NA
> >>  mean(c(NaN, NA))
> >>  #[1] NaN
> >>
> >> I created issue so in case of no replies here status of it can be
> looked up
> >> at:
> >> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17441
> >
> > The help page for ?NaN says,
> >
> > "Computations involving NaN will return NaN or perhaps NA: which of
> > those two is not guaranteed and may depend on the R platform (since
> > compilers may re-order computations)."
> >
> > And ?NA says,
> >
> > "Numerical computations using NA will normally result in NA: a possible
> > exception is where NaN is also involved, in which case either might
> > result (which may depend on the R platform). "
> >
> > So I doubt if this inconsistency will be fixed.
> >
> > Duncan Murdoch
> >
> >>
> >> Best,
> >> Jan
> >>
> >>   [[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
>

[[alternative HTML version deleted]]

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

Re: [Rd] Bug in file.access on Windows when using network shares

[Tomas Kalibera]

Dear Nick,

thank you for your report. In general one cannot know reliably in 
advance whether reading a file will work, if nothing else, there are 
possible race conditions with other applications and/or the system (e.g. 
a service may lock the file, move it away temporarily, etc). The only 
correct way to handle errors is try the read and catch errors. Please 
note there is a disclaimer in ?file.access to this effect.


If you still want to report a bug in file.access, please provide an 
example that does not require a package, and provide more details (what 
do you think would be the correct behavior, etc). From looking at the 
code, when winAccessW/GetFileSecurityW fails to retrieve information 
about the file, file.access would signal an error, which seems to be a 
fine behavior for me. It is not surprising to me that in some cases 
(like working on a local copy of a file in a distributed file-system), 
the OS would not know whether a file is readable/writeable before trying 
out on/syncing the distributed version.


Best
Tomas

On 07/03/2018 01:11 AM, Nick Kennedy wrote:

Dear R-Devel,

I've run into an issue with a package (vcfR) that uses file.access to check
a file is readable before opening it. The issue is actually in base R
though. I've looked into the package code, and it calls file.access(path,
mode = 4). I've created a minimal working example of the code in winAccessW
from src/gnuwin32/extra.c, and the problem arises when GetFileSecurityW is
called on shared files under certain circumstances.

One situation I've seen it in are when a file is shared from a non-Windows
host (e.g. Linux), which is similar to the situation documented at
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/f57928d3-d89b-426d-a174-d06d97355afc/how-to-check-if-a-filefolder-is-writable-or-not?forum=windowssdk
.

The other situation arises when a file is cached offline by Windows Offline
files feature. The call to GetFileSecurityW works fine when the network is
up (and so the file is being accessed from the share), but fails when the
network is down and the file is being accessed from the offline files cache.

Is there any reason that there is a custom function here? Windows supports
the use of access (as is used on other OSes), although the ISO C++ _waccess
would be preferred. This seems to work well even in situations where the
current code does not.

BW

Nick

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