В Tue, 9 Apr 2024 12:04:26 +0200
Adelchi Azzalini пишет:
> res <- CEoptim(sumsqrs, f.arg = list(xt), continuous = list(mean =
> c(0, 0, 0), sd = rep(1,3), conMat = A, conVec = b), discrete =
> list(categories = c(298L, 298L), smoothProb = 0.5),N = 1, rho
> = 0.001)
>
> Error in
В Tue, 9 Apr 2024 09:55:06 +0200
gernop...@gmx.net пишет:
> If I only move away /usr/local/lib/libomp.dylib, I can still install
> it. So it seems that also here the internal libomp.dylib from R is
> used. Just the bundled omp files at /usr/local/include (omp-tools.h,
> omp.h, ompt.h) seem to be
Sorry fort he late reply, your mail ended up in my spam and I've just seen it
recently.
> Does the behaviour change if you temporarily move away
> /usr/local/lib/libomp.dylib?
It does not change the behavior after loading (or attaching) data.table using
"library(data.table)". It is still
Sorry, if have to correct this. If I only move away
/usr/local/lib/libomp.dylib, I can still install it. So it seems that also here
the internal libomp.dylib from R is used. Just the bundled omp files at
/usr/local/include (omp-tools.h, omp.h, ompt.h) seem to be used. So maybe this
is caused
In the attempt to explore the usage of package CEoptim, I have run the code
listed at the end of this message. This code is nothing but the one associated
to example 5.7 in the main reference of the package, available at
https://www.jstatsoft.org/article/view/v076i08
and is included in the
So, you know how to get volume for given water level.
For the reverse problem, you get in trouble because of the nonlinearity
inherent in the dependence of surface area on the level.
I don't think there is a simple solution to this, save for mapping out the
volume as a function of water
Hi, Adelchi,
Depends on what you want help with...
The proximate cause would seem to be that the code ought to have "is.null(A) ||
any(is.NA(A))", which I presume you could fairly easily fix for yourself in the
package sources or even locally in an R session. Vector-valued logicals in flow
> On 9 Apr 2024, at 14:54, peter dalgaard wrote:
>
> Hi, Adelchi,
>
> Depends on what you want help with...
>
> The proximate cause would seem to be that the code ought to have "is.null(A)
> || any(is.NA(A))", which I presume you could fairly easily fix for yourself
> in the package
Thanks for the suggestion, Ivan.
The issue has been overcome with a simple change of the code to the form
(is.null(A) || any(is.na(A))
following advice from Peter Dalgard.
However, I have kept a note of the R Inferno reference, for future problems.
Best wishes,
Adelchi
> On 9 Apr 2024, at
On Tue, 9 Apr 2024, Ivan Krylov wrote:
At this point in the build, R already exists, is quite operable and
even has all the recommended packages installed. The build system then
uses this freshly compiled R to run Sweave on the vignettes. Let me
break the build in a similar manner and see what
Water engineer here. The standard approach is to 1) get the storage vs.
elevation data from the designers of the reservoir or, barring that, 2)
get the bathymetry data from USBR or state DWR, or, if available, get
the DEM data from USGS if the survey was done before the reservoir was
built or
Dear RHelp-list,
I generate a swept sine signal using the signal library. I can see
using the spec.pgram command that the spectrum of this signal is white.
But when I am calculating the cumulative periodogram using the command
cpgram the process doesn't stay inside the confidence band (cf.
On Tue, 9 Apr 2024, Ivan Krylov wrote:
That's fine, R will run straight from the build directory. It has to do
so in order to compile the vignettes.
Ivan,
That's good to know. Thanks.
But let's skip this step. Here's reshape.tex from R-4.3.3:
https://0x0.st/XidU.tex/reshape.tex
(Feel free
I answer to myself: I have to generate my signal up to f1 = Fs/2 in
order to have a flat response over the entire frequency range.
Le 09/04/2024 à 19:48, laurentRhelp a écrit :
Dear RHelp-list,
I generate a swept sine signal using the signal library. I can see
using the spec.pgram command
14 matches
Mail list logo
