similar to: memory limit

Hi Sebastian, It boils down to this: The previous heuristic solver could return infinite cost solutions in some rare cases (despite finite-cost solutions existing). The new solver is still heuristic, but it should always return a finite cost solution if one exists. It does this by avoiding early reduction of infinite spill cost nodes via R1 or R2. To illustrate why the early reductions can be a

Hi All, I think there may be some possible confusion about what allowsInf would be reporting (or maybe its just me :) ) if we did this. Consider a class "myclass", S3, for starters, with setMethod("allowsInf", "myclass", function(obj) FALSE) Then, what would myclassthing <- structure(1.5, class = "mything") myclassthing[1] <- Inf do. Assumely it

Hello all, I have to import numeric data from file but found it contains Infinite values which need to be eliminated. I tried to replace them in this way: data[which(data=="-Inf")] <- -0.3 data[which(data=="+Inf")] <- 0.3 But, somehow, the Infinite values stayed there. Any suggestions? regards, N. -- View this message in context:

Dear All, I've tried to add axis limit ( e.g. ylim=c(0,50)) to the log-log plot, but it turn out to be error (see below). Any solution is much appreciated. > plot(maxsd$tph,maxsd$qdbh,log="xy",xlab="Stand density(trees per ha)",ylab="Quadratic mean dbh (cm)",ylim=c(0,50)) Error in plot.window(xlim, ylim, log, asp, ...) : Infinite axis extents

Dear all, Using rmultinom() in a stochastic model, I found this function returns an error message 'NA in probability' for an infinite probability. Maybe, a more precise message will be helpful when debugging. > rmultinom(1, 3:5, c(1/2, 1/3, Inf)) Error in rmultinom(1, 3:5, c(1/2, 1/3, Inf)) : NA in probability vector > rmultinom(1, 3:5, c(1/2, 1/3, NA)) Error in rmultinom(1,

On 08/04/2023 5:53 p.m., Martin Maechler wrote: >>>>>> Christophe Dutang >>>>>> on Sat, 8 Apr 2023 14:21:53 +0200 writes: > > > Dear all, > > > Using rmultinom() in a stochastic model, I found this function returns an error message 'NA in probability' for an infinite probability. > > > Maybe, a more

>>>>> Christophe Dutang >>>>> on Sat, 8 Apr 2023 14:21:53 +0200 writes: > Dear all, > Using rmultinom() in a stochastic model, I found this function returns an error message 'NA in probability' for an infinite probability. > Maybe, a more precise message will be helpful when debugging. >> rmultinom(1, 3:5, c(1/2, 1/3,

Hi, I'm trying to use isoMDS to project a directed graph to 2-dim vectors, but I got an error. #here is the code to create the graph using igraph package and run isoMDS on it. library(igraph) library(MASS) g<-make_graph(c(1,2, 2,3, 2,4, 3,4, 4,5, 5,6, 3,6, 1,6, 2,5),directed=TRUE) dist<-distances(g, mode="out") loc<-isoMDS(dist) # below is content of the dist matrix

Hi everyone I have a problem about "infinite". If I type 10^308, R shows "1e+308" When I type 10^309, R shows "Inf" So, we know if a value is large than 1.XXXe+308, R will show "Inf" How can i do let the value, like "10^400" ,typed in R to show the word "1e+400" not "Inf" -- View this message in context:

Hi Gabriel, The point is that it *visually* displays as NA, but is.na() still responds as FALSE. When I (and I am sure many people) see an NA, we then use is.na(). If we see Inf displayed, we then use is.infinite(). With as.Date() this breaks down. I'm not arguing that as.Date(Inf) should be coerced to NA. I'm arguing that as.Date(Inf) should be *visually* displayed as Inf (i.e. the

Having worked with optim() and related programs for years, it surprised me that I haven't noticed this before, but optim() is inconsistent in how it deals with bounds constraints specified at infinity. Here's an example: # optim-glitch-Ex.R x0<-c(1,2,3,4) fnt <- function(x, fscale=10){ yy <- length(x):1 val <- sum((yy*x)^2)*fscale } grt <- function(x, fscale=10){ nn

Under windows, R supports IEEE floating point arithmetic, but doesn't allow conversion of Inf and NaN from character to numeric. R> is.nan(NaN) [1] TRUE R> as.numeric(as.character(NaN)) [1] NA Warning message: NAs introduced by coercion R> is.infinite(Inf) [1] TRUE R> as.numeric(as.character(Inf)) [1] NA Warning message: NAs introduced by coercion whereas under Linux R>

>>>>> Gabriel Becker >>>>> on Tue, 5 Mar 2019 22:01:37 -0800 writes: > On Tue, Mar 5, 2019 at 9:54 PM Richard White <w at rwhite.no> wrote: >> Hi Gabriel, >> >> The point is that it *visually* displays as NA, but is.na() still >> responds as FALSE. >> >> When I (and I am sure many people)

Hi, I found in a bit of code the following test for infinity: if (x == Inf) ... Is that valid, or should it be (as I always thought): if (is.infinite(x)) ...? Does it depend on whether 'x' is float or integer? My question is related to testing for missing values where is.na(x) is required. /Henrik

Hi, I want to recode all Inf and NaN values to NA, but I;m surprised to see the result of the following code. Could anybody enlighten me about this? > df <- data.frame(a=c(NA, NaN, Inf, 1:3)) > df[is.infinite(df) | is.nan(df)] <- NA > df a 1 NA 2 NaN 3 Inf 4 1 5 2 6 3 > Thanks! Cheers!! Albert-Jan

Hi, I want to recode all Inf and NaN values to NA, but I;m surprised to see the result of the following code. Could anybody enlighten me about this? > df <- data.frame(a=c(NA, NaN, Inf, 1:3)) > df[is.infinite(df) | is.nan(df)] <- NA > df a 1 NA 2 NaN 3 Inf 4 1 5 2 6 3 > Thanks! Cheers!! Albert-Jan

I'm having some trouble with optim(method="L-BFGS-B"), and I'm not sure I have the ability to track down and fix what seem to be bugs within optim(). I'm bootstrapping an original data set and fitting a model to each bootstrapped data set. For some bootstrapped samples, optim() sets negative parameter values (despite the fact that I have explicitly set non-zero lower

I am porting some FORTRAN to R in which an Inf triggers an if(). The trigger is infinite on exp(lgamma(OVER)). What is the canonical R style of determining OVER when exp(OVER)== Inf? The code structure that I am porting is best left intact--so I need to query R somehow to the value of OVER that causes exp(lgamma(OVER)) to equal Inf. On my system, exp(lgamma(171)) is about first to equal Inf.

I am doing work on changes in establishment sizes and came across behavior that is quite understandable and easily worked around but a little surprising. On R 1.5.1 on Debian unstable (see below for R.version output): > cut.off <- c(-Inf, 0, Inf) > x <- c(-Inf, -10, 0, 10, Inf) > is.numeric(x) [1] TRUE > is.double(x) [1] TRUE > # but > cut(x, cut.off, include.lowest=T) [1]

Hi, just a quick question: Should weighted.mean be able to cope with the specific case where one weight is Inf? I came across this when trying to implement a simple weighted moving average algorithm for surface smoothing: these algorithms often result in a single infinite weight when predicting the surface value at known data points. e.g. > weighted.mean(c(77,88,99), c(Inf, 1, 2))