It can be difficult to remember all threads on the mailing list that relate to changes made in Julia. Hence, it is very helpful when users make cross references such that you are doing here. A link to the exact issues on github would be even better so here they are
https://github.com/JuliaLang/julia/issues/8750 https://github.com/JuliaLang/julia/pull/9344 2014-12-26 13:14 GMT+01:00 Hans W Borchers <hwborch...@gmail.com>: > I started this thread long time ago with a question about rounding rules > and the IEEE floating point standard. I felt like being criticized for even > thinking Julia could follow the "round-to-even" rule. Now I learn that > Julia version 0.4 will apply this rule (as default?). > > We had similar discussions about whether Julia should use the "+" or ".+" > operator for adding scalars to vectors. One strong argument was that, > mathematically, there is no addition of scalars to vectors. Since then > Julia has switched back to using "+" again. > > I would wish the replies were not that strict when questions or requests > come up for a different behavior of Julia operators or functions. And > because mailing lists are also an information source for users, it may be > appropriate to mention such changes at the end of threads like this one. > > > On Thursday, June 5, 2014 7:18:43 PM UTC+2, Stefan Karpinski wrote: >> >> Right, calling one particular rounding style round_ieee would be very odd >> – the IEEE 754 spec lists various functions for rounding floats to integers >> and doesn't favor any of them over the others. This is unlike rounding >> modes where it does indicate that the default mode should be ties to even. >> >> >> On Thu, Jun 5, 2014 at 8:42 AM, Simon Byrne <simon...@gmail.com> wrote: >> >>> On Thursday, 5 June 2014 09:47:21 UTC+1, Hans W Borchers wrote: >>>> >>>> What I would like to have is a function round_ieee(x,n) such that >>>> >>>> julia> round_ieee(0.025, 2) >>>> 0.02 >>>> >>>> Can I do this somehow with with_rounding() do ... end ? >>>> >>> >>> Not generally: the IEEE notions of even and odd only pertain to binary >>> arithmetic (as determined by the last bit of the mantissa), trying to force >>> this notion into approximate decimal representations is going to cause all >>> sorts of confusion: technically the Float64 represented by 0.025 is >>> actually 1.39e-18 larger than the exact 0.025, so should it be rounded to >>> 0.03 instead? >>> >>> The IEEE754 spec itself only defines explicit rounding (as opposed to >>> rounding after calculations) to integers (section 5.9 for those following >>> along at home). According to the standard, IEEE754 compatible languages are >>> required to provide methods for the following: >>> a) round to nearest integral: ties to even >>> b) round to nearest integral: ties to away (round) >>> c) round to integral toward zero (trunc) >>> d) round to integral toward positive (ceil) >>> e) round to integral toward negative (floor) >>> f) round to integral using rounding mode >>> >>> At the moment, I don't think we implement (a) or (f). >>> >> >>
