Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #66492 > unrolled thread

Re: inheriting a large python code base

Started byCameron Simpson <cs@zip.com.au>
First post2014-02-16 09:32 +1100
Last post2014-02-17 00:26 +1100
Articles 5 — 5 participants

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: inheriting a large python code base Cameron Simpson <cs@zip.com.au> - 2014-02-16 09:32 +1100
    Re: inheriting a large python code base Roy Smith <roy@panix.com> - 2014-02-15 18:15 -0500
      Re: inheriting a large python code base Rustom Mody <rustompmody@gmail.com> - 2014-02-15 19:06 -0800
        Re: inheriting a large python code base Rita <rmorgan466@gmail.com> - 2014-02-16 07:59 -0500
        Re: inheriting a large python code base Chris Angelico <rosuav@gmail.com> - 2014-02-17 00:26 +1100

#66492 — Re: inheriting a large python code base

FromCameron Simpson <cs@zip.com.au>
Date2014-02-16 09:32 +1100
SubjectRe: inheriting a large python code base
Message-ID<mailman.7028.1392505094.18130.python-list@python.org>
On 15Feb2014 12:10, Rita <rmorgan466@gmail.com> wrote:
> i just inherited a large python code base and I would like to optimize the
> code (run faster). The application is a scientific application so I really
> don't understand the internal logic.
[...]

One thing I would keep in mind is that scientific applications
generally involve floating point math. That is subject to loss of
precision if done the wrong way.

If you are fiddling with a numeric algorithm (as opposed to plain
old data structure manipulations) I would want to be sure the code
you're changing is not done that way for a specific reason. Make
unit tests to check for correctness if possible. Make regression
tests to compare the results of your modified code against the
results from the original code on the same data.

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

Plague, Famine, Pestilence, and C++ stalk the land. We're doomed! Doomed!
        - Simon E Spero

[toc] | [next] | [standalone]


#66495

FromRoy Smith <roy@panix.com>
Date2014-02-15 18:15 -0500
Message-ID<roy-F1B3DF.18150315022014@news.panix.com>
In reply to#66492
In article <mailman.7028.1392505094.18130.python-list@python.org>,
 Cameron Simpson <cs@zip.com.au> wrote:

> On 15Feb2014 12:10, Rita <rmorgan466@gmail.com> wrote:
> > i just inherited a large python code base and I would like to optimize the
> > code (run faster). The application is a scientific application so I really
> > don't understand the internal logic.
> [...]
> 
> One thing I would keep in mind is that scientific applications
> generally involve floating point math. That is subject to loss of
> precision if done the wrong way.

Another thing to keep in mind is that scientific applications are often 
written by {physicists, chemists, astronomers, etc} who have no clue 
about how floating point math, or indeed much of anything about 
computers, works :-)

[toc] | [prev] | [next] | [standalone]


#66504

FromRustom Mody <rustompmody@gmail.com>
Date2014-02-15 19:06 -0800
Message-ID<ff79ffd3-7d39-4a55-95c3-ddada5ee4955@googlegroups.com>
In reply to#66495
On Sunday, February 16, 2014 4:45:04 AM UTC+5:30, Roy Smith wrote:
> In article Cameron Simpson  wrote:

> > On 15Feb2014 12:10, Rita wrote:
> > > i just inherited a large python code base and I would like to optimize the
> > > code (run faster). The application is a scientific application so I really
> > > don't understand the internal logic.
> > [...]
> > One thing I would keep in mind is that scientific applications
> > generally involve floating point math. That is subject to loss of
> > precision if done the wrong way.

> Another thing to keep in mind is that scientific applications are often 
> written by {physicists, chemists, astronomers, etc} who have no clue 
> about how floating point math, or indeed much of anything about 
> computers, works :-)

Not exactly my experience.
Most of the {physicists, chemists, astronomers, etc}s I know grok
floating point better than Ive been able to do in 30 years.
They dont get much else though! -- Usually called 'Fortran programmers'.

The guy who taught me numerical analysis -- a brilliant chemist -- could
never understand why anyone should want to use anything other than Fortran.
And it was a self-evident God's truth that a variable starting with
I-N was integer Rest real.
Declarations??  Pshaw! Sissy stuff!
"I *IS* an integer and no hanky-panky about it"

[toc] | [prev] | [next] | [standalone]


#66530

FromRita <rmorgan466@gmail.com>
Date2014-02-16 07:59 -0500
Message-ID<mailman.7051.1392555592.18130.python-list@python.org>
In reply to#66504

[Multipart message — attachments visible in raw view] — view raw

when I do profiling is it possible to find out if I am spending a lot of
time in type conversion?
it seems I am not. Also, is it possible to predeclare a type in python?
Similar to C: int i=0;




On Sat, Feb 15, 2014 at 10:06 PM, Rustom Mody <rustompmody@gmail.com> wrote:

> On Sunday, February 16, 2014 4:45:04 AM UTC+5:30, Roy Smith wrote:
> > In article Cameron Simpson  wrote:
>
> > > On 15Feb2014 12:10, Rita wrote:
> > > > i just inherited a large python code base and I would like to
> optimize the
> > > > code (run faster). The application is a scientific application so I
> really
> > > > don't understand the internal logic.
> > > [...]
> > > One thing I would keep in mind is that scientific applications
> > > generally involve floating point math. That is subject to loss of
> > > precision if done the wrong way.
>
> > Another thing to keep in mind is that scientific applications are often
> > written by {physicists, chemists, astronomers, etc} who have no clue
> > about how floating point math, or indeed much of anything about
> > computers, works :-)
>
> Not exactly my experience.
> Most of the {physicists, chemists, astronomers, etc}s I know grok
> floating point better than Ive been able to do in 30 years.
> They dont get much else though! -- Usually called 'Fortran programmers'.
>
> The guy who taught me numerical analysis -- a brilliant chemist -- could
> never understand why anyone should want to use anything other than Fortran.
> And it was a self-evident God's truth that a variable starting with
> I-N was integer Rest real.
> Declarations??  Pshaw! Sissy stuff!
> "I *IS* an integer and no hanky-panky about it"
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
--- Get your facts first, then you can distort them as you please.--

[toc] | [prev] | [next] | [standalone]


#66533

FromChris Angelico <rosuav@gmail.com>
Date2014-02-17 00:26 +1100
Message-ID<mailman.7054.1392557224.18130.python-list@python.org>
In reply to#66504
On Sun, Feb 16, 2014 at 11:59 PM, Rita <rmorgan466@gmail.com> wrote:
> when I do profiling is it possible to find out if I am spending a lot of
> time in type conversion?
> it seems I am not.

I would guess that you don't. But in Python, type conversion is like
any other function call:

value = int("12345")

So you can test for it the same way you would any other.

> Also, is it possible to predeclare a type in python?
> Similar to C: int i=0;
>

No, because in Python, variables/names don't have types - only
objects/values do. You can simply initialize i to 0, in the obvious
way:

i = 0

And if you never put anything but an integer into i, it'll always be
an integer. That's about as close as you'll get to an "integer
variable" like C has. (Python's idea of an integer is rather better
than C's, of course; C's 'int' type is a machine word, so it can't
store values greater than 2**32 or 2**64 or whatever the limit is, but
Python's int can store any integer you have RAM enough to store.)

ChrisA

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web