On the one hand, you say "If it gives you the wrong answer, it's a
bug. Period. If your representation cannot give you the precision
you need for the task at hand, then you need a different
representation. Period."
Then you say "No, becuase [representing irrational numbers is]
impossible to do with a finite representation AFAIK. If I'm wrong, I
would love to know how this can be done."
Interesting question. I don't think that's a contradiction so much as
an acknowledgement of the fundamental limitations of digital computing.
With data structures like BigDecimal and Rational, we can exactly
represent any rational number we like in a finite amount of storage.
Irrational numbers are different. We could represent them exactly on an
analog computer such as a slide rule, but there is no general method
that I am aware of for doing so in a finite amount of digital storage.
Certain numbers, such as square roots, can be represented with tricks
like quadratic equations to which they are the root, but that won't work
for transcendental numbers like e or π. We can calculate those numbers
to millions of decimal places if we need to -- but unlike rational
numbers, we can never store them exactly.
So we do the best we can. Since rational numbers can be represented
exactly, it makes sense to do so. Since (many) irrational numbers
cannot be represented exactly, we get as close as we can.
transcendentals can also be represented exactly by formulae with a
finite number of bits:
pi/4 = 1 - 1/3 + 1/5 - 1/7 + .... #that might not be the exact right formula, but you get the idea
this can also be represented by a (fairly short) program:
def pi_over_4
result=0
sign=1
for i in 0..Infinity do
result+= Rational.new(sign,2*i+1)
sign=-sign
end
return result
end
of course, this would take an infinite amount of time to execute, and
require an infinite amount of memory to store the result, but in a
lazy functional language like haskell, that would not be true. also,
in a functional language, I _believe_ you can manipulate programs like
the one above as if they were numbers. how often is that capability
really needed? maybe mathematica actually works this way, but it's
probably the only one.
on the other hand, there is another class of (real) numbers, the
incomputables, beyond the transcendentals, for which there is no
(finite length) formula or program possible.... but how often do you
need to write a program which deals with (an exact representation of)
those?
···
On 11/16/09, Marnen Laibow-Koser <marnen@marnen.org> wrote:
Certain numbers, such as square roots, can be represented with tricks
like quadratic equations to which they are the root, but that won't work
for transcendental numbers like e or π. We can calculate those numbers
to millions of decimal places if we need to -- but unlike rational
numbers, we can never store them exactly.
Certain numbers, such as square roots, can be represented with tricks
like quadratic equations to which they are the root, but that won't work
for transcendental numbers like e or �. We can calculate those numbers
to millions of decimal places if we need to -- but unlike rational
numbers, we can never store them exactly.
transcendentals can also be represented exactly by formulae with a
finite number of bits:
pi/4 = 1 - 1/3 + 1/5 - 1/7 + .... #that might not be the exact right formula, but you get the idea
Oh, good point. Hadn't thought about that.
this can also be represented by a (fairly short) program:
def pi_over_4
result=0
sign=1
for i in 0..Infinity do
result+= Rational.new(sign,2*i+1)
sign=-sign
end
return result
end
of course, this would take an infinite amount of time to execute, and
require an infinite amount of memory to store the result, but in a
lazy functional language like haskell, that would not be true. also,
in a functional language, I _believe_ you can manipulate programs like
the one above as if they were numbers.
To some extent, you can do that in Ruby. Proc and Method are
first-class objects.
how often is that capability
really needed?
Which capability? Functional programming? It can be useful.
maybe mathematica actually works this way, but it's
probably the only one.
I'm not sure.
on the other hand, there is another class of (real) numbers, the
incomputables, beyond the transcendentals, for which there is no
(finite length) formula or program possible.... but how often do you
need to write a program which deals with (an exact representation of)
those?
I don't know. Are any important constants incomputable?
Best,
···
On 11/16/09, Marnen Laibow-Koser <marnen@marnen.org> wrote:
... transcendentals can also be represented exactly by formulae with a
finite number of bits:
Doesn't that depend on the transcendental?
... on the other hand, there is another class of (real) numbers, the
incomputables, beyond the transcendentals, for which there is no
(finite length) formula or program possible.... but how often do you
need to write a program which deals with (an exact representation of)
those?
"Most" real numbers are both transcendental and non computable.
... almost all real and complex numbers are transcendental ...
... almost all real numbers are not computable ...
... Are any important constants incomputable?
An interesting question. There are, for example Chaitin's constants: Chaitin's constant - Wikipedia Chaitin's Constant -- from Wolfram MathWorld
which are (I assume) important in computation theory
but (very?) unlikely to be useful in normal problems!
(Although it's slightly risky to make that statement
about anything: even obscure mathematics
sometimes turns out to have "real world" importance.)
Returning to the original question(s) in this thread:
* From years ago I recall Fractint being written using integers
for speed (and possibly also for precision). But now:
"... the first versions of it computed fractals by using only
integer arithmetic (also known as fixed-point arithmetic),
which led to much faster rendering on x86 computers
without math coprocessors. Since then, floating-point arithmetic
and "arbitrary-precision" modes have been added,
the latter of which emulates an arbitrarily large mantissa in RAM.
The arbitrary-precision mode is slow even on modern computers. ..."
* Depending on the problem, inherent uncertainty in the data
may make the notion of an "exact" number misleading.
I'm not arguing against using "precise" representations,
I'm just saying that before using more precise representations
one should ask whether what that gives (and costs,
in terms of performance) is worth having. There may well
be "wrong" answers without there being unique "right" answers,
just degrees of "rightness".
For example, using 22/7 for pi is an error of about 0.04%.
(Using Ruby Math::PI = 3.14159265358979 as an approximation to pi.)
Using 355/113 is an error of less than (10 ** -7)%.
The circumference of the Earth is about 40,000 km, and depending on
where and how you measure it, the "actual" figure is +/- about 75 km.
Using 22/7 instead of pi for the circumference gives an "error" of 16 km,
which may be "reasonable" given the inherent "uncertainty"
in the circumference (depending on what you want to do).
Using 355/113 instead of pi gives an "error" of about 4 metres,
which for most(?) purposes is insignificant compared with
the inherent "uncertainty" in the circumference.
I'm to some extent guilty of not following my own precepts:
for financial calculations I mostly use double precision floats,
and I suspect that for much of those calculations
using single precision floats would be sufficiently accurate.
I don't do that because double precision floats are fast,
and with double precision I don't need to worry so much
about "rounding errors". But I do try to present the results
in ways which do not give an impression of "spurious accuracy".
of course, this would take an infinite amount of time to execute, and
require an infinite amount of memory to store the result, but in a
lazy functional language like haskell, that would not be true. also,
in a functional language, I _believe_ you can manipulate programs like
the one above as if they were numbers.
To some extent, you can do that in Ruby. Proc and Method are
first-class objects.
Yeah, but you can't manipulate their results when they return one if
they ever do as if they were numbers.
how often is that capability
really needed?
Which capability? Functional programming? It can be useful.
The capability to represent transcendental numbers exactly. I mean,
how much precision do you really need?
···
On 11/16/09, Marnen Laibow-Koser <marnen@marnen.org> wrote:
When I said 'transcendental', I meant a transcendental which is not
incomputable. Just as when Marnen said 'irrational', he meant an
irrational which is not transcendental.
···
On 11/16/09, Colin Bartlett <colinb2r@googlemail.com> wrote:
To some extent, you can do that in Ruby. Proc and Method are
first-class objects.
Yeah, but you can't manipulate their results when they return one if
they ever do as if they were numbers.
Of course you can, unless I'm totally misunderstanding. Got a concrete
example
how often is that capability
really needed?
Which capability? Functional programming? It can be useful.
The capability to represent transcendental numbers exactly. I mean,
how much precision do you really need?
Depends on the task. I suspect a couple hundred decimals would be the
most you'd ever really need, and a couple of decades of decimals would
probably suffice for most cases.
The pi_over_4 method I posted earlier is a good one. You can't
manipulate the _future_ result of that as if it were a number, because
(among other things) it never returns. Need a lazy functional language
for that kind of thing. (If that even suffices....)
_Maybe_ you could write a futures library and implement the pi_over_4
formula within that in some kind of useful way, but idunno.... I kind
of think you need laziness built into the core language for something
like that to be useful.
···
On 11/17/09, Marnen Laibow-Koser <marnen@marnen.org> wrote:
Yeah, but you can't manipulate their results when they return one if
they ever do as if they were numbers.
Of course you can, unless I'm totally misunderstanding. Got a concrete
example
On 11/17/09, Marnen Laibow-Koser <marnen@marnen.org> wrote:
Yeah, but you can't manipulate their results when they return one if
they ever do as if they were numbers.
Of course you can, unless I'm totally misunderstanding. Got a concrete
example
The pi_over_4 method I posted earlier is a good one. You can't
manipulate the _future_ result of that as if it were a number, because
(among other things) it never returns. Need a lazy functional language
for that kind of thing. (If that even suffices....)
You can't manipulate the future in any language that I'm aware of --
it's not there to manipulate yet! Are you thinking of lisp's
tail-recursion optimization?
On 11/17/09, Marnen Laibow-Koser <marnen@marnen.org> wrote:
Yeah, but you can't manipulate their results when they return one if
they ever do as if they were numbers.
Of course you can, unless I'm totally misunderstanding. Got a concrete
example
The pi_over_4 method I posted earlier is a good one. You can't
manipulate the _future_ result of that as if it were a number, because
(among other things) it never returns. Need a lazy functional language
for that kind of thing. (If that even suffices....)
_Maybe_ you could write a futures library and implement the pi_over_4
formula within that in some kind of useful way, but idunno.... I kind
of think you need laziness built into the core language for something
like that to be useful.
On 17 Nov 2009, at 18:22, Marnen Laibow-Koser wrote:
Caleb Clausen wrote:
On 11/17/09, Marnen Laibow-Koser <marnen@marnen.org> wrote:
Yeah, but you can't manipulate their results when they return one if
they ever do as if they were numbers.
Of course you can, unless I'm totally misunderstanding. Got a concrete
example
The pi_over_4 method I posted earlier is a good one. You can't
manipulate the _future_ result of that as if it were a number, because
(among other things) it never returns. Need a lazy functional language
for that kind of thing. (If that even suffices....)
You can't manipulate the future in any language that I'm aware of --
it's not there to manipulate yet! Are you thinking of lisp's
tail-recursion optimization?
Well, that'll teach me. How did you find it, out of sheer curiosity? I
did not use lazy as a keyword, so maybe that was it..
--
Posted via http://www.ruby-forum.com/\.
I've just been reading this list forever and knew it existed. I had an unfair advantage.
Lazy evaluation was a popular topic in Ruby circles sometime back. That was when Lazy.rb was invented. I looked into it quite a bit while writing this old blog post:
I've just been reading this list forever and knew it existed. I had an
unfair advantage.
Lazy evaluation was a popular topic in Ruby circles sometime back. That
was when Lazy.rb was invented. I looked into it quite a bit while
writing this old blog post:
Time to get some more reading underway. Oh... And did you know that the
lazy.rb file/gem is actually mentioned in "Ruby Best Practices" ?
Figures that ruby-forum and the book would act synchronistically for
me..
James does know that because the chapter in RBP was based off the blog
series he just linked to
···
On Tue, Nov 17, 2009 at 10:33 PM, Aldric Giacomoni <aldric@trevoke.net> wrote:
James Edward Gray II wrote:
I've just been reading this list forever and knew it existed. I had an
unfair advantage.
Lazy evaluation was a popular topic in Ruby circles sometime back. That
was when Lazy.rb was invented. I looked into it quite a bit while
writing this old blog post:
Time to get some more reading underway. Oh... And did you know that the
lazy.rb file/gem is actually mentioned in "Ruby Best Practices" ?
Figures that ruby-forum and the book would act synchronistically for
me..
On Tue, Nov 17, 2009 at 10:33 PM, Aldric Giacomoni <aldric@trevoke.net> > wrote:
James Edward Gray II
Time to get some more reading underway. Oh... And did you know that the
lazy.rb file/gem is actually mentioned in "Ruby Best Practices" ?
Figures that ruby-forum and the book would act synchronistically for
me..
James does know that because the chapter in RBP was based off the blog
series he just linked to
Alright, so I'm a n00b I turned two more pages to see his name show
up.. I'll just be quiet until I'm done with the book
--
Posted via http://www.ruby-forum.com/\.
