search for: stringent

...are checking the results against a "golden file" output > computed with fp-contract=off. > IMHO the most sensible solution is to continue checking those tests > with the same flag > as at the time when the reference output has been recorded. We don't want to lose the more-stringent test coverage just because that no longer might be the default mode. We'll also want, where practical, some looser test mode that will work regardless of the FP contraction setting. Both are important. -Hal > > Thanks, > Sebastian > ______________________________________________...

Thanks a lot for pointing out the reason (and yes, I am testing quite to stringent in this case - it's my old testing disease ;-) For other readers: The R-devel NEWS is a good source to find possible change reasons: https://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html On Sun, 2019-09-29 at 08:33 -0400, Duncan Murdoch wrote: > On 29/09/2019 7:55 a.m., nospam at alt...

...code ] ... } ) Thus if rs is an instance of an rstream object one can a random sample of size 10 using rstream.sample(rs, 10) for a sample of size 1 one can use equivalently rstream.sample(rs,1) rstream.sample(rs) however, with R-devel the above construct does not work any more, due to more stringent checkings. It can be fixed by replacing it by if(!isGeneric("rstream.sample")) setGeneric("rstream.sample", function(stream,n) standardGeneric("rstream.sample")) setMethod("rstream.sample", c("rstream","numeric"), func...

...tches I neglected to send out instructions on how to get patches into the LLVM 3.0 branch. All patches must be approved by the code owners (http://llvm.org/docs/DeveloperPolicy.html#owners). Please CC me on all emails for patches you want in. I may not catch them otherwise. Code owners, please be stringent about which patches you accept. Please approve only those patches that are critical for the release. I'm no longer accepting new features into 3.0. I will accept patches for features which were turned on before the 3.0 branch, if they are absolutely necessary and have gone through at least one...

....05 which is quite conservative (i.e., very likely none of the tested genes will be ranked as differentially expressed at 5% FDR). I would argue that for an exploratory study it would be okay to use a 0.05 < FDR <0.20. So, I was wondering if we can change that default of FDR=0.0.5 with a less stringent FDR value (0.10, 0.20, etc.) in the "topTable" function. How do I change it? Thanks a lot for the help on the use of "topTable" function from the LIMMA package. Roger Roger L. Vallejo, Ph.D. Computational Biologist & Geneticist U.S. Department of Agricultur...

Hi, I have a failing unit test in my package tryCatchLog on the CRAN build infrastructure (https://cran.r-project.org/web/checks/check_results_tryCatchLog.html) with "R Under development (unstable) (2019-09-27 r77229)" and the unit tests just ensures consistent behaviour of R (not of my package) as a precondition: The failing unit test is caused by >

...en is shared through Samba. I wish to know the possible disadvantages of this solution. Does the above conflict of permission bits occur in this case. 3.Does any other solution exist? Is it possible to somehow map the SMB protocol with NFS protocol,(because the SMB protocol is more stringent than NFS protocol). regards, nac ?

...ummary(1:5) Min. 1st Qu. Median Mean 3rd Qu. Max. 1 2 3 3 4 5 > summary(c(1:5,NA)) Min. 1st Qu. Median Mean 3rd Qu. Max. NA's 1 2 3 3 4 5 1 Wouldn't it be more stringent if "NA's" was also reported in the first case?? Regards S?ren

....xx.144:53943 [0]: command MAIL: Destroy Apr 6 12:02:08 mail dovecot: submission(user at host.com)<14972><ko4tJitpt9JYSSSC>: Debug: smtp-server: conn 22.73.xx.144:53943 [0]: command MAIL; 501 reply: Destroy Is there a chance that you will incorporate a fix (be more compatible but less stringent)? Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20180406/2a961864/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application...

...eglected to send out instructions on how to get patches into the LLVM 3.0 branch. All patches must be approved by the code owners (http://llvm.org/docs/DeveloperPolicy.html#owners). Please CC me on all emails for patches you want in. I may not catch them otherwise. > > Code owners, please be stringent about which patches you accept. Please approve only those patches that are critical for the release. I'm no longer accepting new features into 3.0. I will accept patches for features which were turned on before the 3.0 branch, if they are absolutely necessary and have gone through at least one...

A package I have written makes considerable use of external C code. There appear to be no problems building a Windows binary with the GNU C compiler, but now I would like to make the package available for other platforms. A stringent check of the code with the gcc options '-Wall -pedantic' flags many nested functions and variable-length arrays that are not allowed in ISO C. Is it essential that distributed C source code for R packages conforms to ISO C in this respect? I'm working in Windows XP with R2.9.2 and Rto...

...s not possible, since we don't have S-plus code; but it is also not desirable in the cases where S's pretty() is funny. However, with more experiments and thought, it ought to be possible to come quite close to S's behavior. But I don't want to spend that extra time if there are no stringent reasons.. Martin Maechler <maechler@stat.math.ethz.ch> <>< Seminar fuer Statistik, ETH-Zentrum SOL G1; Sonneggstr.33 ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND phone: x-41-1-632-3408 fax: ...-1086 http://www.stat.math.ethz.ch/~maechler/ -.-.-.-.-.-.-.-.-.-.-.-.-.-.-....

...I guess that methods for 'summary' and all other R base generics, written in a package as I did it and attached with the library command would have the same problem in R-devel 4.0. I did not try it. My questions are now: (1) Is action required or is it a bug in 4.0? (2) Should I be more stringent, for e.g. using special directives in the NAMESPACE file of the package? I did not. (3) Should I change to S4? For e.g. Bioconductor package CGHbase (Mark van de Wiel) contains S4 plot-methods for its objects. For whom it may be interesting the URL of my Bioconductor package: http://bioconductor...

...he most paranoid organisation might overlook regular checking of permissions on the files/directories found under SSH_AUTH_SOCK 3/ ssh and sshd, do a really good job of totally ignoring id_???/identity/authorized_keys etc if the permissions aren't absolutely as required, shouldn't the same stringent tests be applied to the directories/sockets used by the agent? (yes I realize that anyone whose sued to root, can easily su to be me) Tim McGarry

...to send out instructions on how to get patches into the LLVM 3.0 branch. All patches must be approved by the code owners (http://llvm.org/docs/DeveloperPolicy.html#owners). Please CC me on all emails for patches you want in. I may not catch them otherwise. >> >> Code owners, please be stringent about which patches you accept. Please approve only those patches that are critical for the release. I'm no longer accepting new features into 3.0. I will accept patches for features which were turned on before the 3.0 branch, if they are absolutely necessary and have gone through at least one...

...adata (line numbers in debug info?), but that is not really necessary. In reality, metadata might want to have merging rules and a defined API so that metadata merging can be used by a number of passes (vectorization will need this too). For example, merging fp-accuracy data should choose the more-stringent bound, but not really be removed all together. -Hal > > > Dan > > > > Cheers, > Rafael > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailma...

...ithin my project. At first, I got bogged down in a mysterious "parse" problem, R's not-too-revealing result of a simple eval, but after discovering the keep.tempfiles flag I was able to trace the obvious errors without running codoc line by line interactively. Apparently, R keeps very stringent requirements on its documentation's usage field. If it's anything other than myFunc(arg1, arg2...), codoc won't parse it correctly in its tempfiles. And the particular S code I was translating used chiefly example calls in its documentation's usage fields. Is this formatting an inte...

...s of Wine development effort: 1. to ensure 'absolute' compatibility with existing platforms 2. to extend for developing/unfinished platforms Obviously the codebase should be set up to allow code which is partially shared between targets on a file-by-file or subsystem basis, and some fairly stringent guidelines/administration as to when a shared code line should be split off into a target-specific variant. The user of Wine would then opt to use the 'highest' level of compatibility required for their application. Regards, Mike Whittaker PS. the mailto links on the winehq.com pages do...

...ppet, because I think C has the best-understood implementation of TBAA among the folks on the list. However, I was unable to actually come up with an example where this inhibits optimizations coming from C code. I myself have this problem as a real problem in a non-C frontend, which allows for more stringent AA. With that in mind, consider void foo(unsigned int *data, int128_t *value) { for (int i = 1; i < 100; ++i) { data[i] += (int)*value; } } This will get lowered to something like (pseudo llvm IR here) for.body: %l = load i128, i128* %value, !tbaa !1 %t = trunc %l to i32 %gep...

...e let me know. > > That's on the edge of OK. There are numerous tricky ABI issues that > could be caused by simply swapping a -march argument to LLVM . Clang, > for example, wouldn't be able to compile correct C or C++ code with > just that switch. But GHC presumably has less stringent ABI > compatibility requirements, so it might get away with it. I hope so. > On the other hand, I think x86 (and possibly ARM) has specific code to > handle the GHC calling conventions, which I'm fairly sure AArch64 > doesn't. That *might* just be a matter of performance, or i...