>From the virtual desk of Lowell Tackett
--- On Tue, 4/20/10, Steven D'Aprano wrote:
> From: Steven D'Aprano
> Subject: Re: [Tutor] the binary math "wall"
> To: tutor@python.org
> Date: Tuesday, April 20, 2010, 7:39 PM
> On Wed, 21 Apr 2010 02:58
Steven D'Aprano wrote:
On Thu, 22 Apr 2010 01:37:35 am Lowell Tackett wrote:
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.
YES!!!
And just by being aware of th
On Thu, 22 Apr 2010 01:37:35 am Lowell Tackett wrote:
> 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.
Unf
Lowell Tackett wrote:
> >From the virtual desk of Lowell Tackett
>
>
>
> --- On Wed, 4/21/10, Dave Angel wrote:
>
>
>> From: Dave Angel
>> Subject: Re: [Tutor] the binary math "wall"
>> To: "Lowell Tackett"
>> Cc: tutor@p
>From the virtual desk of Lowell Tackett
--- On Wed, 4/21/10, Dave Angel wrote:
> From: Dave Angel
> Subject: Re: [Tutor] the binary math "wall"
> To: "Lowell Tackett"
> Cc: tutor@python.org, "Steven D'Aprano"
> Date: Wednesday, Apri
Lowell Tackett wrote:
From the virtual desk of Lowell Tackett
--- On Wed, 4/21/10, Dave Angel wrote:
From: Dave Angel
Subject: Re: [Tutor] the binary math "wall"
To: "Lowell Tackett"
Cc: tutor@python.org, "Steven D'Aprano"
Date: Wednesday, April
On 4/21/2010 8:37 AM Lowell Tackett said...
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.
Then keep the source data in tenths (or 100ths or 1000ths) a
>From the virtual desk of Lowell Tackett
--- On Wed, 4/21/10, Dave Angel wrote:
> From: Dave Angel
> Subject: Re: [Tutor] the binary math "wall"
> To: "Lowell Tackett"
> Cc: tutor@python.org, "Steven D'Aprano"
> Date: Wednesday,
Lowell Tackett wrote:
--- On Tue, 4/20/10, Steven D'Aprano wrote:
From: Steven D'Aprano
The simplest, roughest way to fix these sorts of problems
(at the risk
of creating *other* problems!) is to hit them with a
hammer:
round(18.15*100) == 1815
True
In
On Tue, 20 Apr 2010 19:11:24 -0700 (PDT)
Lowell Tackett wrote:
> > >>> round(18.15*100) == 1815
> > True
>
> Interestingly, this is the [above] result when I tried entered the same
> snippet:
>
> Python 2.5.1 (r251:54863, Oct 14 2007, 12:51:35)
> [GCC 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)]
>From the virtual desk of Lowell Tackett
--- On Tue, 4/20/10, Steven D'Aprano wrote:
> From: Steven D'Aprano
> Subject: Re: [Tutor] the binary math "wall"
> To: tutor@python.org
> Date: Tuesday, April 20, 2010, 7:39 PM
> On Wed, 21 Apr 2010 02:58
On Wed, 21 Apr 2010 02:58:06 am Lowell Tackett wrote:
> I'm running headlong into the dilemma of binary math representation,
with game-ending consequences, e.g.:
> >>> 0.15
>
> 0.14999
>
> Obviously, any attempts to manipulate this value, under the misguided
> assumption that it is tru
On Tue, 20 Apr 2010 14:45:50 -0400
Dave Angel wrote:
> If all values are made up of degrees/minutes/seconds, and seconds is a
> whole number, then store values as num-seconds, and do all arithmetic on
> those values. Only convert them back to deg/min/sec upon output.
This seems the most dire
Lowell Tackett wrote:
I'm running headlong into the dilemma of binary math representation, with
game-ending consequences, e.g.:
0.15
0.14999
Obviously, any attempts to manipulate this value, under the misguided assumption that it
is truly "0.15" are ill-advised, with
>From the virtual desk of Lowell Tackett
--- On Tue, 4/20/10, Luke Paireepinart wrote:
> From: Luke Paireepinart
> Subject: Re: [Tutor] the binary math "wall"
> To: "Lowell Tackett"
> Cc: "tutor"
> Date: Tuesday, April 20, 2010, 1:20
On 04/21/10 02:58, Lowell Tackett wrote:
> I'm running headlong into the dilemma of binary math representation, with
> game-ending consequences, e.g.:
>
Never use float for representing numbers, use float to represent a
"magnitude", do not rely on the exact representation of the number itself.
On Tue, 20 Apr 2010 09:58:06 -0700 (PDT)
Lowell Tackett wrote:
> I'm running headlong into the dilemma of binary math representation, with
> game-ending consequences, e.g.:
>
> >>> 0.15
> 0.14999
> [...]
> The last line should be zero, and needs to be for me to continue this
> algo
On Tue, Apr 20, 2010 at 11:58 AM, Lowell Tackett wrote:
> I'm running headlong into the dilemma of binary math representation, with
> game-ending consequences, e.g.:
>
> >>> 0.15
> 0.14999
>
> Obviously, any attempts to manipulate this value, under the misguided
> assumption that it is
On Tue, Apr 20, 2010 at 12:58 PM, Lowell Tackett
wrote:
> Any of Python's help-aids that I apply to sort things out, such as formatting
> (%), or modules like "decimal" do nothing more than "powder up" the display
> for visual consumption (turning it into a string). The underlying float
> valu
On Tue, Apr 20, 2010 at 11:58 AM, Lowell Tackett
wrote:
> I'm running headlong into the dilemma of binary math representation, with
> game-ending consequences, e.g.:
>
0.15
> 0.14999
>
> Obviously, any attempts to manipulate this value, under the misguided
> assumption that it i
I'm running headlong into the dilemma of binary math representation, with
game-ending consequences, e.g.:
>>> 0.15
0.14999
Obviously, any attempts to manipulate this value, under the misguided
assumption that it is truly "0.15" are ill-advised, with inevitable bad results.
the part
21 matches
Mail list logo
