Re: When are immutable tuples *essential*? Why can't you just use lists *everywhere* instead?

[pdpi]

Iou need only consider having cartesian coordinate sets as the keys
for an example. A 2 dimensional list might be overly expensive if your
coordinates span a large area but are relatively sparse.

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

Re: Can I get a technical explanation on the following error

[pdpi]

On May 24, 6:41 pm, grocery_stocker  wrote:
> How come something like '\'  causes an error? Here is what I mean.
>
> [cdal...@localhost ~]$ python
> Python 2.6.2 (r262:71600, May  3 2009, 17:04:44)
> [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.>>> 
> print "test \"
>
>   File "", line 1
>     print "test \"
>                  ^
> SyntaxError: EOL while scanning string literal
>
>
>
> I mean, isn't the '\' a character just like the letter 't'?

Ask yourself: 'How would I tell Python to print the " character when
it's used as the string delimitation character?'. Unlike us (you
probably didn't even blink at the usage of ' in "it's" versus its
usage as quote delimiters in that sentence), computers can't quite
tell usage from context. So you have to come up with a way to express
ourselves. Many languages use the \ character as an escape character,
which modifies the meaning of the next character in a string. \n, \t,
\" are all common. Other languages use other conventions -- I program
ABAP professionally, and it uses ' as the string delimiter, and '' as
a literal -- so a string with one single ' is expressed as .

The python interpreter isn't doing any bit magic here, it's just
reading a \ character followed by a " character and changing its
interpretation of " appropriately.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: import sqlite3

[pdpi]

On Jun 4, 12:45 pm, willgun  wrote:
> By the way ,what does 'best regards' means at the end of a mail?

"regard" means roughly "care".

Its use as "best regards" closing a letter (or, in this case, email),
means that you care for the person you're saying goodbye to. It's just
a polite way to end a letter :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[pdpi]

On Jun 15, 5:55 am, Steven D'Aprano
 wrote:
> 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

You're mixing up the notion of countability. It only applies to set
sizes. Unless you're saying that there an infinite series has a
countable number of terms (a completely trivial statement), to say
that the length is "countably finite" simply does not parse correctly
(let alone being semantically correct or not). This said, I agree with
you: I reckon that the Koch curve, while composed of uncountable
cardinality, is completely described by the vertices, so a countable
set of points. It follows that you must be able to correctly calculate
the Hausdorff dimension of the curve from those control points alone,
so you should also be able to estimate it from a finite sample (you
can arguably infer self-similarity from a limited number of self-
similar generations).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to stop a function execution like...

[pdpi]

On Jun 16, 12:45 pm, "Diez B. Roggisch"  wrote:
> Gaudha wrote:
> > Is there any built-in function to stop execution of a function similar
> > to stop the program execution by sys.exit?
> > In the example below, I want to skip statement 2... if the 'if'
> > condition is satisfied.
> > Don't advice me to put statement 2 in 'else' block. That's not my
> > intention.
>
> Why not? It's from all you tell us perfectly the right thing to do.
>

If I understood his post correctly, it's because he really wants to
exit the function early.
If that is the case, in his real situation rather than the tiny
example he posted, using the else clause would translate into:

def funct(params):
  if a:
something
  else:
rest of the function
goes here
and it goes on for a while
so you just burnt through
an indentation level needlessly

Now we can have a nice philosophical discussion about how using the
else version makes the execution outline more obvious :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Need to know if a file as only ASCII charaters

[pdpi]

On Jun 16, 2:17 pm, Dave Angel  wrote:
> Jorge wrote:
> > Hi there,
> > I'm making  a application that reads 3 party generated ASCII files, but some
> > times
> > the files are corrupted totally or partiality and I need to know if it's a
> > ASCII file with *nix line terminators.
> > In linux I can run the file command but the applications should run in
> > windows.
>
> > Any help will be great.
>
> > Thank you in advance.
>
> So, which is the assignment:
>    1) determine if a file has non-ASCII characters
>    2) determine whether the line-endings are crlf or just lf
>
> In the former case, look at translating the file contents to Unicode,
> specifying ASCII as source.  If it fails, you have non-ASCII
> In the latter case, investigate the 'u' attribute of the mode parameter
> in the open() function.
>
> You also need to ask yourself whether you're doing a validation of the
> file, or doing a "best guess" like the file command.

>From your requisites, you're already assuming something that _should_
be ASCII, so it's easiest to check for ASCIIness at the binary level:

Open the file as binary
Loop at the bytes
  exit with error upon reading a byte outside the printable range
(32-126 decimal)
  or any of a number of lower-range exceptions (\n, \t -- not \r since
you want UNIX-style linefeeds)
exit with success if the loop ended cleanly

This supposes you're dealing strictly with ASCII, and not a full 8 bit
codepage, of course.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: question about a command like 'goto ' in Python's bytecode orit's just a compiler optimization?

[pdpi]

On Jun 17, 9:01 am, "Hendrik van Rooyen"  wrote:
>  "Diez B. Roggisch"  wrote:
>
> > Getting a depression because of a compiler is a bit strong...
>
> > However, yes, bytecode is similar to assembler, and in that respect
> > higher-level control-structures are created using (conditional) jumps.
>
> > The same is true for other bytecode-languages, see here for the JVM:
>
> >http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc
>
> This is right.
>
> It is my opinion that it is not possible to make a useful machine,
> virtual or real, which executes instructions sequentially, if the
> instruction set does not contain a conditional jump of some sort.
>
> I have tried doing it using conditional calls, and it fails on
> the equivalent of the first if ..., elif ...  you try to write.
>
> - Hendrik

Not a matter of opinion. One of the requisite elements of a Turing
Machine is conditional jumping.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[pdpi]

On Jun 17, 4:18 pm, Mark Dickinson  wrote:
> On Jun 17, 3:46 pm, Paul Rubin  wrote:
>
> > Mark Dickinson  writes:
> > > It looks as though you're treating (a portion of?) the Koch curve as
> > > the graph of a function f from R -> R and claiming that f is
> > > uniformly continuous.  But the Koch curve isn't such a graph (it
> > > fails the 'vertical line test',
>
> > I think you treat it as a function f: R -> R**2 with the usual
> > distance metric on R**2.
>
> Right.  Or rather, you treat it as the image of such a function,
> if you're being careful to distinguish the curve (a subset
> of R^2) from its parametrization (a continuous function
> R -> R**2).  It's the parametrization that's uniformly
> continuous, not the curve, and since any curve can be
> parametrized in many different ways any proof of uniform
> continuity should specify exactly which parametrization is
> in use.
>
> Mark

I was being incredibly lazy and using loads of handwaving, seeing as I
posted that (and this!) while procrastinating at work.

an even lazier argument: given the _/\_ construct, you prove that its
vertical growth is bound: the height of / is less than 1/3 (given a
length of 1 for ___), so, even if you were to build _-_ with the
middle segment at height = 1/3, the maximum vertical growth would be
sum 1/3^n from 1 to infinity, so 0.5. Sideways growth has a similar
upper bound. 0.5 < 1, so the chebyshev distance between any two points
on the curve is <= 1. Ergo, for any x,y, f(x) is at most at chebyshev
distance 1 of (y). Induce the argument for "smaller values of one".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exotic Logics

[pdpi]

On Jun 17, 5:37 pm, Lie Ryan  wrote:
> Steven D'Aprano wrote:
> > On Tue, 16 Jun 2009 22:46:14 -0700, William Clifford wrote:
>
> >> I was staring at a logic table the other day, and I asked myself, "what
> >> if one wanted to play with exotic logics; how might one do it?"
>
> > This might be useful for you, and if not useful, at least it might blow
> > your mind like it did mine.
>
> > (This is not original to me -- I didn't create it. However, I can't find
> > the original source.)
>
> > Imagine for a moment that there are no boolean values.
> > There are no numbers.  They were never invented.
> > There are no classes.
> > There are no objects.
> > There are only functions.
>
> > Could you define functions that act like boolean values? And could you
> > define other functions to operate on them?
>
> > def true(x, y):
> >     return x
>
> > def false(x, y):
> >     return y
>
> > def print_bool(b):
> >     print b("true", "false")
>
> String isn't considered object?
>
> Also, b/true()/false() is a function object, isn't it? Unless function
> is first-class, you can't pass them around like that, since you need a
> function pointer (a.k.a number); but if function is first-class then
> there it is an object.

What Steven was doing was implementing some of the more basic stuff
from Lambda calculus in python. If you're implementing a different
system in an existing language, you'll need to use _some_ facilities
of the original language to interface with the outside world. Anyway,
here's a sample interactive session I just tried:

>>> def a(stuff):
... print stuff
...
>>> def b(stuff):
...  stuff("abc")
...
>>> b(a)
abc

functions are first-class citizens in python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: fastest native python database?

[pdpi]

On Jun 18, 8:09 am, Pierre Quentel  wrote:
> On 18 juin, 05:28, per  wrote:
>
>
>
>
>
> > hi all,
>
> > i'm looking for a native python package to run a very simple data
> > base. i was originally using cpickle with dictionaries for my problem,
> > but i was making dictionaries out of very large text files (around
> > 1000MB in size) and pickling was simply too slow.
>
> > i am not looking for fancy SQL operations, just very simple data base
> > operations (doesn't have to be SQL style) and my preference is for a
> > module that just needs python and doesn't require me to run a separate
> > data base like Sybase or MySQL.
>
> > does anyone have any recommendations? the only candidates i've seen
> > are snaklesql and buzhug... any thoughts/benchmarks on these?
>
> > any info on this would be greatly appreciated. thank you
>
> Hi,
>
> buzhug syntax doesn't use SQL statements, but a more Pythonic syntax :
>
> from buzhug import Base
> db = Base('foo').create(('name',str),('age',int))
> db.insert('john',33)
> # simple queries
> print db(name='john')
> # complex queries
> print [ rec.name for rec in db if age > 30 ]
> # update
> rec.update(age=34)
>
> I made a few speed comparisons with Gadfly, KirbyBase (another pure-
> Python DB, not maintained anymore) and SQLite. You can find the
> results on the buzhug home page :http://buzhug.sourceforge.net
>
> The conclusion is that buzhug is much faster than the other pure-
> Python db engines, and (only) 3 times slower than SQLite
>
> - Pierre

Which means that, at this point in time, since both gadfly and sqlite
use approximately the same API, sqlite takes the lead as a core
package (post-2.5 anyway)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[pdpi]

On Jun 17, 1:26 pm, Jaime Fernandez del Rio 
wrote:
> P.S. The snowflake curve, on the other hand, is uniformly continuous, right?


The definition of uniform continuity is that, for any epsilon > 0,
there is a delta > 0 such that, for any x and y, if x-y < delta, f(x)-f
(y) < epsilon. Given that Koch's curve is shaped as recursion over the
transformation from ___ to _/\_, it's immediately obvious that, for a
delta of at most the length of , epsilon will be at most the
height of /. It follows that, inversely, for any arbitrary epsilon,
you find the smallest / that's still taller than epsilon, and delta is
bound by the respective . (hooray for ascii demonstrations)

Curiously enough, it's the recursive/self-similar nature of the Koch
curve so easy to prove as uniformly continuous.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Once again, comparison wxpython with PyQt

[pdpi]

On Jun 18, 3:49 pm, "Diez B. Roggisch"  wrote:
> Hans Müller wrote:
> > Here we have to select between wxPython and PyQt for a medium size
> > project. In this project several hundred dialogs are to be created. This
> > work will be done by a program generator which has to re-written.
>
> > The question now is which framework should we use.
> > As far as I could found is PyQt with the Qt Framework the superior choice.
> > Most articles I found (not all) results to PyQt.
> > But Qt is expensive ~ 3400€ per Developer and OS.
>
> No, it's not. It is LGPL by now.
>
> You will have to pay licensing for *PyQT*. I'm not sure, but I *think* it's
> about 500€. However, it is much less than Qt used to be.
>
> Diez

Not quite. You only have to pay for the commercial license -- you can
use PyQT as GPL as well. This may or may not be acceptable for Hans's
purposes, but nowhere near "have to pay licensing".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[pdpi]

On Jun 19, 8:13 pm, Charles Yeomans  wrote:
> On Jun 19, 2009, at 2:43 PM, David C. Ullrich wrote:
>
>
>
>
>
> > Evidently my posts are appearing, since I see replies.
> > I guess the question of why I don't see the posts themselves
> > \is ot here...
>
> > On Thu, 18 Jun 2009 17:01:12 -0700 (PDT), Mark Dickinson
> >  wrote:
>
> >> On Jun 18, 7:26 pm, David C. Ullrich   
> >> wrote:
> >>> On Wed, 17 Jun 2009 08:18:52 -0700 (PDT), Mark Dickinson
>  Right.  Or rather, you treat it as the image of such a function,
>  if you're being careful to distinguish the curve (a subset
>  of R^2) from its parametrization (a continuous function
>  R -> R**2).  It's the parametrization that's uniformly
>  continuous, not the curve,
>
> >>> Again, it doesn't really matter, but since you use the phrase
> >>> "if you're being careful": In fact what you say is exactly
> >>> backwards - if you're being careful that subset of the plane
> >>> is _not_ a curve (it's sometimes called the "trace" of the curve".
>
> >> Darn.  So I've been getting it wrong all this time.  Oh well,
> >> at least I'm not alone:
>
> >> "De?nition 1. A simple closed curve J, also called a
> >> Jordan curve, is the image of a continuous one-to-one
> >> function from R/Z to R2. [...]"
>
> >> - Tom Hales, in 'Jordan's Proof of the Jordan Curve Theorem'.
>
> >> "We say that Gamma is a curve if it is the image in
> >> the plane or in space of an interval [a, b] of real
> >> numbers of a continuous function gamma."
>
> >> - Claude Tricot, 'Curves and Fractal Dimension' (Springer, 1995).
>
> >> Perhaps your definition of curve isn't as universal or
> >> 'official' as you seem to think it is?
>
> > Perhaps not. I'm very surprised to see those definitions; I've
> > been a mathematician for 25 years and I've never seen a
> > curve defined a subset of the plane.
>
> I have.
>
>
>
>
>
>
>
> > Hmm. You left out a bit in the first definition you cite:
>
> > "A simple closed curve J, also called a Jordan curve, is the image
> > of a continuous one-to-one function from R/Z to R2. We assume that
> > each curve
> > comes with a fixed parametrization phi_J : R/Z ->¨ J. We call t in R/Z
> > the time
> > parameter. By abuse of notation, we write J(t) in R2 instead of phi_j
> > (t), using the
> > same notation for the function phi_J and its image J."
>
> > Close to sounding like he can't decide whether J is a set or a
> > function...
>
> On the contrary, I find this definition to be written with some care.

I find the usage of image slightly ambiguous (as it suggests the image
set defines the curve), but that's my only qualm with it as well.

Thinking pragmatically, you can't have non-simple curves unless you
use multisets, and you also completely lose the notion of curve
orientation and even continuity without making it a poset. At this
point in time, parsimony says that you want to ditch your multiposet
thingie (and God knows what else you want to tack in there to preserve
other interesting curve properties) and really just want to define the
curve as a freaking function and be done with it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[pdpi]

On Jun 23, 6:49 pm, Lie Ryan  wrote:
> Mark Dickinson wrote:
> > On Jun 23, 3:52 am, Steven D'Aprano
> >  wrote:
> >> On Mon, 22 Jun 2009 13:43:19 -0500, David C. Ullrich wrote:
> >>> In my universe the standard definition of "log" is different froim what
> >>> log means in a calculus class
> >> Now I'm curious what the difference is.
>
> > It's just the usual argument about whether 'log' means
> > log base 10 or log base e (natural log).  At least in the
> > US, most[*] calculus texts (and also most calculators),
> > for reasons best known to themselves, use 'ln' to mean
> > natural log and 'log' to mean log base 10.  But most
> > mathematicians use 'log' to mean natural log:  pick up a
> > random pure mathematics research paper that has the word
> > 'log' in it, and unless it's otherwise qualified, it's
> > safe to assume that it means log base e.  (Except in the
> > context of algorithmic complexity, where it might well
> > mean log base 2 instead...)
>
> I usually use log without explicit base only when the base isn't
> relevant in the context (i.e. when whatever sane base you put in it
> wouldn't really affect the operations). In algorithmic complexity, a
> logarithm's base doesn't affect the growth shape and, like constant
> multiplier, is considered irrelevant to the complexity.
>
> > Python also suffers a bit from this confusion:  the
> > Decimal class defines methods 'ln' and 'log10', while
> > the math module and cmath modules define 'log' and
> > 'log10'.  
>
> In fact, in the Decimal class there is no log to an arbitrary base.
>
> > (But the Decimal module has other problems,
> > like claiming that 0**0 is undefined while
> > infinity**0 is 1.)
>
> Well, in math inf**0 is undefined. Since python is programming language,
> and in language standards it is well accepted that undefined behavior
> means implementations can do anything they like including returning 0,
> 1, 42, or even spitting errors, that doesn't make python non-conforming
> implementation.
>
> A more serious argument: in IEEE 745 float, inf**0 is 1. Mathematic
> operation in python is mostly a wrapper for the underlying C library's
> sense of math.
>
>
>
> > [*] A notable exception is Michael Spivak's 'Calculus', which also
> > happens to be the book I learnt calculus from many years ago.

Well, AFAIK Python defines CPython as the standard. So whatever
CPython does is the defined behaviour.

Regarding inf ** 0, why does IEEE745 define it as 1, when there is a
perfectly fine NaN value?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[pdpi]

On Jun 24, 2:58 pm, "Hendrik van Rooyen"  wrote:
> "Steven D'Aprano"  wrote:
> >On Mon, 22 Jun 2009 13:43:19 -0500, David C. Ullrich wrote:
>
> >> In my universe the standard definition of "log" is different froim what
> >> log means in a calculus class
>
> >Now I'm curious what the difference is.
>
> Maybe he is a lumberjack, and quite all right...
>
> - Hendrik

Or perhaps he works in a sewage facility.

But yeah, Log2 and LogE are the only two bases that make "natural"
sense except in specialized contexts. Base 10 (and, therefore, Log10)
is an artifact of having that 10 fingers (in fact, whatever base you
use, you always refer to it as base 10).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[pdpi]

On Jun 24, 1:32 pm, Mark Dickinson  wrote:
> On Jun 24, 10:12 am, pdpi  wrote:
>
> > Regarding inf ** 0, why does IEEE745 define it as 1, when there is a
> > perfectly fine NaN value?
>
> Other links:  the IEEE 754 revision working group mailing list
> archives are public;  there was extensive discussion about
> special values of pow and similar functions.  Here's a relevant
> Google search:
>
> http://www.google.com/search?q=site:grouper.ieee.org++pow+annex+D
>
> The C99 rationale document has some explanations for the
> choices for special values in Annex F.  Look at pages 179--182
> in:
>
> http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
>
> Note that the original IEEE 754-1985 didn't give specifications
> for pow and other transcendental functions;  so a complete
> specification for pow appeared in the C99 standard before it
> appeared in the current IEEE standard, IEEE 754-2008.  Thus
> C99 Annex F probably had at least some small influence on the
> choices made for IEEE 754-2008 (and in turn, IEEE 754-1985
> heavily influenced C99 Annex F).
>
> My own take on all this, briefly:
>
>  - floating-point numbers are not real numbers, so mathematics
>    can only take you so far in deciding what the 'right' values
>    are for special cases;  pragmatics has to play a role too.
>
>  - there's general consensus in the numerical and mathematical
>    community that it's useful to define pow(0.0, 0.0) to be 1.
>
>  - once you've decided to define pow(0.0, 0.0) to be 1.0, it's
>    easy to justify taking pow(inf, 0.0) to be 1.0:  the same
>    limiting arguments can be used as justification;  or one can
>    use reflection formulae like pow(1/x, y) = 1/pow(x, y), or...
>
>  - one piece of general philosophy used for C99 and IEEE 754
>    seems to have been that NaN results should be avoided
>    when it's possible to give a meaningful non-nan value instead.
>
>  - part of the reason that pow is particularly controversial
>    is that it's really trying to be two different functions
>    at once:  it's trying to be both a generalization of the
>    `analytic' power function x**y = exp(y*log(x)), for
>    real y and positive real x, and in this context one can
>    make a good argument that 0**0 should be undefined; but
>    at the same time it's also used in contexts where y is
>    naturally thought of as an integer; and in the latter
>    context bad things happen if you don't define pow(0, 0)
>    to be 1.
>
> I really should get back to work now.
>
> Mark

Thanks for the engrossing read (and damn you for making me waste
valuable work hours). After perusing both C99 and the previous
presentation on IEEE754, I find myself unconvinced regarding the
special cases. It just stinks of bug-proneness, and I fail to see how
assuming common values for exceptional cases relieves you from testing
for those special cases and getting them behaving right (in an
application-specific way) just the same.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[pdpi]

On Jun 25, 12:23 pm, Robin Becker  wrote:
> Paul Rubin wrote:
>
> so does this render all the discreteness implied by quantum theory unreliable?
> or is it that we just cannot see(measure) the continuity that really happens?
> Certainly there are people like Wolfram who seem to think we're in some kind 
> of
> giant calculating engine where state transitions are discontinuous.

More like that axiomatic system doesn't accurately map to reality as
we currently understand it.

Your posts made me think that I wasn't clear in saying e and 2 are the
only "natural" bases for logs.

The log function, as the inverse of the exponential, is a pretty
fundamental function.

The base e exponential has a load of very natural properties, f'(x) = f
(x) being an example.

As the smallest admissible integer base, log 2 is also a pretty
natural notion, especially in computer science, or in general all that
follow from binary true/false systems.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[pdpi]

On Jun 25, 10:38 am, Paul Rubin  wrote:
> Robin Becker  writes:
> > someone once explained to me that the set of systems that are
> > continuous in the calculus sense was of measure zero in the set of all
> > systems I think it was a fairly formal discussion, but my
> > understanding was of the hand waving sort.
>
> That is very straightforward if you don't mind a handwave.  Let S be
> some arbitrary subset of the reals, and let f(x)=0 if x is in S, and 1
> otherwise (this is a discontinuous function if S is nonempty).  How
> many different such f's can there be?  Obviously one for every
> possible subset of the reals.  The cardinality of such f's is the
> power set of the reals, i.e. much larger than the set of reals.
>
> On the other hand, let g be some arbitrary continuous function on the
> reals.  Let H be the image of Q (the set of rationals) under g.  That
> is, H = {g(x) such that x is rational}.  Since g is continuous, it is
> completely determined by H, which is a countable set.  So the
> cardinality is RxN which is the same as the cardinality of R.  
>
> > If true that makes calculus (and hence all of our understanding of
> > such "natural" concepts) pretty small and perhaps non-applicable.
>
> No really, it is just set theory, which is a pretty bogus subject in
> some sense.  There aren't many discontinuous functions in nature.
> There is a philosophy of mathematics (intuitionism) that says
> classical set theory is wrong and in fact there are NO discontinuous
> functions.  They have their own mathematical axioms which allow
> developing calculus in a way that all functions are continuous.
>
> > On the other hand R Kalman (of Bucy and Kalman filter fame) likened
> > study of continuous linear dynamical systems to "a man searching for
> > a lost ring under the only light in a dark street" ie we search
> > where we can see. Because such systems are tractable doesn't make
> > them natural or essential or applicable in a generic sense.
>
> Really, I think the alternative he was thinking of may have been
> something like nonlinear PDE's, a horribly messy subject from a
> practical point of view, but still basically free of set-theoretic
> monstrosities.  The Banach-Tarski paradox has nothing to do with nature.

I'll take the Banach-Tarski construct (it's not a paradox, damn it!)
over non-linear PDEs any day of the week, thankyouverymuch. :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: 3.2*2 is 9.6 ... or maybe it isn't?

[pdpi]

On Jun 26, 11:01 am, Steven D'Aprano  wrote:
> On Thu, 25 Jun 2009 12:41:13 -0600, Michael Torrie wrote:
> > If you want accurate math, check out other types like what is in the
> > decimal module:
>
>  import decimal
>  a=decimal.Decimal('3.2')
>  print a * 3
> > 9.6
>
> Not so. Decimal suffers from the exact same problem, just with different
> numbers:
>
> >>> import decimal
> >>> x = decimal.Decimal('1')/decimal.Decimal('3')
> >>> 3*x == 1
>
> False
>
> Some numbers can't be represented exactly in base 2, and some numbers
> can't be represented exactly in base 10.
>
> --
> Steven

But since 10 = 2 * 5, all numbers that can be finitely represented in
binary can be represented finitely in decimal as well, with the exact
same number of  places for the fractional part (and no more digits
than the binary representation in the integer part)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Measuring Fractal Dimension ?

[pdpi]

On Jun 29, 3:17 am, greg  wrote:
> Paul Rubin wrote:
> > Steven D'Aprano  writes:
>
> >>But that depends on what you call "things"... if electron shells are real
> >>(and they seem to be) and discontinuous, and the shells are predicted/
> >>specified by eigenvalues of some continuous function, is the continuous
> >>function part of nature or just a theoretical abstraction?
>
> Another thing to think about: If you put the atom in a
> magnetic field, the energy levels of the electrons get
> shifted slightly. To the extent that you can vary the
> magnetic field continuously, you can continuously
> adjust the energy levels.
>
> This of course raises the question of whether it's
> really possible to continuously adjust a magnetic field.
> But it's at least possible to do so with much finer
> granularity than the differences between energy levels
> in an atom.
>
> So if there is a fundamentally discrete model
> underlying everything, it must be at a much finer
> granularity than anything we've so far observed, and
> the discrete things that we have observed probably
> aren't direct reflections of it.
>
> --
> Greg

Electron shells and isolated electrons stuck in a magnetic field are
different phenomena that can't be directly compared. Or, at least,
such a comparison requires you to explain why it's proper.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Passing parameters for a C program in Linux.

[pdpi]

On Jun 30, 11:46 am, "venutaurus...@gmail.com"
 wrote:
> Hi all,
>        I have to write an automted script which will test my c
> program. That program when run will ask for the commands. For example:
>
> local-host# ./cli
> Enter 1 for add
> Enter 2 for sub
> Enter 3 for mul
> 1            ---Our option
> Enter two numbers
> 44 33   Our option
> Result is 77
>
> As shown in the above example it lists all the options and waits for
> user input and once given, it does some operations and waits for some
> more. This has to be automated.
>
> Can someone give suggestions how to do this in Python (Linux Platform
> in particular).
>
> Thank you,
> Venu.

The easiest (and ugliest) way to do this would probably be to write a
file input.txt and a file output.txt with each input/output value, and
then to do this on the command prompt:
./a.out < input.txt | diff output.txt -

this will run a.out (assuming that's your program's name), feed in
input.txt as input, and pipe that into diff to compute the differences
between its output and output.txt
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A Bug By Any Other Name ...

[pdpi]

On Jul 6, 1:12 pm, "Hendrik van Rooyen"  wrote:
> "Terry Reedy"  wrote:
> > Gabriel Genellina wrote:
>
> > > In this case, a note in the documentation warning about the potential
> > > confusion would be fine.
>
> > How would that help someone who does not read the doc?
>
> It obviously won't.
>
> All it will do, is that it will enable people on this group,
> who may read the manual, to tell people who complain,
> to RTFM.
>
>  I agree that it would be a good idea to make it an
> error, or a warning - "this might not do what you
> think it does", or an "are you sure?" exception.
>
>   :-)
>
> - Hendrik

I dunno. Specifically recognizing (and emitting code code for) a token
that's not actually part of the language because people coming from
other languages think it exists seems like the start of a fustercluck.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why re.match()?

[pdpi]

On Jul 2, 4:49 am, kj  wrote:
> In  Duncan Booth 
>  writes:
>
> >So, for example:
>  re.compile("c").match("abcdef", 2)
> ><_sre.SRE_Match object at 0x02C09B90>
>  re.compile("^c").search("abcdef", 2)
>
> I find this unconvincing; with re.search alone one could simply
> do:
>
> >>> re.compile("^c").search("abcdef"[2:])

given large enough values of "abcdef", you just allocated several megs
for no good reason, when re.compile("c").match("abcdef", 2) would
process "abcdef" in-place.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Clarity vs. code reuse/generality

[pdpi]

On Jul 7, 2:16 am, Steven D'Aprano  wrote:
> On Mon, 06 Jul 2009 16:43:43 +0100, Tim Rowe wrote:
> > 2009/7/4 kj :
>
> >> Precisely.  As I've stated elsewhere, this is an internal helper
> >> function, to be called only a few times under very well-specified
> >> conditions.  The assert statements checks that these conditions are as
> >> intended.  I.e. they are checks against the module writer's programming
> >> errors.
>
> > Good for you. I'm convinced that you have used the assertion
> > appropriately, and the fact that so many here are unable to see that
> > looks to me like a good case for teaching the right use of assertions.
> > For what it's worth, I read assertions at the beginning of a procedure
> > as part of the specification of the procedure, and I use them there in
> > order to document the procedure. An assertion in that position is for me
> > a statement to the user of the procedure "it's your responsibility to
> > make sure that you never call this procedure in such a way as to violate
> > these conditions". They're part of a contract, as somebody (maybe you)
> > pointed out.
>
> > As somebody who works in the safety-critical domain, it's refreshing to
> > see somebody teaching students to think about the circumstances in which
> > a procedure can legitimately be called. The hostility you've received to
> > that idea is saddening, and indicative of why there's so much buggy
> > software out there.
>
> LOL.
>
> Maybe the reason for "so much buggy software" is that people
> inappropriately use assert, thus changing the behaviour of code depending
> on whether it is run with the -O flag or not.
>
> I don't know what "hostility" you're seeing. The only hostility I'm
> seeing is from the OP, which is bizarre considering that he asked for
> advice and we gave it. What I see is a bunch of people concerned that the
> OP is teaching novices a bad habit, namely, using assert for error
> checking. He claims -- angrily and over and over again -- that in his
> code, the assertions should never fail. Great. Good for him for knowing
> when to use assert. (...)

But he doesn't.

He asserts:
assert lo < hi
but then compares:
sense = cmp(func(hi), func(lo))

sense can't ever be anything other than 1. I actually find it amusing
that this threat got to 50 posts of raving discussion about assertions
without anyone spotting that.

Personally, I think the code is an unreadable mess, but that's mostly
because of all the micro optimizations, not the generality of it.
Here's my unoptimized, but still equally generic, version:

def _binary_search(lo, hi, func, target, epsilon):
sense = cmp(func(hi), func(lo))
if sense == 0:
return None
guess = (lo + hi) / 2.
while abs(func(guess) - target) > epsilon:
guess = (lo + hi) / 2.
if func(guess) > target:
hi = guess
elif func(guess) < target:
lo = guess
elif lo == hi:
return None
return guess

This is a newbie course, right? A while True loop might be faster, but
it's all sorts of wrong for teaching newbies. Likewise, calculating a
midpoint as mid = (hi + lo) * .5 is an aberration in a beginner
environment. You want your students asking why you're calculating an
average, not asking why you're multiplying by 0.5. In the same vein, I
have no words for your target_plus/target_minus cleverness.

The right way to go about it, IMO, is to give them my version, let
them digest it, make all the necessary changes to it to turn it into
your (faster) version. Present benchmarks for both, then let the
readability/performance trade-off sink in. What you achieve with this
exercise is that, instead of making your students think "I have to
read that crud!?", they'll respect that ugly code is often the result
of eking out every last drop of performance from a program as you
possibly can.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Clarity vs. code reuse/generality

[pdpi]

On Jul 7, 7:26 pm, Andre Engels  wrote:
> On Tue, Jul 7, 2009 at 8:01 PM, pdpi wrote:
> > He asserts:
> >    assert lo < hi
> > but then compares:
> >    sense = cmp(func(hi), func(lo))
>
> > sense can't ever be anything other than 1.
>
> It can - there is no necessity that func is monotonically increasing.
>
> --
> André Engels, andreeng...@gmail.com

Yes, I realized that as I was walking home.

In other news, some of you may be interested in my seminar in advanced
foot-in-mouth placement.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Clarity vs. code reuse/generality

[pdpi]

On Jul 7, 7:06 pm, Paul Rubin <http://phr...@nospam.invalid> wrote:
> pdpi  writes:
> > Personally, I think the code is an unreadable mess, but that's mostly
> > because of all the micro optimizations, not the generality of it.
> > Here's my unoptimized, but still equally generic, version:
>
> That version doesn't use "sense" inside the binary search, i.e. it
> relies on the function being monotonically increasing.

You're right, make that:

def _binary_search(lo, hi, func, target, epsilon):
sense = cmp(func(hi), func(lo))
if sense == 0:
return None
guess = (lo + hi) / 2.
while abs(func(guess) - target) > epsilon:
guess = (lo + hi) / 2.
if sense * func(guess) > target:
hi = guess
elif sense * func(guess) < target:
lo = guess
elif lo == hi:
return None
return guess

Seems I had a serious brain cramp while posting that...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Clarity vs. code reuse/generality

[pdpi]

On Jul 7, 7:31 pm, pdpi  wrote:
> On Jul 7, 7:06 pm, Paul Rubin <http://phr...@nospam.invalid> wrote:
>
> > pdpi  writes:
> > > Personally, I think the code is an unreadable mess, but that's mostly
> > > because of all the micro optimizations, not the generality of it.
> > > Here's my unoptimized, but still equally generic, version:
>
> > That version doesn't use "sense" inside the binary search, i.e. it
> > relies on the function being monotonically increasing.
>
> You're right, make that:
>
> def _binary_search(lo, hi, func, target, epsilon):
>     sense = cmp(func(hi), func(lo))
>     if sense == 0:
>         return None
>     guess = (lo + hi) / 2.
>     while abs(func(guess) - target) > epsilon:
>         guess = (lo + hi) / 2.
>         if sense * func(guess) > target:
>             hi = guess
>         elif sense * func(guess) < target:
>             lo = guess
>         elif lo == hi:
>             return None
>     return guess
>
> Seems I had a serious brain cramp while posting that...

Actually, scratch that.

def _binary_search(lo, hi, func, target, epsilon):
sense = cmp(func(hi), func(lo))
if sense == 0:
return None
guess = (lo + hi) / 2.
while abs(func(guess) - target) > epsilon:
guess = (lo + hi) / 2.
if sense * func(guess) > sense * target:
hi = guess
elif sense * func(guess) < sense * target:
lo = guess
elif lo == hi:
return None
return guess
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Clarity vs. code reuse/generality

[pdpi]

On Jul 7, 8:04 pm, Dave Angel  wrote:
> And of course your clarified function will fail if the func is
> monotonically decreasing.

yeah, I eventually realized that and corrected it... And the assert()/
cmp() confusion too. I blame lack of sleep.

The whole sign/sense thing left a really bad taste in my mouth,
though, and the swapping lo and hi suggestion of yours seems like the
neatest solution presented.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Clarity vs. code reuse/generality

[pdpi]

On Jul 8, 2:24 am, Paul Rubin <http://phr...@nospam.invalid> wrote:
> pdpi  writes:
> >     while abs(func(guess) - target) > epsilon:
> >         guess = (lo + hi) / 2.
> >         if sense * func(guess) > sense * target:
> >             hi = guess
> >         elif sense * func(guess) < sense * target:
> >             lo = guess
> >         elif lo == hi:
> >             return None
> >     return guess
>
> That is completely confusing.  I get the, er, impression that "sense"
> is supposed to change during the loop, and it takes much head
> scratching to tell whether what you have there is right or not.  Also,
> it calls func 3 times on each loop, which could be extremely slow.
> You don't know what func does, so eliminating 2/3 of the calls to it
> is not a micro-optimization--it could be a major time saving.
>
> Yet another version:
>
>     def _binary_search(x0, x1, func, target, epsilon):
>         y0,y1 = func(x0), func(x1)
>         while abs(y1 - target) > epsilon:
>             if x0 == x1 or cmp(y0,target) == cmp(y1,target):
>                 return None
>             xn = (x0 + x1) / 2.
>             yn = func(xn)
>             if cmp(yn,target) == cmp(y0,target):
>                x0,y0 = xn,yn
>             else:
>                x1,y1 = xn,yn
>         return x1

micro-optimization was perhaps too harsh, but it is an optimization
that's not obvious for the newbie, and one best learnt from experience
rather than having it spoon fed. I'll restate: you should start with
the cleanest code possible and mangle it for performance. Then again,
that implicitly assumes that f(x) is more readable than y, which is
really a matter of taste...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: tough-to-explain Python

[pdpi]

On Jul 10, 2:11 pm, Steven D'Aprano  wrote:
> On Fri, 10 Jul 2009 12:54:21 +0200, Hendrik van Rooyen wrote:
> > "Steven D'Aprano"  wrote:
>
> >>On Wed, 08 Jul 2009 22:05:57 -0700, Simon Forman wrote:
>
>  persistent idea "out there" that programming is a very accessible
>  skill, like cooking or gardening, anyone can do it, and even profit
>  from it, monetarily or otherwise, etc., and to some extent I am
>
> >>> Programming is not like any other human activity.
>
> >>In practice? In principle? Programming in principle is not the same as
> >>it is performed in practice.
>
> >>But in either case, programming requires both the logical reasoning of
> >>mathematics and the creativity of the arts. Funnily enough,
>
> > I do not buy this arty creativity stuff. - or are you talking about
> > making a website look pretty?
>
> I must admit, it never crossed my mind that anyone here would claim that
> there was no creativity involved in programming, that it was all a
> mindless, algorithmic process capable of being done by a simple
> mechanical device.
>
> This is certainly the accusation made against *bad* programmers -- that
> they can't actually solve new, unique problems, but just apply recipes
> they learned without any insight or intelligence. The sort of people who
> program so poorly that "a trained monkey could do what they do".

I wholeheartedly agree. Coming up with Duff's device is nothing if not
creative. My mind still reels at trying to grok it.
http://www.lysator.liu.se/c/duffs-device.html

> Even *soup stock* fits the same profile as what Hendrik claims is almost
> unique to programming. On its own, soup stock is totally useless. But you
> make it, now, so you can you feed it into something else later on.
>
> Or instant coffee.

I've always found cooking an apt metaphor for programming.

You've got your well-limited for loops (cook for x minutes), your less
straightforward while/until loops (roast until golden), you have your
subprocedures (prepare sauce in advance/in parallel), you have some
conditionals (tenderize the steak if the meat isn't really that
tender), etc etc.

The complexities of assignment can be easily visualized in terms of
containers and mixing stuff together. Nothing makes a += b more
obvious than having a bowl of cream (a), an egg (b), and adding the
egg to the bowl of cream (a += b). Well, except for the part where
that in that case evaluating b is destructive ;)

> They can't reason? Then what are they doing when they manipulate symbols?

"Computers aren't intelligent. They only think they are." Or, more to
the point: the typical definition of "reasoning" tends to involve more
of what defines humans as self-aware, animate beings than what is
usually ascribed to computers.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Implementing a cache

[pdpi]

On Jul 12, 2:01 pm, s...@pobox.com wrote:
>     Nikolaus> I want to implement a caching data structure in Python that
>     Nikolaus> allows me to:
>
>     Nikolaus>  1. Quickly look up objects using a key
>     Nikolaus>  2. Keep track of the order in which the objects are accessed
>     Nikolaus>     (most recently and least recently accessed one, not a
>     Nikolaus>     complete history)
>     Nikolaus>  3. Quickly retrieve and remove the least recently accessed
>     Nikolaus>     object.
>
> My Cache module does #1 and #3.  I'm not sure if you want #2 for internal
> cache maintenance or for as part of the API.
>
>    http://www.smontanaro.net/python/Cache.py
>
> Skip

I'm not sure whether #2 is doable at all, as written. You _need_ a
complete history (at least the full ordering of the items in the
cache) to be able to tell what the least recently used item is.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Infinite loops and synchronization

[pdpi]

On Jul 13, 6:06 am, Vincent Gulinao  wrote:
> lst = list()
>
> (lst populated by async twisted deferred callbacks)
>
> while True:
>         if len(lst) == SOME_NUMBER:
>                 return lst
>
> Q1: is this a common OK practice? I'm worried infinite loops hogs memory.
> Q2: operating on list from threads (mostly appends) must be safe,
> right (synchronization)?

Q1: I'll answer your question with another. What's so fundamentally
different between your infinite loop and this one:

while len(lst) != SOME_NUMBER:
  pass
return lst

which is not an "infinite loop"[1]. Why would yours be any worse in
terms of memory than mine? Are you allocating anything that would hog
memory? Of course, like Piet said, it *will* hog your CPU, so you want
a time.sleep(.1) in there, at the least. Of course, the question is:
why aren't you using a semaphore to let you know you can proceed, and
make the provider increment the semaphore?

[1] -- well, it can be, if len(lst) == SOME_NUMBER never comes about,
and I'd hazard a guess that that's pretty much where your fear of
memory hogging comes from: it's easy to allocate stuff and not
deallocate it within a cycle, only to find the bounds on that cycle
going awry.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: one-time factory in python for an experienced java guy

[pdpi]

On Jul 14, 3:03 pm, phonky  wrote:
> Hi
>
> I have searched all over and haven't found the solution
> for my problem yet. I am new to python, and all the time realize I
> do program python in java, which is not great.
>
> Besides being a real-life problem, I want to
> solve it as elegant as I can, using it to
> also learn about python (I know I could just
> hack something easy for now).
>
> That's what I want to do.
>
> I have an Account class.
> An Account instance has to get an account number.
> On instance creation, I want the account number to
> be generated (I don't want callers to pass
> the account # to ensure uniqueness):
>
> class Account(object):
>         def __init__(self, holder):
>                 self.__accountnumber = self.__generate_account_number()
>
> Now, I do not know yet how the account number scheme looks like.
> For now, I just want to have an incremental number; later,
> when going to production, we'll need the proper one.
>
> Furthermore, as we plan to distribute the package, we want
> to allow custom account numbering schemes. Thus, customers
> should be able to plug in their own AccountNumberGenerator implementation.
>
> For now, I have a generators.py module.
>
> I have an AccountNumberGenerator base class,
> all subclasses should implement "generate".
>
> I have an IncrementalGenerator subclass.
>
> So for now, I need to instantiate IncrementalGenerator,
> allowing for a future module to plugin their own generator.
>
> Any suggestions on how to do this?
> Thanks so much

You don't want an AccountNumberGenerator class and subclassing, all
you need is an iterator/generator of some form.

These might help:
http://docs.python.org/tutorial/classes.html#iterators
http://docs.python.org/tutorial/classes.html#generators
(in fact, that whole page is pretty relevant)

Once your code expects one of those, it's trivially easy to plug
something else in there.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: missing 'xor' Boolean operator

[pdpi]

On Jul 15, 12:08 am, Christian Heimes  wrote:
> Chris Rebert wrote:
> > Using the xor bitwise operator is also an option:
> > bool(x) ^ bool(y)
>
> I prefer something like:
>
>     bool(a) + bool(b) == 1
>
> It works even for multiple tests (super xor):
>
>   if bool(a) + bool(b) + bool(c) + bool(d) != 1:
>       raise ValueError("Exactly one of a, b, c and d must be true")
>
> Christian

"if bool(a) + bool(b) + bool(c) + bool(d) != 1:" is not equivalent to
xor. 1 xor 1 xor 1 = 1 xor (1 xor 1) = 1 xor 0 = 1 (or = (1 xor 1) xor
1 = 0 xor 1 = 1 if you assicate to the left)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: missing 'xor' Boolean operator

[pdpi]

On Jul 15, 12:37 pm, Christian Heimes  wrote:
> pdpi wrote:
> > On Jul 15, 12:08 am, Christian Heimes  wrote:
> >> Chris Rebert wrote:
> >>> Using the xor bitwise operator is also an option:
> >>> bool(x) ^ bool(y)
> >> I prefer something like:
>
> >>     bool(a) + bool(b) == 1
>
> >> It works even for multiple tests (super xor):
>
> >>   if bool(a) + bool(b) + bool(c) + bool(d) != 1:
> >>       raise ValueError("Exactly one of a, b, c and d must be true")
>
> >> Christian
>
> > "if bool(a) + bool(b) + bool(c) + bool(d) != 1:" is not equivalent to
> > xor. 1 xor 1 xor 1 = 1 xor (1 xor 1) = 1 xor 0 = 1 (or = (1 xor 1) xor
> > 1 = 0 xor 1 = 1 if you assicate to the left)
>
> I'm well aware of the fact that I've described something differently.
> 'xor' can be explained as 'check if exactly one element of two elements
> is true'. My algorithms describes a super xor, aka 'check if exactly one
> element of n elements is true'.
>
> Christian

Well, I just wouldn't call it a "super xor" then, when "unicity test"
works much better -- especially as an alternative to an actual xor
without any specification to the actual intended functionality except
the exception text.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Equivalent for dd & fold

[pdpi]

On Jul 16, 3:12 pm, seldan24  wrote:
> On Jul 15, 1:48 pm, Emile van Sebille  wrote:
>
>
>
>
>
> > On 7/15/2009 10:23 AM MRAB said...
>
> > >> On Jul 15, 12:47 pm, Michiel Overtoom  wrote:
> > >>> seldan24 wrote:
> >  what can I use as the equivalent for the Unix 'fold' command?
> > >>> def fold(s,len):
> > >>>      while s:
> > >>>          print s[:len]
> > >>>          s=s[len:]
>
> > 
> > > You might still need to tweak the above code as regards how line endings
> > > are handled.
>
> > You might also want to tweak it if the strings are _really_ long to
> > simply slice out the substrings as opposed to reassigning the balance to
> > a newly created s on each iteration.
>
> > Emile
>
> Thanks for all of the help.  I'm almost there.  I have it working now,
> but the 'fold' piece is very slow.  When I use the 'fold' command in
> shell it is almost instantaneous.  I was able to do the EBCDIC->ASCII
> conversion usng the decode method in the built-in str type.  I didn't
> have to import the codecs module.  I just decoded the data to cp037
> which works fine.
>
> So now, I'm left with a large file, consisting of one extremely long
> line of ASCII data that needs to be sliced up into 35 character
> lines.  I did the following, which works but takes a very long time:
>
> f = open(ascii_file, 'w')
> while ascii_data:
>     f.write(ascii_data[:len])
>     ascii_data = ascii_data[len:]
> f.close()
>
> I know that Emile suggested that I can slice out the substrings rather
> than do the gradual trimming of the string variable as is being done
> by moving around the length.  So, I'm going to give that a try... I'm
> a bit confused by what that means, am guessing that slice can break up
> a string based on characters; will research.  Thanks for the help thus
> far.  I'll post again when all is working fine.

Assuming your rather large text file is 1 meg long, you have 1 million
characters in there. 100/35 = ~29k lines. The size remaining
string decreases linearly, so the average size is (100 + 0) / 2 or
500k. All said and done, you're allocating and copying a 500K string
-- not once, but 29 thousand times. That's where your slowdown resides.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Convert points to polygon shapefile

[pdpi]

On Jul 24, 11:21 am, Luis Pedro Almeida  wrote:
> Dear all,
>
> I would like to know how to convert a list of points into a polygon
> shapefile (esri).
>
> Thanks!
>
> Best regards,
>
> Luis Pedro Almeida

I think you'd be better served by asking this question in a newsgroup
dedicated to GIS software (I'm guessing that's the ESRI you meant).
Still, what you want is to find the file format specification, and
implement it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: hanning python

[pdpi]

On Sep 8, 12:36 pm, Pierre  wrote:
> Hello,
>
> anyone knows what is the python equivalent of the matlab's hanning
> function.
>
> Note that in matlab hann and hanning are different.
>
> Thanks !

I assume you mean the tapering function mentioned here:
http://mathworld.wolfram.com/HanningFunction.html

Python is a general purpose language, unlike the maths-specialized
MATLAB. I suggest you look into numpy, in which, a quick googling
suggests, an implementation of a the Hanning function is provided. In
fact, if you're using python to replace matlab in any meaningful way,
you'll probably want to use numpy anyway.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: hanning python

[pdpi]

On Sep 8, 1:55 pm, sturlamolden  wrote:
> On 8 Sep, 13:36, Pierre  wrote:
>
> > anyone knows what is the python equivalent of the matlab's hanning
> > function.
>
> > Note that in matlab hann and hanning are different.
>
> If you don't know how to compute a von Hann window, you are not
> competent to do any scientific programming. Seriously!
>

Come, come. I think it's a good rule that, where available, a vendor-
supplied implementation is the preferable choice until proven
otherwise.

> I assume you are using NumPy and SciPy, so consider
> scipy.signal.hanning for convinience.

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

Re: Extracting patterns after matching a regex

[pdpi]

On Sep 8, 1:56 pm, Martin  wrote:
> Hi,
>
> I need to extract a string after a matching a regular expression. For
> example I have the string...
>
> s = "FTPHOST: e4ftl01u.ecs.nasa.gov"
>
> and once I match "FTPHOST" I would like to extract
> "e4ftl01u.ecs.nasa.gov". I am not sure as to the best approach to the
> problem, I had been trying to match the string using something like
> this:
>
> m = re.findall(r"FTPHOST", s)
>
> But I couldn't then work out how to return the "e4ftl01u.ecs.nasa.gov"
> part. Perhaps I need to find the string and then split it? I had some
> help with a similar problem, but now I don't seem to be able to
> transfer that to this problem!
>
> Thanks in advance for the help,
>
> Martin

What you're doing is telling python "look for all matches of
'FTPHOST'". That doesn't really help you much, because you pretty much
expect FTPHOST to be there anyway, so finding it means squat. What you
_really_ want to tell it is "Look for things shaped like 'FTPHOST:
', and tell me what  actually is". Look here:
http://docs.python.org/howto/regex.html#grouping. That'll explain how
to accomplish what you're trying to do.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Extracting patterns after matching a regex

[pdpi]

On Sep 8, 3:21 pm, nn  wrote:
> On Sep 8, 9:55 am, "Mart."  wrote:
>
>
>
>
>
> > On Sep 8, 2:16 pm, "Andreas Tawn"  wrote:
>
> > > > Hi,
>
> > > > I need to extract a string after a matching a regular expression. For
> > > > example I have the string...
>
> > > > s = "FTPHOST: e4ftl01u.ecs.nasa.gov"
>
> > > > and once I match "FTPHOST" I would like to extract
> > > > "e4ftl01u.ecs.nasa.gov". I am not sure as to the best approach to the
> > > > problem, I had been trying to match the string using something like
> > > > this:
>
> > > > m = re.findall(r"FTPHOST", s)
>
> > > > But I couldn't then work out how to return the "e4ftl01u.ecs.nasa.gov"
> > > > part. Perhaps I need to find the string and then split it? I had some
> > > > help with a similar problem, but now I don't seem to be able to
> > > > transfer that to this problem!
>
> > > > Thanks in advance for the help,
>
> > > > Martin
>
> > > No need for regex.
>
> > > s = "FTPHOST: e4ftl01u.ecs.nasa.gov"
> > > If "FTPHOST" in s:
> > >     return s[9:]
>
> > > Cheers,
>
> > > Drea
>
> > Sorry perhaps I didn't make it clear enough, so apologies. I only
> > presented the example  s = "FTPHOST: e4ftl01u.ecs.nasa.gov" as I
> > thought this easily encompassed the problem. The solution presented
> > works fine for this i.e. re.search(r'FTPHOST: (.*)',s).group(1). But
> > when I used this on the actual file I am trying to parse I realised it
> > is slightly more complicated as this also pulls out other information,
> > for example it prints
>
> > e4ftl01u.ecs.nasa.gov\r\n', 'FTPDIR: /PullDir/0301872638CySfQB\r\n',
> > 'Ftp Pull Download Links: \r\n', 'ftp://e4ftl01u.ecs.nasa.gov/PullDir/
> > 0301872638CySfQB\r\n', 'Down load ZIP file of packaged order:\r\n',
>
> > etc. So I need to find a way to stop it before the \r
>
> > slicing the string wouldn't work in this scenario as I can envisage a
> > situation where the string lenght increases and I would prefer not to
> > keep having to change the string.
>
> > Many thanks
>
> It is not clear from your post what the input is really like. But just
> guessing this might work:
>
> >>> print s
>
> 'MEDIATYPE: FtpPull\r\n', 'MEDIAFORMAT: FILEFORMAT\r\n','FTPHOST:
> e4ftl01u.ecs.nasa.gov\r\n', 'FTPDIR: /PullDir/0301872638CySfQB\r
> \n','Ftp Pull Download Links: \r\n'
>
> >>> re.search(r'FTPHOST: (.*?)\\r',s).group(1)
>
> 'e4ftl01u.ecs.nasa.gov'

Except, I'm assuming, the OP's getting the data from a (windows-
formatted) file, so \r\n shouldn't be escaped in the regex:

>>> re.search(r'FTPHOST: (.*?)\r',s).group(1)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: hanning python

[pdpi]

On Sep 9, 3:27 am, sturlamolden  wrote:
> On 9 Sep, 00:24, Steven D'Aprano
>
>  wrote:
> > A decent vendor-supplied implementation will include error checking that
> > you otherwise would need to implement yourself, so yes.
>
> Not for code like this:
>
>
>
> >>> import numpy as np
> >>> n = np.arange(101)
> >>> w = 0.5*(1.0-np.cos(2*np.pi*n/(100.)))

Well, I went and dug into NumPy. They write it as 0.5 - 0.5 * cos
(...), and special case N = 1, and properly error check N < 1. Still,
probably because of differences in dictionary look ups (because of
namespace scopes), np.hanning, on average, takes a wee bit over half
as long as your case, and yours is only a shade faster than

>>> window = [0.5 - math.cos(2 * x * math.pi /100.) for x in range(101)]

(Yes, I know I should've used xrange instead of range)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: hanning python

[pdpi]

On Sep 9, 3:46 pm, pdpi  wrote:
> On Sep 9, 3:27 am, sturlamolden  wrote:
>
> > On 9 Sep, 00:24, Steven D'Aprano
>
> >  wrote:
> > > A decent vendor-supplied implementation will include error checking that
> > > you otherwise would need to implement yourself, so yes.
>
> > Not for code like this:
>
> > >>> import numpy as np
> > >>> n = np.arange(101)
> > >>> w = 0.5*(1.0-np.cos(2*np.pi*n/(100.)))
>
> Well, I went and dug into NumPy. They write it as 0.5 - 0.5 * cos
> (...), and special case N = 1, and properly error check N < 1. Still,
> probably because of differences in dictionary look ups (because of
> namespace scopes), np.hanning, on average, takes a wee bit over half
> as long as your case, and yours is only a shade faster than
>
> >>> window = [0.5 - math.cos(2 * x * math.pi /100.) for x in range(101)]
>
> (Yes, I know I should've used xrange instead of range)

Sorry, should've been smarter than this.

Raising this to 1 million, rather than 100, nodes in the window, the
timing difference between your version and NumPy's is tiny (but numpy
still edges you out, but just barely), but they trounce my naive
version, being around 7 or 8 times faster the list comprehension I
suggested. So implementing this in vanilla python instead of using
numpy would hurt performance a fair bit, and odds are the OP is going
to put this to use somewhere that involves more maths, which makes
learning about numpy well worth having asked the question here.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: hanning python

[pdpi]

On Sep 9, 7:01 pm, sturlamolden  wrote:
> On 9 Sep, 16:57, pdpi  wrote:
>
> > Raising this to 1 million, rather than 100, nodes in the window, the
> > timing difference between your version and NumPy's is tiny (but numpy
> > still edges you out, but just barely), but they trounce my naive
> > version, being around 7 or 8 times faster the list comprehension I
> > suggested.
>
> "Premature optimization is the root of all evil in computer
> programming."
>
> Speed is not the issue here.

Sure it is. And safety. And practicality. And all the other reasons
why people use libraries rather than reinventing the wheel every time
they fire up their editors. Given the OP's question, a snarky "you're
not competent enough to do scientific computing" serves no purpose,
where pointing him to NumPy (and SciPy, I forgot to mention that bit)
serves him much better.
-- 
http://mail.python.org/mailman/listinfo/python-list