similar to: Compilation package error

Hello r-help, I am having trouble installing the add-on package gstat. I suspect (but I'm not sure) that the trouble may be that it runs all the checks for gcc, then uses Intel's compiler to actually compile. I have not been able to successfully force it to use gcc to test that theory. R CMD INSTALL and R.version() output follow below; any help greatly appreciated! -Tim -- Timothy

Dear all, I did post a message about problems on installing a package (gstat) which ends with a compilation error: ** libs gcc -I/usr/lib/R/include -mieee-with-inexact -fPIC -g -O2 -c block.c -o block.o gcc -I/usr/lib/R/include -mieee-with-inexact -fPIC -g -O2 -c chfactor.c -o chfactor.o gcc -I/usr/lib/R/include -mieee-with-inexact -fPIC -g -O2 -c copy.c -o copy.o gcc

Hi all, I got the >"chfactor.c", line 130: singular matrix in function LDLfactor() Error in predict.gstat(g, newdata = newdata, block = block, nsim = nsim, : LDLfactor< Error, probably because there are some point pairs with zero distance in the matrix. My question is, how can i delete these duplicate nodes from the data set? Thanks, m [[alternative

optim ignores misspelled control parameters, so that trying to set (e.g.) "maxint=1000" in the control argument silently does nothing. The patch below (watch out for line breaks! also posted at http://www.zoo.ufl.edu/bolker/optim_patch.R , and http://www.zoo.ufl.edu/bolker/optim_new.R) adds three lines to optim.R that issue a warning if any names of elements of "control" fail

Changing the list from cfe-dev to llvm-dev > On 20 Apr 2017, at 4:52 AM, Michael Clark <michaeljclark at mac.com> wrote: > > I’m getting close. I think it may be an issue with an individual intrinsic. I’m looking for the X86 lowering of Instruction::FPToUI. > > I found a comment around the rationale for using a conditional move versus a branch. I believe the predicate logic

Thanks, Andy. I'm not sure how to solve that or my case given the DAG's basic-block limit. Probably CodeGenPrepare or SelectionDAGBuilder...or we wait until after isel and try to split it up in a machine instruction pass. I filed my example here: https://bugs.llvm.org/show_bug.cgi?id=33013 Feel free to comment there and/or open a new bug for the FP_TO_UINT case. On Thu, May 11, 2017 at

Hi, Currently Omega/scriptindex supports filtering by date. For example, all dates between START and END. Would it be possible to extend this behaviour to include the time? We have documents which expire. In order to filter out 'old' articles, we would like to check if the document date is between START=NOW and END=MAXINT. Best regards, Eric

Hi folks, I am planning to write some more time-consuming matrix manipulations in c++. What is the experience with the existing c++ matrix libraries? Do you have some recommendations? Are some libraries more compatible with R than the others? All suggestions welcome! Best, Ott

Dear R-help, Here's a simple example of nonlinear curve fitting where nls seems to get the answer wrong on a very simple exponential fit (my R version 2.7.2). Look at this code below for a very basic curve fit using nls to fit to (a) a logarithmic and (b) an exponential curve. I did the fits using self-start functions and I compared the results with a more simple fit using a straight lm()

Thanks for expanding, Chris. Responses inline. > On Mar 2, 2018, at 12:32 AM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: <snip> > - Because LLVM reorders and speculates the instruction forms, and because IEEE defines the corresponding IEEE operations as trapping on SNaNs, it is clear that SNaNs are outside of the domain of these LLVM operations. Either

Some clarification after getting feedback from Craig Topper…. It’s probably best to say in the documentation that the llvm.nearbyint and llvm.rint functions “assume the default rounding mode, roundToNearest”. This will allow the optimizer to transform them as if they were rounding to nearest without requiring backends to use an encoding that enforces roundToNearest as the rounding mode for these

This email is just to summarize a bit of digging I did last night into our attribute inference.  Unfortunately, I'm not going to have time to implement any of the gaps I noticed, but I figured someone else out there might be interested. *Missing Attributes* argmemonly - influences AA, particularly relevant for libraries which wrap build in functions which are annotated, but don't

> > I'm not sure why this is an issue. Yes, these two intrinsics depend > on the current rounding mode according to the C standard, and yes, > LLVM in default mode assumes that the current rounding mode is the > default rounding mode. But the same holds true for many other > intrinsics and even the arithmetic IR operations like add. Any other intrinsic, like `floor`,

> This seems like it was done for perf reason (mispredict). Conditional-to-cmov transformation should keep > from introducing additional observable side-effects, and it's clear that whatever did this did not account > for floating point exception. That’s a very reasonable statement, but I’m not sure it corresponds to the way we have typically approached this sort of problem. In

On Tue, Oct 2, 2018 at 12:09 PM Kevin Neal <Kevin.Neal at sas.com> wrote: > If we don’t have constrained intrinsics for some of the fp math > instructions then aren’t we risking non-strict optimizations? > So far we've only added constrained FP intrinsics for operations that have side effects (i.e. can trap). The quiet-computational sign-bit operations are special. They never

> > The only issue I see is that since we also assume FP operations have no > side effects by default there is no difference between llvm.rint and > llvm.nearbyint. I wouldn’t have a problem with dropping llvm.rint > completely. The forthcoming C standard ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf, 7.12.9.8) defines new function, `roundeven`, which implements

In your sequences in asm/paravirt.h, you explicitly save the caller-save regs: static inline void raw_local_irq_restore(unsigned long f) { __asm__ __volatile__(paravirt_alt("pushl %%ecx; pushl %%edx\n\t" "pushl %1; call *%0\n\t" "popl %1; popl %%edx; popl %%ecx", PARAVIRT_RESTORE_FLAGS) : : "m" (paravirt_ops.restore_fl),

So imagine rpois is changed, such that the storage mode of its return value is sometimes integer and sometimes numeric. Then imagine the case where lambda is itself a realization of a random variable. Do we really want the storage mode to inherit that randomness? On 1/19/20 10:47 AM, Avraham Adler wrote: > Maybe there should be code for 64 bit R to use long long or the like? > > On

I am running 2.6.18-1.2693.fc6xen and I am receiving this message powernow-k8: Processor cpuid 681 not supported anyone know if xen works on processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(tm) Prosussor stepping : 1 cpu MHz : 1994.985 cache size : 256 KB fdiv_bug : no hlt_bug : no

I am running 2.6.18-1.2693.fc6xen and I am receiving this message powernow-k8: Processor cpuid 681 not supported anyone know if xen works on processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(tm) Prosussor stepping : 1 cpu MHz : 1994.985 cache size : 256 KB fdiv_bug : no hlt_bug : no