Re: [R] MASS::mvrnorm() on MKL may produce different numbers even when the seed is the same?

Thanks a lot! I am not aware of this behavior! I will take this into account in my work. Regards, Shu Fai On Thu, Aug 17, 2023 at 10:31 PM Bill Dunlap wrote: > > MKL's results can depend on the number of threads running and perhaps other > things. They blame it on the non-associativity of floa

Re: [R] Timezone question

You may also find the package "lutz" to be of interest, although that may be overkill for your needs. (found by an internet search). Cheers, Bert On Thu, Aug 17, 2023 at 1:31 PM Dennis Fisher wrote: > R 4.3.1 > OS X > > Colleagues > > Is there a simple way to determine the timezone offset for

Re: [R] Timezone question

Hi Dennis, I believe that it may be as simple as: > format(Sys.time(), "%z") [1] "-0400" Where "%z" returns the offset from UTC as a character vector, and where I am in: > Sys.timezone() [1] "America/New_York" There may be some subtleties, and I would suggest reading the relevant help files f

[R] Timezone question

R 4.3.1 OS X Colleagues Is there a simple way to determine the timezone offset for my present location. For example, during standard time in the US, the offset from GMT is 8 hours in California. Dennis Dennis Fisher MD P < (The "P Less Than" Company) Phone / Fax: 1-866-PLessThan (1-866-753-7

Re: [R] Questions about R

When I installed R no personally identifiable information was given, none was requested. There is no login, so no password or user name. R resides on the host computer, so security is the responsibility of the owner(s) of that computer. There are packages and other third party programs, but thes

Re: [R] Questions about R

Hi, Shaun: I suggest you also check the Wikipedia article on "R (programming language)": https://en.wikipedia.org/wiki/R_(programming_language) That article has 115 numbered "References" that provide more information. You don't have to believe anything you read anywhere. However y

Re: [R] Questions about R

Às 12:10 de 17/08/2023, Shaun Parr escreveu: Sent from Outlook for Android Hi there, My name is Shaun and I work in an organisation where one of our users wishes to install the R software and our process is to assess the safety of anyone software prior to authorisat

Re: [R] Questions about R

Incidentally, you might be interested in the banner shown when R starts up: "R is free software and comes with ABSOLUTELY NO WARRANTY." I believe this is standard for open source software (upon which a lot of organizations depend). In any case, that might be the most definitive and "official" ans

Re: [R] Questions about R

This is a volunteer Help list for users of R, which is open source, so you can see all its code. I can answer no to your questions, unless you are using one of R's innumerable packages that interacts with the internet and to which the user may give personal information to enable the desired functio

Re: [R] Questions about R

1. R is open source software. You are welcome to review the source code of the R interpreter for handling of PII. No warranty is offered by the (volunteer) developers of R. 2. R software is a programming interpreter, which by definition allows for a wide range of behaviours. Users of R frequen

[R] Questions about R

Sent from Outlook for Android Hi there, My name is Shaun and I work in an organisation where one of our users wishes to install the R software and our process is to assess the safety of anyone software prior to authorisation. I can’t seem to locate all the information

Re: [R] MASS::mvrnorm() on MKL may produce different numbers even when the seed is the same?

Ah, super interesting! Thanks for the pointer, Bill. I might not have seen the issue because I have export MKL_NUM_THREADS=1 in my .profile, so MKL never goes beyond using one thread on my machine. That's a potential source of non-reproducibility I have not come across. So the 'wisdom' that on

Re: [R] MASS::mvrnorm() on MKL may produce different numbers even when the seed is the same?

Thanks, I was missing the point that this was *non-repeatability on the same platform*. On 2023-08-17 10:31 a.m., Bill Dunlap wrote: MKL's results can depend on the number of threads running and perhaps other things. They blame it on the non-associativity of floating point arithmetic. This

Re: [R] MASS::mvrnorm() on MKL may produce different numbers even when the seed is the same?

Sorry for the confusion caused by that sentence. I did not expect using the same seed generates the same sequence of numbers unconditionally. What puzzled me is not having the same sequence when running the same code repeatedly in the same computer in the same session of R. The following four sets

Re: [R] MASS::mvrnorm() on MKL may produce different numbers even when the seed is the same?

MKL's results can depend on the number of threads running and perhaps other things. They blame it on the non-associativity of floating point arithmetic. This article gives a way to make results repeatable: https://www.intel.com/content/www/us/en/developer/articles/technical/introduction-to-the-c

Re: [R] MASS::mvrnorm() on MKL may produce different numbers even when the seed is the same?

But I have never seen a case where, on the same machine and using the same math routines, using the same seed repeatedly generated different values. That is quite bizarre (the issue I was discussing in the thread is quite simple in comparison). I tried to reproduce the issue below, but was unabl

Re: [R] MASS::mvrnorm() on MKL may produce different numbers even when the seed is the same?

> However, should the numbers > generated identical if the same seed is used? I don't see how using the same seed can overcome floating-point differences across platforms (compilers etc.) stemming from differences in an eigen() computation (based on arcane details like use of registers, co

Re: [R] Numerical stability of: 1/(1 - cos(x)) - 2/x^2

> Leonard Mada > on Wed, 16 Aug 2023 20:50:52 +0300 writes: > Dear Iris, > Dear Martin, > Thank you very much for your replies. I add a few comments. > 1.) Correct formula > The formula in the Subject Title was correct. A small glitch swept into > the last f