On Fri, 27 Oct 2006 07:57:10 -0500, Bill Hart <[EMAIL PROTECTED]> wrote:
> William Stein wrote:
>
>> Literals are parsed by the RealNumber command, which you can set to
>> whatever
>> you want (as I explained a day or two ago on sage-devel).
>
> Whoops, I see that now. I can't imagine how I manage
Bill,
Thanks for getting to the bottom of this. It's about time. People
have asked about this probably 10 times before...
-- William
On Fri, 27 Oct 2006 07:57:10 -0500, Bill Hart <[EMAIL PROTECTED]> wrote:
>
>
> William Stein wrote:
>
>> Literals are parsed by the RealNumber command, which
William Stein wrote:
> Literals are parsed by the RealNumber command, which you can set to
> whatever
> you want (as I explained a day or two ago on sage-devel).
Whoops, I see that now. I can't imagine how I managed to miss that. It
works, thanks.
By the way, I noted above that one more decima
On Thu, 26 Oct 2006 14:39:13 -0500, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> I would say that computing more bits would be less confusing. I use the
> general rule of thumb that 10 bits equals 3 decimal digits. At present,
> SAGE seems to be out on the last digits, I think the answer is R(10/3)
>
I would say that computing more bits would be less confusing. I use the
general rule of thumb that 10 bits equals 3 decimal digits. At present,
SAGE seems to be out on the last digits, I think the answer is R(10/3)
= 3.35 bits. :-)
On a more serious note, sage currently claims to be w
On Thu, 26 Oct 2006 12:38:10 -0500, Vanuxem Grégory <[EMAIL PROTECTED]>
wrote:
>
> Le mercredi 25 octobre 2006 à 22:17 -0400, didier deshommes a écrit :
>
> [...]
>
>>
>> BTW, there is a tiny bug in rings/real_mpfr.pyx. In the documentation,
>> it says that the default precision is RNDU (round
On Thu, 26 Oct 2006 12:36:02 -0500, Justin C. Walker <[EMAIL PROTECTED]>
wrote:
>> SAGE could internally compute with a few more digits of precision
>> than requested, and always output numbers with the last few digits
>> truncated. Would that be less confusing?
>
> I believe that this is the w
Le mercredi 25 octobre 2006 à 22:17 -0400, didier deshommes a écrit :
[...]
>
> BTW, there is a tiny bug in rings/real_mpfr.pyx. In the documentation,
> it says that the default precision is RNDU (round to + \inf), but it's
> actually set to RNDN...
Same thing for sci_not (scientific notation)
On Oct 26, 2006, at 10:23 , William Stein wrote:
>
> On Thu, 26 Oct 2006 06:51:42 -0500, Bill Hart <[EMAIL PROTECTED]>
> wrote:
>
>>
>> But it returns the answer in decimal, not binary, and the answer is
>> incorrect, in some cases not just to one, but to two decimal places.
>>
>> I have read
On Thu, 26 Oct 2006 06:51:42 -0500, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> But it returns the answer in decimal, not binary, and the answer is
> incorrect, in some cases not just to one, but to two decimal places.
>
> I have read the MPFR manual, in detail, and I understand their model
> and wh
But it returns the answer in decimal, not binary, and the answer is
incorrect, in some cases not just to one, but to two decimal places.
I have read the MPFR manual, in detail, and I understand their model
and why it is useful, but I find it confusing to output the incorrect
decimal expression in
On Thu, 26 Oct 2006 04:10:20 -0500, Bill Hart <[EMAIL PROTECTED]> wrote:
> Well, why does R(61/3) return the wrong thing then? 61/3 is an exact
> expression, which should then be computed correctly. It's not.
> None of this makes sense to me as a default behaviour by the way.
MPFR's arithmetic ma
Well, why does R(61/3) return the wrong thing then? 61/3 is an exact
expression, which should then be computed correctly. It's not.
None of this makes sense to me as a default behaviour by the way.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-d
On Wed, 25 Oct 2006 23:36:57 -0500, Justin C. Walker <[EMAIL PROTECTED]>
wrote:
> On Oct 25, 2006, at 21:17 , didier deshommes wrote:
>> On 10/25/06, William Stein <[EMAIL PROTECTED]> wrote:
>>> You should do RR('61/3.0') or RR('61')/RR('3.0') instead of
>>> what you wrote above.
>>
>> Even more
On Oct 25, 2006, at 21:17 , didier deshommes wrote:
>
> On 10/25/06, William Stein <[EMAIL PROTECTED]> wrote:
>> You should do RR('61/3.0') or RR('61')/RR('3.0') instead of
>> what you wrote above.
>
> Even more convenient. Is that in SAGE-1.4.1? In sage 1.4, I get an
> error when I try it:
> sa
On 10/25/06, William Stein <[EMAIL PROTECTED]> wrote:
> You should do RR('61/3.0') or RR('61')/RR('3.0') instead of
> what you wrote above.
Even more convenient. Is that in SAGE-1.4.1? In sage 1.4, I get an
error when I try it:
sage: RR('61/1.0')
--
On Wed, 25 Oct 2006 21:17:53 -0500, didier deshommes <[EMAIL PROTECTED]>
wrote:
> On 10/25/06, Bill Hart <[EMAIL PROTECTED]> wrote:
>>
>> When asked 61/3.0, SAGE returns:
>>
>> 20.332
>>
>> Now I understand that floating point numbers are often rounded down to
>> prevent floating poi
On 10/25/06, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> When asked 61/3.0, SAGE returns:
>
> 20.332
>
> Now I understand that floating point numbers are often rounded down to
> prevent floating point drift. But I was wondering if rounding it down
> in the manner above is quite necessary.
18 matches
Mail list logo
