#8336 closed defect (invalid)
round(x) <> x.round() for x in RealField
Reported by: | zimmerma | Owned by: | robertwb |
---|---|---|---|
Priority: | critical | Milestone: | sage-duplicate/invalid/wontfix |
Component: | basic arithmetic | Keywords: | |
Cc: | was, jason, robertwb, ncalexan, craigcitro, mabshoff | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
This is related to #188 and #2899.
sage: R=RealField(150) sage: x=R(3493274823748475345934875398475345349.9343498375) sage: y=round(x) sage: y, type(y) (3.49327482375e+36, <type 'sage.rings.real_double.RealDoubleElement'>) sage: z=x.round() sage: z, type(z) (3493274823748475345934875398475345350, <type 'sage.rings.integer.Integer'>)
If one performs ZZ(y)
to convert y
to an integer, one
has a huge loss of accuracy.
I see no point of forcing coercion to RDF, which has limited precision and exponent range.
I would expect round(x)
to return the same value as z
,
either as Integer or RealField?.
Attachments (1)
Change History (13)
comment:1 Changed 12 years ago by
comment:3 Changed 11 years ago by
- Status changed from new to needs_info
With much help from Robert Bradshaw, I wrote some code for this ticket, that does the rounding, though it leaves trailing zeros in the destination type. Robert: Is the latter not a separate (display) issue? You noted off-list that the return type should have the same precision. If so, I don't think they will uniformly display without treating the issues separately. (If so, the one issue per ticket rule applies.) Much thanks.
comment:4 Changed 11 years ago by
- Owner changed from AlexGhitza to robertwb
Patch? I think
sage: round(2.5) 2.500000000000
is just fine for elements of RR.
comment:5 follow-up: ↓ 6 Changed 11 years ago by
Correction:
sage: round(2.5) 3 sage: round(2.5, ndigits=1) 2.500000000000
comment:6 in reply to: ↑ 5 Changed 11 years ago by
Replying to robertwb:
Correction:
sage: round(2.5) 3 sage: round(2.5, ndigits=1) 2.500000000000
it is fine for me that round(x)
returns a float, however I don't understand why it returns
a float of fixed precision (RDF). It should then be called RDF_round
. It would be more
natural to return a float with the same precision as the input.
Paul
comment:7 Changed 11 years ago by
I don't think it should return a float of fixed precision, it just so happened that the input was 53 bits.
What I want is round(x) to call x.round() and possibly x.round(ndigits=ndigits), if available. Thus
sage: L = [RDF(pi), RealField(100)(pi), float(pi)] sage: [x.round() for x in L if hasattr(x, 'round')] [3, 3] sage: [round(x) for x in L] [3, 3, 3] sage: [x.round(ndigits=2) for x in L if hasattr(x, 'round')] [3.14, 3.1400000000000000000000000000] sage: [round(x, ndigits=2) for x in L] [3.14, 3.1400000000000000000000000000, 3.1400000000000001] sage: [parent(round(x, ndigits=2)) is parent(x) for x in L] [True, True, True]
Sometimes it seems it'd be quicker to just code this up than keep talking about it :).
comment:8 Changed 11 years ago by
- Status changed from needs_info to needs_work
Whoops, I didn't realize uploading the patch would end my comments. I wanted to say, you didn't like that patch Robert. What's the next step?
comment:9 Changed 11 years ago by
What I want is round(x) to call x.round() and possibly x.round(ndigits=ndigits), if available.
this would be ok for me.
Paul
PS: donmorrison, your patch is missing some examples checking the new behaviour.
comment:10 Changed 11 years ago by
Thanks Paul. The patch I sent is incomplete because it breaks doctests for the following:
./sage -t -force_lib "devel/sage/doc/en/thematic_tutorials/linear_programming.rst";
./sage -t -force_lib "devel/sage/sage/misc/functional.py";
./sage -t -force_lib "devel/sage/sage/numerical/mip.pyx";
comment:11 Changed 10 years ago by
- Milestone changed from sage-4.8 to sage-duplicate/invalid/wontfix
- Resolution set to invalid
- Status changed from needs_work to closed
I'm going to close this as invalid now since we have the following behavior:
sage: R = RealField(150) sage: x = R(3493274823748475345934875398475345349.9343498375) sage: y = round(x) sage: y, type(y) (3493274823748475345934875398475345350, <type 'sage.rings.integer.Integer'>) sage: z = x.round() sage: z, type(z) (3493274823748475345934875398475345350, <type 'sage.rings.integer.Integer'>)
comment:12 Changed 10 years ago by
I agree to close that ticket. Just for the record, it would be nice to track down which patch did fix that issue.
Paul
+1 I was bitten by this myself recently.