similar to: rewrite of scatter.smooth to handle NAs

Hello When I run scatter.smooth(jitter(weight), jitter(height2), span = .25, evaluation = 50, pch = '.') I get the type of graph I thought I would get, but also a warning..... k-d tree limited by memory. ncmax= 528 I always get concerned when there are warnings I don't understand. What's a k-d tree? Is this something to be concerned about? Thanks Peter Peter L. Flom,

Dear list, In using the scatter.smooth() function (modreg) on a small data set (100 obs) the following error was produced: > scatter.smooth(Na, S) Warning message: k-d tree limited by memory. ncmax= 200 I haven't used scatter.smooth much but when I have, I haven't seen this message before. gc() returns > gc() used (Mb) gc trigger (Mb) Ncells 417693 11.2 667722

Dear List, Having had my appetite sufficiently whetted by Prof. Ripley's email about the new graphics capabilities in Unixes, I wanted to try them out. I updated to svn r44608, configured with the following options: R is now configured for x86_64-unknown-linux-gnu Source directory: .. Installation directory: /usr/local C compiler: gcc -O3 -g -std=gnu99

Hello, I have been using scatter.smooth and been trying to format my plots and been unable to adjust the line type or color of the smooth curve. When I specify col in scatter.smooth, I can adjust the color of the scatter plot points, but the line always stays black and solid. lty has no effect. When I specify par prior to calling scatter.smooth, col will change the color of the points,

On Tue, Dec 10, 2013 at 5:08 PM, Hans Wennborg <hans at chromium.org> wrote: > On Tue, Dec 10, 2013 at 4:39 PM, Reid Kleckner <rnk at google.com> wrote: >> I think we need to relax the test cases. MSVC usually prints the calling >> convention, and it's often useful information. > > I was going to argue that MSVC doesn't print them, but then I tried, >

I am experimenting with rSymPy, and it seems to work nice. However, I dislike the need to wrap all sympy expressions within quotes, it leads to ugly calls like library(rSymPy) Var("x,y,z") sympy("(x+y)**2") and so on. Inspired by the function cq from mvbutiles package: library(mvbutils) > cq function (...) { as.character(sapply(as.list(match.call(expand.dots =

Hi there, I would like to draw a scatter plot and fit a smooth line by loess. Below is the data. However, the curve line started from 0, which my "resid" list doesn't consist of 0 value. It returned some warnings which I don't know if this is the reason affecting such problem. Here I also attached the warning messages. Please let me know if there is a solution to fix this. Thank

Hello Aaron, Anton, LLVM-dev, While working on http://llvm.org/PR13676#c6 I found out that whenever I compile code with class methods returning structures it get generated incompatible with MSVC. Looking at lib/Target/X86/X86CallingConv.td, I found out that CC_X86_32_ThisCall maps SRet to EAX but in fact it should push the address of the return temp on stack. The following patch fixes the issue

On Tue, Dec 10, 2013 at 4:39 PM, Reid Kleckner <rnk at google.com> wrote: > I think we need to relax the test cases. MSVC usually prints the calling > convention, and it's often useful information. I was going to argue that MSVC doesn't print them, but then I tried, and you're right - it does :) I'll start relaxing the tests then. > Maybe we can make the

I think we need to relax the test cases. MSVC usually prints the calling convention, and it's often useful information. Maybe we can make the diagnostic text smaller by using the __thiscall, __cdecl, __stdcall, etc keywords when printing types with LangOpts.MicrosoftExt, but it will require moving the attribute from after the identifier to before, which is exciting. On Tue, Dec 10, 2013 at

On 5 Feb 2018, at 21:19, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello everyone, > > I encountered a strange behaviour which I can't explain. > > I'm developing an application under Windows 7 64bit. This application is using the LLVM library to load and resolve BC files generated with clang. Then the program picks some functions from the module and

On Tue, Oct 2, 2012 at 8:44 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >>>> b) Should I be altering CC_X86_32_ThisCall >>>> OR should I introduce CC_X86_Win32_ThisCall instead? >>>> [Answer not clear to me - is there any platform besides Windows >>>> that uses thiscall?] >>> no >> Can you please clarify which

Hello Timur, > I'd like to ask for advice: > a) Is it OK to change the SRet/ThisCall behaviour on non-Windows platforms? > [I suppose no] no > > b) Should I be altering CC_X86_32_ThisCall > OR should I introduce CC_X86_Win32_ThisCall instead? > [Answer not clear to me - is there any platform besides Windows > that uses thiscall?] no It seems for me

> Attached is a patch that fixes all the test failures I saw due to > printing out the thiscall attribute on types. > > Do we want to land this now, or wait until the thiscall switch is > actually flipped for MinGW? Maybe combining the patches would be the best? It is funny, I had never tried check-all on mingw. I just did and found some codegen errors, mostly when we look for

I have a need to call and pass arguments to nlme() from within another function. I use R version 1.8. I have found an apparent way to make this work, but I would appreciate some comments on whether this fix is really appropriate, or there is another way to do it that does not involve changing the source code. I don't have enough experience to start changing the sorurce code of a library

I'm updating the loess routines to allow for, among other things, arbitrary local polynomial degree and number of predictors. For now, I've given the updated package its own namespace. The trouble is, panel.loess still calls the original code in package:stats instead of the new loess package, regardless of whether package:loess or package:lattice comes first in the search list. If I

On Tue, Oct 2, 2012 at 7:03 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: > Hello Timur, > >> I'd like to ask for advice: >> a) Is it OK to change the SRet/ThisCall behaviour on non-Windows platforms? >> [I suppose no] > no > >> >> b) Should I be altering CC_X86_32_ThisCall >> OR should I introduce CC_X86_Win32_ThisCall

Hi, I have a scatter plot of the variables GNI and Lifeexp (Gross National Income and Life Expectancy, both metric). So I plotted them and I want to add a regression line and a lowess line. I use lowess and not loess because I have missing values. My code: plot(GNI,Lifeexp) abline(lm(Lifeexp~GNI), col="red") y.loess<-loess(Lifeexp~GNI,na. action = na.exclude)

On Tue, Dec 10, 2013 at 3:57 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Dec 10, 2013 at 11:58 AM, Hans Wennborg <hans at chromium.org> wrote: >> >> It would be nice if we could make the TypePrinter not print the >> calling convention if it's the default one for the ABI, but >> TypePrinter doesn't have a lot of context.. no Sema, no

On Tue, Oct 2, 2012 at 11:02 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > On Tue, Oct 2, 2012 at 8:28 PM, David Blaikie <dblaikie at gmail.com> wrote: >> On Tue, Oct 2, 2012 at 8:54 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> [+cfe-dev as this does seem like both LLVM+Clang issue] >>> [Sorry for an incomplete e-mail context,