Re: [Tutor] Fwd: Re: SciPy Optimize-like calling function as string

[Alan Gauld via Tutor]

On 25/02/17 17:24, Alan Gauld via Tutor wrote:

>> If you don't know that you need to optimize then your
>> time is usually better spent elsewhere. Dictionaries
>> are pretty fast in Python and I'd suggest you try
>> that first before shaving milliseconds in places
>> that may not be where you need to make savings.
> 
> Honestly, that method makes no sense to me whatsoever. 

Sorry, what I meant is: try the simpler dictionary
based technique first. Dictionaries are what Python
uses internally for almost everything so they
are very fast. Only if you know you need to improve
on their performance should you try using other
techniques (and that's an extremely rare scenario).

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] Fwd: Re: SciPy Optimize-like calling function as string

[Alan Gauld via Tutor]

Forwarding to list.

Please always use reply-All or Reply-list when responding to the list.

On Feb 18, 2017, at 6:21 PM, Alan Gauld via Tutor > wrote:
>
> On 18/02/17 21:52, Joseph Slater wrote:
>> I'm trying to use the scipy.optimize code ...
>> I've seen this done with dictionaries on some pages,
>> but it seems that this is intended to be faster
>
> There is a saying in programming that premature
> optimization is the root of all evil.

This is true, but I'm conceding that I don't need the solution so much
as I'm trying to polish my Python. In fact, there is no problem I'm
solving today. This is mostly a training exercise. I'd like to be as
"pythonic" as possible in the long run.

>
> If you don't know that you need to optimize then your
> time is usually better spent elsewhere. Dictionaries
> are pretty fast in Python and I'd suggest you try
> that first before shaving milliseconds in places
> that may not be where you need to make savings.

Honestly, that method makes no sense to me whatsoever. 

>
> Identify an actual problem, then identify the cause
> and optimise that. Don't try to second guess the future.
> Most performance problems are down to bad algorithms
> or bad data structures not bad dispatch techniques.

(I will go Google "dispatch techniques"). 

I'm trying to overcome 20 years of "Matlab" programming to modernize.
I've fallen way out of touch and taken this up as a hobby that may also
be professionally helpful from time to time. 

Sorry for the delay. I really do appreciate the responses. It's my hobby
versus my day job now. My students get all the fun of actually
programing these days!


Professor & Chair

(+1) 937-775-5040
https://people.wright.edu/joseph.slater

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor