Re: [Tutor] Excited about python
My all-time favourite is Programming in Python 3 (Mark Summerfield) http://www.qtrac.eu/py3book.html Most of it is not for absolute beginners. Some of the chapters contain stuff I still cannot wrap my brain around. I believe the chapter about regexes (which is VERY good) is freely downloadable. Cheers!! Albert-Jan ~~ All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health, what have the Romans ever done for us? ~~ From: Chris Fuller To: tutor@python.org Sent: Fri, June 10, 2011 7:12:11 PM Subject: Re: [Tutor] Excited about python For a handy reference, you can't beat "Python Essential Reference" by David Beazley (along with the online documentation, of course!). I think this book is obligatory if you are going to be working with Python a lot. I own all four editions :) But you wanted something more in depth with algorithms, etc. The O'Reilly book "Programming Python" by Mark Lutz is a classic and is probably a good bet for you. Core Python by Wesley Chun is also good, and I've seen him on this list from time to time. Also, check out the Python wiki: http://wiki.python.org/moin/PythonBooks Cheers ___ 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] Floating Point Craziness
Hi everyone,
I'm designing a timeline. When the user presses the right arrow, 0.1 is
added to the current position. The user can add events to the timeline, and
can later scroll back across those events to see what they are. But
something I absolutely don't understand is happening:
I used the program to place events at 1.1, 2.1, and 3.1. Here is the end of
the debug output for arrowing to 3.1 and placing the event:
position = 2.7
position = 2.8
position = 2.9
position = 3.0
position = 3.1
event placed.
Everything appears straight forward. But then when I check the dictionary's
contents:
dictionary = {3.1014: value, 2.1005: value,
1.0999: value}
Why is this happening? The output is telling me 3.1, but the value isn't
being placed there. I've tried rounding the 0.1 interval increase to one
decimal point, but the dictionary values are still being improperly placed.
Thanks for any help you can provide.
Best,
Ryan
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Floating Point Craziness
> dictionary = {3.1014: value, 2.1005: value,
> 1.0999: value}
> Why is this happening? The output is telling me 3.1, but the value isn't
It's a quirk of how computers store floating point numbers.
While humans mentally tend to treat everything as characters (and thus
"3.1" is three character: a "3", a ".", and a "1") the computer
internally stores everything as bytes (which are basically numbers),
and we have a character set that says that such-and-such number can
represent "A" or "B", or even "3". For the purposes of efficiency,
actual numbers can be STORED as numbers. This is the difference
between an "integer" value and a "character" value - not what is
stored, but the stored number is interpreted. Internally it's all
represented as binary numbers = sums of bits that represent powers of
two. So 111 = 64+32+8+4+2+1 which is 110 (assuming the math I
just did in my head is correct, but you get the idea)
(Note that the Python Virtual machine is another layer of translation
above this, but that's irrelevant to the basic point)
Okay fine, so "1024" stored as a number only requires 10 bits (binary
digits) to store, while "1024" as a string is 4 characters, requiring
(at least, depending on your character set) 4 bytes to store. None of
this explains what you're seeing.
So how is a floating number stored? Say, 0.5? The short version (you
can google for the longer and more accurate version) is that the
decimal part is stored as a denominator.
So 0.5 would be 2 (because 1/2 = .5) and 0.125 = 8 (because /18 =
0.125) and .75 would be the 2 bit and the 4 bit (because 1/2 + 1/4 =
0.75)
That works great for powers of two, but how do you represent something
like 0.1? 1/10 isn't easily represented in binary fractions.
Answer: you don't. The computer instead gets the best approximation
it can. When you deal with most common representations, you never
notice the difference, but it's still there.
Floating point math is an issue for all programs that require high
precision, and there are additional libraries (including in Python) to
deal with it, but they aren't the default (again, both in and out of
Python) for various reasons.
In your case I suspect you'll just want to use a format to output the
number and you'll see exactly what you expect. It only becomes a
problem in high-precision areas, which 0.1 increments don't tend to
be.
Hope that helps!
--
Brett Ritter / SwiftOne
swift...@swiftone.org
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Floating Point Craziness
Ryan Strunk wrote:
Hi everyone,
I'm designing a timeline. When the user presses the right arrow, 0.1 is
added to the current position. The user can add events to the timeline, and
can later scroll back across those events to see what they are. But
something I absolutely don't understand is happening:
I used the program to place events at 1.1, 2.1, and 3.1. Here is the end of
the debug output for arrowing to 3.1 and placing the event:
position = 2.7
position = 2.8
position = 2.9
position = 3.0
position = 3.1
event placed.
Everything appears straight forward.
It only *appears* straight forward, it actually isn't. That's because
the printed output is rounded so as to look nice. Compare:
>>> x = 1/10.0
>>> print(x) # displayed as nicely as possible
0.1
>>> print('%.25f' % x) # display 25 decimal places
0.155511151
For speed and simplicity, floats are stored by the computer using
fractional powers of two. That's fine for numbers which are powers of
two (1/2, 1/4, 1/256, and sums of such) but numbers that humans like to
use tend to be powers of 10, not 2.
Unfortunately, many common fractions cannot be written exactly in
binary. You're probably familiar with the fact that fractions like 1/3
cannot be written exactly in decimal:
1/3 = 0.... goes on forever
The same is true for some numbers in binary:
1/10 in decimal = 1/16 + 1/32 + 1/256 + ...
also goes on forever. Written in fractional bits:
1/10 decimal = 0.00011001100110011... in binary
Since floats can only store a finite number of bits, 1/10 cannot be
stored exactly. It turns out that the number stored is a tiny bit larger
than 1/10:
>>> Fraction.from_float(0.1) - Fraction(1)/10
Fraction(1, 180143985094819840)
Rounding doesn't help: 0.1 is already rounded as close to 1/10 as it can
possibly get.
Now, when you print the dictionary containing those floats, Python
displays (almost) the full precision:
>>> print {1: 0.1}
{1: 0.10001}
In newer versions of Python, it may do a nicer job of printing the float
so that the true value is hidden. E.g. in Python 3.1 I see:
>>> print({1: 0.1})
{1: 0.1}
but don't be fooled: Python's print display is pulling the wool over
your eyes, the actual value is closer to 0.10001.
One consequence of that is that adding 0.1 ten times does not give 1
exactly, but slightly less than 1:
>>> x = 0.1
>>> 1 - sum([x]*10)
1.1102230246251565e-16
(P.S. this is why you should never use floats for currency. All those
missing and excess fractions of a cent add up to real money.)
To avoid this, you can:
* Upgrade to a newer version of Python that lies to you more often, so
that you can go on living in blissful ignorance (until such time as you
run into a more serious problem with floats);
* Use the fraction module, or the decimal module, but they are slower
than floats; or
* Instead of counting your timeline in increments of 0.1, scale
everything by 10 so the increment is 1.
That is, instead of:
2.0 2.1 2.2 2.3 ...
you will have
20 21 22 23 24 ...
* Or you just get used to the fact that some numbers are not exact in
floating point.
--
Steven
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
[Tutor] [OT] Re: Floating Point Craziness
> * Or you just get used to the fact that some numbers are not exact in > floating point. This got me thinking. How many decimal places do you need to accurately, say, aim a laser somewhere in a 180 degree arc accurately enough to hit a dime on the surface of the moon? Alan ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Lists
Dnia 11-06-2011 o 17:51:03 Piotr Kamiński napisał(a): Dnia 11-06-2011 o 17:30:50 Alan Gauld napisał(a): "Piotr Kamiński" wrote This is a *technical* list, as I understand it, solely dedicated to ... Since this seems to be something we can all agree on can we consider this discussion closed and get back to Python? If you wish to continue the philosophical debate please take it off list. Alan g. List moderator. OK. I like this style of talking - no feelings hurt, *including Christian ones as well*. Thank you. Piotr. To be perfectly clear, as I've got the impression that my words were interpreted in various ways by different people: the "thank you" in my reply to Alan Gauld's message, *is not* a sign of subservience/weakness, my seeking his approval or a similar attitude. I thanked him strictly for *the *polite* style of talking* on the list; I do not expect Alan Gauld or any other Tutor list user to agree with or approve of any of my philosophical views. In other words, *in my culture* thanking someone for something (and, by the way: apologising to someone for a mistake made) is strictly a sign of *politeness*, not of some weakness, defeat, being a losing party, a member of a lower social class etc. Over and out. Piotr ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] [OT] Re: Floating Point Craziness
Hi Alan,
>> * Or you just get used to the fact that some numbers are not exact in
>> floating point.
>
> This got me thinking. How many decimal places do you need to
> accurately, say, aim a laser somewhere in a 180 degree arc accurately
> enough to hit a dime on the surface of the moon?
Here is a quick back of the envelope estimate for you. (While I am still
learning the Python, I can answer this one!)
The angle subtended by a dime on the earth is (approximately) given by
sin( theta ) = d / sqrt( R^2 + d^2 )
where
d = 1 cm (the diameter of a dime)
R = 384,403 km (the average distance from the center of the earth to the center
of the moon - the moon traverses an elliptical path about the earth)
To make the approximation simple, take advantage of the series expansion for
sin (theta) and 1 / sqrt(R^2 + d^2)
first
d / sqrt( R^2 + d^2 ) = d / R * 1 / sqrt(1 + d^2 / R^2 )
~= d / R * (1 - 1/2 * d^2 / R^2 + ...)
now
d / R = 1 * e-2 / (384403 * e3)
~= 3 * e-11
so the d^2 / R^2 correction will be very small, and won't effect the
determination. So we now have
sin (theta) ~= d / R
This will be a very small angle. The next approximation to make is for small
angles
sin (theta) ~= theta + ...
leaving us with
theta ~= d / R
To be approximate, assume the precision you need is equal to the size of the
dime. This means you need an precision of
d theta ~= d/R ~= 3 * e-11 ( = 3 * 10^{-11} if you aren't familiar with the "e"
notation)
this is the minimum precision you would need in both the "x" and "y" direction
to accurately hit the dime on the moon with your laser (at its average
distance).
Corrections to this estimate will come from the fact that the moon's radius is
~1737 km and the earth's radius is ~6370 km, so you are actually this much
closer (R is this much smaller).
Of course both the earth is spinning and the moon is moving relative to us, so
you would have to account for those extra corrections as well.
Hope that wasn't too much info,
André
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Lists
Having followed this absurd thread from its beginning hopefully to this, the end of it. Everyone replying to your diatribe has been incredibly polite to you. One of the moderators tried to explain the obvious to you. This is a Python group. Python is to most of us a delightful language. To others it is a snake. It is not a god a priest or a rabbi. You are arguing religion and issues pertaining to very elementary sophistry. You are acting the fool. Enough. You have crossed the line and have become the 'Troll mediocre'. Go forth and spew your venom elsewhere. Robert > -Original Message- > From: tutor-bounces+bermanrl=cfl.rr@python.org [mailto:tutor- > bounces+bermanrl=cfl.rr@python.org] On Behalf Of Piotr Kaminski > Sent: Sunday, June 12, 2011 4:06 PM > To: tutor@python.org > Subject: Re: [Tutor] Lists > > Dnia 11-06-2011 o 17:51:03 Piotr Kamiński > napisał(a): > > > Dnia 11-06-2011 o 17:30:50 Alan Gauld > > napisał(a): > > > >> "Piotr Kamiński" wrote > >> > > This is a *technical* list, as I understand it, solely > dedicated to > ... > > >> Since this seems to be something we can all agree on > >> can we consider this discussion closed and get back > >> to Python? > >> > >> If you wish to continue the philosophical debate please > >> take it off list. > >> > >> Alan g. > >> List moderator. > > > > > > OK. > > > > I like this style of talking - no feelings hurt, *including > Christian > > ones as well*. > > Thank you. > > > > Piotr. > > > To be perfectly clear, as I've got the impression that my words were > interpreted in various ways by different people: the "thank you" in > my > reply to Alan Gauld's message, *is not* a sign of > subservience/weakness, > my seeking his approval or a similar attitude. > > I thanked him strictly for *the *polite* style of talking* on the > list; I > do not expect Alan Gauld or any other Tutor list user to agree with > or > approve of any of my philosophical views. > > In other words, *in my culture* thanking someone for something (and, > by > the way: apologising to someone for a mistake made) is strictly a > sign of > *politeness*, not of some weakness, defeat, being a losing party, a > member > of a lower social class etc. > > Over and out. > > Piotr > ___ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor -- I am using the free version of SPAMfighter. We are a community of 7 million users fighting spam. SPAMfighter has removed 237 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len The Professional version does not have this message ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Saving data as jpg file
Hi, I tried using the "wb" to create and write the file. In a simple test I did to open an existing jpg file I know is good, putting the data in my new file and closing it, it worked. I don't have access to the camera now, but will try it tomorrow. Thanks Johan -Original Message- From: tutor-bounces+johan=accesstel.com...@python.org [mailto:tutor-bounces+johan=accesstel.com...@python.org] On Behalf Of Steven D'Aprano Sent: Sunday, 12 June 2011 10:14 AM To: Tutor@python.org Subject: Re: [Tutor] Saving data as jpg file Johan Geldenhuys wrote: > Hi, > > I have a Axis IP camera that I can send a HTTP command to and the data > returned is the jpg image. > > When I get this data, I want to save it as a .jpg file, but I think my > encoding is not correct, because the image is all distorted. Are you sure that the data produced by the camera isn't already distorted? I would expect that anything you do wrong with the jpg file (such as the wrong encoding) will corrupt the file, not just distort it. But I see that you are opening the output file in text mode, and you are on Windows: img_file = "E:\work\img1.jpg" f = open(img_file, 'w') You need to open the file in binary mode, as you are writing binary data: f = open(img_file, 'wb') My guess is that this is your problem. Also, using backslashes in pathnames is tricky. You are lucky that the above works correctly, but if you move the file, it might not continue to work. Python uses backslashes to escape special characters, e.g. \n means newline. Try using this as a file name, and you will see what I mean: example = 'C:\temp\report.txt' So you need to be *very* careful of using backslashes in pathnames. The best practice is to either: * escape all the backslashes: img_file = "E:\\work\\img1.jpg" * or use forward slashes: img_file = "E:/work/img1.jpg" Windows will happily accept / instead of \ and you will save yourself a lot of grief in the future. > I looked at using PIL, but the device I will install my script on can't be > used to install other packages like this. I'll have to include the modules > in my own folder. If you can install modules in your own folder, you could put PIL in your folder and then install it. -- Steven ___ 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] [OT] Re: Floating Point Crazines
>> * Or you just get used to the fact that some numbers are not exact in >> floating point. > > This got me thinking. How many decimal places do you need to > accurately, say, aim a laser somewhere in a 180 degree arc accurately > enough to hit a dime on the surface of the moon? > > Alan In short: it's pretty much impossible. The mirrors used in the Lunar Laser Ranging experiments are roughly the size of a suitcase (each). Data from the APOLLO (Apache Point Observatory Lunar Laser-ranging Operation) gives us some numbers to go by: it uses 1 gigawatt energy, generating a (roughly) 1-inch long "bullet" of light. By the time it hits the moon it will have distorted to a diameter of 1.25 miles (earth's atmosphere is the biggest culprit). only about 1 in 30 *million* photons will actually hit the retroflector, and by the time it gets back to the telescope on earth the beam is about 9 miles wide. Again, only 1 in 30 million *of the returning* photons will hit the telescope. Now imagine scaling the retroflector in size to a dime. To bring it back on topic: could python handle these numbers reliably? -- best regards, Robert S. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] subprocess.Popen() OR subprocess.call() ?
Hi all, I am newbie and want to know what is the difference between subprocess.Popen() and subprocess.call() ? when is it best to use each one? Any help appreciated!! Regards, Neha___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] Creating Reports in Python
Hi I am looking for recommendations for Report writers under Python. Current reports are in Crystal reports if that is an option. Any suggestions are welcome. Thanks Mark ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] subprocess.Popen() OR subprocess.call() ?
"Neha P" wrote I am newbie and want to know what is the difference between subprocess.Popen() and subprocess.call() ? Simply speaking, call() is a way to make subprocess easier to use. Popen gives you much more powerful options but that flexibility means it's harder to use. when is it best to use each one? Use the simplest option that works for you. Start with call and if it can't do the job switch to Popen. HTH, ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] [OT] Re: Floating Point Crazines
Robert Sjoblom wrote: * Or you just get used to the fact that some numbers are not exact in floating point. This got me thinking. How many decimal places do you need to accurately, say, aim a laser somewhere in a 180 degree arc accurately enough to hit a dime on the surface of the moon? Alan In short: it's pretty much impossible. [...] To bring it back on topic: could python handle these numbers reliably? *Physically* impossible, not mathematically. If you prefer, imagine putting a laser and a dime in deep space, far from any dust or atmosphere or gravitational distortion, so that we can assume perfectly Euclidean geometry. Put the dime some distance away, and aim the laser at the centre of it: laser * --- + dime Your margin of error in the aiming angle is given by the angle subtended by the dime. That is, you don't have to aim exactly at the centre (angle = 0 degrees), but at any angle between -a and +a degrees, whatever a happens to be. That angle a gives the precision needed. (Strictly speaking, we should be talking about solid angles, steradians, rather than degrees. But for this thought experiment, the difference doesn't matter.) Andre Walker-Loud has already given a back-of-the-envelope calculation which estimates that angle as about 1e-11, so the precision needed is about 12 decimal places. Python's floats have 52 *binary* places of precision, or approximately 15 *decimal* places. So even though we may not be able to physically build a machine capable of aiming a laser to a precision of 0.001 degrees, at least we can be comforted by the knowledge that a C double or a Python float is precise enough to handle the job. -- Steven ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Creating Reports in Python
Mark Cowley - FlexSystems wrote: Hi I am looking for recommendations for Report writers under Python. Current reports are in Crystal reports if that is an option. Any suggestions are welcome. You might get more responses on the main python mailing list, python-l...@python.org, or comp.lang.python on Usenet, than here. -- Steven ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] [OT] Re: Floating Point Crazines
On Sun, Jun 12, 2011 at 9:11 PM, Steven D'Aprano wrote: > Robert Sjoblom wrote: > >> * Or you just get used to the fact that some numbers are not exact in floating point. >>> This got me thinking. How many decimal places do you need to >>> accurately, say, aim a laser somewhere in a 180 degree arc accurately >>> enough to hit a dime on the surface of the moon? >>> >>> Alan >>> >> >> In short: it's pretty much impossible. >> > [...] > > To bring it back on topic: could python handle these numbers reliably? >> > > *Physically* impossible, not mathematically. > [...] at least we can be comforted by the knowledge that a C double or a > Python float is precise enough to handle the job. > Which is actually unsurprising, since my calculator has several times the processing power of the computers on board the original lunar lander. Also, the phone in my pocket probably has several thousand times the processing power and millions of times the memory. Pretty amazing! -Wayne ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] [OT] Re: Floating Point Crazines
> Python's floats have 52 *binary* places of precision, or approximately > 15 *decimal* places. So even though we may not be able to physically > build a machine capable of aiming a laser to a precision of > 0.001 degrees, at least we can be comforted by the knowledge > that a C double or a Python float is precise enough to handle the job. Comforting, indeed. Thanks :) Alan ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
