Opened 12 years ago

Closed 10 years ago

Last modified 10 years ago

#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:

Status badges

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)

bug8336-almost-a-patch.txt (3.8 KB) - added by donmorrison 11 years ago.
patch for release "barnacle" ;)

Download all attachments as: .zip

Change History (13)

comment:1 Changed 12 years ago by robertwb

+1 I was bitten by this myself recently.

comment:2 Changed 12 years ago by zimmerma

  • Authors Paul Zimmermann deleted

I removed my name as "author" since I only reported that problem.

comment:3 Changed 11 years ago by donmorrison

  • 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 robertwb

  • 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: Changed 11 years ago by robertwb

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 zimmerma

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 robertwb

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

Changed 11 years ago by donmorrison

patch for release "barnacle" ;)

comment:8 Changed 11 years ago by donmorrison

  • 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 zimmerma

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 donmorrison

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 mhansen

  • 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 zimmerma

I agree to close that ticket. Just for the record, it would be nice to track down which patch did fix that issue.

Paul

Note: See TracTickets for help on using tickets.