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 t
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
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 mis
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
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:
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,
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.or
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
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?
>
>
>
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 p
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=7071
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 thos
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
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
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/softwa
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
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
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 p
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-Be
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 ca
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 (eve
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
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 Sou
- 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
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
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 c
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,
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
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 g
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 an
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!"
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:-
-
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:-
--
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
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 cons
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 or
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
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(ata
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 num
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)
Speaki
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 happe
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 importa
On 05/11/2014 10:51 AM, Roy Smith wrote:
In article <871tw0s2kl@elektro.pacujo.net>,
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 g
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.
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
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 l
In article <871tw0s2kl@elektro.pacujo.net>,
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 sci
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. It
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
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 succe
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/
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 n
Le 11/05/14 16:40, Roy Smith a écrit :
In article <536f869c$0$2178$426a7...@news.free.fr>,
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.
Bu
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
In article <536f869c$0$2178$426a7...@news.free.fr>,
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
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 (
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
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. Neithe
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**
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 v
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
>
On 11/05/2014 08:45, subhabangal...@gmail.com 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
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
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 retur
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
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.
> >
> > [.
On Sunday, May 11, 2014 11:50:32 AM UTC+5:30, subhaba...@gmail.com wrote:
> On Sunday, May 11, 2014 12:57:34 AM UTC+5:30, subhaba...@gmail.com wrote:
>
> > Dear Room,
>
> >
>
> >
>
> >
>
> > I was trying to go through a code given in
> > http://en.wikipedia.org/wiki/Forward%E2%80%93backwar
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.
>>
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:
>
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 t
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 sma
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 dynami
72 matches
Mail list logo
