From: r0g on
dbd wrote:
> On Dec 6, 1:12 am, Raymond Hettinger <pyt...(a)rcn.com> wrote:
>> On Dec 5, 11:42 pm, Tim Roberts <t...(a)probo.com> wrote:
>>
>>> Raymond Hettinger <pyt...(a)rcn.com> 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
>
> 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. At what point can they become too large? Isn't eps entirely
arbitrary anyway?



>
> Mark's suggestion is longer, but it works. The downside is it requires
> you to think about the scale and accuracy of your application.
>


Shouldn't one be doing that in any case??


Roger.
From: sturlamolden on
On 6 Des, 21:52, r0g <aioe....(a)technicalbloke.com> 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 it wrong. If both a smaller than eps, the absolute
difference is smaller than eps, so they are considered equal.





From: Dave Angel on


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?
>
>
>
You have to define your own "comfortable." But if it's zero you're
checking for, then I most certainly wouldn't try to hide it inside a
"number class." Most such formulas go ballistic when you get near zero.

The definition of 'close enough" is very context dependent, and
shouldn't be hidden at too low a level. But your mileage may vary.

For example, in your case, you might want to check that the prefactor is
much smaller than the average (of the abs values) of the vector
elements. Enough orders of magnitude smaller, and you call it equal to
zero.

DaveA

From: Carl Banks on
On Dec 6, 11:34 am, Anton81 <gerenu...(a)googlemail.com> 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?

I highly recommend against it; among other things it invalidates the
transitive property of equality:

"If a == b and b == c, then a == c."

It will also make the number non-hashable, and have several other
negative consequences. Plus, it's not something that's never
foolproof. What numbers are close enought to be condidered "equal"
depends on the calculations.

(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 really didn't matter.)



Carl Banks
From: TheSeeker on
On Dec 6, 4:54 pm, Carl Banks <pavlovevide...(a)gmail.com> wrote:
> On Dec 6, 11:34 am, Anton81 <gerenu...(a)googlemail.com> 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?
>
> I highly recommend against it; among other things it invalidates the
> transitive property of equality:
>
> "If a == b and b == c, then a == c."
>
> It will also make the number non-hashable, and have several other
> negative consequences.    What numbers are close enought to be condidered "equal"
> depends on the calculations.
>
> (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 really didn't matter.)
>
> Carl Banks

Maybe it's the gin, but
"Plus, it's not something that's never foolproof.'

+1 QOTW

Cheers,
TheSeeker