Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #46060 > unrolled thread

Short-circuit Logic

Back to article view | Back to comp.lang.python

Contents

  Short-circuit Logic Ahmed Abdulshafy <abdulshafy@gmail.com> - 2013-05-26 04:11 -0700
    Re: Short-circuit Logic Roy Smith <roy@panix.com> - 2013-05-26 07:38 -0400
    Re: Short-circuit Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-26 12:13 +0000
      Re: Short-circuit Logic Ahmed Abdulshafy <abdulshafy@gmail.com> - 2013-05-27 13:11 -0700
        Re: Short-circuit Logic Nobody <nobody@nowhere.com> - 2013-05-28 01:10 +0100
          Re: Short-circuit Logic Ahmed Abdulshafy <abdulshafy@gmail.com> - 2013-05-28 01:39 -0700
            RE: Short-circuit Logic Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-28 12:32 +0300
            Re: Short-circuit Logic Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-05-28 12:45 +0100
            Re: Short-circuit Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-28 13:51 +0000
              Re: Short-circuit Logic Grant Edwards <invalid@invalid.invalid> - 2013-05-28 15:14 +0000
                Re: Short-circuit Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-28 15:55 +0000
        Re: Short-circuit Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-28 13:48 +0000
          Re: Short-circuit Logic Chris Angelico <rosuav@gmail.com> - 2013-05-29 00:01 +1000
          Re: Short-circuit Logic Ahmed Abdulshafy <abdulshafy@gmail.com> - 2013-05-29 07:27 -0700
            Re: Short-circuit Logic Chris Angelico <rosuav@gmail.com> - 2013-05-30 00:32 +1000
            Re: Short-circuit Logic rusi <rustompmody@gmail.com> - 2013-05-29 07:33 -0700
              Re: Short-circuit Logic Ian Kelly <ian.g.kelly@gmail.com> - 2013-05-29 10:50 -0600
                Re: Short-circuit Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-30 02:28 +0000
                  Re: Short-circuit Logic Chris Angelico <rosuav@gmail.com> - 2013-05-30 13:45 +1000
                    Re: Short-circuit Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-30 05:42 +0000
                      Re: Short-circuit Logic Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-05-30 10:22 +0300
                        Re: Short-circuit Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-30 08:29 +0000
                          Re: Short-circuit Logic Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-05-30 12:07 +0300
                            Re: Short-circuit Logic Nobody <nobody@nowhere.com> - 2013-05-30 23:55 +0100
                          Re: Short-circuit Logic Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-05-30 19:31 -0400
                          Re: Short-circuit Logic Stefan Drees <stefan@drees.name> - 2013-05-31 17:34 +0200
                        Re: Short-circuit Logic Roy Smith <roy@panix.com> - 2013-05-30 08:48 -0400
                          Re: Short-circuit Logic Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-05-30 19:38 -0400
                            Re: Short-circuit Logic Nobody <nobody@nowhere.com> - 2013-05-31 02:10 +0100
                              Re: Short-circuit Logic Roy Smith <roy@panix.com> - 2013-05-30 21:21 -0400
                              Re: Short-circuit Logic Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-05-30 21:57 -0400
                              Re: Short-circuit Logic Michael Torrie <torriem@gmail.com> - 2013-05-30 21:33 -0600
                          RE: Short-circuit Logic Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-31 03:03 +0300
                      Re: Short-circuit Logic Chris Angelico <rosuav@gmail.com> - 2013-05-30 18:29 +1000
                      RE: Short-circuit Logic Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-31 00:03 +0300
                        Re: Short-circuit Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-31 05:13 +0000
                          RE: Short-circuit Logic Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-31 09:42 +0300
                            Re: Short-circuit Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-31 08:11 +0000
                          Re: Short-circuit Logic Chris Angelico <rosuav@gmail.com> - 2013-05-31 17:09 +1000
                            Re: Short-circuit Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-31 08:45 +0000
                              Re: Short-circuit Logic Roy Smith <roy@panix.com> - 2013-05-31 09:20 -0400
                              RE: Short-circuit Logic Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-06-01 10:23 +0300
                  Re: Short-circuit Logic 88888 Dihedral <dihedral88888@gmail.com> - 2013-05-30 20:11 -0700
              Re: Short-circuit Logic Dave Angel <davea@davea.name> - 2013-05-29 20:23 -0400
                Re: Short-circuit Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-30 05:20 +0000
            Re: Short-circuit Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-30 05:10 +0000
              Re: Short-circuit Logic Chris Angelico <rosuav@gmail.com> - 2013-05-30 15:22 +1000
                Re: Short-circuit Logic Roy Smith <roy@panix.com> - 2013-05-30 08:40 -0400
                  Re: Short-circuit Logic Chris Angelico <rosuav@gmail.com> - 2013-05-30 22:58 +1000
                    Re: Short-circuit Logic rusi <rustompmody@gmail.com> - 2013-05-30 09:58 -0700
                      Re: Short-circuit Logic Chris Angelico <rosuav@gmail.com> - 2013-05-31 03:23 +1000
                      Re: Short-circuit Logic Rick Johnson <rantingrickjohnson@gmail.com> - 2013-05-30 17:13 -0700
                        Re: Short-circuit Logic Chris Angelico <rosuav@gmail.com> - 2013-05-31 12:29 +1000
                  Re: Short-circuit Logic Ethan Furman <ethan@stoneleaf.us> - 2013-05-30 08:02 -0700
                  Re: Short-circuit Logic Chris Angelico <rosuav@gmail.com> - 2013-05-31 01:56 +1000
                    Re: Short-circuit Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-30 16:40 +0000
                      Re: Short-circuit Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-30 19:22 +0000
                        Re: Short-circuit Logic Chris Angelico <rosuav@gmail.com> - 2013-05-31 07:46 +1000
                  Re: Short-circuit Logic Ethan Furman <ethan@stoneleaf.us> - 2013-05-30 09:30 -0700
                Re: Short-circuit Logic Neil Cerutti <neilc@norwich.edu> - 2013-05-30 19:30 +0000
                  Re: Short-circuit Logic Ian Kelly <ian.g.kelly@gmail.com> - 2013-05-30 13:49 -0600
    Re: Short-circuit Logic Terry Jan Reedy <tjreedy@udel.edu> - 2013-05-26 16:19 -0400
      Re: Short-circuit Logic Roy Smith <roy@panix.com> - 2013-05-26 16:22 -0400
        Re: Short-circuit Logic Terry Jan Reedy <tjreedy@udel.edu> - 2013-05-26 17:28 -0400
        Re: Short-circuit Logic Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-05-27 00:40 +0000
          Re: Short-circuit Logic Cameron Simpson <cs@zip.com.au> - 2013-05-27 11:57 +1000
          Re: Short-circuit Logic rusi <rustompmody@gmail.com> - 2013-05-26 21:44 -0700
          Re: Short-circuit Logic Vito De Tullio <vito.detullio@gmail.com> - 2013-05-27 06:59 +0200
    Re: Short-circuit Logic Nobody <nobody@nowhere.com> - 2013-05-27 18:52 +0100
    Re: Short-circuit Logic Ahmed Abdulshafy <abdulshafy@gmail.com> - 2013-05-27 13:08 -0700
      Re: Short-circuit Logic Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-05-27 21:36 -0400

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#46440

Steven D'Aprano writes:

> On Thu, 30 May 2013 13:45:13 +1000, Chris Angelico wrote:
> 
> > Let's suppose someone is told to compare floating point numbers by
> > seeing if the absolute value of the difference is less than some
> > epsilon.
> 
> Which is usually the wrong way to do it! Normally one would prefer
> *relative* error, not absolute:
> 
> # absolute error:
> abs(a - b) < epsilon
> 
> 
> # relative error:
> abs(a - b)/a < epsilon
> 

...

I wonder why floating-point errors are not routinely discussed in
terms of ulps (units in last position). There is a recipe for
calculating the difference of two floating point numbers in ulps, and
it's possible to find the previous or next floating point number, but
I don't know of any programming language having built-in support for
these.

Why isn't this considered the most natural measure of a floating point
result being close to a given value? The meaning is roughly this: how
many floating point numbers there are between these two.

"close enough" if abs(ulps(a, b)) < 3 else "not close enough"

"equal" if ulps(a, b) == 0 else "not equal"

There must be some subtle technical issues here, too, but it puzzles
me that this measure of closeness is not often even discussed when
absolute and relative error are discussed - and computed using the
same approximate arithmetic whose accuracy is being measured. Scary.

Got light?

[toc] | [prev] | [next] | [standalone]

#46443

On Thu, 30 May 2013 10:22:02 +0300, Jussi Piitulainen wrote:

> I wonder why floating-point errors are not routinely discussed in terms
> of ulps (units in last position). There is a recipe for calculating the
> difference of two floating point numbers in ulps, and it's possible to
> find the previous or next floating point number, but I don't know of any
> programming language having built-in support for these.

That is an excellent question!

I think it is because the traditional recipes for "close enough" equality 
either pre-date any standardization of floating point types, or because 
they're written by people who are thinking about abstract floating point 
numbers and not considering the implementation.

Prior to most compiler and hardware manufacturers standardizing on IEEE 
754, there was no real way to treat float's implementation  in a machine 
independent way. Every machine laid their floats out differently, or used 
different number of bits. Some even used decimal, and in the case of a 
couple of Russian machines, trinary. (Although that's going a fair way 
back.)

But we now have IEEE 754, and C has conquered the universe, so it's 
reasonable for programming languages to offer an interface for accessing 
floating point objects in terms of ULPs. Especially for a language like 
Python, which only has a single float type.

I have a module that works with ULPs. I may clean it up and publish it. 
Would there be interest in seeing it in the standard library?


> Why isn't this considered the most natural measure of a floating point
> result being close to a given value? The meaning is roughly this: how
> many floating point numbers there are between these two.

There are some subtleties here also. Firstly, how many ULP should you 
care about? Three, as you suggest below, is awfully small, and chances 
are most practical, real-world calculations could not justify 3 ULP. 
Numbers that we normally care about, like "0.01mm", probably can justify 
thousands of ULP when it comes to C-doubles, which Python floats are.

Another subtlety: small-but-positive numbers are millions of ULP away 
from small-but-negative numbers. Also, there are issues to do with +0.0 
and -0.0, NANs and the INFs.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#46445

Steven D'Aprano writes:

> On Thu, 30 May 2013 10:22:02 +0300, Jussi Piitulainen wrote:
> 
> > I wonder why floating-point errors are not routinely discussed in
> > terms of ulps (units in last position). There is a recipe for
> > calculating the difference of two floating point numbers in ulps,
> > and it's possible to find the previous or next floating point
> > number, but I don't know of any programming language having
> > built-in support for these.

...

> But we now have IEEE 754, and C has conquered the universe, so it's
> reasonable for programming languages to offer an interface for
> accessing floating point objects in terms of ULPs. Especially for a
> language like Python, which only has a single float type.

Yes, that's what I'm thinking, that there is now a ubiquitous floating
point format or two, so the properties of the format could be used.

> I have a module that works with ULPs. I may clean it up and publish it. 
> Would there be interest in seeing it in the standard library?

Yes, please.

> There are some subtleties here also. Firstly, how many ULP should
> you care about? Three, as you suggest below, is awfully small, and
> chances are most practical, real-world calculations could not
> justify 3 ULP.  Numbers that we normally care about, like "0.01mm",
> probably can justify thousands of ULP when it comes to C-doubles,
> which Python floats are.

I suppose this depends on the complexity of the process and the amount
of data that produced the numbers of interest. Many individual
floating point operations are required to be within an ulp or two of
the mathematically correct result, I think, and the rounding error
when parsing a written representation of a number should be similar.
Either these add up to produce large errors, or the computation is
approximate in other ways in addition to using floating point.

One could develop a kind of sense for such differences. Ulps could be
a tangible measure when comparing different algorithms. (That's what I
tried to do with them in the first place. And that's how I began to
notice their absence when floating point errors are discussed.)

> Another subtlety: small-but-positive numbers are millions of ULP
> away from small-but-negative numbers. Also, there are issues to do
> with +0.0 and -0.0, NANs and the INFs.

The usual suspects ^_^ and no reason to dismiss the ulp when the
competing kinds of error have their corresponding subtleties. A matter
of education, I'd say.

Thank you much for an illuminating discussion.

[toc] | [prev] | [next] | [standalone]

#46551

On Thu, 30 May 2013 12:07:40 +0300, Jussi Piitulainen wrote:

> I suppose this depends on the complexity of the process and the amount
> of data that produced the numbers of interest. Many individual
> floating point operations are required to be within an ulp or two of
> the mathematically correct result, I think, and the rounding error
> when parsing a written representation of a number should be similar.

Elementary operations (+, -, *, /, %, sqrt) are supposed to be within
+/- 0.5 ULP (for round-to-nearest), i.e. the actual result should be the
closest representable value to the exact result.

Transcendental functions should ideally be within +/- 1 ULP, i.e. the
actual result should be one of the two closest representable values to the
exact result. Determining the closest value isn't always feasible due to
the "table-maker's dilemma", i.e. the fact that regardless of the number
of digits used for intermediate results, the upper and lower bounds
can remain on opposite sides of the dividing line.

[toc] | [prev] | [next] | [standalone]

#46558

On 30 May 2013 08:29:41 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following in
gmane.comp.python.general:

> Prior to most compiler and hardware manufacturers standardizing on IEEE 
> 754, there was no real way to treat float's implementation  in a machine 
> independent way. Every machine laid their floats out differently, or used 
> different number of bits. Some even used decimal, and in the case of a 
> couple of Russian machines, trinary. (Although that's going a fair way 
> back.)
>
	Xerox Sigma used an exponent that moved in "16", so a "normalized"
binary mantissa could have up to three leading 0 bits, unlike so many
others that assume a normalized mantissa will have a 1 bit (and then go
one step further and don't store that leading 1 bit <G>).
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#46606

On 2013-05-30 08:29:41 +0000, Steven D'Aprano said:
> On Thu, 30 May 2013 10:22:02 +0300, Jussi Piitulainen wrote:
>> I wonder why floating-point errors are not routinely discussed in terms
>> of ulps (units in last position). ...
> That is an excellent question! ...
> I have a module that works with ULPs. I may clean it up and publish it.
> Would there be interest in seeing it in the standard library? ...

I am definitely interested seeing this in the python standard library.
But as I continued to read the lines following your proposal and the 
excellent article from Bruce pointed to by Carlos on this thread, maybe 
a package on pypi first grounding somewhat the presumably massive 
discussion thread on python-ideas :-?)

All the best,

Stefan.

[toc] | [prev] | [next] | [standalone]

#46479

In article <qotk3mhx78l.fsf@ruuvi.it.helsinki.fi>,
 Jussi Piitulainen <jpiitula@ling.helsinki.fi> wrote:

> I wonder why floating-point errors are not routinely discussed in
> terms of ulps (units in last position).

Analysis of error is a complicated topic (and is much older than digital 
computers).  These sorts of things come up in the real world, too.  For 
example, let's say I have two stakes driven into the ground 1000 feet 
apart.  One of them is near me and is my measurement datum.

I want to drive a third stake which is 1001 feet away from the datum.  
Do I measure 1 foot from the second stake, or do I take out my 
super-long tape measure and measure 1001 feet from the datum?

[toc] | [prev] | [next] | [standalone]

#46559

On Thu, 30 May 2013 08:48:59 -0400, Roy Smith <roy@panix.com> declaimed
the following in gmane.comp.python.general:

> 
> Analysis of error is a complicated topic (and is much older than digital 
> computers).  These sorts of things come up in the real world, too.  For 
> example, let's say I have two stakes driven into the ground 1000 feet 
> apart.  One of them is near me and is my measurement datum.
> 
> I want to drive a third stake which is 1001 feet away from the datum.  
> Do I measure 1 foot from the second stake, or do I take out my 
> super-long tape measure and measure 1001 feet from the datum?

	On the same azimuth? Using the "super long tape" and ensuring it
traverses the 1000 foot stake is probably going to be most accurate --
you only have the uncertainty of the positioning of the tape on the
datum, and the small uncertainty of azimuth over the 1000 foot stake.
And even the azimuth error isn't contributing to the distance error.

	Measuring 1 foot from the 1000 foot stake leaves you with any error
from datum to the 1000 foot, plus any error from the 1000 foot, PLUS any
azimuth error which would contribute to shortening the datum distance.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#46564

On Thu, 30 May 2013 19:38:31 -0400, Dennis Lee Bieber wrote:

> 	Measuring 1 foot from the 1000 foot stake leaves you with any error
> from datum to the 1000 foot, plus any error from the 1000 foot, PLUS any
> azimuth error which would contribute to shortening the datum distance.

First, let's ignore azimuthal error.

If you measure both distances from the same origin, and you have a
measurement error of 0.1% (i.e. 1/1000), then the 1000' measurement will
actually be between 999' and 1001', while the 1001' measurement will be
between 1000' and 1002' (to the nearest whole foot).

Meaning that the distance from the 1000' stake to the 1001' stake could be
anywhere between -1' and 3' (i.e. the 1001' stake could be measured as
being closer than the 1000' stake).

This is why technical drawings which include regularly-spaced features
will normally specify the positions of features relative to their
neighbours instead of (or as well as) relative to some origin.

When you're dealing with relative error, the obvious question is
"relative to what?".

[toc] | [prev] | [next] | [standalone]

#46565

In article <pan.2013.05.31.01.09.55.109000@nowhere.com>,
 Nobody <nobody@nowhere.com> wrote:

> On Thu, 30 May 2013 19:38:31 -0400, Dennis Lee Bieber wrote:
> 
> > 	Measuring 1 foot from the 1000 foot stake leaves you with any error
> > from datum to the 1000 foot, plus any error from the 1000 foot, PLUS any
> > azimuth error which would contribute to shortening the datum distance.
> 
> First, let's ignore azimuthal error.
> 
> If you measure both distances from the same origin, and you have a
> measurement error of 0.1% (i.e. 1/1000), then the 1000' measurement will
> actually be between 999' and 1001', while the 1001' measurement will be
> between 1000' and 1002' (to the nearest whole foot).
> 
> Meaning that the distance from the 1000' stake to the 1001' stake could be
> anywhere between -1' and 3' (i.e. the 1001' stake could be measured as
> being closer than the 1000' stake).
> 
> This is why technical drawings which include regularly-spaced features
> will normally specify the positions of features relative to their
> neighbours instead of (or as well as) relative to some origin.

Not to mention "Do not scale drawing" warnings.  Do they still put that 
on drawings?  It was standard practice back when I was learning drafting.

> When you're dealing with relative error, the obvious question is
> "relative to what?".

Exactly.  Most programmers are very poorly training in these sorts of 
things (not to mention crypto, UX, etc).  I put myself in that camp too.  
I know just enough about floating point to understand that I don't 
really know what I'm doing.  I would never write a program where 
numerical accuracy was critical (say, stress analysis of a new airframe 
or a nuclear power plant control system) without having somebody who 
really knew that stuff on the team.

[toc] | [prev] | [next] | [standalone]

#46566

On Fri, 31 May 2013 02:10:03 +0100, Nobody <nobody@nowhere.com>
declaimed the following in gmane.comp.python.general:

> 
> If you measure both distances from the same origin, and you have a
> measurement error of 0.1% (i.e. 1/1000), then the 1000' measurement will
> actually be between 999' and 1001', while the 1001' measurement will be
> between 1000' and 1002' (to the nearest whole foot).
>
	I presumed the /same/ tape measure was used for the initial 1000 ft
measurement, and that this tape measure is fairly in-elastic... Such
that even your 0.1% error is constant in the first 1000 foot -- that is,
any error in the original 1000 feet is reproduced by the use of the same
tape. And that, in turn, would mean only the last foot difference would
be off, and the error would be in scale (if the 1000ft is 0.1% short,
the 1001ft is also 0.1% short of the total); but not that the first
distance could be short and the second could be long.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#46571

On 05/30/2013 07:10 PM, Nobody wrote:
> This is why technical drawings which include regularly-spaced features
> will normally specify the positions of features relative to their
> neighbours instead of (or as well as) relative to some origin.

If I am planting trees, putting in fence posts, or drilling lots of
little holes in steel, I am actually more likely to measure from the
origin (or one arbitrary position).  I trust that the errors
accumulating as the tape measure marks were printed on the tape is less
than the error I'd accumulate by digging a hole, and measuring from
there to the next hole.  And definitely when drilling a series of holes
I'll never measure hole to hole to mark.  If I measure from the origin
than any error for the hole is limited to itself as much as possible
rather than passing on the error to subsequent hole positions.  If I was
making a server rack, for example, having the holes consistently near
their desired position is necessary.  Tolerances are such that my hole
can be off by as much as a 1/16" of inch of my desired position and it
would still be fine, but not if each hole was off by an additional
1/16".  I guess what I've described is accuracy vs precision.  In the
case of the server rack accuracy is important, and precision can be more
coarse depending on the screw size and the mount type (threaded hole vs
square hole with snap-in nut).

[toc] | [prev] | [next] | [standalone]

#46562

----------------------------------------
> To: python-list@python.org
> From: wlfraed@ix.netcom.com
> Subject: Re: Short-circuit Logic
> Date: Thu, 30 May 2013 19:38:31 -0400
>
> On Thu, 30 May 2013 08:48:59 -0400, Roy Smith <roy@panix.com> declaimed
> the following in gmane.comp.python.general:
>
>>
>> Analysis of error is a complicated topic (and is much older than digital
>> computers). These sorts of things come up in the real world, too. For
>> example, let's say I have two stakes driven into the ground 1000 feet
>> apart. One of them is near me and is my measurement datum.
>>
>> I want to drive a third stake which is 1001 feet away from the datum.
>> Do I measure 1 foot from the second stake, or do I take out my
>> super-long tape measure and measure 1001 feet from the datum?
>
> On the same azimuth? Using the "super long tape" and ensuring it
> traverses the 1000 foot stake is probably going to be most accurate --
> you only have the uncertainty of the positioning of the tape on the
> datum, and the small uncertainty of azimuth over the 1000 foot stake.
> And even the azimuth error isn't contributing to the distance error.
>
> Measuring 1 foot from the 1000 foot stake leaves you with any error
> from datum to the 1000 foot, plus any error from the 1000 foot, PLUS any
> azimuth error which would contribute to shortening the datum distance.

Just because you have more causes of error doesn't mean you have lesser accurate measures.

If fact, errors may compensate each other. It all depends on the bias (accuracy) and variation (precision) involved in the measurements you are considering.

> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
>
> --
> http://mail.python.org/mailman/listinfo/python-list 		 	   		  

[toc] | [prev] | [next] | [standalone]

#46442

On Thu, May 30, 2013 at 3:42 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Thu, 30 May 2013 13:45:13 +1000, Chris Angelico wrote:
>
>> Let's suppose someone is told to compare floating point numbers by
>> seeing if the absolute value of the difference is less than some
>> epsilon.
>
> Which is usually the wrong way to do it! Normally one would prefer
> *relative* error, not absolute:
>
> # absolute error:
> abs(a - b) < epsilon
>
>
> # relative error:
> abs(a - b)/a < epsilon

I was picking an epsilon based on a, though, which comes to pretty
much the same thing as the relative error calculation you're using.

> But using relative error also raises questions:
>
> - what if a is negative?
>
> - why relative to a instead of relative to b?
>
> - what if a is zero?
>
> The first, at least, is easy to solve: take the absolute value of a.

One technique I saw somewhere is to use the average of a and b. But
probably better is to take the lower absolute value (ie the larger
epsilon). However, there's still the question of what epsilon should
be - what percentage of a or b you take to mean equal - and that one
is best answered by looking at the original inputs.

Take these guys, for instance. Doing the same thing I was, only with
more accuracy.

http://www.youtube.com/watch?v=ZNiRzZ66YN0

ChrisA

[toc] | [prev] | [next] | [standalone]

#46543

----------------------------------------
> From: steve+comp.lang.python@pearwood.info
> Subject: Re: Short-circuit Logic
> Date: Thu, 30 May 2013 05:42:17 +0000
> To: python-list@python.org
[...]
> Here's another way, mathematically equivalent (although not necessarily
> equivalent using floating point computations!) which avoids the divide-by-
> zero problem:
>
> abs(a - b) < epsilon*a

That's wrong! If abs(a) < abs(a-b)/epsilon you will break the commutative law. For example:

import sys
eps = sys.float_info.epsilon
def almost_equalSD(a,b):
    return abs(a-b) < eps*a

#special case
a=1
b=1/(1-eps)
almost_equalSD(a,b) == almost_equalSD(b,a)

Returns False.

This discussion reminded me of TAOCP and I paid a visit and bring the following functions:


#Floating Point Comparison Operations
#Knuth, Donald (1981). The Art of Computer Programming. 2nd ed. Vol. 2. p. 218. Addison-Wesley. ISBN 0-201-03822-6.
import sys

#floating point comparison: u ≺ v(ε) "definitely less than" (definition 21)
def fpc_dlt(u,v,eps=sys.float_info.epsilon):
    au=abs(u)
    av=abs(v)
    return (v-u)> (eps*(au if au>av else av))  # v-u> ε*max(|u|,|v|)

#floating point comparison: u ~ v(ε) "approximately equal to" (definition 22)
def fpc_aeq(u,v,eps=sys.float_info.epsilon):
    au=abs(u)
    av=abs(v)
    return abs(v-u) <= (eps*(au if au>av else av))  # |v-u| <= ε*max(|u|,|v|)

#floating point comparison: u ≻ v(ε) "definitely greater than" (definition 23)
def fpc_dgt(u,v,eps=sys.float_info.epsilon):
    au=abs(u)
    av=abs(v)
    return (u-v)> (eps*(au if au>av else av))  # u-v> ε*max(|u|,|v|)

#floating point comparison: u ≈ v(ε) "essentially equal to" (definition 24)
def fpc_eeq(u,v,eps=sys.float_info.epsilon):
    au=abs(u)
    av=abs(v)
    return abs(v-u) <= (eps*(au if au<av else av))  # |v-u| <= ε*min(|u|,|v|)


I've tried to make it look a bit pythonic. Please let me know if it can be improved. ;)

So, if you try the following you get the correct answer:

#special case
a=1
b=1/(1-eps)
fpc_aeq(a,b) == fpc_aeq(b,a)


>
> Whichever method you choose, there are gotchas to watch out for.
>
>> http://xkcd.com/1047/
>
> Nice!
>
>
> --
> Steven
> --
> http://mail.python.org/mailman/listinfo/python-list 		 	   		  

[toc] | [prev] | [next] | [standalone]

#46574

On Fri, 31 May 2013 00:03:13 +0300, Carlos Nepomuceno wrote:

> ----------------------------------------
>> From: steve+comp.lang.python@pearwood.info Subject: Re: Short-circuit
>> Logic
>> Date: Thu, 30 May 2013 05:42:17 +0000 To: python-list@python.org
> [...]
>> Here's another way, mathematically equivalent (although not necessarily
>> equivalent using floating point computations!) which avoids the
>> divide-by- zero problem:
>>
>> abs(a - b) < epsilon*a
> 
> That's wrong! If abs(a) < abs(a-b)/epsilon you will break the
> commutative law. For example:

What makes you think that the commutative law is relevant here?

Many things break the commutative law, starting with division and 
subtraction:

    20 - 10 != 10 - 20

    1/2 != 2/1

Most comparison operators other than equality and inequality:

    (23 < 42) != (42 < 23)

String concatenation:

    "Hello" + "World" != "World" + "Hello"

Many operations in the real world:

    put on socks, then shoes != put on shoes, then socks.


But you are correct that approximately-equal using *relative* error is 
not commutative. (Absolute error, on the other hand, is commutative.) As 
I said, any form of "approximate equality" has gotchas. But this gotcha 
is simple to overcome: 

    abs(a -b) < eps*max(abs(a), abs(b))

(Knuth's "approximately equal to" which you give.)


> This discussion reminded me of TAOCP and I paid a visit and bring the
> following functions:

"TAOCP"?


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#46576

----------------------------------------
> From: steve+comp.lang.python@pearwood.info
> Subject: Re: Short-circuit Logic
> Date: Fri, 31 May 2013 05:13:51 +0000
> To: python-list@python.org
>
> On Fri, 31 May 2013 00:03:13 +0300, Carlos Nepomuceno wrote:
>
>> ----------------------------------------
>>> From: steve+comp.lang.python@pearwood.info Subject: Re: Short-circuit
>>> Logic
>>> Date: Thu, 30 May 2013 05:42:17 +0000 To: python-list@python.org
>> [...]
>>> Here's another way, mathematically equivalent (although not necessarily
>>> equivalent using floating point computations!) which avoids the
>>> divide-by- zero problem:
>>>
>>> abs(a - b) < epsilon*a
>>
>> That's wrong! If abs(a) < abs(a-b)/epsilon you will break the
>> commutative law. For example:
>
> What makes you think that the commutative law is relevant here?

How can't you see?

I'll requote a previous message:

}On Thu, 30 May 2013 13:45:13 +1000, Chris Angelico wrote:
} 
}> Let's suppose someone is told to compare floating point numbers by
}> seeing if the absolute value of the difference is less than some
}> epsilon. 
} 
}Which is usually the wrong way to do it! Normally one would prefer 
}*relative* error, not absolute:
 
Since we are considering Chris's supposition ("to compare floating point numbers") it's totally relevant to understand how that operation can be correctly implemented.


> Many things break the commutative law, starting with division and
> subtraction:
>
> 20 - 10 != 10 - 20
>
> 1/2 != 2/1
>
> Most comparison operators other than equality and inequality:
>
> (23 < 42) != (42 < 23)
>
> String concatenation:
>
> "Hello" + "World" != "World" + "Hello"
>
> Many operations in the real world:
>
> put on socks, then shoes != put on shoes, then socks.
>

That's is totally irrelevant in this case. The commutative law is essential to the equality operation.

> But you are correct that approximately-equal using *relative* error is
> not commutative. (Absolute error, on the other hand, is commutative.) As
> I said, any form of "approximate equality" has gotchas. But this gotcha
> is simple to overcome:
>
> abs(a -b) < eps*max(abs(a), abs(b))
>
> (Knuth's "approximately equal to" which you give.)
>
>
>> This discussion reminded me of TAOCP and I paid a visit and bring the
>> following functions:
>
> "TAOCP"?

The Art of Computer Programming[1]! An old book full of excellent stuff! A MUST READ!!!! ;)

http://www-cs-faculty.stanford.edu/~uno/taocp.html

[1] Knuth, Donald (1981). The Art of Computer Programming. 2nd ed. Vol. 2. p. 218. Addison-Wesley. ISBN 0-201-03822-6.

>
>
> --
> Steven
> --
> http://mail.python.org/mailman/listinfo/python-list 		 	   		  

[toc] | [prev] | [next] | [standalone]

#46580

On Fri, 31 May 2013 09:42:38 +0300, Carlos Nepomuceno wrote:

>> From: steve+comp.lang.python@pearwood.info Subject: Re: Short-circuit
>> Logic
>> Date: Fri, 31 May 2013 05:13:51 +0000 To: python-list@python.org
>>
>> On Fri, 31 May 2013 00:03:13 +0300, Carlos Nepomuceno wrote:
>>>> From: steve+comp.lang.python@pearwood.info Subject: Re: Short-circuit
>>>> Logic
>>>> Date: Thu, 30 May 2013 05:42:17 +0000 To: python-list@python.org
>>> [...]
>>>> Here's another way, mathematically equivalent (although not
>>>> necessarily equivalent using floating point computations!) which
>>>> avoids the divide-by- zero problem:
>>>>
>>>> abs(a - b) < epsilon*a
>>>
>>> That's wrong! If abs(a) < abs(a-b)/epsilon you will break the
>>> commutative law. For example:
>>
>> What makes you think that the commutative law is relevant here?
> 
> How can't you see?

I can ask the same thing about you. How can you see that it is not 
relevant?


> I'll requote a previous message:

Thanks, but that's entirely irrelevant. It says nothing about the 
commutative law.

[...]
> Since we are considering Chris's supposition ("to compare floating point
> numbers") it's totally relevant to understand how that operation can be
> correctly implemented.

Of course! But what does that have to do with the commutative law?


>> Many things break the commutative law, starting with division and
>> subtraction:
>>
>> 20 - 10 != 10 - 20
>>
>> 1/2 != 2/1
>>
>> Most comparison operators other than equality and inequality:
>>
>> (23 < 42) != (42 < 23)
[...]
> That's is totally irrelevant in this case. The commutative law is
> essential to the equality operation.

That's fine, but we're not talking about equality, we're talking about 
*approximately equality* or *almost equal*. Given the simple definition 
of relative error under discussion, the commutative law does not hold. 
The mere fact that it does not hold is no big deal. It doesn't hold for 
many comparison operators.

Nor does the transitive law hold, even using absolute epsilon:

eps = 0.5
a = 1.1
b = 1.5
c = 1.9

then a ≈ b, and b ≈ c, but a ≉ c.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#46577

On Fri, May 31, 2013 at 3:13 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> What makes you think that the commutative law is relevant here?
>

Equality should be commutative. If a == b, then b == a. Also, it's
generally understood that if a == c and b == c, then a == b, though
there are more exceptions to that (especially in loosely-typed
languages).

ChrisA

[toc] | [prev] | [next] | [standalone]

#46581

On Fri, 31 May 2013 17:09:01 +1000, Chris Angelico wrote:

> On Fri, May 31, 2013 at 3:13 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> What makes you think that the commutative law is relevant here?
>>
>>
> Equality should be commutative. If a == b, then b == a. Also, it's
> generally understood that if a == c and b == c, then a == b, though
> there are more exceptions to that (especially in loosely-typed
> languages).

Who is talking about equality? Did I just pass through the Looking Glass 
into Wonderland again? *wink*

We're talking about *approximate equality*, which is not the same thing, 
despite the presence of the word "equality" in it. It is non-commutative, 
just like other comparisons like "less than" and "greater than or equal 
to". Nobody gets their knickers in a twist because the >= operator is non-
commutative.

Approximate equality is not just non-commutative, it's also intransitive. 
I'm reminded of a story about Ken Iverson, the creator of APL. Iverson 
was a strong proponent of what he called "tolerant equality", and APL 
defined the = operator as a relative approximate equal, rather than the 
more familiar exactly-equal operator most programming languages use.

    In an early talk Ken was explaining the advantages of tolerant
    comparison. A member of the audience asked incredulously, 
    “Surely you don’t mean that when A=B and B=C, A may not equal C?”
    Without skipping a beat, Ken replied, “Any carpenter knows that!”
    and went on to the next question. — Paul Berry

 
    The intransitivity of [tolerant] equality is well known in
    practical situations and can be easily demonstrated by sawing
    several pieces of wood of equal length. In one case, use the
    first piece to measure subsequent lengths; in the second case,
    use the last piece cut to measure the next. Compare the lengths
    of the two final pieces.
    — Richard Lathwell, APL Comparison Tolerance, APL76, 1976 


See also here:

http://www.jsoftware.com/papers/APLEvol.htm

(search for "fuzz" or "tolerance".



-- 
Steven

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web