<div><span class="q" style="color: rgb(85, 0, 85); "><span class="gmail_quote">On 9/30/07, <b class="gmail_sendername">Facundo Batista</b> <<a href="mailto:facundobatista@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
facundobatista@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">2007/9/28, Rob Crowther <<a href="mailto:weilawei@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
weilawei@gmail.com</a>>:<br><br>> a) MPF() now takes a float or integer argument because mpf_set_str is just<br><br>Rob, there has been a *lot* of discussion about this for Decimal (see <br>the PEP and discussions in python-dev and python-list around the PEP
<br>date).</blockquote><div><br> </div></span><div>But there's a major difference here: Decimal is *decimal* floating point, MPF and Python floats are *binary* floating point. </div><div><br> </div><div>So in the case of Decimal, conversion from a decimal string is a straightforward operation, while conversion from binary involves making choices about how to round, how many decimal digits to use, etc.
</div><div><br> </div><div>But for MPF it's the other way around: conversion from a float is immediate (the GMP precision is always at least 53 bits, so any IEEE double can be represented as an MPF with no loss of information), while conversion from a string involves hard work and decisions about how to round (and GMP's approach to rounding seems pretty haphazard here...).
</div><div><br> </div><div>So since there's really no ambiguity about what MPF(float) should be, and since it's a computationally trivial operation to initialize an MPF from a float, you certainly want to allow MPF's to be initialized from floats. Admittedly, for initialization from a float *literal* there are still going to be some surprises for the unwary: with MPF precision set to 128 bits, MPF(
1.1) is going to give a binary number that's an accurate representation of the decimal 1.1 to only 53 bits, not 128 bits.</div><span class="q" style="color: rgb(85, 0, 85); "><div><br> </div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
The main issue here is what means the user if he calls MPF(2.3):<br><br>a) MPF("2.3")<br><br>b) MPF("2.2999999999999998")</blockquote><div><br> </div></span><div>All 3 of MPF(2.3), MPF("2.3") and MPF("
2.29...998") should be different values. MPF(2.3) is the closest 53-bit binary floating point number to the decimal 2.3, padded out with zero bits to whatever the current MPF precision is. MPF("2.3") should ideally be the closest p-bit binary floating point number to the decimal
2.3, where p is the current precision. But in fact, with the way that GMP works it seems that all that can be said is that MPF("2.3") is a (p+some_extra_bits) binary floating point number that's close (but not necessarily closest) to the decimal
2.3. Similarly for MPF("2.29...998").</div><div><br> </div><div>By the way, I'm wondering whether this discussion really belongs on comp.lang.python instead...</div><div><br> </div><div>Mark</div></div>