On 09/12/2013 20:46, Dave Angel wrote:
On Mon, 09 Dec 2013 15:54:36 +, Robin Becker wrote:
On 06/12/2013 22:07, Joel Goldstick wrote:
> end, start = start, end
a similar behaviour for simple assignments
for less than 4 variables the tuple method is faster.
What does speed have
> Actually for optimised code it looks very similar to some code posted
>
> here
>
> http://www.daniweb.com/software-development/python/threads/321181/python-bresenham-circle-arc-algorithm
>
>
> over three years ago.
>
This is where it origins from. I just extended it for my needs and now
On 06/12/2013 08:47, Robert Voigtländer wrote:
Hi,
I try to squeeze out some performance of the code pasted on the link below.
http://pastebin.com/gMnqprST
The code will be used to continuously analyze sonar sensor data. I set this up
to calculate all coordinates in a sonar cone without heavy
On Mon, 09 Dec 2013 15:54:36 +, Robin Becker
wrote:
On 06/12/2013 22:07, Joel Goldstick wrote:
> end, start = start, end
a similar behaviour for simple assignments
for less than 4 variables the tuple method is faster.
What does speed have to do with it? When you want to swap tw
On 06/12/2013 22:07, Joel Goldstick wrote:
..
Not that this will speed up your code but you have this:
if not clockwise:
s = start
start = end
end = s
Python people would write:
end, start = start, end
this works for some small number of variabl
On 09/12/2013 14:19, Robert Voigtländer wrote:
Am Samstag, 7. Dezember 2013 00:01:49 UTC+1 schrieb Dan Stromberg:
On Fri, Dec 6, 2013 at 2:38 PM, Mark Lawrence wrote:
On 06/12/2013 16:52, John Ladasky wrote:
On Friday, December 6, 2013 12:47:54 AM UTC-8, Robert Voigtländer wrote:
I try
Am Samstag, 7. Dezember 2013 00:01:49 UTC+1 schrieb Dan Stromberg:
> On Fri, Dec 6, 2013 at 2:38 PM, Mark Lawrence wrote:
>
>
> On 06/12/2013 16:52, John Ladasky wrote:
>
>
> On Friday, December 6, 2013 12:47:54 AM UTC-8, Robert Voigtländer wrote:
>
>
>
>
> I try to squeeze out some perfor
On Fri, Dec 6, 2013 at 2:38 PM, Mark Lawrence wrote:
> On 06/12/2013 16:52, John Ladasky wrote:
>
>> On Friday, December 6, 2013 12:47:54 AM UTC-8, Robert Voigtländer wrote:
>>
>> I try to squeeze out some performance of the code pasted on the link
>>> below.
>>> http://pastebin.com/gMnqprST
>>>
On 06/12/2013 16:52, John Ladasky wrote:
On Friday, December 6, 2013 12:47:54 AM UTC-8, Robert Voigtländer wrote:
I try to squeeze out some performance of the code pasted on the link below.
http://pastebin.com/gMnqprST
Several comments:
1) I find this program to be very difficult to read, la
On Fri, Dec 6, 2013 at 11:52 AM, John Ladasky wrote:
> On Friday, December 6, 2013 12:47:54 AM UTC-8, Robert Voigtländer wrote:
>
> > I try to squeeze out some performance of the code pasted on the link
> below.
> > http://pastebin.com/gMnqprST
>
Not that this will speed up your code but you have
On Friday, December 6, 2013 12:47:54 AM UTC-8, Robert Voigtländer wrote:
> I try to squeeze out some performance of the code pasted on the link below.
> http://pastebin.com/gMnqprST
Several comments:
1) I find this program to be very difficult to read, largely because there's a
whole LOT of du
Am Freitag, 6. Dezember 2013 17:36:03 UTC+1 schrieb Mark Lawrence:
> > I already did some basic profiling and optimized a lot. Especially > with
> > help of a goof python performance tips list I found.
>
> Wonderful typo -^ :)
>
Oh well :-) ... it was a good one. Just had a quick look at
On 06/12/2013 16:29, Robert Voigtländer wrote:
Thanks for your replies.
I already did some basic profiling and optimized a lot. Especially > with help
of a goof python performance tips list I found.
Wonderful typo -^ :)
I think I'll follow the cython path.
The geometry approach also s
Thanks for your replies.
I already did some basic profiling and optimized a lot. Especially with help of
a goof python performance tips list I found.
I think I'll follow the cython path.
The geometry approach also sound good. But it's way above my math/geometry
knowledge.
Thanks for your input
On Fri, Dec 6, 2013 at 8:46 PM, Jeremy Sanders wrote:
> This sort of code is probably harder to make faster in pure python. You
> could try profiling it to see where the hot spots are. Perhaps the choice of
> arrays or sets might have some speed impact.
I'd make this recommendation MUCH stronger.
Robert Voigtländer wrote:
> I try to squeeze out some performance of the code pasted on the link
> below. http://pastebin.com/gMnqprST
>
> The code will be used to continuously analyze sonar sensor data. I set
> this up to calculate all coordinates in a sonar cone without heavy use of
> trigonome
16 matches
Mail list logo
