similar to: Looking for greater floating-point precision

Full_Name: D Kreil Version: 2.8.1 and 2.9.0 OS: Debian Linux Submission from: (NULL) (141.244.140.179) Group: Accuracy I understand that most floating point numbers are approximated due to their binary storage. On the other hand, I thought that modern math CPUs used guard digits to protect against trivial underflows. Not true? # integers, no problem > 1+1+1==3 [1] TRUE # binary floating

Full_Name: D Kreil Version: 2.8.1 and 2.9.0 OS: Debian Linux Submission from: (NULL) (141.244.140.179) Group: Accuracy I understand that most floating point numbers are approximated due to their binary storage. On the other hand, I thought that modern math CPUs used guard digits to protect against trivial underflows. Not true? # integers, no problem > 1+1+1==3 [1] TRUE # binary floating

There has been a recent thread on R-help on this, which resurrected concepts from bug reports PR#1228 and PR#6743. Since the discussion has included a lot of erroneous 'information' based on misunderstandings of floating-point computations, this is an attempt to set the record straight and explain the solutions adopted. The problem was that var(rep(0.02, 10)) was observed to be (on

We have a problem inverting a matrix which has the following eigenvalues: > eigen(tcross, only.values=TRUE) $values [1] 7.917775e+20 2.130980e+16 7.961620e+13 8.241041e+12 2.258325e+12 [6] 3.869428e+11 6.791041e+10 2.485352e+09 9.863098e+08 9.819373e+05 [11] 3.263408e+05 2.929853e+05 2.920419e+05 2.714355e+05 8.733435e+04 [16] 8.127136e+04 6.543883e+04 5.335074e+04

Just been trying to get the polygon triangulation code from this package: http://www-2.cs.cmu.edu/~quake/triangle.html to dyn.load into R. Uh oh. Floating point exceptions. Track it down to some FPU diddling that the author deems is necessary. Here's my minimal code that breaks: flipme.c: #include <fpu_control.h> void flipme(){ int cword; cword=4210; _FPU_SETCW(cword);

Hi, I'm sure that this question has come up many times before. When I load an R extension dll I've built with the Microsoft compiler, I get the warning: Warning message: DLL attempted to change FPU control word from 8001f to 9001f So, what I did to try to fix the problem (to my knowledge, Microsoft will not support compile time switching of floating point control until version

Hi Manoj, I tried a few other options myself: * function 'target' attribute - the list of extensions this supports isn't complete and it doesn't enable the ACLE macros needed for intrinsics * manually defining ACLE macros - this allows intrinsics and is additive but assumes that you're not relying on codegen to emit instructions. I don't think it helps the bug linked

On 06/16/2015 06:21 PM, Daniel Sanders wrote: > > > > the best I can suggest is to target mips2 and O32 > > > > It's not work for all, still get Assembler messages error on some > source files > > > > > Warning: float register should be even, was 7 > > Could you add –save-temps to the compiler command and send me the > command along with the

Hi, I am not sure if this is just me using R (R-2.3.1 and R-2.4.0) in the wrong way or if there is a more serious bug. I was having problems getting some calculations to add up so I ran the following tests: > (2.34567 - 2.00000) == 0.34567 <------- should be true [1] FALSE > (2.23-2.00) == 0.23 <------- should be true [1] FALSE > 4-2==2 [1] TRUE > (4-2)==2 [1] TRUE >

Hello Paul and Simon, (Sorry - I'm not sure about the social conventions in mailing lists) Both of your answers helped me a lot! So If I understand it correctly, Clang knows what 'mips1' and 'mips5' are - but can't generate code for it? Why is it like that? I actually have a more in general questions about processors... If this is the wrong place for it, please ignore it,

Hi Manoj, Not too late at all, we have not got to that point of the work yet. Are there examples of this kind of build setup that are available publicly? I think I understand the problem but it'd help to see one in action. To see if there are any other Arm extensions that are already being added like this and whether those systems support GCC and how. Thanks, David Spickett.

Hi, Below is a document detailing changes we'd like to make to Clang/LLVM to improve the usability of the target options for ARM and AArch64. To keep things simple the proposed changes are listed at the start and you can find the supporting examples at the end of the document. I look forward to your feedback. Thanks, David Spickett. RFC New Clang target feature selection options for

Hello, is there a possibilty in R to convert numbers (double precision, 64bit) into single precision ones (32bit). I need that for compatibility reasons. Until now I call a C application which casts a double to a float. float precision32(double value) { return (float)value; } But I want to use a R only method. What can I do? Kind regards, Sebastian

Hi all, How can I get R to change the default precision value? For example: > x=0.99999999999999999 > 1-x [1] 0 > Is there a way that I can get a non-zero value using some parameter, or some package? many thanks. [[alternative HTML version deleted]]

Thanks for the response. If we add the support would you accept the patch? Seems like a pretty straightforward flag since it maps directly to NumericLiteralParser::NumericLiteralParser within LiteralSupport.cpp. I understand the maintenance concern with flags that affect multiple points in code though. Still trying to get the bottom of why we're crashing with double floating point literal.

Dear list, When using as.POSIXlt with times measured down to microseconds the default format.POSIXlt seems to cause some possibly undesirable behaviour: According to the code in format.POSIXlt the maximum accuracy of printing fractional seconds is 1 microsecond, but if I do; options( digits.secs = 6 ) as.POSIXlt( 1.000002 , tz="", origin="1970-01-01") as.POSIXlt( 1.999998 ,

Does anyone have suggestions for either extending operators or adding intrinsics that support multiple return values? Or is packaging everything into a derived types the only way? I have an idea for supporting floating-point exception flags and modes in a flexible way by making the data dependencies explicit, but I've become quite lost poking around. I suspect this will end up involving

Hi, If R is compiled for a 64 bit platform, does the double data type make use of the additional precision or is it set at a fixed length? Thanks, Paul

On Tue, 18 Apr 2006 23:27:39 -0700 Evan Cheng <evan.cheng at apple.com> wrote: > Hi Simon, > > The x86 backend does generate scalar SSE2 instructions. For your > example, it should emit something like: Oh, how did you get this ? [...] > > There is nothing here that should cause an exception. Are you using a > release or cvs? CVS. >From what I remember,

On 06/12/2015 07:12 PM, Daniel Sanders wrote: > > Hi, > > I'm afraid targeting a 64-bit CPU and the O32 ABI is completely broken > at the moment, it's one of the very long-standing issues I'm working > towards. The main problem is that a lot of the internals of the Mips > LLVM backend derive their behaviour from the target CPU rather than > the target ABI.