Steven,
Thanks for your comments. You bring up some interesting points, however, you
also raise some more questions.
First, you criticize my use of the variable name 'epsilon'. Of course, this
usage is entirely consistent with its ubiquitous use in mathematics. I am
designating a(n) (arbitrari
All~
A good "close enough" comparison is actually very difficult. I adapted one
based on
http://adtmag.com/Articles/2000/03/16/Comparing-Floats-How-To-Determine-if-Floating-Quantities-Are-Close-Enough-Once-a-Tolerance-Has-Been.aspx?Page=1
which provides a pretty good example and handles all the
cej38 writes:
> (defn float=
> ([x y] (float= x y 0.1))
> ([x y epsilon]
> (let [scale (if (or (zero? x) (zero? y)) 1 (Math/abs x))]
>(<= (Math/abs (- x y)) (* scale epsilon )
You're scaling epsilon incorrectly here. Epsilon defines the smallest
value that yields a value
On Oct 14, 2010, at 12:07 PM, cej38 wrote:
> I am kinda sorry that I started this whole thing. I don't need
> another lesson in limits. The simple fact of the matter is that, in
> my code, I run into a place where I have a comparison (= some-value
> (some-function some-data)), the function, dat
On Thu, Oct 14, 2010 at 12:07 PM, cej38 wrote:
> I am kinda sorry that I started this whole thing. I don't need
> another lesson in limits. The simple fact of the matter is that, in
> my code, I run into a place where I have a comparison (= some-value
> (some-function some-data)), the function,
I am kinda sorry that I started this whole thing. I don't need
another lesson in limits. The simple fact of the matter is that, in
my code, I run into a place where I have a comparison (= some-value
(some-function some-data)), the function, data, and value can change.
In a use case that I am inte
For the sake of comparison with other LISPs - some Scheme
implementations have an exact? function for dealing with non-precise
numbers.
This seems not to have come across to Clojure. (Although we do have
ratios and BigInteger).
JG
--
You received this message because you are subscribed to the
Another proof:
Let study the sequence sn = 0....9 , with n 9s.
Or s0= 0 and s(n+1) = sn + 9 / 10 ^n
lim sn = 0.9...
and lim sn = 1.
so
If I remember my meth correctly,
the number 0... does not exist.
This not a legal decimal sequence.
(Any decimal sequence finishing b
OKay, I think I get it. Thanks :)
On 14/10/10 00:56, David Sletten wrote:
> Here's a slightly more informal argument. Suppose you challenge me that
> 1 is not equal to 0.... What you are saying is that 1 - 0.... is
> not equal to 0, i.e., the difference is more than 0. But for any
> positi
The quick and dirty proof (not formal proof) for 1 = ....
1/3 = .33...
2/3 = .66...
3/3 = .99...
Think of 3/3 as 1/3 (that is .3...) times 3.
-Terrance Davis
www.terrancedavis.com
Felix H. Dahlke wrote:
On 13/10/10 22:28, David Sletten wrote:
On Oct 12, 2010, at 5:44
On Thu, 14 Oct 2010 00:27:39 +0200
"Felix H. Dahlke" wrote:
> On 13/10/10 22:28, David Sletten wrote:
> >
> > On Oct 12, 2010, at 5:44 PM, Brian Hurt wrote:
> >
> >> For example, in base 10, 1/3 * 3 = 0.9...
> >
> > It may seem counterintuitive, but that statement is perfectly true.
>
Here's a slightly more informal argument. Suppose you challenge me that 1 is
not equal to 0.... What you are saying is that 1 - 0.... is not equal
to 0, i.e., the difference is more than 0. But for any positive value
arbitrarily close to 0 I can show that 0.999... is closer to 1 than tha
Felix~
You are correct that the sequence of numbers
0.9
0.99
0.999
...
asymptotically approaches 1; however, the number 0.... (with an infinite
number of 9s) is equal to 1. The formal proof of this is fairly tricky as
the definition of the real number is usually done as an equivalence class
On 13/10/10 22:28, David Sletten wrote:
>
> On Oct 12, 2010, at 5:44 PM, Brian Hurt wrote:
>
>> For example, in base 10, 1/3 * 3 = 0.9...
>
> It may seem counterintuitive, but that statement is perfectly true.
> 1 = 0....
>
> That's a good test of how well you understand infinity.
Um, not if you're going to try and turn them into numbers first. But
if you store them as ['sqrt 5] or some similar operator/operand pair,
then you can manipulate them symbolically and wait for them to cancel
out, instead of evaluating them. This requires implementing some kind
of symbolic-algebra
A slight tangent, is there anyway to represent exact square roots?
I'd like to have an exact closed form fibonacci function.
On Oct 13, 1:28 pm, David Sletten wrote:
> On Oct 12, 2010, at 5:44 PM, Brian Hurt wrote:
>
> > For example, in base 10, 1/3 * 3 = 0.9...
>
> It may seem counterint
On Oct 12, 2010, at 5:44 PM, Brian Hurt wrote:
> For example, in base 10, 1/3 * 3 = 0.9...
It may seem counterintuitive, but that statement is perfectly true.
1 = 0....
That's a good test of how well you understand infinity.
Of course, the problem arises when we truncate the string
Nice rant, I learned something here :) I somehow thought BigDecimal
wouldn't have any precision issues, but I probably never noticed because
I can only think in base-10 arithmetic. Has been good enough for my
humble precision problems so far though, never had a notable performance
issue with it eit
On Tue, Oct 12, 2010 at 8:35 PM, cej38 wrote:
> The more that I think about it, the more I would rather have a set of
> equalities that always work. float= was a good try.
>
>
The only way to do so is to have numbers with infinite precision.
For example as lazy-seq of their digits.
But:
- it i
On Tue, 12 Oct 2010 17:44:20 -0400
Brian Hurt wrote:
> On Tue, Oct 12, 2010 at 3:35 PM, cej38 wrote:
>
> > The more that I think about it, the more I would rather have a set of
> > equalities that always work. float= was a good try.
>
Maybe initially, but not later on...
> Floating point is
On Tue, Oct 12, 2010 at 3:35 PM, cej38 wrote:
> The more that I think about it, the more I would rather have a set of
> equalities that always work. float= was a good try.
>
>
>
Every fucking language I've ever worked on has had this problem- "floats are
broken!" And every single one, people
o becomes "fuzzy" - whether two numbers are equal will
depend on the context. So you have to choose the equality that's
appropriate for the context.
If you want precise numbers, Clojure has three options:
1) If you can represent everything as integers, then BigInteger is
probably the
I suggest you read the article a bit more closely. Here are the details of your
specific case.
The number that you are typing as 12.305 is actually being stored in the
computer as this:
1100.010011110100001011110100001011100
This number is actually this fraction:
173177479421231
The more that I think about it, the more I would rather have a set of
equalities that always work. float= was a good try.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts fr
Short comment:
I remember Common Lisp has rational numbers (I'm not sure). Any rational
number library for Clojure?
Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
On Tue, Oct 12, 2010 at 4:14 PM, Luka Stojanovic wrote:
> On Tue, 12 Oct 2010 20:53:16 +0200, cej38 wrote:
On Tue, 12 Oct 2010 20:53:16 +0200, cej38 wrote:
On Oct 12, 12:50 pm, David Sletten wrote:
This discussion may
help:http://www.gettingclojure.com/cookbook:numbers#comparing-floats
I originally tried something like float= described in the link, I give
the definition here
(defn float=
([x
On Oct 12, 12:50 pm, David Sletten wrote:
> This discussion may
> help:http://www.gettingclojure.com/cookbook:numbers#comparing-floats
I originally tried something like float= described in the link, I give
the definition here
(defn float=
([x y] (float= x y 0.1))
([x y epsilon]
(le
If you want to be really precise, most real numbers are an infinite
number of decimals.
If you encode them as a lazy seq of decimals, + - and other ops are doable.
Comparison is semi-decidable only: it terminates only in certain case
(finite number of decimals)
or when the number are different.
b
Welcome to floating point math.
As an alternative, try using arbitrary-precision numerics:
user=> (- 12.305M 12.3049M)
0.0001M
user=> (type *1)
java.math.BigDecimal
On Oct 12, 9:17 am, cej38 wrote:
> I keep running into this type of problem:
>
> user=> (- 12.305 12.3049)
> 9.9976694E-5
Um, I meant BigDecimal, not BigInteger.
On 12/10/10 18:24, Felix H. Dahlke wrote:
> You could use BigInteger, which was created to work around double's
> rounding issues - among other things.
>
> (- 12.305M 12.3049M)
> 0.0001M
>
> On 12/10/10 18:17, cej38 wrote:
>> I keep running into this type
Also see (rationalize) to simplify my example of using ratios. I
couldn't remember the name of the function off the top of my head, so
I used a hacked-up-by-me version.
On Oct 12, 9:33 am, Alan wrote:
> The JVM has no choice: it must faithfully implement the IEEE floating-
> point spec (http://en
This discussion may help:
http://www.gettingclojure.com/cookbook:numbers#comparing-floats
Have all good days,
David Sletten
On Oct 12, 2010, at 12:17 PM, cej38 wrote:
> I keep running into this type of problem:
>
> user=> (- 12.305 12.3049)
> 9.9976694E-5
>
> The computer (probably the
The JVM has no choice: it must faithfully implement the IEEE floating-
point spec (http://en.wikipedia.org/wiki/IEEE_754-2008), which
specifies limited precision. By asking it to use floats, you are
demanding that it accept rounding errors. If you want precision, there
are lots of ways to get it; t
On Tue, Oct 12, 2010 at 12:17 PM, cej38 wrote:
> I keep running into this type of problem:
>
> user=> (- 12.305 12.3049)
> 9.9976694E-5
http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
David
--
You received this message because you are subscribed to the Googl
You could use BigInteger, which was created to work around double's
rounding issues - among other things.
(- 12.305M 12.3049M)
0.0001M
On 12/10/10 18:17, cej38 wrote:
> I keep running into this type of problem:
>
> user=> (- 12.305 12.3049)
> 9.9976694E-5
>
> The computer (probably the
I keep running into this type of problem:
user=> (- 12.305 12.3049)
9.9976694E-5
The computer (probably the JVM) has just lied to me. Any fourth grade
student will know that this does not equal 0.0001. This would be less
of a problem is the JVM was consistent; if it were consistent then
36 matches
Mail list logo