ASKSAGE: Sage Q&A Forum - RSS feedhttps://ask.sagemath.org/questions/Q&A Forum for SageenCopyright Sage, 2010. Some rights reserved under creative commons license.Mon, 25 Jun 2018 23:27:05 +0200Semantics of RealBallField and RealIntervalField ?https://ask.sagemath.org/question/42722/semantics-of-realballfield-and-realintervalfield/I do not understand the meaning (or the output) of RealBallField elements. An example will be clearer :
sage: foo=RealBallField(10)(pi/2);foo
[1.57 +/- 2.27e-3]
So far, so good.
sage: sin(foo)
[1.0 +/- 3.92e-3]
An interval *centered* on 1, Isn't there a problem ? Mathematically, he upper bound is 1, and, since the derivative is 0, the maximal error is intuitively expected to be much smaller than the error on the argument. Let's find out analytically. If I'm not mistaken, the maximal error is :
sage: 1-sin(pi/2-2^-10).n()
4.76837120344520e-7
So I would expect something along the lines of [1-4.76*10^-7 1].
Maybe my expectation to use directly the printed notation is misguided. Let's use the specialized methods :
sage: sin(foo).below_abs()
[0.996 +/- 9.38e-5]
sage: sin(foo).above_abs()
[1.00 +/- 3.91e-3]
Three surprises :
* I'd expect the bounds to be ("sharp") reals, not balls...
* The stated radii make no sense to me/
* The stated lower bound is way too low.
Therefore, I do not understand the results. But I may be mistaken : my last formal contact with numerical analysis of errors is about 35 years old...
Can some kind soul point me to an explanation ?
Note : the RealIntervalField gives me *different* nonsense :
sage: bar=RealIntervalField(10)(pi/2);bar
1.58?
sage: bar.str(style="brackets")
'[1.5703 .. 1.5723]'
Okay so far...
sage: sin(bar)
1.000?
Possibly okay : value at the center of the argument. But not the center of the interval...
sage: sin(bar).str(style="brackets")
'[0.99902 .. 1.0000]'
The upper bound is correct ; I beleeve that the lower bound is too low...
sage: sin(bar).center()
1.0
Again, this is not the center of the interval, but the value at the center of the interval of the *argument*...
sage: sin(bar).absolute_diameter()
0.00098
I think this is too low...
**EDIT :** My understanding problems mat be better summarized by the following :
sage: foo=RealBallField(10)(pi/2);foo
[1.57 +/- 2.27e-3]
sage: bar=RealIntervalField(10)(pi/2);bar
1.58?
sage: foo.sin().upper()
1.1
sage: bar.sin().upper()
1.0Sat, 23 Jun 2018 11:27:09 +0200https://ask.sagemath.org/question/42722/semantics-of-realballfield-and-realintervalfield/Answer by tmonteil for <p>I do not understand the meaning (or the output) of RealBallField elements. An example will be clearer :</p>
<pre><code>sage: foo=RealBallField(10)(pi/2);foo
[1.57 +/- 2.27e-3]
</code></pre>
<p>So far, so good.</p>
<pre><code>sage: sin(foo)
[1.0 +/- 3.92e-3]
</code></pre>
<p>An interval <em>centered</em> on 1, Isn't there a problem ? Mathematically, he upper bound is 1, and, since the derivative is 0, the maximal error is intuitively expected to be much smaller than the error on the argument. Let's find out analytically. If I'm not mistaken, the maximal error is :</p>
<pre><code>sage: 1-sin(pi/2-2^-10).n()
4.76837120344520e-7
</code></pre>
<p>So I would expect something along the lines of [1-4.76*10^-7 1].</p>
<p>Maybe my expectation to use directly the printed notation is misguided. Let's use the specialized methods :</p>
<pre><code>sage: sin(foo).below_abs()
[0.996 +/- 9.38e-5]
sage: sin(foo).above_abs()
[1.00 +/- 3.91e-3]
</code></pre>
<p>Three surprises :</p>
<ul>
<li>I'd expect the bounds to be ("sharp") reals, not balls...</li>
<li>The stated radii make no sense to me/</li>
<li>The stated lower bound is way too low.</li>
</ul>
<p>Therefore, I do not understand the results. But I may be mistaken : my last formal contact with numerical analysis of errors is about 35 years old...</p>
<p>Can some kind soul point me to an explanation ?</p>
<p>Note : the RealIntervalField gives me <em>different</em> nonsense :</p>
<pre><code>sage: bar=RealIntervalField(10)(pi/2);bar
1.58?
sage: bar.str(style="brackets")
'[1.5703 .. 1.5723]'
</code></pre>
<p>Okay so far...</p>
<pre><code>sage: sin(bar)
1.000?
</code></pre>
<p>Possibly okay : value at the center of the argument. But not the center of the interval...</p>
<pre><code>sage: sin(bar).str(style="brackets")
'[0.99902 .. 1.0000]'
</code></pre>
<p>The upper bound is correct ; I beleeve that the lower bound is too low...</p>
<pre><code>sage: sin(bar).center()
1.0
</code></pre>
<p>Again, this is not the center of the interval, but the value at the center of the interval of the <em>argument</em>...</p>
<pre><code>sage: sin(bar).absolute_diameter()
0.00098
</code></pre>
<p>I think this is too low...</p>
<p><strong>EDIT :</strong> My understanding problems mat be better summarized by the following :</p>
<pre><code>sage: foo=RealBallField(10)(pi/2);foo
[1.57 +/- 2.27e-3]
sage: bar=RealIntervalField(10)(pi/2);bar
1.58?
sage: foo.sin().upper()
1.1
sage: bar.sin().upper()
1.0
</code></pre>
https://ask.sagemath.org/question/42722/semantics-of-realballfield-and-realintervalfield/?answer=42724#post-id-42724Ball arithmetics and interval arithmetics serve the same purpose: computing with high-precision floating-point numbers with a guaranteed bound on the approximation error which remains correct along the computation.
So to understand the difference, it is better to work with, say, 1000 bits of precision, not 10.
In interval arithmetics, numbers are represented with an interval whose endpoints have 1000 bits of precision. So, for the computation of the sinus of an interval that contains ``pi/2``, it makes sense to say that the upper point of the image is 1 (so that the computation of this endpoint is both very fast and accurate).
In ball arithmetics, numbers are represented with a ball whose center has 1000 bits of precision, but the radius has only 30 bits of precision: when the precision is high, the computation is twice as fast as for interval arithmetics, and you do not want to sacrifice that advantage. So, to compute the image of a ball by a function, the image of the center is computed with high precision and an estimation of the error is made to compute the radius.
Now, imagine that we want to achieve the behaviour you are expecting, that is that the image of a ball that contains ``pi/2`` has its right endpoint equal to 1: this implies that you will have to shift the center accordingly, which requires an additional compuration with 1000 bits of precision. Moreover, since both the radius and 1 can be expressed with 30 bits of precision, if you want the right side of the ball to be exactly 1, it will imply that the new center and the left side of the ball will also be exprimable with 30 bits of precision, which might imply a loss of precision of that side (not completely sure, you should make the computation to get convinced).
Basically, the ``upper`` and ``lower`` methods are meaningful for interval arithmetics, while for ball arithmetics, the interesing methods are ``center`` and ``rad``.
You can also have a look at the thematic tutorial about the representations of real and complex numbers proposed at https://trac.sagemath.org/ticket/15944Sun, 24 Jun 2018 10:47:23 +0200https://ask.sagemath.org/question/42722/semantics-of-realballfield-and-realintervalfield/?answer=42724#post-id-42724Comment by Emmanuel Charpentier for <p>Ball arithmetics and interval arithmetics serve the same purpose: computing with high-precision floating-point numbers with a guaranteed bound on the approximation error which remains correct along the computation.</p>
<p>So to understand the difference, it is better to work with, say, 1000 bits of precision, not 10.</p>
<p>In interval arithmetics, numbers are represented with an interval whose endpoints have 1000 bits of precision. So, for the computation of the sinus of an interval that contains <code>pi/2</code>, it makes sense to say that the upper point of the image is 1 (so that the computation of this endpoint is both very fast and accurate).</p>
<p>In ball arithmetics, numbers are represented with a ball whose center has 1000 bits of precision, but the radius has only 30 bits of precision: when the precision is high, the computation is twice as fast as for interval arithmetics, and you do not want to sacrifice that advantage. So, to compute the image of a ball by a function, the image of the center is computed with high precision and an estimation of the error is made to compute the radius.</p>
<p>Now, imagine that we want to achieve the behaviour you are expecting, that is that the image of a ball that contains <code>pi/2</code> has its right endpoint equal to 1: this implies that you will have to shift the center accordingly, which requires an additional compuration with 1000 bits of precision. Moreover, since both the radius and 1 can be expressed with 30 bits of precision, if you want the right side of the ball to be exactly 1, it will imply that the new center and the left side of the ball will also be exprimable with 30 bits of precision, which might imply a loss of precision of that side (not completely sure, you should make the computation to get convinced).</p>
<p>Basically, the <code>upper</code> and <code>lower</code> methods are meaningful for interval arithmetics, while for ball arithmetics, the interesing methods are <code>center</code> and <code>rad</code>.</p>
<p>You can also have a look at the thematic tutorial about the representations of real and complex numbers proposed at <a href="https://trac.sagemath.org/ticket/15944">https://trac.sagemath.org/ticket/15944</a></p>
https://ask.sagemath.org/question/42722/semantics-of-realballfield-and-realintervalfield/?comment=42733#post-id-42733Thanks a lot. This points me to the fact that my assumptions about balls were wrong. I'll have to read a bit about those to understand the point...Mon, 25 Jun 2018 23:27:05 +0200https://ask.sagemath.org/question/42722/semantics-of-realballfield-and-realintervalfield/?comment=42733#post-id-42733