On Dec 10, 2:23 pm, Carl Banks wrote:
> ...
> > A useful description of floating point issues can be found:
>
> [snip]
>
> I'm not reading it because I believe I grasp the situation just fine.
> ...
>
> Say I have two numbers, a and b. They are expected to be in the range
> (-1000,1000). As far
[Carl Banks]
> > You're talking about machine epsilon? I think everyone else here is
> > talking about a number that is small relative to the expected smallest
> > scale of the calculation.
That was also my reading of the OP's question.
The suggestion to use round() was along the
lines of perfor
On Dec 10, 10:46 am, dbd wrote:
> On Dec 7, 12:58 pm, Carl Banks wrote:
>
> > On Dec 7, 10:53 am, dbd wrote:
> > > ...
>
> > You're talking about machine epsilon? I think everyone else here is
> > talking about a number that is small relative to the expected smallest
> > scale of the calculatio
On Dec 7, 12:58 pm, Carl Banks wrote:
> On Dec 7, 10:53 am, dbd wrote:
> > ...
>
> You're talking about machine epsilon? I think everyone else here is
> talking about a number that is small relative to the expected smallest
> scale of the calculation.
>
> Carl Banks
When you implement an algori
On Dec 7, 4:28 am, sturlamolden wrote:
> ...
>
> You don't understand this at all do you?
>
> If you have a sine wave with an amplitude less than the truncation
> error, it will always be approximately equal to zero.
>
> Numerical maths is about approximations, not symbolic equalities.
>
> > 1.0 +
On 7 Des, 06:43, dbd wrote:
> If you have
> samples of a sine wave with peak amplitude of one half eps, the "abs(x-
> y) < eps" test would report all values on the sine wave as equal to
> zero. This would not be correct.
You don't understand this at all do you?
If you have a sine wave with an a
On Dec 7, 10:53 am, dbd wrote:
> On Dec 7, 4:28 am, sturlamolden wrote:
>
> > ...
>
> > You don't understand this at all do you?
>
> > If you have a sine wave with an amplitude less than the truncation
> > error, it will always be approximately equal to zero.
>
> > Numerical maths is about approx
On Dec 7, 12:16 am, David Cournapeau wrote:
> If you can depend on IEEE 754 semantics, one relatively robust method
> is to use the number of representable floats between two numbers. The
> main advantage compared to the proposed methods is that it somewhat
> automatically takes into account the a
On Dec 6, 7:34 pm, Anton81 wrote:
> I do some linear algebra and whenever the prefactor of a vector turns
> out to be zero, I want to remove it.
Hmm. Comparing against zero is something of a special case. So you'd
almost certainly be doing an 'if abs(x) < tol: ...' check, but the
question is wh
On Sun, 06 Dec 2009 14:54:37 -0800, Carl Banks wrote:
> (I remember once struggling in a homework assignment over seemingly
> large discrepancies in a calculation I was doing, until i realized that
> the actual numbers were on the scale of 10**11, and the difference was
> around 10**1, so it reall
On Dec 6, 1:48 pm, sturlamolden wrote:
> On 6 Des, 21:52, r0g wrote:
>
> > > .> Right. Using abs(x-y) < eps is the way to go.
> > > .>
> > > .> Raymond
>
> > > This only works when abs(x) and abs(y) are larger that eps, but not
> > > too much larger.
>
> > Okay, I'm confused now... I thought the
Carl Banks wrote:
On Dec 6, 11:34 am, Anton81 wrote:
I do some linear algebra and whenever the prefactor of a vector turns
out to be zero, I want to remove it.
I'd like to keep the system comfortable. So basically I should write a
new class for numbers that has it's own __eq__ operator?
I
On Sun, Dec 6, 2009 at 1:46 AM, Mark Dickinson wrote:
> On Dec 5, 3:37 pm, Anton81 wrote:
>> I'd like to do calculations with floats and at some point equality of
>> two number will be checked.
>> What is the best way to make sure that equality of floats will be
>> detected, where I assume that m
On Dec 6, 4:54 pm, Carl Banks wrote:
> On Dec 6, 11:34 am, Anton81 wrote:
>
> > I do some linear algebra and whenever the prefactor of a vector turns
> > out to be zero, I want to remove it.
>
> > I'd like to keep the system comfortable. So basically I should write a
> > new class for numbers tha
On Dec 6, 11:34 am, Anton81 wrote:
> I do some linear algebra and whenever the prefactor of a vector turns
> out to be zero, I want to remove it.
>
> I'd like to keep the system comfortable. So basically I should write a
> new class for numbers that has it's own __eq__ operator?
> Is there an exis
Anton81 wrote:
I do some linear algebra and whenever the prefactor of a vector turns
out to be zero, I want to remove it.
I'd like to keep the system comfortable. So basically I should write a
new class for numbers that has it's own __eq__ operator?
Is there an existing module for that?
Y
On 6 Des, 21:52, r0g wrote:
> > .> Right. Using abs(x-y) < eps is the way to go.
> > .>
> > .> Raymond
>
> > This only works when abs(x) and abs(y) are larger that eps, but not
> > too much larger.
>
> Okay, I'm confused now... I thought them being larger was entirely the
> point.
Yes. dbd got
dbd wrote:
> On Dec 6, 1:12 am, Raymond Hettinger wrote:
>> On Dec 5, 11:42 pm, Tim Roberts wrote:
>>
>>> Raymond Hettinger wrote:
if not round(x - y, 6): ...
>>> That's a dangerous suggestion. It only works if x and y happen to be
>>> roughly in the range of integers.
> .>
> .> Right.
I do some linear algebra and whenever the prefactor of a vector turns
out to be zero, I want to remove it.
I'd like to keep the system comfortable. So basically I should write a
new class for numbers that has it's own __eq__ operator?
Is there an existing module for that?
--
http://mail.python.o
On Dec 6, 1:12 am, Raymond Hettinger wrote:
> On Dec 5, 11:42 pm, Tim Roberts wrote:
>
> > Raymond Hettinger wrote:
>
> > > if not round(x - y, 6): ...
>
> > That's a dangerous suggestion. It only works if x and y happen to be
> > roughly in the range of integers.
.>
.> Right. Using abs(x-y)
On Dec 5, 11:42 pm, Tim Roberts wrote:
> Raymond Hettinger wrote:
>
> > if not round(x - y, 6): ...
>
> That's a dangerous suggestion. It only works if x and y happen to be
> roughly in the range of integers.
Right. Using abs(x-y) < eps is the way to go.
Raymond
--
http://mail.python.org/
Raymond Hettinger wrote:
>
> if not round(x - y, 6): ...
That's a dangerous suggestion. It only works if x and y happen to be
roughly in the range of integers.
For example, here x and y are within roundoff error of each other, but
round doesn't know it:
>>> x=1e32
>>> y=x+1e16
>>> x-
On 5 Des, 16:37, Anton81 wrote:
> I'd like to do calculations with floats and at some point equality of
> two number will be checked.
> What is the best way to make sure that equality of floats will be
> detected, where I assume that mismatches beyond a certain point are
> due to truncation errors
On Dec 5, 12:56 pm, Mark Dickinson wrote:
> On Dec 5, 8:25 pm, Raymond Hettinger wrote:
>
> > On Dec 5, 7:37 am, Anton81 wrote:
>
> > > I'd like to do calculations with floats and at some point equality of
> > > two number will be checked.
> > > What is the best way to make sure that equality of
On Dec 5, 8:25 pm, Raymond Hettinger wrote:
> On Dec 5, 7:37 am, Anton81 wrote:
>
> > I'd like to do calculations with floats and at some point equality of
> > two number will be checked.
> > What is the best way to make sure that equality of floats will be
> > detected, where I assume that misma
On Dec 5, 7:37 am, Anton81 wrote:
> I'd like to do calculations with floats and at some point equality of
> two number will be checked.
> What is the best way to make sure that equality of floats will be
> detected, where I assume that mismatches beyond a certain point are
> due to truncation erro
On Dec 5, 3:37 pm, Anton81 wrote:
> I'd like to do calculations with floats and at some point equality of
> two number will be checked.
> What is the best way to make sure that equality of floats will be
> detected, where I assume that mismatches beyond a certain point are
> due to truncation erro
27 matches
Mail list logo
