Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #2302 > unrolled thread

64 bit code

Back to article view | Back to comp.programming

Contents

  64 bit code bob <bob@coolfone.comze.com> - 2012-10-10 08:22 -0700
    Re: 64 bit code Jongware <jongware@no-spam.plz> - 2012-10-10 17:35 +0200
      Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-10 17:37 +0100
        Re: 64 bit code Robert Wessel <robertwessel2@yahoo.com> - 2012-10-10 12:54 -0500
        Re: 64 bit code Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-10 21:37 +0200
          Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-10 21:46 -0500
        Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-10 20:43 +0100
          Re: 64 bit code "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-10-12 08:40 +0100
            Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-12 12:36 -0500
            Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-12 20:57 +0100
              Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-12 21:30 +0100
                Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-12 16:33 -0500
                  Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-13 00:44 +0100
                  Re: 64 bit code Ben Pfaff <blp@cs.stanford.edu> - 2012-10-12 20:07 -0700
                Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-13 11:11 +0100
                  Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-13 13:11 +0100
                    Re: 64 bit code Willem <willem@turtle.stack.nl> - 2012-10-13 12:34 +0000
                      Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-13 09:50 -0500
                      Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-13 17:25 +0100
                        Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-13 17:53 +0100
                    Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-13 17:05 +0100
            Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-13 10:37 +0200
              Re: 64 bit code "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-10-27 12:18 +0100
                Re: 64 bit code "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-10-27 12:54 +0100
                Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-27 15:13 +0200
                  Re: 64 bit code Robert Miles <milesrf@Usenet-News.net> - 2012-10-28 04:12 -0500
                    Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-28 13:10 +0100
                      Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-29 04:38 +0000
                        Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-29 09:30 +0100
                          Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-30 22:09 +0000
                            Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-31 09:47 +0100
                              Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-31 09:55 +0100
                              Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-31 14:32 +0000
              Re: 64 bit code Patricia Shanahan <pats@acm.org> - 2012-10-27 08:51 -0700
                Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-27 17:23 +0100
                Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-27 20:43 +0200
                  Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-30 22:16 +0000
                    Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-31 09:53 +0100
                      Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-31 14:33 +0000
                        Re: 64 bit code Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> - 2012-11-01 00:25 +0100
        Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-10 21:04 +0100
          Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-10 21:52 +0100
            Re: 64 bit code Ian Collins <ian-news@hotmail.com> - 2012-10-11 10:50 +1300
              Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-10 21:54 -0500
                Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-11 13:11 +0100
                  Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-11 11:17 -0500
        Re: 64 bit code Ben Pfaff <blp@cs.stanford.edu> - 2012-10-10 13:17 -0700
          Re: 64 bit code Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-11 19:36 +0200
            Re: 64 bit code Ben Pfaff <blp@cs.stanford.edu> - 2012-10-12 08:13 -0700
      Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-10 20:38 +0100
      Re: 64 bit code Robin Vowels <robin.vowels@gmail.com> - 2012-10-10 15:22 -0700
    Re: 64 bit code Robert Miles <milesrf@Usenet-News.net> - 2012-10-12 02:13 -0500

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#2341

BartC wrote:

> If the hardware can directly deal with 64-bit floats, then there is little
> performance loss (compared with attempting 64-bit arithmetic on 32-bit
> hardware, or in software).

It really depends on the hardware and how the code was compiled.  For 
example, the x86-64 ISA includes instructions which take operands that pack 
four single-precision numbers, while the double precision version can only 
pack two double-precision ones, which means that compilers are able to pull 
some magic tricks.  For instance, take the following functions:

<code>
float foo(float const A[], float const B[], float const C[], float const 
D[])
{
        float value = 0;
        for(int i = 0; i < 10; i++)
                value += A[i]+B[i] + C[i] + D[i];

        return value;
}

double bar(double const A[], double const B[], double const C[], double 
const D[])
{
        float value = 0;
        for(int i = 0; i < 10; i++)
                value += A[i]+B[i] + C[i] + D[i];

        return value;
}
</code>


With g++ 4.6, compiling this code with -mtune=k8 -O2, foo() results in a 
loop with 9 instructions, while bar() results in a loop with 11 
instructions.  If -mtune=k8 -O3 is used, foo() unrolls to 50 instructions 
while bar() is unrolled to 71.  

This example might be very specific, but it indicates thath the performance 
penalty associated with the use of double-precision numbers instead of 
single-precision ones may not be that small.  


> Anyway, I remember using 32-bit floats in an application (originally using
> software emulation), and they weren't of sufficient accuracy for some
> types of problems (mapping for example). They only have 1 in 8 million
> precision after all. Switching to 64-bits solved that problem.

That isn't a FP error, only a blatant design error.  Single-precision 
numbers simply weren't capable of representing the numbers that needed to be 
represented.  It's like trying to represent unicode characters in 7-bit 
ASCII.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#2336

On Fri, 12 Oct 2012 08:40:59 +0100, Chris Uppal wrote:

> Rui Maciel wrote:
> 
>> And let's not forget about the ever elusive 80-bit extended precision
>> floating point format, also known as "why bother".
> 
> For one answer, people might like to read:
> 
>     http://www.cs.berkeley.edu/~wkahan/Stnfrd50.pdf
> 
> linked to from Kahan's page:
> 
>     http://www.cs.berkeley.edu/~wkahan/

Great reading, thanks!

I remember George Forsythe’s excellent analysis of numeric computations on
the example of solving a quadratic equation. Basically it showed how
accuracy may flow from point to point. In the example it was one root (very
accurate) and another (catastrophic).

Nonetheless, it is worth to mention that configurable rounding is not an
answer. The answer is IMO interval computations, which always deliver an
*accurate* result (interval certainly containing the exact result).

"Therefore we must (re)design computer architectures,  languages 
and program-development environments to diminish rather than 
enlarge the capture cross-section for numerical misadventure of 
programs written by clever but numerically naive programmers"

Very true, and not limited to numerical programs only.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2394

Dmitry A. Kazakov wrote:

> Nonetheless, it is worth to mention that configurable rounding is not an
> answer. The answer is IMO interval computations, which always deliver an
> *accurate* result (interval certainly containing the exact result).

I've hardly used interval computation at all, but my impression from small 
experiments and what I've read on the web (Kahan's page and elsewhere) is that 
the intervals quickly become unusable wide (i.e. far too pessimistic).

In any case, if you are using floating-point to /implement/ your interval 
arithmetic, then I think you need control over the rounding mode -- since you 
can't risk having the lower bound rounded up, or the upper bound rounded down.

I have a package for my PLoC[*] -- Smalltalk -- which uses rational arithmetic 
for the end-points (tagged exclusive or inclusive), it's really aimed at 
symolic maths over significant ranges (not typicaly error bounds, but "large" 
set like [1,3]) but I have occasionally tried to [ab]use it to get an 
impression of the likely error bounds on some floating-point computation. 
Hasn't been a lot of help to me so far (in that way), but then I don't do a lot 
of floating point stuff, and I'm in no way at all a numerical analysist.

    -- chris 

[toc] | [prev] | [next] | [standalone]

#2396

I wrote:

> I have a package for my PLoC[*] -- Smalltalk -- which uses rational

Forgot to add the footnote: PLoC == Programming Language of Choice

    -- chris 

[toc] | [prev] | [next] | [standalone]

#2397

On Sat, 27 Oct 2012 12:18:47 +0100, Chris Uppal wrote:

> Dmitry A. Kazakov wrote:
> 
>> Nonetheless, it is worth to mention that configurable rounding is not an
>> answer. The answer is IMO interval computations, which always deliver an
>> *accurate* result (interval certainly containing the exact result).
> 
> I've hardly used interval computation at all, but my impression from small 
> experiments and what I've read on the web (Kahan's page and elsewhere) is that 
> the intervals quickly become unusable wide (i.e. far too pessimistic).

But what he described in the lecture was trying all sorts of rounding
behaviors and comparing the results. This is just what interval arithmetic
does automatically. It considers all possible outcomes of rounding and the
resulting interval includes all of them.

Now in this context the argument of being too pessimistic is bogus. Let
rounding r1 yields x1 and rounding r2 yields x2. If x1<<x2 there is nothing
to do about that without additional information. How is that better than
the interval [x1, x2]? It is not a problem of computation, it is of
interpreting the results.

> In any case, if you are using floating-point to /implement/ your interval 
> arithmetic, then I think you need control over the rounding mode -- since you 
> can't risk having the lower bound rounded up, or the upper bound rounded down.

Not really. The only thing you need is a guarantee that the exact result of
the operation is adjacent to the returned value, which all modern CPUs do.
E.g. if the machine operation, say, a+b, returns c, then [c-eps, c+eps]
contains the exact result.

Interval arithmetic is easier to implement when rounding is fixed, like
towards negative infinity. Then you could take [c, c+eps], which is twice
better than when it rounds to the nearest value, because you don't know
where is the exact value, on the left or on the right.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2401

On 10/27/2012 8:13 AM, Dmitry A. Kazakov wrote:
> On Sat, 27 Oct 2012 12:18:47 +0100, Chris Uppal wrote:
>
>> Dmitry A. Kazakov wrote:
[snip]
>> In any case, if you are using floating-point to /implement/ your interval
>> arithmetic, then I think you need control over the rounding mode -- since you
>> can't risk having the lower bound rounded up, or the upper bound rounded down.
> Not really. The only thing you need is a guarantee that the exact result of
> the operation is adjacent to the returned value, which all modern CPUs do.
> E.g. if the machine operation, say, a+b, returns c, then [c-eps, c+eps]
> contains the exact result.

Is that adequate for a-b when a and are nearly  the same?

[toc] | [prev] | [next] | [standalone]

#2402

On Sun, 28 Oct 2012 04:12:51 -0500, Robert Miles wrote:

> On 10/27/2012 8:13 AM, Dmitry A. Kazakov wrote:
>> On Sat, 27 Oct 2012 12:18:47 +0100, Chris Uppal wrote:
>>
>>> Dmitry A. Kazakov wrote:
> [snip]
>>> In any case, if you are using floating-point to /implement/ your interval
>>> arithmetic, then I think you need control over the rounding mode -- since you
>>> can't risk having the lower bound rounded up, or the upper bound rounded down.
>> Not really. The only thing you need is a guarantee that the exact result of
>> the operation is adjacent to the returned value, which all modern CPUs do.
>> E.g. if the machine operation, say, a+b, returns c, then [c-eps, c+eps]
>> contains the exact result.
> 
> Is that adequate for a-b when a and are nearly  the same?

Yes, + or - makes no difference. In general, for intervals:
[a,b]-[c,d]=[a-d,b-c] where a-d is rounded towards negative infinity, b-c
is rounded towards positive infinity.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2403

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1cyg6bpqcn1uu$.w8upkuzwty9o$.dlg@40tude.net...
> On Sun, 28 Oct 2012 04:12:51 -0500, Robert Miles wrote:
>> On 10/27/2012 8:13 AM, Dmitry A. Kazakov wrote:
>>> On Sat, 27 Oct 2012 12:18:47 +0100, Chris Uppal wrote:
>>>> Dmitry A. Kazakov wrote:
>> [snip]
>>>> In any case, if you are using floating-point to /implement/ your 
>>>> interval
>>>> arithmetic, then I think you need control over the rounding mode --  
>>>> since you
>>>> can't risk having the lower bound rounded up, or the upper bound 
>>>> rounded down.
>>> Not really. The only thing you need is a guarantee that the exact result 
>>> of
>>> the operation is adjacent to the returned value, which all modern CPUs 
>>> do.
>>> E.g. if the machine operation, say, a+b, returns c, then [c-eps, c+eps]
>>> contains the exact result.
>>
>> Is that adequate for a-b when a and are nearly  the same?
>
> Yes, + or - makes no difference. In general, for intervals:
> [a,b]-[c,d]=[a-d,b-c] where a-d is rounded towards negative infinity, b-c
> is rounded towards positive infinity.

Some care is needed because, despite different formulations can be 
mathematically equivalent, depending on how exactly a formula is written 
down errors may or may not amplify, i.e. intervals may or may not widen. 
This is called the "dependence problem": each occurrence of a variable in an 
interval computation is treated as a different variables.  Of course, there 
are techniques to tackle this problem.

-LV
 

[toc] | [prev] | [next] | [standalone]

#2404

On Mon, 29 Oct 2012 04:38:33 -0000, LudovicoVan wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1cyg6bpqcn1uu$.w8upkuzwty9o$.dlg@40tude.net...
>> On Sun, 28 Oct 2012 04:12:51 -0500, Robert Miles wrote:

>>> Is that adequate for a-b when a and are nearly  the same?
>>
>> Yes, + or - makes no difference. In general, for intervals:
>> [a,b]-[c,d]=[a-d,b-c] where a-d is rounded towards negative infinity, b-c
>> is rounded towards positive infinity.
> 
> Some care is needed because, despite different formulations can be 
> mathematically equivalent, depending on how exactly a formula is written 
> down errors may or may not amplify, i.e. intervals may or may not widen. 
> This is called the "dependence problem": each occurrence of a variable in an 
> interval computation is treated as a different variables.  Of course, there 
> are techniques to tackle this problem.

Yes, e.g. x*x /= x**2.

But the question, as far as I understood it, was about what happens in the
situations close to underflow. The answer is: nothing wrong. Interval
bounds will capture precision loss.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2406

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:yq9rpdkhtkbq.1a1dn96tarsn6.dlg@40tude.net...
> On Mon, 29 Oct 2012 04:38:33 -0000, LudovicoVan wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1cyg6bpqcn1uu$.w8upkuzwty9o$.dlg@40tude.net...
>>> On Sun, 28 Oct 2012 04:12:51 -0500, Robert Miles wrote:
>
>>>> Is that adequate for a-b when a and are nearly  the same?
>>>
>>> Yes, + or - makes no difference. In general, for intervals:
>>> [a,b]-[c,d]=[a-d,b-c] where a-d is rounded towards negative infinity, 
>>> b-c
>>> is rounded towards positive infinity.
>>
>> Some care is needed because, despite different formulations can be
>> mathematically equivalent, depending on how exactly a formula is written
>> down errors may or may not amplify, i.e. intervals may or may not widen.
>> This is called the "dependence problem": each occurrence of a variable in 
>> an
>> interval computation is treated as a different variables.  Of course, 
>> there
>> are techniques to tackle this problem.
>
> Yes, e.g. x*x /= x**2.
>
> But the question, as far as I understood it, was about what happens in the
> situations close to underflow. The answer is: nothing wrong. Interval
> bounds will capture precision loss.

The typical example of the dependence problem is X-X where X is, for 
instance, [0;1].  By the rule above, we get [-1;1] and not the more obvious 
and quite sharper [0;0].

Again, there are techniques to tackle the problem: rewriting the expression 
as you hint at above, but also using "improper" intervals (I think that was 
the term, but I am going from memory), i.e. relaxing the rule that the left 
end-point must be <= to the right end-point, so that we can rewrite 
[0;1]-[0;1] as [0;1]-[1;0] and get, still by the same rule, the sought for 
result [0;0].

As said, just from the top of my head: details and rules are of course in 
the technical treatments.

-LV
 

[toc] | [prev] | [next] | [standalone]

#2410

On Tue, 30 Oct 2012 22:09:54 -0000, LudovicoVan wrote:

> Again, there are techniques to tackle the problem: rewriting the expression 
> as you hint at above,

There is no magic in dependency analysis, except that it becomes very
complex.

I only wanted to stress that dependency analysis is an equivalent of
rounding analysis. One cannot blame intervals for being too wide without
doing the latter.

> but also using "improper" intervals (I think that was 
> the term, but I am going from memory), i.e. relaxing the rule that the left 
> end-point must be <= to the right end-point, so that we can rewrite 
> [0;1]-[0;1] as [0;1]-[1;0] and get, still by the same rule, the sought for 
> result [0;0].

I believe here you mean extended interval arithmetic, where [1,0] means
]-oo,1[U]0,+oo[.

AFAIK it is difficult to deploy them because their arithmetic is not closed
upon standard operations.

P.S. There is much research done in the direction of fuzzy arithmetic,
where various sets of numbers taken to represent estimations of imprecise
values. From that point of view intervals are such numbers with a
rectangular membership function.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2412

On Wed, 31 Oct 2012 09:47:23 +0100, Dmitry A. Kazakov wrote:

> I believe here you mean extended interval arithmetic, where [1,0] means
> ]-oo,1[U]0,+oo[.

]-oo,0[U]1,+oo[ of course.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2414

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ggvw01gqi246$.byym06hqymay$.dlg@40tude.net...
> On Tue, 30 Oct 2012 22:09:54 -0000, LudovicoVan wrote:
>
>> Again, there are techniques to tackle the problem: rewriting the 
>> expression
>> as you hint at above,
>
> There is no magic in dependency analysis, except that it becomes very
> complex.

Did I mention magic?

> I only wanted to stress that dependency analysis is an equivalent of
> rounding analysis. One cannot blame intervals for being too wide without
> doing the latter.
>
>> but also using "improper" intervals (I think that was
>> the term, but I am going from memory), i.e. relaxing the rule that the 
>> left
>> end-point must be <= to the right end-point, so that we can rewrite
>> [0;1]-[0;1] as [0;1]-[1;0] and get, still by the same rule, the sought 
>> for
>> result [0;0].
>
> I believe here you mean extended interval arithmetic, where [1,0] means
> ]-oo,1[U]0,+oo[.

If it is extended, then you should rather write [-oo ... +oo], i.e. the 
end-points at infinity are included.

Anyway no, I meant and said *closed* interval arithmetic, which is also 
extended but that was not the point.  The example of X-X that does not give 
zero and not even near to zero does not need an extended setting.

> AFAIK it is difficult to deploy them because their arithmetic is not 
> closed
> upon standard operations.

In *closed* interval arithmetic there are no undefined operator-operand 
combinations.

> P.S. There is much research done in the direction of fuzzy arithmetic,
> where various sets of numbers taken to represent estimations of imprecise
> values. From that point of view intervals are such numbers with a
> rectangular membership function.

Which is not what I was talking about.

-LV
 

[toc] | [prev] | [next] | [standalone]

#2398

On 10/13/2012 1:37 AM, Dmitry A. Kazakov wrote:
...
> Nonetheless, it is worth to mention that configurable rounding is not an
> answer. The answer is IMO interval computations, which always deliver an
> *accurate* result (interval certainly containing the exact result).

Do you have some references for non-trivial interval arithmetic
computations that produced a narrow enough range for the answer to be
useful?

Patricia

[toc] | [prev] | [next] | [standalone]

#2399

"Patricia Shanahan" <pats@acm.org> wrote in message 
news:AM2dnUzGRPuOnhHNnZ2dnUVZ_sOdnZ2d@earthlink.com...
> On 10/13/2012 1:37 AM, Dmitry A. Kazakov wrote:
> ...
>> Nonetheless, it is worth to mention that configurable rounding is not an
>> answer. The answer is IMO interval computations, which always deliver an
>> *accurate* result (interval certainly containing the exact result).
>
> Do you have some references for non-trivial interval arithmetic
> computations that produced a narrow enough range for the answer to be
> useful?

Intervals certainly containing the solution is *closed* interval arithmetic 
and it uses outwardly directed rounding.  See E. Hansen, G.W. Walster, 
"Global Optimization Using Interval Analysis".  Systems can be more or less 
"sharp", i.e. provide more or less narrow intervals (at the cost of extra 
complexity).  Some important problems including the Kepler conjecture have 
been eventually proved this way.

-LV
 

[toc] | [prev] | [next] | [standalone]

#2400

On Sat, 27 Oct 2012 08:51:36 -0700, Patricia Shanahan wrote:

> On 10/13/2012 1:37 AM, Dmitry A. Kazakov wrote:
> ...
>> Nonetheless, it is worth to mention that configurable rounding is not an
>> answer. The answer is IMO interval computations, which always deliver an
>> *accurate* result (interval certainly containing the exact result).
> 
> Do you have some references for non-trivial interval arithmetic
> computations that produced a narrow enough range for the answer to be
> useful?

http://www.cs.utep.edu/interval-comp

I would expect iterative algorithms to converge in terms interval width.

The point is that if interval computation yields a result of the width
making it useless, then a result obtained without intervals is garbage
unless rounding error analysis made. Intervals do not solve the original
mathematical problem, they add safety.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2407

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1le7t8ij5jkfp$.4y8buibrxvv7$.dlg@40tude.net...
> On Sat, 27 Oct 2012 08:51:36 -0700, Patricia Shanahan wrote:
>> On 10/13/2012 1:37 AM, Dmitry A. Kazakov wrote:
>> ...
>>> Nonetheless, it is worth to mention that configurable rounding is not an
>>> answer. The answer is IMO interval computations, which always deliver an
>>> *accurate* result (interval certainly containing the exact result).
>>
>> Do you have some references for non-trivial interval arithmetic
>> computations that produced a narrow enough range for the answer to be
>> useful?
>
> http://www.cs.utep.edu/interval-comp
>
> I would expect iterative algorithms to converge in terms interval width.
>
> The point is that if interval computation yields a result of the width
> making it useless, then a result obtained without intervals is garbage
> unless rounding error analysis made. Intervals do not solve the original
> mathematical problem, they add safety.

Sorry but that is not strictly correct either: _closed_ interval arithmetic 
(*) can solve in polynomial time problems that are simply unfeasible to 
traditional approaches.  Informally speaking, this arithmetic works by 
removing non-solutions rather than by selecting solutions.  Again, a most 
famous example is the solution of Kepler's conjecture, which had remained 
open for 300+ years.  And, of course, entirely new computational 
perspectives open, to tackle the general problem of global optimization.

(*) Closed interval arithmetic is not interval arithmetic tout court.  The 
reference text is E. Hansen, G.W. Walster, "Global Optimization Using 
Interval Analysis".

-LV
 

[toc] | [prev] | [next] | [standalone]

#2411

On Tue, 30 Oct 2012 22:16:35 -0000, LudovicoVan wrote:

> Informally speaking, this arithmetic works by 
> removing non-solutions rather than by selecting solutions.

Interesting, this looks like "intuitionistic" numbers describing both
inclusion and/or non-inclusion.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2415

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1vdd6sl1vuknj.1k4qch30g4b57.dlg@40tude.net...
> On Tue, 30 Oct 2012 22:16:35 -0000, LudovicoVan wrote:
>
>> Informally speaking, this arithmetic works by
>> removing non-solutions rather than by selecting solutions.
>
> Interesting, this looks like "intuitionistic" numbers describing both
> inclusion and/or non-inclusion.

It looks more like fried bananas.

-LV
 

[toc] | [prev] | [next] | [standalone]

#2428

"LudovicoVan" <julio@diegidio.name> wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1vdd6sl1vuknj.1k4qch30g4b57.dlg@40tude.net...
> > On Tue, 30 Oct 2012 22:16:35 -0000, LudovicoVan wrote:
> >
> >> Informally speaking, this arithmetic works by
> >> removing non-solutions rather than by selecting solutions.
> >
> > Interesting, this looks like "intuitionistic" numbers describing both
> > inclusion and/or non-inclusion.
> 
> It looks more like fried bananas.

But it tastes like chicken.

Bananas! The "other" white meat!

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.programming

csiph-web