bill <(E-Mail Removed)> wrote in comp.lang.perl.misc:

> In <ddi69e$o30$(E-Mail Removed)-Berlin.DE>

> (E-Mail Removed)-berlin.de (Anno Siegel) writes:

>

> >bill <(E-Mail Removed)> wrote in comp.lang.perl.misc:

> >> In <ddhtkk$iuq$(E-Mail Removed)-Berlin.DE>

> >> (E-Mail Removed)-berlin.de (Anno Siegel) writes:
[snip comparison of floats]

> >Something like that "binary eq" could probably be written (in Perl

> >or otherwise), but what would it gain? In effect, it gives you a

> >choice of epsilons that are powers of two, instead of powers of ten

> >like rounding. The practical difference is small.

>

> The effect is to leave it up to the user to decide, instead of

> forcing him/her to rationalize a suboptimal situation after the

> fact. The phrase "practical difference" makes a huge blanket

> assumption about the task at hand. What's "good enough"? 10%?

> 1%? 0.0001%?
Hmmm? Even the rounding approach gives you the choice of exactly

that? I don't get the big diff. The right approach to float

comparison is an epsilon approach, where (in principle) epsilon

must be specified for each comparison. The same goes for rounding,

whether done in decimal or binary. In principle, the number of

places to round must be specified on each comparison. There's your

chance to decide what's good enough. Nothing is being forced on you.

The rounding approach is basically equivalent to epsilon values

that are powers of ten (or two), just more convenient than a

specific comparison procedure. You get fewer choices of epsilon,

but you don't need that many.

> The answer obviously depends on the application, and

> my philosophy is to give as much power to the user as possible.

> In this case, the best that can be done is to allow a binary

> specification of precision, and let the user avail him/herself of

> this as desired.
Nah... that would depend on the odds and ends of the local representation

of floating point numbers. That's not a good thing for a program to

depend on. Specify the "range of equality" numerically, explicitly

or implicitly through rounding.

> I suppose "binary eq" could be written using pack/unpack, but even

> though I've been programming Perl for 8+ years and consider myself

> pretty proficient at it, I remain a pack/unpack illiterate. For

> some reason, even after I study pack/unpack intensively, its

> operations seem mysterious to me, and therefore my minds retains

> whatever I learn about it for roughly one nanosecond. Maybe I

> should just read the perl source to finally understand it.
That's not the way to understand pack/unpack. To learn about them,

play with them. Few people learn all the pack/unpack specifications

by heart, that's something to look up in each case. But it's useful

to acquaint oneself with the basic possibilities, so write a few test

cases and see what you get. It isn't used often, but for some things

it is just the ticket. One of them is reading of fixed-column data,

another (somewhat surprisingly) is counting the one-bits in a bit

string. Pack/unpack might be used in a "binary compare", but not

before we know what exactly it does.

Anno

--

If you want to post a followup via groups.google.com, don't use

the broken "Reply" link at the bottom of the article. Click on

"show options" at the top of the article, then click on the

"Reply" at the bottom of the article headers.