Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Computation using real numbers as opposed to rational approximations to real numbers
41 views
Skip to first unread message
Robert Myers
Jan 10, 2012, 9:28:51 PM1/10/12
to
Since computers doing credible numerical analysis are going to spend
most of their time waiting for data to arrive from the other side of the
universe, perhaps we can find a way to keep exotic CPU's busy while waiting.
Would anyone care to speculate on the possibility of using (recursively
computable) continued fractions to do arithmetic with actual real
numbers, as opposed to rational approximations to real numbers?
Unless you throw sand in the gears by deliberately introducing
pathological real numbers (e.g. ones whose continued fraction
representation would involve frequent primality testing), I don't think
that computers are likely to produce real numbers that do not have a
recursively computable continued fraction representation.
Just think. No more haggling over the round-off bit or denormals.
Robert.
most of their time waiting for data to arrive from the other side of the
universe, perhaps we can find a way to keep exotic CPU's busy while waiting.
Would anyone care to speculate on the possibility of using (recursively
computable) continued fractions to do arithmetic with actual real
numbers, as opposed to rational approximations to real numbers?
Unless you throw sand in the gears by deliberately introducing
pathological real numbers (e.g. ones whose continued fraction
representation would involve frequent primality testing), I don't think
that computers are likely to produce real numbers that do not have a
recursively computable continued fraction representation.
Just think. No more haggling over the round-off bit or denormals.
Robert.
nm...@cam.ac.uk
Jan 11, 2012, 4:06:05 AM1/11/12
to
In article <gu6Pq.25710$Uj1....@newsfe20.iad>,
>Would anyone care to speculate on the possibility of using (recursively
>computable) continued fractions to do arithmetic with actual real
>numbers, as opposed to rational approximations to real numbers?
That's a deluded dichotomy - sorry. You need to compare like with
like. A continued fraction representation has been studied in the
past, and so has the representation of numbers as lazy functions
(i.e. where you can call and recall them, asking for as many bits
as you want). But those are entirely different!
>Unless you throw sand in the gears by deliberately introducing
>pathological real numbers (e.g. ones whose continued fraction
>representation would involve frequent primality testing), I don't think
>that computers are likely to produce real numbers that do not have a
>recursively computable continued fraction representation.
I am too rusty to remember the theory, but am not sure of that,
though it's probably true.
Anyway, back to our muttons. The problem is that there are a lot
of practical calculations where the error of intermediate values
builds up super-exponentially, but where the final result can be
reliable. It doesn't matter WHAT form of lazy function you use,
those calculations are always going to knacker such approaches.
A simple language using lazy evaluation would be very useful for
some specialist purposes, such as calculating the constants for
special functions, but I don't see much scope in general.
Regards,
Nick Maclaren.
Robert Myers <rbmye...@gmail.com> wrote:
>
>Since computers doing credible numerical analysis are going to spend
>most of their time waiting for data to arrive from the other side of the
>universe, perhaps we can find a way to keep exotic CPU's busy while waiting.
There are lots out there, of which this is one.
>
>Since computers doing credible numerical analysis are going to spend
>most of their time waiting for data to arrive from the other side of the
>universe, perhaps we can find a way to keep exotic CPU's busy while waiting.
>Would anyone care to speculate on the possibility of using (recursively
>computable) continued fractions to do arithmetic with actual real
>numbers, as opposed to rational approximations to real numbers?
like. A continued fraction representation has been studied in the
past, and so has the representation of numbers as lazy functions
(i.e. where you can call and recall them, asking for as many bits
as you want). But those are entirely different!
>Unless you throw sand in the gears by deliberately introducing
>pathological real numbers (e.g. ones whose continued fraction
>representation would involve frequent primality testing), I don't think
>that computers are likely to produce real numbers that do not have a
>recursively computable continued fraction representation.
though it's probably true.
Anyway, back to our muttons. The problem is that there are a lot
of practical calculations where the error of intermediate values
builds up super-exponentially, but where the final result can be
reliable. It doesn't matter WHAT form of lazy function you use,
those calculations are always going to knacker such approaches.
A simple language using lazy evaluation would be very useful for
some specialist purposes, such as calculating the constants for
special functions, but I don't see much scope in general.
Regards,
Nick Maclaren.
Robert Myers
Jan 11, 2012, 2:28:11 PM1/11/12
to
On 1/11/2012 4:06 AM, nm...@cam.ac.uk wrote:
> In article<gu6Pq.25710$Uj1....@newsfe20.iad>,
> Robert Myers<rbmye...@gmail.com> wrote:
>>
>> Since computers doing credible numerical analysis are going to spend
>> most of their time waiting for data to arrive from the other side of the
>> universe, perhaps we can find a way to keep exotic CPU's busy while waiting.
>
> There are lots out there, of which this is one.
>
>> Would anyone care to speculate on the possibility of using (recursively
>> computable) continued fractions to do arithmetic with actual real
>> numbers, as opposed to rational approximations to real numbers?
>
> That's a deluded dichotomy - sorry. You need to compare like with
> like. A continued fraction representation has been studied in the
> past, and so has the representation of numbers as lazy functions
> (i.e. where you can call and recall them, asking for as many bits
> as you want). But those are entirely different!
>
Perhaps I misused terminology. It is easy to imagine continued
> In article<gu6Pq.25710$Uj1....@newsfe20.iad>,
> Robert Myers<rbmye...@gmail.com> wrote:
>>
>> Since computers doing credible numerical analysis are going to spend
>> most of their time waiting for data to arrive from the other side of the
>> universe, perhaps we can find a way to keep exotic CPU's busy while waiting.
>
> There are lots out there, of which this is one.
>
>> Would anyone care to speculate on the possibility of using (recursively
>> computable) continued fractions to do arithmetic with actual real
>> numbers, as opposed to rational approximations to real numbers?
>
> That's a deluded dichotomy - sorry. You need to compare like with
> like. A continued fraction representation has been studied in the
> past, and so has the representation of numbers as lazy functions
> (i.e. where you can call and recall them, asking for as many bits
> as you want). But those are entirely different!
>
fractions for which there is no substantially shorter representation
than actually writing the fraction out until you run out of room or
tired to write. For such continued fractions, there is no advantage to
continued fractions over arbitrary precision arithmetic. You get as
much as you pay for by way of precision. No more, and no less.
For some useful continued fractions, a rule would suffice for forward
computation of as many terms of the fraction as you might desire. You
may, in some cases of interest, be able to do computation by
manipulating the rules, rather than by manipulating the continued
fraction itself. In some cases a finite continued fraction
representation of a real number might offer advantages over a rational
approximation, but that is not what I am proposing. I am proposing
manipulating the continued fraction as you would infinite series--where
it is possible to do so, as in the case of exp (i * theta) = cos (theta)
+ i sin (theta).
>> Unless you throw sand in the gears by deliberately introducing
>> pathological real numbers (e.g. ones whose continued fraction
>> representation would involve frequent primality testing), I don't think
>> that computers are likely to produce real numbers that do not have a
>> recursively computable continued fraction representation.
>
> I am too rusty to remember the theory, but am not sure of that,
> though it's probably true.
>
> Anyway, back to our muttons. The problem is that there are a lot
> of practical calculations where the error of intermediate values
> builds up super-exponentially, but where the final result can be
> reliable. It doesn't matter WHAT form of lazy function you use,
> those calculations are always going to knacker such approaches.
>
> A simple language using lazy evaluation would be very useful for
> some specialist purposes, such as calculating the constants for
> special functions, but I don't see much scope in general.
>
general sense. Are denormals useful in any general sense? ;-)
Even though it has clearly occurred to others before, it had not
occurred to me that there was any way to manipulate real numbers (as
opposed to rational approximations to real numbers) on a computer.
Robert.
nm...@cam.ac.uk
Jan 12, 2012, 3:48:14 AM1/12/12
to
In article <YplPq.73747$ed2....@newsfe05.iad>,
>I wasn't proposing anything that I thought actually *useful* in any
>general sense. Are denormals useful in any general sense? ;-)
Kahan and his followers think so; others don't. It's moot.
>Even though it has clearly occurred to others before, it had not
>occurred to me that there was any way to manipulate real numbers (as
>opposed to rational approximations to real numbers) on a computer.
There is. And there's even some theory behind it :-)
Regards,
Nick Maclaren.
Robert Myers <rbmye...@gmail.com> wrote:
>
>For some useful continued fractions, a rule would suffice for forward
>computation of as many terms of the fraction as you might desire. You
>may, in some cases of interest, be able to do computation by
>manipulating the rules, rather than by manipulating the continued
>fraction itself. In some cases a finite continued fraction
>representation of a real number might offer advantages over a rational
>approximation, but that is not what I am proposing. I am proposing
>manipulating the continued fraction as you would infinite series--where
>it is possible to do so, as in the case of exp (i * theta) = cos (theta)
>+ i sin (theta).
Yes. And that is what I responded to, in the following.
>
>For some useful continued fractions, a rule would suffice for forward
>computation of as many terms of the fraction as you might desire. You
>may, in some cases of interest, be able to do computation by
>manipulating the rules, rather than by manipulating the continued
>fraction itself. In some cases a finite continued fraction
>representation of a real number might offer advantages over a rational
>approximation, but that is not what I am proposing. I am proposing
>manipulating the continued fraction as you would infinite series--where
>it is possible to do so, as in the case of exp (i * theta) = cos (theta)
>+ i sin (theta).
>I wasn't proposing anything that I thought actually *useful* in any
>general sense. Are denormals useful in any general sense? ;-)
>Even though it has clearly occurred to others before, it had not
>occurred to me that there was any way to manipulate real numbers (as
>opposed to rational approximations to real numbers) on a computer.
Regards,
Nick Maclaren.
Torben Ægidius Mogensen
Jan 12, 2012, 5:36:42 AM1/12/12
to
Robert Myers <rbmye...@gmail.com> writes:
> Would anyone care to speculate on the possibility of using
> (recursively computable) continued fractions to do arithmetic with
> actual real numbers, as opposed to rational approximations to real
> numbers?
Arbitrary-precision computable reals have been done with continued
> Would anyone care to speculate on the possibility of using
> (recursively computable) continued fractions to do arithmetic with
> actual real numbers, as opposed to rational approximations to real
> numbers?
fractions that are expanded on demand. I can't offhand see any strong
advantage to using these over a lazy sequence of digits/bits. While
some numbers can be represented exactly in finite space using continued
fractions but not using digit sequences, there are still a lot of
numbers that can't. And calculations using continued fractions are much
more complicated than calculation using digit sequences. It would, IMO,
make more sense to use digit sequences that explicitly mark repetition.
In any case, computing with arbitray precision takes a lot of time and
space, as even if you only want 100 digits of precision in the final
result, you might need thousands of digits in the intermediate results.
Torben
nm...@cam.ac.uk
Jan 12, 2012, 5:41:33 AM1/12/12
to
In article <7zaa5t1...@ask.diku.dk>,
digit sequences are 'simpler' is cultural and not mathematical.
Note that I am not claiming the converse is true mathematically
or computationally, but only that the tradeoff is unclear.
>In any case, computing with arbitray precision takes a lot of time and
>space, as even if you only want 100 digits of precision in the final
>result, you might need thousands of digits in the intermediate results.
If you are lucky! If unlucky, you might need an exponentially
greater number.
Regards,
Nick Maclaren.
Torben Ægidius Mogensen <tor...@diku.dk> wrote:
>
>Arbitrary-precision computable reals have been done with continued
>fractions that are expanded on demand. I can't offhand see any strong
>advantage to using these over a lazy sequence of digits/bits. While
>some numbers can be represented exactly in finite space using continued
>fractions but not using digit sequences, there are still a lot of
>numbers that can't. And calculations using continued fractions are much
>more complicated than calculation using digit sequences. It would, IMO,
>make more sense to use digit sequences that explicitly mark repetition.
The last two sentences are extremely dubious. The main reason that
>
>Arbitrary-precision computable reals have been done with continued
>fractions that are expanded on demand. I can't offhand see any strong
>advantage to using these over a lazy sequence of digits/bits. While
>some numbers can be represented exactly in finite space using continued
>fractions but not using digit sequences, there are still a lot of
>numbers that can't. And calculations using continued fractions are much
>more complicated than calculation using digit sequences. It would, IMO,
>make more sense to use digit sequences that explicitly mark repetition.
digit sequences are 'simpler' is cultural and not mathematical.
Note that I am not claiming the converse is true mathematically
or computationally, but only that the tradeoff is unclear.
>In any case, computing with arbitray precision takes a lot of time and
>space, as even if you only want 100 digits of precision in the final
>result, you might need thousands of digits in the intermediate results.
greater number.
Regards,
Nick Maclaren.
Terje Mathisen
Jan 12, 2012, 7:51:57 AM1/12/12
to
nm...@cam.ac.uk wrote:
> In article<7zaa5t1...@ask.diku.dk>,
not with the number system.
There are probably useful functions that simply cannot be evaluated
without using severely misbehaved algorithms (typically involving
differences of nearly identical values), but many/most of them can be
converted to different forms which behave better.
I.e. how do you calculate how high up you need to be in order to see the
horizon X kilometers away?
It is easy to come up with an expression which involves
(1 - cos(phi)) // with phi _very_ small
but you can do the math in your head if you convert it a better form first.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
> In article<7zaa5t1...@ask.diku.dk>,
>> In any case, computing with arbitray precision takes a lot of time and
>> space, as even if you only want 100 digits of precision in the final
>> result, you might need thousands of digits in the intermediate results.
>
> If you are lucky! If unlucky, you might need an exponentially
> greater number.
I'd say that in both these cases the problem lies with your algorithm,
>> space, as even if you only want 100 digits of precision in the final
>> result, you might need thousands of digits in the intermediate results.
>
> If you are lucky! If unlucky, you might need an exponentially
> greater number.
not with the number system.
There are probably useful functions that simply cannot be evaluated
without using severely misbehaved algorithms (typically involving
differences of nearly identical values), but many/most of them can be
converted to different forms which behave better.
I.e. how do you calculate how high up you need to be in order to see the
horizon X kilometers away?
It is easy to come up with an expression which involves
(1 - cos(phi)) // with phi _very_ small
but you can do the math in your head if you convert it a better form first.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
nm...@cam.ac.uk
Jan 12, 2012, 8:22:09 AM1/12/12
to
In article <ek13u8-...@ntp6.tmsw.no>,
misleading except for simple functions. For almost all complete
problems, both such classes are swamped by the class of ones for
which there is no known algorithm with a known, moderate bound on
its error. It doesn't matter whether you know that there is a
good algorithm out there, if you have no way of finding it! And,
in the vast majority of cases, you don't know whether such an
algorithm even exists.
In a lot of cases, you probably can get away with a much smaller
accuracy in the intermediate results, but can you prove that,
even post hoc?
Regards,
Nick Maclaren.
Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>
>>> In any case, computing with arbitray precision takes a lot of time and
>>> space, as even if you only want 100 digits of precision in the final
>>> result, you might need thousands of digits in the intermediate results.
>>
>> If you are lucky! If unlucky, you might need an exponentially
>> greater number.
>
>I'd say that in both these cases the problem lies with your algorithm,
>not with the number system.
>
>There are probably useful functions that simply cannot be evaluated
>without using severely misbehaved algorithms (typically involving
>differences of nearly identical values), but many/most of them can be
>converted to different forms which behave better.
Oh, really, Terje! While that statement is true, it is SERIOUSLY
>
>>> In any case, computing with arbitray precision takes a lot of time and
>>> space, as even if you only want 100 digits of precision in the final
>>> result, you might need thousands of digits in the intermediate results.
>>
>> If you are lucky! If unlucky, you might need an exponentially
>> greater number.
>
>I'd say that in both these cases the problem lies with your algorithm,
>not with the number system.
>
>There are probably useful functions that simply cannot be evaluated
>without using severely misbehaved algorithms (typically involving
>differences of nearly identical values), but many/most of them can be
>converted to different forms which behave better.
misleading except for simple functions. For almost all complete
problems, both such classes are swamped by the class of ones for
which there is no known algorithm with a known, moderate bound on
its error. It doesn't matter whether you know that there is a
good algorithm out there, if you have no way of finding it! And,
in the vast majority of cases, you don't know whether such an
algorithm even exists.
In a lot of cases, you probably can get away with a much smaller
accuracy in the intermediate results, but can you prove that,
even post hoc?
Regards,
Nick Maclaren.
Terje Mathisen
Jan 12, 2012, 9:01:19 AM1/12/12
to
nm...@cam.ac.uk wrote:
> In article<ek13u8-...@ntp6.tmsw.no>,
> Terje Mathisen<"terje.mathisen at tmsw.no"> wrote:
>>
>>>> In any case, computing with arbitray precision takes a lot of time and
>>>> space, as even if you only want 100 digits of precision in the final
>>>> result, you might need thousands of digits in the intermediate results.
>>>
>>> If you are lucky! If unlucky, you might need an exponentially
>>> greater number.
>>
>> I'd say that in both these cases the problem lies with your algorithm,
>> not with the number system.
>>
>> There are probably useful functions that simply cannot be evaluated
>> without using severely misbehaved algorithms (typically involving
>> differences of nearly identical values), but many/most of them can be
>> converted to different forms which behave better.
>
> Oh, really, Terje! While that statement is true, it is SERIOUSLY
> misleading except for simple functions. For almost all complete
> problems, both such classes are swamped by the class of ones for
> which there is no known algorithm with a known, moderate bound on
> its error. It doesn't matter whether you know that there is a
> good algorithm out there, if you have no way of finding it! And,
> in the vast majority of cases, you don't know whether such an
> algorithm even exists.
Your experience is different from mine, possibly because I don't even
> In article<ek13u8-...@ntp6.tmsw.no>,
> Terje Mathisen<"terje.mathisen at tmsw.no"> wrote:
>>
>>>> In any case, computing with arbitray precision takes a lot of time and
>>>> space, as even if you only want 100 digits of precision in the final
>>>> result, you might need thousands of digits in the intermediate results.
>>>
>>> If you are lucky! If unlucky, you might need an exponentially
>>> greater number.
>>
>> I'd say that in both these cases the problem lies with your algorithm,
>> not with the number system.
>>
>> There are probably useful functions that simply cannot be evaluated
>> without using severely misbehaved algorithms (typically involving
>> differences of nearly identical values), but many/most of them can be
>> converted to different forms which behave better.
>
> Oh, really, Terje! While that statement is true, it is SERIOUSLY
> misleading except for simple functions. For almost all complete
> problems, both such classes are swamped by the class of ones for
> which there is no known algorithm with a known, moderate bound on
> its error. It doesn't matter whether you know that there is a
> good algorithm out there, if you have no way of finding it! And,
> in the vast majority of cases, you don't know whether such an
> algorithm even exists.
try to calculate badly behaved functions.
> In a lot of cases, you probably can get away with a much smaller
> accuracy in the intermediate results, but can you prove that,
> even post hoc?
a) Try the calculation with both increased (extended) resolution and
with reduced (take away one or two low end bits) and see what happens.
This helps, but just like you wrote, it is no guarantee.
b) Try with interval arithmetic. The problem is of course that even
extremely well-behaved algorithm can show that the final confidence
interval is -Inf to Inf.
:-(
James Van Buskirk
Jan 12, 2012, 11:43:22 AM1/12/12
to
<nm...@cam.ac.uk> wrote in message news:jemdct$u85$1...@gosset.csi.cam.ac.uk...
> In article <7zaa5t1...@ask.diku.dk>,
> Torben Ægidius Mogensen <tor...@diku.dk> wrote:
>>Arbitrary-precision computable reals have been done with continued
>>fractions that are expanded on demand. I can't offhand see any strong
>>advantage to using these over a lazy sequence of digits/bits. While
>>some numbers can be represented exactly in finite space using continued
>>fractions but not using digit sequences, there are still a lot of
>>numbers that can't. And calculations using continued fractions are much
>>more complicated than calculation using digit sequences. It would, IMO,
>>make more sense to use digit sequences that explicitly mark repetition.
> The last two sentences are extremely dubious. The main reason that
> digit sequences are 'simpler' is cultural and not mathematical.
> Note that I am not claiming the converse is true mathematically
> or computationally, but only that the tradeoff is unclear.
For representing an approximation to a real number, writing out a
convergent to a continued fraction takes about the same number of
digits as writing out the 'decimal expansion' in some base, but
when you do any arithmetic on numbers represented like this the
number of digits doubles at every step unless an intermediate
recalculation of a new convergent is undertaken. See
http://groups.google.com/group/sci.math/msg/6cebced1fb69b0a2?hl=en
for an example of this. The 'decimal expansion' with its
implicit denominator doesn't require this step so it seems to
me that there is a mathematical reason for it being preferred
in our culture.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
> In article <7zaa5t1...@ask.diku.dk>,
> Torben Ægidius Mogensen <tor...@diku.dk> wrote:
>>Arbitrary-precision computable reals have been done with continued
>>fractions that are expanded on demand. I can't offhand see any strong
>>advantage to using these over a lazy sequence of digits/bits. While
>>some numbers can be represented exactly in finite space using continued
>>fractions but not using digit sequences, there are still a lot of
>>numbers that can't. And calculations using continued fractions are much
>>more complicated than calculation using digit sequences. It would, IMO,
>>make more sense to use digit sequences that explicitly mark repetition.
> The last two sentences are extremely dubious. The main reason that
> digit sequences are 'simpler' is cultural and not mathematical.
> Note that I am not claiming the converse is true mathematically
> or computationally, but only that the tradeoff is unclear.
convergent to a continued fraction takes about the same number of
digits as writing out the 'decimal expansion' in some base, but
when you do any arithmetic on numbers represented like this the
number of digits doubles at every step unless an intermediate
recalculation of a new convergent is undertaken. See
http://groups.google.com/group/sci.math/msg/6cebced1fb69b0a2?hl=en
for an example of this. The 'decimal expansion' with its
implicit denominator doesn't require this step so it seems to
me that there is a mathematical reason for it being preferred
in our culture.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Andy (Super) Glew
Jan 12, 2012, 12:20:30 PM1/12/12
to
On 1/12/2012 12:48 AM, nm...@cam.ac.uk wrote:
> In article<YplPq.73747$ed2....@newsfe05.iad>,
> Robert Myers<rbmye...@gmail.com> wrote:
>>
>> For some useful continued fractions, a rule would suffice for forward
>> computation of as many terms of the fraction as you might desire. You
>> may, in some cases of interest, be able to do computation by
>> manipulating the rules, rather than by manipulating the continued
>> fraction itself. In some cases a finite continued fraction
>> representation of a real number might offer advantages over a rational
>> approximation, but that is not what I am proposing. I am proposing
>> manipulating the continued fraction as you would infinite series--where
>> it is possible to do so, as in the case of exp (i * theta) = cos (theta)
>> + i sin (theta).
>
> Yes. And that is what I responded to, in the following.
>
>> I wasn't proposing anything that I thought actually *useful* in any
>> general sense. Are denormals useful in any general sense? ;-)
>
> Kahan and his followers think so; others don't. It's moot.
ISO examples of computations where using denormals leads in incorrect
> In article<YplPq.73747$ed2....@newsfe05.iad>,
> Robert Myers<rbmye...@gmail.com> wrote:
>>
>> For some useful continued fractions, a rule would suffice for forward
>> computation of as many terms of the fraction as you might desire. You
>> may, in some cases of interest, be able to do computation by
>> manipulating the rules, rather than by manipulating the continued
>> fraction itself. In some cases a finite continued fraction
>> representation of a real number might offer advantages over a rational
>> approximation, but that is not what I am proposing. I am proposing
>> manipulating the continued fraction as you would infinite series--where
>> it is possible to do so, as in the case of exp (i * theta) = cos (theta)
>> + i sin (theta).
>
> Yes. And that is what I responded to, in the following.
>
>> I wasn't proposing anything that I thought actually *useful* in any
>> general sense. Are denormals useful in any general sense? ;-)
>
> Kahan and his followers think so; others don't. It's moot.
results, compared to using normalized floating point.
Also compared to doing the same calculations in infinite precision.
I.e. I am sure that one can always find a code that has been tweaked to
run correctly in any given representation.
nm...@cam.ac.uk
Jan 12, 2012, 12:20:53 PM1/12/12
to
In article <jen2jb$qi4$1...@dont-email.me>,
properties are such that convergents or rationals can be done
efficiently but where decimal expansion ones cannot. That is
fairly common in probability calculations, for example. I am
certainly not arguing that there aren't cases where decimal
expansion isn't better, but merely that it's not clear whether
that maps to an overall gain.
Regards,
Nick Maclaren.
James Van Buskirk <not_...@comcast.net> wrote:
>
>>>Arbitrary-precision computable reals have been done with continued
>>>fractions that are expanded on demand. I can't offhand see any strong
>>>advantage to using these over a lazy sequence of digits/bits. While
>>>some numbers can be represented exactly in finite space using continued
>>>fractions but not using digit sequences, there are still a lot of
>>>numbers that can't. And calculations using continued fractions are much
>>>more complicated than calculation using digit sequences. It would, IMO,
>>>make more sense to use digit sequences that explicitly mark repetition.
>
>> The last two sentences are extremely dubious. The main reason that
>> digit sequences are 'simpler' is cultural and not mathematical.
>> Note that I am not claiming the converse is true mathematically
>> or computationally, but only that the tradeoff is unclear.
>
>For representing an approximation to a real number, writing out a
>convergent to a continued fraction takes about the same number of
>digits as writing out the 'decimal expansion' in some base, but
>when you do any arithmetic on numbers represented like this the
>number of digits doubles at every step unless an intermediate
>recalculation of a new convergent is undertaken. See
>
>http://groups.google.com/group/sci.math/msg/6cebced1fb69b0a2?hl=en
>
>for an example of this. The 'decimal expansion' with its
>implicit denominator doesn't require this step so it seems to
>me that there is a mathematical reason for it being preferred
>in our culture.
There are also quite a lot of calculations where the cancellation
>
>>>Arbitrary-precision computable reals have been done with continued
>>>fractions that are expanded on demand. I can't offhand see any strong
>>>advantage to using these over a lazy sequence of digits/bits. While
>>>some numbers can be represented exactly in finite space using continued
>>>fractions but not using digit sequences, there are still a lot of
>>>numbers that can't. And calculations using continued fractions are much
>>>more complicated than calculation using digit sequences. It would, IMO,
>>>make more sense to use digit sequences that explicitly mark repetition.
>
>> The last two sentences are extremely dubious. The main reason that
>> digit sequences are 'simpler' is cultural and not mathematical.
>> Note that I am not claiming the converse is true mathematically
>> or computationally, but only that the tradeoff is unclear.
>
>For representing an approximation to a real number, writing out a
>convergent to a continued fraction takes about the same number of
>digits as writing out the 'decimal expansion' in some base, but
>when you do any arithmetic on numbers represented like this the
>number of digits doubles at every step unless an intermediate
>recalculation of a new convergent is undertaken. See
>
>http://groups.google.com/group/sci.math/msg/6cebced1fb69b0a2?hl=en
>
>for an example of this. The 'decimal expansion' with its
>implicit denominator doesn't require this step so it seems to
>me that there is a mathematical reason for it being preferred
>in our culture.
properties are such that convergents or rationals can be done
efficiently but where decimal expansion ones cannot. That is
fairly common in probability calculations, for example. I am
certainly not arguing that there aren't cases where decimal
expansion isn't better, but merely that it's not clear whether
that maps to an overall gain.
Regards,
Nick Maclaren.
nm...@cam.ac.uk
Jan 12, 2012, 12:50:29 PM1/12/12
to
In article <4F0F165E...@SPAM.comp-arch.net>,
denormalised numbers preserve some mathematical properties
that you lose without them. And those claims are (a) correct
and (b) relevant to practical analysis and validation. On
the other hand, there are some properties that normalised
numbers preserve that are broken by denormalised ones.
So he (and I) am talking at a more rigorous level than mere
code. I disagree with him, and feel that the balance comes
down marginally in favour of NOT having denormalised numbers,
but he may well be right and I wrong. He is, after all,
vastly more eminent :-)
Of course, your last sentence remains true, no matter HOW
perverse the representation (Nick's exception-free Java, for
example)!
Regards,
Nick Maclaren.
Andy (Super) Glew <an...@SPAM.comp-arch.net> wrote:
>>
>>> I wasn't proposing anything that I thought actually *useful* in any
>>> general sense. Are denormals useful in any general sense? ;-)
>>
>> Kahan and his followers think so; others don't. It's moot.
>
>ISO examples of computations where using denormals leads in incorrect
>results, compared to using normalized floating point.
>
>Also compared to doing the same calculations in infinite precision.
>
>I.e. I am sure that one can always find a code that has been tweaked to
>run correctly in any given representation.
Let's be fair, here. His opinion is based on the fact that
>>
>>> I wasn't proposing anything that I thought actually *useful* in any
>>> general sense. Are denormals useful in any general sense? ;-)
>>
>> Kahan and his followers think so; others don't. It's moot.
>
>ISO examples of computations where using denormals leads in incorrect
>results, compared to using normalized floating point.
>
>Also compared to doing the same calculations in infinite precision.
>
>I.e. I am sure that one can always find a code that has been tweaked to
>run correctly in any given representation.
denormalised numbers preserve some mathematical properties
that you lose without them. And those claims are (a) correct
and (b) relevant to practical analysis and validation. On
the other hand, there are some properties that normalised
numbers preserve that are broken by denormalised ones.
So he (and I) am talking at a more rigorous level than mere
code. I disagree with him, and feel that the balance comes
down marginally in favour of NOT having denormalised numbers,
but he may well be right and I wrong. He is, after all,
vastly more eminent :-)
Of course, your last sentence remains true, no matter HOW
perverse the representation (Nick's exception-free Java, for
example)!
Regards,
Nick Maclaren.
Quadibloc
Jan 12, 2012, 3:56:21 PM1/12/12
to
On Jan 10, 7:28 pm, Robert Myers <rbmyers...@gmail.com> wrote:
> Would anyone care to speculate on the possibility of using (recursively
> computable) continued fractions to do arithmetic with actual real
> numbers, as opposed to rational approximations to real numbers?
Obviously, you couldn't represent _all_ real numbers that way. But you
> Would anyone care to speculate on the possibility of using (recursively
> computable) continued fractions to do arithmetic with actual real
> numbers, as opposed to rational approximations to real numbers?
could represent some of them. Which ones?
Ah. That says that this is useful for the kinds of problems which
people already solve using symbolic algebra programs.
John Savard
Joe keane
Jan 12, 2012, 5:27:00 PM1/12/12
to
In article <gu6Pq.25710$Uj1....@newsfe20.iad>,
that all the values are rational.
OF course you can use GJE and GMP and get the right answer.
But the intermediate values are humungous, although i thought the end
result must be pretty simple [in fact the end result i cared about is
'yes' or 'no'].
So i came up with a clever [i think] improvement: represent each
rational by four values modulo primes p_j, which are close to the word
size of the machine [which was 2^32, now i would use 2^64].
For each operation there is a one-in-a-billion [billion-billion for new
word size] chance that it would fail due to 'false zero' [that actually
came up a lot and i needed some tricks to defer it].
It was a lot faster.
comp.arch
Robert Myers <rbmye...@gmail.com> wrote:
>Would anyone care to speculate on the possibility of using (recursively
>computable) continued fractions to do arithmetic with actual real
>numbers, as opposed to rational approximations to real numbers?
A while back i had a problem, solve a big matrix equation where we know
>Would anyone care to speculate on the possibility of using (recursively
>computable) continued fractions to do arithmetic with actual real
>numbers, as opposed to rational approximations to real numbers?
that all the values are rational.
OF course you can use GJE and GMP and get the right answer.
But the intermediate values are humungous, although i thought the end
result must be pretty simple [in fact the end result i cared about is
'yes' or 'no'].
So i came up with a clever [i think] improvement: represent each
rational by four values modulo primes p_j, which are close to the word
size of the machine [which was 2^32, now i would use 2^64].
For each operation there is a one-in-a-billion [billion-billion for new
word size] chance that it would fail due to 'false zero' [that actually
came up a lot and i needed some tricks to defer it].
It was a lot faster.
comp.arch
Andreas Eder
Jan 12, 2012, 5:20:40 PM1/12/12
to
Hi Quadibloc,
>>>>> "Quadibloc" == Quadibloc <jsa...@ecn.ab.ca> writes:
Quadibloc> On Jan 10, 7:28 pm, Robert Myers <rbmyers...@gmail.com> wrote:
>> Would anyone care to speculate on the possibility of using (recursively
>> computable) continued fractions to do arithmetic with actual real
>> numbers, as opposed to rational approximations to real numbers?
Quadibloc> Obviously, you couldn't represent _all_ real numbers that way. But you
Quadibloc> could represent some of them. Which ones?
All the computable reals, and that is obviously the best you can
expect even though - in a sense - they are a negligable quantitiy.
The computable reals are countable, the reals as we know and love
are uncountable.
'Andreas
--
ceterum censeo redmondinem esse delendam.
>>>>> "Quadibloc" == Quadibloc <jsa...@ecn.ab.ca> writes:
Quadibloc> On Jan 10, 7:28 pm, Robert Myers <rbmyers...@gmail.com> wrote:
>> Would anyone care to speculate on the possibility of using (recursively
>> computable) continued fractions to do arithmetic with actual real
>> numbers, as opposed to rational approximations to real numbers?
Quadibloc> could represent some of them. Which ones?
All the computable reals, and that is obviously the best you can
expect even though - in a sense - they are a negligable quantitiy.
The computable reals are countable, the reals as we know and love
are uncountable.
'Andreas
--
ceterum censeo redmondinem esse delendam.
Robert Myers
Jan 12, 2012, 8:33:39 PM1/12/12
to
that there are varying degrees of transcendence of real numbers, and
that the uncomputable real numbers must be the limits of some set of
sequences or other, but that, long before we have to consider those
limit points, we we will be confronted by numbers whose computability
and/or representability becomes increasingly challenging and even
unmanageable. That is to say that, long before we get to numbers that
are not computable even in theory, we we will reach numbers that are not
computable in practice.
The only way that I can imagine creating a number on a computer that is
not computable is endlessly to query some equivalent of a random number
generator. Thus, I can't imagine that the limitation to computable
numbers has any consequences, but your observation that the set of
computable numbers is countable makes me pause. Is there any
conceivable practical consequence to the inability to manipulate numbers
that are not computable?
Robert.
Mark Thorson
Jan 12, 2012, 11:07:21 PM1/12/12
to
nm...@cam.ac.uk wrote:
>
> Let's be fair, here. His opinion is based on the fact that
> denormalised numbers preserve some mathematical properties
> that you lose without them. And those claims are (a) correct
> and (b) relevant to practical analysis and validation. On
> the other hand, there are some properties that normalised
> numbers preserve that are broken by denormalised ones.
>
> So he (and I) am talking at a more rigorous level than mere
> code. I disagree with him, and feel that the balance comes
> down marginally in favour of NOT having denormalised numbers,
> but he may well be right and I wrong. He is, after all,
> vastly more eminent :-)
I thought denorms were to prevent the sudden discontinuity
>
> Let's be fair, here. His opinion is based on the fact that
> denormalised numbers preserve some mathematical properties
> that you lose without them. And those claims are (a) correct
> and (b) relevant to practical analysis and validation. On
> the other hand, there are some properties that normalised
> numbers preserve that are broken by denormalised ones.
>
> So he (and I) am talking at a more rigorous level than mere
> code. I disagree with him, and feel that the balance comes
> down marginally in favour of NOT having denormalised numbers,
> but he may well be right and I wrong. He is, after all,
> vastly more eminent :-)
when you overflow the number range, sort of like the way
high-end vacuum tube audio equipment would gracefully
handle overdriving. Unlike early transistorized equipment,
tubes would distort rather than clip when overdriven, and
you could hear the clipping, giving rise to a prejudice
against solid-state equipment among audiophiles that lasted
many years.
jacko
Jan 12, 2012, 11:48:28 PM1/12/12
to
All representable reals, even the ones of infinite length can be generated by an algorithm and are thus countable. Just because you believe a false proof of some concept of a complete set and then are able to generate another set member, does not mean the the set is never countably complete, it does however mean you have found a generator of the set, so implying the idea to consider it complete to be bullshit of the reducto absurdum kind. NOT RED does not have to be GREEN.
Don't be a pre Godelian idiot.
Don't be a pre Godelian idiot.
EricP
Jan 13, 2012, 1:30:15 AM1/13/12
to
jacko wrote:
>
> Don't be a pre Godelian idiot.
I nominate this as the "standard dismissive retort" for 2012.
>
> Don't be a pre Godelian idiot.
It shall henceforth replace Nick's "sigh..."
Eric
Andreas Eder
Jan 13, 2012, 1:08:57 AM1/13/12
to
Hi Robert,
>>>>> "Robert" == Robert Myers <rbmye...@gmail.com> writes:
Robert> The only way that I can imagine creating a number on a computer that
Robert> is not computable is endlessly to query some equivalent of a random
Robert> number generator. Thus, I can't imagine that the limitation to
Robert> computable numbers has any consequences, but your observation that the
Robert> set of computable numbers is countable makes me pause. Is there any
Robert> conceivable practical consequence to the inability to manipulate
Robert> numbers that are not computable?
you can not create a non-computable number on a computer, because
it *is* not computable. So if you are going to compute with
numbers, you will always have to contend with the computable ones.
The consequences are more philosophical: about almost all real
numbers, we can not even talk as individuals, because to identify
one you have to find a qay to constructively specify it, which
means it is computable.
>>>>> "Robert" == Robert Myers <rbmye...@gmail.com> writes:
Robert> The only way that I can imagine creating a number on a computer that
Robert> is not computable is endlessly to query some equivalent of a random
Robert> number generator. Thus, I can't imagine that the limitation to
Robert> computable numbers has any consequences, but your observation that the
Robert> set of computable numbers is countable makes me pause. Is there any
Robert> conceivable practical consequence to the inability to manipulate
Robert> numbers that are not computable?
you can not create a non-computable number on a computer, because
it *is* not computable. So if you are going to compute with
numbers, you will always have to contend with the computable ones.
The consequences are more philosophical: about almost all real
numbers, we can not even talk as individuals, because to identify
one you have to find a qay to constructively specify it, which
means it is computable.
Andy (Super) Glew
Jan 13, 2012, 2:47:49 AM1/13/12
to
I am wondering if there are any examples where denormals hurt correctness.
I have heard many arguments of the form
* you don't need denormals to be correct - it's not that hard to code
with unorms
* denorms provide a false sense of security - here's an example that
fails with both unormas and denorms
* denorms cost hardware
But I can't recall seeing many examples where denorms produced incorrect
results while unnorms do not.
If this is so - well, if the choice is spending hardware versus getting
more correct code, even if its is naive correct code, well, I think the
trend is towards spending the hardware. Perhaps not in a super number
cruncher coded up by numerical analysts - but possibly for DOE nuclear
bomb simulation codes.
nm...@cam.ac.uk
Jan 13, 2012, 4:12:32 AM1/13/12
to
In article <tSLPq.80836$cN1....@newsfe12.iad>,
can be described only in terms of such - but, because we poor
humans are subject to the Turing/Goedel limitation, we can only
speculate about their existence and would not be able to identify
them :=)
From that you will gather that I am not a Penrosian ....
Anway, in the words of Monty Python, this is getting silly, so
I shall stop.
Regards,
Nick Maclaren.
Robert Myers <rbmye...@gmail.com> wrote:
>
>The only way that I can imagine creating a number on a computer that is
>not computable is endlessly to query some equivalent of a random number
>generator. Thus, I can't imagine that the limitation to computable
>numbers has any consequences, but your observation that the set of
>computable numbers is countable makes me pause. Is there any
>conceivable practical consequence to the inability to manipulate numbers
>that are not computable?
Yes. It is possible that there are some physical processes that
>
>The only way that I can imagine creating a number on a computer that is
>not computable is endlessly to query some equivalent of a random number
>generator. Thus, I can't imagine that the limitation to computable
>numbers has any consequences, but your observation that the set of
>computable numbers is countable makes me pause. Is there any
>conceivable practical consequence to the inability to manipulate numbers
>that are not computable?
can be described only in terms of such - but, because we poor
humans are subject to the Turing/Goedel limitation, we can only
speculate about their existence and would not be able to identify
them :=)
From that you will gather that I am not a Penrosian ....
Anway, in the words of Monty Python, this is getting silly, so
I shall stop.
Regards,
Nick Maclaren.
nm...@cam.ac.uk
Jan 13, 2012, 4:23:19 AM1/13/12
to
In article <4F0FADF8...@sonic.net>,
It's often described that way, but that's more for simplicity
than rigour. With denormals, if A > B, then A-B > 0, which is
obviously needed with code like IF a > b THEN c = 1.0/(a-b) FI.
However, it ALSO means that, if A > 0 and B > 1, A/B < A is
no longer reliable, which is bad news for some iterative solvers.
Overall, I agree with him that denormals preserve more (and
more common) invariants than not having them does, but I don't
agree that is the correct measure of importance. I believe
that, overall, small number detection and analysis is simpler
without them - but, as I said, it's moot.
Regards,
Nick Maclaren.
than rigour. With denormals, if A > B, then A-B > 0, which is
obviously needed with code like IF a > b THEN c = 1.0/(a-b) FI.
However, it ALSO means that, if A > 0 and B > 1, A/B < A is
no longer reliable, which is bad news for some iterative solvers.
Overall, I agree with him that denormals preserve more (and
more common) invariants than not having them does, but I don't
agree that is the correct measure of importance. I believe
that, overall, small number detection and analysis is simpler
without them - but, as I said, it's moot.
Regards,
Nick Maclaren.
nm...@cam.ac.uk
Jan 13, 2012, 4:33:11 AM1/13/12
to
In article <4F0FE1A5...@SPAM.comp-arch.net>,
>I have heard many arguments of the form
>
>* you don't need denormals to be correct - it's not that hard to code
>with unorms
>
>* denorms provide a false sense of security - here's an example that
>fails with both unormas and denorms
>
>* denorms cost hardware
>
>But I can't recall seeing many examples where denorms produced incorrect
>results while unnorms do not.
No, and I explain why below.
>If this is so - well, if the choice is spending hardware versus getting
>more correct code, even if its is naive correct code, well, I think the
>trend is towards spending the hardware. Perhaps not in a super number
>cruncher coded up by numerical analysts - but possibly for DOE nuclear
>bomb simulation codes.
What you say is the 'official' line, but I believe that the
majority of the causality goes the other way! Because almost
all programs written numerically naively have been for machines
with denorms for quite a long time, few people see the problems
in real code. I have seen both classes of failure in real codes,
but I have an unusually wide experience.
I think that it is probably correct that denorms remove more gotchas
than they introduce, but they ALSO make writing robust code (i.e.
code that handles generalised underflow numerically well) quite a
lot harder.
Regards,
Nick Maclaren.
Andy (Super) Glew <an...@SPAM.comp-arch.net> wrote:
>
>Kahan et al have shown many examples where denormals help correctness.
>
>I am wondering if there are any examples where denormals hurt correctness.
Yes, there are - see my response to Mark Thorson.
>
>Kahan et al have shown many examples where denormals help correctness.
>
>I am wondering if there are any examples where denormals hurt correctness.
>I have heard many arguments of the form
>
>* you don't need denormals to be correct - it's not that hard to code
>with unorms
>
>* denorms provide a false sense of security - here's an example that
>fails with both unormas and denorms
>
>* denorms cost hardware
>
>But I can't recall seeing many examples where denorms produced incorrect
>results while unnorms do not.
>If this is so - well, if the choice is spending hardware versus getting
>more correct code, even if its is naive correct code, well, I think the
>trend is towards spending the hardware. Perhaps not in a super number
>cruncher coded up by numerical analysts - but possibly for DOE nuclear
>bomb simulation codes.
majority of the causality goes the other way! Because almost
all programs written numerically naively have been for machines
with denorms for quite a long time, few people see the problems
in real code. I have seen both classes of failure in real codes,
but I have an unusually wide experience.
I think that it is probably correct that denorms remove more gotchas
than they introduce, but they ALSO make writing robust code (i.e.
code that handles generalised underflow numerically well) quite a
lot harder.
Regards,
Nick Maclaren.
Andy (Super) Glew
Jan 13, 2012, 12:59:28 PM1/13/12
to
if A> 0 and B> 1, A/B< A is no longer reliable
In a subsequent post you say
>I think that it is probably correct that denorms remove more gotchas
>than they introduce, but they ALSO make writing robust code (i.e.
>code that handles generalised underflow numerically well) quite a
>lot harder.
This would be an argument for having both denorm and flush to zero mode.
>than they introduce, but they ALSO make writing robust code (i.e.
>code that handles generalised underflow numerically well) quite a
>lot harder.
Which is common when denorm handling ios slow and flush to zero is
faster. But if you make denorm handling fast, as is increasingly
common, nobody wants the additional complexity of supporting FTZ.
Terje Mathisen
Jan 13, 2012, 1:14:24 PM1/13/12
to
Andy (Super) Glew wrote:
> Can you provide an example of
>
> if A> 0 and B> 1, A/B< A is no longer reliable
>
> ?
That seems obvious:
> Can you provide an example of
>
> if A> 0 and B> 1, A/B< A is no longer reliable
>
> ?
float A = 1/4 of lowest normalized number, i.e. a 18-bit mantissa.
B = 1.0 + 1 ulp
In this case A/B will always be == A, as long as you have default rounding.
nm...@cam.ac.uk
Jan 13, 2012, 1:29:44 PM1/13/12
to
In article <4F107100...@SPAM.comp-arch.net>,
empirical derivatives, or any of those iterative methods.
They all rely on reducing the range, and one perfectly valid
termination test is when that reaches zero. But denormals
will often break that when the true minimum is AT zero! I have
seen that failure several times, and even fallen into it :-)
Remember that, with round-to-nearest, 0.618*min = min.
Another VERY nasty one is that x*(1-p)+x*p can be very different
from x, with no zero to indicate a problem. I have seen that
cause a multi-dimensional minimiser take a flying leap into the
domain of a physically infeasible attractor and converge to a
completely nonsensical solution.
With both of these, the problems can occur for hard underflow,
too, but denormals can cause code that was properly written for
hard underflow to fail.
>In a subsequent post you say
> >I think that it is probably correct that denorms remove more gotchas
> >than they introduce, but they ALSO make writing robust code (i.e.
> >code that handles generalised underflow numerically well) quite a
> >lot harder.
>
>This would be an argument for having both denorm and flush to zero mode.
Not at all, not if you regard software engineering as being more
important than benchmarketing (as I do). It is a cardinal error
in ANY tool design to make it easier to avoid the simple problems
at the cost of making it harder to avoid the more serious ones.
> Which is common when denorm handling ios slow and flush to zero is
>faster. But if you make denorm handling fast, as is increasingly
>common, nobody wants the additional complexity of supporting FTZ.
Right. But that's not a numerical software engineering argument.
Regards,
Nick Maclaren.
>Can you provide an example of
>
>if A> 0 and B> 1, A/B< A is no longer reliable
>
>?
Eh? Consider a Fibonacci minimiser, an algorithm that uses
>
>if A> 0 and B> 1, A/B< A is no longer reliable
>
>?
empirical derivatives, or any of those iterative methods.
They all rely on reducing the range, and one perfectly valid
termination test is when that reaches zero. But denormals
will often break that when the true minimum is AT zero! I have
seen that failure several times, and even fallen into it :-)
Remember that, with round-to-nearest, 0.618*min = min.
Another VERY nasty one is that x*(1-p)+x*p can be very different
from x, with no zero to indicate a problem. I have seen that
cause a multi-dimensional minimiser take a flying leap into the
domain of a physically infeasible attractor and converge to a
completely nonsensical solution.
With both of these, the problems can occur for hard underflow,
too, but denormals can cause code that was properly written for
hard underflow to fail.
>In a subsequent post you say
> >I think that it is probably correct that denorms remove more gotchas
> >than they introduce, but they ALSO make writing robust code (i.e.
> >code that handles generalised underflow numerically well) quite a
> >lot harder.
>
>This would be an argument for having both denorm and flush to zero mode.
important than benchmarketing (as I do). It is a cardinal error
in ANY tool design to make it easier to avoid the simple problems
at the cost of making it harder to avoid the more serious ones.
> Which is common when denorm handling ios slow and flush to zero is
>faster. But if you make denorm handling fast, as is increasingly
>common, nobody wants the additional complexity of supporting FTZ.
Regards,
Nick Maclaren.
Jason Riedy
Jan 13, 2012, 7:43:55 PM1/13/12
to
And Andy Glew writes:
> This would be an argument for having both denorm and flush to
> zero mode.
The argument against is not mathematical but related to the
> This would be an argument for having both denorm and flush to
> zero mode.
"-fast" option in compilers and the utter lack of knowledge of
how to make code safe against it (or utter lack of funding to
make code safe against it).
For examples where subnormal numbers can cause incorrect results,
look towards contractive processes. If you're contracting
towards X, the behavior is different when X is zero. I can't
come up with a concrete example right now; I'm too out of
practice.
I'm on the side of "if (a != b) z = c/(a-b)". Others aren't.
Evidence supporting the different sides appears anecdotal at
best. The anecdotes supporting subnormals were stronger when
most people used the extremely limited range of single precision
(lose a factor of eight in range). Oh, wait, we're still
there...
--
Jason, also an active Cray XMT user, so I really don't exist...
ken...@cix.compulink.co.uk
Jan 13, 2012, 8:39:00 PM1/13/12
to
In article <tSLPq.80836$cN1....@newsfe12.iad>, rbmye...@gmail.com
digits anything using Pi will give problems. Still in most cases
internal representation only has to be as accurate as the inputs and
there are physical limits on measurement.
Ken Young
(Robert Myers) wrote:
> The only way that I can imagine creating a number on a computer that
> is not computable is endlessly to query some equivalent of a random
> number generator
Or do geometry assuming you mean by computable a finite number of
> The only way that I can imagine creating a number on a computer that
> is not computable is endlessly to query some equivalent of a random
> number generator
digits anything using Pi will give problems. Still in most cases
internal representation only has to be as accurate as the inputs and
there are physical limits on measurement.
Ken Young
Robert Myers
Jan 13, 2012, 10:41:43 PM1/13/12
to
fits, no matter what you do, even without theoretically uncomputable
numbers. That shouldn't stop us from thinking about other ways we might
be doing business.
Robert.
Andreas Eder
Jan 14, 2012, 3:15:00 AM1/14/12
to
Hi kenney,
>>>>> "kenney" == kenney <ken...@cix.compulink.co.uk> writes:
kenney> Or do geometry assuming you mean by computable a finite number of
kenney> digits anything using Pi will give problems.
No, computable is not the same as having a finite number of
digits. That depends on the representation and is essentially just
floating point. Computable number (or real) means the subset of
computable numbers in the reals or complex numbers. The real
thing! And computable in the abstract sense like Turing
>>>>> "kenney" == kenney <ken...@cix.compulink.co.uk> writes:
kenney> Or do geometry assuming you mean by computable a finite number of
kenney> digits anything using Pi will give problems.
No, computable is not the same as having a finite number of
digits. That depends on the representation and is essentially just
floating point. Computable number (or real) means the subset of
computable numbers in the reals or complex numbers. The real
thing! And computable in the abstract sense like Turing
Andy (Super) Glew
Jan 14, 2012, 8:11:38 PM1/14/12
to
On 1/13/2012 10:14 AM, Terje Mathisen wrote:
> Andy (Super) Glew wrote:
>> Can you provide an example of
>>
>> if A> 0 and B> 1, A/B< A is no longer reliable
>>
>> ?
>
> That seems obvious:
>
> float A = 1/4 of lowest normalized number, i.e. a 18-bit mantissa.
>
> B = 1.0 + 1 ulp
>
> In this case A/B will always be == A, as long as you have default rounding.
>
> Terje
Fair enough.
> Andy (Super) Glew wrote:
>> Can you provide an example of
>>
>> if A> 0 and B> 1, A/B< A is no longer reliable
>>
>> ?
>
> That seems obvious:
>
> float A = 1/4 of lowest normalized number, i.e. a 18-bit mantissa.
>
> B = 1.0 + 1 ulp
>
> In this case A/B will always be == A, as long as you have default rounding.
>
> Terje
Now, is this always true in normalized FP?
Terje Mathisen
Jan 15, 2012, 8:14:16 AM1/15/12
to
That's interesting actually:
The case of 1.0 vs (1.0 + 1 ulp) is the maximum relative distance
between two consecutive fp numbers, right?
This means that for any normalized value A, dividing by B will always
result in a new mantissa which is at least 1 ulp smaller!
Robert Myers
Jan 15, 2012, 5:21:24 PM1/15/12
to
On 1/13/2012 4:12 AM, nm...@cam.ac.uk wrote:
> In article<tSLPq.80836$cN1....@newsfe12.iad>,
> Robert Myers<rbmye...@gmail.com> wrote:
>>
>> The only way that I can imagine creating a number on a computer that is
>> not computable is endlessly to query some equivalent of a random number
>> generator. Thus, I can't imagine that the limitation to computable
>> numbers has any consequences, but your observation that the set of
>> computable numbers is countable makes me pause. Is there any
>> conceivable practical consequence to the inability to manipulate numbers
>> that are not computable?
>
> Yes. It is possible that there are some physical processes that
> can be described only in terms of such - but, because we poor
> humans are subject to the Turing/Goedel limitation, we can only
> speculate about their existence and would not be able to identify
> them :=)
Since you regard the discussion as silly, I won't bother to explain why
> In article<tSLPq.80836$cN1....@newsfe12.iad>,
> Robert Myers<rbmye...@gmail.com> wrote:
>>
>> The only way that I can imagine creating a number on a computer that is
>> not computable is endlessly to query some equivalent of a random number
>> generator. Thus, I can't imagine that the limitation to computable
>> numbers has any consequences, but your observation that the set of
>> computable numbers is countable makes me pause. Is there any
>> conceivable practical consequence to the inability to manipulate numbers
>> that are not computable?
>
> Yes. It is possible that there are some physical processes that
> can be described only in terms of such - but, because we poor
> humans are subject to the Turing/Goedel limitation, we can only
> speculate about their existence and would not be able to identify
> them :=)
an unsupported claim that the Turing/Goedel model is an appropriate
model for the brain is silly.
http://en.wikipedia.org/wiki/Clarke's_three_laws
Does the First Law apply? Are you sufficiently distinguished?
Robert.
Mark Thorson
Jan 15, 2012, 8:25:31 PM1/15/12
to
Robert Myers wrote:
>
> On 1/13/2012 4:12 AM, nm...@cam.ac.uk wrote:
> > In article<tSLPq.80836$cN1....@newsfe12.iad>,
> > Robert Myers<rbmye...@gmail.com> wrote:
> >>
> >> The only way that I can imagine creating a number on a computer that is
> >> not computable is endlessly to query some equivalent of a random number
> >> generator. Thus, I can't imagine that the limitation to computable
> >> numbers has any consequences, but your observation that the set of
> >> computable numbers is countable makes me pause. Is there any
> >> conceivable practical consequence to the inability to manipulate numbers
> >> that are not computable?
> >
> > Yes. It is possible that there are some physical processes that
> > can be described only in terms of such - but, because we poor
> > humans are subject to the Turing/Goedel limitation, we can only
> > speculate about their existence and would not be able to identify
> > them :=)
>
> Since you regard the discussion as silly, I won't bother to explain why
> an unsupported claim that the Turing/Goedel model is an appropriate
> model for the brain is silly.
I'd point out he's talking about numbers
>
> On 1/13/2012 4:12 AM, nm...@cam.ac.uk wrote:
> > In article<tSLPq.80836$cN1....@newsfe12.iad>,
> > Robert Myers<rbmye...@gmail.com> wrote:
> >>
> >> The only way that I can imagine creating a number on a computer that is
> >> not computable is endlessly to query some equivalent of a random number
> >> generator. Thus, I can't imagine that the limitation to computable
> >> numbers has any consequences, but your observation that the set of
> >> computable numbers is countable makes me pause. Is there any
> >> conceivable practical consequence to the inability to manipulate numbers
> >> that are not computable?
> >
> > Yes. It is possible that there are some physical processes that
> > can be described only in terms of such - but, because we poor
> > humans are subject to the Turing/Goedel limitation, we can only
> > speculate about their existence and would not be able to identify
> > them :=)
>
> Since you regard the discussion as silly, I won't bother to explain why
> an unsupported claim that the Turing/Goedel model is an appropriate
> model for the brain is silly.
which are not only uncomputable but also
unthinkable. Wow, what an unconcept!
Joe keane
Jan 16, 2012, 10:15:51 AM1/16/12
to
In article <a20bu8-...@ntp6.tmsw.no>,
Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>The case of 1.0 vs (1.0 + 1 ulp) is the maximum relative distance
>between two consecutive fp numbers, right?
>
>This means that for any normalized value A, dividing by B will always
>result in a new mantissa which is at least 1 ulp smaller!
That's easy, how about 1.0 - 0.5*ulp?
>The case of 1.0 vs (1.0 + 1 ulp) is the maximum relative distance
>between two consecutive fp numbers, right?
>
>This means that for any normalized value A, dividing by B will always
>result in a new mantissa which is at least 1 ulp smaller!
Terje Mathisen
Jan 16, 2012, 12:21:33 PM1/16/12
to
relative distance which is ~half the divisor epsilon, so after the
division the (rounded) result will be 1.0 - 1.5 ulp.
I.e. the result is indeed always smaller than the starting value.
jacko
Jan 17, 2012, 9:33:34 PM1/17/12
to
Further logic says the uncountable set just contains the representable countable reals and other exact copies of these reals with indeterminate numbers of trailing zeros on the fractional expansion. In fact a countable infinitude number of copies of a singular real.
But back to reality, and why would the creation make more detail to fill out reality, just because we developed better microscopes? If there is not enough information there, then there is not enough information to fully specify any quantum reality.
Cheers Jacko
But back to reality, and why would the creation make more detail to fill out reality, just because we developed better microscopes? If there is not enough information there, then there is not enough information to fully specify any quantum reality.
Cheers Jacko
Robert Myers
Jan 18, 2012, 3:36:40 PM1/18/12
to
On 1/17/2012 9:33 PM, jacko wrote:
>
> But back to reality, and why would the creation make more detail to fill out reality, just because we developed better microscopes? If there is not enough information there, then there is not enough information to fully specify any quantum reality.
>
The history of mathematics is littered with things that seemed obviously
>
> But back to reality, and why would the creation make more detail to fill out reality, just because we developed better microscopes? If there is not enough information there, then there is not enough information to fully specify any quantum reality.
>
silly but later turned out to be useful or important.
Simply because one cannot make measurements beyond a certain level of
precision is no reason to be solving the equations inexactly. Your
sloppiness in solving the equations may show up as a measurable reality.
It is my tiresome claim that this happens on a nearly daily basis.
There is a real, inescapable difference between piecewise continuous
approximations to differential operators and analytic representations on
finite dimensional function spaces. That's been my mantra for years.
Is there a similarly real, inescapable difference between rational
approximations to reals and operating on representations that are not
limited to the form P/Q, where P and Q are integers? I can't make any
such claim, but I can ask the question. Given the bandwidth given over
here to the arcana of computer arithmetic, I think my question is worth
asking.
Robert.
Terje Mathisen
Jan 18, 2012, 3:58:55 PM1/18/12
to
Robert Myers wrote:
> Is there a similarly real, inescapable difference between rational
> approximations to reals and operating on representations that are not
> limited to the form P/Q, where P and Q are integers? I can't make any
> such claim, but I can ask the question. Given the bandwidth given over
> here to the arcana of computer arithmetic, I think my question is worth
> asking.
It is worth asking.
> Is there a similarly real, inescapable difference between rational
> approximations to reals and operating on representations that are not
> limited to the form P/Q, where P and Q are integers? I can't make any
> such claim, but I can ask the question. Given the bandwidth given over
> here to the arcana of computer arithmetic, I think my question is worth
> asking.
I am willing to go out on a limb and claim that there are _no_ phenomena
which cannot be adequately represented with P/Q (with Q being a power of
two), as long as you allow sufficient bits in P.
I.e. since there is a limited range from the quantum area to the size of
the universe, how many bits do you need to uniquely locate any
sub-atomic particle in the universe? 15e9 light years is around 1.4e26
meters or 1.4e38 picometer.
You need 127 bits to handle this range exactly, so working with 256-bit
fp (I suggest 1:31:224) should give sufficient guard bits to do quite a
bit of computation.
James Van Buskirk
Jan 18, 2012, 5:04:30 PM1/18/12
to
"Terje Mathisen" <"terje.mathisen at tmsw.no"> wrote in message
news:gdoju8-...@ntp6.tmsw.no...
> I.e. since there is a limited range from the quantum area to the size of
> the universe, how many bits do you need to uniquely locate any sub-atomic
> particle in the universe? 15e9 light years is around 1.4e26 meters or
> 1.4e38 picometer.
> You need 127 bits to handle this range exactly, so working with 256-bit fp
> (I suggest 1:31:224) should give sufficient guard bits to do quite a bit
> of computation.
The kind of answer one expects from a non-physicist. For a better
estimate of how many bits you might want, assume that the universe
is something like 1.0e22 solar masses and mostly made of H atoms
at 2.7 K. Then take the energy per particle to be 1.5*k*T and
apply the Sackur-Tetrode equation to get the entropy. Now recall
that S = k*ln(W) and tell how many bits you need to represent W,
the number of quantum states accessible to the universe to the
nearest integer.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
news:gdoju8-...@ntp6.tmsw.no...
> I.e. since there is a limited range from the quantum area to the size of
> the universe, how many bits do you need to uniquely locate any sub-atomic
> particle in the universe? 15e9 light years is around 1.4e26 meters or
> 1.4e38 picometer.
> You need 127 bits to handle this range exactly, so working with 256-bit fp
> (I suggest 1:31:224) should give sufficient guard bits to do quite a bit
> of computation.
estimate of how many bits you might want, assume that the universe
is something like 1.0e22 solar masses and mostly made of H atoms
at 2.7 K. Then take the energy per particle to be 1.5*k*T and
apply the Sackur-Tetrode equation to get the entropy. Now recall
that S = k*ln(W) and tell how many bits you need to represent W,
the number of quantum states accessible to the universe to the
nearest integer.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Tim McCaffrey
Jan 18, 2012, 5:56:34 PM1/18/12
to
In article <jf7fle$asr$1...@dont-email.me>, not_...@comcast.net says...
value (what a time for Wikipedia to be offline :().
Can you just give us a peek at the answer in the back of the book?
The CDC 6600 took about 400 ns to access a work, and 100ns to do math on it.
Loads/stores could be overlapped if they didn't have a bank conflict.
Assuming that the average computation required two loads, one math
operation, and a store, and you wrote an optimized loop, you could probably
get one computation per 300 ns.
Now, how many bits could you have in a bignum and get the same throughput
with today's technology? I *think* you could have a fixed point real that
had the same range as the 6600's floats (2k bits, I think), with more
precision, of course.
- Tim
>
>"Terje Mathisen" <"terje.mathisen at tmsw.no"> wrote in message
>news:gdoju8-...@ntp6.tmsw.no...
>
>> I.e. since there is a limited range from the quantum area to the size of
>> the universe, how many bits do you need to uniquely locate any sub-atomic
>> particle in the universe? 15e9 light years is around 1.4e26 meters or
>> 1.4e38 picometer.
>
>> You need 127 bits to handle this range exactly, so working with 256-bit fp
>> (I suggest 1:31:224) should give sufficient guard bits to do quite a bit
>> of computation.
>
>The kind of answer one expects from a non-physicist. For a better
>estimate of how many bits you might want, assume that the universe
>is something like 1.0e22 solar masses and mostly made of H atoms
>at 2.7 K. Then take the energy per particle to be 1.5*k*T and
>apply the Sackur-Tetrode equation to get the entropy. Now recall
>that S = k*ln(W) and tell how many bits you need to represent W,
>the number of quantum states accessible to the universe to the
>nearest integer.
>
And you can assume that this non-physicist doesn't know how to compute that
>"Terje Mathisen" <"terje.mathisen at tmsw.no"> wrote in message
>news:gdoju8-...@ntp6.tmsw.no...
>
>> I.e. since there is a limited range from the quantum area to the size of
>> the universe, how many bits do you need to uniquely locate any sub-atomic
>> particle in the universe? 15e9 light years is around 1.4e26 meters or
>> 1.4e38 picometer.
>
>> You need 127 bits to handle this range exactly, so working with 256-bit fp
>> (I suggest 1:31:224) should give sufficient guard bits to do quite a bit
>> of computation.
>
>The kind of answer one expects from a non-physicist. For a better
>estimate of how many bits you might want, assume that the universe
>is something like 1.0e22 solar masses and mostly made of H atoms
>at 2.7 K. Then take the energy per particle to be 1.5*k*T and
>apply the Sackur-Tetrode equation to get the entropy. Now recall
>that S = k*ln(W) and tell how many bits you need to represent W,
>the number of quantum states accessible to the universe to the
>nearest integer.
>
value (what a time for Wikipedia to be offline :().
Can you just give us a peek at the answer in the back of the book?
The CDC 6600 took about 400 ns to access a work, and 100ns to do math on it.
Loads/stores could be overlapped if they didn't have a bank conflict.
Assuming that the average computation required two loads, one math
operation, and a store, and you wrote an optimized loop, you could probably
get one computation per 300 ns.
Now, how many bits could you have in a bignum and get the same throughput
with today's technology? I *think* you could have a fixed point real that
had the same range as the 6600's floats (2k bits, I think), with more
precision, of course.
- Tim
Jason Riedy
Jan 18, 2012, 9:58:18 PM1/18/12
to
And James Van Buskirk writes:
> The kind of answer one expects from a non-physicist.
sigh.
> The kind of answer one expects from a non-physicist.
These arguments never die. People do, however. Some who refute
this one quite eloquently have or will.
This becomes depressing quickly. Must we continue the same
arguments even in technical spaces? I know social ones will
continue, but I like to pretend technical ones can make
progress.
--
Jason
EricP
Jan 19, 2012, 1:30:57 AM1/19/12
to
James Van Buskirk wrote:
> "Terje Mathisen" <"terje.mathisen at tmsw.no"> wrote in message
> news:gdoju8-...@ntp6.tmsw.no...
>
>> I.e. since there is a limited range from the quantum area to the size of
>> the universe, how many bits do you need to uniquely locate any sub-atomic
>> particle in the universe? 15e9 light years is around 1.4e26 meters or
>> 1.4e38 picometer.
>
>> You need 127 bits to handle this range exactly, so working with 256-bit fp
>> (I suggest 1:31:224) should give sufficient guard bits to do quite a bit
>> of computation.
>
> The kind of answer one expects from a non-physicist. For a better
> estimate of how many bits you might want, assume that the universe
> is something like 1.0e22 solar masses and mostly made of H atoms
> at 2.7 K. Then take the energy per particle to be 1.5*k*T and
> apply the Sackur-Tetrode equation to get the entropy. Now recall
> that S = k*ln(W) and tell how many bits you need to represent W,
> the number of quantum states accessible to the universe to the
> nearest integer.
>
If we know the energy of the universe and its radius we can
> "Terje Mathisen" <"terje.mathisen at tmsw.no"> wrote in message
> news:gdoju8-...@ntp6.tmsw.no...
>
>> I.e. since there is a limited range from the quantum area to the size of
>> the universe, how many bits do you need to uniquely locate any sub-atomic
>> particle in the universe? 15e9 light years is around 1.4e26 meters or
>> 1.4e38 picometer.
>
>> You need 127 bits to handle this range exactly, so working with 256-bit fp
>> (I suggest 1:31:224) should give sufficient guard bits to do quite a bit
>> of computation.
>
> The kind of answer one expects from a non-physicist. For a better
> estimate of how many bits you might want, assume that the universe
> is something like 1.0e22 solar masses and mostly made of H atoms
> at 2.7 K. Then take the energy per particle to be 1.5*k*T and
> apply the Sackur-Tetrode equation to get the entropy. Now recall
> that S = k*ln(W) and tell how many bits you need to represent W,
> the number of quantum states accessible to the universe to the
> nearest integer.
>
calculate, from black hole information theory, the number of bits:
Bekenstein bound
http://en.wikipedia.org/wiki/Bekenstein_bound
from: The structure of the world from pure numbers (2004)
F J Tipler
"An upper bound to the information content of the universe
can be obtained if we assume all the non-gravitational energy
in the universe is in the form of baryons, assume that the universe
is at the critical density, and ignore the gravitational energy.
Penrose pointed out in 1973 that putting these assumptions into the
Bekenstein Bound, and choosing R to be the radius of the visible
universe (∼10^10 lyrs), one obtains 10^123 bits as the upper bound to
the amount of information in the visible universe at the present time.
A better estimate of the upper bound to the information content of
the universe would have been obtained if just the baryonic content
of the universe, 4% of the critical density, were inserted into the
Bekenstein inequality. This would have given a number some two orders
of magnitude lower than the Penrose Number, but as Penrose himself noted,
it is still much too high. We shall see why in later sections of
this paper.
Two years before Penrose obtained his upper bound to the amount
of information in the visible universe, Carl Friedrich
von Weizsacker argued, independently of Bekenstein and Penrose,
that the universe at the present time had to have an upper bound
to its information content, namely 10^120 bits of informtation"
What is interesting is that the maximum information content
is set by the surface area of the enclosed volume.
The universe may be trying to tell us something important -
we're just not sure what yet (ditto for entangled particles).
Eric
Terje Mathisen
Jan 19, 2012, 2:31:11 AM1/19/12
to
> the amount of information in the visible universe at the present time.
> A better estimate of the upper bound to the information content of
> the universe would have been obtained if just the baryonic content
> of the universe, 4% of the critical density, were inserted into the
> Bekenstein inequality. This would have given a number some two orders
> of magnitude lower than the Penrose Number, but as Penrose himself noted,
> it is still much too high. We shall see why in later sections of
> this paper.
>
> Two years before Penrose obtained his upper bound to the amount
> of information in the visible universe, Carl Friedrich
> von Weizsacker argued, independently of Bekenstein and Penrose,
> that the universe at the present time had to have an upper bound
> to its information content, namely 10^120 bits of informtation"
Thanks, this is the kind of number I was looking for!
> A better estimate of the upper bound to the information content of
> the universe would have been obtained if just the baryonic content
> of the universe, 4% of the critical density, were inserted into the
> Bekenstein inequality. This would have given a number some two orders
> of magnitude lower than the Penrose Number, but as Penrose himself noted,
> it is still much too high. We shall see why in later sections of
> this paper.
>
> Two years before Penrose obtained his upper bound to the amount
> of information in the visible universe, Carl Friedrich
> von Weizsacker argued, independently of Bekenstein and Penrose,
> that the universe at the present time had to have an upper bound
> to its information content, namely 10^120 bits of informtation"
This would then be (within a few orders of magnitude) the amount of
information some god-like entity is currently manipulating in order to
run the emulation we are currently experiencing, right?
> What is interesting is that the maximum information content
> is set by the surface area of the enclosed volume.
>
> The universe may be trying to tell us something important -
> we're just not sure what yet (ditto for entangled particles).
Terje Mathisen
Jan 19, 2012, 2:36:51 AM1/19/12
to
James Van Buskirk wrote:
> "Terje Mathisen"<"terje.mathisen at tmsw.no"> wrote in message
> news:gdoju8-...@ntp6.tmsw.no...
>
>> I.e. since there is a limited range from the quantum area to the size of
>> the universe, how many bits do you need to uniquely locate any sub-atomic
>> particle in the universe? 15e9 light years is around 1.4e26 meters or
>> 1.4e38 picometer.
>
>> You need 127 bits to handle this range exactly, so working with 256-bit fp
>> (I suggest 1:31:224) should give sufficient guard bits to do quite a bit
>> of computation.
>
> The kind of answer one expects from a non-physicist. For a better
That's me indeed James: An MSEE who became interested in computers.
> "Terje Mathisen"<"terje.mathisen at tmsw.no"> wrote in message
> news:gdoju8-...@ntp6.tmsw.no...
>
>> I.e. since there is a limited range from the quantum area to the size of
>> the universe, how many bits do you need to uniquely locate any sub-atomic
>> particle in the universe? 15e9 light years is around 1.4e26 meters or
>> 1.4e38 picometer.
>
>> You need 127 bits to handle this range exactly, so working with 256-bit fp
>> (I suggest 1:31:224) should give sufficient guard bits to do quite a bit
>> of computation.
>
> The kind of answer one expects from a non-physicist. For a better
> estimate of how many bits you might want, assume that the universe
> is something like 1.0e22 solar masses and mostly made of H atoms
> at 2.7 K. Then take the energy per particle to be 1.5*k*T and
> apply the Sackur-Tetrode equation to get the entropy. Now recall
> that S = k*ln(W) and tell how many bits you need to represent W,
> the number of quantum states accessible to the universe to the
> nearest integer.
discrete, not analog, down at the quantum level.
I surely can't be the only c.arch regular who finds this fascinating?
Andy (Super) Glew
Jan 19, 2012, 3:02:00 AM1/19/12
to
On 1/18/2012 12:58 PM, Terje Mathisen wrote:
> Robert Myers wrote:
>> Is there a similarly real, inescapable difference between rational
>> approximations to reals and operating on representations that are not
>> limited to the form P/Q, where P and Q are integers? I can't make any
>> such claim, but I can ask the question. Given the bandwidth given over
>> here to the arcana of computer arithmetic, I think my question is worth
>> asking.
>
> It is worth asking.
>
> I am willing to go out on a limb and claim that there are _no_ phenomena
> which cannot be adequately represented with P/Q (with Q being a power of
> two), as long as you allow sufficient bits in P.
>
> I.e. since there is a limited range from the quantum area to the size of
> the universe, how many bits do you need to uniquely locate any
> sub-atomic particle in the universe? 15e9 light years is around 1.4e26
> meters or 1.4e38 picometer.
Symbolic algebra can solve some problems that FP numerical analyst cannot.
> Robert Myers wrote:
>> Is there a similarly real, inescapable difference between rational
>> approximations to reals and operating on representations that are not
>> limited to the form P/Q, where P and Q are integers? I can't make any
>> such claim, but I can ask the question. Given the bandwidth given over
>> here to the arcana of computer arithmetic, I think my question is worth
>> asking.
>
> It is worth asking.
>
> I am willing to go out on a limb and claim that there are _no_ phenomena
> which cannot be adequately represented with P/Q (with Q being a power of
> two), as long as you allow sufficient bits in P.
>
> I.e. since there is a limited range from the quantum area to the size of
> the universe, how many bits do you need to uniquely locate any
> sub-atomic particle in the universe? 15e9 light years is around 1.4e26
> meters or 1.4e38 picometer.
>
> You need 127 bits to handle this range exactly, so working with 256-bit
> fp (I suggest 1:31:224) should give sufficient guard bits to do quite a
> bit of computation.
Care to add more to
http://semipublic.comp-arch.net/wiki/Floating_Point_Formats
Torben Ægidius Mogensen
Jan 19, 2012, 3:56:29 AM1/19/12
to
you have 100 bit precision for intermediate values, you may lose all
precision in the final result (i.e, even the most significant bit is
wrong). So you can not argue that because you need only X bits in the
final results, 2X (or 10X or 100X) bits is enough for intermediate
values. It all depends on the problem.
Torben
Terje Mathisen
Jan 19, 2012, 7:30:29 AM1/19/12
to
Torben Ćgidius Mogensen wrote:
>> I.e. since there is a limited range from the quantum area to the size
>> of the universe, how many bits do you need to uniquely locate any
>> sub-atomic particle in the universe? 15e9 light years is around 1.4e26
>> meters or 1.4e38 picometer.
>>
>> You need 127 bits to handle this range exactly, so working with
>> 256-bit fp (I suggest 1:31:224) should give sufficient guard bits to
>> do quite a bit of computation.
>
>
> Simulation of chaotic systems is very sensitive to precision. Even if
> you have 100 bit precision for intermediate values, you may lose all
> precision in the final result (i.e, even the most significant bit is
> wrong). So you can not argue that because you need only X bits in the
> final results, 2X (or 10X or 100X) bits is enough for intermediate
> values. It all depends on the problem.
I believe really chaotic systems like that can only ever be modeled in a
>> I.e. since there is a limited range from the quantum area to the size
>> of the universe, how many bits do you need to uniquely locate any
>> sub-atomic particle in the universe? 15e9 light years is around 1.4e26
>> meters or 1.4e38 picometer.
>>
>> You need 127 bits to handle this range exactly, so working with
>> 256-bit fp (I suggest 1:31:224) should give sufficient guard bits to
>> do quite a bit of computation.
>
>
> Simulation of chaotic systems is very sensitive to precision. Even if
> you have 100 bit precision for intermediate values, you may lose all
> precision in the final result (i.e, even the most significant bit is
> wrong). So you can not argue that because you need only X bits in the
> final results, 2X (or 10X or 100X) bits is enough for intermediate
> values. It all depends on the problem.
statistical manner:
First of all, you can never measure the initial state with anything like
100 (or 200 or just 64 bits precision), right?
(One of the most accurate measurements we seem to be doing these days
would be the 300 (?) clock ensemble that defines what UTC is, here we
are working with something like 1e-15 or about 50 bits.)
If you have a model where you can perturb the bottommost bits, past
whatever your measurement precision is, and get wild swings in the final
result, then you have something that you cannot really model directly.
Weather forecasts sort of do this now, resulting in probability
distributions for the most likely weather N days from now.
Robert Myers
Jan 19, 2012, 2:49:59 PM1/19/12
to
On 1/19/2012 7:30 AM, Terje Mathisen wrote:
>
> I believe really chaotic systems like that can only ever be modeled in a
> statistical manner:
>
But the statistics of a system that is limited to a certain class of
>
> I believe really chaotic systems like that can only ever be modeled in a
> statistical manner:
>
numbers may be different from the statistics of a system that is not so
constrained. That's one way of stating why this question seems
interesting to me.
For example, maybe there are closed orbits in artificially discretized
systems that are not closed if the phase space is represented by a less
incomplete set of real numbers (or possibly the other way around).
Robert.
Tim McCaffrey
Jan 19, 2012, 3:21:00 PM1/19/12
to
In article <Mt_Rq.524$yi7...@newsfe23.iad>, rbmye...@gmail.com says...
For years I was trying to come up with a (fairly) compact representation
which was in the form:
(PQ1, PQ2, ... PQn) / (PD1, PD2, ... PDn)
Where PQx & PDx were primes, such that no PQn == PDn (no common divisor) (I
guess it really should be x*Pxx where a prime is needed multiple times).
When you would do a math operation the idea would be to factor out common
primes to limit the size of the result.
It is basically the same thing Robert is proposing, but it may keep the
numbers from exploding all over the place (or it might make it worse). I
guess you could include some mathmatical constants, like pi, e, ln, etc. to
make it *really* interesting to implement.
- Tim
which was in the form:
(PQ1, PQ2, ... PQn) / (PD1, PD2, ... PDn)
Where PQx & PDx were primes, such that no PQn == PDn (no common divisor) (I
guess it really should be x*Pxx where a prime is needed multiple times).
When you would do a math operation the idea would be to factor out common
primes to limit the size of the result.
It is basically the same thing Robert is proposing, but it may keep the
numbers from exploding all over the place (or it might make it worse). I
guess you could include some mathmatical constants, like pi, e, ln, etc. to
make it *really* interesting to implement.
- Tim
mac
Jan 19, 2012, 11:26:48 PM1/19/12
to
> I just started from the interesting point that nature itself seems to be
> discrete, not analog, down at the quantum level.
Measurements may be discrete, but state vectors are complex continuous. And
> discrete, not analog, down at the quantum level.
since they can combine via interference, I don't think it's safe to say
Nature is discrete.
Robert Myers
Jan 19, 2012, 11:34:34 PM1/19/12
to
and sort of wave your hands to go to an infinite-dimensional Hilbert space.
Let me say that a different way. You can do physics on a lattice and,
at the end of the course, mention that, oh, by the way, you can extend
the methods to infinite-dimensional systems.
I know of no corresponding program for teaching real analysis.
Robert.
Terje Mathisen
Jan 20, 2012, 2:55:40 AM1/20/12
to
However, I seem to remember that the current model says that reality is
discrete, i.e. there is a minimum quantum size.
If this is true, and a digital model can work on the same or even
smaller scales, then it is hard to see how such artifacts could turn up?
OTOH, it is probably much more likely that no physical computer would
have enough memory and flops to actually run any interesting model at
this resolution. :-)
Stefan Monnier
Jan 20, 2012, 9:26:12 AM1/20/12
to
> You need 127 bits to handle this range exactly, so working with 256-bit fp
> (I suggest 1:31:224) should give sufficient guard bits to do quite a bit
> of computation.
I think going from 1:8:23 to 1:31:224 is grossly unfair. We should at
> (I suggest 1:31:224) should give sufficient guard bits to do quite a bit
> of computation.
least leave one additional bit for the sign part as well. After all,
with such insanely large numbers we will probably want to distinguish
the "very positive" from the "somewhat positive", or maybe introduce
"super negative". Well, you get the idea ;-)
Stefan "and now for something completely different"
Robert Myers
Jan 20, 2012, 12:06:32 PM1/20/12
to
On 1/20/2012 2:55 AM, Terje Mathisen wrote:
>
> However, I seem to remember that the current model says that reality is
> discrete, i.e. there is a minimum quantum size.
I don't want to be yet again blamed for turning this into a physics
>
> However, I seem to remember that the current model says that reality is
> discrete, i.e. there is a minimum quantum size.
forum, but I don't think the Planck scale is a minimum size. If you had
enough energy in one place to produce a phenomenon that size, you'd have
a black hole, so people just throw up their hands.
> If this is true, and a digital model can work on the same or even
> smaller scales, then it is hard to see how such artifacts could turn up?
>
> OTOH, it is probably much more likely that no physical computer would
> have enough memory and flops to actually run any interesting model at
> this resolution. :-)
history of nonlinear systems) that you could find at least a hint of it
on a desktop.
Robert.
Andy (Super) Glew
Jan 20, 2012, 1:18:24 PM1/20/12
to
we know that the value is strictly positive, and will not cross zero.
By the way, I have long pointed out that the problem with interval
arithmetic is interval splitting: e.g. divide by a number whose interval
crosses zero, (-m,+n), and you get two intervals extending from
(-inf,1/-m), (1/n,+inf)
With more work, you can get many different combinations of disjoint
intervals.
Mike H has pointed out that a not-unreasonable thing to do would be to
reject any division by an interval containing zero as an error.
Overall, reject any computation that leads to interval splitting.
Terje Mathisen
Jan 20, 2012, 1:23:00 PM1/20/12
to
With a size like this I would be willing to consider a valid/non-valid
bit. :-)
Robert Myers
Jan 20, 2012, 2:13:40 PM1/20/12
to
On 1/20/2012 12:06 PM, Robert Myers wrote:
>
> If there is anything interesting to be found, I suspect (given the
> history of nonlinear systems) that you could find at least a hint of it
> on a desktop.
>
In fact, I think that any pseudo random number generator that doesn't
>
> If there is anything interesting to be found, I suspect (given the
> history of nonlinear systems) that you could find at least a hint of it
> on a desktop.
>
use a non-deterministic input gives more than just a hint of the problem.
Robert.
MitchAlsup
Jan 20, 2012, 6:17:31 PM1/20/12
to
On Friday, January 20, 2012 1:13:40 PM UTC-6, Robert Myers wrote:
> In fact, I think that any pseudo random number generator that doesn't
> use a non-deterministic input gives more than just a hint of the problem.
A long time ago, I (and a team of 4) wrote a BASIC interpreter for an 8085.
> In fact, I think that any pseudo random number generator that doesn't
> use a non-deterministic input gives more than just a hint of the problem.
The random number generator had a randomize seeding function.
What I did was to reach down the stack 3 words and XOR that value with the current value in the random number generator <seed>.
It was fast and very random!
In fact it was the word <16-bits> containing the millisecond part of the
time of day being computed by the OS.
Mitch
Kai Harrekilde-Petersen
Jan 21, 2012, 1:06:12 PM1/21/12
to
> Torben Ćgidius Mogensen wrote:
>>> I.e. since there is a limited range from the quantum area to the size
>>> of the universe, how many bits do you need to uniquely locate any
>>> sub-atomic particle in the universe? 15e9 light years is around 1.4e26
>>> meters or 1.4e38 picometer.
>>>
>>> You need 127 bits to handle this range exactly, so working with
>>> 256-bit fp (I suggest 1:31:224) should give sufficient guard bits to
>>> do quite a bit of computation.
>>
>> Simulation of chaotic systems is very sensitive to precision. Even if
>> you have 100 bit precision for intermediate values, you may lose all
>> precision in the final result (i.e, even the most significant bit is
>> wrong). So you can not argue that because you need only X bits in the
>> final results, 2X (or 10X or 100X) bits is enough for intermediate
>> values. It all depends on the problem.
>
> I believe really chaotic systems like that can only ever be modeled in
> a statistical manner:
You don't need to look at chaotic systems to run into problems where you
>>> I.e. since there is a limited range from the quantum area to the size
>>> of the universe, how many bits do you need to uniquely locate any
>>> sub-atomic particle in the universe? 15e9 light years is around 1.4e26
>>> meters or 1.4e38 picometer.
>>>
>>> You need 127 bits to handle this range exactly, so working with
>>> 256-bit fp (I suggest 1:31:224) should give sufficient guard bits to
>>> do quite a bit of computation.
>>
>> Simulation of chaotic systems is very sensitive to precision. Even if
>> you have 100 bit precision for intermediate values, you may lose all
>> precision in the final result (i.e, even the most significant bit is
>> wrong). So you can not argue that because you need only X bits in the
>> final results, 2X (or 10X or 100X) bits is enough for intermediate
>> values. It all depends on the problem.
>
> I believe really chaotic systems like that can only ever be modeled in
> a statistical manner:
need obscene amount of intermediate precision to get anywhere: if you
try to compute the impedance of a pair of differential microstrips, you
run into elliptic integrals and the areas of interest are (of course)
very close to x=0 or x=1 where your bits disappear at the rate of N^4 or
so - even the 80-bit extended precision mode didn't cut it.
Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>
Robert Myers
Jan 21, 2012, 3:47:22 PM1/21/12
to
On 1/21/2012 1:06 PM, Kai Harrekilde-Petersen wrote:
>
> You don't need to look at chaotic systems to run into problems where you
> need obscene amount of intermediate precision to get anywhere: if you
> try to compute the impedance of a pair of differential microstrips, you
> run into elliptic integrals and the areas of interest are (of course)
> very close to x=0 or x=1 where your bits disappear at the rate of N^4 or
> so - even the 80-bit extended precision mode didn't cut it.
Situations like that give you a strong incentive to understand the
>
> You don't need to look at chaotic systems to run into problems where you
> need obscene amount of intermediate precision to get anywhere: if you
> try to compute the impedance of a pair of differential microstrips, you
> run into elliptic integrals and the areas of interest are (of course)
> very close to x=0 or x=1 where your bits disappear at the rate of N^4 or
> so - even the 80-bit extended precision mode didn't cut it.
methods of pre-supercomputer analysis.
In many cases, there is a closed form approximate solution that takes
care of the part of the problem that is greedy for precision, leaving
the computer to deal with undemanding corrections to the approximate
solution.
I can't remember encountering a problem where there was no choice but to
resort to brute force (lots and lots of bits).
Robert.
Robert Wessel
Jan 22, 2012, 10:53:09 PM1/22/12
to
"lots and lots of bit" is such that only rarely would such a solution
be considered acceptable, which will certainly lead to seeking a
solution that does *not* require that, or failing that, recasting the
problem in a more tractable form, or abandoning it altogether.
Terje Mathisen
Jan 23, 2012, 2:26:37 AM1/23/12
to
Robert Wessel wrote:
>> In many cases, there is a closed form approximate solution that takes
>> care of the part of the problem that is greedy for precision, leaving
>> the computer to deal with undemanding corrections to the approximate
>> solution.
>>
>> I can't remember encountering a problem where there was no choice but to
>> resort to brute force (lots and lots of bits).
>
> Isn't that at least a bit circular? The performance overhead of using
> "lots and lots of bit" is such that only rarely would such a solution
> be considered acceptable, which will certainly lead to seeking a
> solution that does *not* require that, or failing that, recasting the
> problem in a more tractable form, or abandoning it altogether.
I believe you're both right:
>> In many cases, there is a closed form approximate solution that takes
>> care of the part of the problem that is greedy for precision, leaving
>> the computer to deal with undemanding corrections to the approximate
>> solution.
>>
>> I can't remember encountering a problem where there was no choice but to
>> resort to brute force (lots and lots of bits).
>
> Isn't that at least a bit circular? The performance overhead of using
> "lots and lots of bit" is such that only rarely would such a solution
> be considered acceptable, which will certainly lead to seeking a
> solution that does *not* require that, or failing that, recasting the
> problem in a more tractable form, or abandoning it altogether.
We (computer people) tend to automatically avoid algorithms that are
misbehaved (needing excessive working bit size), but the success rate in
seeking better algorithms have been so high that we tend to assume more
algorithms instead of more bits.
Those (few?) problems where we cannot find better algorithms in order to
reduce the need for excessive "guard" bits therefore tend to be ignored
as "not interesting enough". I.e. "too hard for me, but I won't admit that".
Sort of like our friend Anton Ertl: "...Most things have to be believed
to be seen".
nm...@cam.ac.uk
Jan 23, 2012, 3:43:39 AM1/23/12
to
In article <87fwfja...@NaN.sparse.dyndns.org>,
Jason Riedy <ja...@lovesgoodfood.com> wrote:
>And Andy Glew writes:
>> This would be an argument for having both denorm and flush to
>> zero mode.
>
>The argument against is not mathematical but related to the
>"-fast" option in compilers and the utter lack of knowledge of
>how to make code safe against it (or utter lack of funding to
>make code safe against it).
As I and others, I have pointed out, that is misleading to the
point of being false. That may be the main reason, but there
are also mathematical ones, and exactly the same argument can
be applied the other way round! TANSTAAFL.
>For examples where subnormal numbers can cause incorrect results,
>look towards contractive processes. If you're contracting
>towards X, the behavior is different when X is zero. I can't
>come up with a concrete example right now; I'm too out of
>practice.
Yes. I could, but it's not worth it.
>I'm on the side of "if (a != b) z = c/(a-b)". Others aren't.
No, that is NOT so. What others are in favour of is preserving
some of the invariants that denormalised numbers break. It is
all a matter of value judgement.
>Evidence supporting the different sides appears anecdotal at
>best. The anecdotes supporting subnormals were stronger when
>most people used the extremely limited range of single precision
>(lose a factor of eight in range). Oh, wait, we're still
>there...
Even this thread has produced better evidence than that. What
there is no hard evidence for is which of the two sides is better
overall - and I explained why the answer is likely to differ
according to exactly what you mean by 'better'. Despite common
belief, this is NOT an unstudied area.
Regards,
Nick Maclaren.
Jason Riedy <ja...@lovesgoodfood.com> wrote:
>And Andy Glew writes:
>> This would be an argument for having both denorm and flush to
>> zero mode.
>
>The argument against is not mathematical but related to the
>"-fast" option in compilers and the utter lack of knowledge of
>how to make code safe against it (or utter lack of funding to
>make code safe against it).
As I and others, I have pointed out, that is misleading to the
point of being false. That may be the main reason, but there
are also mathematical ones, and exactly the same argument can
be applied the other way round! TANSTAAFL.
>For examples where subnormal numbers can cause incorrect results,
>look towards contractive processes. If you're contracting
>towards X, the behavior is different when X is zero. I can't
>come up with a concrete example right now; I'm too out of
>practice.
Yes. I could, but it's not worth it.
>I'm on the side of "if (a != b) z = c/(a-b)". Others aren't.
No, that is NOT so. What others are in favour of is preserving
some of the invariants that denormalised numbers break. It is
all a matter of value judgement.
>Evidence supporting the different sides appears anecdotal at
>best. The anecdotes supporting subnormals were stronger when
>most people used the extremely limited range of single precision
>(lose a factor of eight in range). Oh, wait, we're still
>there...
Even this thread has produced better evidence than that. What
there is no hard evidence for is which of the two sides is better
overall - and I explained why the answer is likely to differ
according to exactly what you mean by 'better'. Despite common
belief, this is NOT an unstudied area.
Regards,
Nick Maclaren.
Joe keane
Jan 23, 2012, 1:26:55 PM1/23/12
to
In article <4F19AFF0...@SPAM.comp-arch.net>,
You just need 'out' intervals and 'in' intervals. You don't even need
an extra bit to mark it, just switch the bounds.
This is pretty natural, it starts this place, it ends this place, it
just happens to go through this town called infinity, but what of it?
When you have a division operation, the space of both kinds combined
makes more sense.
Andy (Super) Glew <an...@SPAM.comp-arch.net> wrote:
>By the way, I have long pointed out that the problem with interval
>arithmetic is interval splitting: e.g. divide by a number whose interval
>crosses zero, (-m,+n), and you get two intervals extending from
>(-inf,1/-m), (1/n,+inf)
It's no problem.
>By the way, I have long pointed out that the problem with interval
>arithmetic is interval splitting: e.g. divide by a number whose interval
>crosses zero, (-m,+n), and you get two intervals extending from
>(-inf,1/-m), (1/n,+inf)
You just need 'out' intervals and 'in' intervals. You don't even need
an extra bit to mark it, just switch the bounds.
This is pretty natural, it starts this place, it ends this place, it
just happens to go through this town called infinity, but what of it?
When you have a division operation, the space of both kinds combined
makes more sense.
Robert Myers
Jan 23, 2012, 2:11:08 PM1/23/12
to
require extreme precision almost always had an idealization that
captured the need for extreme precision but that wasn't the actual
problem. So you do the approximate extreme precision problem the
old-fashioned (pre-computer) way, and let the computer clean up the
difference between the extreme precision (often asymptotic) idealization
and the real problem. There is no theorem that guarantees such will
always be the case, but I've never actually encountered a problem where
brute force extreme precision was the only choice.
Many-particle, strong-field problems may eventually require more
precision, but there are other obstacles to that class of problems about
which I have already gone on at too much length.
Robert.
Andy (Super) Glew
Jan 23, 2012, 10:55:35 PM1/23/12
to
It's not just in and out.
Andy (Super) Glew
Jan 23, 2012, 11:01:14 PM1/23/12
to
On 1/23/2012 10:26 AM, Joe keane wrote:
Let b = a+1 => [-inf,+1/2] union [4/3,+inf]
Let c = min(b,40) => [-inf,+1/2] union [4/3,40]
Let c = 1/b => [-inf,0] union [2,+inf] union [1/40,3/4]
Etc.
Torben Ægidius Mogensen
Jan 24, 2012, 6:20:35 AM1/24/12
to
timca...@aol.com (Tim McCaffrey) writes:
> For years I was trying to come up with a (fairly) compact representation
> which was in the form:
>
> (PQ1, PQ2, ... PQn) / (PD1, PD2, ... PDn)
>
> Where PQx & PDx were primes, such that no PQn == PDn (no common divisor) (I
> guess it really should be x*Pxx where a prime is needed multiple times).
While multiplication is easy, addition would require factorisation:
> For years I was trying to come up with a (fairly) compact representation
> which was in the form:
>
> (PQ1, PQ2, ... PQn) / (PD1, PD2, ... PDn)
>
> Where PQx & PDx were primes, such that no PQn == PDn (no common divisor) (I
> guess it really should be x*Pxx where a prime is needed multiple times).
p/q+r/s = (ps+rq)/qs. If you want to represent ps+rq as a product of
primes, there is no way of avoiding factorisation.
It makes more sense to represent numbers as p/q where p and q has no
common factor. Largest common divisor is (relatively) fast to compute.
But p and q will grow very quickly, so it isn't practical for lengthy
computations.
Scheme has a reasonable approach: There is only one number type, which
includes unbounded integers, fractions, floating point and complex.
When you divide integers, you get fractions and when you use operations
that give irrational results, you get floating-point or complex. Any
number is combined with an "exact" indicator. If any operation loses
precision, this is set. It can be set even for integers: If you round
an inexact number to integer, the result is still considered inexact. I
don't recall if Scheme has infinite numbers.
Torben
Torben Ægidius Mogensen
Jan 24, 2012, 6:34:51 AM1/24/12
to
line. See http://en.wikipedia.org/wiki/Real_projective_line, in
particular the interval arithmetic section.
Torben
Andy (Super) Glew
Jan 24, 2012, 1:29:26 PM1/24/12
to
intervals with finite bounds
Joe keane
Jan 25, 2012, 10:51:39 AM1/25/12
to
In article <4F1E2D0A...@SPAM.comp-arch.net>,
interval. Remember that we're only storing two values.
You can choose between [-inf,40] and [-inf,+1/2] | [4/3,inf]. They are
equally bad, losing information, but both correct.
It's interval arithmetic. It says 'every possible result is a member of
this interval' and not 'every member of this interval is a possible
result'.
Andy (Super) Glew <an...@SPAM.comp-arch.net> wrote:
>Let b = a+1 => [-inf,+1/2] union [4/3,+inf]
>
>Let c = min(b,40) => [-inf,+1/2] union [4/3,40]
That is not one of the possible values of the type. It's not even an
>Let b = a+1 => [-inf,+1/2] union [4/3,+inf]
>
>Let c = min(b,40) => [-inf,+1/2] union [4/3,40]
interval. Remember that we're only storing two values.
You can choose between [-inf,40] and [-inf,+1/2] | [4/3,inf]. They are
equally bad, losing information, but both correct.
It's interval arithmetic. It says 'every possible result is a member of
this interval' and not 'every member of this interval is a possible
result'.
Torben Ægidius Mogensen
Jan 26, 2012, 4:47:03 AM1/26/12
to
"Andy (Super) Glew" <an...@SPAM.comp-arch.net> writes:
> On 1/24/2012 3:34 AM, Torben Ægidius Mogensen wrote:
>> "Andy (Super) Glew"<an...@SPAM.comp-arch.net> writes:
>>> Let a = 1 / [-2,+3] => [-inf,-1/2] union [+1/3,+inf]
>>>
>>> Let b = a+1 => [-inf,+1/2] union [4/3,+inf]
>>>
>>> Let c = min(b,40) => [-inf,+1/2] union [4/3,40]
>>>
>>> Let c = 1/b => [-inf,0] union [2,+inf] union [1/40,3/4]
>>>
>>> Etc.
>>
>> You can solve this by equating -inf and +inf on the real projective
>> line. See http://en.wikipedia.org/wiki/Real_projective_line, in
>> particular the interval arithmetic section.
>>
> On 1/24/2012 3:34 AM, Torben Ægidius Mogensen wrote:
>> "Andy (Super) Glew"<an...@SPAM.comp-arch.net> writes:
>>> Let a = 1 / [-2,+3] => [-inf,-1/2] union [+1/3,+inf]
>>>
>>> Let b = a+1 => [-inf,+1/2] union [4/3,+inf]
>>>
>>> Let c = min(b,40) => [-inf,+1/2] union [4/3,40]
>>>
>>> Let c = 1/b => [-inf,0] union [2,+inf] union [1/40,3/4]
>>>
>>> Etc.
>>
>> You can solve this by equating -inf and +inf on the real projective
>> line. See http://en.wikipedia.org/wiki/Real_projective_line, in
>> particular the interval arithmetic section.
>>
> by judicious use of min and max you can get any number of disjoint
> intervals with finite bounds
The usual less-than relation is not well defined on the projective line
> intervals with finite bounds
(since it circular), so neither are min and max in the usual sense. We
can, however, define functions that coincide with the usual when both
intervals are finite.
In any case, as Joe mentioned, interval arithmetic must result in an
interval that contains all possible values, so the _set_ of results
obtained by taking all possible points in the argument intervals must be
extended to an _interval_ (the smallest interval containing the set of
results). Yes, this gives loss of precision compared to working with
exact sets, but you at least have a bound on the imprecision, which you
don't with normal FP arithmetic.
Torben
0 new messages