search for: xarray

.... September 2006 11:44 >An: Gunther H?ning >Cc: r-help at stat.math.ethz.ch >Betreff: Re: AW: [R] Question on apply() with more information... > >Hi > >If I am correct apply do not choose from SmoothList as you expected. >Instead probably > >lapply(SmoothList, predict,Xarray) >or >mapply(predict,SmoothList, Xarray) > >can give you probably what you want. > >HTH >Petr > > >On 18 Sep 2006 at 9:26, Gunther H?ning wrote: > >From: Gunther H?ning <gunther.hoening at ukmainz.de> >To: "'Petr Pikal...

Hello, how convert x in xarray (numbers)? > x [1] "0 - 13" > y [1] "11 - 23" > z [1] "220 - 9" > xarray [1] 0 13 > yarray [1] 11 23 > zarray [1] 220 9 Thanks, RMB

Hello list, my question is related to svd of a matrix: b=matrix(rnorm(50),10,5) mysvd=svd(b) I would like to compute each xi where xi = di* ui %*% t(vi). I do it by : xlist=sapply(1:ncol(b), function(x1,y) y$d[x1]*y$u[,x1]%*%t(y$v[,x1]),y=mysvd,simplify=F) # result is a list xarray=array(sapply(1:ncol(b), function(x1,y) y$d[x1]*y$u[,x1]%*%t(y$v[,x1]),y=mysvd),c(nrow(b),ncol(b),ncol(b))) # result is an array Now i would like to compute cumulative sum: y1=x1 # y[,,1] y2=x1+x2 # y[,,2] ... I have try to do it with apply without succes: y=apply(xarray,c(1,2),cumsum) The re...

On Tue, Jan 9, 2018 at 1:10 PM, Wei Wang <wei.w.wang at intel.com> wrote: > From: Matthew Wilcox <mawilcox at microsoft.com> > > The eXtensible Bitmap is a sparse bitmap representation which is > efficient for set bits which tend to cluster. It supports up to > 'unsigned long' worth of bits. > lib/xbitmap.c | 444

On Tue, Jan 9, 2018 at 1:10 PM, Wei Wang <wei.w.wang at intel.com> wrote: > From: Matthew Wilcox <mawilcox at microsoft.com> > > The eXtensible Bitmap is a sparse bitmap representation which is > efficient for set bits which tend to cluster. It supports up to > 'unsigned long' worth of bits. > lib/xbitmap.c | 444

...sertion and O(m) on removal of an extobj, > while using the maple tree is O(log(n))? No, insertion and removal is O(m) where m is the number of vms the object is currently bound to. Typically a very small number. > >>> Although assuming that's a no-go for GPUVA wouldn't an XArray be a better >>> choice, keeping O(1)? >>> When tracking extobjs, the address of the drm_gem_object is the key while the >>> reference count is the value. I was thinking of an XArray as well, but I was >>> worried that the corresponding indices could be too much d...

From: Mike Stunes <mstunes at vmware.com> To avoid a future VMEXIT for a subsequent CPUID function, cache the results returned by CPUID into an xarray. [tl: coding standard changes, register zero extension] Signed-off-by: Mike Stunes <mstunes at vmware.com> Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> [ jroedel at suse.de: - Wrapped cache handling into vc_handle_cpuid_cached() - Used lower_32_bits() w...

...'t eliminating radix_tree_exception() case and always storing > "struct ida_bitmap" simplifies the code (and make the processing faster)? It happens all the time. The vast majority of users of the IDA set low bits. Also, it's the first 62 bits -- going up to 63 bits with the XArray rewrite. I do plan to redo the xbitmap on top of the XArray; I'm just trying to get the XArray merged first. The IDA and xbitmap code will share much more code when that happens.

...see how to extend it by S4. Am I being dumb here? 2. Seeking then to define a similar class in S4, my principal task is to modify (extend?) a the extractor "[", modifying the range variables i,j,... . I run into problems here, though. The following is a minimal example: setClass("xarray",representation("array")) setMethod(f="[", signature=signature("xarray","ANY"), definition=function(x,i,j, ..., drop) { xcall <- match.call() #sundry processes on xcall to adjust i,j,......

...wrote: > > >> On Apr 28, 2020, at 8:17 AM, Joerg Roedel <joro at 8bytes.org> wrote: >> >> From: Mike Stunes <mstunes at vmware.com> >> >> To avoid a future VMEXIT for a subsequent CPUID function, cache the >> results returned by CPUID into an xarray. >> >> [tl: coding standard changes, register zero extension] >> >> Signed-off-by: Mike Stunes <mstunes at vmware.com> >> Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> >> [ jroedel at suse.de: - Wrapped cache handling into vc_handle_cpuid_c...

...d xbit_alloc, which looks like ida_get_new, I think set/clear should be adequate to the current usages. I'm intending on replacing the xb_ and ida_ implementations with this one. It removes the preload API which makes it easier to use, and it handles the locking for you. But I need to get the XArray (which replaces the radix tree) finished first.

...d xbit_alloc, which looks like ida_get_new, I think set/clear should be adequate to the current usages. I'm intending on replacing the xb_ and ida_ implementations with this one. It removes the preload API which makes it easier to use, and it handles the locking for you. But I need to get the XArray (which replaces the radix tree) finished first.

On Fri, Jan 31, 2020 at 11:36:51AM +0800, Tiwei Bie wrote: > +static int vhost_vdpa_alloc_minor(struct vhost_vdpa *v) > +{ > + return idr_alloc(&vhost_vdpa.idr, v, 0, MINORMASK + 1, > + GFP_KERNEL); > +} Please don't use idr in new code, use xarray directly > +static int vhost_vdpa_probe(struct device *dev) > +{ > + struct vdpa_device *vdpa = dev_to_vdpa(dev); > + const struct vdpa_config_ops *ops = vdpa->config; > + struct vhost_vdpa *v; > + struct device *d; > + int minor, nvqs; > + int r; > + > + /* Curren...

On Fri, Jan 31, 2020 at 11:36:51AM +0800, Tiwei Bie wrote: > +static int vhost_vdpa_alloc_minor(struct vhost_vdpa *v) > +{ > + return idr_alloc(&vhost_vdpa.idr, v, 0, MINORMASK + 1, > + GFP_KERNEL); > +} Please don't use idr in new code, use xarray directly > +static int vhost_vdpa_probe(struct device *dev) > +{ > + struct vdpa_device *vdpa = dev_to_vdpa(dev); > + const struct vdpa_config_ops *ops = vdpa->config; > + struct vhost_vdpa *v; > + struct device *d; > + int minor, nvqs; > + int r; > + > + /* Curren...

On Tue, Apr 28, 2020 at 05:17:14PM +0200, Joerg Roedel wrote: > From: Mike Stunes <mstunes at vmware.com> > > To avoid a future VMEXIT for a subsequent CPUID function, cache the > results returned by CPUID into an xarray. > > [tl: coding standard changes, register zero extension] > > Signed-off-by: Mike Stunes <mstunes at vmware.com> > Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> > [ jroedel at suse.de: - Wrapped cache handling into vc_handle_cpuid_cached() >...

On Tue, Apr 28, 2020 at 05:17:14PM +0200, Joerg Roedel wrote: > From: Mike Stunes <mstunes at vmware.com> > > To avoid a future VMEXIT for a subsequent CPUID function, cache the > results returned by CPUID into an xarray. > > [tl: coding standard changes, register zero extension] > > Signed-off-by: Mike Stunes <mstunes at vmware.com> > Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com> > [ jroedel at suse.de: - Wrapped cache handling into vc_handle_cpuid_cached() >...

...convention is objectively awful, which is why I'm working >> to change it. Specifying the GFP flags at radix tree initialisation time >> rather than allocation time leads to all kinds of confusion. The preload >> API is a pretty awful workaround, and it will go away once the XArray >> is working correctly. That said, there's no alternative to it without >> making XBitmap depend on XArray, and I don't want to hold you up there. >> So there's an xb_preload for the moment. > I'm ready to propose cvbmp shown below as an alternative to xbitmap...

...+ > > Please, split tests to a separate module. Hah, I just did this two days ago! I didn't publish it yet, but I also made it compile both in userspace and as a kernel module. It's the top two commits here: http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/heads/xarray-2018-02-12 Note this is a complete rewrite compared to the version presented here; it sits on top of the XArray and no longer has a preload interface. It has a superset of the IDA functionality.

...ts to a separate module. > > Hah, I just did this two days ago! I didn't publish it yet, but I also made > it compile both in userspace and as a kernel module. > > It's the top two commits here: > > http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/heads/xarray-2018-02-12 > Thanks! > Note this is a complete rewrite compared to the version presented here; it > sits on top of the XArray and no longer has a preload interface. It has a > superset of the IDA functionality. Noted. Now, the question about test case. Why do you heavily use BUG_ON...

...# plot.spdf <- function(xmin, xmax, skewlocation, skewscale, skewshape, skewmax, skewtitle) { if(missing(skewtitle)) { plottitle <- "Skewed Probability Density Function" } else { plottitle <- skewtitle } skip <- (xmax - xmin) / 100.0 xArray <- numeric(100) yArray <- numeric(100) for (i in 1:100){ x <- xmin + i * skip y <- (spdf(x, skewlocation, skewscale, skewshape))/skewmax xArray[i] <- x yArray[i] <- y } plot(xArray,yArray, main=plottitle) }...