Talk:Rounding

Redundant with Significant figures/Rounding?

This page is basically redundant with Significant figures#Rounding, but I feel that this is better written, so warrants merging instead of deleting. ~ Irrel 17:33, 28 September 2005 (UTC)

Please restrain yourself. They are very different subjects. And this page doesn't describe rounding very well. --Cat5nap 05:46, 3 October 2005 (UTC)

The discussion at Talk:Significant figures#Merge is overwhelmingly against the suggested merge of Rounding with Significant figures. I suggest the tags be removed. If anything, I'd consider merging with Truncation. Jimp 13Oct05

• Well, this got resolved pretty much as I intended (altho the merge went the other way). Regardless, I hardly think putting up a "merge?" template shows a lack of restraint, seeing as it's just a request for input. Actually doing the merge, with no discussion -- now that'd be un-restrained. ~ Irrel 20:20, 13 May 2006 (UTC)

Rounding rule error

"but if the five is succeeded by nothing, odd last reportable digits are decreased by one" Shouldn't this be increased?68.227.80.79 05:44, 13 November 2005 (UTC)

Yes. Thanks for spotting this! -- Jitse Niesen (talk) 12:21, 13 November 2005 (UTC)

Hopefully the revisedversion of the article gotthis right too. --Jorge Stolfi (talk) 05:52, 1 August 2009 (UTC)

I had a question about whether everyone in the world rounds the same way. In the US, there are two common methods. The first needs little explanation and is even programmed into things like MS Excel. The other is sometimes called scientific rounding or rounding to even on 5. I'm asking because I run into a lot of foreign professionals who round differently, so I didn't know if they were out of practice or taught differently. From a philosophical view, it would actually make sense to round to significant figures by simple truncation, because anything beyond the "best guess" digit is considered noise and should have no impact on the reported value. I once asked myself which of the two rounding methods used in the US is best. I approached the question with the assumption that the noise digits were random and equally likely to appear. If I have a set of values with all possible noise digits and calculate the mean and standard deviation, and then repeat the mean and standard deviation calculation after rounding all of the values, the best method would not deviate from the true mean and standard deviation. It turned out that the round to even on 5 method actually gave a more accurate mean, but the most popular rounding method gave a more accurate standard deviation. I don't know if any of this would be of interest for this lesson on rounding, but thought that I'd mention it. John Leach (talk) 21:52, 6 July 2020 (UTC)

Rounding negative numbers.

How are negative numbers handled? According to the article round(-1.5) = -2, which is wrong, right? round(-1.5) = -1 I believe.

There are many different implementations. — Omegatron 19:59, 30 June 2006 (UTC)

There are many implementations, and very few are covered in this article. Here's an external article which covers the field [1]. Hopefully someone has time to incorporate the information from that article without engaging in copyvio. -Harmil 15:55, 14 July 2006 (UTC)

Negative numebrs should be properly covered in the current version. --Jorge Stolfi (talk) 05:52, 1 August 2009 (UTC)

The Rounding of ALL numbers, requires the rounding of the absolute value of the number, and then replace the original sign (+ or -). The above answer is "-2", and not "-1". If the number preceding a "5" is ODD, then make it EVEN by adding "1". If the number preceding a "5" is EVEN, then leave it alone. As there are an equal amount of ODD numbers and EVEN numbers in the counting system.

Example; "1.6 - 1.6 = 0", "1.6 + (-1.6) = 0", rounding to the 1's unit is "2.0 + (-2.0) = 0" as |-1.6| is 1.6, rounded gives us "2.0".
Example; "1.4 - 1.4 = 0", "1.4 + (-1.4) = 0", rounding to the 1's unit is "1.0 + (-1.0) = 0" as |-1.4| is 1.4, rounded gives us "1.0". 
Example; "1.5 - 1.5 = 0", "1.5 + (-1.5) = 0", rounding to the 1's unit is "2.0 + (-2.0) = 0" as |-1.5| is 1.5, rounded gives us "2.0".
Example; "2.5 - 2.5 = 0", "2.5 + (-2.5) = 0", rounding to the 1's unit is "2.0 + (-2.0) = 0" as |-2.5| is 2.5, rounded gives us "2.0".

The Rounding of a number can never give a value of "0.0".

The rounding depends on the type of rounding being done. Rounding to even is normally explained as rounding to the nearest even number without talking about absolute numbers or adding or anything like that. The numbers 0.5 and -0.5 will both round to 0.0 when using round to even, I don't know why you say what you said about it.. Dmcq (talk) 19:29, 9 September 2009 (UTC)

Organization

I don't know if it's a good idea to merge with floor function, but they are related. A sort of "family tree" of rounding functions:

• Floor
• Ceiling
• Half round
  • Half round up
    • Where up is +∞
    • Where up is away from zero
  • Half round down
    • Where down is −∞
    • Where down is towards zero
  • Half round even
  • Half round odd

Which method introduces the most error?

From the "Round-to-even method" section in this article, as of right now:

"When dealing with large sets of scientific or statistical data, where trends are important, traditional rounding on average biases the data upwards slightly. Over a large set of data, or when many subsequent rounding operations are performed as in digital signal processing, the round-to-even rule tends to reduce the total rounding error, with (on average) an equal portion of numbers rounding up as rounding down."

Huh? Doesn't traditional rounding have an equal portion of numbers rounding up and down? In traditional rounding, numbers between 0 and <5 are rounded to 0, while numbers between 5 and <10 are rounded to 10, if 10 is an increase in the next highest digit of the number being rounded. The difference of (<10 - 5) equals the difference of (<5 - 0), doesn't it? Am I missing something? 4.242.147.47 21:13, 19 September 2006 (UTC)

In four cases (1, 2, 3 and 4) the value is rounded down. In five cases (5,6,7,8,9) the value is rounded up. In one case (0) the value is left unchanged. This may be what you were missing. 194.109.22.149 15:14, 28 September 2006 (UTC)

But "unchanged" is not entirely correct, as there may be further digits after the 0. For example, rounded to one decimal place, 2.304 would round to 2.3; it is not unchanged under the traditional rounding scheme, but rather rounded down, thus making five cases for rounding down and five for rounding up.

If we consider rounding all of 0.00, 0.01, ..., 1.00 (101 numbers) to the nearest one, we get 50 0s and 51 1s. The total amount of down-rounding is $-0.01+-0.02+...=\sum _{i=1}^{49}-i/100=-12.25$, but the amount of up-rounding is $0.50+0.49+...=\sum _{i=1}^{50}i/100=12.75$. The average error is thus ${\frac {-12.25+12.75}{101}}=0.0049505$. Importantly, this imbalance remains even if we exclude 1 (where you get 50 numbers going each way), and the average error increases (to precisely half the last digit specified; this is not a coincidence). This is the bias; because it doesn't depend on the granularity of the rounding but rather of the data, it's easy to miss. --Tardis 07:10, 31 October 2006 (UTC)

The number 1.00 should not appear in this calculation. We're interested in rounding the interval [0.00, 1.00) -- that is, all numbers >= 0.00 and < 1.00 (strictly smaller than 1). Once the number 1.00 is removed from the above paragraph, the imbalance disappears (contrary to what's written above). In reality, there is no imbalance in the regular rounding - the interval [0, 0.5) has the same length as the interval [0.5, 1).

But, like 1.00, 0.00 is also not rounded. So the intervals would be (0, 0.5) and [0.5, 1) ; this results in a bias upwards. —The preceding unsigned comment was added by 85.144.113.76 (talk) 00:06, 20 January 2007 (UTC).

If you look at the calculation a bit more closely, you'll see it sums the difference between the number to be rounded and the result of the rounding. In both the 0.00 and 1.00 cases this is 0, so it doesn't matter if you include them in the summation or not.

Tardis said: "This is the bias; because it doesn't depend on the granularity of the rounding but rather of the data, it's easy to miss." This is the crucial point. If the data is quantised (granular) then the error is related to the size of the quantisation. But for any physical process the numbers involved are normally not quantised hence there is no bias at all. If you repeat the calculation above with a rounding granularity of 0.1 still but a data granularity of 0.0001 (say) then you will see this in action. Thus, the conclusion is that if the data set you are rounding has no quantisation, you should use "0.5 goes up" rounding not bankers rounding. 137.222.40.78 (talk) 13:18, 23 May 2008 (UTC)

If your data have "no quantization" (including no discrete probability accumulations), then you can round 0.5 to 23 if you like. It almost never happens, so what does it matter what you do with it? In the real world, this limit is never accessed. --Tardis (talk) 11:11, 9 November 2008 (UTC)

I was just thinking about this issue too, but am convinced that there is an imbalance in rounding 0.5 to 1. Consider the ten values 0.0, 0.1, 0.2 ... 0.9, 1.0. Each covers a 0.1 range. 0.0 covers -0.05 to 0.05. 0.1 covers 0.05 to 0.15. 1.0 covers 0.95 to 1.05. If you want to round to whole values, you have 0 and 1 available. 0 covers -0.5 to 0.5, and 1 covers 0.5 to 1.5. 0.0 through 0.4 thus clearly convert to 0, and 0.6 through 1.0 clearly convert to 1. 0.5's range is perfectly divided in two by the ranges that 0 and 1 cover. Converting 0.5 to 0 is just as valid as converting it to 1. The only way to decide which is better is to examine the context; I don't see any clear correct choice for all cases, since either direction involves tradeoffs. 72.48.98.66 (talk) 12:27, 20 June 2010 (UTC)

Yes that's why round to even is used, it means half of them are rounded up and half down. Round to even is used insted of round to odd so you are less likely to get odd digits in particular 5 at the end in subsequent calculations which means you do less rounding overall. Dmcq (talk) 12:50, 20 June 2010 (UTC)

To weigh in on this little debate, rounding 0.5 up leads to a more uniform distribution of values in the decimal system as a whole. If you divide numbers into sets of 10 with n representing everything but the least significant digit n0-n9 is 10 numbers with the next number being part of the next set(n10 which means that the 1 "carries over"). Since the rounding discussed is concerned with the decimal number system you have to follow the divisions of that system. In other words rounding can be viewed as an operation on all possible values of the least significant digit of a number (and viewed recursively for extension), which means that only the values for the least significant digits should be changed, once you change a number in any other place you're introducing a new set (and would have to introduce the full set for consistency). So 5 numbers down 0-4, 5 numbers up 5-9 (notice there's only one "0"). I'd image the round to even system stems from the issue that the "0" isn't being rounded. Therefore, when dealing with sets of data where exact values are for some reason excluded or less likely than values which are to be rounded, some of the balance needs to be shifted around. The main reason I'm chiming is that it appears as though "asymmetric" in the article regarding round 0.5 up is used incorrectly, so this should either be cited or removed. -mwhipple —Preceding unsigned comment added by 98.229.243.133 (talk) 18:13, 1 October 2010 (UTC)

And to expand a bit from above, the rounding to even method is probably more appropriate when dealing with less certain sets (i.e. there is an ill-defined, unknown, or otherwise troublesome minimum or maximum). —Preceding unsigned comment added by 98.229.243.133 (talk) 18:22, 1 October 2010 (UTC)

Oh...and rounding to even would be a convenient way to offset rounding issues caused by the problems with floating point representation in computers. —Preceding unsigned comment added by 98.229.243.133 (talk) 19:07, 1 October 2010 (UTC)

Disregard most the above, aside from the bit about the misuse of asymmetric. I was too caught up with the number system I lost sight of the values. Rounding is changing values and therefore the significant set is the inexact numbers (and the cumulative change accrued). The argument below is a bit out of context (though does highlight some of my poor wording) —Preceding unsigned comment added by 98.229.243.133 (talk) 22:31, 1 October 2010 (UTC)

The numbers are considered to be rounded to the precision and cover a range slightly below as well as above the exact number. So 0.5 means anything in the range 0.45 to 0.55, it does not mean from 0.5 to 0.6. Your initial argument about 0.0 .. 0.9 is wrong, the ones from -0.05 to 0.05 should go to 0.0, it is not rounding 0.0 to 0.1 to 0.0 Dmcq (talk) 19:28, 1 October 2010 (UTC)

I am amazed that any serious scientist could argue that there are either are either x+1 or x-1 numbers between integers in a base 10 system. When fully discreet, there are an equal amount of numbers that go to the lower integer as the higher integer. 2.0, 2.1, 2.2, 2.3 and 2.4 go to 2. 2.5, 2.6, 2.7, 2.8 and 2.9 go to 3. 5 each. The same would have been true from 1.0 - 1.9 and then from 3.0 t- 3.9. Every single integer will have 10 numbers that can result in that rounding. The tie-breaking rule is silly, and as engineers have known for years, wrong. If you want the true answer, you never analyze rounded numbers! You must use the actual values to beyond at least one significant digit to what you are trying to analyze. This is confusing, unnecessarily, kids in school today. Go back to what we have known for years, and can be proven to be correct. And never, ever analyze rounded numbers to the same significant digit if you know the data set is more discreet. — Preceding unsigned comment added by 24.237.80.31 (talk) 04:24, 3 November 2013 (UTC)

This depends on the model and the context. You can assume a uniform distribution in the interval [0,1], in which case the midpoint 0.5 appears with a null probability, so that under this assumption, the choice for half-points doesn't matter. In practice, this is not true because one has specific inputs and algorithms, but then, the best choice depends on the actual distribution of the inputs (either true inputs of a program or intermediate results). Vincent Lefèvre (talk) 13:37, 20 April 2015 (UTC)

Another Method ?

There seems to be at least one other method; rounding up or down with probability given by nearness.

It is given in javascript by
R = Math.round(X + Math.random() - 0.5)

It has the possible advantage that the average value of R for a large set of roundings of constant X is X itself.

82.163.24.100 11:51, 29 January 2007 (UTC)

This is called "dithering". Added a section on it. --Jorge Stolfi (talk) 05:41, 1 August 2009 (UTC)

The dithering section says "This is equivalent to rounding y + s to the nearest integer, where s is a random number uniformly distributed between 0 and 1". I'm not a mathematician, so I'm probably missing something, but that seems to round your example to 23 with probability .33 and to 24 with probability .67 instead of .83 and .17. Should be "rounding y+s toward 0" ? (for y>=0 anyway) M frankied (talk) 18:31, 9 August 2010 (UTC)

Yes it should have said rounding down instead of rounding to nearest, I've updated the text. Dmcq (talk) 18:42, 9 August 2010 (UTC)

Why are halfway-values rounded away from zero?

Can somebody please tell me, why is it - and why does it make sense - that we round, say, 1.5 to 2 and not to 1? Here's my thinking: 1.1, 1.2, 1.3 and 1.4 go to 1 - 1.6, 1.7, 1.8, 1.9 go to 2. So 1.5 is of course right in the middle. Why should we presume it's more 2ish than 1ish, if it's equally close? Do you think it's just because teachers are nice, and when they do grade averages, they want to give you a little boost, rather than cut you down? Is there some philosophical or mathematical justification? Wikidea 23:38, 6 February 2008 (UTC)

You forgot 1.0. —Preceding unsigned comment added by 207.245.46.103 (talk) 19:08, 7 February 2008 (UTC)

I also left out 2.0, surely? Wikidea 19:41, 7 February 2008 (UTC)

I do not see a good reason. A convention is useful, but it could have been the other way around.--Patrick (talk) 23:46, 7 February 2008 (UTC)

That's exactly what I'm thinking too! So maybe it's true: Maths teachers were just being nice in marking up students' average test results! They could've had the convention the other way indeed. Wikidea 00:01, 8 February 2008 (UTC)

Or vendors invented it for finding the price of half a unit. But it is more likely that they round up all broken values, not only those halfway.--Patrick (talk) 00:22, 8 February 2008 (UTC)

Refer to the discussion above, the "Which method introduces the most error?" question. I guess I retract my 1.0 statement. —Preceding unsigned comment added by 207.245.46.103 (talk) 18:30, 8 February 2008 (UTC)

Hopefully the current version of the article makes it clear that it is just an arbitrary choice (and some choice is needed). All the best, --Jorge Stolfi (talk) 05:47, 1 August 2009 (UTC)

Problem with decimal rounding of binary fractions

The floating point unit on the common PC works with IEEE-754, floating binary point numbers. I have not seen addressed in this page or this talk page the problem of doing rounding of the binary fraction numbers to a specified number of decimal fraction digits. The problem results from fact that variables with binary point fractions cannot generally exactly represent decimal fraction numbers. One can see this from the following table. This table is an attempt to represent the numbers from 1.23 to 1.33 in 0.005 increments.

ExactFrac   Approx.   Closest IEEE-754 (64-bit floating binary point number)
1230/1000    1.230    1.229999999999999982236431605997495353221893310546875
1235/1000    1.235    1.2350000000000000976996261670137755572795867919921875
1240/1000    1.240    1.2399999999999999911182158029987476766109466552734375
1245/1000    1.245    1.24500000000000010658141036401502788066864013671875
1250/1000    1.250    1.25
1255/1000    1.255    1.25499999999999989341858963598497211933135986328125
1260/1000    1.260    1.2600000000000000088817841970012523233890533447265625
1265/1000    1.265    1.2649999999999999023003738329862244427204132080078125
1270/1000    1.270    1.270000000000000017763568394002504646778106689453125
1275/1000    1.275    1.274999999999999911182158029987476766109466552734375
1280/1000    1.280    1.2800000000000000266453525910037569701671600341796875
1285/1000    1.285    1.2849999999999999200639422269887290894985198974609375
1290/1000    1.290    1.29000000000000003552713678800500929355621337890625
1295/1000    1.295    1.2949999999999999289457264239899814128875732421875
1300/1000    1.300    1.3000000000000000444089209850062616169452667236328125
1305/1000    1.305    1.3049999999999999378275106209912337362766265869140625
1310/1000    1.310    1.310000000000000053290705182007513940334320068359375
1315/1000    1.315    1.314999999999999946709294817992486059665679931640625
1320/1000    1.320    1.3200000000000000621724893790087662637233734130859375
1325/1000    1.325    1.3249999999999999555910790149937383830547332763671875
1330/1000    1.330    1.3300000000000000710542735760100185871124267578125

The exact result of doing the division indicated in the first column is shown as the long number in the third column. The intended result is in the second column. The thing to note is that only one of the quotients is exact; the others are only approximate. Thus when we are trying to round our numbers up or down, we cannot use rules based on simple greater-than, less-than, or at some exact decimal fraction value, because, in general, these decimal fraction values have no exact representation in binary fraction numbers. JohnHD7 (talk) 22:08, 28 June 2008 (UTC)

This isn't unique to decimal fractions and is covered reasonably well at floating point. Floating point operations have a finite precision, which lead to rounding errors, which can stack. If you need your code to generate a certain number of accurate decimal (or binary, etc.) places, or to satisfy some other accuracy criterium, you should check that the worst-case deviation your code could generate stays within limits. Shinobu (talk) 07:18, 8 November 2008 (UTC)

Round to even

I've seen two sources that claim that it's correct to round (e.g.) 2.459 to 2.4 rather than 2.5, though they both give the same bogus logic: that 2.45 might as well be rounded to 2.4 as to 2.5, and so this also applies to 2.459, even though this is a different number and is obviously closer to 2.5. But are we sure this isn't standard practice in some crazy field or other? Evercat (talk) 20:51, 17 September 2008 (UTC)

That isn't a valid rounding method, as the result can deviate significantly more than half an integral step from the original. If it's actually in use somewhere the users should get a rap on the knuckles. Perhaps, if its use were to cause a big scandal, it might be appropriate to document that on Wikipedia, but in the meantime it lacks notability. Shinobu (talk) 07:07, 8 November 2008 (UTC)

Agreed. Those sources are probably just plain wrong. --Jorge Stolfi (talk) 05:44, 1 August 2009 (UTC)

Rounding 2.50001 to nearest integer

Please comment: rounding 2.50001 to the nearest integer. Is it 2 or 3? Redding7 (talk) 01:42, 5 January 2010 (UTC)

Definitely 3 (distance from 2.50001 to 2 is 0.50001, to 3 is 0.49999, so the latter is nearest). --Jorge Stolfi (talk) 03:02, 5 January 2010 (UTC)

Consistency

Please edit ‘Rounding functions in programming languages’ for naming consistency. I'm not sure which names you prefer, so I'll let you do it, but please be consistent. Shinobu (talk) 07:07, 8 November 2008 (UTC)

Needs fixing

The section "Common method" does not explain negative numbers. The first example of negative just says "one rounds up as well" but shows different behavior for the case of 5, otherwise the same as positive. The second example is supposed to be the opposite but shows the same thing! It calls it "down" instead of "up", but gives the same answer. —Długosz (talk) 19:55, 18 February 2009 (UTC)

The section has been thoroughly rewritten. Please check if the problem has been fixed. --Jorge Stolfi (talk) 05:42, 1 August 2009 (UTC)

Useof "-0" by meteorlogists

The article claims that

"Some meteorologists may write "-0" to indicate a temerature between 0.0 and −0.5 degrees (exclusive) that was rounded to integer. This notation is used when the negative sign is concidered important, no matter how small is the magnitude; for example, when giving temperatures in the Celsius scale, where below zero indicates freezing."

I am bothered by this paragraph because (1) evidence should be provided that meteorologists actualy do this; it may well be an original invention by the editor. Also (2) tallying days with negative temperature seems a rather unscientific idea, since even small errors in measurement could lead to a large error in the result. If the station's thermometer says -0.4C or -0.1C, it is not certain that street puddles are freezing. On the other hand, if the thermometer says +0.1C or +0.4C, the puddles may be freezing nonetheless. To compare the harshness of weather, one shoudl use a more robust statistic, such as the mean temperature. Therefore, there does not seem to be a good excuse for preserving the minus sign. All the best, --Jorge Stolfi (talk) 06:03, 1 August 2009 (UTC)

Another 'Bankers' or 'Accounting' Rounding Method?

I recall reading about a method (I believe on Wikipedia) some months and/or years ago, allegedly used in some banking systems to not acrue (or lose) pennies or cents over time, it was rounded as follows, if I recall correctly:

$XX.XXY was rounded 'up' if Y was odd, and 'down' id Y was even. (5 of the 10 options going in each direction)

Eg:

$10.012 was rounded to $10.00

$10.013 was rounded to $10.01

$10.014 was rounded to $10.00

$10.015 was rounded to $10.01

$10.016 was rounded to $10.00

$10.017 was rounded to $10.01

I forget how it handled negative cases... The 'bankers round' (Round half to even) given, does perform one of the same purposes of symetric rounding, but in a different way, potentially with a bias that's relevant to finances, and I'm wondering if the article is missing this method (and if so, if it's worth someone who knows the details accurately adding it), if it's documented elsewhere on wikipedia, or if it's even been used at all, or was wrong in my source previously! (Possibly Wikipedia, iirc). The advantages of it seemed to basically be 'random' with even distribution in the sense that things are not moving to the closest number at the required level of precision, where identifiable, but with repeatable results. FleckerMan (talk) 01:03, 18 August 2009 (UTC)

Indeed it seems to be a different rounding method It should be added to the "Basic rounding to integer" section, but recast as rounding XXX.Y to integer. However, this method does not round to the nearest valid value. If I were a client of such a bank, I would feel cheated (even though the method is fair in the long run). 8-) --Jorge Stolfi (talk) 17:29, 18 August 2009 (UTC)

This is not Bankers/Accountants rounding, as I was taught to do it in accounting class, and as I have applied it in a number of business systems over the years.

I've done some google searching, but I have not yet found anything close to a decent reference for it.

Briefly, the "difference" caused by rounding one value (a fraction of a cent) is carried forward and added to the next result, right before rounding. That carries through all the way to the end. The objective is that if you're adding "p%" of interest to each one of a long line of accounts, then each one will get "p%" of interest (within a penny), and the final result will show that (total before interest) * (1+p%) = (total of the final amounts computed for each of the accounts). And yes, when done right, the final totals always do match.

So we should be looking for sources that say "start with 0.5 in your 'carry'. Add the 'carry' before rounding. Set the 'carry' to the amount 'gained' or 'lost' by this rounding."

-- Jeff Grigg 68.15.44.5 (talk) 00:44, 20 October 2017 (UTC)

"Rounding in language X" section

I deleted the long list of rounding functions in language X, Y, Z, ... It was not useful to readers (programmers will look it up in the language's article, not here), it was waaaaay too long (and still far from complete), and extremely repetitive (most languages now simply provide the four basic IEEE rounding functions -- trunc,round,ceil,floor). The lists were not discarded but merely moved to the respective language articles (phew!). All the best, --Jorge Stolfi (talk) 22:31, 6 December 2009 (UTC)

Looks much better without them. I've been wondering for a while what to do with such sections in a lot of articles. I think perhaps just some standard library implementation should be mentioned, certainly the lists of languages is excessive. Dmcq (talk) 23:22, 6 December 2009 (UTC)

The list of rounding IEEE basic functions is of course made of 4 functions, because in most cases it forgets to speak about negative numbers. This is where the rounding up or down are differentiated from rounding towards or from zero. Then for the "round" function, there are also 4 rounding modes, which are available for all floatting point operations, independantly of these rounding functions: it's about how ties are rounded : up or down ? Here again there are the same 4 modes, plus the 2 additional modes for round to nearest even and round to nearest odd... IEEE does not have any randomized rounding modes, and no support for dithering with variable biases (the only biases supported are 0 for floor and ceil function, and the related "truncate" function (round to zero), and 0.5 for the round function). IEEE also does not have the round to infinity (round from zero), and round to odd as they have no practical use....

However the "round to nearest integer, and round ties towards zero" has mathematical applications (notably when computing the shortest continuous fractions of any rational number) because of its symetry: the round to nearest property allows the continuous fractions to be reduced to the smallest form (with less terms), and the symetry allows a negative rational to have exactly the same terms (in absolute value) in the continuous fraction as the opposite positive rational. With less terms (caused by rounding to nearest), it also allows the continuous fractions to converge twice faster per term (so the number of terms is effectively divided by 2 on average when expressing any real number as continuous fractions: this is especially important when optimizing the speed of numeric computation of irrational functions, but also, it ensures a better numeric stability of the result when working with floatting point numbers (with limited precision), producing more exact numbers and monotonous approximations (if we use a limited number of terms when computing the continuous fraction approximants, starting by the last term)... verdy_p (talk) 01:54, 12 August 2010 (UTC)

There seems to be a lot of stuff that I don't remember seeing anywhere else here. I think I need to stick in a number of citations needed in the article. Dmcq (talk) 19:58, 12 August 2010 (UTC)

Round to even, again

I was considering adding this:

The advantage of "round to even" (if the radix is not a multiple of 4) is that it prevents the problem of halves from propagating. Consider 23.55: with a "round to odd" rule this would become 23.5 and then 23, though 24 would be nearer. Instead, 23.55 is rounded to 23.6 and then to 24.

This is explained in The Art of Computer Programming chapter 4, I think, which I'd cite if my copy were not hidden in a box somewhere. —Tamfang (talk) 03:04, 19 July 2010 (UTC)

Yes, and this is why "round ties to odd" is not part of standard IEEE-754 rounding modes (so it has no native support in x87 FPUs), and also explains why "round ties to even" is the default mode for floatting points in ANSI C, C++, Java, and many other languages supporting or using floatting point types (including Javascript, despite Javascript does not mandate any minimum precision for numbers, except that they are handled as if they were in decimal with infinite precision, as expressed in their source text representation). verdy_p (talk) 02:00, 12 August 2010 (UTC)

The reason is more that if you add two random numbers of about the same magnitude you're less likely to need to round the sum if they are the results of round to even, so you need less rounding operations overall. Dmcq (talk) 09:09, 12 August 2010 (UTC)

You'll still need rounding, because such addition of even numbers will just resist one time, before needing a new rounding again for the least significant bit. On average this will just divide by 2 the residual error created by accumulated values, i.e. it will just add one bit of precision to the sum. If you're cumulating lots of values, this single bit will rapidly not be very significant in the overall error remaining in the sum. So the assertion that "it prevents the problem of halves from propagating" is false. It just reduces the problem by 50%.

There's another model, "round to odd" that better preserves the magnitude, and so that it better prevents this propagation of errors (but also does not prevent it completely). Unfortunately it is not the default rounding mode.

In all cases, there's simply no way to prevent the propagation of errors with any isolated rounding mode, except if roundoff errors are cumulated separately from the main cumulated values, so that they can finally be taken into account in the sum when they reach some threshold.

The effect of this separation of errors is exactly equivalent to computing the sum with an accumulator with a higher precision (i.e. the precision of the final sum to return, and the precision of the error accumulator), so it is just simpler to compute the sum directly with this extra precision.

For example when rounding 64-bit double elements into a 32-bit float, sum the original values into a 64-bit double, and use that high-precision sum to finally round the sum to a 32-bit float: this also explains why C and C++ are automatically promoting float values to double within expressions, and rounding only the result of the full expression back into 32-bit float, if the expression has the float semantics (i.e. was not explicitly promoted to double); in all other cases, the compiler will warn the programmer about possible loss of precision.

However this automatic promotion without intermediate rounding to the precision of floats will not occur if the function is compiled with the "strict floatting point" semantic, where rounding will occur after each operation, even if this creates larger roundoff errors in the final result of expressions. The "relaxed" and "strictfp" computing modes also exist in Java. Generally it is a bad idea to use the "strictfp" rounding mode, unless you want strict portability with systems that don't have support for computing with 64-bit double precision (such systems are now extremely rare).

In fact, C and C++ can also compute expressions by also implicitly promoting also 32-bit float and 64-bit double into a more precise long double (typically 80-bit wide on x87 systems) within expressions. The effective rounding will to 32-bit or 64-bit only occur when storing the result into a float or double variable, or when passing it as a parameter to a function, a constructor or a method. Here again the "strictfp" computing mode can force the comoiler to round all intermediate long double values to their semantic 32-bit or 64-bit type.

In C, C++ and Java (and probably also in many other languages supporting the IEEE 754 standard), the "strictfp" computing mode is not the default and must be specified explicitly, either in the source code with additional modifier keywords in the function declaration or in a statements block declaration (or sometimes within a parenthesed subexpression), or by using a specific compiler option. The compiled code will be less efficient due to the additional rounding operations that will be compiled and executed at runtime. verdy_p (talk) 23:47, 12 August 2010 (UTC)

Would you please stop just asserting things and put in some citations instead. Loads of waffling does not make what you say any better. Dmcq (talk) 07:43, 13 August 2010 (UTC)

The "7-up" rule?

I was taught that "round half to even" is also called the "7-up" rule. Does anybody else know about this? 216.58.55.247 (talk) 00:36, 26 December 2010 (UTC)

Why would it be called that? Oli Filth^{(talk|contribs)} 00:52, 26 December 2010 (UTC)

No never heard of it. Sounds like some teacher's idea. I'd guess the idea is that 7-up is written with a point after the 7 and 7.5 would round up to 8 as 7 is odd. Just my guess. Dmcq (talk) 10:09, 26 December 2010 (UTC)

Chopped dithering and scaled rounding

I've cut down the sections on dithering and scaled rounding. The dithering is better dealt with elsewhere. The scaled rounding had no citations and was long and rambling and dragged in floating point for no good reason. Dmcq (talk) 23:30, 10 December 2011 (UTC)

Rounding with an odd radix

With particular reference to Rounding § Double rounding, it seems significant that when an odd radix is used, AFAICT multiple rounding is stable provided that we start with finite precision (actually a broader class of values that excludes only a limited set of recurring values). Surely work has been published on this, and it would be relevant for mentioning in this article? — Quondum 06:17, 20 November 2012 (UTC)

Hmm. It looks to me as though there is little to nothing published on this. Pity. —Quondum 19:21, 23 April 2015 (UTC)

The reason may be that an odd radix is never used in practice (except radix 3 on the Setun in the past). Vincent Lefèvre (talk) 22:08, 23 April 2015 (UTC)

Maybe it is not all that bad; Google searching on "Setun" and "rounding" pops up some results. Consider [2], Balanced ternary ("Donald Knuth has pointed out that truncation and rounding are the same operation in balanced ternary"), [3] ("ideal rounding is achieved simply by truncation") – this may be sufficient reference for this article. We'd have to make some obvious inferences, such as that repeated ideal rounding is still ideal rounding. We could restrict the comment to the sourced ternary case, though it should apply unchanged to any odd radix. —Quondum 23:05, 23 April 2015 (UTC)

Von Neumann rounding and sticky rounding

I wonder whether a paragraph should be added on Von Neumann rounding and sticky rounding, or this is regarded as original research (not really used in practice except internally, in particular no public API, no standard, no standard terminology...). In short: Von Neumann rounding (introduced by A. W. Burks, H. H. Goldstine, and J. von Neumann, Preliminary discussion of the logical design of an electronic computing instrument, 1963, taken from report to U.S. Army Ordnance Department, 1946) consists in replacing the least significant bit of the truncation by a 1 (in the binary representation); the goal was to get a statistically unbiased rounding (as claimed in this paper) without carry propagation. In On the precision attainable with various floating-point number systems, 1972, Brent suggested not to do that for the exactly representable results. This corresponds to the sticky rounding mode (term used by J. S. Moore, T. Lynch, and M. Kaufmann, A Mechanically Checked Proof of the Correctness of the Kernel of the AMD5K86™ Floating-Point Division Algorithm, 1996), a.k.a. rounding to odd (term used by S. Boldo and G. Melquiond, Emulation of a FMA and correctly-rounded sums: proved algorithms using rounding to odd, 2006); it can be used to avoid the double-rounding problem. Vincent Lefèvre (talk) 13:58, 20 April 2015 (UTC)

I thought it was standard to have a rounding bit and a sticky bit in descriptions of how it was all done in IEEE. Is that what you mean? That would go into some IEEE article I'd have thought. Dmcq (talk) 15:34, 20 April 2015 (UTC)

The rounding bit and sticky bit are well-known notions (they are only used by implementers, though, i.e. there is nothing about them in the IEEE 754 standard, for instance). However sticky rounding can be seen as a way to include a useful part of the rounding bit and sticky bit information in a return value (mostly internally, before a second rounding in the target precision), and it is much less used. Vincent Lefèvre (talk) 21:21, 20 April 2015 (UTC)

I removed the sentences about sticky rounding. If someone wants to add them back, they should have their own section, like the other of the functional rounding methods. I thought the sentences that did exist were inadequate in describing how they work and why they are significant. It's a rather obscure method, and I'm not an expert on it.StephenJohns00 (talk) 04:47, 13 August 2018 (UTC)

IBM, in its zSeries and pSeries, implements the following method (cited from "z/Architecture Principles of Operation"):

> Round to prepare for shorter precision: For a BFP or HFP permissible set, the candidate selected is the one whose voting digit has an odd value. For a DFP permissible set, the candidate that is smaller in magnitude is selected, unless its voting digit has a value of either 0 or 5; in that case, the candidate that is greater in magnitude is selected.

Here, BFP is IEEE754 binary, DFP is IEEE754 decimal, and HFP is old-style S/360 binary/hexadecimal floating. I think it is worth listing. Netch 06:42, 07 June 2021 (UTC)

'Half rounds up' is NOT asymmetric for things like stop watches

I think this article needs to explain that 'Half rounds up' is NOT asymmetric for things like stop watches, whereas 'Half rounds down' is just plain wrong in such cases. This may (or may not) be part of the reason for 'Half rounds up' being the more common rule.

The point is that when a stopwatch says, for instance, 0.4, this really means 'at least 0.4 but less than 0.5', which averages to 0.45. So rounding becomes symmetric - 0.0 is really 0.05, which loses 0.05, matched by the gain of 0.05 when 0.9 (which is really 0.95) rounds up, and similarly 0.1 (which is really 0.15) matches 0.8 (which is really 0.85), 0.2 (which is really 0.25) matches 0.7 (which is really 0.75), 0.3 (which is really 0.35) matches 0.6 (which is really 0.65), and finally 0.4 (which is really 0.45) matches 0.5 (which is really 0.55).

Presumably quite a lot of other measurement processes have relevant similarities to stopwatches.

I assume there are Reliable Sources out there which say this better than I can, but I'm not the right person to go looking for them, partly thru lack of interest and partly thru lack of knowledge of where to look. So I prefer to just raise the topic here and let others more interested and more competent than me take the matter further.

Incidentally a good case can be made for putting much of the above in the article straight away without looking for reliable sources to back it up (as most of the article has no such sources - the self-evident truth doesn't need backing sources), but, if so, at least for now I prefer to leave it up to somebody else to try to do that, as such a person is less at risk of being accused of 'bias in favor of his own inadmissible original research' (the self-evident truth is not original research, but can always be labelled as such in an environment like Wikipedia). Tlhslobus (talk) 10:13, 12 April 2016 (UTC)

On second thoughts, I decided to just put in a bit of that self-evident truth, and see how it fares. Tlhslobus (talk) 10:43, 12 April 2016 (UTC)

What you are saying is simply that a stop watch rounds down to one decimal place so one can have the problem of double rounding. You really need a citation before sticking in your own thoughts on things like that. Dmcq (talk) 18:13, 12 April 2016 (UTC)

There was the same issue about the bias, which is also due to double rounding. I've removed the concerned text for consistency. Vincent Lefèvre (talk) 20:17, 12 April 2016 (UTC)

Related AfD

A deletion discussion on a related topic is occurring at Wikipedia:Articles for deletion/Mathcad rounding syntax. One potential outcome that I intend to suggest is a merge to the "Rounding functions in programming languages" section here. Please participate if you have an opinion. —David Eppstein (talk) 19:21, 28 June 2016 (UTC)

Round to even of negative numbers

There's something I'm not getting right here. The text says -23.5 should round to -24 but when I try to apply the formula I get -23.

$q=-\left\lceil -y-0.5\right\rceil -1+\left|\operatorname {sgn}((y\!\!\!\!\mod 2)-0.5)\right|$

$y=-23.5$

---

$q=-\left\lceil -(-23.5)-0.5\right\rceil -1+\left|\operatorname {sgn}((-23.5\!\!\!\!\mod 2)-0.5)\right|$

$q=-\left\lceil 23.5-0.5\right\rceil -1+\left|\operatorname {sgn}((-1.5)-0.5)\right|$

$q=-\left\lceil 23\right\rceil -1+\left|\operatorname {sgn}(-2)\right|$

$q=-23-1+\left|-1\right|$

$q=-23-1+1$

$q=-23$

Can somebody tell me what's wrong? Maybe I'm not fully understanding the $\left|\operatorname {sgn}((y\!\!\!\!\mod 2)-0.5)\right|$ part. --181.16.134.10 (talk) 19:42, 26 December 2016 (UTC)

Personally I think that formula should be removed as modulo can have many different definitions in computer languages. I think I'll stick citation needed on it which should allow someone else to remove it in the future. Anyway in mathematics the usual definition is with the result being 0 <= result < absolute value of divisor. That means that -23.5 mod 2 gives 0.5 not -1.5. Dmcq (talk) 20:29, 26 December 2016 (UTC)

Yes, for the reference: Modulo operation. In mathematics, I'm not sure that there is a standard definition; one generally uses an equivalence relation: n ≡ k mod m (ISO 80000-2:2009). Moreover, the formula is too complex to really be useful on WP, IMHO. And it will not necessarily be used in implementations (probably not). Vincent Lefèvre (talk) 22:36, 26 December 2016 (UTC)

Round to Even Revisions

Hi David Eppstein,

I am leaving this as I am curious as to why you undid my revisions to the rounding Wikipedia page. I am not sure what you mean by "correctness needs analysis of overflow conditions" in this context. Help would be appreciated.

Thanks!

Elyisgreat (talk) 02:10, 15 January 2017 (UTC)

You said the formula was obviously correct. But some very similar looking formulas, for instance the one for the integer halfway between two other integers x and y, can have numerical issues (such as overflows) when written in the obvious way like (x+y)/2 and may be preferable to write in a non-obvious way like x+(y-x)/2 or even ((x^y)>>1)+(x&y). So it would be helpful to have a source for the best choice of formula to use for this rounding mode, from someone who can be trusted to have thought about these issues and either handled them appropriately or concluded that there is no reason not to do it the obvious way. —David Eppstein (talk) 03:13, 15 January 2017 (UTC)

Thank you for this. I will see what I can find. Apparently another problem is the ambiguity of the modulo operation when dealing with negative values; I assumed the definition which takes the sign of the divisor, however this was apparently unclear to some users. Now, I know that there is nothing mathematically problematic with the formulae that I posted, however I am not sure if they could cause overflows in various programmatic implementations. Although I'm curious: Wouldn't any overflow issues caused by the round-to-even formula also crop up in the round half up formula? —Elyisgreat (talk) 06:17, 15 January 2017 (UTC)

The unclearness of modulo wrt negative numbers is because many major programming languages (C, C++, Java, etc) get it wrong and return negative results for a negative dividend. Actually, this is because of rounding! They choose the modulus value so that (x / y) * y + x % y == x, always, but then they choose a rounding mode for the division that is inconsistent with having an always-positive modulo. So that's another danger of just putting up a formula, without sources or clarification: people will use the formula, thinking they can just write it that way in a program, and it will return the wrong answer. —David Eppstein (talk) 06:31, 15 January 2017 (UTC)

Besides the formula not being pretty much immediately obvious which is a requirement if no source is provided, see WP:CALC, the problem with mod that David Eppstein talks about makes it quite unusable in the context. See Modulo operator for more about this. I think the other formulae are okay as being straightforward transcriptions of the English into mathematics, though I think the 'negative' version could be removed without loss. Actually in the latest formula I don't know what the mod is supposed to refer to anyway so I even don't know what it means. Dmcq (talk) 13:32, 15 January 2017 (UTC)

The original formula is possible to write without the mod function, if that is what is causing the ambiguity. It can be written like so:

$q={\begin{cases}y-0.5,&{\mbox{if }}y-2\left\lfloor y/2\right\rfloor =0.5\\\left\lfloor y+0.5\right\rfloor ,&{\mbox{if }}y-2\left\lfloor y/2\right\rfloor \not =0.5\end{cases}}$

or:

$q={\begin{cases}y-0.5,&{\mbox{if }}y-\left\lfloor y\right\rfloor =0.5{\mbox{ and}}\left\lfloor y\right\rfloor {\mbox{is even }}\\y+0.5,&{\mbox{if }}y-\left\lfloor y\right\rfloor =0.5{\mbox{ and}}\left\lfloor y\right\rfloor {\mbox{is odd }}\\\left\lfloor y+0.5\right\rfloor ,&{\mbox{if }}y-\left\lfloor y\right\rfloor \not =0.5\end{cases}}$

This last way is very similar to how it is done in this stackoverflow post (Ruby uses the divisor definition of modulus).

—Elyisgreat (talk) 19:49, 15 January 2017 (UTC)

Trying to work out which of several similar formulas is the right one to include is definitely edging into WP:OR territory, in my opinion. Please just look for a source. —David Eppstein (talk) 20:22, 15 January 2017 (UTC)

I agree, this seems WP:OR. Formulas that are not a direct formalization of a definition and that are never used in practice should be rejected. Vincent Lefèvre (talk) 22:31, 15 January 2017 (UTC)

truncate(y) without singularities

The following (original research) formula implements truncate(y) without the singularity at y=0. Requires abs and floor functions:

$\mathrm {truncate} (y)=\left\lfloor y\right\rfloor +{\frac {1-{\frac {\left|\left\lfloor y\right\rfloor +{\frac {1}{2}}\right|}{\left\lfloor y\right\rfloor +{\frac {1}{2}}}}}{2}}=\left\lfloor y\right\rfloor -{\frac {\left|\left\lfloor y\right\rfloor +{\frac {1}{2}}\right|}{2\left\lfloor y\right\rfloor +1}}+{\frac {1}{2}}$

70.190.166.108 (talk) 17:39, 15 January 2017 (UTC)

Italics and MOS:NUM cleanup

I've done some article-wide cleanup of style and markup, especially semantically distinguishing different uses of what visually renders as italics, with {{var}} (template wrapper for <var>...</var>) and {{em}} (<em>...</em>) where appropriate, and by occasionally removing some pointless, brow-beating emphasis. More could be done. For example, it seems unnecessary and reader-annoying to keep italicizing every single mention of a rounding algorithm/approach after the first instance (which is already boldfaced), and except where we're talking about them as words-as-words (as in "The term banker's rounding ..."). Also did some other MOS:NUM-related cleanup, such as use non-breaking spaces in "y × q = ...", not "y×q=...", nor using line-breakable regular spaces. Might have missed a couple of instances, but I did this in an external text editor and was pretty thorough.

However, I did not touch anything in <math>...</math> or {{math}} markup; I'm not sure whether those support {{var}} (or raw HTML <var>...</var>). I will note that the presentation of variables inside math-markup code blocks is wildly inconsistent, and should be normalized to var markup (if possible) or at least to non-semantic italics, for consistency and to avoid confusing the reader.
 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:21, 11 September 2017 (UTC)

Round half to odd

The Round half to odd section currently contains:

This variant is almost never used in computations, except in situations where one wants to avoid rounding 0.5 or −0.5 to zero; or to avoid increasing the scale of floating point numbers, which have a limited exponent range. With round half to even, a non-infinite number would round to infinity, and a small denormal value would round to a normal non-zero value. Effectively, this mode prefers preserving the existing scale of tie numbers, avoiding out-of-range results when possible for even-based number systems (such as binary and decimal).

But this tie-breaking rule concerns only halfway numbers, so that I don't see how "increasing the scale of floating point numbers" (or returning infinity) can be avoided. And the next sentence, citing an article, seems dubious too:

This system is rarely used because it never rounds to zero, yet "rounding to zero is often a desirable attribute for rounding algorithms".

Again, this tie-breaking rule concerns only halfway numbers, so that "it never rounds to zero" is incorrect. Moreover, this sentence would also imply that "round half away from zero" and "round away from zero" would also be rarely used, which is not true. Vincent Lefèvre (talk) 14:47, 11 September 2017 (UTC)

@Vincent Lefèvre: I guess that "never to zero" means that the applicable rounding case (half-number) will not round to zero. However, whether or not this is desirable is context dependent. For example, in fixed point, rounding towards uneven will only produce a single bit-change, while rounding to even may trigger a full add. Paamand (talk) 09:04, 21 September 2017 (UTC)

Yes, this might be (slightly?) faster in some specific cases only (the halfway ones), but when using dedicated hardware, and such cases may need to be detected, meaning that this can also slow things down. So this is not obvious. Moreover, I doubt that this is used in practice. In any case, this seems WP:OR, unless you have some reference showing an existing use. Vincent Lefèvre (talk) 10:05, 21 September 2017 (UTC)

Rounding of VAT

The VAT Guide cited states:

Note: The concession in this paragraph to round down amounts of VAT is designed for invoice traders and applies only where the VAT charged to customers and the VAT paid to Customs and Excise is the same. As a general rule, the concession to round down is not appropriate to retailers, who should see paragraph 17.6.

and paragraph 17.6 says the rounding down only is not allowed. So I don't think it is "quite clearly" stated. --81.178.31.210 17:27, 2 September 2006 (UTC)

Can anyone answer this question? There is a slot in the article for this kind of examples. --Jorge Stolfi (talk) 05:52, 1 August 2009 (UTC)

Independent from the preceding question, VAT on items in an invoice is an example for the need to round each item such that the sum of the rounded items equals the rounded sum of the items. A particular solution for positive items only is the Largest_remainder_method, a more general one is Curve_fitting. Perhaps someone who reads German may include (and expand?) in the article material from https://de.wiki.x.io/wiki/Rundung#Summenerhaltendes_Runden. -- Wegner8 07:04, 18 September 2017 (UTC)

Done. Wegner8 11:51, 7 October 2017 (UTC) — Preceding unsigned comment added by Wegner8 (talk • contribs)

Argentina and Swiss Rounding

I'm not sure if it really merits coverage in this article, but this blog page describes "Argentina" and "Swiss" rounding.

"Argentina Rounding" is (roughly but not exactly) rounding to halves, rather than whole digits. "Roughly" because (in my view) they only look at one digit.

"Swiss Rounding" is (if I understand it correctly) rounding to quarters. Like rounding to 0.0, 0.25, 0.5, 0.75, and 1.0 as rounded results.

-- Jeff Grigg 68.15.44.5 (talk) 00:32, 20 October 2017 (UTC)

References

This would mean that "Argentina Rounding" corresponds to radix-2 fixed-point rounding with one fractional digit, but that's not correct rounding, and that "Swiss Rounding" corresponds to radix-2 fixed-point rounding with two fractional digits. So, these are not really new roundings. Vincent Lefèvre (talk) 00:39, 21 October 2017 (UTC)

Stochastic rounding and Monte Carlo arithmetic

The article has just stocastic rounding for ties, however the term stochastic rounding is applied in for instance

Gupta, Suyog; Angrawl, Ankur; Gopalakrishnan, Kailash; Narayanan, Pritish (9 February 2016). "Deep Learning with Limited Numerical Precision". ArXiv. p. 3.

where we have the probability of rounding $x$ to $\lfloor x\rfloor$ is proportional to the proximity of $x$ to $\lfloor x\rfloor$:

$\operatorname {Round} (x)={\begin{cases}\lfloor x\rfloor &{\text{ with probability }}1-(x-\lfloor x\rfloor )\\\lfloor x\rfloor +1&{\text{ with probability }}{x-\lfloor x\rfloor }\end{cases}}$

Rounding in Monte Carlo rounding is random, the above can be considered as one form of Monte Carlo rounding, but others can be used and can be used with multiple runs to test the stability of a result. The stochastic rounding above has the property that addition is unbiased. There's a lot about Moonte Carlo arithmetic at Monte Carlo Arithmetic. Dmcq (talk) 16:17, 21 October 2017 (UTC)

Axiomatic theory of rounding

In my opinion it would be nice to add a starting section which says something about the axioms of rounding operations, possibly starting with "what rounding is" in a most general sense and then adding some more specializing axioms for the various types of rounding in use. However it's not yet clear to me how much of such an "axiomatic rounding theory" already has been developed in the research community. So it might also be a bit too early to discuss it here in the context of a WP article. I'll check some of the resources I know that exist on such an axiomatization and post it here for further discussion. Any other input is highly welcome, thanks! Axiom0 (talk) 14:37, 7 March 2018 (UTC)

Sourcing would be a great place to start. See WP:V and WP:RS. --Guy Macon (talk) 14:53, 7 March 2018 (UTC)

I suggest to look at what has been done for theorem provers, like Coq. For instance: Daumas, Marc; Rideau, Laurence; Théry, Laurent (2001). "A Generic Library for Floating-Point Numbers and Its Application to Exact Computing". Retrieved 7 March 2018. {{cite journal}}: Cite journal requires |journal= (help) But note that this is already more specific (floating-point only) than what is considered in the WP article. Vincent Lefèvre (talk) 16:00, 7 March 2018 (UTC)

Here is a list of sources of definitions of rounding I've found so far (in chronological order, "list under construction"):

U. Kulisch. Mathematical foundation of computer arithmetic. IEEE Transactions on Computers, C-26(7):610–621, July 1977. (p.610 et seq.)

R. Mansfield. A Complete Axiomatization of Computer Arithmetic. Mathematics of Computation, 42(166):623–635, 1984. (p.624)

G. Hämmerlin and K. Hoffmann. Numerische Mathematik. Springer, 4th edition, 1994. (p.14; very specific only (FP))

I'll add more later and I can possibly find earlier sources. However, as far as I know e.g. neither Turing (1948) nor Wilkinson (1963) in their publications formally defined a rounding operation. But I could be wrong. Axiom0 (talk) 22:19, 8 March 2018 (UTC)

After some more research I came to the conclusion that unfortunately it is indeed too early to include such a starting section into a WP article. Since a generally accepted "axiomatic rounding theory" has yet to be developed first. And as Vincent Lefèvre indicated on his talk page, we shouldn't try to invent one here. So I apologize for pushing this too far here. I've just liked the idea :-) Axiom0 (talk) 11:31, 21 March 2018 (UTC)

Towards-zero-bias in round-to-even in the y - 0.5 is even case

The text presently sayssaid that the round-half-to-even "rule will introduce a towards-zero bias when y − 0.5 is even".

I assumes this means that with a set such as 2.5, 2.5, 4.5, 10.5, the result of rounding will be 2, 2, 4, 10, which has a towards-zero bias. But −1.5, −1.5, −11.5, −7.5 are also of the form "y − 0.5 is even", and they round to −2, −2, −12, −8. So really this should read:

"rule will introduce a towards-negative-infinity bias when y − 0.5 is even".

So I've fixed this. Boud (talk) 16:41, 24 April 2018 (UTC)

Personally I think that bit should just be removed, I've never seen any document describing it so it probably isn't important enough to include and in fact very possibly violates WP:OP - which would explain why the person who wrote it got it wrong.. Dmcq (talk) 21:24, 24 April 2018 (UTC)

I also think that this should be removed. Vincent Lefèvre (talk) 21:45, 24 April 2018 (UTC)

round half up (or round half towards positive infinity), is widely used in many disciplines. Citation needed

I think it's actually round half away from zero that is widely used in many disciplines.StephenJohns00 (talk) 04:56, 13 August 2018 (UTC)

I also think so, and it's probably why it has been included in IEEE 754-2008. Vincent Lefèvre (talk) 07:13, 13 August 2018 (UTC)

Yes its not to positive infinity, it is round to nearest away and it is for decimal computations. Some financial institutions want it - and I guess they've got the money ;-) Dmcq (talk) 15:25, 13 August 2018 (UTC)

VAT rounding revisited

• The Largest remainder method is definitely a method of rounding. It is practically used in some democracies for the apportionment of seats. Therefore it should appear in this article.
• It can definitely be done with elementary arithmetic. Therefore no research is involved and no source should be required. (It should be possible to prevent the respective bot from challengig this again.)
• David Eppstein, Dmcq: After having deleted the respective section twice, please insert a wording you like.

Here is my proposed text, simplified once more. Wegner8 08:06, 28 October 2018 (UTC)

=== Rounding of summands preserving the total: VAT rounding ===

Rounding preserving the total means rounding each summand in a way that the total of the rounded numbers equals their rounded total. The [[Largest remainder method]] is the special case with positive summands only.

Among other purposes, this procedure is practised (a) for the [[proportional representation]] in a legislative body with a fixed number of members and (b) if in an invoice the total [[VAT]] is to be distributed to the items keeping the addition of each column correct.

If, after rounding each summand as usual, their sum is too large or too small, one rounds the nesessary number of summands away from their closest rounded values towards the second closest such that (a) the desired total is achieved and (b) the [[absolute value]] of the total of all rounding differences becomes minimal.

On what basis did you conclude that "The Largest remainder method is definitly[sic] a method of rounding"? It -- and all the other methods of Party-list proportional representation -- appears to only bear a superficial resemblance to rounding. --Guy Macon (talk) 09:37, 28 October 2018 (UTC)

Quotients (normally non-integer simple fractions) are given, integers nearby have to be determined. This is a special case of rounding. -- Wegner8 10:47, 28 October 2018 (UTC)

You are indulging in WP:Original research unless you have a reliable source which says that it is a method of rounding. This policy is basic to Wikipedia. See WP:5P2 "Editors' personal experiences, interpretations, or opinions do not belong." The best that can be done is have a see also to Proportionality but the various topics of proportional division or proportional representation or suchlike just are not considered as rounding in sources and so should not be considered as rounding here. Dmcq (talk) 11:34, 28 October 2018 (UTC)

Can you please, instead of simply deleting potentially useful material, help finding the right place and wording for it? Where would someone with the VAT problem look for a solution? -- Thanks for the hint to the article Party-list proportional representation; this link should replace the link to the Largest remainder method in the proposed text above. -- Wegner8 06:49, 29 October 2018 (UTC)

"Potentially useful material" is not a valid reason to add something to an encyclopedia article. The following is definitely "potentially useful material""

A Cockcroft–Walton multiplier converts AC or pulsing DC electrical power from a low voltage level to a higher DC voltage level. Unlike the case with transformers no single part of a CW multiplier has to withstand the full output voltage, thus allowing arbitrarily high output voltages.

Does the fact that it is potentially useful mean that we should add the above statement to our Rounding article? No. It us extremely useful information for someone who needs very high voltages, but does not belong here.

Furthermore, it is your responsibility as the person who wishes to add the material to figure out where the right place is. Simply deleting it from the wrong place does not imply that the deleting editor is obligated to do your work for you.

We do have a place where you can ask what the right place is, and volunteers are standing by to help you. See WP:Helpdesk. Please note that once you figure out where the right place is, you need to follow WP:V and provided a source for your claims. When adding information, please WP:CITE a source for each statement.

This is an encyclopedia, so remember that it's a necessity to include references listing reliable websites, newspapers, articles, books and other sources you have used to write or expand articles. Please understand that these sources should verify the information in a fair and accurate manner.

However, you must not copy and paste text you find anywhere, except for short quotations, marked as such with quote marks and carefully cited to the source the quote was taken from. New articles and statements added to existing articles may be deleted by others if unreferenced or referenced poorly or if they are copyright violations. See referencing for beginners for more details.

Here are some more pages that you might find helpful:

• Introduction
• The five pillars of Wikipedia
• Contributing to Wikipedia
• How to edit a page
• Help pages
• How to write a great article
• Discover what's going on in the Wikimedia community

Also, when you post on talk pages you should sign your name using four tildes (~~~~); this will automatically add your username and the date with properly formatted links. --Guy Macon (talk) 07:44, 29 October 2018 (UTC)

Air: not so good at being an insulator if the voltage is high enough

Well I think a cite at th end of every sentence is a bit much when a source can cover a whole paragraph but yes, basically what goes into an article needs to be a summary of what one or more source say. Dmcq (talk) 12:11, 29 October 2018 (UTC)

p.s. with a transformer one would put in more windings for a higher voltage, no single winding need sustain a higher voltage. — Preceding unsigned comment added by Dmcq (talk • contribs) 12:15, 29 October 2018 (UTC)

Who said anything about a cite at the end of each sentence? Wegner8's addition had no citations at all.

In a high voltage transformer, the breakdown path is usually lowest-voltage-winding --> core --> highest voltage winding. For air core transformers it is extremely difficult to get the two ends of the secondary far enough apart to withstand a voltage that can arc over 20 feet -- something that Cockcroft–Walton multipliers handle with ease. --Guy Macon (talk) 17:10, 29 October 2018 (UTC)

"When adding information, please WP:CITE a source for each statement" might be read as requiring one at the end of each statement.

Ferrites don't conduct ;-) I'm just pointing out that a reliable source is very good even for a person thinks is 'useful information' or there may be problems. Dmcq (talk) 17:31, 29 October 2018 (UTC)

Ferrites don't conduct at low voltages. Neither does air. Both have a dielectric withstanding voltage (commonly referred to as "breakdown voltage"). Try to get the kind of voltages commonly found in large Cockcroft–Walton multipliers out of a ferrite-core transformer and it will arc right through the ferrite. It really is true that no part of a Cockcroft–Walton multiplier sees the full output voltage and it really is true that some parts of a transformer do see the full output voltage. --Guy Macon (talk) 18:55, 29 October 2018 (UTC)

The article begins as follows: "Rounding a number means replacing it with a different number that is approximately equal to the original ...". Isn't this exactly what VAT rounding does? Everyone talks about fake news; denying facts is a twin of fake news. Please restore a paragraph on VAT rounding. -- Wegner8 08:19, 10 January 2019 (UTC) — Preceding unsigned comment added by Wegner8 (talk • contribs)

No, it is not just about rounding a number. It might have its own article. Then I suppose that a link in the "See also" section would be OK. Vincent Lefèvre (talk) 11:10, 10 January 2019 (UTC)

Anyway have you got a source for VAT rounding yet? If so you could start an article on for instance VAT rounding around the world. Each system would apply rounding and this article could have a see also link to it as an interesting use. Dmcq (talk) 13:58, 10 January 2019 (UTC)

Merge from Nearest integer function

There is a proposal on Talk:Nearest integer function to merge that article into this one; see Talk:Nearest_integer_function#Merge_into_Rounding. --JBL (talk) 22:16, 18 April 2019 (UTC)

Age heaping

In the history section there is a short bit on age heaping at the end which is a kind of rounding people do that seems to be more about a psychological thing and way of fixing statistics than anything to do with rounding as described in the rest of the article. Does that rally belong in this article? Dmcq (talk) 11:44, 24 September 2019 (UTC)

Faithful rounding

No mention of faithful rounding and why it's a good idea. I think it means logic can be smaller and generally the rounding/overflow/underflow is quicker, but I came here for more info and didn't find any. — Preceding unsigned comment added by ChippendaleMupp (talk • contribs) 15:50, 13 February 2020 (UTC)

That example with the Goldbach Conjecture

My apologies Dr. Lefèvre, I honestly thought I was correcting a typo with my edit.

I found this example fascinating, but when I tried to work it out by substituting different values for $n$, it didn't seem to add up.

Here is the original text before my edit:

For instance, if Goldbach's conjecture is true but unprovable, then the result of rounding the following value up to the next integer cannot be determined: 1+10⁻ⁿ where n is the first even number greater than 4 which is not the sum of two primes, or 1 if there is no such number. The rounded result is 2 if such a number n exists and 1 otherwise.

Let's first take the case where the number doesn't exist, so we substitute $n=1$ in the formula:

$$1+10^{-n}=1+10^{-1}=1+{\frac {1}{10^{1}}}=1+{\frac {1}{10}}=1.1$$

Now let's take the other case, where an even number greater than 4 exists that is not a sum of two primes. That number would presumably be very large, but let's start with $n=4$:

$$1+10^{-n}=1+10^{-4}=1+{\frac {1}{10^{4}}}=1+{\frac {1}{10000}}=1.0001$$

Clearly, the larger the $n$, the closer the resulting value will be to 1. For a very large $n$ we would get 1.000...0001 with very many zeroes in between.

So the values we get in both cases of the example, 1.1 and 1.000...0001, will both end up being rounded to the same number, regardless of which rounding mode we use. So how do we get this formula to round to 1 or 2, depending on the provability of Goldbach's Conjecture?

The only way I can think of getting different rounded values is to use $n=0$ for the case when no such number exists, which would cause the above formula to round to 2 in that case and to 1 in the other case (when rounding to nearest integer).

Clearly I have misunderstood something here, but I can't seem to figure out what. I would really appreciate if someone could elaborate this example.

Grnch (talk) 21:51, 27 March 2021 (UTC)

@Grnch: If the conjecture is false, then the result will be 1+10⁻ⁿ for some value of n, which will round to 2. If the conjecture is true, then the result will be 1 (see "1 if there is no such number" above), which will round to 1 (since 1 is an integer, rounding it does not change its value). — Vincent Lefèvre (talk) 02:46, 28 March 2021 (UTC)

I spent way more time trying to understand this answer than I would like to admit, until it finally dawned on me: my problem is not mathematical, but grammatical.

In this sentence:

1+10⁻ⁿ where n is the first even number greater than 4 which is not the sum of two primes, or 1 if there is no such number

I took the "1 if there is no such number" to apply to the "where n is" clause, i.e. that n should take on the value of 1 when no such number exists. I now realize that in fact the whole expression takes on the value of 1 when no such number exists.

To attempt to put this in more precise notation, I interpreted the example as rounding up the value of $x$, where $x$ is defined as:

$$x=1+10^{-n},{\text{where }}n={\begin{cases}{\text{the first even number greater than 4 which is not a sum of two primes}}\\1,{\text{ if no such number exists}}\end{cases}}$$

But in fact the correct interpretation is to round up the value of $x$, where $x$ is defined as:

$$x={\begin{cases}1+10^{-n},&{\text{where }}n{\text{ is the first even number greater than 4 which is not a sum of two primes}}\\1,&{\text{if no such number exists}}\end{cases}}$$

To be perfectly honest, even though I am now aware of the correct interpretation, that sentence above still looks pretty ambiguous to me. It may trip up other readers too, who are not a priori familiar with this material.

Maybe adding the above mathematical notation (the second one) would help remove any possible ambiguity from the example?

Grnch (talk) 01:07, 31 March 2021 (UTC)

@Grnch: Yes, it should be clarified, but not with <math display="block"> as everything in it appears as an image, which is bad for accessibility or if one wants to copy-paste. I don't know whether there is wikicode to solve that. Alternatively, adding "either" before "1+10⁻ⁿ" would make the sentence unambiguous, IMHO. — Vincent Lefèvre (talk) 11:01, 31 March 2021 (UTC)

Oh, that would be perfect! Yes, that strategic addition of "either" would create an "either/or" symmetry that should make the meaning of the whole sentence more obvious, at least to my eyes. Thank you! — Grnch (talk) 17:44, 3 April 2021 (UTC)

@Grnch: Done in Special:Diff/1015824758. — Vincent Lefèvre (talk) 19:46, 3 April 2021 (UTC)

Rounding to nearest half integer values

I didn't find any description for rounding to the nearest 1/2 integer value, i.e. to values of 0, 0.5, 1, 1.5, etc.--Fkbreitl (talk) 12:00, 8 May 2021 (UTC)

Not needed (like rounding to some number of fractional digits): this is like doing an exact multiplication by 2, rounding to an integer, and dividing by 2. The article cannot cover every possible case of rounding. — Vincent Lefèvre (talk) 16:43, 8 May 2021 (UTC)

Why not include rounding up or down to nearest multiple?

I thought it would be useful to include the formula for rounding up and down a number to the nearest multiple of another positive number, since there's already a section for rounding to a specific multiple (https://en.wiki.x.io/wiki/Rounding#Rounding_to_a_specified_multiple), and a section for rounding up and down to nearest integer (https://en.wiki.x.io/wiki/Rounding#Rounding_down and https://en.wiki.x.io/wiki/Rounding#Rounding_up). The formulas would be:

$\mathrm {roundUpToMultiple} (x,m)=\lceil x/m\rceil \times m$

$\mathrm {roundDownToMultiple} (x,m)=\lfloor x/m\rfloor \times m$

So, I added them to the article, but the user Vincent Lefèvre removed them. He said that "This is a particular case of what is described in this section (which is not restricted to rounding to nearest)". While that's true, I don't see why that's a problem or a reason to remove them. I mean, rounding up or down (using the ceiling and floor functions) is a particular case of rounding, so why don't we also remove the sections "Rounding down" and "Rounding up"? --Alej27 (talk) 19:24, 3 March 2022 (UTC)

The point is that $\mathrm {roundToMultiple} (x,m)=\mathrm {round} (x/m)\times m$ given in this section Rounding to a specified multiple is the general formula, where you can choose any rounding function to an integer for "round". For instance, with $\mathrm {round} (x)=\mathrm {floor} (x)=\left\lfloor x\right\rfloor$ from the subsection Rounding down, you immediately get your second formula. It is useless to repeat everything that has been said in Section Rounding to integer. — Vincent Lefèvre (talk) 20:25, 3 March 2022 (UTC)

Recent disputes

Hi @Boh39083, I notice you've gotten into a bit of a revert war about your recent changes. Maybe you want to discuss your rationale here a bit? (cf. "bold–revert–discuss".) Trying to make arguments in edit summaries is not the most effective in my experience. –jacobolus (t) 16:04, 19 November 2023 (UTC)

any mentions that best only round at the final step when possible?

In JS, I tested a simple conversion of 1/3 into a percentage (JS number is double-precision floating point), and if you divide (round) first before multiplying, will have a larger discrepancy than if you to multiply first than divide (as divide can result in landing in an non-representable value so a rounding must occur):

(1/3*100).toFixed(16)
'33.3333333333333286'
 
(1*100/3).toFixed(16)
'33.3333333333333357'

This is because the former, did 1/3, which cannot be exactly represented in double-precision floating point format, so that number gets rounded, and then gets multiplied by 100, which increases this error. The latter did 1*100, which can be exactly represented, then divided by 3, which is then rounded, at the final step. Joeleoj123 (talk) 02:04, 18 December 2023 (UTC)

That's covered at the linked article on Round-off error. MrOllie (talk) 02:08, 18 December 2023 (UTC)