Talk:Rounding

message: "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)
replies: text: Yes. Thanks for spotting this! -- Jitse Niesen (talk) 12:21, 13 November 2005 (UTC)

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

message: 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)
replies: text: There are many implementations, and very few are covered in this article. Here's an external article which covers the field . Hopefully someone has time to incorporate the information from that article without engaging in copyvio. -Harmil 15:55, 14 July 2006 (UTC)
replies: text: Negative numebrs should be properly covered in the current version. --Jorge Stolfi (talk) 05:52, 1 August 2009 (UTC)

text: 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)
thread_title:  Rounding negative numbers. 

message: 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)
replies: text: This is called "dithering".  Added a section on it. --Jorge Stolfi (talk) 05:41, 1 August 2009 (UTC)
replies: text:  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)
replies: text: 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)
thread_title:  Another Method ? 

message: 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)
replies: text: I also left out 2.0, surely? Wikidea 19:41, 7 February 2008 (UTC)

text: 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)
replies: text: 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)

text: 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)

text: 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)
thread_title:  Why are halfway-values rounded away from zero? 

message: 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)
replies: text: 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)
thread_title:  Problem with decimal rounding of binary fractions  

message: 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)
replies: text: 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)
replies: text: Agreed. Those sources are probably just plain wrong. --Jorge Stolfi (talk) 05:44, 1 August 2009 (UTC)
thread_title:  Round to even 

message: Please comment: rounding 2.50001 to the nearest integer. Is it 2 or 3? Redding7 (talk) 01:42, 5 January 2010 (UTC)
replies: text: 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)
thread_title: Rounding 2.50001 to nearest integer

message: 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)
thread_title: Consistency

message: 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)
replies: text: The section has been thoroughly rewritten. Please check if the problem has been fixed. --Jorge Stolfi (talk) 05:42, 1 August 2009 (UTC)
thread_title:  Needs fixing 

message: 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)
thread_title:  Useof "-0" by meteorlogists 

message: 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)
replies: text: 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)
thread_title:  Another 'Bankers' or 'Accounting' Rounding Method? 

message: 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)
replies: text: Why would it be called that?  Oli Filth(talk|contribs) 00:52, 26 December 2010 (UTC)
replies: text: 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)
thread_title:  The "7-up" rule? 

message: 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)
thread_title:  Chopped dithering and scaled rounding 

message: With particular reference to , 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)
replies: text: Hmm. It looks to me as though there is little to nothing published on this. Pity. —Quondum 19:21, 23 April 2015 (UTC)
replies: text: 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)
replies: text: Maybe it is not all that bad; Google searching on "Setun" and "rounding" pops up some results.  Consider , Balanced ternary ("Donald Knuth has pointed out that truncation and rounding are the same operation in balanced ternary"),  ("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)
thread_title:  Rounding with an odd radix 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
thread_title:  Von Neumann rounding and sticky rounding 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  'Half rounds up' is NOT asymmetric for things like stop watches 

message: 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)
thread_title:  Related AfD 

message: 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| \sgn((y \!\!\!\!\mod 2) - 0.5) \right| 
y = -23.5 
----------------------------------
q = -\left\lceil -(-23.5) - 0.5 \right\rceil - 1 + \left| \sgn((-23.5 \!\!\!\!\mod 2) - 0.5) \right| 
q = -\left\lceil 23.5 - 0.5 \right\rceil - 1 + \left| \sgn((-1.5) - 0.5) \right| 
q = -\left\lceil 23 \right\rceil - 1 + \left| \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| \sgn((y \!\!\!\!\mod 2) - 0.5) \right| part. --181.16.134.10 (talk) 19:42, 26 December 2016 (UTC)
replies: text: 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)
replies: text: 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)
thread_title:  Round to even of negative numbers 

message: 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)
thread_title:  truncate(y) without singularities 

message: I've done some article-wide cleanup of style and markup, especially semantically distinguishing different uses of what visually renders as italics, with  (template wrapper for ) and  () 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 " ×  = ...", not "×=...", 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  or  markup; I'm not sure whether those support  (or raw HTML ). 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)
thread_title:  Italics and [[MOS:NUM]] cleanup 

message: 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)
replies: text: 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)
thread_title:  Round half to odd 

message: 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)
replies: text: 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)

text: Done. Wegner8 11:51, 7 October 2017 (UTC)
thread_title:  Rounding of VAT 

message: I'm not sure if it really merits coverage in this article, but this blog page http://blog.syspro.com/2013/09/12/rounding-accounting 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)
replies: text: 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)
thread_title:  Argentina and Swiss Rounding 

message: The article has just stocastic rounding for ties, however the term stochastic rounding is applied in for instance 
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)
thread_title:  Stochastic rounding and Monte Carlo  arithmetic 

message: 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)
replies: text: 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)
replies: text: I also think that this should be removed. Vincent Lefèvre (talk) 21:45, 24 April 2018 (UTC)
thread_title:  Towards-zero-bias in round-to-even in the y - 0.5 is even case 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  round half up (or round half towards positive infinity), is widely used in many disciplines. Citation needed 

message: 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)
thread_title:  Merge from [[Nearest integer function]] 

message: 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)
thread_title:  Age heaping 

message: 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)
thread_title:  Faithful rounding 

message: 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)
replies: text: 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)
thread_title: Rounding to nearest half integer values

message: 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)
thread_title:  Recent disputes 

message: 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)
replies: text: That's covered at the linked article on Round-off error. MrOllie (talk) 02:08, 18 December 2023 (UTC)
thread_title:  any mentions that best only round at the final step when possible?