>From the virtual desk of Lowell Tackett  


--- On Wed, 4/21/10, Dave Angel <da...@ieee.org> wrote:

> From: Dave Angel <da...@ieee.org>
> Subject: Re: [Tutor] the binary math "wall"
> To: "Lowell Tackett" <lowelltack...@yahoo.com>
> Cc: tutor@python.org, "Steven D'Aprano" <st...@pearwood.info>
> Date: Wednesday, April 21, 2010, 6:46 AM
> 
> 
> Lowell Tackett wrote:
> > --- On Tue, 4/20/10, Steven D'Aprano <st...@pearwood.info>
> wrote:
> > 
> >   
> >> From: Steven D'Aprano <st...@pearwood.info>
> >>     <snip>
> >> 
> >> The simplest, roughest way...hit them with a
> >> hammer:
> >>     
> >>>>> round(18.15*100) == 1815
> >>>>>       
>    
> >> True
> >>     
> > 
> > ...when I tried...:
> > 
> > Python 2.5.1 (r251:54863, Oct 14 2007, 12:51:35)
> > [GCC 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)] on linux2
> > Type "help", "copyright", "credits" or "license" for
> more information.
> >   
> >>>> round(18.15)*100 == 1815
> >>>>         
> > False
> >   
> > <snip>
> But you typed it differently than Steven.  He
> had   round(18.15*100), and you used
> round(18.15)*100

As soon as I'd posted my answer I realized this mistake.

> 
> Very different.   His point boils down to
> comparing integers, and when you have dubious values, round
> them to an integer before comparing.  I have my doubts,
> since in this case it would lead to bigger sloppiness than
> necessary.
> 
> round(18.154 *100) == 1815
> 
> probably isn't what you'd want.
> 
> So let me ask again, are all angles a whole number of
> seconds?  Or can you make some assumption about how
> accurate they need to be when first input (like tenths of a
> second, or whatever)?  If so use an integer as
> follows:
> 
> val =  round((((degrees*60)+minutes)*60) +
> seconds)*10)
> 
> The 10 above is assuming that tenths of a second are your
> quantization.
> 
> HTH
> DaveA
> 
> 

Recalling (from a brief foray into college Chem.) that a result could not be 
displayed with precision greater than the least precise component that bore 
[the result].  So, yes, I could accept my input as the arbitrator of accuracy.

A scenario:

Calculating the coordinates of a forward station from a given base station 
would require [perhaps] the bearing (an angle from north, say) and distance 
from hither to there.  Calculating the north coordinate would set up this 
relationship, e.g.:

cos(3° 22' 49.6") x 415.9207'(Hyp) = adjacent side(North)

My first requirement, and this is the struggle I (we) are now engaged in, is to 
convert my bearing angle (3° 22' 49.6") to decimal degrees, such that I can 
assign its' proper cosine value.  Now, I am multiplying these two very refined 
values (yes, the distance really is honed down to 10,000'ths of a foot-that's 
normal in surveying data); within the bowels of the computer's blackboard 
scratch-pad, I cannot allow errors to evolve and emerge.

Were I to accumulate many of these "legs" into perhaps a 15 mile 
traverse-accumulating little computer errors along the way-the end result could 
be catastrophically wrong.

(Recall that in the great India Survey in the 1800's, Waugh got the elevation 
of Mt. Everest wrong by almost 30' feet for just this exact same reason.)  In 
surveying, we have a saying, "Measure with a micrometer, mark with chalk, cut 
with an axe".  Accuracy [in math] is a sacred tenet.

So, I am setting my self very high standards of accuracy, simply because those 
are the standards imposed by the project I am adapting, and I can require 
nothing less of my finished project.


      

_______________________________________________
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Reply via email to