search for: precbit

Hello everyone, R beginner, I am confronted with the need to use Rmpf. In my first scripts I made use of X=read.table(file.choose(), header=FALSE, sep=",",dec=".") X=as.matrix(X) to load into a matrix data from file before matrix use. How can I do to load the same data in a "mpfrMatrix". Is it possible to use with "mpfrMatrix" the same as operations

...f the computations > by a factor 'fPrec' with default 'fPrec = 1'; > notably, instead of x %*% y (where the `%*%` cannot have more > than two arguments) does have a counterpart matmult(x,y, ....) > which allows more arguments, namely 'fPrec', or directly 'precBits'; > and of course there are crossprod() and tcrossprod() one should > use when applicable and they also got the 'fPrec' and > 'precBits' arguments. > > {The %*% etc precision increase still does not work optimally > efficiency wise, as it simply increases...

Given that a number of us are housebound, it might be a good time to try to improve the approximation. It's not an area where I have much expertise, but in looking at the qbeta.c code I see a lot of root-finding, where I do have some background. However, I'm very reluctant to work alone on this, and will ask interested others to email off-list. If there are others, I'll report back.

...arge the precision of the computations by a factor 'fPrec' with default 'fPrec = 1'; notably, instead of x %*% y (where the `%*%` cannot have more than two arguments) does have a counterpart matmult(x,y, ....) which allows more arguments, namely 'fPrec', or directly 'precBits'; and of course there are crossprod() and tcrossprod() one should use when applicable and they also got the 'fPrec' and 'precBits' arguments. {The %*% etc precision increase still does not work optimally efficiency wise, as it simply increases the precision of all computat...

...f the computations > by a factor 'fPrec' with default 'fPrec = 1'; > notably, instead of x %*% y (where the `%*%` cannot have more > than two arguments) does have a counterpart matmult(x,y, ....) > which allows more arguments, namely 'fPrec', or directly 'precBits'; > and of course there are crossprod() and tcrossprod() one should > use when applicable and they also got the 'fPrec' and > 'precBits' arguments. > > {The %*% etc precision increase still does not work optimally > efficiency wise, as it simply increases t...

As a side note, Splus makes sin(x) NA, with a warning, for abs(x)>1.6*2^48 (about 4.51e+14) because more than half the digits are incorrect in sin(x) for such x. E.g., in R we get: > options(digits=16) > library(Rmpfr) > sin(4.6e14) [1] -0.792253849684354 > sin(mpfr(4.6e14, precBits=500)) 1 'mpfr' number of precision 500 bits [1] -0.7922542110462653250609291646717356496505801794010... If R did make sin(4.6e14) NaN, would you want a warning? Bill Dunlap TIBCO Software wdunlap tibco.com On Mon, Nov 30, 2015 at 2:38 PM, Greg Snow <538280 at gmail.com> wrote:...

Dear R users, I have to calculate gamma functions for negative numbers beyond -171.4. e.x. gamma(-500.4) I got following: > gamma(-170.4) [1] -5.824625e-308 > gamma(-171.4) [1] 0 Warning message: underflow occurred in 'gammafn' I have tried to use a recursion getting values a little futher -180. How could I solve this problem? Thank you beforehand. Chuse.

Hello R-Experts, I want to calculate values like 15^200 or 17^300 in R. In normal case it can calculate the small values of b (a^b). I have fixed width = 10000 and digits = 22 but still answers are Inf. How to deal the cases like these? Thanks in advance. Regards, rehena [[alternative HTML version deleted]]

Hi, I have a data frame with one column containing string of the form "ABC...|XYZ..." where ABC etc are fields of 6 alphanumeric characters each and XYZ etc are fields of 8 alphanumeric characters each; "|" is a mandatory separator; I do not know in advance how many fields of each kind will each row contain. I need to extract these fields from the string. === How do I do that?

This question is more out of curiosity than a complaint or suggestion, but I'm just wondering. The behavior of R on calculations that result in NaN seems a bit inconsistent. # this is expected: > 0/0 [1] NaN # but this gives a warning > sin(Inf) [1] NaN Warning message: In sin(Inf) : NaNs produced # and this again does not > exp(NaN) [1] NaN Conceptually, I like to think that R