Re: Fortran (Was: The "does Python have variables?" debate)
On Sunday, May 11, 2014 11:47:55 AM UTC+5:30, Mark H. Harris wrote: > 'Julia' is going to give everyone a not so small run for competition; > justifiably so, not just against FORTRAN. > > > Julia is Matlab and R, Python, Lisp, Scheme; all rolled together on > steroids. Its amazing as a dynamic language, and its fast, like > lightning fast as well as multiprocessing (parallel processing) at its > core. Its astounding, really. I think the big thing is that Julia is cooperating rather than competing https://github.com/JuliaLang/IJulia.jl If they can carry this off, its a definite winning strategy -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On Sun, 11 May 2014 01:17:55 -0500, Mark H Harris wrote: > On 5/10/14 8:42 AM, Roy Smith wrote: >> Ars Technica article a couple of days ago, about Fortran, and what is >> likely to replace it: >> >> http://tinyurl.com/mr54p96 >> >> > uhm, yeeah! > > 'Julia' is going to give everyone a not so small run for competition; > justifiably so, not just against FORTRAN. That and two hundred other languages. Good languages (for some definition of "good") are a dime a dozen. Miranda, Rust, Go, D, Ceylon, Coffeescript, F#, Scala, Lua, Erlang, Eiffel, Ocaml, Haskell, Kotlin, Grovy, Clojure, Dart, Mercury, ML... the list of "amazing", "astounding" languages is never ending. Very few of them take over the world, and those that do rarely do so due to technical excellence. (BASIC, Java, PHP, Javascript ...) Some of them, like Haskell, influence other languages without ever being popular themselves. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Free vs proprietary (was Re: NumPy, SciPy, & Python 3X Installation/compatibility issues)
On Sat, 10 May 2014 21:16:06 -0700, Nelson Crosby wrote: > I also believe in this more 'BSD-like' view, but from a business point > of view. No one is going to invest in a business that can't guarantee > against piracy, and such a business is much less likely to receive > profit (see Ardour). I think that's nonsense. Look at Red Hat, and Ubuntu. Their software is free to copy and free to distribute, although Red Hat does make it more difficult to copy actual RHEL, you can copy and distribute the re-branded RHEL known as Centos completely free of charge. Selling physical product is not the only way to make money from software, and in fact, most programmers are not paid to write software for sale. They are paid to write in-house applications which are never distributed outside of the company paying for their labour. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Values and objects
On Sat, 10 May 2014 18:28:43 -0700, Ethan Furman wrote: > On 05/10/2014 04:18 PM, Chris Angelico wrote: >> On Sun, May 11, 2014 at 5:10 AM, Ethan Furman >> wrote: >>> And if you don't like that argument (although it is a perfectly sound >>> and correct argument), think of the module name space: >>> >>> >>> ret = spam >>> spam = 23 >>> >>> will net you a simple NameError, because spam has not yet been >>> created. >> >> What about this, though: >> >> ret = int >> int = 23 >> >> That will *not* net you a NameError, because 'int' exists in an outer >> scope (builtins). You can create a new module-scope variable and it >> will immediately begin to shadow a builtin; you can delete that >> variable and it will immediately cease to shadow that builtin. That's >> the difference I'm talking about. With function-local variables, they >> all have to exist (as other responses confirmed, that *is* a language >> guarantee), even though some of them aren't bound to anything yet. > > Well, with function variables they have to exist *when you use them*. ;) > > This seems like more of a scoping issue than a "can we create variables > in Python" issue. Correct. The first line "ret = int" does a name lookup for "int", finds it in the built-ins, and binds it to "ret". The second line "int = 23" binds the object 23 to the name "int" in the current namespace, i.e. the globals. It has nothing to do with how variables are created. By default, you can't do that inside a function because function scoping is special, not because function locals are kept inside slots. (1) They aren't always, not even in CPython, and (2) even if they are, an implementation could hide that fact and provide the same behaviour. I say "by default" because with byte-code hacking you can. Suppose I write the function: def special(): spam = spam process(spam) Under normal circumstances, this will fail, because the assignment "spam = ..." tells the compiler that spam is a local, and so the lookup for "... = spam" does a LOAD_FAST which fails. But if I hack the byte code, I can turn that LOAD_FAST into a LOAD_GLOBAL, which then gives behaviour just like Lua: spam (the local variable) = spam (the global variable) Of course, this isn't a feature of Python the language. But with sufficient byte-code hacking skills, it is possible. > I am curious, though, what other python's do with respect to function > variables. As far as I know, Jython and IronPython store them in a dict namespace, just like globals. See my previous responses to Chris. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Values and objects
On Sun, 11 May 2014 11:59:21 +1000, Chris Angelico wrote:
> On Sun, May 11, 2014 at 11:28 AM, Ethan Furman
> wrote:
>> Well, with function variables they have to exist *when you use them*.
>> ;)
>>
>> This seems like more of a scoping issue than a "can we create variables
>> in Python" issue.
>>
>> I am curious, though, what other python's do with respect to function
>> variables.
>
> Variables exist in scope. Apart from assembly language, where registers
> have universal scope, every language I know of has some concept of
> scope.
BASIC.
> (REXX is very different from most, in that "PROCEDURE EXPOSE"
> isn't at all your classic notion of scoping, but there's still the
> concept that there can be two variables with the same name.) When you
> create one, you create it in a particular scope, and that's how it must
> be.
Yes. But when do you create it? At declaration time, or when a value is
bound to it?
# Ensure spam does not exist.
try:
del spam
except NameError:
pass
assert "spam" not in globals()
# Declare spam.
global spam
print ("spam" in globals()) # prints False
print (spam) # raises NameError
The same applies to locals. Whether a slot is pre-allocated or not, the
variable doesn't exist until there is a value bound to the name.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Question on Debugging a code line
On Sunday, May 11, 2014 11:50:32 AM UTC+5:30, [email protected] wrote: > On Sunday, May 11, 2014 12:57:34 AM UTC+5:30, [email protected] wrote: > > > Dear Room, > > > > > > > > > > > > I was trying to go through a code given in > > http://en.wikipedia.org/wiki/Forward%E2%80%93backward_algorithm[ Forward > > Backward is an algorithm of Machine Learning-I am not talking on that > > > > > > I am just trying to figure out a query on its Python coding.] > > > > > > > > > > > > I came across the following codes. > > > > > > > > > > > > >>> states = ('Healthy', 'Fever') > > > > > > >>> end_state = 'E' > > > > > > >>> observations = ('normal', 'cold', 'dizzy') > > > > > > >>> start_probability = {'Healthy': 0.6, 'Fever': 0.4} > > > > > > >>> transition_probability = { > > > > > >'Healthy' : {'Healthy': 0.69, 'Fever': 0.3, 'E': 0.01}, > > > > > >'Fever' : {'Healthy': 0.4, 'Fever': 0.59, 'E': 0.01}, > > > > > >} > > > > > > >>> emission_probability = { > > > > > >'Healthy' : {'normal': 0.5, 'cold': 0.4, 'dizzy': 0.1}, > > > > > >'Fever' : {'normal': 0.1, 'cold': 0.3, 'dizzy': 0.6}, > > > > > >} > > > > > > > > > > > > def fwd_bkw(x, states, a_0, a, e, end_st): > > > > > > L = len(x) > > > > > > fwd = [] > > > > > > f_prev = {} #THE PROBLEM > > > > > > # forward part of the algorithm > > > > > > for i, x_i in enumerate(x): > > > > > > f_curr = {} > > > > > > for st in states: > > > > > > if i == 0: > > > > > > # base case for the forward part > > > > > > prev_f_sum = a_0[st] > > > > > > else: > > > > > > prev_f_sum = sum(f_prev[k]*a[k][st] for k in states) ## > > > > > > > > > > > > f_curr[st] = e[st][x_i] * prev_f_sum > > > > > > > > > > > > fwd.append(f_curr) > > > > > > f_prev = f_curr > > > > > > > > > > > > p_fwd = sum(f_curr[k]*a[k][end_st] for k in states) > > > > > > > > > > > > As this value was being called in prev_f_sum = sum(f_prev[k]*a[k][st] for k > > in states marked ## > > > > > > I wanted to know what values it is generating. > > > > > > So, I had made the following experiment, after > > > > > > for i, x_i in enumerate(x): > > > > > > I had put print f_prev > > > > > > but I am not getting how f_prev is getting the values. > > > > > > > > > > > > Here, > > > > > > x=observations, > > > > > > states= states, > > > > > > a_0=start_probability, > > > > > > a= transition_probability, > > > > > > e=emission_probability, > > > > > > end_st= end_state > > > > > > > > > > > > Am I missing any minor aspect? > > > > > > Code is running fine. > > > > > > > > > > > > If any one of the esteemed members may kindly guide me. > > > > > > > > > > > > Regards, > > > > > > Subhabrata Banerjee. > > > > Dear Sir, > > Thank you for your kind reply. I will check. > > Regards, > > Subhabrata Banerjee. Dear Sir, Thank you. It worked. I made another similar statement over another set of values on your reply it went nice. Regards, Subhabrata Banerjee. -- https://mail.python.org/mailman/listinfo/python-list
Re: Values and objects
Marko Rauhamaa writes: > Rustom Mody: > > > On Saturday, May 10, 2014 2:39:31 PM UTC+5:30, Steven D'Aprano wrote: > >> > >> Personally, I don't imagine that there ever could be a language > >> where variables were first class values *exactly* the same as > >> ints, strings, floats etc. > > > > [...] > > > > What you mean by *exactly* the same mean, I am not sure... > > Lisp variables (symbols) are on an equal footing with other objects. > IOW, lisp variables are objects in the heap. Only some, or only in quite old or special members of the family. But yes, I suppose when Lisp was still LISP, it was the kind of language that Steven fails to imagine in the quotation above. Variables really were symbols, which still are objects that can be passed around and stored in data structures. Or maybe not - wasn't the essential binding component (originally an "association list", later a more abstract "environment", called "namespace" in Python culture) separate from the symbol even then? Global bindings aside. But default in Common Lisp is lexical binding, and Scheme has only lexical bindings. An ordinary lexical variable is not an object in any reasonable sense that I can see. (let ((f (let ((x 3)) (lambda () x ;; The binding of x is still relevant here but not in scope and not ;; accessible through the symbol x (funcall f)) ;==> 3 # That's (lambda f : f())((lambda x : (lambda : x))(3)) #=> 3 # Roughly, f = (lambda x : (lambda : x))(3) ; f() #=> 3 -- https://mail.python.org/mailman/listinfo/python-list
Re: Values and objects
On Sunday, May 11, 2014 1:56:41 PM UTC+5:30, Jussi Piitulainen wrote: > Marko Rauhamaa writes: > > Rustom Mody: > > > > > On Saturday, May 10, 2014 2:39:31 PM UTC+5:30, Steven D'Aprano wrote: > > >> > > >> Personally, I don't imagine that there ever could be a language > > >> where variables were first class values *exactly* the same as > > >> ints, strings, floats etc. > > > > > > > > [...] > > > > > > > > What you mean by *exactly* the same mean, I am not sure... > > > > > > Lisp variables (symbols) are on an equal footing with other objects. > > > IOW, lisp variables are objects in the heap. > > > Only some, or only in quite old or special members of the family. But > yes, I suppose when Lisp was still LISP, it was the kind of language > that Steven fails to imagine in the quotation above. Variables really > were symbols, which still are objects that can be passed around and > stored in data structures. Or maybe not - wasn't the essential binding > component (originally an "association list", later a more abstract > "environment", called "namespace" in Python culture) separate from the > symbol even then? Global bindings aside. > A symbol is a first-class data structure in any lisp (that I know) http://en.wikipedia.org/wiki/Homoiconicity is a defining characteristic of lisp Environments are first class in many schemes: http://sicp.ai.mit.edu/Fall-2004/manuals/scheme-7.5.5/doc/scheme_14.html (The '+'es there indicate its an MIT scheme extension; but its quite common) In my understanding a symbol can be called a variable only wrt some environment IOW there is no meaning to the word 'variable' without some notion of scope. I am not sure what your references to old and new lisps and static vs dynamic scope has to do with this. Or are you saying that in the 1960s lisps, a symbol was the string (name) along with its (dynamic binding) stack?? Python to qualify for this not only would the namespacing of locals have to be systematic with globals, the nesting structure of environments would have to be introspectively available as in the scheme example. Note the functions: environment-parent and environment-bound-names -- https://mail.python.org/mailman/listinfo/python-list
What is the difference between 32 and 64 bit Python on Windows 7 64 bit?
Hi, I want to install Python on a PC with 16GB of RAM and the 64 bit version of Windows 7. I want Python to be able to use as much as possible of the RAM. When I install the 64 bit version of Python I find that sys.maxint == 2**31 - 1 Whereas the Pythpon installed on my 64 bit linux system returns sys.maxint == 2**63 - 1. It looks to me as though 32 and 64 bit versions of Python on 64 bit Windows are both really 32 bit Python, differing only in how they interact with Windows. So I wouldn't expect 64 bit Python running on 64 bit Windows to allow the large data struictures I could have with 64 bit Python running on 64 bit linux. Is that true?I have spent a couple of hours searching for a definitive description of the difference between the 32 and 64 bit versions of Python for Windows and haven't found anything. Thanks Ross -- https://mail.python.org/mailman/listinfo/python-list
Re: What is the difference between 32 and 64 bit Python on Windows 7 64 bit?
On 5/11/2014 2:56 AM, Ross Gayler wrote: Hi, I want to install Python on a PC with 16GB of RAM and the 64 bit version of Windows 7. I want Python to be able to use as much as possible of the RAM. When I install the 64 bit version of Python I find that sys.maxint == 2**31 - 1 Since sys.maxint is gone in 3.x, you must be using some version of 2.x. Do yourself a favor and install 3.4 unless you absolutely need 2.x. With 3.4: >>> a = [None]*10 >>> sys.getsizeof(a) 800064 That is 10 8-byte pointers, as I expected. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Question on Debugging a code line
On 11/05/2014 08:45, [email protected] wrote: [268 lines snipped] Would you please use the mailing list https://mail.python.org/mailman/listinfo/python-list or read and action this https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing double line spacing and single line paragraphs, thanks. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Values and objects
Rustom Mody writes: > On Sunday, May 11, 2014 1:56:41 PM UTC+5:30, Jussi Piitulainen wrote: > > Marko Rauhamaa writes: > > > Rustom Mody: > > > > > > > On Saturday, May 10, 2014 2:39:31 PM UTC+5:30, Steven D'Aprano wrote: > > > >> > > > >> Personally, I don't imagine that there ever could be a > > > >> language where variables were first class values *exactly* > > > >> the same as ints, strings, floats etc. > > > > > > [...] > > > > > > What you mean by *exactly* the same mean, I am not sure... > > > > > Lisp variables (symbols) are on an equal footing with other > > > objects. IOW, lisp variables are objects in the heap. > > > > Only some, or only in quite old or special members of the > > family. But yes, I suppose when Lisp was still LISP, it was the > > kind of language that Steven fails to imagine in the quotation > > above. Variables really were symbols, which still are objects that > > can be passed around and stored in data structures. Or maybe not - > > wasn't the essential binding component (originally an "association > > list", later a more abstract "environment", called "namespace" in > > Python culture) separate from the symbol even then? Global > > bindings aside. > > A symbol is a first-class data structure in any lisp (that I know) > http://en.wikipedia.org/wiki/Homoiconicity is a defining characteristic of > lisp I don't see the relevance of these observations. The claim was that Lisp variables are symbols. What do you write in Common Lisp in place of the "..." to have the following evaluate to the the value of the variable x? (let ((x (f)) (y 'x)) (... y ...)) No, (eval y) is not an answer, and (symbol-value y) is not an answer: these do not do the thing at all. To suggest (progn y x) is to concede my point that there is no way to get the value of x through the symbol x that is the value of y. > Environments are first class in many schemes: > http://sicp.ai.mit.edu/Fall-2004/manuals/scheme-7.5.5/doc/scheme_14.html > (The '+'es there indicate its an MIT scheme extension; but its quite common) It's not very common. A couple of top-level environment specifiers are in the reports (scheme-report-environment, null-environment, and interaction-environment is optional, if I recall correctly) but the crucial reifier of an arbitrary lexical environment is not, and environment specifiers can only be used as an argument to eval. Even if that were common, it seems to me a joke to say that the symbol itself is the variable, which is the claim that I responded to. It's like saying that pairs of integers are first class variables because they can be interpreted as lexical addresses wrt an environment. You know, (0, 0) refers to the first variable in the current environment frame, (3, 1) to the second variable in a specific ancestor frame, and so on. > In my understanding a symbol can be called a variable only wrt some > environment > > IOW there is no meaning to the word 'variable' without some notion > of scope. Agreed. So you consider it reasonable to say that variables are symbols in Lisp, and then clarify that a symbol means a symbol together with a first-class lexical environment, as if that was implicit in the original claim (and as if such environments were widely available in Lisp)? If so, I admit I've been fooled, and I've spent far too much time on this already. At least I was responding in good faith. > I am not sure what your references to old and new lisps and static > vs dynamic scope has to do with this. I'm saying that lexical variables are not accessible through the symbol that happens to look like the variable in the source code. And I'm saying that it's the lexical variables that need to be considered, because they are the default kind even in Lisp today. Dynamic variables are special. (They are even _called_ special.) I'm not saying that a dynamic variable cannot be accessed through the symbol, because that doesn't seem to be true. (I installed a Common Lisp and experimented a little when I wrote my original response.) > Or are you saying that in the 1960s lisps, a symbol was the string > (name) along with its (dynamic binding) stack?? It seems to be the case today, in Common Lisp, that a special variable is accessible through the symbol. For example, (symbol-value y) would work in my example above if x had been declared special. The dynamic environment is implicit. In the 1960s, before Scheme AFAIUI, things were that way. > Python to qualify for this not only would the namespacing of locals > have to be systematic with globals, the nesting structure of > environments would have to be introspectively available as in the > scheme example. > > Note the functions: environment-parent and environment-bound-names If Marko meant MIT Scheme when he said Lisp, and reification of arbitrary lexical environments when he said symbol, I've responded to a quite different claim than he intended, and spent far too much effort on this. -- https://mail.python.org/mail
Re: Values and objects
On Sun, 11 May 2014 11:26:41 +0300, Jussi Piitulainen wrote: > Marko Rauhamaa writes: >> Rustom Mody: >> >> > On Saturday, May 10, 2014 2:39:31 PM UTC+5:30, Steven D'Aprano wrote: >> >> >> >> Personally, I don't imagine that there ever could be a language >> >> where variables were first class values *exactly* the same as ints, >> >> strings, floats etc. >> > >> > [...] >> > >> > What you mean by *exactly* the same mean, I am not sure... >> >> Lisp variables (symbols) are on an equal footing with other objects. >> IOW, lisp variables are objects in the heap. > > Only some, or only in quite old or special members of the family. But > yes, I suppose when Lisp was still LISP, it was the kind of language > that Steven fails to imagine in the quotation above. Variables really > were symbols, which still are objects that can be passed around and > stored in data structures. Or maybe not - wasn't the essential binding > component (originally an "association list", later a more abstract > "environment", called "namespace" in Python culture) separate from the > symbol even then? Global bindings aside. I'm not sure if you are agreeing or disagreeing that variables are values in Common Lisp or not. First you say they are, they you say "maybe not". The point is, it is *logically impossible* for a language to use precisely the same syntax for value-assignment and variable-assignment. Consider the variable called "x", which is bound to the value 23. If the language has a single assignment operator or statement: let y := name; that cannot be used for *both* binding the value 23 to y and binding the variable "x" to y (making y an alias for x). To use Pascal as an example, you cannot use the same declaration for pass- by-value and pass-by-reference, one or the other must use different syntax. function foo(x: integer, var y: integer): integer; Given that declaration, and the function call foo(a, b), x is bound to the value of a, while y is bound to the variable b. In the case of Common List, I count at least four different assignment forms: set, setq, setf, psetq, let plus two unbinding forms: makunbound, fmakunbound but I don't know enough about Lisp to tell you which ones implement binding-to-values and which binding-to-variables, if any. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: What is the difference between 32 and 64 bit Python on Windows 7 64 bit?
On Sat, May 10, 2014 at 11:56 PM, Ross Gayler wrote: > > Hi, > > I want to install Python on a PC with 16GB of RAM and the 64 bit version of > Windows 7. > I want Python to be able to use as much as possible of the RAM. > > When I install the 64 bit version of Python I find that sys.maxint == 2**31 > - 1 > Whereas the Pythpon installed on my 64 bit linux system returns sys.maxint == > 2**63 - 1. > That comes from the underlying C implementation. 64-bit MSVC still has long int as 32-bit. You need to specify long long int to get a 64-bit number even on a 64-bit compiler. Microsoft is a little nuts on the backwards compatiblity. > It looks to me as though 32 and 64 bit versions of Python on 64 bit Windows > are both really 32 bit Python, differing only in how they interact with > Windows. So I wouldn't expect 64 bit Python running on 64 bit Windows to > allow the large data struictures I could have with 64 bit Python running on > 64 bit linux. > > Is that true?I have spent a couple of hours searching for a definitive > description of the difference between the 32 and 64 bit versions of Python > for Windows and haven't found anything. > long int (the size of an integer) != size_t (the size of an object). 64-bit Python still uses 64-bit pointers so it can still address more than 4GB of memory. It just rolls over into longs after 32-bit int max instead of after 64-bit int max. -- https://mail.python.org/mailman/listinfo/python-list
Re: Values and objects
On 11/05/2014 04:11, Steven D'Aprano wrote:
[...]
And try running
this function in both 2.7 and 3.3 and see if you can explain the
difference:
def test():
if False: x = None
exec("x = 1")
return x
I must confess to being baffled by what happens in 3.3 with this
example. Neither locals() nor globals() has x = 1 immediately before the
return statement, so what is exec("x = 1") actually doing?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Values and objects
On Sunday, May 11, 2014 6:21:08 PM UTC+5:30, Steven D'Aprano wrote: > The point is, it is *logically impossible* for a language to use > precisely the same syntax for value-assignment and variable-assignment. > Consider the variable called "x", which is bound to the value 23. If the > language has a single assignment operator or statement: Its called set in classic lisp. Here's an emacs lisp session (the oldest lisp I can lay my hands on) The semicolons are comments like python's # *** Welcome to IELM *** Type (describe-mode) for help. ELISP> (set (quote d) "Hello World") "Hello World" ELISP> (set (quote c) (quote d)) d ELISP> ; those quote-s are getting boring ELISP> (set 'b 'c) c ELISP> ; once more short-form a very common case ELISP> (setq a 'b) b ELISP> ; Now unfold the chain ELISP> ; Level 0 ELISP> 'a a ELISP> ; Level 1 ELISP> a b ELISP> ;Level 2 ELISP> (eval a) c ELISP> ;Level 3 ELISP> (eval (eval a)) d ELISP> ;Level 4 ELISP> (eval (eval (eval a))) "Hello World" ELISP> IOW set UNIFORMLY evaluates its 2 arguments. To get usual assignment like behavior of normal programming languages, one (typically) quotes the first argument. This is a sufficiently common case that it gets its own 'special form' -- setq (ie set-quote) However the more general case in which (the name of)* the variable is evaluated at run-time is always available. * "Name of" is strictly not correct because: ELISP> (symbol-name 'a) "a" However if I dont say the "name of..." its hard to speak in an intelligible way. Here is the relevant intro from the elisp manual: A "symbol" in GNU Emacs Lisp is an object with a name. The symbol name serves as the printed representation of the symbol. In ordinary Lisp use, ... a symbol's name is unique--no two symbols have the same name. A symbol can serve as a variable, as a function name, or to hold a property list. Or it may serve only to be distinct from all other Lisp objects, so that its presence in a data structure may be recognized reliably. tl;dr: Quote-Eval go up and down the 'meta-language' tower just as Lambda-(function)Apply go up and down the functional tower. Elaborated further: http://blog.languager.org/2013/08/applying-si-on-sicp.html -- https://mail.python.org/mailman/listinfo/python-list
Using threads for audio computing?
Hello, I'd like to be able to analyze incoming audio from a sound card using Python, and I'm trying to establish a correct architecture for this. Getting the audio is OK (using PyAudio), as well as the calculations needed, so won't be discussing those, but the general idea of being able at (roughly) the same time: getting audio, and performing calculation on it, while not loosing any incoming audio. I also make the assumption that my calculations on audio will be done faster than the time I need to get the audio itself, so that the application would be almost real time. So far my idea (which works according to the small tests I did) consist of using a Queue object as a buffer for the incoming audio and two threads, one to feed the queue, the other to consume it. The queue could store the audio as a collection of numpy array of x samples. The first thread work would be to put() into the queue new chunks of audio as they are received from the audio card, while the second would get() from the queue chunks and perform the necessary calculations on them. Am I in the right direction, or is there a better general idea? Thanks! -- https://mail.python.org/mailman/listinfo/python-list
Re: Using threads for audio computing?
In article <[email protected]>, lgabiot wrote: > Hello, > > I'd like to be able to analyze incoming audio from a sound card using > Python, and I'm trying to establish a correct architecture for this. > > Getting the audio is OK (using PyAudio), as well as the calculations > needed, so won't be discussing those, but the general idea of being able > at (roughly) the same time: getting audio, and performing calculation on > it, while not loosing any incoming audio. > I also make the assumption that my calculations on audio will be done > faster than the time I need to get the audio itself, so that the > application would be almost real time. > > > So far my idea (which works according to the small tests I did) consist > of using a Queue object as a buffer for the incoming audio and two > threads, one to feed the queue, the other to consume it. > > > The queue could store the audio as a collection of numpy array of x samples. > The first thread work would be to put() into the queue new chunks of > audio as they are received from the audio card, while the second would > get() from the queue chunks and perform the necessary calculations on them. > > Am I in the right direction, or is there a better general idea? > > Thanks! If you are going to use threads, the architecture you describe seems perfectly reasonable. It's a classic producer-consumer pattern. But, I wonder if you even need anything this complicated. Using a queue to buffer work between threads makes sense if the workload presented is uneven. Sometimes you'll get a burst of work all at once and don't have the capacity to process it in real-time, so you want to buffer it up. I would think sampling audio would be a steady stream. Every x ms, you get another chunk of samples, like clockwork. Is this not the case? -- https://mail.python.org/mailman/listinfo/python-list
Re: Values and objects
Rustom Mody : > On Sunday, May 11, 2014 11:51:59 AM UTC+5:30, Marko Rauhamaa wrote: >> Lisp variables (symbols) are on an equal footing with other objects. >> IOW, lisp variables are objects in the heap. > > But is a symbol a variable?? Yes. A classic lisp symbol is even more "variable" than most other variables! It can hold *two* values. One is called a value binding and the other one the function binding. Scheme has unified the two; scheme symbols have only one value binding, which can be a function. > Sure, by providing a data-structure symbol, lisp provides one of the > key building blocks for developing language processing systems. > > However I would argue that a variable is not a merely a symbol > (identifier in more usual programming language-speak) but a relation > between identifiers/symbols and some 'rhs' The lisp symbol really is a data object with several fields: I can think of name, value, function and properties. They can be accessed with accessor functions. (Interestingly, scheme doesn't have the 'symbol-value accessor function of lisp's.) If lisp didn't have a way to rebind symbols (i.e., if it were purely functional and had no side effects), they wouldn't be so much variables as substitution spots in the code. > For an (interpreted?) language like python, rhs is naturally > value/object For a C like language it is memory. Symbols in lisp are memory slots, conceptually and physically. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Using threads for audio computing?
Le 11/05/14 16:40, Roy Smith a écrit : In article <[email protected]>, lgabiot wrote: Hello, Le 11/05/14 16:40, Roy Smith a écrit : If you are going to use threads, the architecture you describe seems perfectly reasonable. It's a classic producer-consumer pattern. But, I wonder if you even need anything this complicated. Using a queue to buffer work between threads makes sense if the workload presented is uneven. Sometimes you'll get a burst of work all at once and don't have the capacity to process it in real-time, so you want to buffer it up. I would think sampling audio would be a steady stream. Every x ms, you get another chunk of samples, like clockwork. Is this not the case? Thanks for your answer, yes, I guess I can consider audio as a steady stream. PyAudio gives me the audio samples by small chunks (2048 samples at a time for instance, while the sound card gives 48 000 samples/seconds). I accumulate the samples into a numpy array, and once the numpy array has reached the needed size (for instance 5 seconds of audio), I put this numpy array in the queue. So I think you are right in thinking that every 5 seconds I get a new chunk of audio to work on. Then I perform a calculation on this 5 seconds of audio (which needs to be done in less than 5 seconds, so that it will be ready to process the next 5 second chunk), but meanwhile, I need to still constantly get from Pyaudio a new 5 second chunk of audio. Hence my system. I guess if my calculation had to be performed on a small number of samples (i.e. under the value of the Pyaudio buffer size (2048 samples for instance), and that the calculation would last less than the time it takes to get the next 2048 samples from Pyaudio, I wouldn't need the Queue and Thread system. But in my case where I need a large buffer, it might not work? Unless I ask pyaudio to feed me directly with 5 seconds chunks (instead of the usual buffer sizes: 1024, 2048, etc...), which I didn't try, because I hadn't though of it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Values and objects
Jussi Piitulainen : > The claim was that Lisp variables are symbols. What do you write in > Common Lisp in place of the "..." to have the following evaluate to > the the value of the variable x? > > (let ((x (f)) (y 'x)) (... y ...)) > > No, (eval y) is not an answer, and (symbol-value y) is not an answer: > these do not do the thing at all. I must admit I have never used Common Lisp. I can only guess from your question its symbol-value fetches the value from the global symbol table -- even if you replaced let with let* (the two x's are not the same symbol when let is used). I don't see any practical reason for that limitation. If you allow setq/setf/set!, you have no reason to disallow symbol-value on a local variable. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On Sun, May 11, 2014 at 07:09:27AM +, Steven D'Aprano wrote: > On Sun, 11 May 2014 01:17:55 -0500, Mark H Harris wrote: > > > On 5/10/14 8:42 AM, Roy Smith wrote: > >> Ars Technica article a couple of days ago, about Fortran, and what is > >> likely to replace it: > >> > >> http://tinyurl.com/mr54p96 > >> > >> > > uhm, yeeah! > > > > 'Julia' is going to give everyone a not so small run for competition; > > justifiably so, not just against FORTRAN. > > That and two hundred other languages. > Given that Fortran is here for almost 60 years and lot of effort has been spent to keep it backwards compatible (AFAIK), I wouldn't hold my breath. Something may look like cool and great, but wait ten years and see if after major language revision you can still (more or less) easily run your existing huge projects with it. Does it require to give another option to compiler or does it require spending hours or weeks deep in the code (possibly introducing subtle bugs, too)? So far, in my opinion, very few languages can stand this test (or perhaps none at all). Strong candidates are C, Fortran, Common Lisp, and unfortunately, Java (I can only talk about those which I happened to use and checked a bit, but not extensively). I'm not really sure about Python, haven't had time/energy to check yet (but going 1.5->2.x was painless to me). > Good languages (for some definition of "good") are a dime a dozen. > Miranda, Rust, Go, D, Ceylon, Coffeescript, F#, Scala, Lua, Erlang, > Eiffel, Ocaml, Haskell, Kotlin, Grovy, Clojure, Dart, Mercury, ML... the > list of "amazing", "astounding" languages is never ending. Very few of > them take over the world, and those that do rarely do so due to technical > excellence. (BASIC, Java, PHP, Javascript ...) ... and Perl... Even if it's not as bad as I sometimes think. BTW, after seeing "@" and "$" in Julia manual, I think I will stay aside for a while. > Some of them, like Haskell, influence other languages without ever > being popular themselves. Interestingly, Haskell developers seem to not care much about old codebases in their own language (but I didn't make systematic research of the subject). I hope others will not be influenced by such attitude :-). Neglecting someone's effort to make working flawless code, forcing people into periodic rewrites of things that used to work, such events always blink red in my head. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:[email protected] ** -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
Tomasz Rola : > Given that Fortran is here for almost 60 years and lot of effort has > been spent to keep it backwards compatible (AFAIK), I wouldn't hold my > breath. I have seen a glimpse of the so-called scientific computing and Fortran programming. I can't help but think that Fortran is successful with people who don't know how to program and don't care. That's fine. If I were to build a cyclotron, I bet the Fortran coders would smile at my clumsy efforts. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On Mon, May 12, 2014 at 2:09 AM, Tomasz Rola wrote: > Given that Fortran is here for almost 60 years and lot of effort has > been spent to keep it backwards compatible (AFAIK), I wouldn't hold my > breath. Something may look like cool and great, but wait ten years and > see if after major language revision you can still (more or less) > easily run your existing huge projects with it. The Unix pipe system is still working beautifully, and will continue to do so for the next few decades. Build your system as a number of separate processes that pipe data from one into another, keep your old interpreters and compilers around, and you'll be fine. But retaining that backward compatibility is a huge cost. Sixty years ago's hardware wasn't the same as we have today. You can't simply run the exact same compiler and get the same bytes of output and run them. Someone has to maintain that old compiler, make sure it works with the latest toolchain and hardware, etc. Probably make sure it's bug-for-bug compatible with the original, too. How long do you want to keep that up? It's a huge trade-off. If a language basically says "That code you wrote two years ago? Not gonna work now", then I'd see that as a big blinking red light. But "Ten years ago's code will probably work on today's interpreter, unless it uses as identifiers what's now a keyword, or it might be unintentionally treading on now-fixed bugs in which case it might have to be fixed", that's not as big a problem. Yes, you'd need to 2to3 that old Python 2.3 code to get it to run on Python 3.4, but chances are it'll run mostly-unchanged on 2.7 (modulo string exceptions, maybe). I'm cheating a bit by citing Python 2.7, given that it's now four years old, but it's also going to be supported for a good few more years. Not sixty, presumably, but a good while. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
Mark H Harris writes: > On 5/10/14 8:42 AM, Roy Smith wrote: >> http://tinyurl.com/mr54p96 > 'Julia' is going to give everyone a not so small run for competition; > justifiably so, not just against FORTRAN. > > Julia is Matlab and R, Python, Lisp, Scheme; all rolled together on > steroids. Its amazing as a dynamic language, and its fast, like > lightning fast as well as multiprocessing (parallel processing) at its > core. Its astounding, really. Hmmm... > Its number concept is unified, What exactly is unified? There is no implicit promotion between primitive types and BigInt/Float. Conversion happens because all arithmetic is overloaded for various types, and julia does multi-dispatch. There is little chance number-crunching applications will shine in julia, unless everything is statically typed. > BigFloats are by default arbitrary precision with full scientific and > transcendental functions built-in, everything complex just works, and > did I mention its fast? Yes, julia wraps GMP and MPFR, just like many compilers already do (e.g., gcc). Very good, but nothing specific to julia here. And for linear algebra, julia uses... BLAS and LAPACK. And fftw for FFT. And so on. Nothing new for a Fortran programmer, really. > The bench-marks are within 2x of C across the boards; makes Matlab > look like a rock, and is well ahead of python (NumPy SciPy) for > technical computing. 2x for syntactic sugar is a lot. But yes, numpy/scipy developers should watch out... > Julia is still very much beta in my opinion but its maturing fast. Its > open free (libre) and cross platform and did I mention it flatout > screams? Not only will it replace FORTRAN completely if things keep > progressing, but also Matlab, Mathematica, NumPy, & SciPy (and > others). Keep your eye on her fellows. Well, Fortran experts around me are skeptic. -- Alain. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
In article <[email protected]>, Marko Rauhamaa wrote: > Tomasz Rola : > > > Given that Fortran is here for almost 60 years and lot of effort has > > been spent to keep it backwards compatible (AFAIK), I wouldn't hold my > > breath. > > I have seen a glimpse of the so-called scientific computing and Fortran > programming. I can't help but think that Fortran is successful with > people who don't know how to program and don't care. > > That's fine. If I were to build a cyclotron, I bet the Fortran coders > would smile at my clumsy efforts. It is fine. Computers are tools. The sign of a good tool is that you can pick it up and use it without having to read the instruction manual. I can jump into pretty much any car, start the engine, and drive it, without any learning curve. There's a lot of complicated organic chemistry and thermodynamics going on inside the engine's combustion chambers, but I don't need to know any of that to make use of the tool. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
On Mon, May 12, 2014 at 02:42:13AM +1000, Chris Angelico wrote: > On Mon, May 12, 2014 at 2:09 AM, Tomasz Rola wrote: > > Given that Fortran is here for almost 60 years and lot of effort has > > been spent to keep it backwards compatible (AFAIK), I wouldn't hold my > > breath. Something may look like cool and great, but wait ten years and > > see if after major language revision you can still (more or less) > > easily run your existing huge projects with it. > > The Unix pipe system is still working beautifully, and will continue [...] > > But retaining that backward compatibility is a huge cost. Sixty years > ago's hardware wasn't the same as we have today. You can't simply run > the exact same compiler and get the same bytes of output and run them. [...] > > If a language basically says "That code you wrote two years ago? Not > gonna work now", then I'd see that as a big blinking red light. But > "Ten years ago's code will probably work on today's interpreter, > unless it uses as identifiers what's now a keyword, or it might be > unintentionally treading on now-fixed bugs in which case it might have > to be fixed", that's not as big a problem. Yes, you'd need to 2to3 > that old Python 2.3 code to get it to run on Python 3.4, but chances > are it'll run mostly-unchanged on 2.7 (modulo string exceptions, > maybe). I'm cheating a bit by citing Python 2.7, given that it's now > four years old, but it's also going to be supported for a good few > more years. Not sixty, presumably, but a good while. > > ChrisA I can easily agree to your points. Personally I don't really care much about decades-old codes (unless I want to play with them inside some emulator). There was indeed a lot of change in OSes and hardware, and languages should keep up with it, if possible. And the "pipe extention" is one of the things I'd consider - as well as other similar means, like SOAP or REST. However, obsoleting code younger than five years does not feel good to me. AFAIK big projects take years to be written, polished up, debugged and sometimes refactored (during this time they may also be used and go throu their own big version changes), so it is really big pain to see how after all this work someone's decision changes ground under one's feet. As of remark by Marko Rauhamaa, that "Fortran is successful with people who don't know how to program and don't care" - I wrote maybe two Fortran programs so far, both very simple. I tried to obey so called rules, inserted comment lines, checked for return values and issued warnings/errors when needed, didn't use goto excessively (AFAIR), didn't make stupid things like changing index variable inside loop (other than by predefined step in one and only one place, be it by hand or by compiler). For one program I got max points to get (uni course) and for the other I have been presented with a basket of strawberries. Was I successful - or my use of Fortran :-)? OTOH I once had to work with someone else's Java code, a huge class in huge file and I found it too borked to repair so I rewrote from the scratch. Will I write some more code in Fortran - maybe, or maybe not. I don't feel any urgent need to do this. There is still a lot of things I'd like to learn and a day has only so many hours. I consider Fortran a useful tool which may possibly outlive me (but let's wait and see :-) ). As of quality of its users, sure, I consider programming a full time activity and it is very hard to find people who want to be good at it *and* in their supposed domain at the same time. Heck, I keep reading it is hard to find people who would like to be good in anything at all. Perhaps part of the problem is unwillingness to tackle it. I think majority of people would like to do things better, especially if it only requires small changes in behaviour. But they simply don't know there is better way, because nobody cared to tell them or show by example. Or nobody knew there were some people who would have been happy to hear a word of advice. Well, at least it is nice to believe in this. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:[email protected] ** -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
On Mon, May 12, 2014 at 4:04 AM, Tomasz Rola wrote: > And the "pipe > extention" is one of the things I'd consider - as well as other > similar means, like SOAP or REST. Yep. My point was, keep the processes separate and it's easy. There are myriad ways of doing the glue. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
On Mon, May 12, 2014 at 3:51 AM, Roy Smith wrote: > It is fine. Computers are tools. The sign of a good tool is that you > can pick it up and use it without having to read the instruction manual. > I can jump into pretty much any car, start the engine, and drive it, > without any learning curve. There's a lot of complicated organic > chemistry and thermodynamics going on inside the engine's combustion > chambers, but I don't need to know any of that to make use of the tool. Err, I don't know that the analogy is really fair. Either you know how to drive a car, or you don't; if you do, what you really mean is that cars are sufficiently standardized that, even though you trained on an X, you can drive a Y without reading its instruction manual - but if you don't, then you're basically at the dangerous level of "hey look, I can type these commands and stuff happens", without knowing the rather important safety implications of what you're doing. Can you use a hammer without an instruction manual? Sure! Can you use a circular saw without reading the instructions? Quite probably, but will you know how to do it safely? The organic chemistry and thermodynamics are the car's equivalent of refcounting and garbage collection. They're absolutely critical if you're building a car, but in driving one, you almost never need to care about those details - and it's entirely possible to have a car that doesn't work the same way (electric, perhaps). I would expect the instruction manual to be more about things like how to check the oil, so you don't blow your engine up. (Caveat: I don't drive, so I might have the details of the analogy facepalmingly wrong.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
On 05/11/2014 10:51 AM, Roy Smith wrote: In article <[email protected]>, Marko Rauhamaa wrote: Tomasz Rola : Given that Fortran is here for almost 60 years and lot of effort has been spent to keep it backwards compatible (AFAIK), I wouldn't hold my breath. I have seen a glimpse of the so-called scientific computing and Fortran programming. I can't help but think that Fortran is successful with people who don't know how to program and don't care. That's fine. If I were to build a cyclotron, I bet the Fortran coders would smile at my clumsy efforts. It is fine. Computers are tools. The sign of a good tool is that you can pick it up and use it without having to read the instruction manual. I can jump into pretty much any car, start the engine, and drive it, without any learning curve. There's a lot of complicated organic chemistry and thermodynamics going on inside the engine's combustion chambers, but I don't need to know any of that to make use of the tool. That is an excellent example. For the most part cars are very similar, yet in some circumstances (such as a vehicle in front of you suddenly stopping) the exact details (such as the precise location and size and shape of the brake pedal) become excruciatingly important (having your foot stomp the floor just to the right of the current break pedal, because that's where the brake was in your last vehicle, is not going to help here). How the lights and/or windshield wipers turn on/off is also an important detail. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
On Mon, May 12, 2014 at 4:05 AM, Ethan Furman wrote: > For the most part cars are very similar, yet in some circumstances (such as > a vehicle in front of you suddenly stopping) the exact details (such as the > precise location and size and shape of the brake pedal) become > excruciatingly important (having your foot stomp the floor just to the right > of the current break pedal, because that's where the brake was in your last > vehicle, is not going to help here). Some things are more standardized than others. A piano keyboard is incredibly standard, to make it possible to play without having to look at your fingers (even when jumping your hands around, which doesn't happen as much on a computer keyboard); mobile phones are anything but, so you really need to get to know your particular phone (there may or may not even be brand similarities). But that's really tangential to the question of using something without gaining any skill in it; it's more a matter of how well skill gained on one device in a class translates to other devices in that class. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Values and objects
On 5/11/14 9:46 AM, Rotwang wrote:
On 11/05/2014 04:11, Steven D'Aprano wrote:
[...]
And try running
this function in both 2.7 and 3.3 and see if you can explain the
difference:
def test():
if False: x = None
exec("x = 1")
return x
I must confess to being baffled by what happens in 3.3 with this
example. Neither locals() nor globals() has x = 1 immediately before the
return statement, so what is exec("x = 1") actually doing?
The same happens if you try to modify locals():
>>> def test():
... if 0: x = 1
... locals()['x'] = 13
... return x
...
>>> test()
Traceback (most recent call last):
File "", line 1, in
File "", line 4, in test
UnboundLocalError: local variable 'x' referenced before assignment
The doc for exec says:
Note: The default locals act as described for function locals()
below: modifications to the default locals dictionary should not be
attempted. Pass an explicit locals dictionary if you need to see
effects of the code on locals after function exec() returns.
The doc for locals says:
Note: The contents of this dictionary should not be modified;
changes may not affect the values of local and free variables used
by the interpreter.
This is a tradeoff of practicality for purity: the interpreter runs
faster if you don't make locals() a modifiable dict.
--
Ned Batchelder, http://nedbatchelder.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
In article , Chris Angelico wrote: > Some things are more standardized than others. A piano keyboard is > incredibly standard, to make it possible to play without having to > look at your fingers (even when jumping your hands around, which > doesn't happen as much on a computer keyboard) Speaking of which, here's a trivia question. Without looking at your keyboard, describe how the "F" and "J" keys (assuming a US-English key layout) differ from, say, the "G" and "K" keys. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On 5/11/14 12:05 PM, Alain Ketterlin wrote: Julia is Matlab and R, Python, Lisp, Scheme; all rolled together on steroids. Its amazing as a dynamic language, and its fast, like lightning fast as well as multiprocessing (parallel processing) at its core. Its astounding, really. Hmmm... Its number concept is unified, What exactly is unified? There is no implicit promotion between primitive types and BigInt/Float. The built-in math functions (extensive, by the way) just work, and they work consistently the way you might expect across types. Consider sqrt(): > julia> sqrt(-1+0im) > 0.0 + 1.0im > julia> sqrt(complex(-1)) > 0.0 + 1.0im > julia> sqrt(2) > 1.4142135623730951 >julia> sqrt(2.0) > 1.4142135623730951 > julia> sqrt(BigFloat(2.0)) >1.414213562373095048801688724209698078569671875376948073176679737990732478462102 >e+00 with 256 bits of precision >julia> with_bigfloat_precision(1024) do > sqrt(BigFloat(2.0)) > end >1.414213562373095048801688724209698078569671875376948073176679737990732478462107 >03885038753432764157273501384623091229702492483605585073721264412149709993583141 >32226659275055927557999505011527820605714701095599716059702745345968620147285174 >18640889198609552329230484308714321450839762603627995251407989687253402e+00 >with 1024 bits of precision You'll notice that I did not need to import anything to use sqrt(), and sqrt() takes all types and does something meaningful with them. The following code will produce over 100,000 digits of π (pi) in less than 2 seconds on a low-end processor, like my mac mini dual core 2Ghz: >julia> prec=524288 >524288 >julia> with_bigfloat_precision(prec) do > println(atan(BigFloat(1)/5)*16 - atan(BigFloat(1)/239)*4) > end The scientific and transcendental functions (built-ins) just work. The coder sets the precision in floating point bits, and the functions just work --- at that precision. Nothing needs to be imported, and special functions are not necessary. The maths are unified, and they are fast; yet, the coder has the flexibility and ease of python coding, with a very useful repl. But, like lisp, Julia's internal structures are lists, so, it can create and modify its own code on-the-fly. Unicode characters above code point \u00A0 can be used as symbols, and constants ARE their unicode characters: >julia> sin(π/4) > 0.7071067811865475 >julia> cos(π/4) > 0.7071067811865476 >julia> sin(BigFloat(π/4)) > 7.0710678118654750275194295621751674626154323953749278952436611913748 > 20215180412e-01 with 256 bits of precision marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On Mon, May 12, 2014 at 4:54 AM, Mark H Harris wrote: > The following code will produce over 100,000 digits of π (pi) in less than 2 > seconds on a low-end processor, like my mac mini dual core 2Ghz: > >>julia> prec=524288 >>524288 > >>julia> with_bigfloat_precision(prec) do >> println(atan(BigFloat(1)/5)*16 - atan(BigFloat(1)/239)*4) >> end Would it be quicker (and no less accurate) to represent pi as atan(BigFloat(1))*4 instead? That's how I originally met a pi-calculation (as opposed to "PI = 3.14" extended to however much accuracy someone cared to do). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.
Thank you everyone who replied, for your help. Using the command prompt console, it accepts the first line of code, but doesn't seem to accept the second line. I have altered it a little, but it is not having any of it, I quote my console input and output here, as it can probably explain things better than I :- Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\Intel Atom>cd"c:\Beautiful Soup" The filename, directory name, or volume label syntax is incorrect. C:\Users\Intel Atom>cd "c:\Beautiful Soup" c:\Beautiful Soup>python setup.py install. File "setup.py", line 22 print "Unit tests have failed!" ^ SyntaxError: invalid syntax c:\Beautiful Soup>python setup.py install" File "setup.py", line 22 print "Unit tests have failed!" ^ SyntaxError: invalid syntax c:\Beautiful Soup> I have tried writing "python setup.py install" ie putting the statement in inverted commas, but the console still seems to reject it re:- c:\Beautiful Soup>"python setup. py install" '"python setup. py install"' is not recognized as an internal or external comman d, operable program or batch file. c:\Beautiful Soup> Again I hope you python practitioners can help. I am only on page 12, and have another 99 pages to go, so can only hope it gets easier. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On 5/11/14 1:59 PM, Chris Angelico wrote: julia> prec=524288 524288 julia> with_bigfloat_precision(prec) do println(atan(BigFloat(1)/5)*16 - atan(BigFloat(1)/239)*4) end Would it be quicker (and no less accurate) to represent pi as atan(BigFloat(1))*4 instead? That's how I originally met a pi-calculation (as opposed to "PI = 3.14" extended to however much accuracy someone cared to do). No. Simple experiment will show you. The atan(x<=1) will converge faster. For 524288 bits atan(1) formula converged in 3 seconds, and Machin's formula atan(x<1) converged in 2 seconds. Where it becomes very apparent is 10K and 100K or above. Also, the difference is much more noticeable in Python than in Julia, but it is there no-the-less. But here is the cool part: what if your π function could be broken down into three very fast converging atan(x<1) functions like this one: > pi = 24*atan(1/8) + 8*atan(1/57) + 4*atan(1/239)(Shanks used this) ... and then, you have julia send each piece to a separate processor|core (it does this at its center) and they converge together, then julia pieces them together at the end. Then things get incredibly faster. -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.
On Mon, May 12, 2014 at 5:05 AM, Simon Evans wrote: > Thank you everyone who replied, for your help. Using the command prompt > console, it accepts the first line of code, but doesn't seem to accept the > second line. I have altered it a little, but it is not having any of it, I > quote my console input and output here, as it can probably explain things > better than I :- > Thank you. This sort of transcript does make it very easy to see what's going on! > Microsoft Windows [Version 6.1.7601] > Copyright (c) 2009 Microsoft Corporation. All rights reserved. > > C:\Users\Intel Atom>cd"c:\Beautiful Soup" > The filename, directory name, or volume label syntax is incorrect. Command line syntax is always to put a command first (one word), and then its arguments (zero, one, or more words). You put quotes around a logical word when it has spaces in it. So, for instance, "foo bar" is one logical word. In this case, you omitted the space between the command and its argument, so Windows couldn't handle it. [1] > C:\Users\Intel Atom>cd "c:\Beautiful Soup" And this is correct; you put quotes around the argument, and execute the "cd" command with an argument of "c:\Beautiful Soup". It then works, as is shown by the change of prompt in your subsequent lines. > c:\Beautiful Soup>python setup.py install. > File "setup.py", line 22 > print "Unit tests have failed!" > ^ > SyntaxError: invalid syntax This indicates that you've installed a 3.x version of Python as the default, and setup.py is expecting a 2.x Python. Do you have multiple Pythons installed? Try typing this: c:\Python27\python setup.py install (That will work only if you have Python 2.7 installed into the default location.) Hope that helps! ChrisA [1] Windows lets you be a bit sloppy; for instance, cd\ works without a space between the command and the argument. (AFAIK this is true if and only if the path name starts with a backslash.) But normally, you separate command and argument(s) with a space. -- https://mail.python.org/mailman/listinfo/python-list
Re: Values and objects
Marko Rauhamaa : > I don't see any practical reason for that limitation. If you allow > setq/setf/set!, you have no reason to disallow symbol-value on a local > variable. In fact, the reason probably is practical and analogous to the locals() caveat in Python. If the language made local variables available indirectly, I'm guessing some optimizations would be much harder or impossible. In my own lisp implementation, where performance is not a concern at all, the local variables are both lexically scoped and offer access to symbol-value. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.
Dear Chris Angelico, Yes, you are right, I did install Python 3.4 as well as 2.7. I have removed Python 3.4, and input the code you suggested and it looks like it has installed properly, returning the following code:- Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\Intel Atom>cd "c:\Beautiful Soup" c:\Beautiful Soup>c:\Python27\python setup.py install running install running build running build_py creating build creating build\lib copying BeautifulSoup.py -> build\lib copying BeautifulSoupTests.py -> build\lib running install_lib copying build\lib\BeautifulSoup.py -> c:\Python27\Lib\site-packages copying build\lib\BeautifulSoupTests.py -> c:\Python27\Lib\site-packages byte-compiling c:\Python27\Lib\site-packages\BeautifulSoup.py to BeautifulSoup.p yc byte-compiling c:\Python27\Lib\site-packages\BeautifulSoupTests.py to BeautifulS oupTests.pyc running install_egg_info Writing c:\Python27\Lib\site-packages\BeautifulSoup-3.2.1-py2.7.egg-info c:\Beautiful Soup> Would that things were as straightforward as they are in the books, but anyway thank you much for your assistance, I'd still be typing the zillionth variation on the first line without your help. I don't doubt though that I will be coming unstuck in the not distant future. Until then, again thank you for your selfless help. -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.
On 2014-05-11 21:03, Simon Evans wrote: Dear Chris Angelico, Yes, you are right, I did install Python 3.4 as well as 2.7. I have removed Python 3.4, and input the code you suggested and it looks like it has installed properly, returning the following code:- Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\Intel Atom>cd "c:\Beautiful Soup" c:\Beautiful Soup>c:\Python27\python setup.py install running install running build running build_py creating build creating build\lib copying BeautifulSoup.py -> build\lib copying BeautifulSoupTests.py -> build\lib running install_lib copying build\lib\BeautifulSoup.py -> c:\Python27\Lib\site-packages copying build\lib\BeautifulSoupTests.py -> c:\Python27\Lib\site-packages byte-compiling c:\Python27\Lib\site-packages\BeautifulSoup.py to BeautifulSoup.p yc byte-compiling c:\Python27\Lib\site-packages\BeautifulSoupTests.py to BeautifulS oupTests.pyc running install_egg_info Writing c:\Python27\Lib\site-packages\BeautifulSoup-3.2.1-py2.7.egg-info c:\Beautiful Soup> Would that things were as straightforward as they are in the books, but anyway thank you much for your assistance, I'd still be typing the zillionth variation on the first line without your help. I don't doubt though that I will be coming unstuck in the not distant future. Until then, again thank you for your selfless help. You didn't need to remove Python 3.4. When you typed: python setup.py install it defaulted to Python 3.4, presumably because that was the last one you installed. You just needed to be explicit instead: C:\Python27\python.exe setup.py install -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.
On 5/11/2014 3:17 PM, Chris Angelico wrote: On Mon, May 12, 2014 at 5:05 AM, Simon Evans wrote: c:\Beautiful Soup>python setup.py install. There is no need for a standalone Beautiful Soup directory. See below. File "setup.py", line 22 print "Unit tests have failed!" ^ SyntaxError: invalid syntax This indicates that you've installed a 3.x version of Python as the default, and setup.py is expecting a 2.x Python. Do you have multiple Pythons installed? Try typing this: c:\Python27\python setup.py install (That will work only if you have Python 2.7 installed into the default location.) Please do not advise people to unnecessarily downgrade to 2.7 ;-). Simon just needs the proper current version of BeautifulSoup. BeautifulSoup3 does not work with 3.x. BeautifulSoup4 works with 2.6+ and 3.x. http://www.crummy.com/software/BeautifulSoup/ Installation (of the latest version on PyPI) is trivial with 3.4: C:\Programs\Python34>pip install beautifulsoup4 Downloading/unpacking beautifulsoup4 Running setup.py (path:C:\Users\Terry\AppData\Local\Temp\pip_build_Terry\beautifulsoup4\setup.py) egg_info for package beautifulsoup4 Installing collected packages: beautifulsoup4 Running setup.py install for beautifulsoup4 Skipping implicit fixer: buffer Skipping implicit fixer: idioms Skipping implicit fixer: set_literal Skipping implicit fixer: ws_comma Successfully installed beautifulsoup4 Cleaning up... --- Adding the '4' is necessary as >pip install beautifulsoup tries to install beautifulsoup3 as a py3.4 package and that fails with the SyntaxError message Simon got. With '4', there is now an entry in lib/site-packages you are ready to go. Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)] on win32 >>> from bs4 import BeautifulSoup # from the bs4 online doc >>> BeautifulSoup -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.
I have downloaded Beautiful Soup 3, I am using Python 2.7. I understand from your message that I ought to use Python 2.6 or Python 3.4 with Beautiful Soup 4, the book I am using 'Getting Started with Beautiful Soup' is for Beautiful Soup 4. Therefore I gather I must re-download Beautiful Soup and get the 4 version, dispose of my Python 2.7 and reinstall Python 3.4. I am sure I can do this, but doesn't the above information suggest that the only Python grade left that might work with Beautiful Soup 3 would by Python 2.7 - which is the configuration I have at present, though I am not perfectly happy, as it is not taking code in the book (meant for BS4) such as the following on page 16 : helloworld = "Hello World" re:- c:\Beautiful Soup>helloworld = "Hello World" 'helloworld' is not recognized as an internal or external command, operable program or batch file. I take it that this response is due to using code meant for BS4 with Python 2.6/ 3.4, rather than BS3 with Python 2.7 which is what I am currently using. If so I will change the configurations. -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.
On 2014-05-11 23:03, Simon Evans wrote: I have downloaded Beautiful Soup 3, I am using Python 2.7. I understand from your message that I ought to use Python 2.6 or Python 3.4 with Beautiful Soup 4, the book I am using 'Getting Started with Beautiful Soup' is for Beautiful Soup 4. Therefore I gather I must re-download Beautiful Soup and get the 4 version, dispose of my Python 2.7 and reinstall Python 3.4. I am sure I can do this, but doesn't the above information suggest that the only Python grade left that might work with Beautiful Soup 3 would by Python 2.7 - which is the configuration I have at present, though I am not perfectly happy, as it is not taking code in the book (meant for BS4) such as the following on page 16 : helloworld = "Hello World" re:- c:\Beautiful Soup>helloworld = "Hello World" 'helloworld' is not recognized as an internal or external command, operable program or batch file. I take it that this response is due to using code meant for BS4 with Python 2.6/ 3.4, rather than BS3 with Python 2.7 which is what I am currently using. If so I will change the configurations. That's the Windows command prompt, not the Python command prompt. -- https://mail.python.org/mailman/listinfo/python-list
Re: Values and objects
On 11/05/2014 19:40, Ned Batchelder wrote:
On 5/11/14 9:46 AM, Rotwang wrote:
On 11/05/2014 04:11, Steven D'Aprano wrote:
[...]
And try running
this function in both 2.7 and 3.3 and see if you can explain the
difference:
def test():
if False: x = None
exec("x = 1")
return x
I must confess to being baffled by what happens in 3.3 with this
example. Neither locals() nor globals() has x = 1 immediately before the
return statement, so what is exec("x = 1") actually doing?
The same happens if you try to modify locals():
>>> def test():
... if 0: x = 1
... locals()['x'] = 13
... return x
...
>>> test()
Traceback (most recent call last):
File "", line 1, in
File "", line 4, in test
UnboundLocalError: local variable 'x' referenced before assignment
The doc for exec says:
Note: The default locals act as described for function locals()
below: modifications to the default locals dictionary should not be
attempted. Pass an explicit locals dictionary if you need to see
effects of the code on locals after function exec() returns.
The doc for locals says:
Note: The contents of this dictionary should not be modified;
changes may not affect the values of local and free variables used
by the interpreter.
This is a tradeoff of practicality for purity: the interpreter runs
faster if you don't make locals() a modifiable dict.
Thanks.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote: > In article , > Chris Angelico wrote: > >> Some things are more standardized than others. A piano keyboard is >> incredibly standard, to make it possible to play without having to look >> at your fingers (even when jumping your hands around, which doesn't >> happen as much on a computer keyboard) > > Speaking of which, here's a trivia question. Without looking at your > keyboard, describe how the "F" and "J" keys (assuming a US-English key > layout) differ from, say, the "G" and "K" keys. The F and J keys have "F" and "J" printed on them instead of "G" and "K". They're also in slightly different positions, offset one position to the left. Otherwise they are identical, to the limits of my vision and touch. (I haven't tried measuring them with a micrometer, or doing chemical analysis of the material they are made of.) -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.
Yeah well at no point does the book say to start inputting the code mentioned in Python command prompt rather than the Windows command prompt, but thank you for your guidance anyway. I have downloaded the latest version of Beautiful Soup 4, but am again facing problems with the second line of code, re:- --- Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\Intel Atom>cd "c:\Beautiful Soup" c:\Beautiful Soup>c:\Python27\python setup.py install c:\Python27\python: can't open file 'setup.py': [Errno 2] No such file or direct ory though that was the code I used before which installed okay see above). Can anyone tell me where I am going wrong ? Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.
On Monday, May 12, 2014 12:19:24 AM UTC+1, Simon Evans wrote: > Yeah well at no point does the book say to start inputting the code mentioned > in Python command prompt rather than the Windows command prompt, but thank > you for your guidance anyway. > > I have downloaded the latest version of Beautiful Soup 4, but am again facing > problems with the second line of code, re:- > > --- > > > Microsoft Windows [Version 6.1.7601] > > Copyright (c) 2009 Microsoft Corporation. All rights reserved. > > > > C:\Users\Intel Atom>cd "c:\Beautiful Soup" > > > > c:\Beautiful Soup>c:\Python27\python setup.py install > > c:\Python27\python: can't open file 'setup.py': [Errno 2] No such file or > direct > > ory > > > > though that was the code I used before which installed okay see above). Can > anyone tell me where I am going wrong ? Thanks. Oh I think I see - I should be using Python 3.4 now, with BS4 ? -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.
- but wait a moment 'BeautifulSoup4 works with 2.6+ and 3.x'(Terry Reedy) - doesn't 2.6 + = 2.7, which is what I'm using with BeautifulSoup4. -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.
On Sun, May 11, 2014 at 5:19 PM, Simon Evans wrote: > Yeah well at no point does the book say to start inputting the code mentioned > in Python command prompt rather than the Windows command prompt, but thank > you for your guidance anyway. > I have downloaded the latest version of Beautiful Soup 4, but am again facing > problems with the second line of code, re:- > --- > Microsoft Windows [Version 6.1.7601] > Copyright (c) 2009 Microsoft Corporation. All rights reserved. > > C:\Users\Intel Atom>cd "c:\Beautiful Soup" > > c:\Beautiful Soup>c:\Python27\python setup.py install > c:\Python27\python: can't open file 'setup.py': [Errno 2] No such file or > direct > ory > > though that was the code I used before which installed okay see above). Can > anyone tell me where I am going wrong ? Thanks. The error message is telling you that the file setup.py that you're trying to run is missing. That would seem to indicate that Beautiful Soup hasn't been downloaded or unzipped correctly. What do you have in the Beautiful Soup directory? Also, use Python 3.4 as Terry Reedy suggested, unless the book is using 2.7 in which case you should probably use the same version as the book. -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.
On 5/11/2014 6:03 PM, Simon Evans wrote: I have downloaded Beautiful Soup 3, I am using Python 2.7. I understand from your message that I ought to use Python 2.6or Python 3.4 with Beautiful Soup 4, I wrote "BeautifulSoup4 works with 2.6+ and 3.x.". '2.6+' means 2.6 or 2.7. '3.x' should mean 3.1 to 3.4 but the range might start later. It does not matter because you should download and use 3.4 unless you *really* need to use something earlier. But also note that Windows has no problem with multiple version of python installed in different pythonxy directories. One of the things 3.4 does for you is make sure that pip is installed. It is now the more or less 'official' python package installer. To install BS4, do what the authors recommend on their web page http://www.crummy.com/software/BeautifulSoup/ and what I did: 'pip install beautifulsoup4' in a python34 directory. It took me less than a minute, far less that it took you to report that doing something else did not work. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
On 2014-05-12 00:15, Steven D'Aprano wrote: On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote: In article , Chris Angelico wrote: Some things are more standardized than others. A piano keyboard is incredibly standard, to make it possible to play without having to look at your fingers (even when jumping your hands around, which doesn't happen as much on a computer keyboard) Speaking of which, here's a trivia question. Without looking at your keyboard, describe how the "F" and "J" keys (assuming a US-English key layout) differ from, say, the "G" and "K" keys. The F and J keys have "F" and "J" printed on them instead of "G" and "K". They're also in slightly different positions, offset one position to the left. Otherwise they are identical, to the limits of my vision and touch. (I haven't tried measuring them with a micrometer, or doing chemical analysis of the material they are made of.) Maybe keyboards are different where you are! :-) Mine have an little ridge on the keytop of those keys. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
On Mon, 12 May 2014 04:08:15 +1000, Chris Angelico wrote: > On Mon, May 12, 2014 at 3:51 AM, Roy Smith wrote: >> It is fine. Computers are tools. The sign of a good tool is that you >> can pick it up and use it without having to read the instruction >> manual. I can jump into pretty much any car, start the engine, and >> drive it, without any learning curve. There's a lot of complicated >> organic chemistry and thermodynamics going on inside the engine's >> combustion chambers, but I don't need to know any of that to make use >> of the tool. > > Err, I don't know that the analogy is really fair. Either you know how > to drive a car, or you don't; if you do, what you really mean is that > cars are sufficiently standardized that, even though you trained on an > X, you can drive a Y without reading its instruction manual Correct. It's a terrible analogy. Cars are relatively simple things, they basically have three functions: speed up, turn, slow down. And yet look at how many people manage to kill themselves, and others, by doing it wrong. In the US, more people die *each year* due to faulty driving than American soldiers died in the entire Vietnam war. (The one exception was 1968.) Programming languages, on the other hand, have effectively an infinite number of functions: most languages come built-in with dozens or hundreds, and the programmer then extends them with whatever functions they need. Cars are standardized -- there are basically two types, manuals and automatics. Programming languages are not, and thank goodness, because they whole point of having multiple programming languages is that they have different semantic models and different syntax so as to specialise on different tasks. I'm a critic of C the language, but only for application development -- it makes a grand high-level assembly language for low-level programming by experts where fine control and efficiency is more important than simplicity and programmer efficiency. Fortran is excellent for long-lasting numeric work, and Inform-7 is excellent for writing interactive fiction. I wouldn't write an 3D shooter game in bash, and I wouldn't write a throw-away admin script in Java. > - but if you > don't, then you're basically at the dangerous level of "hey look, I can > type these commands and stuff happens", without knowing the rather > important safety implications of what you're doing. Can you use a hammer > without an instruction manual? Sure! Can you use a circular saw without > reading the instructions? Quite probably, but will you know how to do it > safely? Circular saws have only a few functions: start spinning, and stop spinning. There's a few "gotchas" to learn, related to physical properties (momentum, energy transfer, the relative hardness and sharpness of the blade versus the softness of your fingers...) and maybe a couple of bells and whistles (e.g. can you cut on angles?). It's not within an order of magnitude of the complexity of a programming language. A better comparison would be with one of these: http://www.wisegeek.org/what-are-cnc-machines.htm And no surprise, to operate a CNC machine, the operator typically has to program it using a programming language (G-code). -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.
On Sun, May 11, 2014 at 5:47 PM, Ian Kelly wrote:
> Also, use Python 3.4 as Terry Reedy suggested, unless the book is
> using 2.7 in which case you should probably use the same version as
> the book.
Following up on that, if this is the book you are using:
http://www.amazon.com/Getting-Started-Beautiful-Soup-Vineeth/dp/1783289554
then it says to use Python 2.7.5 or greater. There is no indication
that the book is targeted at Python 3, and in fact I see at least one
line that won't work in Python 3 ("import urllib2"), so I definitely
recommend sticking with a 2.7 release.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
In article , MRAB wrote: > On 2014-05-12 00:15, Steven D'Aprano wrote: > > On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote: > > > >> In article , > >> Chris Angelico wrote: > >> > >>> Some things are more standardized than others. A piano keyboard is > >>> incredibly standard, to make it possible to play without having to look > >>> at your fingers (even when jumping your hands around, which doesn't > >>> happen as much on a computer keyboard) > >> > >> Speaking of which, here's a trivia question. Without looking at your > >> keyboard, describe how the "F" and "J" keys (assuming a US-English key > >> layout) differ from, say, the "G" and "K" keys. > > > > The F and J keys have "F" and "J" printed on them instead of "G" and "K". > > They're also in slightly different positions, offset one position to the > > left. Otherwise they are identical, to the limits of my vision and touch. > > (I haven't tried measuring them with a micrometer, or doing chemical > > analysis of the material they are made of.) > > > Maybe keyboards are different where you are! :-) > > Mine have an little ridge on the keytop of those keys. Yup. Long before the days of computers, the F/J keys have had some sort of tactile feedback (a raised dot or whatever) so you can tell when you hands are in the home position by feel. Pyjrteodr upi vsm rmf i[ yu[omh ;olr yjod/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
On 12/05/2014 00:51, Steven D'Aprano wrote: Cars are standardized -- there are basically two types, manuals and automatics. Sadly they can still go wrong due to modern engineering practices. In my neck of the woods some years ago people were killed when standing at a bus stop, because the car driver was desperately pressing down on the automatic's brake but EMI overrode the engine controls and the car simply went faster. At least that is what the defence claimed at the trial. With no expert on the prosecution to refute the claim "not guilty" was the verdict. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
On Mon, 12 May 2014 00:51:01 +0100, MRAB wrote: > On 2014-05-12 00:15, Steven D'Aprano wrote: >> On Sun, 11 May 2014 14:43:19 -0400, Roy Smith wrote: >>> Speaking of which, here's a trivia question. Without looking at your >>> keyboard, describe how the "F" and "J" keys (assuming a US-English key >>> layout) differ from, say, the "G" and "K" keys. >> >> The F and J keys have "F" and "J" printed on them instead of "G" and >> "K". They're also in slightly different positions, offset one position >> to the left. Otherwise they are identical, to the limits of my vision >> and touch. (I haven't tried measuring them with a micrometer, or doing >> chemical analysis of the material they are made of.) >> > Maybe keyboards are different where you are! :-) Certainly not. However they may be different where *you* are :-P I'm using an IBM keyboard, model SK-8820. > Mine have an little ridge on the keytop of those keys. I've seen keyboards with those, but not many. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.
On Mon, May 12, 2014 at 6:31 AM, Terry Reedy wrote: > Please do not advise people to unnecessarily downgrade to 2.7 ;-). > Simon just needs the proper current version of BeautifulSoup. > BeautifulSoup3 does not work with 3.x. > BeautifulSoup4 works with 2.6+ and 3.x. > http://www.crummy.com/software/BeautifulSoup/ > Installation (of the latest version on PyPI) is trivial with 3.4: Oh, I'm glad of that! But without digging into the details of BS, all I could say for sure was that setup.py was expecting 2.x. :) Sticking with 3.4 and upgrading to BS4 is a much better solution. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
On Mon, 12 May 2014 01:27:17 +0100, Mark Lawrence wrote: > On 12/05/2014 00:51, Steven D'Aprano wrote: >> >> Cars are standardized -- there are basically two types, manuals and >> automatics. >> >> > Sadly they can still go wrong due to modern engineering practices. In > my neck of the woods some years ago people were killed when standing at > a bus stop, because the car driver was desperately pressing down on the > automatic's brake Perhaps (s)he should have steered the car away from the people. Or I suppose the steering wheel failed as well? > but EMI overrode the engine controls EMI? The record company? Wow, I knew they were evil, but I didn't realise they were *that* evil. > and the car > simply went faster. At least that is what the defence claimed at the > trial. With no expert on the prosecution to refute the claim "not > guilty" was the verdict. Sounds like the prosecution were just going through the motions. They should have either had an expert able to refute the claim, or not prosecuted in the first place. Personally, I'm rather skeptical about claims of "I kept pushing the brake but the car just accelerated". There is a long and inglorious history of people stepping on the wrong pedal when in a panic, or drunk, or distracted. I've even done it myself. (I expect *every* driver has, at some point.) And a not-quite-as-long but even more inglorious history of lawyers inventing nonsense links between the brake pedal and the accelerator in order to extort money from car manufacturers. E.g. see "Galileo's Revenge" by Peter W Huber and the case of the mythical, but amazingly profitable for the lawyers involved, Audi Sudden Acceleration Syndrome. For me personally, perhaps the most despicable part of the whole sordid story was the case of Wende Gatts, who ran over Darlene Norris, causing $300,000 in damages. Not only did she got off scot-free, thanks to the junk science invented by her "expert witness", but actual victim Norris was ordered to pay Gatts' legal fees of $64K. Of course, that was in the late 1980s, when even luxury cars still had mechanical linkage between the user and the brakes. These days, when nearly everything in the car is computer controlled, I wouldn't be *quite* so skeptical. Nevertheless, chances are almost certain that by far the majority of unexpected acceleration cases are PEBCAP errors. http://www.caranddriver.com/features/its-all-your-fault-the-dot-renders-its-verdict-on-toyotas-unintended-acceleration-scare-feature http://www.caranddriver.com/news/toyota-recall-scandal-media-circus-and-stupid-drivers-editorial -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: How do I access 'Beautiful Soup' on python 2.7 or 3.4 , console or idle versions.
On Saturday, May 10, 2014 10:28:18 PM UTC+5:30, Simon Evans wrote: > I am new to Python, but my main interest is to use it to Webscrape. I guess you've moved on from this specific problem. However here is some general advice: To use beautiful soup you need to use python. To use python you need to know python. Some people spend months on that, or weeks or days. Maybe you are clever and can reduce that to hours but not further :-) So start with this https://docs.python.org/2/tutorial/ or https://docs.python.org/3.4/tutorial/ [depending on which python you need] It may take a bit longer; but you will suffer less. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran
On 05/11/2014 09:11 PM, Steven D'Aprano wrote: On Mon, 12 May 2014 00:51:01 +0100, MRAB wrote: Certainly not. However they may be different where *you* are :-P I'm using an IBM keyboard, model SK-8820. Mine have an little ridge on the keytop of those keys. I've seen keyboards with those, but not many. My experience has been the exact opposite. Except for very cheap keyboards, I believe the standard marks have been on F and J on every keyboard I've encountered (USA) in the past 30 years. They certainly are on my two Thinkpads, two Toshibas, a Dell, and an IOGear keyboard. They're also on the 5 key of the keypads for a credit card machine and remotes from Sony and Samsung. Not all Sony's, though; some are defective. I had a close friend who is blind and deaf, and counted on those marks to touch type. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On 05/11/2014 02:54 PM, Mark H Harris wrote: >julia> sin(BigFloat(π/4)) > 7.0710678118654750275194295621751674626154323953749278952436611913748 > 20215180412e-01 with 256 bits of precision That answer doesn't seem to come anywhere near 256 bits of precision. Using Python 3.2, >>> x=70710678118654750275194295621751674626154323953749278952436611913748 >>> x*x 4999693838300213161705693483516931249926767981110058185818806614907837502621065882204197129973479350206261627418690991407504 Not that this is surprising, but it does make a terrible ad for how great Julia is. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On 5/11/14 10:10 PM, Dave Angel wrote: On 05/11/2014 02:54 PM, Mark H Harris wrote: >julia> sin(BigFloat(π/4)) > 7.0710678118654750275194295621751674626154323953749278952436611913748 > 20215180412e-01 with 256 bits of precision That answer doesn't seem to come anywhere near 256 bits of precision. Using Python 3.2, >>> x=70710678118654750275194295621751674626154323953749278952436611913748 >>> x*x 4999693838300213161705693483516931249926767981110058185818806614907837502621065882204197129973479350206261627418690991407504 Not that this is surprising, but it does make a terrible ad for how great Julia is. Dave, you get the golden egg! I expected D'Aprano to catch it first! Yes, BigFloat does the same dumb thing Python's Decimal does. π/4 is not a BigFloat, and BigFloat simply makes the 16 digit float into a 256 bit float, the sin of which will only be 16 digits accurate (more or less). It has nothing to do with the language (Python vs. Julia) it has to do with the way the BigFloat is formed. So let's fix it by forming the π constant as a BigFloat constant: >julia> n = BigFloat(1) >1e+00 with 256 bits of precision >julia> π = atan(n/5)*16 - atan(n/239)*4 >3.141592653589793238462643383279502884197169399375105820974944592307816406286198e+00 >with 256 bits of precision >julia> S = sin(π/4) >7.07106781186547524400844362104849039284835937688474036588339868995366239231051e-01 >with 256 bits of precision >julia> S * S >4.57e-01 >with 256 bits of precision Not too bad... marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: parsing multiple root element XML into text
On Friday, May 9, 2014 4:02:42 PM UTC+7, Chris Angelico wrote: > On Fri, May 9, 2014 at 6:59 PM, Percy Tambunan > wrote: > > > Hai, I would like to parse this multiple root element XML > > > > Easy fix might be to wrap it in and , which will give > > you a new root. Would that help? > > > > ChrisA Thanks chris for the idea. Any suggestion to make it print like this: create enumdnsched 4.1.0.1.4.7.3.4.3.2.6.e164.arpa -set naptrFlags=nu create enumdnsched 5.1.0.1.4.7.3.4.3.2.6.e164.arpa -set naptrFlags=nu -- https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On 5/11/14 11:10 PM, Mark H Harris wrote:
On 5/11/14 10:10 PM, Dave Angel wrote:
On 05/11/2014 02:54 PM, Mark H Harris wrote:
>julia> sin(BigFloat(π/4))
> 7.0710678118654750275194295621751674626154323953749278952436611913748
> 20215180412e-01 with 256 bits of precision
That answer doesn't seem to come anywhere near 256 bits of precision.
Using Python 3.2,
>>>
x=70710678118654750275194295621751674626154323953749278952436611913748
>>> x*x
4999693838300213161705693483516931249926767981110058185818806614907837502621065882204197129973479350206261627418690991407504
Not that this is surprising, but it does make a terrible ad for how
great Julia is.
Dave, you get the golden egg! I expected D'Aprano to catch it first!
Yes, BigFloat does the same dumb thing Python's Decimal does. π/4 is
not a BigFloat, and BigFloat simply makes the 16 digit float into a 256
bit float, the sin of which will only be 16 digits accurate (more or less).
It has nothing to do with the language (Python vs. Julia) it has to do
with the way the BigFloat is formed. So let's fix it by forming the π
constant as a BigFloat constant:
>julia> n = BigFloat(1)
>1e+00 with 256 bits of precision
>julia> π = atan(n/5)*16 - atan(n/239)*4
>3.141592653589793238462643383279502884197169399375105820974944592307816406286198e+00
>with 256 bits of precision
>julia> S = sin(π/4)
>7.07106781186547524400844362104849039284835937688474036588339868995366239231051e-01
>with 256 bits of precision
>julia> S * S
>4.57e-01
>with 256 bits of precision
Having said that, the accuracy was not my point; in the first place. My
point is that the sin() function is built-in, takes standard floats (32
bit, 64 bit, 128 bit) and BigFloats of arbitrary precision (and does
something meaningful with it). Let's take a look at Python Deciaml:
>>> === RESTART ===
>>> from decimal import * (first I have to import)
>>> from math import * (than I have to import again)
>>> π
Traceback (most recent call last):
File "", line 1, in
π
NameError: name 'π' is not defined (whoops, don't know π )
>>> π=4*atan(1) (let's create it)
>>> sin(Decimal(π/4))
0.7071067811865475 (whoops sin doesn't do Decimals)
>>> from pdeclib import sin (let's get a sin that does do Decimals)
>>> sin(Decimal(π/4))
Decimal('0.707106781186547502751942956217516746261543')
>>> S=sin(Decimal(π/4)) (Whoops has the same problem as BigFloat)
>>> S**2
Decimal('0.499969383830021316170569348351')
>>>
Now let's fix it:
>>>
>>> from pdeclib import d
>>> n=d(1)
>>> from pdeclib import *
>>> n=d(1)
>>> π=atan(n/5)*16 - atan(n/239)*4
>>> S=sin(π/4)
>>> S**2
> Decimal('0.50')
>>>
Also not bad, but slower.;-)
marcus
--
https://mail.python.org/mailman/listinfo/python-list
Re: Fortran (Was: The "does Python have variables?" debate)
On Mon, May 12, 2014 at 2:26 PM, Mark H Harris wrote: > Having said that, the accuracy was not my point; in the first place. My > point is that the sin() function is built-in... So what? Built-in just means that there's no namespacing of mathematical functions. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Using threads for audio computing?
Le 11/05/14 17:40, lgabiot a écrit : I guess if my calculation had to be performed on a small number of samples (i.e. under the value of the Pyaudio buffer size (2048 samples for instance), and that the calculation would last less than the time it takes to get the next 2048 samples from Pyaudio, I wouldn't need the Queue and Thread system. But in my case where I need a large buffer, it might not work? Unless I ask pyaudio to feed me directly with 5 seconds chunks (instead of the usual buffer sizes: 1024, 2048, etc...), which I didn't try, because I hadn't though of it. I guess this solution might probably not work, since it would mean that the calculation should be quick enough so it wouldn't last longer than 1 sample (1/48000 s for instance), since while doing the calculation, no audio would be ingested (unless pyAudio possess some kind of internal concurrency system). Which leads me to think that a buffer (queue) and separate threads (producer and consumer) are necessary for this task. But AFAIK the python GIL (and in smaller or older computers that have only one core) does not permit true paralell execution of two threads. I believe it is quite like the way multiple processes are handled by an OS on a single CPU computer: process A has x CPU cycles, then process B has y CPU cycles, etc... So in my case, I must have a way to make sure that: thread 1 (which gets audio from Pyaudio and put() it in the Queue) is not interrupted long enough to miss a sample. If I suppose a worst case scenario for the computer, like a raspberry-pi, the CPU speed is 700MHz, which gives approx 14 000 CPU cycles between each audio samples (at 48 kHz FS). I don't know if 14 000 CPU cycle is a lot or not for the tasks at hands. Well, at least, it is what I understand, but since I'm really both a beginner and an hobbyist, I might be totally wrong... -- https://mail.python.org/mailman/listinfo/python-list
Re: Using threads for audio computing?
On Mon, May 12, 2014 at 3:33 PM, lgabiot wrote: > But AFAIK the python GIL (and in smaller or older computers that have only > one core) does not permit true paralell execution of two threads. I believe > it is quite like the way multiple processes are handled by an OS on a single > CPU computer: process A has x CPU cycles, then process B has y CPU cycles, > etc... > So in my case, I must have a way to make sure that: > thread 1 (which gets audio from Pyaudio and put() it in the Queue) is not > interrupted long enough to miss a sample. > If I suppose a worst case scenario for the computer, like a raspberry-pi, > the CPU speed is 700MHz, which gives approx 14 000 CPU cycles between each > audio samples (at 48 kHz FS). I don't know if 14 000 CPU cycle is a lot or > not for the tasks at hands. > > Well, at least, it is what I understand, but since I'm really both a > beginner and an hobbyist, I might be totally wrong... The GIL is almost completely insignificant here. One of your threads will be blocked practically the whole time (waiting for more samples; collecting them into a numpy array doesn't take long), and the other is, if I understand correctly, spending most of its time inside numpy, which releases the GIL. You should be able to thread just fine. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Using threads for audio computing?
Le 12/05/14 07:41, Chris Angelico a écrit : The GIL is almost completely insignificant here. One of your threads will be blocked practically the whole time (waiting for more samples; collecting them into a numpy array doesn't take long), and the other is, if I understand correctly, spending most of its time inside numpy, which releases the GIL. You should be able to thread just fine. ChrisA Thanks Chris for your answer. So back to my original question: A Queue and two threads (producer/consumer) seems a good answer to my problem, or is there a better way to solve it? (again, I'm really a beginner, so I made up this solution, but really wonder if I do not miss a well known obvious much better idea). -- https://mail.python.org/mailman/listinfo/python-list
Re: Using threads for audio computing?
On Mon, May 12, 2014 at 3:54 PM, lgabiot wrote: > So back to my original question: A Queue and two threads (producer/consumer) > seems a good answer to my problem, or is there a better way to solve it? > (again, I'm really a beginner, so I made up this solution, but really wonder > if I do not miss a well known obvious much better idea). Well, the first thing I'd try is simply asking for more data when you're ready for it - can you get five seconds' of data all at once? Obviously this won't work if your upstream buffers only a small amount, in which case your thread is there to do that buffering; also, if you can't absolutely *guarantee* that you can process the data quickly enough, every time, then you need to use the queue to buffer that. But otherwise, it sounds like a quite reasonable way to do things. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Using threads for audio computing?
Le 12/05/14 07:58, Chris Angelico a écrit : Well, the first thing I'd try is simply asking for more data when you're ready for it - can you get five seconds' of data all at once? Obviously this won't work if your upstream buffers only a small amount, in which case your thread is there to do that buffering; also, if you can't absolutely *guarantee* that you can process the data quickly enough, every time, then you need to use the queue to buffer that. But otherwise, it sounds like a quite reasonable way to do things. ChrisA Ok, thanks a lot! -- https://mail.python.org/mailman/listinfo/python-list
Re: Using threads for audio computing?
lgabiot, 12.05.2014 07:33: > Le 11/05/14 17:40, lgabiot a écrit : > >> I guess if my calculation had to be performed on a small number of >> samples (i.e. under the value of the Pyaudio buffer size (2048 samples >> for instance), and that the calculation would last less than the time it >> takes to get the next 2048 samples from Pyaudio, I wouldn't need the >> Queue and Thread system. >> But in my case where I need a large buffer, it might not work? >> Unless I ask pyaudio to feed me directly with 5 seconds chunks (instead >> of the usual buffer sizes: 1024, 2048, etc...), which I didn't try, >> because I hadn't though of it. > > I guess this solution might probably not work, since it would mean that the > calculation should be quick enough so it wouldn't last longer than 1 sample > (1/48000 s for instance), since while doing the calculation, no audio would > be ingested (unless pyAudio possess some kind of internal concurrency system). > Which leads me to think that a buffer (queue) and separate threads > (producer and consumer) are necessary for this task. This sounds like a use case for double buffering. Use two buffers, start filling one. When it's full, switch buffers, start filling the second and process the first. When the second is full, switch again. Note that you have to make sure that the processing always terminates within the time it takes to fill the other buffer. If you can't assure that, however, you have a problem anyway and should see if there's a way to improve your algorithm. If the "fill my buffer" call in PyAudio is blocking (i.e. if it returns only after filling the buffer), then you definitely need two threads for this. > But AFAIK the python GIL (and in smaller or older computers that have only > one core) does not permit true paralell execution of two threads. Not for code that runs in the *interpreter", but it certainly allows I/O and low-level NumPy array processing to happen in parallel, as they do not need the interpreter. Stefan -- https://mail.python.org/mailman/listinfo/python-list
