rounding-error

This question already has an answer here: Is floating point math broken? 31 answers Math precision requirements of C and C++ standard 1 answer I have a program that were giving slithly different results under Android and Windows. As I validate the output data against a binary file containign expected result, the difference, even if very small (rounding issue) is annoying and I must find a way to fix it. Here is a sample program: #include <iostream> #include <iomanip> #include <bitset> int main( int argc, char* argv[] ) { // this value was identified as producing different result when used as

How do I prevent R from rounding? For example, > a<-893893084082902 > a [1] 8.93893e+14 I am losing a lot of information there. I have tried signif() and it doesn't seem to do what I want. Thanks in advance! (This came up as a result of a student of mine trying to determine how long it would take to count to a quadrillion at a number per second) It's not rounding; it's just the default format for printing large (or small) numbers. a <- 893893084082902 > sprintf("%f",a) [1] "893893084082902.000000" See the "digits" section of ?options for a global solution. To get around R's integer limits, you

I'm wanting to find the number of mantissa digits and the unit round-off on a particular computer. I have an understanding of what these are, just no idea how to find them - though I understand they can vary from computer to computer. I need this number in order to perform certain aspects of numerical analysis, like analyzing errors. What I'm currently thinking is that I could write a small c++ program to slowly increment a number until overflow occurs, but I'm not sure what type of number to use. Am I on the right track? How exactly does one go about calculating this? I would think that

I am curious about the existence of any "rounding" standards" when it comes to the calculation of financial data. My initial thoughts are to perform rounding only when the data is being presented to the user (presentation layer). If "rounded" data is then used for further calculations, should be use the "rounded" figure or the "raw" figure? Does anyone have any advice? Please note that I am aware of different rounding methods, i.e. Bankers Rounding etc. The first and most important rule: use a decimal data type , never ever binary floating-point types. When exactly rounding should be performed

I want to convert a time_duration to a DATE format, which is the number of days since 1899, 12, 30. DATE date_from_duration(time_duration td) { double days = td.hours()/24.+td.minutes()/(24.*60.)+td.seconds()/(24.*60.*60.); return days; } This code almost works but gives sometimes rounding errors, f.i the time_duration(1007645, 15, 0) should result in 2014-12-12 00:15:00, but is actually 2014-12-12 00:14:59. The check of DATE is done with this method, stolen from here : ptime pTime_from_DATE(double date) { using boost::math::modf; static const ptime::date_type base_date(1899, Dec, 30); static

In C# Is there any difference in the accuracy of the two decimal rounding strategies MidpointRounding.ToEven and MidpointRounding.AwayFromZero ? I mean do both ensure an even distribution amongst the numbers that are rounded to, or is one rounding strategy over representing the rounded numbers compared to the other? From MSDN: By default, Math.Round uses MidpointRounding.ToEven. Most people are not familiar with "rounding to even" as the alternative, "rounding away from zero" is more commonly taught in school. .NET defaults to "Rounding to even" as it is statistically superior because it doesn