Re: Good books in computer science?

[Bob Martin]

in 117455 20090615 044816 Steven D'Aprano 
 wrote:
>On Mon, 15 Jun 2009 10:39:50 +1200, Lawrence D'Oliveiro wrote:
>
>>> Shame on you for deliberately cutting out my more serious and nuanced
>>> answer while leaving a silly quip.
>>
>> Can't have been very "serious and nuanced" if it could be summed up by
>> such a "silly quip" though, could it?
>
>But it can't be summed up by the silly quip, which is why I'm complaining
>that the silly quip on its own fails to include the more serious and
>nuanced elements of my post.

Lots of references to "good programmer" but no attempt to define the term.

Who is the better programmer - one who writes lousy code but produces good 
programs
or one who obeys all the rules of coding but whose programs break all the time?
(Yes, I know there are two other categories!)
In almost 50 years programming I have met all types but I tended to judge them
by the end results, not on their style.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: moving Connection/PipeConnection between processes

[Randall Smith]

Now that I've done some homework, everything you said is clear.

Mike Kazantsev wrote:


Pickle has nothing to do with the problem since it lay much deeper: in
the OS.

From kernel point of view, every process has it's own "descriptor
table" and the integer id of the descriptor is all the process gets, so
when you say "os.pipe()" kernel actually gives you a number which is
completely meaningless for any other process - it either doesn't exists
in it's descriptor table or points to something else.

So, what you actually need is to tell the kernel to duplicate
underlying object in another process' table (with it's own numbering),
which is usually done via special flag for sendmsg(2) in C, so you
should probably look out for py implementation of this call, which I
haven't stumbled upon, but, admittely, never looked for.



sendmsg is a missing feature of the socket module.

http://bugs.python.org/issue1194378

And this implements it:

http://pypi.python.org/pypi/python-eunuchs/0.0.0



--
http://mail.python.org/mailman/listinfo/python-list

Re: waling a directory with very many files

[Steven D'Aprano]

On Sun, 14 Jun 2009 22:35:50 +0200, Andre Engels wrote:

> On Sun, Jun 14, 2009 at 6:35 PM, tom wrote:
>> i can traverse a directory using os.listdir() or os.walk(). but if a
>> directory has a very large number of files, these methods produce very
>> large objects talking a lot of memory.
>>
>> in other languages one can avoid generating such an object by walking a
>> directory as a liked list. for example, in c, perl or php one can use
>> opendir() and then repeatedly readdir() until getting to the end of the
>> file list. it seems this could be more efficient in some applications.
>>
>> is there a way to do this in python? i'm relatively new to the
>> language. i looked through the documentation and tried googling but
>> came up empty.
> 
> What kind of directories are those that just a list of files would
> result in a "very large" object? I don't think I have ever seen
> directories with more than a few thousand files...


You haven't looked very hard :)

$ pwd
/home/steve/.thumbnails/normal
$ ls | wc -l
33956

And I periodically delete thumbnails, to prevent the number of files 
growing to hundreds of thousands.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[Steven D'Aprano]

On Sun, 14 Jun 2009 14:29:04 -0700, Kay Schluehr wrote:

> On 14 Jun., 16:00, Steven D'Aprano
>  wrote:
> 
>> Incorrect. Koch's snowflake, for example, has a fractal dimension of
>> log 4/log 3 ≈ 1.26, a finite area of 8/5 times that of the initial
>> triangle, and a perimeter given by lim n->inf (4/3)**n. Although the
>> perimeter is infinite, it is countably infinite and computable.
> 
> No, the Koch curve is continuous in R^2 and uncountable. 

I think we're talking about different things. The *number of points* in 
the Koch curve is uncountably infinite, but that's nothing surprising, 
the number of points in the unit interval [0, 1] is uncountably infinite. 
But the *length* of the Koch curve is not, it's given by the above limit, 
which is countably infinite (it's a rational number for all n).


> Lawrence is
> right and one can trivially cover a countable infinite set with disks of
> the diameter 0, namely by itself. The sum of those diameters to an
> arbitrary power is also 0 and this yields that the Hausdorff dimension
> of any countable set is 0.

Nevertheless, the Hausdorff dimension (or a close approximation thereof) 
can be calculated from the scaling properties of even *finite* objects. 
To say that self-similar objects like broccoli or the inner surface of 
the human lungs fails to nest at all scales is pedantically correct but 
utterly pointless. If it's good enough for Benoît Mandelbrot, it's good 
enough for me.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Steven D'Aprano]

On Sun, 14 Jun 2009 19:14:10 -0400, Terry Reedy wrote:

> Steven D'Aprano wrote:
>> 
>> So-called "vacuous truth". It's often useful to have all([]) return
>> true, but it's not *always* useful -- there are reasonable cases where
>> the opposite behaviour would be useful:
[...]
> It seems to me that the absurd conclusion implied by the theorem
> invalidates the theorem rather than supporting your point.

I wouldn't go so far as to say the vacuous truth theorem ("empty 
statements are true") is invalidated. The Wikipedia article discusses 
various reasons why it's more correct (or at least more useful) to treat 
vacuous statements as true:

http://en.wikipedia.org/wiki/Vacuous_truth

But it's not without difficulties -- however those difficulties are 
smaller than those if you take vacuous statements as false in general.

[...]
> Try finding another 'reasonable case'.

Any time you do something like:

if not x and all(x):
process(x)


instead of just:

if all(x):
process(x)


I can't think of a real world example off the top of my head, but here's 
a contrived example demonstrating that vacuous truths imply both a fact 
and it's opposite:


def startswith(s, chars):
"""Return True if s starts with any of chars."""
for c in chars:
if s.startswith(c): return True
return False


if all([startswith(w, "aeiou") for w in words]):
print "All the words start with vowels."

if all([startswith(w, "bcdfghjklmnpqrstvwxyz") for w in words]):
print "All of the words start with consonants."


If words is empty, this code claims that all of the words start with 
vowels as well as starting with consonants.

There are, of course, ways to work around that other than rejecting 
vacuous truths. One is to simply use an "elif" for the second test.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Steven D'Aprano]

On Sun, 14 Jun 2009 18:02:54 +0100, Arnaud Delobelle wrote:

> Steven D'Aprano  writes:
>> So-called "vacuous truth". It's often useful to have all([]) return
>> true, but it's not *always* useful -- there are reasonable cases where
>> the opposite behaviour would be useful:
>>
>> if all(the evidence points to the Defendant's guilt) then:
>> the Defendant is guilty
>> execute(the Defendant)
>>
>> sadly means that if there is no evidence that a crime has been
>> committed, the person accused of committing the imaginary crime will be
>> executed.
> 
> This is a bad example.  Someone is not convicted of a crime just because
> all the available evidence points towards their guilt.  There may be
> very little evidence altogether, or it might just be circumstancial, or
> unconvincing.  Even though it may all point towards the defendent's
> guilt, it doesn't mean they will be convicted.  There needs to be enough
> evidence to convince the jury.  So it would be something like:
> 
> if sum(guilt_weight(e) for e in evidence) > GUILT_THRESHOLD:
>the defendant is guilty
>...

Not all trials are jury trials, and not all cultures have a presumption 
of innocence.

There are, in fact, many places where the government and police think 
little of falsifying evidence to convict innocent people, including 
people that they know are innocent of any crime (an extreme case was 
Stalin's show trials). But as far as I know, nobody ever argues that 
people are guilty based on the principle of Vacuous Truth: everybody 
agrees that if there is no evidence of a crime, the person should be 
considered innocent rather than guilty. Even Stalin manufactured evidence 
of crimes. (In most cases, that evidence was to torture people into 
confessing to crimes that did not, in fact, take place.)

To put it another way, logically:

all(the evidence is true)
not any(the evidence is false)

should be considered identical, but in practice, we treat:

evidence = [] # evidence of a crime
all(evidence)

as false instead of true, even in places with no presumption of innocence.

While:

not any(map(operator.not_, evidence))

is also treated as false.


In any case, I'm not arguing against vacuous truth -- it's clearly the 
right way to deal with empty sets *nearly always*. But it isn't entirely 
straight-forward, and leads to some difficulties, such as a vacuous truth 
X implies both Y and not Y at the same time.




-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Specify the sorting direction for the various columns/

[Oni]

Thanks for the answers. My goal was to try to avoid hard coding
and add a little shine to the code I have inherited. But its
too far gone already and time is short.  So have used Mike's answer.

Mike answer with minor changes:

import datetime
import pprint
import operator
import time

entries = [{'name': 'ZZ2', 'username': 'ZZ3', 'date':
datetime.datetime (2007, 9, 30, 16, 43, 54)},{'name': 'ZZ2',
'username': 'ZZ5','date': datetime.datetime(2008, 9, 30, 16, 43,
54)},{'name': 'ZZ3', 'username': 'ZZ1', 'date':
datetime.datetime(2007, 9, 30, 16, 43, 54)}, {'name': 'AA2',
'username': 'AA2','date': datetime.datetime(2007, 9, 30, 16, 43,
54)}]

entries.sort(key = lambda x: (x['name'], -time.mktime(x
['date'].timetuple())   ))

pp = pprint.PrettyPrinter(depth=2)
pp.pprint(entries)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Good books in computer science?

[Steven D'Aprano]

On Mon, 15 Jun 2009 10:39:50 +1200, Lawrence D'Oliveiro wrote:

>> Shame on you for deliberately cutting out my more serious and nuanced
>> answer while leaving a silly quip.
> 
> Can't have been very "serious and nuanced" if it could be summed up by
> such a "silly quip" though, could it?

But it can't be summed up by the silly quip, which is why I'm complaining 
that the silly quip on its own fails to include the more serious and 
nuanced elements of my post.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Good books in computer science?

[Phil Runciman]

>Rhodri James wrote:
>> On Sun, 14 Jun 2009 14:19:13 +0100, Graham Ashton 
>>  wrote:
>> 
>>> On 2009-06-14 14:04:02 +0100, Steven D'Aprano 
>>>  said:
>>>
 Nathan Stoddard wrote:

> The best way to become a good programmer is to program. Write a lot of
> code; work on some large projects. This will improve your skill more 
> than
> anything else.
  I think there are about 100 million VB code-monkeys who prove that 
 theory
 wrong.
>>>
>>> Really? So you don't think that the best way to get good at something 
>>> is to practice?
>> 
>> Self-evidently.  If what you practice is bad practice, it doesn't matter
>> how much you practice it you'll still be no good at good practice in
>> practice.  Practically speaking, that is :-)
>> 
>True. And there's no point in practising if you don't understand what
>you're doing or why you're doing it that way. There are plenty of good
>tutorials for Python, for example, but if you can't follow any of them
>(assuming that it's not just a language problem), or can't be bothered
>to read any of them, then you probably shouldn't be a programmer.


If you are given to depression then programming is possibly not for you.

Keep tackling problems that are beyond your current capabilities.

Think about what you are doing... this is more subtle that you might grasp at 
first.

Know there is always a better way and seek it.

Prime your thinking by reading Edsgar Dijkstra. Dijkstra's "Notes on Structured 
Programming" are a good read and are probably available on the 'Net by now. You 
will see that his concerns had practically nothing to do with "Goto Considered 
Harmful". That was a later observation made as a result of checking students 
programs. His notes were knocking around in the UK back in 1966 and earlier. 
His co-authored book on "Structure Programming" is good reading even now. (O-J 
Dahl, EW Dijkstra, and CAR Hoare). See 
http://www.cs.utexas.edu/users/EWD/transcriptions/transcriptions.html for his 
famous EWD series of notes. 

Gain access to one of the IEEE or ACM web sites and their resources. I used to 
sneak into my local university library before the 'Net to read this stuff. 

Beyond that I check up on the reading lists for CS students from time to time. 
This often throws up real gems and prevents me from being blind-sided.

Beware any "programmer" who only knows one computer language and only one OS, 
especially if this is either windows or a version of UNIX. 

My 2c worth

-- 
http://mail.python.org/mailman/listinfo/python-list

Cisco certification

[Asim Saeed]

if you wnat to know about cisco certification it books and dump
http://ciscocity.blogspot.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: matplotlib installation

[Lawrence D'Oliveiro]

In message , David 
Cournapeau wrote:

> Basically, there are some functions which are erroneously "declared"
> in the .lib, but they don't actually exist in the MS C runtime.

Isn't this a MinGW bug?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: uncompress base64-gzipped string

[Lawrence D'Oliveiro]

In message , John 
Machin wrote:

> What a long journey: parse xml, base64 decode, gunzip,
> and you're still not home; next stop is struct.unpack ...

Binary data in an XML file?? Were these the same folks who worked on OOXML, 
by any chance?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python-2.6.2 Exception: TypeError: "'NoneType' object is not callable" in ignored

[Poor Yorick]

Terry Reedy wrote:
> Poor Yorick wrote:
>> The following code produces an error (python-2.6.2).
>
> You forgot to post the error traceback.
>

There was no traceback, but following John Machin's prodding, I read back
through some older posts (including one of yours) which I hadn't guessed were
relevant the first time around.  It seems that the program itself was
functioning properly, but when the interpreter exited, objects were being
deleted in an order which did not permit orderly teardown of other objects.  I
hadn't thought to look, before, but despite the warnings, the exit status of
the interpreter was 0.  The solution to the errors was to register a teardown
function in the module:

import atexit

def teardown():
del globals()['d1']

atexit.register(teardown)

--
Yorick




--
http://mail.python.org/mailman/listinfo/python-list

Re: waling a directory with very many files

[Tim Chase]

i can traverse a directory using os.listdir() or os.walk(). but if a
directory has a very large number of files, these methods produce very
large objects talking a lot of memory.

in other languages one can avoid generating such an object by walking
a directory as a liked list. for example, in c, perl or php one can
use opendir() and then repeatedly readdir() until getting to the end
of the file list. it seems this could be more efficient in some
applications.

is there a way to do this in python? i'm relatively new to the
language. i looked through the documentation and tried googling but
came up empty.


You did not specify version.  In Python3, os.walk has become a generater 
function.  So, to answer your question, use 3.1.


Since at least 2.4, os.walk has itself been a generator. 
However, the contents of the directory (the 3rd element of the 
yielded tuple) is a list produced by listdir() instead of a 
generator.  Unless listdir() has been changed to a generator 
instead of a list (which other respondents seem to indicate has 
not been implemented), this doesn't address the OP's issue of 
"lots of files in a single directory".


-tkc




--
http://mail.python.org/mailman/listinfo/python-list

Re: python-2.6.2 Exception: TypeError: "'NoneType' object is not callable" in ignored

[Dave Angel]

Poor Yorick wrote:
The 
following code produces an error (python-2.6.2).  Either of the following

eliminates the error:

. assign something besides mod1 (the newly-created module) to d1

. remove the call to shelve.open

Why is there an error produced in the first place?  What is the 
interaction
between d1, mod1, and shelve about?  This code runs without error in 
python-3.1


$ cat test1.py
import test2
newmodule = test2.load()

$ cat test2.py

import imp
import shelve

def load():
text='import test2\n'
text += '''print('hello from test3')\n'''
code = compile(text,'', 'exec')
mod1 = imp.new_module('newmodule')

newdict = mod1.__dict__
#newdict = {}

exec(code,newdict)
mod1
mode = mod1
d1['unique'] = mod1
#d1['unique'] = ''
return mod1

print('hello from test2')
d1 = {}
cache = shelve.open('persist')

$ python2.6 test1.py
hello from test2
hello from test3
Exception TypeError: "'NoneType' object is not callable" in  ignored
Exception TypeError: "'NoneType' object is not callable" in  ignored

You don't need all those lines to trigger these exception messages.  All 
you need in  test1.py is the import statement.  And in test2.py:


import shelve
cache = shelve.open('persist')

To cure it, just close the cache:

cache.close()

I don't have any idea what the exception means, but this seems like a 
logical thing, to close it.


--
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Aaron Brady]

On Jun 14, 12:37 pm, Paul Rubin  wrote:
> Andre Engels  writes:
snip
> > type "thingy". A car is a single car. Nothing is zero cars, which is
> > not a car, just like two cars is not a car.
>
> That seems to confuse values with collections of them.  A car is not
> the same as a one-element list of cars.  Nothing is not the same as a
> zero-element list of cars.

Collections are a mathematical (ideal, cognitive) construct.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: walking a directory with very many files

[Lawrence D'Oliveiro]

In message , Andre 
Engels wrote:

> On Sun, Jun 14, 2009 at 6:35 PM, tom wrote:
>
>> in other languages one can avoid generating such an object by walking
>> a directory as a liked list.

I suppose it depends how well-liked it is. Nerdy lists may work better, but 
they tend not to be liked.

> What kind of directories are those that just a list of files would
> result in a "very large" object? I don't think I have ever seen
> directories with more than a few thousand files...

I worked on an application system which, at one point, routinely dealt with 
directories containing hundreds of thousands of files. But even that kind of 
directory contents only adds up to a few megabytes.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: TypeError: int argument required

[Lawrence D'Oliveiro]

In message , Rhodri 
James wrote:

> On Sun, 14 Jun 2009 10:43:30 +0100, Lawrence D'Oliveiro
>  wrote:
> 
>> In message , Rhodri
>> James wrote:
>>
>>> 2.  That output string has severe "leaning toothpick" syndrome.  Python
>>> accepts both single and double quotes to help avoid creating something
>>> so unreadable: use them.
>>
>> Backslashes are more scalable.
> 
> That doesn't excuse sprinkling several million backslashes through literal
> constants when there's a more readable alternative.

Perl allows just about any printable character as a quote. I tried 
alternative quotes for many years, and decided making that choice was a 
waste of brain cells.

So no, using alternative quotes does not make things more readable.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: waling a directory with very many files

[Christian Heimes]

Terry Reedy wrote:
> You did not specify version.  In Python3, os.walk has become a generater
> function.  So, to answer your question, use 3.1.

I'm sorry to inform you that Python 3.x still returns a list, not a
generator.


ython 3.1rc1+ (py3k:73396, Jun 12 2009, 22:45:18)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> type(os.listdir("."))


Christian

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: waling a directory with very many files

[MRAB]

Christian Heimes wrote:

tom schrieb:

i can traverse a directory using os.listdir() or os.walk(). but if a
directory has a very large number of files, these methods produce very
large objects talking a lot of memory.

in other languages one can avoid generating such an object by walking
a directory as a liked list. for example, in c, perl or php one can
use opendir() and then repeatedly readdir() until getting to the end
of the file list. it seems this could be more efficient in some
applications.

is there a way to do this in python? i'm relatively new to the
language. i looked through the documentation and tried googling but
came up empty.


Some time ago we had a discussion about turning os.listdir() into a
generator. No conclusion was agreed on. We also thought about exposing
the functions opendir(), readdir(), closedir() and friends but as far as
I know and as far as I've checked the C code in Modules/posixmodule.c
none of the functions as been added.


Perhaps if there's a generator it should be called iterdir(). Or would
it be unPythonic to have listdir() and iterdir()? Probably.


For now you are on your own to implement wrappers for the system calls.
For the distant future you may see the appropriate functions in the os
module. A mail to the python ideas list may increase your chances. ;)



--
http://mail.python.org/mailman/listinfo/python-list

Re: waling a directory with very many files

[Christian Heimes]

Andre Engels wrote:
> What kind of directories are those that just a list of files would
> result in a "very large" object? I don't think I have ever seen
> directories with more than a few thousand files...

I've seen directories with several hundreds of thousand files. Depending
on the file system and IO capacity it can take about one to several
minute until 'ls' even starts to print out files names. It's no fun on
directories on a CIFS storage or ext3 w/o a btree dir index.

Christian

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python-2.6.2 Exception: TypeError: "'NoneType' object is not callable" in ignored

[Terry Reedy]

Poor Yorick wrote:

The following code produces an error (python-2.6.2).


You forgot to post the error traceback.

--
http://mail.python.org/mailman/listinfo/python-list

Re: python-2.6.2 Exception: TypeError: "'NoneType' object is not callable" in ignored

[John Machin]

Poor Yorick  pooryorick.com> writes:

> 
> The following code produces an error (python-2.6.2).  Either of the following
> eliminates the error:
> 
>  . assign something besides mod1 (the newly-created module) to d1
> 
>  . remove the call to shelve.open
[snip]
> 
>  $ python2.6 test1.py
>  hello from test2
>  hello from test3
>  Exception TypeError: "'NoneType' object is not callable" in  ignored
>  Exception TypeError: "'NoneType' object is not callable" in  ignored
 
Take your error message, paste it into a search box in a browser, delete
punctuation characters (especially "), and hit the search button. Limiting your
search to this newsgroup is a good idea.



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: waling a directory with very many files

[Terry Reedy]

tom wrote:

i can traverse a directory using os.listdir() or os.walk(). but if a
directory has a very large number of files, these methods produce very
large objects talking a lot of memory.

in other languages one can avoid generating such an object by walking
a directory as a liked list. for example, in c, perl or php one can
use opendir() and then repeatedly readdir() until getting to the end
of the file list. it seems this could be more efficient in some
applications.

is there a way to do this in python? i'm relatively new to the
language. i looked through the documentation and tried googling but
came up empty.


You did not specify version.  In Python3, os.walk has become a generater 
function.  So, to answer your question, use 3.1.


tjr

--
http://mail.python.org/mailman/listinfo/python-list

Re: waling a directory with very many files

[Christian Heimes]

tom schrieb:
> i can traverse a directory using os.listdir() or os.walk(). but if a
> directory has a very large number of files, these methods produce very
> large objects talking a lot of memory.
> 
> in other languages one can avoid generating such an object by walking
> a directory as a liked list. for example, in c, perl or php one can
> use opendir() and then repeatedly readdir() until getting to the end
> of the file list. it seems this could be more efficient in some
> applications.
> 
> is there a way to do this in python? i'm relatively new to the
> language. i looked through the documentation and tried googling but
> came up empty.

Some time ago we had a discussion about turning os.listdir() into a
generator. No conclusion was agreed on. We also thought about exposing
the functions opendir(), readdir(), closedir() and friends but as far as
I know and as far as I've checked the C code in Modules/posixmodule.c
none of the functions as been added.

For now you are on your own to implement wrappers for the system calls.
For the distant future you may see the appropriate functions in the os
module. A mail to the python ideas list may increase your chances. ;)

Christian

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Terry Reedy]

Paul LaFollette wrote:

Thank you all for your thoughtful and useful comments.  Since this has
largely morphed into a discussion of my 3rd question, perhaps it would
interest you to hear my reason for asking it.

John is just about spot on. Part of my research involves the
enumeration and generation of various combinatorial objects using what
are called "loopless" or "constant time" algorithms.  (This means that
the time required to move from one object to the next is bounded by a
constant that is independent of the size of the object.  It is related
to following idea:  If I generate all of the possible patterns
expressible with N bits by simply counting in binary, as many as N
bits may change from one pattern to the next.  On the other hand if I
use Gray code only one bit changes from each pattern to the next.


But the number of bits you must examine to determine which to change is 
bounded by N and increases with N.


--
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Terry Reedy]

Mel wrote:

John Yeung wrote:


And I accept your answer, as well as Steven's and Paul's for that
matter.  I still think it is understandable (and people may choose to
understand in a condescending way, if they wish) that someone might
not get the difference between what you are saying and the statement
that all elements of the empty set are floats.  I mean, what's in the
empty set?  Nothing.  But you've said that floats are something.  How
is it that nothing is something?


It's sort of a logic equivalent of divide-by-zero.

All elements of the empty set are floats.
All elements of the empty set are ints.
Ints are not floats.
Therefore all elements of the empty set are not floats.

If
x in e => x in floats
x in e => x in ints
x in ints => x not in floats
Then
x in e => x not in floats, a contradition,
So
not(x in e), the definition of empty set.

You elaborate your logic to talk around this problem, and you quit when you 
get tired.


No problem. Colloquial English is not the same as careful logic.
2 minutes, tired? Nah.

tjr

--
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Terry Reedy]

Steven D'Aprano wrote:


So-called "vacuous truth". It's often useful to have all([]) return
true, but it's not *always* useful -- there are reasonable cases
where the opposite behaviour would be useful:

if all(the evidence points to the Defendant's guilt) then: the
Defendant is guilty execute(the Defendant)

sadly means that if there is no evidence that a crime has been
committed, the person accused of committing the imaginary crime will
be executed.


It seems to me that the absurd conclusion implied by the theorem
invalidates the theorem rather than supporting your point.  No evidence 
is only the endpoint of a continuum.  Suppose that 'all' is one teensy 
weensy bit of evidence. A drunked bystander gives a vague description 
that fits.  Or twenty years before, the defendent argued with the 
deceased and said 'I wish you were dead'. Should the person be executed? 
I say not.  You?


Of course, a person would only be a defendant in the absence of evidence 
under a depraved regime that would not much care if there were.


Try finding another 'reasonable case'.

Terry Jan Reedy


--
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[Peter Billam]

>> In message , Peter Billam wrote:
>>> Are there any modules, packages, whatever, that will
>>> measure the fractal dimensions of a dataset, e.g. a time-series ?
 
> Lawrence D'Oliveiro wrote:
>> I don't think any countable set, even a countably-infinite set, can
>> have a fractal dimension. It's got to be uncountably infinite, and
>> therefore uncomputable.

You need a lot of data-points to get a trustworthy answer.
Of course edge-effects step in as you come up against the
spacing betwen the points; you'd have to weed those out.

On 2009-06-14, Steven D'Aprano  wrote:
> Strictly speaking, there's not one definition of "fractal dimension", there
> are a number of them. One of the more useful is the "Hausdorf dimension",

They can be seen as special cases of Renyi's generalised entropy;
the Hausdorf dimension (D0) is easy to compute because of the
box-counting-algorithm:
  http://en.wikipedia.org/wiki/Box-counting_dimension

Also easy to compute is the Correlation Dimension (D2):
  http://en.wikipedia.org/wiki/Correlation_dimension

Between the two, but much slower, is the Information Dimension (D1)
  http://en.wikipedia.org/wiki/Information_dimension
which most closely corresponds to physical entropy.

Multifractals are very common in nature
(like stock exchanges, if that counts as nature :-))
  http://en.wikipedia.org/wiki/Multifractal_analysis
but there you really need _huge_ datasets to get useful answers ...

There have been lots of papers published (these are some refs I have:
  G. Meyer-Kress, "Application of dimension algorithms to experimental
  chaos," in "Directions in Chaos", Hao Bai-Lin ed., (World Scientific,
  Singapore, 1987) p. 122
  S. Ellner, "Estmating attractor dimensions for limited data: a new
  method, with error estimates" Physi. Lettr. A 113,128 (1988)
  P. Grassberger, "Estimating the fractal dimensions and entropies
  of strange attractors", in "Chaos", A.V. Holden, ed. (Princeton
  University Press, 1986, Chap 14)
  G. Meyer-Kress, ed. "Dimensions and Entropies in Chaotic Systems -
  Quantification of Complex Behaviour", vol 32 of Springer series
  in Synergetics (Springer Verlag, Berlin, 1986)
  N.B. Abraham, J.P. Gollub and H.L. Swinney, "Testing nonlinear
   dynamics," Physica 11D, 252 (1984)
) but I haven't chased these up and I don't think they contain
any working code. But the work has been done, so the code must
be there still, on some computer somwhere...

Regards,  Peter

-- 
Peter Billam   www.pjb.com.auwww.pjb.com.au/comp/contact.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: TypeError: int argument required

[Rhodri James]

On Sun, 14 Jun 2009 10:43:30 +0100, Lawrence D'Oliveiro  
 wrote:



In message , Rhodri
James wrote:


2.  That output string has severe "leaning toothpick" syndrome.  Python
accepts both single and double quotes to help avoid creating something
so unreadable: use them.


Backslashes are more scalable.


Yes, yes, you can print them at any size.  That doesn't excuse sprinkling
several million backslashes through literal constants when there's a more
readable alternative.

--
Rhodri James *-* Wildebeest Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list

Re: Good books in computer science?

[MRAB]

Rhodri James wrote:
On Sun, 14 Jun 2009 14:19:13 +0100, Graham Ashton 
 wrote:


On 2009-06-14 14:04:02 +0100, Steven D'Aprano 
 said:



Nathan Stoddard wrote:


The best way to become a good programmer is to program. Write a lot of
code; work on some large projects. This will improve your skill more 
than

anything else.
 I think there are about 100 million VB code-monkeys who prove that 
theory

wrong.


Really? So you don't think that the best way to get good at something 
is to practice?


Self-evidently.  If what you practice is bad practice, it doesn't matter
how much you practice it you'll still be no good at good practice in
practice.  Practically speaking, that is :-)


True. And there's no point in practising if you don't understand what
you're doing or why you're doing it that way. There are plenty of good
tutorials for Python, for example, but if you can't follow any of them
(assuming that it's not just a language problem), or can't be bothered
to read any of them, then you probably shouldn't be a programmer.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Good books in computer science?

[Lawrence D'Oliveiro]

In message <0050ecf7$0$9684$c3e8...@news.astraweb.com>, Steven D'Aprano 
wrote:

> Graham Ashton wrote:
> 
>> On 2009-06-14 14:04:02 +0100, Steven D'Aprano
>>  said:
>> 
>>> Nathan Stoddard wrote:
>>> 
 The best way to become a good programmer is to program. Write a lot of
 code; work on some large projects. This will improve your skill more
 than anything else.
>>> 
>>> I think there are about 100 million VB code-monkeys who prove that
>>> theory wrong.
>> 
>> Really? So you don't think that the best way to get good at something
>> is to practice?
> 
> Shame on you for deliberately cutting out my more serious and nuanced
> answer while leaving a silly quip.

Can't have been very "serious and nuanced" if it could be summed up by such 
a "silly quip" though, could it?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Good books in computer science?

[Rhodri James]

On Sun, 14 Jun 2009 14:19:13 +0100, Graham Ashton  
 wrote:


On 2009-06-14 14:04:02 +0100, Steven D'Aprano  
 said:



Nathan Stoddard wrote:


The best way to become a good programmer is to program. Write a lot of
code; work on some large projects. This will improve your skill more  
than

anything else.
 I think there are about 100 million VB code-monkeys who prove that  
theory

wrong.


Really? So you don't think that the best way to get good at something is  
to practice?


Self-evidently.  If what you practice is bad practice, it doesn't matter
how much you practice it you'll still be no good at good practice in
practice.  Practically speaking, that is :-)

--
Rhodri James *-* Wildebeest Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list

Re: Different types of dicts with letter before the curly braces.

[Rhodri James]

On Sun, 14 Jun 2009 12:02:47 +0100, kindly  wrote:


I am sure people have thought of this before, but I cant find where.
I think that python should adapt a way of defining different types of
mapping functions by proceeding a letter before the curly brackets.
i.e   ordered = o{},  multidict = m{}  (like paste multidict).  So you
could define an ordered dict by newordered = o{"llvm" : "ptyhon",
"parrot" : "perl"} .  (they should also probably have there own
comprehensions as well o{foo for bar in foobar}).


-1.  And before you ask, that would have been my reaction to the
'u' and 'b' string prefixes as well.

Python has perfectly good constructors for any class already, and
it's perfectly obvious what they're doing because they involve the
class name.  Obfuscating this by using one character modifiers on
existing literal syntax and expecting the result to be (a) obvious
and (b) meaningful in the face of an ever-extending collection of
basic types is optimistic in the extreme.  Even Perl doesn't
expect that much memory of you!

--
Rhodri James *-* Wildebeest Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list

python-2.6.2 Exception: TypeError: "'NoneType' object is not callable" in ignored

[Poor Yorick]

The following code produces an error (python-2.6.2).  Either of the following
eliminates the error:

. assign something besides mod1 (the newly-created module) to d1

. remove the call to shelve.open

Why is there an error produced in the first place?  What is the interaction
between d1, mod1, and shelve about?  This code runs without error in python-3.1

$ cat test1.py
import test2
newmodule = test2.load()

$ cat test2.py

import imp
import shelve

def load():
text='import test2\n'
text += '''print('hello from test3')\n'''
code = compile(text,'', 'exec')
mod1 = imp.new_module('newmodule')

newdict = mod1.__dict__
#newdict = {}

exec(code,newdict)
mod1
mode = mod1
d1['unique'] = mod1
#d1['unique'] = ''
return mod1

print('hello from test2')
d1 = {}
cache = shelve.open('persist')

$ python2.6 test1.py
hello from test2
hello from test3
Exception TypeError: "'NoneType' object is not callable" in  ignored
Exception TypeError: "'NoneType' object is not callable" in  ignored

--
Yorick
--
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[Kay Schluehr]

On 14 Jun., 16:00, Steven D'Aprano
 wrote:

> Incorrect. Koch's snowflake, for example, has a fractal dimension of log
> 4/log 3 ≈ 1.26, a finite area of 8/5 times that of the initial triangle,
> and a perimeter given by lim n->inf (4/3)**n. Although the perimeter is
> infinite, it is countably infinite and computable.

No, the Koch curve is continuous in R^2 and uncountable. Lawrence is
right and one can trivially cover a countable infinite set with disks
of the diameter 0, namely by itself. The sum of those diameters to an
arbitrary power is also 0 and this yields that the Hausdorff dimension
of any countable set is 0.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Paul Rubin]

Andre Engels  writes:
> I was making a point that I don't agree that "nothing" would match any
> type. The reason was that anything of the type car is one car, not two
> cars or zero cars, but "nothing" is zero cars. You don't agree with
> me, so apparently you are of the opinion that "nothing" would be a car.

I don't agree that "nothing" is "zero cars".  Just like I don't agree
that the empty set, the empty list, and the empty string are the same
thing.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Good books in computer science?

[dads]

I'm wanting to purchase some of the titles that have been raised in
this thread. When I look they are very expensive books which is
understandable. Do you think getting earlier editions that are cheaper
is a daft thing or should I fork out the extra £10-£30 to get the
latest edition?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: waling a directory with very many files

[Andre Engels]

On Sun, Jun 14, 2009 at 6:35 PM, tom wrote:
> i can traverse a directory using os.listdir() or os.walk(). but if a
> directory has a very large number of files, these methods produce very
> large objects talking a lot of memory.
>
> in other languages one can avoid generating such an object by walking
> a directory as a liked list. for example, in c, perl or php one can
> use opendir() and then repeatedly readdir() until getting to the end
> of the file list. it seems this could be more efficient in some
> applications.
>
> is there a way to do this in python? i'm relatively new to the
> language. i looked through the documentation and tried googling but
> came up empty.

What kind of directories are those that just a list of files would
result in a "very large" object? I don't think I have ever seen
directories with more than a few thousand files...


-- 
André Engels, andreeng...@gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Andre Engels]

On Sun, Jun 14, 2009 at 10:21 PM, Paul
Rubin wrote:
> Andre Engels  writes:
>> > That seems to confuse values with collections of them.  A car is not
>> > the same as a one-element list of cars.  Nothing is not the same as a
>> > zero-element list of cars.
>>
>> So you are of the opinion that "nothing" _is_ a car?
>
> Eh?  No of course not.  a != b and b != c does not mean a==c.
> I don't understand what you're getting at.

I was making a point that I don't agree that "nothing" would match any
type. The reason was that anything of the type car is one car, not two
cars or zero cars, but "nothing" is zero cars. You don't agree with
me, so apparently you are of the opinion that "nothing" would be a
car.

-- 
André Engels, andreeng...@gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: shoehorn c-structured data into Numpy

[Scott David Daniels]

MRAB wrote:

Helmut Fritz wrote:
I have binary output 
from a Fortran program that is in a big-endian C-structured binary 
file.  The output can be very variable and many options create 
different orderings in the binary file. So I'd like to keep the 
header-reading in python.


Anyhoo, I've so far been able to read the output with the struct 
module.  But my question is how do I create numpy arrays from the bits 
of the file I want?

>> TC1 = np.frombuffer(struct.unpack(">%df" % ncells,
>>data.read(4*ncells))[0], dtype=float)

Note both struct and numpy.frombuffer unpack data from a buffer.
Do it only once:

If you are going to a numpy array:
TC1 = np.frombuffer(data.read(4*ncells)), dtype=float)
# and possibly:
TC1.byteswap(True) # True to byteswap in place.

Or (even better -- less copying):

TC1 = np.fromfile(data, count=ncells, dtype=float)
# and again, possibly:
TC1.byteswap(True) # True to byteswap in place.

--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Paul Rubin]

Andre Engels  writes:
> > That seems to confuse values with collections of them.  A car is not
> > the same as a one-element list of cars.  Nothing is not the same as a
> > zero-element list of cars.
> 
> So you are of the opinion that "nothing" _is_ a car?

Eh?  No of course not.  a != b and b != c does not mean a==c.
I don't understand what you're getting at.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Good books in computer science?

[Chris Jones]

On Sun, Jun 14, 2009 at 09:04:02AM EDT, Steven D'Aprano wrote:
> Nathan Stoddard wrote:
> 
> > The best way to become a good programmer is to program. Write a lot of
> > code; work on some large projects. This will improve your skill more than
> > anything else.
> 
> I think there are about 100 million VB code-monkeys who prove that theory
> wrong.
> 
> Seriously, and without denigrating any specific language, you can program by
> (almost) mindlessly following a fixed number of recipes and patterns. This
> will get the job done, but it won't make you a good programmer.

Vivaldi vs. Mozart 

And the latter especially had definitely mastered his editor. Just think
of the sheer volume of the coding he managed during his short life.

Not many bugs either…

CJ
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Andre Engels]

On Sun, Jun 14, 2009 at 9:37 PM, Paul Rubin wrote:
> Andre Engels  writes:
>> I don't see why that would be the case. Something of the type "thingy"
>> is ONE thingy. Nothing is ZERO thingies, so it is not something of the
>> type "thingy". A car is a single car. Nothing is zero cars, which is
>> not a car, just like two cars is not a car.
>
> That seems to confuse values with collections of them.  A car is not
> the same as a one-element list of cars.  Nothing is not the same as a
> zero-element list of cars.

So you are of the opinion that "nothing" _is_ a car?



-- 
André Engels, andreeng...@gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Paul Rubin]

Andre Engels  writes:
> I don't see why that would be the case. Something of the type "thingy"
> is ONE thingy. Nothing is ZERO thingies, so it is not something of the
> type "thingy". A car is a single car. Nothing is zero cars, which is
> not a car, just like two cars is not a car.

That seems to confuse values with collections of them.  A car is not
the same as a one-element list of cars.  Nothing is not the same as a
zero-element list of cars.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: waling a directory with very many files

[Tim Golden]

tom wrote:

On Jun 14, 1:35 pm, Tim Golden  wrote:

If you're on Windows, you can use the win32file.FindFilesIterator
function from the pywin32 package. (Which wraps the Win32 API
FindFirstFile / FindNextFile pattern).


thanks, tim.

however, i'm not using windows. freebsd and os x.


Presumably, if Perl etc. can do it then it should be simple
enough to drop into ctypes and call the same library code, no?
(I'm not a BSD / OS X person, I'm afraid, so perhaps this isn't
so easy...)

TJG
--
http://mail.python.org/mailman/listinfo/python-list

Re: Good books in computer science?

[Benjamin Kaplan]

On Sun, Jun 14, 2009 at 9:04 AM, Steven D'Aprano <
st...@removethis.cybersource.com.au> wrote:

> Nathan Stoddard wrote:
>
> > The best way to become a good programmer is to program. Write a lot of
> > code; work on some large projects. This will improve your skill more than
> > anything else.
>
> I think there are about 100 million VB code-monkeys who prove that theory
> wrong.
>

There aren't 100 million VB code-monkeys. There are 100 million VB
drag-and-drop monkeys, but they never actually wrote any program by
themselves- Daddy Microsoft wrote a lot of it for them.



>
> Seriously, and without denigrating any specific language, you can program
> by
> (almost) mindlessly following a fixed number of recipes and patterns. This
> will get the job done, but it won't make you a good programmer.
>
>
> --
> Steven
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

weakrefs, threads,, and object ids

[Jeremy]

Hello,

I'm using weakrefs in a small multi-threaded application.  I have been
using object IDs as dictionary keys with weakrefs to execute removal
code, and was glad to find out that this is in fact recommended
practice (http://docs.python.org/library/weakref.html)

> This simple example shows how an application can use objects IDs to retrieve
> objects that it has seen before. The IDs of the objects can then be used in 
> other
> data structures without forcing the objects to remain alive, but the objects 
> can
> still be retrieved by ID if they do.

After reading this, I realized it made no explicit mention of thread
safety in this section, whereas other sections made a note of correct
practice with threads.  The docs for the id() function specify

> Return the identity of an object.  This is guaranteed to be unique among
> simultaneously existing objects.  (Hint: it's the object's memory address.)

While guaranteed unique for simultaneously existing objects, how often
will an object assume an ID previously held by former object?  Given
that the ID is a memory address in Python's heap, I assume the answer
is either not often, or very often.

Specifically, I'm wondering if the case can occur that the callback
for a weakref is executed after another object has been allocated with
the same object identifier as a previous object.  If such an object is
inserted into a module-level dictionary, could it over-write a
previous entry with the same identifier and then get deleted whenever
the weakref callback happens to fire?



On a related note, what is a recommended way to obtain a weak
reference to a thread?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Aaron Brady]

On Jun 14, 10:02 am, Arnaud Delobelle  wrote:
snip
> guilt, it doesn't mean they will be convicted.  There needs to be enough
> evidence to convince the jury.  So it would be something like:
>
> if sum(guilt_weight(e) for e in evidence) > GUILT_THRESHOLD:
>    the defendant is guilty
>    ...
>
> --
> Arnaud

You all are only two months late.

http://groups.google.com/group/comp.lang.python/msg/7b63d0d11246ecad

Can't argue with results.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: waling a directory with very many files

[tom]

On Jun 14, 1:35 pm, Tim Golden  wrote:
>
> If you're on Windows, you can use the win32file.FindFilesIterator
> function from the pywin32 package. (Which wraps the Win32 API
> FindFirstFile / FindNextFile pattern).

thanks, tim.

however, i'm not using windows. freebsd and os x.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[MRAB]

Andre Engels wrote:

On Sun, Jun 14, 2009 at 6:49 PM, Paul
LaFollette wrote:

Now, suppose that I want to generate, say, the set of all ordered
trees with N nodes.   I need to be able to represent the empty ordered
tree, i.e. the tree with with zero nodes.  There are a lot of ways I
could do this.  The problem is that I might tomorrow be looking
instead at rooted trees, or free trees, or Young tableaux and in each
case I will need to represent the empty rooted tree, or the empty free
tree, or the empty Young tableau.

In a very real sense, the empty Young tableau IS a Young tableau and
the empty ordered tree IS an ordered tree.  But in an equally real
sense they are the same "ghost of a thing" looked at in different
universes of discourse.


But do you also want the empty Young tableau to BE an ordered tree? A
number? A diddlewoodaddy? It seems much more logical to me to define
your Young tableaus such that the definition includes the empty one as
well.


For strings there's the empty string with the same methods. It's not the
same as None.

For lists there's the empty list with the same methods. It's not the
same as None.

For dicts there's the empty dict with the same methods. It's not the
same as None.

For sets there's the empty set with the same methods. It's not the same
as None.

etc.
--
http://mail.python.org/mailman/listinfo/python-list

Re: waling a directory with very many files

[Tim Golden]

tom wrote:

i can traverse a directory using os.listdir() or os.walk(). but if a
directory has a very large number of files, these methods produce very
large objects talking a lot of memory.

in other languages one can avoid generating such an object by walking
a directory as a liked list. for example, in c, perl or php one can
use opendir() and then repeatedly readdir() until getting to the end
of the file list. it seems this could be more efficient in some
applications.

is there a way to do this in python? i'm relatively new to the
language. i looked through the documentation and tried googling but
came up empty.


If you're on Windows, you can use the win32file.FindFilesIterator
function from the pywin32 package. (Which wraps the Win32 API
FindFirstFile / FindNextFile pattern).

TJG
--
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Andre Engels]

On Sun, Jun 14, 2009 at 6:49 PM, Paul
LaFollette wrote:
> Now, suppose that I want to generate, say, the set of all ordered
> trees with N nodes.   I need to be able to represent the empty ordered
> tree, i.e. the tree with with zero nodes.  There are a lot of ways I
> could do this.  The problem is that I might tomorrow be looking
> instead at rooted trees, or free trees, or Young tableaux and in each
> case I will need to represent the empty rooted tree, or the empty free
> tree, or the empty Young tableau.
>
> In a very real sense, the empty Young tableau IS a Young tableau and
> the empty ordered tree IS an ordered tree.  But in an equally real
> sense they are the same "ghost of a thing" looked at in different
> universes of discourse.

But do you also want the empty Young tableau to BE an ordered tree? A
number? A diddlewoodaddy? It seems much more logical to me to define
your Young tableaus such that the definition includes the empty one as
well.


-- 
André Engels, andreeng...@gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: persistent composites

[Jaime Fernandez del Rio]

On Sun, Jun 14, 2009 at 4:27 PM, Aaron Brady wrote:
>
> Before I go and flesh out the entire interfaces for the provided
> types, does anyone have a use for it?

A real-world application of persistent data structures can be found here:

http://stevekrenzel.com/persistent-list

Jaime

-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus
planes de dominación mundial.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: shoehorn c-structured data into Numpy

[MRAB]

Helmut Fritz wrote:


Hello there everyone, I used to be on this a long time ago but then I 
got so much spam I gave up.


But this strategy has come a little unstuck.  I have binary output from 
a Fortran program that is in a big-endian C-structured binary file.  The 
output can be very variable and many options create different orderings 
in the binary file. So I'd like to keep the header-reading in python.


Anyhoo, I've so far been able to read the output with the struct 
module.  But my question is how do I create numpy arrays from the bits 
of the file I want?


So far I've been able to scan through to the relevant sections and I've 
tried all maner of idiotic combinations...


The floats are 4 bytes for sinngle percision, and it's a unstructured 
grid from a finite difference scheme so I know the number of cells 
(ncells) for the property I am looking to extract.


So I've tried:
TC1 = np.frombuffer(struct.unpack(">%df" % ncells, 
data.read(4*ncells))[0], dtype=float)

Only to get a very logical:
 >>> Traceback (most recent call last):
 >>>   File "a2o.py", line 466, in 
 >>> runme(me)
 >>>   File "a2o.py", line 438, in runme
 >>> me.spmapdat(data)
 >>>   File "a2o.py", line 239, in spmapdat
 >>> TC1 = np.frombuffer(struct.unpack(">%df" % ncells, 
data.read(4*ncells))[0], dtype=float)

 >>> AttributeError: 'float' object has no attribute '__buffer__'


This:

struct.unpack(">%df" % ncells, data.read(4*ncells))

unpacks to a tuple of floats, from which you get the first (actually
the zeroth) float. You probably didn't want to do that! :-)

Try:

   TC1 = np.array(struct.unpack(">%df" % ncells, data.read(4 * 
ncells)), dtype=float)



ok... so I'll feed frombuffer my data file...

And then tried:
TC1 = np.frombuffer(data.read(4*ncells), dtype=float, count=ncells)
 >>> Traceback (most recent call last):
 >>>   File "a2o.py", line 466, in 
 >>> runme(me)
 >>>   File "a2o.py", line 438, in runme
 >>> me.spmapdat(data)
 >>>   File "a2o.py", line 240, in spmapdat
 >>> TC1 = np.frombuffer(data.read(4*ncells), dtype=float, count=ncells)
 >>> ValueError: buffer is smaller than requested size

And THEN I tried:
TC1 = np.frombuffer(data.read(4*ncells), dtype=float, count=4*ncells)
 >>> Traceback (most recent call last):
 >>>   File "a2o.py", line 466, in 
 >>> runme(me)
 >>>   File "a2o.py", line 438, in runme
 >>> me.spmapdat(data)
 >>>   File "a2o.py", line 240, in spmapdat
 >>> TC1 = np.frombuffer(data.read(4*ncells), dtype=float, 
count=4*ncells)

 >>> ValueError: buffer is smaller than requested size

But it's the right size - honest.

(In general) I should be able to put these arrays into memory with no 
problems.  Certainly given the rate at which I'm turning around this 
code... Memory may be in the terabytes once I'm done.


Anyone got a Sesame Street answer for this?

Many thanks!  Helmut.


--
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Arnaud Delobelle]

Steven D'Aprano  writes:
> So-called "vacuous truth". It's often useful to have all([]) return true,
> but it's not *always* useful -- there are reasonable cases where the
> opposite behaviour would be useful:
>
> if all(the evidence points to the Defendant's guilt) then:
> the Defendant is guilty
> execute(the Defendant)
>
> sadly means that if there is no evidence that a crime has been committed,
> the person accused of committing the imaginary crime will be executed.

This is a bad example.  Someone is not convicted of a crime just because
all the available evidence points towards their guilt.  There may be
very little evidence altogether, or it might just be circumstancial, or
unconvincing.  Even though it may all point towards the defendent's
guilt, it doesn't mean they will be convicted.  There needs to be enough
evidence to convince the jury.  So it would be something like:

if sum(guilt_weight(e) for e in evidence) > GUILT_THRESHOLD:
   the defendant is guilty
   ...

-- 
Arnaud
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Paul LaFollette]

Thank you all for your thoughtful and useful comments.  Since this has
largely morphed into a discussion of my 3rd question, perhaps it would
interest you to hear my reason for asking it.

John is just about spot on. Part of my research involves the
enumeration and generation of various combinatorial objects using what
are called "loopless" or "constant time" algorithms.  (This means that
the time required to move from one object to the next is bounded by a
constant that is independent of the size of the object.  It is related
to following idea:  If I generate all of the possible patterns
expressible with N bits by simply counting in binary, as many as N
bits may change from one pattern to the next.  On the other hand if I
use Gray code only one bit changes from each pattern to the next.  If
you are interested in this essentially useless (but fun) subject, the
seminal paper by Gideon Ehrlich is here:
http://portal.acm.org/citation.cfm?id=321781 )

Now, suppose that I want to generate, say, the set of all ordered
trees with N nodes.   I need to be able to represent the empty ordered
tree, i.e. the tree with with zero nodes.  There are a lot of ways I
could do this.  The problem is that I might tomorrow be looking
instead at rooted trees, or free trees, or Young tableaux and in each
case I will need to represent the empty rooted tree, or the empty free
tree, or the empty Young tableau.

In a very real sense, the empty Young tableau IS a Young tableau and
the empty ordered tree IS an ordered tree.  But in an equally real
sense they are the same "ghost of a thing" looked at in different
universes of discourse.

So, what I would like is some sort of object that is a "kind of"
everything but contains nothing, a unique minimal element of the
partial ordering imposed on the set of classes by the inheritance
heierarchy.  Whilst I am not naive mathematically, I am relatively
naive in the area of language design.  In my naivete, it seemed to me
that None could have been designed to be such a thing.  Apparently
that is incorrect.

The matter is not urgent, there are oodles of workarounds.  Indeed,
having once found a particular loopless algorithm I don't necessarily
publish an implementation of it, but rather a formal description and
proof of correctness.  Still, before I submit things for publication I
generally prefer to implement them for myself just to convince myself
that what I have proved correct in fact works at least for modest
values of N.

Paul

paul[dot]lafollette[at]gmail.com
http://www.cis.temple.edu/~lafollet
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: persistent composites

[Aaron Brady]

On Jun 14, 8:24 am, Steven D'Aprano
 wrote:
> Aaron Brady wrote:
> > Some time ago, I recommended a pursuit of keeping 'persistent
> > composite' types on disk, to be read and updated at other times by
> > other processes.  Databases provide this functionality, with the
> > exception that field types in any given table are required to be
> > uniform.  Python has no such restriction.
> ...
> > I will be sure to kill any interest you might have by now, by
> > "revealing" a snippet of code.
>
> How about telling us what problem you're trying to solve? Giving us your
> implementation isn't useful if we don't even know what it's for. Persistent
> data on disk, okay, I get that -- but how is it different from (say) XML,
> or INI files, or pickles, or similar? Is the idea to have *live* data
> stored on disk, updated by multiple processes simultaneously? Don't assume
> that people will remember your recommendation from "some time ago".
>
> --
> Steven

It was no time at all in the Usenet world, I suppose.  There are lots
of strategies for storing data on a disk, and lots of strategies for
storing data in memory.  I was trying on disk what Python uses on
memory.

If you want to argue that Python isn't useful, you're in the wrong
place.  If you want to argue that Python's strategy is useful on
disks, you're talking to the right person.

I'll draw an analogy.  static data structures : sql & co. :: Python
data structures : this undertaking.  It has all the advantages over
SQL & XML structures that Python has over C structures: sort of a
'worst of neither' combination.  I haven't written a textbook on DSs,
though, so I don't quite know where to begin.  In my eyes, you're
practically asking, "What's your use case for Python?"  Either that,
or I don't know enough other languages.

I have nothing to use it for, but someone might, and it might be just
plumb interesting to fellow Pythoneers.  If I did, I'd have somewhere
to start.
-- 
http://mail.python.org/mailman/listinfo/python-list

waling a directory with very many files

[tom]

i can traverse a directory using os.listdir() or os.walk(). but if a
directory has a very large number of files, these methods produce very
large objects talking a lot of memory.

in other languages one can avoid generating such an object by walking
a directory as a liked list. for example, in c, perl or php one can
use opendir() and then repeatedly readdir() until getting to the end
of the file list. it seems this could be more efficient in some
applications.

is there a way to do this in python? i'm relatively new to the
language. i looked through the documentation and tried googling but
came up empty.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Generating a unique filename in the face of unicode filename

[Martin v. Löwis]

> where line 175 is the assignment to self.unique_name.  After a little
> back-and-forth with his user it turns out that her computer's hostname
> contains non-ASCII data, so presumably self.hostname is a unicode object.

Most likely, it is not. It's rather the hostname encoded in the ANSI
code page.

> It works for Frank on his Windows box as well.  Any ideas how to properly
> Unicode-proof this code?

You should first decode the gethostname result, using the locale's
encoding; expect this decoding to fail possibly, so the "ignore" error
handler might be your best choice.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Andre Engels]

On Sat, Jun 13, 2009 at 7:23 PM, John Yeung wrote:

> Paul LaFollette is probably thinking along the lines of formal logic
> or set theory.  It's a little bit confused because programming isn't
> quite the same as math, and so it's a common question when designing
> and implementing programming languages how far to take certain
> abstractions.  In some languages, nil, null, or none will try to
> behave as mathematically close to "nothing" (complete absence of
> anything) as possible, even though in reality they have to have some
> concrete implementation, such as perhaps being a singleton object.
> But mathematically speaking, it's intuitive that "nothing" would match
> any type.

I don't see why that would be the case. Something of the type "thingy"
is ONE thingy. Nothing is ZERO thingies, so it is not something of the
type "thingy". A car is a single car. Nothing is zero cars, which is
not a car, just like two cars is not a car.


-- 
André Engels, andreeng...@gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

shoehorn c-structured data into Numpy

[Helmut Fritz]

Hello there everyone, I used to be on this a long time ago but then I got so
much spam I gave up.

But this strategy has come a little unstuck.  I have binary output from a
Fortran program that is in a big-endian C-structured binary file.  The
output can be very variable and many options create different orderings in
the binary file. So I'd like to keep the header-reading in python.

Anyhoo, I've so far been able to read the output with the struct module.
But my question is how do I create numpy arrays from the bits of the file I
want?

So far I've been able to scan through to the relevant sections and I've
tried all maner of idiotic combinations...

The floats are 4 bytes for sinngle percision, and it's a unstructured grid
from a finite difference scheme so I know the number of cells (ncells) for
the property I am looking to extract.

So I've tried:
TC1 = np.frombuffer(struct.unpack(">%df" % ncells, data.read(4*ncells))[0],
dtype=float)
Only to get a very logical:
>>> Traceback (most recent call last):
>>>   File "a2o.py", line 466, in 
>>> runme(me)
>>>   File "a2o.py", line 438, in runme
>>> me.spmapdat(data)
>>>   File "a2o.py", line 239, in spmapdat
>>> TC1 = np.frombuffer(struct.unpack(">%df" % ncells,
data.read(4*ncells))[0], dtype=float)
>>> AttributeError: 'float' object has no attribute '__buffer__'

ok... so I'll feed frombuffer my data file...

And then tried:
TC1 = np.frombuffer(data.read(4*ncells), dtype=float, count=ncells)
>>> Traceback (most recent call last):
>>>   File "a2o.py", line 466, in 
>>> runme(me)
>>>   File "a2o.py", line 438, in runme
>>> me.spmapdat(data)
>>>   File "a2o.py", line 240, in spmapdat
>>> TC1 = np.frombuffer(data.read(4*ncells), dtype=float, count=ncells)
>>> ValueError: buffer is smaller than requested size

And THEN I tried:
TC1 = np.frombuffer(data.read(4*ncells), dtype=float, count=4*ncells)
>>> Traceback (most recent call last):
>>>   File "a2o.py", line 466, in 
>>> runme(me)
>>>   File "a2o.py", line 438, in runme
>>> me.spmapdat(data)
>>>   File "a2o.py", line 240, in spmapdat
>>> TC1 = np.frombuffer(data.read(4*ncells), dtype=float,
count=4*ncells)
>>> ValueError: buffer is smaller than requested size

But it's the right size - honest.

(In general) I should be able to put these arrays into memory with no
problems.  Certainly given the rate at which I'm turning around this code...
Memory may be in the terabytes once I'm done.

Anyone got a Sesame Street answer for this?

Many thanks!  Helmut.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Piet van Oostrum]

> John Yeung  (JY) wrote:

>JY> I've never heard a mathematician use the term "bottom".  It certainly
>JY> could be that I just haven't talked to the right types of
>JY> mathematicians.  

"Bottom" is a term from lattice theory, which is a branch of mathematics.
-- 
Piet van Oostrum 
URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
Private email: p...@vanoostrum.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: persistent composites

[Steven D'Aprano]

Aaron Brady wrote:

> Some time ago, I recommended a pursuit of keeping 'persistent
> composite' types on disk, to be read and updated at other times by
> other processes.  Databases provide this functionality, with the
> exception that field types in any given table are required to be
> uniform.  Python has no such restriction.
...
> I will be sure to kill any interest you might have by now, by
> "revealing" a snippet of code.

How about telling us what problem you're trying to solve? Giving us your
implementation isn't useful if we don't even know what it's for. Persistent
data on disk, okay, I get that -- but how is it different from (say) XML,
or INI files, or pickles, or similar? Is the idea to have *live* data
stored on disk, updated by multiple processes simultaneously? Don't assume
that people will remember your recommendation from "some time ago".


-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Good books in computer science?

[Steven D'Aprano]

Graham Ashton wrote:

> On 2009-06-14 14:04:02 +0100, Steven D'Aprano
>  said:
> 
>> Nathan Stoddard wrote:
>> 
>>> The best way to become a good programmer is to program. Write a lot of
>>> code; work on some large projects. This will improve your skill more
>>> than anything else.
>> 
>> I think there are about 100 million VB code-monkeys who prove that theory
>> wrong.
> 
> Really? So you don't think that the best way to get good at something
> is to practice? 

Shame on you for deliberately cutting out my more serious and nuanced answer
while leaving a silly quip. As I went on to say:

"... you can program by (almost) mindlessly following a fixed number of
recipes and patterns. This will get the job done, but it won't make you a
good programmer."

There are huge numbers (millions?) of lousy programmers who program every
single day and never become good programmers. "Practice makes perfect" only
works for mechanical skills and rote learning, neither of which are
especially applicable to good programming. (Although rote learning is
helpful for reducing the time taken to look up syntax and library
functions.) Without some level of understanding and creativity, as soon as
you hit a problem that can't be efficiently solved by one of the patterns
or recipes you've learned, you're in trouble.

All the practice in the world won't give you the discipline to write
appropriate comments, or to test your code thoroughly. Practice won't
*necessarily* make you creative -- you can't be creative in a field you
know nothing about, but having learned the language and the libraries
doesn't necessarily mean you can apply the tools to solve novel problems. 
Many programmers know a few good tricks, and try to hammer every problem
into a form that can be solved by one of the few tricks they know, no
matter whether it is appropriate or not. Witness how many people try to
write regexes to parse bracketed expressions, a problem which requires a
proper parser.

(This is not necessarily a bad thing, but it often is.)

You could write a piece of code like:

s = ""
for word in some_data:
s += " " + word

a thousand times a day, and *never* learn that this is Bad Code, because you
never profile it with more than a few thousand words and so never discover
that it's O(n**2). Eventually when it gets released into the real world,
somebody reports that it takes eight hours to process 100MB of words, and
then *some other guy* re-writes your code to use s = " ".join(words), and
you remain in blissful ignorance, happily writing your bad code every
single time.



> I think I'm paraphrasing Richard Feynman here, but the 
> only way to truly understand something is to do it.

An amazingly inappropriate quote for a *theoretical* physicist to have said.

Whether Feynman did or didn't say that, it's clearly untrue: many people do
without understanding. Many people can cook, some people are expert cooks,
but few people understand precisely what takes place when you cook food.
People can catch and throw balls, and have little or no understanding of
gravity, air-resistance, and the mechanics of their own bodies.

In fact... just before you hit Delete on this post, how about you explain
*how* you make your finger reach out and press the Delete key? You probably
move bits of your body a million times a day, and the chances are very high
that until now, you've never once noticed that you have no idea how you do
it. I think that simple fact blows out of the water the concept that doing
implies understanding.


> Obviously a bit of guided learning is a major boon, but you can't be
> practice.

I didn't say that practice was useless. Arguably, it may even be necessary
to be a good programmer. (Although less so for an unsurprising language
like Python, where it is very common to write code which works correctly
the first time.) But practice is clearly not *sufficient* to be a good
programmer. 



-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Good books in computer science?

[rustom]

On Jun 14, 6:04 pm, Steven D'Aprano
 wrote:

> I think there are about 100 million VB code-monkeys who prove that theory
> wrong.
>
> Seriously, and without denigrating any specific language, you can program by
> (almost) mindlessly following a fixed number of recipes and patterns. This
> will get the job done, but it won't make you a good programmer.

When Dijkstra was asked what next programming language to learn he
would typically recommend Latin :-)

> Really? So you don't think that the best way to get good at something
> is to practice? I think I'm paraphrasing Richard Feynman here, but the
> only way to truly understand something is to do it.

> Obviously a bit of guided learning is a major boon, but you can't be practice.

For every one Horowitz there are a thousand wannbes thumping on the
piano trying to become Horowitz.
The traction that practice gives is maximal only in the beginning.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: persistent composites

[kindly]

On Jun 14, 3:27 pm, Aaron Brady  wrote:
> Hi, please forgive the multi-posting on this general topic.
>
> Some time ago, I recommended a pursuit of keeping 'persistent
> composite' types on disk, to be read and updated at other times by
> other processes.  Databases provide this functionality, with the
> exception that field types in any given table are required to be
> uniform.  Python has no such restriction.
>
> I tried out an implementation of composite collections, specifically
> lists, sets, and dicts, using 'sqlite3' as a persistence back-end.
> It's significantly slower, but we might argue that attempting to do it
> by hand classifies as a premature optimization; it is easy to optimize
> debugged code.
>
> The essentials of the implementation are:
>   - each 'object' gets its own table.
>     = this includes immutable types
>   - a reference count table
>     = when an object's ref. count reaches zero, its table is dropped
>   - a type-map table
>     = maps object's table ID to a string of its type
>   - a single 'entry point' table, with the table ID of the entry-point
> object
>     = the entry point is the only data structure available to new
> connections.  (I imagine it will usually be a list or dict.)
>
> I will be sure to kill any interest you might have by now, by
> "revealing" a snippet of code.
>
> The object creation procedure:
>
> def new_table( self, type ):
>   ''' 'type' is a string, the name of the class the object is an
> instance of '''
>   cur= self.conn.cursor( )
>   recs= cur.execute( '''SELECT max( tableid ) FROM refcounts''' )
>   rec= cur.fetchone( )
>   if rec[ 0 ] is None:
>     obid= 0
>   else:
>     obid= rec[ 0 ]+ 1
>   cur.execute( '''INSERT INTO types VALUES( ?, ? )''', ( obid,
> type ) )
>   cur.execute( '''INSERT INTO refcounts VALUES( ?, ? )''', ( obid,
> 1 ) )
>
> The increment ref. count procedure:
>
> def incref( self, obid ):
>   cur= self.conn.cursor( )
>   recs= cur.execute( '''SELECT count FROM refcounts WHERE tableid
> = ?''', ( obid, ) )
>   rec= recs.fetchone( )
>   newct= rec[ 0 ]+ 1
>   cur.execute( '''UPDATE refcounts SET count = ? WHERE tableid = ?''',
> ( newct, obid ) )
>
> The top-level structure contains these two procedures, as well as
> 'setentry', 'getentry', and 'revive' procedures.
>
> Most notably, user-defined types are possible.  The dict is merely a
> persistent dict.  'revive' checks the global namespace by name for the
> original type, subject to the same restrictions that we all know and
> love that 'pickle' has.
>
> As usual, deadlocks and cyclic garbage pose the usual problems.  The
> approach I used last time was to maintain a graph of acquired locks,
> and merely check for cycles to avert deadlocks, which would go in a
> separate table.  For garbage, I can't find a better solution than
> Python already uses.
>
> From the 3.0 docs:
> gc.garbage
>
>     A list of objects which the collector found to be unreachable but
> could not be freed (uncollectable objects).
> ...
> Python doesn’t collect such [garbage] cycles automatically because, in
> general, it isn’t possible for Python to guess a safe order in which
> to run the __del__() methods. If you know a safe order, you can force
> the issue by examining the garbage list, and explicitly breaking
> cycles due to your objects within the list.
>
> Before I go and flesh out the entire interfaces for the provided
> types, does anyone have a use for it?

I like it as a concept, have not got any use for it this minute, but I
am sure it will be useful someday.
-- 
http://mail.python.org/mailman/listinfo/python-list

persistent composites

[Aaron Brady]

Hi, please forgive the multi-posting on this general topic.

Some time ago, I recommended a pursuit of keeping 'persistent
composite' types on disk, to be read and updated at other times by
other processes.  Databases provide this functionality, with the
exception that field types in any given table are required to be
uniform.  Python has no such restriction.

I tried out an implementation of composite collections, specifically
lists, sets, and dicts, using 'sqlite3' as a persistence back-end.
It's significantly slower, but we might argue that attempting to do it
by hand classifies as a premature optimization; it is easy to optimize
debugged code.

The essentials of the implementation are:
  - each 'object' gets its own table.
= this includes immutable types
  - a reference count table
= when an object's ref. count reaches zero, its table is dropped
  - a type-map table
= maps object's table ID to a string of its type
  - a single 'entry point' table, with the table ID of the entry-point
object
= the entry point is the only data structure available to new
connections.  (I imagine it will usually be a list or dict.)

I will be sure to kill any interest you might have by now, by
"revealing" a snippet of code.

The object creation procedure:

def new_table( self, type ):
  ''' 'type' is a string, the name of the class the object is an
instance of '''
  cur= self.conn.cursor( )
  recs= cur.execute( '''SELECT max( tableid ) FROM refcounts''' )
  rec= cur.fetchone( )
  if rec[ 0 ] is None:
obid= 0
  else:
obid= rec[ 0 ]+ 1
  cur.execute( '''INSERT INTO types VALUES( ?, ? )''', ( obid,
type ) )
  cur.execute( '''INSERT INTO refcounts VALUES( ?, ? )''', ( obid,
1 ) )

The increment ref. count procedure:

def incref( self, obid ):
  cur= self.conn.cursor( )
  recs= cur.execute( '''SELECT count FROM refcounts WHERE tableid
= ?''', ( obid, ) )
  rec= recs.fetchone( )
  newct= rec[ 0 ]+ 1
  cur.execute( '''UPDATE refcounts SET count = ? WHERE tableid = ?''',
( newct, obid ) )

The top-level structure contains these two procedures, as well as
'setentry', 'getentry', and 'revive' procedures.

Most notably, user-defined types are possible.  The dict is merely a
persistent dict.  'revive' checks the global namespace by name for the
original type, subject to the same restrictions that we all know and
love that 'pickle' has.

As usual, deadlocks and cyclic garbage pose the usual problems.  The
approach I used last time was to maintain a graph of acquired locks,
and merely check for cycles to avert deadlocks, which would go in a
separate table.  For garbage, I can't find a better solution than
Python already uses.

>From the 3.0 docs:
gc.garbage

A list of objects which the collector found to be unreachable but
could not be freed (uncollectable objects).
...
Python doesn’t collect such [garbage] cycles automatically because, in
general, it isn’t possible for Python to guess a safe order in which
to run the __del__() methods. If you know a safe order, you can force
the issue by examining the garbage list, and explicitly breaking
cycles due to your objects within the list.

Before I go and flesh out the entire interfaces for the provided
types, does anyone have a use for it?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Mel]

John Yeung wrote:

> And I accept your answer, as well as Steven's and Paul's for that
> matter.  I still think it is understandable (and people may choose to
> understand in a condescending way, if they wish) that someone might
> not get the difference between what you are saying and the statement
> that all elements of the empty set are floats.  I mean, what's in the
> empty set?  Nothing.  But you've said that floats are something.  How
> is it that nothing is something?

It's sort of a logic equivalent of divide-by-zero.

All elements of the empty set are floats.
All elements of the empty set are ints.
Ints are not floats.
Therefore all elements of the empty set are not floats.

You elaborate your logic to talk around this problem, and you quit when you 
get tired.

Mel.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Scott David Daniels]

Steven D'Aprano wrote:

... or {1}∩0. (If that character between the set and zero ends up missing,
it's meant to be INTERSECTION u'\u2229'.)

Note that you can write this in a quite readable way in ASCII:
"it's meant to be the character u'\N{INTERSECTION}'."

--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[Steven D'Aprano]

Lawrence D'Oliveiro wrote:

> In message , Peter Billam wrote:
> 
>> Are there any modules, packages, whatever, that will
>> measure the fractal dimensions of a dataset, e.g. a time-series ?
> 
> I don't think any countable set, even a countably-infinite set, can have a
> fractal dimension. It's got to be uncountably infinite, and therefore
> uncomputable.

Incorrect. Koch's snowflake, for example, has a fractal dimension of log
4/log 3 ≈ 1.26, a finite area of 8/5 times that of the initial triangle,
and a perimeter given by lim n->inf (4/3)**n. Although the perimeter is
infinite, it is countably infinite and computable.

Strictly speaking, there's not one definition of "fractal dimension", there
are a number of them. One of the more useful is the "Hausdorf dimension",
which relates to the idea of how your measurement of the size of a thing
increases as you decrease the size of your yard-stick. The Hausdorf
dimension can be statistically estimated for finite objects, e.g. the
fractal dimension of the coast of Great Britain is approximately 1.25 while
that of Norway is 1.52; cauliflower has a fractal dimension of 2.33 and
crumpled balls of paper of 2.5; the surface of the human brain and lungs
have fractal dimensions of 2.79 and 2.97.



-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Different types of dicts with letter before the curly braces.

[Aaron Brady]

On Jun 14, 6:30 am, kindly  wrote:
> On Jun 14, 1:59 pm, Steven D'Aprano
snip
> I am glad the ordered dict will be in 2.7 and 3.1. I
> was just imagining what would be the next step in definition of
> structures. New languages like clojure have adopted the dict as top
> level.  I imagine immutable/thread safe/transactional dicts to be
> around soon in other languages to help with concurrency.  It would be
> nice if python was ahead of the game in this.

Just not ahead of its /time/.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Different types of dicts with letter before the curly braces.

[kindly]

On Jun 14, 1:59 pm, Steven D'Aprano
 wrote:
> Stefan Behnel wrote:
> > Hi,
>
> > this kind of stuff is commonly discussed on the python-ideas mailing list.
> > You might want to search that list and/or repost this over there.
>
> Please don't top-post here.
>
> If the OP takes this idea to python-ideas, chances are he'll be told to take
> the concept here first, for feedback, before python-ideas.
>
> More comments below:
>
> > kindly wrote:
> >> I am sure people have thought of this before, but I cant find where.
> >> I think that python should adapt a way of defining different types of
> >> mapping functions by proceeding a letter before the curly brackets.
> >> i.e   ordered = o{},  multidict = m{}  (like paste multidict).  So you
> >> could define an ordered dict by newordered = o{"llvm" : "ptyhon",
> >> "parrot" : "perl"} .  (they should also probably have there own
> >> comprehensions as well o{foo for bar in foobar}).
>
> You can do that more readably:
>
> data = OrderedDict()
> data = SortedDict()
> data = MultiDict() etc.
>
> The advantages are:
>
> * no new syntax is needed;
>
> * you can have as many different types of mappings as needed, without
> needing to change the compiler or worry about clashes between letters;
>
> * not all mapping types necessarily have the same initialiser signature;
>
> * the mapping type doesn't need to be a built-in type.
>
> The analogy with raw strings is faulty: r"" changes the way the compiler
> interprets the characters between the quotes, it doesn't create a different
> type of object.
>
> There's nothing explicitly *wrong* with the idea of o{} m{} etc for a
> *small* number of built-in mapping types. If ordered dicts (say) ever
> become built-ins, rather than a type that you have to import from a module,
> then maybe we'll be looking for syntax for them, in which case there's
> worse ideas than o{}. But even then, a disadvantage would be that it's
> awfully perlish. There's already two uses for {}, namely dicts and sets,
> and I don't know that adding a third or more is a good idea.
>
> --
> Steven

Thank you all for your feedback.  I have never actually used perl, but
I imagine if I did, I imagine I would have more disgust at the suger.

I think my point is more that I think python should consider having
more useful top level data structures and less to do with how they are
created.  There has been a big shift in the way people pass around
structures and this is mainly due to the dict(hash) type, that python
uses so well.  I am glad the ordered dict will be in 2.7 and 3.1. I
was just imagining what would be the next step in definition of
structures. New languages like clojure have adopted the dict as top
level.  I imagine immutable/thread safe/transactional dicts to be
around soon in other languages to help with concurrency.  It would be
nice if python was ahead of the game in this.



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Different types of dicts with letter before the curly braces.

[Aaron Brady]

On Jun 14, 4:02 am, kindly  wrote:
> I am sure people have thought of this before, but I cant find where.
> I think that python should adapt a way of defining different types of
> mapping functions by proceeding a letter before the curly brackets.
> i.e   ordered = o{},  multidict = m{}  (like paste multidict).  So you
> could define an ordered dict by newordered = o{"llvm" : "ptyhon",
> "parrot" : "perl"} .  (they should also probably have there own
> comprehensions as well o{foo for bar in foobar}).

That kind of stuff is highly explosive, unfortunately.  o{ }, m{ }, d
[ ], and q[ ] are just a few.  But 'collections' is kind of sparse.  I
expect you would also want users to be able to define their own
prefixes, no?  As is, the syntax is not atrocious:

oA= OrderedDict( [ ( pair1 ), ( pair2 ) ]
oA= o{ pair1, pair2 }

At least you can still include literals, and are not restricted to per-
line additions as in C.

snip
> Most packages that I have seen re-
> implement these different container types at one point anyway. It
> seems a shame they are not brought up to the top level, with
> potentially new, cleverer ones that have not been thought of yet.
snip

Do you merely want to populate the 'collections' module, or are the
prefixes essential to your idea?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Good books in computer science?

[Christof Donat]

Hi,

> Which are the classic books in computer science which one should
> peruse?

>From having read this discussion up to now I'd recomend you to read code 
written by good programmers.

Christof


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about None

[Steven D'Aprano]

John Yeung wrote:

> Paul LaFollette is probably thinking along the lines of formal logic
> or set theory.  It's a little bit confused because programming isn't
> quite the same as math, and so it's a common question when designing
> and implementing programming languages how far to take certain
> abstractions.  In some languages, nil, null, or none will try to
> behave as mathematically close to "nothing" (complete absence of
> anything) as possible, even though in reality they have to have some
> concrete implementation, such as perhaps being a singleton object.
> But mathematically speaking, it's intuitive that "nothing" would match
> any type.

I think you're wrong. Mathematically, you can't mix types like real numbers
and sets: while 1+0 = 1, you can't expect to get a sensible result from
1+{} or {1}∩0. (If that character between the set and zero ends up missing,
it's meant to be INTERSECTION u'\u2229'.)

Similarly, you can't add a scalar to a vector or matrix, even if one or the
other is null.

 
> I find that it's somewhat like the confusion that often occurs
> regarding the all() function.  Some people are surprised that all([])
> returns True, but it's the same logic behind the truth of the
> statement "every element of the empty set is an integer".  It's also
> true that every element of the empty set is a float.  Or an elephant.

So-called "vacuous truth". It's often useful to have all([]) return true,
but it's not *always* useful -- there are reasonable cases where the
opposite behaviour would be useful:

if all(the evidence points to the Defendant's guilt) then:
the Defendant is guilty
execute(the Defendant)

sadly means that if there is no evidence that a crime has been committed,
the person accused of committing the imaginary crime will be executed.


-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Good books in computer science?

[Graham Ashton]

On 2009-06-14 14:04:02 +0100, Steven D'Aprano 
 said:



Nathan Stoddard wrote:


The best way to become a good programmer is to program. Write a lot of
code; work on some large projects. This will improve your skill more than
anything else.


I think there are about 100 million VB code-monkeys who prove that theory
wrong.


Really? So you don't think that the best way to get good at something 
is to practice? I think I'm paraphrasing Richard Feynman here, but the 
only way to truly understand something is to do it.


Obviously a bit of guided learning is a major boon, but you can't be practice.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Different types of dicts with letter before the curly braces.

[Diez B. Roggisch]

The analogy with raw strings is faulty: r"" changes the way the compiler
interprets the characters between the quotes, it doesn't create a different
type of object.


But u"" does, as does the new bytestring-literal in Python3. So there is 
precedent.


Diez
--
http://mail.python.org/mailman/listinfo/python-list

Re: Good books in computer science?

[Graham Ashton]

On 2009-06-14 03:34:34 +0100, Paul Rubin  said:


Roy Smith  writes:

In the same vein, Death March, by Ed Yourdon.


I've been wanting to read "Antipatterns".


I bought it but couldn't get into it. Light on meat, heavy on boredom 
(for me - these things are always somewhat subjective).


--
http://mail.python.org/mailman/listinfo/python-list

Re: Different types of dicts with letter before the curly braces.

[Colin J. Williams]

Stefan Behnel wrote:

Hi,

this kind of stuff is commonly discussed on the python-ideas mailing list.
You might want to search that list and/or repost this over there.

Stefan

kindly wrote:

I am sure people have thought of this before, but I cant find where.
I think that python should adapt a way of defining different types of
mapping functions by proceeding a letter before the curly brackets.
i.e   ordered = o{},  multidict = m{}  (like paste multidict).  So you
could define an ordered dict by newordered = o{"llvm" : "ptyhon",
"parrot" : "perl"} .  (they should also probably have there own
comprehensions as well o{foo for bar in foobar}).

People nowadays think in terms of hashes and lists (especially with
jsons and javascript not going away} and most of my time seems to be
spent in different ways to store bits of data in memory in this way.
It also seems to be the way to think in python (an object or a class
object are just mappings themselves) Most packages that I have seen re-
implement these different container types at one point anyway. It
seems a shame they are not brought up to the top level, with
potentially new, cleverer ones that have not been thought of yet.
There will be potential to add different letters to the start when it
seems that a certain mapping pattern seems in popular use.

Am I crazy to think this is a good idea?  I have not looked deeply
pythons grammer to see if it conflicts with anything, but on the
surface it looks fine.


This has some appeal in the light of Python 3.1's ordered dictionary.

Colin W.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Good books in computer science?

[Steven D'Aprano]

Nathan Stoddard wrote:

> The best way to become a good programmer is to program. Write a lot of
> code; work on some large projects. This will improve your skill more than
> anything else.

I think there are about 100 million VB code-monkeys who prove that theory
wrong.

Seriously, and without denigrating any specific language, you can program by
(almost) mindlessly following a fixed number of recipes and patterns. This
will get the job done, but it won't make you a good programmer.


-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Perl's @foo[3,7,1,-1] ?

[Steven D'Aprano]

kj wrote:

> OK, I see: if Python allowed foo[3,7,1,-1], then foo[3] would be
> ambiguous: does it mean the fourth element of foo, or the tuple
> consisting of this element alone?  I suppose that's good enough
> reason to veto this idea...

There's nothing ambiguous about it. obj.__getitem__(x) already accepts two
different sorts of objects for x: ints and slice-objects:

>>> range(8)[3]
3
>>> range(8)[slice(3)]
[0, 1, 2]
>>> range(8)[slice(3, None)]
[3, 4, 5, 6, 7]
>>> range(8)[slice(3, 4)]
[3]


Allowing tuple arguments need not be ambiguous:

range(8)[3] => 3
range(8)[(3,)] => [3]
range(8)[(3,5,6)] => [3, 5, 6]


I've rarely needed to grab arbitrary items from a list in this fashion. I
think a more common case would be extracting fields from a tuple. In any
case, there are a few alternatives:


Grab them all, and ignore some of them (ugly for more than one or two
ignorable items):

_, x, _, _, y, _, _, _, z, _ = range(10)  # x=1, y=4, z=9


Subclass list to allow tuple slices:

>>> class MyList(list):
... def __getitem__(self, obj):
... if type(obj) is tuple:
... return [self[i] for i in obj]
... else:
... return list.__getitem__(self, obj)
...
>>> L = MyList(range(10))
>>> L[(1, 4, 8)]
[1, 4, 8]


Write a helper function:

def getitems(L, *indexes):
if len(indexes) == 1:
indexes = indexes[0]
return [L[i] for i in indexes]


But I think this is an obvious enough extension to the __getitem__ protocol
that I for one would vote +1 on it being added to Python sequence objects
(lists, tuples, strings).


-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Different types of dicts with letter before the curly braces.

[Steven D'Aprano]

Stefan Behnel wrote:

> Hi,
> 
> this kind of stuff is commonly discussed on the python-ideas mailing list.
> You might want to search that list and/or repost this over there.

Please don't top-post here.

If the OP takes this idea to python-ideas, chances are he'll be told to take
the concept here first, for feedback, before python-ideas.

More comments below:


> kindly wrote:
>> I am sure people have thought of this before, but I cant find where.
>> I think that python should adapt a way of defining different types of
>> mapping functions by proceeding a letter before the curly brackets.
>> i.e   ordered = o{},  multidict = m{}  (like paste multidict).  So you
>> could define an ordered dict by newordered = o{"llvm" : "ptyhon",
>> "parrot" : "perl"} .  (they should also probably have there own
>> comprehensions as well o{foo for bar in foobar}).

You can do that more readably:

data = OrderedDict()
data = SortedDict()
data = MultiDict() etc.

The advantages are:

* no new syntax is needed;

* you can have as many different types of mappings as needed, without
needing to change the compiler or worry about clashes between letters;

* not all mapping types necessarily have the same initialiser signature;

* the mapping type doesn't need to be a built-in type.


The analogy with raw strings is faulty: r"" changes the way the compiler
interprets the characters between the quotes, it doesn't create a different
type of object.

There's nothing explicitly *wrong* with the idea of o{} m{} etc for a
*small* number of built-in mapping types. If ordered dicts (say) ever
become built-ins, rather than a type that you have to import from a module,
then maybe we'll be looking for syntax for them, in which case there's
worse ideas than o{}. But even then, a disadvantage would be that it's
awfully perlish. There's already two uses for {}, namely dicts and sets,
and I don't know that adding a third or more is a good idea.


-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Different types of dicts with letter before the curly braces.

[Mike Kazantsev]

On Sun, 14 Jun 2009 04:36:17 -0700 (PDT)
kindly  wrote:

> Python already has it for strings r"foo" or u"bar".  So I do not think
> its going against the grain.



Yes, and there's other syntactic sugar like ";" (barely used),
mentioned string types, "(element,)", "%s"%var or curly braces
themselves.

Some of them might even seem as unnecessary and redundant, but they
should there to support legacy code, at least, and I don't think it's a
good idea to add any more. In fact, py3 will drop "%s"%var syntax in
favor of "{0}".format(var) and I think it's a good call.

There's only so much sugar to add before it'll transform into salt and
you'll start seeing lines like these:

s**'@z!~;()=~$x>;%x>l;$(,'*e;y*%z),$;@=!;h(l~;*punch jokers;halt;*;print;

I'm happy to use python because it discourages such syntax, among other things.



-- 
Mike Kazantsev // fraggod.net


signature.asc
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[Paul Rubin]

Arnaud Delobelle  writes:
> I think there are attempts to estimate the fractal dimension of a set
> using a finite sample from this set.  But I can't remember where I got
> this thought from!

There are image data compression schemes that work like that, trying
to detect self-similarity in the data.  It can go the reverse way too.
There was a program called Genuine Fractals that tried to increase the
apparent resolution of photographs by adding artificial detail
constructed from detected self-similarity.  Its results were mixed, as
I remember.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[Arnaud Delobelle]

Lawrence D'Oliveiro  writes:

> In message , Peter Billam wrote:
>
>> Are there any modules, packages, whatever, that will
>> measure the fractal dimensions of a dataset, e.g. a time-series ?
>
> I don't think any countable set, even a countably-infinite set, can have a 
> fractal dimension. It's got to be uncountably infinite, and therefore 
> uncomputable.

I think there are attempts to estimate the fractal dimension of a set
using a finite sample from this set.  But I can't remember where I got
this thought from!

-- 
Arnaud
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Off-topic: Usenet archiving history

[David Bolen]

Ben Finney  writes:

> David Bolen  writes:
>
>> Individual messages could include an Expires: header if they wished,
>
> Since we're already well off-topic: NNTP, HTTP, and email, and probably
> other protocols as well, all deal with messages. They are all consistent
> in defining a message [0] as having *exactly one* header.

Heh, I'm not sure it's quite as consistent as you may think,
particularly with older RFCs, which are relevant in this discussion
since we're talking about historical artifacts.

For example, while more recent mail RFCs like 2822 may specifically
talk about header fields as the "header" (singular) of the message,
the older RFC 822 instead refers to a "headers" (plural) section.

> Every time you call a field from the header “a header”, or refer to
> the plural “headers of a message”, the IETF kills a kitten. You
> don't want to hurt a kitten, do you?

Heaven forbid - though I'd think I could hold my own with the IETF.
My reference to "header" was in lieu of "header line", something that
the Usenet RFCs (1036, and the older 850) do extensively themselves.

But I'll be more careful in the future - need to ensure kitten safety!

-- David
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Good books in computer science?

[Roy Smith]

In article <7x4ouj7dc5@ruckus.brouhaha.com>,
 Paul Rubin  wrote:

> Roy Smith  writes:
> > In the same vein, Death March, by Ed Yourdon.
> 
> I've been wanting to read "Antipatterns".

I didn't think that was so great.  It had a lot of hype, which lead to be 
believe it would be something wonderful, but I wasn't so impressed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Different types of dicts with letter before the curly braces.

[Stefan Behnel]

Hi,

this kind of stuff is commonly discussed on the python-ideas mailing list.
You might want to search that list and/or repost this over there.

Stefan

kindly wrote:
> I am sure people have thought of this before, but I cant find where.
> I think that python should adapt a way of defining different types of
> mapping functions by proceeding a letter before the curly brackets.
> i.e   ordered = o{},  multidict = m{}  (like paste multidict).  So you
> could define an ordered dict by newordered = o{"llvm" : "ptyhon",
> "parrot" : "perl"} .  (they should also probably have there own
> comprehensions as well o{foo for bar in foobar}).
> 
> People nowadays think in terms of hashes and lists (especially with
> jsons and javascript not going away} and most of my time seems to be
> spent in different ways to store bits of data in memory in this way.
> It also seems to be the way to think in python (an object or a class
> object are just mappings themselves) Most packages that I have seen re-
> implement these different container types at one point anyway. It
> seems a shame they are not brought up to the top level, with
> potentially new, cleverer ones that have not been thought of yet.
> There will be potential to add different letters to the start when it
> seems that a certain mapping pattern seems in popular use.
> 
> Am I crazy to think this is a good idea?  I have not looked deeply
> pythons grammer to see if it conflicts with anything, but on the
> surface it looks fine.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Different types of dicts with letter before the curly braces.

[kindly]

On Jun 14, 12:25 pm, Mike Kazantsev  wrote:
> On Sun, 14 Jun 2009 04:02:47 -0700 (PDT)
>
> kindly  wrote:
> > Am I crazy to think this is a good idea?  I have not looked deeply
> > pythons grammer to see if it conflicts with anything, but on the
> > surface it looks fine.
>
> I'd say "on the surface it looks like perl" ;)
> I'd prefer to use dict() to declare a dict, not some mix of letters and
> incomprehensible symbols, thank you.
>
> --
> Mike Kazantsev // fraggod.net
>
>  signature.asc
> < 1KViewDownload

Python already has it for strings r"foo" or u"bar".  So I do not think
its going against the grain.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Different types of dicts with letter before the curly braces.

[Mike Kazantsev]

On Sun, 14 Jun 2009 04:02:47 -0700 (PDT)
kindly  wrote:

> Am I crazy to think this is a good idea?  I have not looked deeply
> pythons grammer to see if it conflicts with anything, but on the
> surface it looks fine.

I'd say "on the surface it looks like perl" ;)
I'd prefer to use dict() to declare a dict, not some mix of letters and
incomprehensible symbols, thank you.

-- 
Mike Kazantsev // fraggod.net


signature.asc
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Different types of dicts with letter before the curly braces.

[kindly]

I am sure people have thought of this before, but I cant find where.
I think that python should adapt a way of defining different types of
mapping functions by proceeding a letter before the curly brackets.
i.e   ordered = o{},  multidict = m{}  (like paste multidict).  So you
could define an ordered dict by newordered = o{"llvm" : "ptyhon",
"parrot" : "perl"} .  (they should also probably have there own
comprehensions as well o{foo for bar in foobar}).

People nowadays think in terms of hashes and lists (especially with
jsons and javascript not going away} and most of my time seems to be
spent in different ways to store bits of data in memory in this way.
It also seems to be the way to think in python (an object or a class
object are just mappings themselves) Most packages that I have seen re-
implement these different container types at one point anyway. It
seems a shame they are not brought up to the top level, with
potentially new, cleverer ones that have not been thought of yet.
There will be potential to add different letters to the start when it
seems that a certain mapping pattern seems in popular use.

Am I crazy to think this is a good idea?  I have not looked deeply
pythons grammer to see if it conflicts with anything, but on the
surface it looks fine.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: error: an integer is required

[jeni]

On 8 Ιούν, 21:46, Terry Reedy  wrote:
> madigre...@yahoo.gr wrote:
> > I execute my code in linux environment.
> > My code is:
>
> > from os import *
>
> > def insert_text_file(self, strng):
> >      t=open("elements_file.txt", "a")
> >      t.write(strng)
> >      t.close()
>
> > I'm getting this error:
>
> > : an integer is required
>
> > Where is the mistake?
> > Help me, please!!
>
> Tell us the Python version and give the *full* traceback message, not
> just the last line.  I am pretty sure you also left out an important
> part of the code you executed to get that message.
>
> tjr- Απόκρυψη κειμένου σε παράθεση -
>
> - Εμφάνιση κειμένου σε παράθεση -

With both import os and os.open there is the same error. I have
developed in python a game for OPLC. When I run the game in Python
2.5.2 at Windows there is no problem. But after I play a game at OLPC
I get the following message:


 Traceback (most recent call last)

/home/olpc/Activities/Kremala.activity/Kremala.py in add_letter
(self=, widget=,
grama='i')
-->   self.find_w()
  self.find_w=>

/home/Activities/Kremala.activity/Kremala.py in find_w
(self=)
  self.show_gr()
--> self.sosti_leksi()
   self.sosti_leksi==>

/home/Activities/Kremala.activity/Kremala.py in sosti_leksi
(self=)
  s=self.categ+":"+str(1)+" nikh me "+str(6-self.m)+"prospatheies
\n"
--> self.insert_text_file(s)
self.insert_text_file===>

/home/Activities/Kremala.activity/Kremala.py in insert_text_file
(self=, strng='geografia:1 nikh me 2 prospatheies\n')
-->  t=open("elements_file.txt", "a")
global open=
  t.write(strng)
  t.close()

: an integer is required

OLPC's software is important?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: TypeError: int argument required

[Lawrence D'Oliveiro]

In message , Rhodri 
James wrote:

> 2.  That output string has severe "leaning toothpick" syndrome.  Python
> accepts both single and double quotes to help avoid creating something
> so unreadable: use them.

Backslashes are more scalable.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: random number including 1 - i.e. [0,1]

[Lawrence D'Oliveiro]

In message , Esmail wrote:

> Here is part of the specification of an algorithm I'm implementing that
> shows the reason for my original query:
> 
> vid = w * vid + c1 * rand( ) * ( pid – xid ) + c2 * Rand( ) * (pgd –xid ) (1a)
> 
> xid = xid + vid (1b)

Are the terms meant to be clamped to a particular range of values? Otherwise it 
probably doesn't matter.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: random number including 1 - i.e. [0,1]

[Lawrence D'Oliveiro]

In message , Esmail 
wrote:

> I'm implementing a Particle Swarm Optimizer. Depending on what paper you
> read you'll see mention of required random values "between 0 and 1"
> which is somewhat ambiguous. I came across one paper that specified
> the range [0,1], so inclusive 1, which was the reason for my question.

Sounds like some of their descriptions are a bit sloppy. Maybe best to clear 
it up by trying to think what a value of exactly or exactly 1 for the random 
value might mean: are those boundaries meant to be inside the set, or 
outside? Is it meaningful to concatenate two adjacent intervals? In that 
case any point can only belong to one of the intervals, not both.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: random number including 1 - i.e. [0,1]

[Lawrence D'Oliveiro]

In message , Jussi Piitulainen wrote:

> Miles Kaufmann writes:
>
>> I'm curious what algorithm calls for random numbers on a closed
>> interval.
> 
> The Box-Muller transform, polar form. At least Wikipedia says so.

Doesn't seem to be necessary, if I interpret the following correctly 
:

Given u and v, independent and uniformly distributed in the closed
interval [−1, +1], set s = R2 = u2 + v2. (Clearly \scriptstyle R =
\sqrt{s}.) If s = 0 or s > 1, throw u and v away and try another pair
(u, v). Continue until a pair with s in the open interval (0, 1) is
found. 

Since s is supposed to be in an open interval, I don't see how it makes any 
difference if u and v are chosen from an open or semiopen interval. The 
probability of hitting the exact endpoints is 0, after all.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[Lawrence D'Oliveiro]

In message , Peter Billam wrote:

> Are there any modules, packages, whatever, that will
> measure the fractal dimensions of a dataset, e.g. a time-series ?

I don't think any countable set, even a countably-infinite set, can have a 
fractal dimension. It's got to be uncountably infinite, and therefore 
uncomputable.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Good books in computer science?

[Lawrence D'Oliveiro]

In message , koranthala wrote:

> I do have Mythical Man-Month - a great book indeed.
> I was looking for more technical books ...

No-one has mentioned Andrew Tanenbaum's "Computer Networks". So much of 
programming seems to involve networking these days, I think the current 
(4th) edition is a great introduction to how to think in network terms, 
particularly about security issues.


-- 
http://mail.python.org/mailman/listinfo/python-list

ANN: pyTenjin 0.8.1 - much faster template engine than Django

[kwatch]

I released pyTenjin 0.8.1.
http://www.kuwata-lab.com/tenjin/
http://pypi.python.org/pypi/Tenjin/

pyTenjin is the fastest template engine for Python.

* Very fast (about 10 times faster than Django template engine)
* Easy to learn (no need to learn template-original language)
* Full-featured (layout template, partial template,
preprocessing, ...)
* Very small (only 1,200 lines, one file)

This is a bug fix release.
See CHANGES for details.
  http://www.kuwata-lab.com/tenjin/pytenjin-CHANGES.txt


Bugfix from 0.8.1
-

  * Fix bugs on CacheStorage#unset(). (thanks Steve)

  * Fix tenjin.helpers.html.new_cycle() to work on Python 3.0.


Changes from 0.8.1
--

  * Update 'doc/faq.html' and add new section.
'Is it possible to change indent restriction more flexible?'
http://www.kuwata-lab.com/tenjin/pytenjin-faq.html#faq-flexibleindent


Documents
-

  * User's Guide
  http://www.kuwata-lab.com/tenjin/pytenjin-users-guide.html
  * FAQ
  http://www.kuwata-lab.com/tenjin/pytenjin-faq.html
  * CHANGES
  http://www.kuwata-lab.com/tenjin/pytenjin-CHANGES.txt


Have fun!

--
regards,
makoto kuwata
-- 
http://mail.python.org/mailman/listinfo/python-list