My rule of thumb is that if I need to worry about the IEEE rounding mode
making a difference in my results, then my problem is really
ill-conditioned and rounding the least of my worries. So I usually just
ignore it.
Same applies to rounding for data displays: if I am worried about 3.5
being
Hans,
yes this can be frustrating. But Julia is in flux and I have to say that I
am very happy that changes are reverted if they turn out to be not
practically (e.g. .+ which I also was not happy with).
One important thing to note: If you don't like this back and forth it
should be better to
Just a remark: round-towards-+Inf is not the same as
round-away-from-zero and
does not fulfill round(-x) = -round(x).
gp round([1.5, 2.5])
%1 = [2, 3]
gp round([-1.5, -2.5])
%2 = [-1, -2]
I am astonished that PARI/GP is rarely mentioned when comparing Julia to
other
I did not mean to imply that no one cares about rounding rules, or that
they are unimportant -- sorry if I was not clear. I only said that in my
(necessarily limited) experience, when IEEE rounding rules start to
matter then I am facing a different, usually more fundamental, problem.
However,
However, these discussions are necessarily very abstract. Having a
concrete issue or use case where you find one rounding mode preferable
to another would help focus the discussion.
@Tamas For an example where it might have the potential to cause problems,
see
Potential future problem:
Hi Hans,
If I understand corretly, #13 is a potential problem arising from a
change in behavior, not an argument in favor of one rounding mode vs
another per se.
The only reasonably cogent argument I know is mentioned in #8750
(unbiasedness). I am glad that the issue is now closed, since that
Tamas,
I agree with you that 'unbiased rounding' is a strong argument in favor of
the
round-to-even rule. It appears natural that e.g. R falls for this rule.
The interpolation case seems to favor a rule that moves all ties in the same
direction, being it upwards or downwards, and independent of
On Sat, 27 Dec 2014, Tamas Papp wrote:
The only reasonably cogent argument I know is mentioned in #8750
(unbiasedness). I am glad that the issue is now closed, since that means
no more electrons are wasted on it, but I am still curious about
practical examples where rounding mode makes a
On Sat, Dec 27, 2014 at 5:17 AM, Hans W Borchers hwborch...@gmail.com
wrote:
Just a remark: round-towards-+Inf is not the same as
round-away-from-zero and
does not fulfill round(-x) = -round(x).
Right, I realize it wasn't clear from my email, but that was an argument
against the current
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
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
On Friday, 26 December 2014 06:14:34 UTC-6, Hans W Borchers wrote:
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
I'm also sorry if you felt like you were being criticized in any way for
proposing alternate behaviors. Please keep in mind that any disagreement is
just that – disagreement. Even if everyone seems disagree with you, please
do make your case. As you've noted, they may change their minds – or they
Don't worry. I am a long-term ... user and as such got used to really harsh
criticism. As others have noted, this is - besides Ruby - the most friendly
mailing list I have seen (and I am sometimes not living up to that
standard). What irritates me a bit are these back-and-forth decisions. I
On Fri, Dec 26, 2014 at 6:00 PM, Hans W Borchers hwborch...@gmail.com
wrote:
What irritates me a bit are these back-and-forth decisions. I accepted
.+ for scalar plus vector operations (with a bit of teeth grinding, but
listening to a good mathematical analogy), used it in some programs, only
I think I now understand the difference between rounding rules and rounding
to
integers as a mathematical function.
Then, how can I in Julia round a number such as 0.025 to two decimal places
and
what will I get? round() does not have a second parameter indicating the
number
of digits to
Right, my fault.
Sorry, I am still wondering: round(x,n) rounds towards zero, even for
non-integers
(as is documented in;
The round() functions return the integral value nearest to x rounding
halfway
cases away from zero, regardless of the current rounding direction.)
julia
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
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.
Many programming languages and scientific computing systems follow the
round half to even
tie-breaking rule; this is also the default rounding mode in the IEEE
standard for floating-point
arithmetic (IEEE 754). So in R or Python (with NumPy), but not in, e.g.,
MATLAB) we have
round(0.5)
We follow C, Fortran, Matlab, Python and most other programming languages
here. R and NumPy's rule is pretty unusual; it has some nice statistical
properties (it's apparently known as statistician's rounding), but is
quite awkward for general programming tasks.
One question: I have the impression that the round() function is not affected
by the currently chosen rounding rule in Julia. Is that right?
-- John
On Jun 4, 2014, at 2:48 PM, Stefan Karpinski ste...@karpinski.org wrote:
We follow C, Fortran, Matlab, Python and most other programming
This isn't really related to IEEE rounding modes. Floating-point rounding
modes are about choosing which of the closest representable floating-point
values an operation should produce when the true value is between them. The
round function is a well-defined mathematical function regardless of IEEE
Couldn't this be provided by the get_rounding/set_rounding/with_rounding
framework?
On Wed, Jun 4, 2014 at 2:59 PM, Stefan Karpinski ste...@karpinski.org
wrote:
This isn't really related to IEEE rounding modes. Floating-point rounding
modes are about choosing which of the closest
It could, but it shouldn't. The rounding mode and how you round to integers
are completely different matters.
On Wed, Jun 4, 2014 at 8:16 PM, Kevin Squire kevin.squ...@gmail.com wrote:
Couldn't this be provided by the get_rounding/set_rounding/with_rounding
framework?
On Wed, Jun 4, 2014
25 matches
Mail list logo
