I will need to run eigen() on a symmetric matrix, but I want to get arbitrary precise eigenvalues since we will need those eigenvalues for our further calculations. Does that make sense?
Best, Khue Tran On Fri, Jul 19, 2024 at 12:14 PM Vladimir Dergachev <volo...@mindspring.com> wrote: > > Do you need to run eigen() on an arbitrary matrix or symmetric one ? > > best > > Vladimir Dergachev > > On Fri, 19 Jul 2024, Khue Tran wrote: > > > Thank you Simon! This is very helpful! Regarding eigen, I found in the > > Boost library the following example for arbitrary precision matrix > solver: > > > https://github.com/boostorg/multiprecision/blob/develop/example/eigen_example.cpp > . > > I am not sure if the precision is fully preserved throughout the process, > > but this example motivated me to try coding with the Boost library. > > > > Best, > > Khue Tran > > > > On Fri, Jul 19, 2024 at 9:50 AM Simon Urbanek < > simon.urba...@r-project.org> > > wrote: > > > >> Khue, > >> > >> > >>> On 19/07/2024, at 11:32 AM, Khue Tran <tr...@kenyon.edu> wrote: > >>> > >>> Thank you for the suggestion, Denes, Vladimir, and Dirk. I have indeed > >>> looked into Rmpfr and while the package can interface GNU MPFR with R > >>> smoothly, as of right now, it doesn't have all the functions I need > (ie. > >>> eigen for mpfr class) and when one input decimals, say 0.1 to mpfr(), > the > >>> precision is still limited by R's default double precision. > >>> > >> > >> > >> Don't use doubles, use decimal fractions: > >> > >>> Rmpfr::mpfr(gmp::as.bigq(1,10), 512) > >> 1 'mpfr' number of precision 512 bits > >> [1] > >> > 0.100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002 > >> > >> As for eigen() - I'm not aware of an arbitrary precision solver, so I > >> think the inputs are your least problem - most tools out there use > LAPACK > >> which doesn't support arbitrary precision so your input precision is > likely > >> irrelevant in this case. > >> > >> Cheers, > >> Simon > >> > >> > >> > >>> Thank you for the note, Dirk. I will keep in mind to send any future > >>> questions regarding Rcpp to the Rcpp-devel mailing list. I understand > >> that > >>> the type used in the Boost library for precision is not one of the > types > >>> supported by SEXP, so it will be more complicated to map between the > cpp > >>> codes and R. Given Rmpfr doesn't provide all necessary mpfr > calculations > >>> (and embarking on interfacing Eigen with Rmpfr is not a small task), > does > >>> taking input as strings seem like the best option for me to get precise > >>> inputs? > >>> > >>> Sincerely, > >>> Khue > >>> > >>> On Fri, Jul 19, 2024 at 8:29 AM Dirk Eddelbuettel <e...@debian.org> > >> wrote: > >>> > >>>> > >>>> Hi Khue, > >>>> > >>>> On 19 July 2024 at 06:29, Khue Tran wrote: > >>>> | I am currently trying to get precise inputs by taking strings > instead > >> of > >>>> | numbers then writing a function to decompose the string into a > >> rational > >>>> | with the denominator in the form of 10^(-n) where n is the number of > >>>> | decimal places. I am not sure if this is the only way or if there > is a > >>>> | better method out there that I do not know of, so if you can think > of > >> a > >>>> | general way to get precise inputs from users, it will be greatly > >>>> | appreciated! > >>>> > >>>> That is one possible way. The constraint really is that the .Call() > >>>> interface > >>>> we use for all [1] extensions to R only knowns SEXP types which map > to a > >>>> small set of known types: double, int, string, bool, ... The type > used > >> by > >>>> the Boost library you are using is not among them, so you have to add > >> code > >>>> to > >>>> map back and forth. Rcpp makes that easier; it is still far from > >> automatic. > >>>> > >>>> R has packages such as Rmpfr interfacing GNU MPFR based on GMP. Maybe > >> that > >>>> is > >>>> good enough? Also note that Rcpp has a dedicated (low volume and > >> friendly) > >>>> mailing list where questions such as this one may be better suited. > >>>> > >>>> Cheers, Dirk > >>>> > >>>> [1] A slight generalisation. There are others but they are less > common / > >>>> not > >>>> recommended. > >>>> > >>>> -- > >>>> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > >>>> > >>> > >>> [[alternative HTML version deleted]] > >>> > >>> ______________________________________________ > >>> R-package-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel > >>> > >> > >> > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
