headers
Pete Shinners | 2 Oct 2000 19:57
Favicon
Gravatar

quick optimization

i've got a quick optimization for the arrayobject.c source.
it speeds my usage of numpy up by about 100%. i've tested with
other numpy apps and noticed a minimum of about 20% speed.

anyways, in "do_sliced_copy", change out the following block:

    if (src_nd == 0 && dest_nd == 0) {
        for(j=0; j<copies; j++) {
            memcpy(dest, src, elsize);
            dest += elsize;
        }
        return 0;
    }

with this slightly larger one:

    if (src_nd == 0 && dest_nd == 0) {
        switch(elsize) {
        case sizeof(char):
            memset(dest, *src, copies);
            break;
        case sizeof(short):
            for(j=copies; j; --j, dest += sizeof(short))
                *(short*)dest = *(short*)src;
            break;
        case sizeof(long):
            for(j=copies; j; --j, dest += sizeof(int))
                *(int*)dest = *(int*)src;
            break;
        case sizeof(double):
(Continue reading)

Permalink | Reply | 2 comments |
headers
Emmanuel Viennet | 3 Oct 2000 07:42
Picon
Favicon

Re: quick optimization

 Oups, you're right...
In most (all ?) systems, memcpy() is a true function,
and is *not* inlined. 
Jim was coding in the C++ way: trusting the optimizer !

Thank you,
Emmanuel
Permalink | Reply | 0 comments |
headers
Paul F. Dubois | 9 Oct 2000 21:50
Picon

[ANNOUNCE] Ninth International Python Conference

CALL FOR PAPERS, POSTERS, AND PARTICIPATION
Ninth International Python Conference
March 5-8, 2001
Long Beach, California
Web site: http://python9.org

The 9th International Python Conference (Python 9) is a forum for Python
users, software developers, and researchers to present current work, discuss
future plans for the language and commercial applications, and learn about
interesting uses of Python. The conference will consist of a day of
tutorials, two days of refereed paper and application tracks including a
Zope track and a multi-technology Python Applications Track, a developers'
day, a small exhibition, demonstrations, and posters.

Paper submission deadline: Monday, November 6, 2000
Notification of acceptance: Monday, December 11, 2000
Final papers due: Monday, January 15, 2001

Authors are invited to submit papers for the Refereed Paper Track that:

* Present new and useful applications and tools that utilize Python
* Describe the use of Python in large, mission-critical or unusual
applications
* Address practical programming problems, and provide lessons based on
experience for Python programmers
Also sought are poster presentations of interesting work in progress.

Full information is available on the website, http://python9.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pearu Peterson | 10 Oct 2000 19:42
Picon
Picon
Favicon

ANNOUNCE: PySymbolic - Doing Symbolics in Python

Hi!

I have started a project

  PySymbolic  - "Doing Symbolics in Python"

PySymbolic is a collection of tools for doing elementary symbolic
calculations in Python. The project is in alpha stage.

Current features include basic simplifications:
      *** removing redundant parenthesis: (a) -> a
      *** applying factorization: -(a) -> -a, +a -> a, ~(a) -> ~a
      *** collecting terms: n*a+b+m*a -> k*a+b (where k=n+m)
      *** collecting powers: a**c*b/a**d -> a**(c-d)*b
      *** cancellations: 0*a -> 0, a+0 -> 0, 
                         a**0 -> 1, 1*a -> a, a**1 -> a
      *** rational arithmetic: 3/4+2/6-1 -> 1/12 
      *** opening parenthesis: (a+b)*c -> a*c+b*c
      *** expanding integer powers: (a+b)**n -> a**n+a**(n-1)*b+...
      *** sorting terms in alphabethic order: a+c+b -> a+b+c
      *** (more to come)

Projects homepage is
    http://cens.ioc.ee/projects/pysymbolic/

You can download the source from
    http://cens.ioc.ee/projects/pysymbolic/PySymbolic.tgz

Regards,
	Pearu
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fred Yankowski | 10 Oct 2000 21:16
Favicon

version.py vs numeric_version.py

I couldn't seem to download a prebuilt distribution of NumPy from
SourceForge earlier today, so I connected via CVS and grabbed the
latest code.  I was eventually able to build and install it OK, but I
had to copy Lib/version.py to Lib/numeric_version.py since the latter
didn't exist but other code refers to it.  Just a "heads up"...

--

-- 
Fred Yankowski           fred <at> OntoSys.com      tel: +1.630.879.1312
Principal Consultant     www.OntoSys.com       fax: +1.630.879.1370
OntoSys, Inc             38W242 Deerpath Rd, Batavia, IL 60510, USA
Permalink | Reply | 0 comments |
headers
Paul F. Dubois | 11 Oct 2000 14:53
Picon

Re: numpy, overflow, inf, ieee, and rich comparison

About controlling floating-point behavior with Numpy: I think that somewhere
buried in the sources Lee Busby had us all set if we would just go through
the source and stick in some macro in the right places (this was maybe 3
years ago, hence the accurate and detailed memory dump) but it was on the
todo list so long it outlived the death of the todo list.

Anyway, my recollection is if we ever did it then we would have control when
things like overflow happen. But we haven't. My last experience of this sort
of thing was that it was completely a hardware-dependent thing, and you had
to find out from each manufacturer what their routine was and how to call it
or what compiler flag to use.

Well, sorry to be so imprecise but I thought it worth mentioning that some
steps had been taken even if I don't remember what they were.
Permalink | Reply | 0 comments |
headers
L. Busby | 11 Oct 2000 20:01

Re: Re: numpy, overflow, inf, ieee, and rich comparison

It was an optional module (fpectl) that got added into Python 1.5.
Looks like it has been carried forward pretty much unchanged into the
2.0 release candidate.  To use the facility, you need to build python
with --with-fpectl, then identify "dangerous" (likely to generate
SIGFPE) operations, and surround them with a pair of macros
PyFPE_START_PROTECT and PyFPE_END_PROTECT.  This has the effect of
turning any SIGFPE into a Python exception.  Start with
Include/pyfpe.h, look for example usage in Objects/floatobject.c.  Grep
the python source for FPE_ to find the several places where these hooks
are located.

[ Paul Dubois wrote ]
>About controlling floating-point behavior with Numpy: I think that somewhere
>buried in the sources Lee Busby had us all set if we would just go through
>the source and stick in some macro in the right places (this was maybe 3
>years ago, hence the accurate and detailed memory dump) but it was on the
>todo list so long it outlived the death of the todo list.
>
>Anyway, my recollection is if we ever did it then we would have control when
>things like overflow happen. But we haven't. My last experience of this sort
>of thing was that it was completely a hardware-dependent thing, and you had
>to find out from each manufacturer what their routine was and how to call it
>or what compiler flag to use.
>
>Well, sorry to be so imprecise but I thought it worth mentioning that some
>steps had been taken even if I don't remember what they were.
Permalink | Reply | 1 comment |
headers
Huaiyu Zhu | 12 Oct 2000 01:33
Picon
Favicon

RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)

On the issue of whether Python should ignore over/underflow on IEEE-enabled
platforms: 

[Tim Peters]
> That would stop the exception on exp() underflow, which is what you're
> concerned about.  It would also stop exceptions on exp() overflow, and on
> underflow and overflow for all other math functions too.  I doubt Guido will
> ever let Python ignore overflow by default, #ifdef'ed or not.  A semantic
> change that jarring certainly won't happen for 2.0 (which is just a week
> away).

It can be argued that on IEEE enabled systems the proper thing to do for
overflow is simply return Inf.  Raising exception is WRONG.  See below.

[Guido van Rossum]
> Incidentally, math.exp(800) returns inf in 1.5, and raises
> OverflowError in 2.0.  So at least it's consistent.

That is not consistent at all.  Suppose I'm plotting the curve f(x) where
x include some singular points of f.  In the first case the plot works with
some portion of the curve clipped.  In the second case it bombs.  

[Tim Peters] 
> Nothing like that will happen without a PEP first.  I would like to see
> *serious* 754 support myself, but that depends too on many platform experts
> contributing real work (if everyone ran WinTel, I could do it myself
> <wink>).

[Guido van Rossum]
> Bingo!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul F. Dubois | 12 Oct 2000 02:04
Picon

RE: RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)

I don't have time to follow in detail this thread about changed behavior
between versions. These observations are based on working with hundreds of
code authors. I offer them as is.

a. Nobody runs a serious numeric calculation without setting
underflow-to-zero, in the hardware. You can't even afford the cost of
software checks. Unfortunately there is no portable way to do that that I
know of.

b. Some people use Inf but most people want the code to STOP so they can
find out where the INFS started. Otherwise, two hours later you have big
arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to
stop, not put a zero and keep going.
Permalink | Reply | 0 comments |
headers
Guido van Rossum | 12 Oct 2000 03:45
Favicon

Re: [Python-Dev] RE: RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison)

> I don't have time to follow in detail this thread about changed behavior
> between versions. These observations are based on working with hundreds of
> code authors. I offer them as is.
> 
> a. Nobody runs a serious numeric calculation without setting
> underflow-to-zero, in the hardware. You can't even afford the cost of
> software checks. Unfortunately there is no portable way to do that that I
> know of.
> 
> b. Some people use Inf but most people want the code to STOP so they can
> find out where the INFS started. Otherwise, two hours later you have big
> arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to
> stop, not put a zero and keep going.

Thanks, Paul!  This behavior has always been what I wanted Python to
do (even though it's not always what Python did, depending on the
platform) and also what Tim's proposed patch will implement for the
specific case of math.exp() (and other math functions that may
underflow or overflow), on most reasonable platforms.

There are still lots of places where the platform gives Python no
choice of creating NaN and Inf, and because there's no
platform-independent way to test for these, they are hard to avoid in
some cases; but eventually, Tim will find a way to root them out.  And
for people like Huaiyu, who want to see Inf, there will (eventually)
be a way to select this as a run-time option; and ditto for whoever
might want underflow to raise an exception.

--Guido van Rossum (home page: http://www.python.org/~guido/)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane