search for: compactify

...t;- b <- as.array(1:3) dim(b) <- c(3,1) Any other comments are very much appreciated! Hadley iapply <- function(x, margins=1, fun, ..., REDUCE=TRUE) { if (!is.array(x)) x <- as.array(x) reorder <- c(margins, (1:length(dim(x)))[-margins]) x <- aperm(x, (reorder)) x <- compactify(x, length(margins)) results <- lapply(x, fun, ...) dim(results) <- dim(x) results <- decompactify(results) if (REDUCE) reduce(results) else results } vdim <- function(x) if (is.vector(x)) length(x) else dim(x) # Compacts an array into a smaller array of lists containing the rem...

...all of them in memory predictions <- predict(lm.1, newdata=my.predict) # Pretend we have a magic function that creates minimally-sized model object # from coefficients that can still be used to predict value, but takes up far less memory # than standard lm object lm.compact.1 <- compactify(lm.1) # Goal: be able to generate same predictions as with standard methods, # but with more compact model object predictions <- predict(lm.compact.1, newdata=my.predict) ######################### One of my initial thoughts would be to somehow automatically create a function fro...

...(f_frsize - 1) *bytes*. >> So on a 1PB fs, we might be off by (256K - 1) bytes. That''s >> 0.000000026 percent. It doesn''t seem like it would generate >> many support calls. > >Even if. As was mentioned about ZFS behaviour a few times, ZFS will >"compactify" small files anyway (meaning that, even if the FS were full to >that degree, extending _small_ files may be possible), and since it >optionally also does disk compression the amount of free space can only be >estimated. >The point, in particular for ZFS, can be made that the acc...

Hi, I have a dataframe (say myData) and want to get a list (say myList) that contains a matrix for each row of the dataframe myData. These matrices are calculated based on the corresponding row of myData. Using a for()-loop to do this is very slow. Thus, I tried to use apply(). However, afaik apply() does only return a list if the matrices have different dimensions, while my matrices have

It isn't really clear that it can't work. This does work by inserting NA's. library(zoo) as.ts(as.zoo(lynx)[ c(1:3, 7) ] ) ## Time Series: ## Start = 1821 ## End = 1827 ## Frequency = 1 ## [1] 269 321 585 NA NA NA 3928 On Mon, Jun 10, 2024 at 10:32?AM Martin Maechler <maechler at stat.math.ethz.ch> wrote: > > >>>>> Spencer Graves

On Tuesday, October 1, 2019, Jacob Lifshay <programmerjake at gmail.com> wrote: > On Mon, Sep 30, 2019 at 2:30 AM Sander De Smalen via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > I've posted two patches on Phabricator to add support for VScale in LLVM. Excellent! > > > > A brief recap on `vscale`: > > The scalable vector type in

...of 32x FP32 operations issued at once. in a *hybrid* CPU - VPU - GPU context even a 1k shader program hits a significant portion of the 1st level cache which is *not* separate from a *GPU*'s 1st level cache because the CPU *is* the GPU. consequently, SV has been specifically designed to "compactify" instruction effectiveness by "prefixing" even RVC 16-bit opcodes with vectorisation "tags". this has the side-effect of reducing executable size by over 10% in many cases when compared to RVV. > so I cannot comment on that, but I'll sketch the reasons for why it&...

An issue was found with the netBeans installer where the installation was failing on a large ZFS filesystem. This resulted in CR 6560644 (zfs statvfs f_frsize needs work). The issue is that large filesystems can cause EOVERFLOW on statvfs() calls. This behavior is documented in the statvfs(2) man page, but I think we can do better. The problem was initially reported against ZFS, and my first fix