[Tutor] writing csv files

[prasad rao]

hello!

I got a problem writing csv file.

1)
  csvw=csv.writer(open('/home/prasad/kkm','w'),
dialect='excel',fieldnames=names)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'fieldnames' is an invalid keyword argument for this function

2)
 for x in csvr:
...y=lambda x: ''.join([x.split()[3],x.split()[-3],x.split()[-6]])
...csvw.write(y)
...
Traceback (most recent call last):
  File "", line 3, in 
AttributeError: '_csv.writer' object has no attribute 'write'

At  http://www.python.org/dev/peps/pep-0305/  they are using  the function write
 and the argument fieldnames.

Where is the problem?Please someone show me  a way to do it.

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

Re: [Tutor] writing csv files

[Alan Gauld]

"prasad rao"  wrote


I got a problem writing csv file.


I can't help with that specifically but...


for x in csvr:
...y=lambda x: 
''.join([x.split()[3],x.split()[-3],x.split()[-6]])

...csvw.write(y)


lambdas are intended for anonymous functions so if you
are not going to pass the lambda expression directly
but assign it to a name, then it would be better to take
the definition outside the loop and only do it once.

def y(x): return ''.join([x.split()[3],x.split()[-3],x.split()[-6]])
for x in csvr:
 csvw.write(y)


Traceback (most recent call last):
 File "", line 3, in 
AttributeError: '_csv.writer' object has no attribute 'write'


But I can't answer this bit, sorry.

Alan G 



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

Re: [Tutor] writing csv files

[Sander Sweers]

On 22 May 2010 09:46, prasad rao  wrote:
>  csvw=csv.writer(open('/home/prasad/kkm','w'),
> dialect='excel',fieldnames=names)
> Traceback (most recent call last):
>  File "", line 1, in 
> TypeError: 'fieldnames' is an invalid keyword argument for this function

fieldnames is part of the dictreader and dictwriter objects and you
use the writer object. See the online docs [1] for more info.

Greets
Sander

[1] http://docs.python.org/library/csv.html#csv.DictWriter
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] writing csv files

[Peter Otten]

prasad rao wrote:

> hello!
> 
> I got a problem writing csv file.
> 
> 1)
>   csvw=csv.writer(open('/home/prasad/kkm','w'),
> dialect='excel',fieldnames=names)
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: 'fieldnames' is an invalid keyword argument for this function
> 
> 2)
>  for x in csvr:
> ...y=lambda x: ''.join([x.split()[3],x.split()[-3],x.split()[-6]])
> ...csvw.write(y)
> ...
> Traceback (most recent call last):
>   File "", line 3, in 
> AttributeError: '_csv.writer' object has no attribute 'write'
> 
> At  http://www.python.org/dev/peps/pep-0305/  they are using  the function
> write
>  and the argument fieldnames.
> 
> Where is the problem?Please someone show me  a way to do it.

The PEP is not uptodate. If you are using Python 2.6 have a look at

http://docs.python.org/library/csv.html

You can find the documentation for other versions of Python via 
http://docs.python.org/index.html

If you are using 2.6 the following might work:

# prepare rows
rows = (row.split() for row in csvr)
rows = ((row[3], row[-3], row[-6]) for row in rows)

with open(filename, "wb") as out:
w = csv.writer(out, dialect="excel")
w.writerow(names) # write header
w.writerows(rows) # write data

Peter

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

[Tutor] writing csv files

[prasad rao]

Thanks

I got it.
I reached the old PEP document by searching the keyword  'excel'
Thanks or the help
___
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

[Steven D'Aprano]

On Sat, 22 May 2010 07:51:31 am Alan Gauld wrote:
> "Neven Gorsic"  wrote
>
> > I run into Python error in rounding and not know how to predict
> > when it will
> > occur in order to prevent wrong result.
>
> It depends how you define wrong. When I was at scvhool the rules f
> or rounding decimals said that if it ended in 5 you rounded to the
> nearest even digit.
> So 0.45 -> 0.4 and 0.55 ->0.6

That's called banker's rounding, and if you perform many calculations, 
on average it leads to the smallest rounding error.

> But you seem to assume a 5 always rounds up...

That's how I was taught to do rounding in school too.



-- 
Steven D'Aprano
___
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

[Steven D'Aprano]

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.

You can't represent all fractions as Decimals either:

>>> from decimal import Decimal
>>> d = Decimal(1)/Decimal(3)
>>> d * 3 == 1
False

If you care about representing fractions exactly, use the fraction 
module, not decimal.


>>> from fractions import Fraction
>>> f = Fraction(1, 3)
>>> f * 3 == 1
True


-- 
Steven D'Aprano
___
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

[Wayne Werner]

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. They implement non-hardware operations to preserve exactness.
For more information on exactly what and how the decimal module does what it
does, see the following:

http://docs.python.org/library/decimal.html
http://speleotrove.com/decimal/
 http://754r.ucbtest.org/standards/854.pdf

 plus they are slower.
>

Because if memory serves correctly the Python implementation uses serial
arithmetic, rather than the hardware implementation of floating point
calculations.

Please stop propagating myths about the Decimal module.

For an example about the exactness of Decimal v Float:

>>> d = Decimal(1)/Decimal(3)
>>> d
Decimal('0.')
>>> d*Decimal(3)
Decimal('0.')
>>> d = 1/3.0
>>> d*3
1.0

3*. != 1

Floating point rounds that, while Decimal does not.

-Wayne
___
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

[Steven D'Aprano]

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":


> For an example about the exactness of Decimal v Float:
> >>> d = Decimal(1)/Decimal(3)
> >>> d
>
> Decimal('0.')
>
> >>> d*Decimal(3)
>
> Decimal('0.')

Does that look like exactly one to you? I don't know what they taught 
you, but when I was in school, I learned that one was exactly 1, not 
0.9 or 0.999 or even 0..

But don't believe five hundred years of mathematics, do the test 
yourself:

>>> d*Decimal(3) == 1
False

We can calculate the exact error:

>>> d = Decimal(1)/Decimal(3)
>>> 1 - d*Decimal(3) == 0
False
>>> 1 - d*Decimal(3)
Decimal('1E-28')

Small, but not zero. And adding more precision isn't the answer: it will 
make the error smaller, true enough, but not zero:

>>> decimal.getcontext().prec = 100
>>> d = Decimal(1)/Decimal(3)
>>> d*Decimal(3) == 1
False
>>> 1 - d*Decimal(3)
Decimal('1E-100')

To get that error to zero exactly, you need an infinite precision.


> They implement non-hardware operations to 
> preserve exactness. For more information on exactly what and how the
> decimal module does what it does, see the following:
>
> http://docs.python.org/library/decimal.html

I know what the decimal module does. It is capable of representing 
*decimal* numbers exactly, but not all fractions are exact decimal 
numbers, just as not all fractions are exact binary numbers. For exact 
fractions, you need the fractions module.


>  plus they are slower.
>
>
> Because if memory serves correctly the Python implementation uses
> serial arithmetic, rather than the hardware implementation of
> floating point calculations.

I don't understand what you mean by serial arithmetic, but the reason 
the decimal module is slow is that it is currently written in pure 
Python. A C version would be faster (but still slower than the hardware 
implementation of float calculations).


> Please stop propagating myths about the Decimal module.

I'm not. You are misrepresenting Decimal as a panacea for all rounding 
issues, which it is not.


> >>> 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 a 
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.



-- 
Steven D'Aprano
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor