On Jan 1, 2010, at 2:08 PM, TimDaly wrote:
>> That is to say, if the Sage
>> documentation says:
>>
>>sage: foo(bar)
>>1.2345
>>
>> but in fact in Sage one has
>>
>>sage: foo(bar)
>>1.2351
>>
>> then I would consider this misleading documentation, i.e., a bug.
>> Your statement
Peter Jeremy wrote:
> There are some gotchas here. On an i387 in default (80-bit) mode, a
> local double variable may be 80-bits if kept in a register but 64-bits
> if written to memory. This means the precision of working variables
> in a function can alternate between 64 and 80 bits depending
William Stein wrote:
>
> Test like your suggestion above would make perfect sense as unittests
> or in the context of randomized testing. Those are great, there are
> some in Sage, but they serve a different purpose than doctests.
>
> William
>
As a matter of interest, I wrote a few lines of
On Fri, Jan 1, 2010 at 2:18 PM, Dr. David Kirkby
wrote:
> TimDaly wrote:
>
>> All non-bit floating point output involves a choice of rounding.
>> You have chosen to do rounding by truncation. This choice is not
>> obvious nor necessarily the best. See
>> http://www.diycalculator.com/popup-m-round.
TimDaly wrote:
> All non-bit floating point output involves a choice of rounding.
> You have chosen to do rounding by truncation. This choice is not
> obvious nor necessarily the best. See
> http://www.diycalculator.com/popup-m-round.shtml
>
> In any case, you're welcome to test any way you prefe
> That is to say, if the Sage
> documentation says:
>
> sage: foo(bar)
> 1.2345
>
> but in fact in Sage one has
>
> sage: foo(bar)
> 1.2351
>
> then I would consider this misleading documentation, i.e., a bug.
> Your statement above suggests that you *don't* consider this a bug at
>
On Thu, Dec 31, 2009 at 10:09 PM, Tim Daly wrote:
> William Stein wrote:
>> On Thu, Dec 31, 2009 at 9:13 PM, Tim Daly wrote:
>> The output is used both for human use and for regression testing. Its
>> primary use is human -- it's an example in the Sage reference manual:
>>
>> sage: float(e)
>
On Thu, Dec 31, 2009 at 10:09 PM, Tim Daly wrote:
> William Stein wrote:
>> On Thu, Dec 31, 2009 at 9:13 PM, Tim Daly wrote:
>> The output is used both for human use and for regression testing. Its
>> primary use is human -- it's an example in the Sage reference manual:
>>
>> sage: float(e)
>
Assuring the correctness of the binary-to-decimal conversion of the
sage output routines can and should be done separately from testing
the exp() function.
That should be fairly obvious.
I am amazed by your insistence that this kind of decimal output should
be used in regression testing.
Certainly
William Stein wrote:
> On Thu, Dec 31, 2009 at 9:13 PM, Tim Daly wrote:
>
>> Dr. David Kirkby wrote:
>>
>>> rjf wrote:
>>>
>>>
On Dec 31, 11:15 am, "Dr. David Kirkby"
wrote:
>> RJF
>>
>>
> The point you are missing is t
On Thu, Dec 31, 2009 at 9:13 PM, Tim Daly wrote:
> Dr. David Kirkby wrote:
>> rjf wrote:
>>
>>> On Dec 31, 11:15 am, "Dr. David Kirkby"
>>> wrote:
>>>
>>>
> RJF
>
The point you are missing is that we want to compare the output what Sage
prints
to a human.
>>> The
Dr. David Kirkby wrote:
> rjf wrote:
>
>> On Dec 31, 11:15 am, "Dr. David Kirkby"
>> wrote:
>>
>>
RJF
>>> The point you are missing is that we want to compare the output what Sage
>>> prints
>>> to a human.
>>>
>>>
>> The point you are missing is that the followi
rjf wrote:
>
> On Dec 31, 11:15 am, "Dr. David Kirkby"
> wrote:
>
>>> RJF
>> The point you are missing is that we want to compare the output what Sage
>> prints
>> to a human.
>>
>
> The point you are missing is that the following item, which presumably
> could be printed by Sage,
> is perfect
On Dec 31, 11:15 am, "Dr. David Kirkby"
wrote:
> > RJF
>
> The point you are missing is that we want to compare the output what Sage
> prints
> to a human.
>
The point you are missing is that the following item, which presumably
could be printed by Sage,
is perfectly readable to a human:
612
rjf wrote:
> You guys could eliminate one (I suspect major) source of confusion by
> not printing the numbers in decimal and reading them back in from
> character strings.
>
> You can read/write exact hexadecimal 64-bit floating-point binary
> numbers.
> or you can write them out as X base you c
You guys could eliminate one (I suspect major) source of confusion by
not printing the numbers in decimal and reading them back in from
character strings.
You can read/write exact hexadecimal 64-bit floating-point binary
numbers.
or you can write them out as X X 2^
without any error or possible
16 matches
Mail list logo
