Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#7830 closed enhancement (fixed)

function for floating point representation of a number

Reported by: jason Owned by: AlexGhitza
Priority: major Milestone: sage-4.3.2
Component: basic arithmetic Keywords:
Cc: Merged in: sage-4.3.2.alpha0
Authors: Jason Grout Reviewers: Robert Bradshaw, John Cremona
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description

Here's a function that answers the question posed in http://groups.google.com/group/sage-devel/browse_thread/thread/c8c75b483f2c47f6 -- give the sign, mantissa, and exponent of a floating point number.

I also cleaned up a few minor other things.

Attachments (5)

trac-7830-floating_point_representation.patch (3.9 KB) - added by jason 12 years ago.
trac-7830-change-name.patch (1.7 KB) - added by jason 12 years ago.
apply on top of previous patch
trac-7830-sign_m_e.patch (2.0 KB) - added by jason 12 years ago.
apply on top of previous patches
trac-7830-fixes.patch (4.1 KB) - added by jason 12 years ago.
apply on top of previous patches
7830-real-rep-all.patch (6.4 KB) - added by robertwb 12 years ago.
all four of the above folded into one

Download all attachments as: .zip

Change History (18)

comment:1 Changed 12 years ago by jason

  • Status changed from new to needs_review

comment:2 Changed 12 years ago by robertwb

Looks good. I don't like the name representation() either--maybe parts()?

comment:3 Changed 12 years ago by jason

parts() seems too vague. Maybe ieee_754_parts(), except that we support arbitrary precision, not just the set precisions they mention. Maybe floating_point_representation(), or sign_mantissa_exponent().

I'm willing to concede on the naming to make sure this gets in before I start my numerical analysis class in two weeks :).

comment:4 Changed 12 years ago by robertwb

Lets go with sign_mantissa_exponent(). Verbose but clear, and one doesn't even have to look at the docstring every time to remember what order the tuple comes in :)

Changed 12 years ago by jason

apply on top of previous patch

comment:5 Changed 12 years ago by jason

Okay, I added a patch which changes the name. This is hopefully ready for a positive review now :).

comment:6 Changed 12 years ago by cremona

I see that you have only added this method to mpfr. Should we not preserve as much consistency as possible between the different real types by also adding it to real_double?

comment:7 Changed 12 years ago by jason

Very good point. I'll look at this. I might just end up creating an RR number and calling this method behind the scenes

Changed 12 years ago by jason

apply on top of previous patches

comment:8 Changed 12 years ago by jason

I've added a similar function to RDF now.

comment:9 Changed 12 years ago by robertwb

  • Status changed from needs_review to needs_work

http://en.wikipedia.org/wiki/IEEE_754-1985

The exponent for 0 should be 0. This also avoids the issue of platform dependance for that value, and RDF(0)'s exponent being unrealistically small.

Also, sage/rings/real_mpfr.pyx, line 1890 should be EXAMPLES::

Changed 12 years ago by jason

apply on top of previous patches

comment:10 Changed 12 years ago by jason

  • Status changed from needs_work to needs_review

The last patch fixes a few other documentation errors and an error in multiplicative_order too. For free.

Changed 12 years ago by robertwb

all four of the above folded into one

comment:11 Changed 12 years ago by robertwb

  • Status changed from needs_review to positive_review

Looks good.

comment:12 Changed 12 years ago by mvngu

  • Authors set to Jason Grout
  • Merged in set to sage-4.3.2.alpha0
  • Resolution set to fixed
  • Reviewers set to Robert Bradshaw, John Cremona
  • Status changed from positive_review to closed

comment:13 Changed 12 years ago by jason

The mantissa and exponent for MPFR is not the same as the mantissa and exponent for IEEE 754. So I'm a little doubtful about the choice to follow IEEE 754 conventions for the exponent value of 0. (but I'm not doubtful enough to change it). I just thought I'd point out that the values from MPFR are different than the conventions from IEEE 754 for the same floating point number.

Note: See TracTickets for help on using tickets.