On 3/28/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> This was actually all a footnote to the main question of the original
> post, namely having an UnparsedLiteralDecimal class used by the
> preparser to avoid awkwardness like
>
> sage: RealField(100)('1.2') == RealField(100)(1.2)
> False
I'm
Optimized RDF element allocation "a bit", new benchmarks:
%pyrex
def foo(R, a, b, c, n):
cdef int i
a = R(a); b = R(b); c = R(c)
for i from 0 <= i < n:
z = a*b + b*c + c*a
sage: time foo(RR, 3, 4.5, 200, N)
CPU time: 0.32 s, Wall time: 0.33 s
sage: time foo(RDF, 3, 4.5,
I ran lots of benchmarks before starting this post, I should have
included them. Here they are some typical ones:
%pyrex
def foo(R, a, b, c, n):
cdef int i
a = R(a); b = R(b); c = R(c)
for i from 0 <= i < n:
z = a.sin().sin()
sage: time foo(RR, 3, 4.5, 200, 10^5)
CPU ti
On 3/28/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> > If we decide that we value portability but not necessarily precision,
> > we could use RDF but avoid using C library implementations of the
> > mathematical functions. (Currently, RDF uses the C library for tan(),
> > acos(), asin(), atan
On Mar 28, 2007, at 2:23 PM, cwitty wrote:
>
> On Mar 28, 12:39 pm, Robert Bradshaw <[EMAIL PROTECTED]>
> wrote:
>> On Mar 28, 2007, at 10:27 AM, cwitty wrote:
>>> In the following carefully chosen example, we see a case where a
>>> native double result (or a result using RDF) has only 4 correct
On Mar 28, 12:39 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> On Mar 28, 2007, at 10:27 AM, cwitty wrote:
> > In the following carefully chosen example, we see a case where a
> > native double result (or a result using RDF) has only 4 correct digits
> > (about 12 bits). (This example is from
On Mar 28, 2007, at 10:27 AM, cwitty wrote:
> In the following carefully chosen example, we see a case where a
> native double result (or a result using RDF) has only 4 correct digits
> (about 12 bits). (This example is from John Harrison's paper, _Formal
> verification of floating point trigono
On Mar 28, 2007, at 10:27 , cwitty wrote:
> On Mar 28, 12:53 am, Robert Bradshaw <[EMAIL PROTECTED]>
> wrote:
>> Thank you. This is exactly the kind of information I was looking for.
>> I knew about the range of values limitation, but was only vaguely
>> aware of the rest. The situation I'm think
On Mar 28, 12:53 am, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> Thank you. This is exactly the kind of information I was looking for.
> I knew about the range of values limitation, but was only vaguely
> aware of the rest. The situation I'm thinking of is the default
> implicit ring (e.g. when o
Thank you. This is exactly the kind of information I was looking for.
I knew about the range of values limitation, but was only vaguely
aware of the rest. The situation I'm thinking of is the default
implicit ring (e.g. when one enters "3.2") in which case the lack of
support for rounding
On Mar 27, 12:12 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> Yes, I am aware that lots of doctests would break, but if its just a
> change in the last decimal or two(?) I'm OK with fixing that. I'm
> wondering if anyone knows of any algorithms/etc. that rely on MPFR 53-
> bit rather than nati
On Mar 27, 2007, at 11:01 AM, Nick Alexander wrote:
> On 26 Mar 2007, at 16:42, Robert Bradshaw wrote:
>
>> In working with higher-precision real numbers, I've come across
>> this odd behavior:
>>
>> sage: RealField(200)(1.2)
>> 1.199955591079014993738383054733276367187500
>>
>>
12 matches
Mail list logo
