16 views

Skip to first unread message

Jun 8, 2011, 3:04:35 PM6/8/11

to sage-devel

On Trac ticket #8896 (http://trac.sagemath.org/sage_trac/ticket/8896),

there is some discussion about whether or not the number 0.00000000

(with many zeros) should have a higher precision than 0.0. Currently,

0.0 and 0.0000000000000000 have the same precision of 53 bits.

there is some discussion about whether or not the number 0.00000000

(with many zeros) should have a higher precision than 0.0. Currently,

0.0 and 0.0000000000000000 have the same precision of 53 bits.

In my opinion, the current behaviour is what makes the most sense

mathematically, but other disagree.

Jun 8, 2011, 3:09:55 PM6/8/11

to sage-...@googlegroups.com

Another issue is the following two cases:

000000000000000000.0

and

0.000000000000000000

Should those both have the same precision? As Robert points out on the

ticket, this is related to what the definition of 'trailing zero' is.

Thanks,

Jason

Jun 8, 2011, 3:17:15 PM6/8/11

to sage-...@googlegroups.com

On 2011-06-08 21:09, Jason Grout wrote:

> On 6/8/11 2:04 PM, Jeroen Demeyer wrote:

>> On Trac ticket #8896 (http://trac.sagemath.org/sage_trac/ticket/8896),

>> there is some discussion about whether or not the number 0.00000000

>> (with many zeros) should have a higher precision than 0.0. Currently,

>> 0.0 and 0.0000000000000000 have the same precision of 53 bits.

>>

>> In my opinion, the current behaviour is what makes the most sense

>> mathematically, but other disagree.

>

> Another issue is the following two cases:

>

> 000000000000000000.0

>

> and

>

> 0.000000000000000000

>

> Should those both have the same precision?

> On 6/8/11 2:04 PM, Jeroen Demeyer wrote:

>> On Trac ticket #8896 (http://trac.sagemath.org/sage_trac/ticket/8896),

>> there is some discussion about whether or not the number 0.00000000

>> (with many zeros) should have a higher precision than 0.0. Currently,

>> 0.0 and 0.0000000000000000 have the same precision of 53 bits.

>>

>> In my opinion, the current behaviour is what makes the most sense

>> mathematically, but other disagree.

>

> Another issue is the following two cases:

>

> 000000000000000000.0

>

> and

>

> 0.000000000000000000

>

> Should those both have the same precision?

Since a decimal point simply indicates a change of exponent in the

floating-point representation, I think these two certainly should have

the same precision. Think of the above numbers as

0000000000000000000e-1

and

0000000000000000000e-18

Jeroen

Jun 8, 2011, 3:23:02 PM6/8/11

to sage-...@googlegroups.com

But we already have the convention that zeros after the decimal indicate

precision:

sage: a=4.000000000000000000000000000000

sage: a.prec()

103

sage: b=4.00000

sage: b.prec()

53

So there is already something special about where the decimal point is

placed.

Jason

Jun 8, 2011, 3:26:50 PM6/8/11

to sage-...@googlegroups.com

On 2011-06-08 21:23, Jason Grout wrote:

> So there is already something special about where the decimal point is

> placed.

Not really. My claim is that> So there is already something special about where the decimal point is

> placed.

4.000000000000000000000000000000

and

4000000000000000000000000000000.

and

4000000000000000000000000000000e100

should have the same precision.

I did not make a claim about

4.00000

Jun 8, 2011, 3:32:16 PM6/8/11

to sage-devel

On Jun 8, 12:23 pm, Jason Grout <jason-s...@creativetrax.com> wrote:

> But we already have the convention that zeros after the decimal indicate

> precision:

[...]
> But we already have the convention that zeros after the decimal indicate

> precision:

> So there is already something special about where the decimal point is

> placed.

Actually, it looks to me like it's zeros after a non-zero digit that
> placed.

have a special role. I don't think the decimal point plays a role in

this:

sage: parent(4.00000000000000000000)

Real Field with 70 bits of precision

sage: parent(400000000000000000.000)

Real Field with 70 bits of precision

sage: parent(0.400000000000000000000)

Real Field with 70 bits of precision

sage: parent(0.0000000000000000400000000000000000000)

Real Field with 70 bits of precision

sage: parent(00000000000000400000000000000000.000)

Real Field with 70 bits of precision

(in each example there are 20 zeros trailing the 4)

That's also the reason why the system has problems guessing the right

precision for representations of 0. I think providing a way to imply

precision for 0 by specifying extra leading/trailing zeros (how do you

tell the difference?) is always going to be a hack.

Jun 8, 2011, 3:40:47 PM6/8/11

to sage-...@googlegroups.com

On Wed, Jun 8, 2011 at 12:26 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:

> On 2011-06-08 21:23, Jason Grout wrote:

>> So there is already something special about where the decimal point is

>> placed.

> Not really. My claim is that

> 4.000000000000000000000000000000

> and

> 4000000000000000000000000000000.

> and

> 4000000000000000000000000000000e100

> should have the same precision.

> On 2011-06-08 21:23, Jason Grout wrote:

>> So there is already something special about where the decimal point is

>> placed.

> Not really. My claim is that

> 4.000000000000000000000000000000

> and

> 4000000000000000000000000000000.

> and

> 4000000000000000000000000000000e100

> should have the same precision.

Which they do, that's not the question here.

The question is really whether

0.00000000000000000000000000000000

should have the same precision as

1.00000000000000000000000000000000

I think it should, as the only semantic information trailing zeros

could possibly carry is an attempt to increase precision. I find the

fact that adding zeros to the latter increases precision, but adding

zeros to the former does not, to be surprising. To me, trailing zeros

are the unnecessary zeros to the right of a decimal expansion (whether

or not they come after a non-zero digit), and are used to denote

precision.

Whether 000000000000000000.0 and 0.000000000000000000 have the same

precision is a smaller question, but I'm inclined to say yes.

- Robert

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu