Re: [Tutor] Python 2.5.4 - error in rounding
On 05/22/10 22:32, Steven D'Aprano wrote: > On Sat, 22 May 2010 07:16:20 am wesley chun wrote: >> correct, it is a floating point issue regardless of language.. it's >> not just Python. you cannot accurately represent repeating fractions >> with binary digits (bits). more info specific to Python here: >> http://docs.python.org/tutorial/floatingpoint.html >> >> also, keep in mind that '%f' is not a rounding operation... it just >> converts floats to strings. if you want to round, you need to use >> both string formatting as well as the round() built-in function. >> >> finally, +1 on using decimal.Decimal as necessary comfortwise. > > Why do people keep recommending Decimal? Decimals suffer from the exact > same issues as floats, plus they are slower. I was recommending Decimal because, to me, the OP seems to want to control how the rounding done, instead of actually wanting precision. Decimal is perfectly fine solution if you only want to control the rounding; using fraction to control rounding is possible, but can be a little awkward. Of course, Decimal only gives "predictable rounding", it doesn't really solve infinite .999.. problems. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Python 2.5.4 - error in rounding
On Sat, May 22, 2010 at 9:58 AM, Steven D'Aprano wrote:
> On Sun, 23 May 2010 12:19:07 am Wayne Werner wrote:
> > On Sat, May 22, 2010 at 7:32 AM, Steven D'Aprano
> wrote:
> > > Why do people keep recommending Decimal? Decimals suffer from the
> > > exact same issues as floats,
> >
> > This is exactly incorrect! The Decimal operator offers /exact/
> > decimal point operations.
>
> Decimal is only exact for fractions which can be represented by a finite
> sum of powers-of-ten, like 0.1, just like floats can only represent
> fractions exactly if they can be represented by a finite sum of
> powers-of-two, like 0.5.
>
> Not only did I demonstrate an example of rounding error using Decimal in
> my post, but you then repeated that rounding error and then had the
> audacity to claim that it was "exact":
>
Decimal doesn't round - exact precision, not exact accuracy. Floating point
has neither reliable precision or accuracy, at least to certain extents.
Decimal, OTOH will perform exactly the same under the exact same
circumstances every time. No matter how many points of precision you go out
to, . * 3 can -never- be equal to 1 (except for very large values of 3).
1/3 is a different number than .3 repeating. It's close, getting closer
the further out you go, and once it reaches infinity then sure, it's
equivalent. But unfortunately computers are finite state machines and
therefore are not capable of expressing the rational number 1/3 in its
decimal equivalent.
This has nothing to do with the Decimal module which will always perform
reliably - you can count on Decimals to behave, precisely, but floats not so
much
>
> I'm not. You are misrepresenting Decimal as a panacea for all rounding
> issues, which it is not.
>
I never said anything about rounding, I only said it performed Decimal
calculations exactly which it does.
> > >>> d = 1/3.0
> > >>> d*3
> > 1.0
>
> Curiously, floats perform that specific calculation better than Decimal.
> That shows that sometimes you can have *too much* precision for
> calculation. float rounds off the answer after just 17 decimal places
> (by memory), giving exactly 1, while Decimal (by default) rounds to 28
> places, leading to an error.
>
> Of course, there are other calculations where Decimal is more accurate:
>
> >>> sum(0.1 for i in range(10)) == 1
> False
> >>> sum(Decimal('0.1') for i in range(10)) == 1
> True
>
> This is only to be expected, because 0.1 is an exact power of ten, but
> not an exact power of two.
>
>
Which is exactly what I stated - that Decimals perform exact decimal
operations, and are thus more reliable than floating point calculations.
Converting fractions to decimals is a separate issue entirely, but one that
Decimals will at least behave reliably on, which is the definition of exact
that I was using.
If you want accurate representation of rational numbers, then of course like
you suggested the Fraction module is available.
-Wayne
>
> --
> Steven D'Aprano
> ___
> Tutor maillist - Tutor@python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
[Tutor] class methods: using class vars as args?
Hello all, I know Python reasonably well, but I still run into basic questions which those over on the other python list request I post here instead. I figure this would be one of them: Why would this not work: class c(object): def __init__(self, arg1, arg2): self.arg1=arg1 self.arg2=arg2 def doSomething(self, arg3=self.arg1): ... The above results in an error that "name 'self' is not defined". Why can I not set the default values of a method's arguments to class vars like that? Thanks! -- Have a great day, Alex (msg sent from GMail website) mehg...@gmail.com; http://www.facebook.com/mehgcap ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] class methods: using class vars as args?
"Alex Hall" wrote class c(object): def __init__(self, arg1, arg2): self.arg1=arg1 self.arg2=arg2 def doSomething(self, arg3=self.arg1): ... The above results in an error that "name 'self' is not defined". Why can I not set the default values of a method's arguments to class vars like that? Thanks! Because they are not class vars they are instance vars. self.arg1 does not exist until after an instance has been created and they have been set by __init__. At the time the class is defined self.arg1 does not exist. You could do class c(object): defArg = 42 def __init__(self, arg1, arg2): self.arg1=arg1 def doSomething(self, arg3=defArg): ... HTH, -- Alan Gauld Author of the Learn to Program web site http://www.alan-g.me.uk ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] class methods: using class vars as args?
Hey Alex, What's happening is that you're still in "defining functions" mode on the line def doSomething(self, arg3=self.arg1): self, which is really nothing more than a parameter being passed in (special parameter, but a parameter none the less) hasn't been assigned a value yet. Imagine this function definition: def do_something(a, b, c=a+b): The parameter instances haven't been instantiated yet. Another way to look at it: You haven't finished defining the class yet, so you can't access data specific to an instance. Not the most technical description, but it's certainly how I look at it. -- I enjoy haiku but sometimes they don't make sense; refrigerator? On Sun, May 23, 2010 at 1:40 PM, Alex Hall wrote: > Hello all, > I know Python reasonably well, but I still run into basic questions > which those over on the other python list request I post here instead. > I figure this would be one of them: > Why would this not work: > > class c(object): > def __init__(self, arg1, arg2): > self.arg1=arg1 > self.arg2=arg2 > > def doSomething(self, arg3=self.arg1): > ... > > The above results in an error that "name 'self' is not defined". Why > can I not set the default values of a method's arguments to class vars > like that? Thanks! > > > -- > Have a great day, > Alex (msg sent from GMail website) > mehg...@gmail.com; http://www.facebook.com/mehgcap > ___ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor > ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Python 2.5.4 - error in rounding
On Mon, 24 May 2010 03:06:28 am Wayne Werner wrote:
> On Sat, May 22, 2010 at 9:58 AM, Steven D'Aprano
wrote:
> > On Sun, 23 May 2010 12:19:07 am Wayne Werner wrote:
> > > On Sat, May 22, 2010 at 7:32 AM, Steven D'Aprano
> >
> > wrote:
> > > > Why do people keep recommending Decimal? Decimals suffer from
> > > > the exact same issues as floats,
> > >
> > > This is exactly incorrect! The Decimal operator offers /exact/
> > > decimal point operations.
> >
> > Decimal is only exact for fractions which can be represented by a
> > finite sum of powers-of-ten, like 0.1, just like floats can only
> > represent fractions exactly if they can be represented by a finite
> > sum of powers-of-two, like 0.5.
> >
> > Not only did I demonstrate an example of rounding error using
> > Decimal in my post, but you then repeated that rounding error and
> > then had the audacity to claim that it was "exact":
>
> Decimal doesn't round - exact precision, not exact accuracy.
Of course decimal rounds! Did you even bother to read the page on
Decimal that you told me to read? It has a section called:
"Mitigating round-off error with increased precision"
http://docs.python.org/library/decimal.html#mitigating-round-off-error-with-increased-precision
Why would it have round-off error if it doesn't round?
Not only do Decimal calculations round, but it gives the user a choice
of rounding modes (e.g. round down, round up, banker's rounding), and
whether to trap rounding and treat it as an error. I demonstrated an
example of this rounding, a calculation of Decimal(1)/Decimal(3) which
did NOT produce the correct result exactly, but ROUNDED the result to
28 decimal places.
Still don't believe me? Then explain this:
>>> x = Decimal('0.')
>>> x + Decimal(7)/Decimal(10**29)
Decimal('1.000')
The answer without rounding is:
0.7
not one. And then there is this:
>>> decimal.getcontext().rounding = decimal.ROUND_DOWN
>>> x + Decimal(7)/Decimal(10**29) == x
True
IEEE-compliant floats also have a choice of rounding modes, but few
high-level programming languages expose that functionality.
> Floating
> point has neither reliable precision or accuracy, at least to certain
> extents.
On IEEE-compliant systems (which include nearly any computer you're
likely to work on) floating point has reliable precision. C singles are
reliably 32 bits with 24 binary digits of precision C doubles (which
Python uses) are reliably 64 bits with 53 binary digits of precision.
As for accuracy, any lack of accuracy (correctness) is a bug in the
implementation, not a fundamental flaw in float. E.g. the infamous
Pentium FDIV bug.
> Decimal, OTOH will perform exactly the same under the exact
> same circumstances every time.
And so will floats.
Decimals and floats are both constructed exactly the same way:
number = significant digits * base ** exponent
The only difference is that Decimal uses digits 0...9 for the digits and
ten for the base, while floats use 0,1 for the digits and two for the
base. This makes Decimal very useful because we humans like to work
with base-ten numbers like 0.1 and get upset that they can't be
expressed exactly in base-two. But Decimal is subject to the exact same
issues as float, because at a fundamental level they are constructed
the same way with the same limitations. The difference in base merely
affects *which* numbers can't be expressed exactly without rounding,
not the existence of such numbers.
Because we tend to *think* in base 10, we naturally get annoyed that
while binary floats can express 0.02 exactly, and
0.10001 exactly, they miss out on 0.1 (as well as an
infinite number of other rationals). But decimal floats suffer from the
same issue. Between Decimal('0.0999...9') and Decimal('0.1') there are
an infinite number of rationals that can't be expressed exactly, and if
a calculation *should* produce one of those rationals, it will be
rounded to an appropriate
> No matter how many points of precision
> you go out to, . * 3 can -never- be equal to 1 (except for very
> large values of 3).
Really? Would you care to put money on that?
>>> decimal.getcontext().prec = 3
>>> Decimal('0.')
Decimal('0.')
>>> Decimal('0.') * 3
Decimal('1.00')
> 1/3 is a different number than .3 repeating.
Nonsense. 0.333 repeating is *exactly* one third. Ask a mathematician.
Here is a short proof:
x = 0.3... # goes on forever
10x = 3.3... # still goes on forever
subtract the first from the second:
9x = 3.0... = 3 exactly
so x = 3/9 = 1/3 exactly.
> It's close, getting closer the further out you go, and once it
> reaches infinity then sure, it's equivalent.
You can't "reach" infinity. That's why it is *repeating* -- it never
stops. This demonstrates that you can't write 1/3 in decimal exactly,
you *must* round the number to a finite number of pla
[Tutor] requesting a help
I am facing the same problem that little complicated.
I have this kind of data in a file and actually it's coming from another class
and it's in formex:0 00 11 01 1and another data which it's in form :0110so now
what I need to put it in form data= [[[0,0],[0]], [[0,1],[1]],
[[1,0],[1]],[[1,1],[0]]]
that is the form for a class that I can use the [0,1] is the inputs and
inputs[0] is = 0 and inputs[1] is = to 1 . the same thing to the output[0] is =
0 and so onok, now this is the problem I have successes to to that reading from
file in form0 00 11 01 1the output0110and I write it in a file called it data
in the new form which is exactly what I want in form [[[0,0],[0]],
[[0,1],[1]], [[1,0],[1]],[[1,1],[0]],]but I got a problem. I cannot
use this as a data when I read it from the data file cuz it's string and I
tried to use int but couldn`t solve it yet.wish you can help me to find the
solution in this problemether I can read the data from the original file and
deal with it separately or write it to file and read it again which I am trying
to do
f=open('data.txt')t=open('target.txt')n=file('newdata.txt','w')
def arange (inputs, targets, outputfile): casesNo = len (inputs.readline())
for s in range (casesNo):for line in inputs:data=line.rsplit()
i=','.join(data)breakfor line1 in targets:
data1=line1.rsplit()#print data1[0]u=','.join(data1)z=
str(i)w= str(u)outputfile.write('[[%s],' % (z)+ '[%s]], \n'
%(w))breakoutputfile.close()arange(f,t,n) # f : input data,
t: target data, n: outputfilelooking to hearing from you as soon as,once again
thanks for your help and cooperation,
Regards,
Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up now.
_
Hotmail: Powerful Free email with security by Microsoft.
https://signup.live.com/signup.aspx?id=60969___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] requesting a help
I'd start with something like this:
final_result = []
for data, target in zip(f, t):
a, b = [elem.strip() for elem in line.split()]
c = target.strip()
final_result.append([[a, b], [c]])
Though I'm not sure why you have the "result" data in single element lists.
--
I enjoy haiku
but sometimes they don't make sense;
refrigerator?
On Sun, May 23, 2010 at 10:34 PM, Ahmed AL-Masri wrote:
>
> I am facing the same problem that little complicated.
> I have this kind of data in a file and actually it's coming from another
> class and it's in form
> ex:
> 0 0
> 0 1
> 1 0
> 1 1
> and another data which it's in form :
> 0
> 1
> 1
> 0
> so now what I need to put it in form
> data= [[[0,0],[0]],
> [[0,1],[1]],
> [[1,0],[1]],
> [[1,1],[0]]
> ]
>
> that is the form for a class that I can use the [0,1] is the inputs and
> inputs[0] is = 0 and inputs[1] is = to 1 . the same thing to the output[0]
> is = 0 and so on
> ok, now this is the problem
> I have successes to to that reading from file in form
> 0 0
> 0 1
> 1 0
> 1 1
> the output
> 0
> 1
> 1
> 0
> and I write it in a file called it data in the new form which is exactly
> what I want in form
> [[[0,0],[0]],
> [[0,1],[1]],
> [[1,0],[1]],
> [[1,1],[0]],]
> but I got a problem. I cannot use this as a data when I read it from the
> data file cuz it's string and I tried to use int but couldn`t solve it yet.
> wish you can help me to find the solution in this problem
> ether I can read the data from the original file and deal with
> it separately or write it to file and read it again which I am trying to do
>
> f=open('data.txt')
> t=open('target.txt')
> n=file('newdata.txt','w')
>
> def arange (inputs, targets, outputfile):
> casesNo = len (inputs.readline())
>
> for s in range (casesNo):
> for line in inputs:
> data=line.rsplit()
> i=','.join(data)
> break
> for line1 in targets:
> data1=line1.rsplit()
> #print data1[0]
> u=','.join(data1)
> z= str(i)
> w= str(u)
> outputfile.write('[[%s],' % (z)+ '[%s]], \n' %(w))
> break
> outputfile.close()
>
> arange(f,t,n) # f : input data, t: target data, n: outputfile
> looking to hearing from you as soon as,
> once again thanks for your help and cooperation,
>
> Regards,
>
>
>
> --
> Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up
> now.
>
> --
> Hotmail: Powerful Free email with security by Microsoft. Get it
> now.
>
> ___
> Tutor maillist - Tutor@python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor
>
>
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
