numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] Re: numpy.sin

[Rob H. <ro...@ho...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Kern wrote:
| Alan G Isaac wrote:
|
|>I am a user, not a numerics type,
|>so this is undoubtedly a naive question.
|>
|>Might the sin function be written to give greater
|>accuracy for large real numbers?  It seems that significant
|>digits are in some sense being discarded needlessly.
|
|
| Not really. The floating point representation of pi is not exact. The
problem
| only gets worse when you multiply it with something. The method you
showed of
| using % (2*pi) is only accurate when the values are created by
multiplying the
| same pi by another value. Otherwise, it just introduces another source
of error,
| I think.
|
| This is one of the few places where a version of trig functions that
directly
| operate on degrees are preferred. 360.0*n is exactly representable by
floating
| point arithmetic until n~=12509998964918 (give or take a power of
two). Doing %
| 360 can be done exactly.

This reminds me of a story Richard Feynman tells in his autobiography.
He used to say: "if you can pose a mathematical question in 10 seconds,
I can solve it with 10% accuracy in one minute just calculating in my
head". This worked for a long time, until someone told him "please
calculate the sine of a million".

Actual mantissa bits are used by the multiple of two-pi, and those are
lost at the back of the calculated value. Calculating the sine of a
million with the same precision as the sine of zero requires 20 more
bits of accuracy.

Rob
- --
Rob W.W. Hooft  ||  ro...@ho...  ||  http://www.hooft.net/people/rob/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEdfziH7J/Cv8rb3QRAiO8AKCQdJ+9EMOP6bOmUX0NIhuWVoEFQgCgmvTS
fgO08dI16AUFcYKkpRJXg/Q=
=qQXI
-----END PGP SIGNATURE-----

Re: [Numpy-discussion] Re: numpy.sin

[Alan G I. <ai...@am...>]

On Thu, 25 May 2006, Robert Kern apparently wrote:=20
> The method you showed of using % (2*pi) is only accurate=20
> when the values are created by multiplying the same pi by=20
> another value. Otherwise, it just introduces another=20
> source of error, I think.

Just to be clear, I meant not (!) to presumptuosly propose=20
a method for improving thigs, but just to illustrate the=20
issue: both the loss of accuracy, and the obvious conceptual=20
point that there is (in an abstract sense, at least) no need=20
for sin(x) and sin(x+ 2*pi) to differ.

Thanks,
Alan

[Numpy-discussion] Re: numpy.sin

[Robert K. <rob...@gm...>]

Alan G Isaac wrote:
> I am a user, not a numerics type,
> so this is undoubtedly a naive question.
> 
> Might the sin function be written to give greater
> accuracy for large real numbers?  It seems that significant  
> digits are in some sense being discarded needlessly.

Not really. The floating point representation of pi is not exact. The problem
only gets worse when you multiply it with something. The method you showed of
using % (2*pi) is only accurate when the values are created by multiplying the
same pi by another value. Otherwise, it just introduces another source of error,
I think.

This is one of the few places where a version of trig functions that directly
operate on degrees are preferred. 360.0*n is exactly representable by floating
point arithmetic until n~=12509998964918 (give or take a power of two). Doing %
360 can be done exactly.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

[Numpy-discussion] numpy.sin

[Alan G I. <ai...@am...>]

I am a user, not a numerics type,
so this is undoubtedly a naive question.

Might the sin function be written to give greater
accuracy for large real numbers?  It seems that significant  
digits are in some sense being discarded needlessly.
I.e., compare these:

>>> sin(linspace(0,10*pi,11))
array([  0.00000000e+00,   1.22460635e-16,  -2.44921271e-16,
         3.67381906e-16,  -4.89842542e-16,   6.12303177e-16,
        -7.34763812e-16,   8.57224448e-16,  -9.79685083e-16,
         1.10214572e-15,  -1.22460635e-15])
>>> sin(linspace(0,10*pi,11)%(2*pi))
array([  0.00000000e+00,   1.22460635e-16,   0.00000000e+00,
         1.22460635e-16,   0.00000000e+00,   1.22460635e-16,
         0.00000000e+00,   1.22460635e-16,   0.00000000e+00,
         1.22460635e-16,   0.00000000e+00])

Just wondering.

Cheers,
Alan Isaac

[Numpy-discussion] Numpy 0.9.8 fails under Mac OS X

[Rudolph v. d. M. <rud...@gm...>]

I built and installed Numpy 0.9.8 successfully from the source using

  python setup.py build
  sudo python setup.py install

When I run the unit-test though, it fails with the following error:

[~] python
ActivePython 2.4.3 Build 11 (ActiveState Software Inc.) based on
Python 2.4.3 (#1, Apr  3 2006, 18:07:18)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.__version__
'0.9.8'
>>> numpy.test(1,1)
  Found 5 tests for numpy.distutils.misc_util
  Found 3 tests for numpy.lib.getlimits
  Found 30 tests for numpy.core.numerictypes
  Found 13 tests for numpy.core.umath
  Found 1 tests for numpy.core.scalarmath
  Found 8 tests for numpy.lib.arraysetops
  Found 42 tests for numpy.lib.type_check
  Found 95 tests for numpy.core.multiarray
  Found 3 tests for numpy.dft.helper
  Found 36 tests for numpy.core.ma
  Found 9 tests for numpy.lib.twodim_base
  Found 2 tests for numpy.core.oldnumeric
  Found 9 tests for numpy.core.defmatrix
  Found 1 tests for numpy.lib.ufunclike
  Found 35 tests for numpy.lib.function_base
  Found 1 tests for numpy.lib.polynomial
  Found 6 tests for numpy.core.records
  Found 19 tests for numpy.core.numeric
  Found 4 tests for numpy.lib.index_tricks
  Found 46 tests for numpy.lib.shape_base
  Found 0 tests for __main__
...................................................python(9463)
malloc: ***  Deallocation of a pointer not malloced: 0xd668; This
could be a double free(), or free() called with the middle of an
allocated block; Try setting environment variable MallocHelp to see
tools to help debug
python(9463) malloc: ***  Deallocation of a pointer not malloced:
0xd4e8; This could be a double free(), or free() called with the
middle of an allocated block; Try setting environment variable
MallocHelp to see tools to help debug
python(9463) malloc: ***  Deallocation of a pointer not malloced:
0xd650; This could be a double free(), or free() called with the
middle of an allocated block; Try setting environment variable
MallocHelp to see tools to help debug
python(9463) malloc: ***  Deallocation of a pointer not malloced:
0xd560; This could be a double free(), or free() called with the
middle of an allocated block; Try setting environment variable
MallocHelp to see tools to help debug
python(9463) malloc: ***  Deallocation of a pointer not malloced:
0xd4a0; This could be a double free(), or free() called with the
middle of an allocated block; Try setting environment variable
MallocHelp to see tools to help debug
python(9463) malloc: ***  Deallocation of a pointer not malloced:
0xd3f8; This could be a double free(), or free() called with the
middle of an allocated block; Try setting environment variable
MallocHelp to see tools to help debug
python(9463) malloc: ***  Deallocation of a pointer not malloced:
0xd470; This could be a double free(), or free() called with the
middle of an allocated block; Try setting environment variable
MallocHelp to see tools to help debug
python(9463) malloc: ***  Deallocation of a pointer not malloced:
0xd320; This could be a double free(), or free() called with the
middle of an allocated block; Try setting environment variable
MallocHelp to see tools to help debug
python(9463) malloc: ***  Deallocation of a pointer not malloced:
0xd728; This could be a double free(), or free() called with the
middle of an allocated block; Try setting environment variable
MallocHelp to see tools to help debug
python(9463) malloc: ***  Deallocation of a pointer not malloced:
0xd440; This could be a double free(), or free() called with the
middle of an allocated block; Try setting environment variable
MallocHelp to see tools to help debug
python(9463) malloc: ***  Deallocation of a pointer not malloced:
0xd410; This could be a double free(), or free() called with the
middle of an allocated block; Try setting environment variable
MallocHelp to see tools to help debug
python(9463) malloc: ***  Deallocation of a pointer not malloced:
0xd590; This could be a double free(), or free() called with the
middle of an allocated block; Try setting environment variable
MallocHelp to see tools to help debug
python(9463) malloc: ***  Deallocation of a pointer not malloced:
0xd458; This could be a double free(), or free() called with the
middle of an allocated block; Try setting environment variable
MallocHelp to see tools to help debug
F..........................................................................=
...........................................................................=
...........................................................................=
...........................................................................=
.................
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FAIL: check_types (numpy.core.tests.test_scalarmath.test_types)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/sit=
e-packages/numpy/core/tests/test_scalarmath.py",
line 63, in check_types
    assert val.dtype.num =3D=3D typeconv[k,l] and \
AssertionError: error with (13,14)

----------------------------------------------------------------------
Ran 368 tests in 1.517s

FAILED (failures=3D1)
<unittest.TextTestRunner object at 0x1052910>



Any idea what is causing this?

Thanks
Rudolph


--=20
Rudolph van der Merwe

Re: [Numpy-discussion] numpy-0.9.5 build is not clean

[Krishna M. G. <gk...@gm...>]

Dear Andrew,

Thanks for your reply. As I said earlier I deleted the existing numpy
installation and the build directories. I am more than confidant that
I did it right. Is there anyway I can prove myself wrong?

I also tried importing umath.so from build directory
===
$ cd numpy-0.9.5/build/lib.linux-x86_64-2.4/numpy/core
$ ls -l umath.so
-rwxr-xr-x    1 krishna  users      463541 May 22 17:46 umath.so
$ python
Python 2.4.3 (#1, Apr  8 2006, 19:10:42)
[GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-49)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import umath
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
RuntimeError: module compiled against version 90500 of C-API but this
version of numpy is 90504
>>>
===

So something is wrong with the build for sure. Could there be anything
wrong other than not deleting the build directory?

thanks,
Krishna.

On 5/24/06, Andrew Straw <str...@as...> wrote:
> Dear Krishna, it looks like there are some mixed versions of numpy
> floating around on your system. Before building, remove the "build"
> directory completely.
>
> Krishna Mohan Gundu wrote:
>
> > Hi,
> >
> > I am trying to build numpy-0.9.5, downloaded from sourceforge download
> > page, as higher versions are not yet tested for pygsl. The build seems
> > to be broken. I uninstall existing numpy and start build from scratch
> > but I get the following errors when I import numpy after install.
> >
> > ====
> >
> >>>> from numpy import *
> >>>
> > import core -> failed: module compiled against version 90504 of C-API
> > but this version of numpy is 90500
> > import random -> failed: 'module' object has no attribute 'dtype'
> > import linalg -> failed: module compiled against version 90504 of
> > C-API but this version of numpy is 90500
> > ====
> >
> > Any help is appreciated. Am I doing something wrong or is it known
> > that this build is broken?
> >
> > thanks,
> > Krishna.
> >
> >
> > -------------------------------------------------------
> > All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> > Fully trained technicians. The highest number of Red Hat
> > certifications in
> > the hosting industry. Fanatical Support. Click to learn more
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> > _______________________________________________
> > Numpy-discussion mailing list
> > Num...@li...
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
>

Re: [Numpy-discussion] numpy-0.9.5 build is not clean

[Andrew S. <str...@as...>]

Dear Krishna, it looks like there are some mixed versions of numpy
floating around on your system. Before building, remove the "build"
directory completely.

Krishna Mohan Gundu wrote:

> Hi,
>
> I am trying to build numpy-0.9.5, downloaded from sourceforge download
> page, as higher versions are not yet tested for pygsl. The build seems
> to be broken. I uninstall existing numpy and start build from scratch
> but I get the following errors when I import numpy after install.
>
> ====
>
>>>> from numpy import *
>>>
> import core -> failed: module compiled against version 90504 of C-API
> but this version of numpy is 90500
> import random -> failed: 'module' object has no attribute 'dtype'
> import linalg -> failed: module compiled against version 90504 of
> C-API but this version of numpy is 90500
> ====
>
> Any help is appreciated. Am I doing something wrong or is it known
> that this build is broken?
>
> thanks,
> Krishna.
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] Re: need help building on windows

[Robert K. <rob...@gm...>]

Christopher Hanley wrote:
> Hi,
> 
> I am new to working on the Windows XP OS and I am having a problem building numpy from source.  I am attempting to build using the MinGW compilers on a Windows XP box which has Python 2.4.1 installed.  I do not have nor do I intend to use any optimized libraries like ATLAS.  I have checked out numpy revision 2542.  This is as clean a build as you could probably get.  I am attaching my build log to this message.  If anyone has any helpful hints they would be most appreciated.

It's a known issue:

  http://projects.scipy.org/scipy/numpy/ticket/129

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

[Numpy-discussion] need help building on windows

[Christopher H. <ch...@st...>]

Hi,

I am new to working on the Windows XP OS and I am having a problem building numpy from source.  I am attempting to build using the MinGW compilers on a Windows XP box which has Python 2.4.1 installed.  I do not have nor do I intend to use any optimized libraries like ATLAS.  I have checked out numpy revision 2542.  This is as clean a build as you could probably get.  I am attaching my build log to this message.  If anyone has any helpful hints they would be most appreciated.

Thanks,
Chris

[Numpy-discussion] numpy-0.9.5 build is not clean

[Krishna M. G. <gk...@gm...>]

Hi,

I am trying to build numpy-0.9.5, downloaded from sourceforge download
page, as higher versions are not yet tested for pygsl. The build seems
to be broken. I uninstall existing numpy and start build from scratch
but I get the following errors when I import numpy after install.

====
>>> from numpy import *
import core -> failed: module compiled against version 90504 of C-API
but this version of numpy is 90500
import random -> failed: 'module' object has no attribute 'dtype'
import linalg -> failed: module compiled against version 90504 of
C-API but this version of numpy is 90500
====

Any help is appreciated. Am I doing something wrong or is it known
that this build is broken?

thanks,
Krishna.

Re: [Numpy-discussion] Dot product threading?

[<jor...@bo...>]

This thread discusses one of the things highest on my wishlist for=20
numpy. I have attached my first attempt at a code that will create a=20
broadcastingfunction that will broadcast a function over arrays where=20
the last N indices are assumed to be for use by the function, N=3D2 would=
=20
be used for matrices. It is implemented for Numeric.


/J=F6rgen


Pau Gargallo skrev:
>> Pau, can you confirm that this is the same
>> as the routine you're interested in?
>>
>> def dot2(a,b):
>>     '''Returns dot product of last two dimensions of two 3-D arrays,
>>     threaded over first dimension.'''
>>     try:
>>         assert a.shape[1] =3D=3D b.shape[2]
>>         assert a.shape[0] =3D=3D b.shape[0]
>>     except AssertionError:
>>         print "incorrect input shapes"
>>     res =3D zeros( (a.shape[0], a.shape[1], a.shape[1]), dtype=3Dfloat=
 )
>>     for i in range(a.shape[0]):
>>         res[i,...] =3D dot( a[i,...], b[i,...] )
>>     return res
>>
>=20
> yes, that is what I would like. I would like it even with more
> dimensions and with all the broadcasting rules ;-)
> These can probably be achieved by building actual 'arrays of matrices'
> (an array of matrix objects) and then using the ufunc machinery.
> But I think that a simple dot2 function (with an other name of course)
> will still very useful.
>=20
> pau
>=20
>=20
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, securit=
y?
> Get stuff done quickly with pre-integrated technology to make your job=20
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron=
imo
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=120709&bid&3057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>=20

Re: [Numpy-discussion] error numpy 0.9.8

[Pujo A. <aj...@gm...>]

Thanks,
It works.

pujo

On 5/24/06, Stephan Tolksdorf <st...@si...> wrote:
>
> The current release accidentally depends on the win32all package:
> sourceforge.net/projects/pywin32/
>
> This should be fixed in the latest SVN version.
>
> Stephan
>

Re: [Numpy-discussion] error numpy 0.9.8

[Stephan T. <st...@si...>]

The current release accidentally depends on the win32all package:
sourceforge.net/projects/pywin32/

This should be fixed in the latest SVN version.

Stephan

[Numpy-discussion] error numpy 0.9.8

[Pujo A. <aj...@gm...>]

Hello,

I have problem importing numpy 0.9.8:
While writing:
>>> import numpy

I 've got this error message:
import testing -> failed: No module named win32pdh


This is not happened in 0.9.6

Can anybody help me?

Thanks,
pujo

[Numpy-discussion] fwd: ANN: PyX 0.9 released

[Arnd B. <arn...@we...>]

Hi,

some of you might have heard about PyX, http://pyx.sourceforge.net/
which """is a Python package for the creation of PostScript and PDF files.
It combines an abstraction of the PostScript drawing model with a TeX/LaTeX
interface.

Features

    * PostScript and PDF output for device independent, free scalable
      figures
    * seamless TeX/LaTeX integration
    * full access to PostScript features like paths, linestyles, fill
      patterns, transformations, clipping, bitmap inclusion, etc.
    * advanced geometric operations on paths like intersections,
      transformations, splitting, smoothing, etc.
    * sophisticated graph generation: modular design, pluggable axes, axes
      partitioning based on rational number arithmetics, flexible graph
      styles, etc.
"""

Below is the release announcement for PyX 0.9.

Best, Arnd

P.S. To simplify the plotting of numpy arrays (1D and 2D) with
     PyX you could have a look at pyxgraph,
       http://www.physik.tu-dresden.de/~baecker/python/pyxgraph.html
     (which is still under heavy development ...;-)



---------- Forwarded message ----------
Date: Wed, 24 May 2006 15:23:22 +0200
From: Andre Wobst <wo...@us...>
To: PyX-user <pyx...@li...>,
     PyX-devel <pyx...@li...>
Subject: [PyX-user] ANN: PyX 0.9 released

Hi!

We're proud to announce the release of PyX 0.9! After quite some time
we finally managed to prepare a new major release. Many improvements
and fixes are included (see the attached list of changes), but there
are a couple of highlights which should be mentioned separately: This
release adds a set of deformers to PyX for path manipulations like
smoothing, shifting, etc. A new set of extensively documented examples
describing various aspects of PyX in a cookbook-like fashion have been
written. Type 1 font-stripping is now handled by a newly written
Python module. The evaluation of functions for graph plotting is now
left to Python. Thereby some obscure data manipulation could be
removed from the bar style for handling of nested bar graphs.
Transparency is now supported for PDF output.

Let me try to summarize some of the *visible* changes (to existing
code out there) we needed to apply to facilitate some of the major
goals of this release:

  - The path system has passed another restructuring phase. The
    normpath, which allows for all the advanced path features of PyX,
    have been moved into a separate module normpath. The
    parametrization of the paths (i.e. of the normpaths) is now
    handled by normpathparam instances allowing for mixing arc lengths
    and normpathparam instances in any order in many path functions
    like split etc. The normpathparam instances allow the addition of
    arc lengths to walk along a path, for example starting at the end
    of a path or at an intersection point.

  - The evaluation of mathematical expressions in the classes from the
    graph.data module is now left to Python. While this leads to a
    huge set of other improvements (like being not restricted to the
    floats datatype anymore), there are no differences between the
    evaluation of the expression compared to Python anymore. As Python
    by default still uses integer division for integer arguments, the
    meaning of a function expression like "1/2" has changed
    dramatically. In earlier versions of PyX for this example the
    value 0.5 was calculated, now it becomes 0. (I'm looking forward
    to Python 3000 to get rid of this situation once and for all! :-))

  - Bars graphs on a list of data sets, which in earlier versions have
    been automatically converted to use a nested bar axis, don't do
    that automatic conversion anymore. You may want to look at the
    example http://pyx.sourceforge.net/examples/bargraphs/compare.html
    to learn more about the new and more flexible solution.

  - The stroke styles linestyle and dash now use the rellength feature
    by default. Furthermore the rellength feature was adjusted to not
    modify the dash lengths for the default linewidth. Hence you're
    affected by this change when you have used the rellength feature
    before or you used linestyles on linewidths different from the
    default.

  - The bbox calcuation was modified in two respects: First it now
    properly takes into account the shape of bezier boxes (so the real
    bounding box is now used instead of the control box). Secondly PyX
    now takes into account the linewidths when stroking a path and
    adds it to the bounding box.


Happy PyXing ...

J=F6rg, Michael, and Andr=E9


------------------

0.9 (2006/05/24):
  - most important changes (to be included in the release notes):
    - mathtree removal (warning about integer division)
    - barpos style does not build tuples for nestedbar axes automatically
    - new deformers for path manipulation (for smoothing, shifting, ... pat=
hs)
  - font modules:
    - new framework for font handling
    - own implementation of type1 font stripping (old pdftex code fragments=
 removed)
    - complete type1 font command representation and glyph path extraction =
from font programs
    - t1code extension module (C version of de-/encoding routines used in T=
ype 1 font files)
    - AFM file parser
  - graph modules:
    - data module:
      - mathtree removal: more flexibility due to true python expressions
      - default style instantiation bug (reported by Gregory Novak)
    - style module:
      - automatic subaxis tuple creation removed in barpos (create tuples
        in expressions now; subnames argument removed since it became point=
less;
        adujstaxis became independend from selectstyle for all styles now)
      - remove multiple painting of frompath in histogram and barpos styles
      - fix missing attribute select when using a bar style once only (repo=
rted by Alan Isaac)
      - fix histograms for negative y-coordinates (reported by Dominic Ford=
, bug #1492548)
      - fix histogram to stroke lines to the baseline for steps=3D0 when tw=
o subsequent values are equal
      - add key method for histogram style (reported by Hagemann, bug #1371=
554)
      - implement a changebar style
    - graph, axis and style module:
      - support for mutual linking of axes between graphs
      - new domethods dependency handling
      - separate axis range calculation from dolayout
    - axis.parter module:
      - linear and logarthmic partitioners always need lists now
        (as it was documented all the time; renamed tickdist/labeldist
        to tickdists/labeldists; renamed tickpos/labelpos to
        tickpreexps/labelpreexps)
    - axis module:
      - patch to tickpos and vtickpos (reported by Wojciech Smigaj, cf. pat=
ch #1286112)
      - anchoredpathaxis added (suggested by Wojciech Smigaj)
      - properly handle range rating on inversed axis (reported by Dominic =
Ford, cf. bug #1461513)
      - invalidate axis partitions with a single label only by the distance=
 rater
      - fallback (with warning) to linear partitioner on a small logarithmi=
cs scale
    - painter module:
      - patch to allow for tickattrs=3DNone (reported by Wojciech Smigaj, c=
f. patch #1286116)
  - color module:
    - transparency support (PDF only)
    - conversion between colorspaces
    - nonlinear palettes added
    - the former palette must now be initialized as linearpalette
    - remove min and max arguments of palettes
  - text module:
    - improve escapestring to handle all ascii characters
    - correct vshift when text size is modified by a text.size instance
    - recover from exceptions (reported by Alan Isaac)
    - handle missing italic angle information in tfm for pdf output (report=
ed by Brett Calcott)
    - allow for .def and .fd files in texmessage.loaddef (new name for
      texmessage.loadfd, which was restricted to .fd files)
  - path module:
    - correct closepath (do not invalidate currentpoint but set it to the
      beginning of the current subpath); structural rework of pathitems
    - calculate real bboxes for Bezier curves
    - fix intersection due to non-linear parametrization of bezier curves
    - add rotate methods to path, normpath, normsubpath, and normsubpathite=
ms
    - add flushskippedline to normsubpath
    - add arclentoparam to normsubpath and normsubpathitems
    - path is no longer a canvasitem
    - reduce number of parameters of outputPS/outputPDF methods (do not pas=
s context and registry)
  - normpath module:
    - contains normpath, normsubpath and normpathparam which have originall=
y
      been in the path module
    - return "invalid" for certain path operations when the curve "speed" i=
s
      below a certain threshold
    - normpath is no longer a canvasitem
    - reduce number of parameters of outputPS/outputPDF methods (do not pas=
s context and registry)
  - deformer module:
    - rewritten smoothed to make use of the subnormpath facilities
    - rewritten parallel for arbitrary paths
  - deco module:
    - add basic text decorator
    - allow arrows at arbitrary positions along the path
  - connector module:
    - boxdists parameter need to be a list/tuple of two items now
    - changed the orientation of the angle parameters
  - trafo module:
    - renamed _apply to apply_pt
    - introduce _epsilon for checking the singularity of a trafo
  - epsfile module:
    - use rectclip instead of clip to remove the clipping path from the
      PostScript stack, which otherwise might create strange effects for
      certain PostScript files (reported by Gert Ingold)
  - dvifile module:
    - silently ignore TrueType fonts in font mapping files (reported by Gab=
riel Vasseur)
  - type1font module:
    - accept [ and ] as separators in encoding files (reported by Mojca Mik=
lavec, cf. bug #1429524)
  - canvas module:
    - remove registerPS/registerPDF in favour of registering resourcing dur=
ing the outputPS/outputPDF run
    - move bbox handling to registry
    - rename outputPS/outputPDF -> processPS/processPDF
    - remove set method of canvas
    - add a pipeGS method to directly pass the PyX output to ghostscript
    - allow file instances as parameter of the writeXXXfile methods (featur=
e request #1419658 by Jason Pratt)
  - document modules:
    - allow file instances as parameter of the writeXXXfile methods (featur=
e request #1419658 by Jason Pratt)
  - style module:
    - make rellength the default for dash styles
  - random notes:
    - switched to subversion on 2006/03/09

--=20
by  _ _      _    Dr. Andr=E9 Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D107521&bid=3D248729&dat=3D1=
21642
_______________________________________________
PyX-user mailing list
PyX...@li...
https://lists.sourceforge.net/lists/listinfo/pyx-user

Re: [Numpy-discussion] win32all dependance

[Pearu P. <pe...@sc...>]

On Wed, 24 May 2006, Ed Schofield wrote:

> Schug, Eric C. wrote:
>>
>> When installing Numpy 0.9.8 then running import scipy I get the
>> following Error
>>
>> import testing -> failed: No module named win32pdh
>>
>>
>>
>> Base on reviewing earlier releases appears to have a dependence on
>> win32all which was removed in
>>
>> numpy-0.9.6r1.win32-py2.4.exe
>>
>> Could this dependence be removed from this latest version?
>>
>
> Doh!  My 0.9.6 rebuild was just a stop-gap measure; I commented out the
> offending lines in numpy/testing/utils.py, but didn't change the trunk.
> I should have communicated this better.  Travis, shall we just remove
> all lines from 67 to 97?

No, the code in these lines is not dead. I'll commit a fix to this 
issue in a moment.

Pearu

Re: [Numpy-discussion] win32all dependance

[Ed S. <sch...@ft...>]

Schug, Eric C. wrote:
>
> When installing Numpy 0.9.8 then running import scipy I get the
> following Error
>
> import testing -> failed: No module named win32pdh
>
>  
>
> Base on reviewing earlier releases appears to have a dependence on
> win32all which was removed in
>
> numpy-0.9.6r1.win32-py2.4.exe
>
> Could this dependence be removed from this latest version?
>

Doh!  My 0.9.6 rebuild was just a stop-gap measure; I commented out the
offending lines in numpy/testing/utils.py, but didn't change the trunk. 
I should have communicated this better.  Travis, shall we just remove
all lines from 67 to 97?

-- Ed

[Numpy-discussion] Fail in building numpy(svn).

[Wenjie H. <laz...@gm...>]

SSBqdXN0IGZvbGxvdyB0aGUgdHV0b3JpYWwgaW4KaHR0cDovL3d3dy5zY2lweS5vcmcvSW5zdGFs
bGluZ19TY2lQeS9XaW5kb3dzIHRvIGJ1aWxkIG51bXB5IHN0ZXAgYnkKc3RlcCwgYW5kIGV2ZXJ5
dGhpbmcgaXMgT0sgZXhjZXB0IGJ1aWxkaW5nIG51bXB5LgoKSSB1c2UgY3lnd2luIHdpdGggZ2Nj
IHRvIGNvbXBpbGUgdGhlbSBhbGwsIGFuZCB1c2UgcHJlLWNvbXBpbGVyCnB5dGhvbi0yLjQgaW4g
d2luZG93cyB4cCBzcDIuCkkgdHJ5IGJ1aWxkIGluIGJvdGggd2luZG93cyBuYXRpdmUgY29tbWFu
ZCBsaW5lIGFuZCBjeWd3aW4gd2l0aDoKcHl0aG9uLmV4ZSBzZXR1cC5weSBjb25maWcgLS1jb21w
aWxlcj1taW5ndzMyIGJ1aWxkIC0tY29tcGlsZXI9bWluZ3czMgpiZGlzdF93aW5pbnN0CkFuZCB0
aGUgcmVzdWx0IGlzIHRoZSBzYW1lIHdpdGggdGhlIGVycm9yIHdoaWNoIGlzIGF0dGFjaGVkIGJl
bG93LgoKSXQgaXMgbXkgZmlyc3QgdGltZSB0byBidWlsZCBhIHB5dGhvbiBtb2R1bGUsIGFuZCBJ
IGRvbid0IGtub3cgd2hlcmUKdG8gc3RhcnQgdG8gZml4IHRoZSBlcnJvci4KQ2FuIGFueW9uZSBz
aG93IG1lIHRoZSB3YXksIHBsej8KCldlbmppZQotLSAKSSdtIGxhenksIEknbSBjb2RpbmcuCmh0
dHA6Ly9teS5kb25ld3MuY29tL2hlbm90aWkK

[Numpy-discussion] win32all dependance

[Schug, E. C. <ERI...@sa...>]

When installing Numpy 0.9.8 then running import scipy I get the following
Error

import testing -> failed: No module named win32pdh

 

Base on reviewing earlier releases appears to have a dependence on win32all
which was removed in

numpy-0.9.6r1.win32-py2.4.exe

Could this dependence be removed from this latest version?

Thanks

 

 

Eric Schug

 

 

Re: [Numpy-discussion] Numpy PR

[Christopher B. <Chr...@no...>]

Rob Hooft wrote:
> I created a link from my own bookmark page, which is reasonably ranked
> in google.... ;-) If we all link to scipy.org somewhere useful, it will
> be raised in googles ranking automatically, and completely legitimately.

ideally, put your link in so that users click on "numpy" to get there, 
that has a large impact on Google (see google bombing, or google 
"failure" for an explanation)

like this:
   <a href="http://www.scipy.org">numpy</a>

However, I"m not sure that the scipy site should be the first one people 
find. I vote for creating a good the home page for the sourceforge site 
at www.numpy.org. Travis' page at numeric.scipy.org would be a good start.

-Chris










-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Numpy-discussion] Numpy PR

[John H. <jdh...@ac...>]

>>>>> "Rob" == Rob Hooft <ro...@ho...> writes:

    Rob> Jonathan Taylor wrote: | I updated the python moin pages.

    Rob> I created a link from my own bookmark page, which is
    Rob> reasonably ranked in google.... ;-) If we all link to
    Rob> scipy.org somewhere useful, it will be raised in googles
    Rob> ranking automatically, and completely legitimately.

A very good (legitimate) way to raise your google page rank is to post
announcements to python-announce and python-list with the keywords you
want google to match on in the subject heading.  Mix these up between
announces to cover the space

  ANN: scipy.xxx: scientific tools for python
  ANN: scipy.xyz: python algorithms and array methods

etc.....  These will be magnified across the net through RSS and
mirrors, much faster than a few people making links on their
homepages.  Also, include the keywords you want google to match in the
title field of the scipy.org html.  The title is now simply scipy.org
and making it something like "scientific tools for python" will help.

JDH

Re: [Numpy-discussion] Numpy PR

[Rob H. <ro...@ho...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jonathan Taylor wrote:
| I updated the python moin pages.

I created a link from my own bookmark page, which is reasonably ranked
in google.... ;-) If we all link to scipy.org somewhere useful, it will
be raised in googles ranking automatically, and completely legitimately.

Rob

- --
Rob W.W. Hooft  ||  ro...@ho...  ||  http://www.hooft.net/people/rob/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEc1mNH7J/Cv8rb3QRAocsAJ9cYiAy211XLBzTO7LEEhvW+3AxkgCdGdYt
Cu//sOM1WzC68YKeFAZMlG0=
=hZy8
-----END PGP SIGNATURE-----

Re: [Numpy-discussion] Numpy PR

[Jonathan T. <jon...@ut...>]

I updated the python moin pages.

On 5/23/06, jo...@st... <jo...@st...> wrote:
> Hi,
>
> I was thinking about our PR for numpy. Imo, the best page that we can
> currently show to newcomers is www.scipy.org. There they find out what is
> Numpy, where you can download it, documentation, cookbook recipes, exampl=
es,
> libraries that build on NumPy like SciPy, etc. In addition, it's the page
> that, imho, looks the most professional.
>
>
> Googling for "numpy" gives:
>
> 1) numeric.scipy.org/
>
> Travis' webpage on Numpy. Travis, would you consider putting a much more
> pronounced link to scipy.org? The current link to is at the very bottom o=
f
> the page and has no further comments...
>
> 2) www.numpy.org/
>
> One is redirected to the sourceforge site. Question: why not to the scipy=
.org
> site? The reason why no wiki page is set up here is, I guess, because the=
re
> is already one at scipy.org. So why not directly linking to it?
>
>
> 3) www.pfdubois.com/numpy/
>
> This site is actually closed. It only contains a short paragraph pointing=
 to
> the page http://sourceforge.net/projects/numpy.
>
>
> 4) www.pfdubois.com/numpy/html2/numpy.html
>
> This is a potentially very confusing web page. It constantly talks about
> 'Numpy' but is actually refering to the obsolete 'Numeric'. Perhaps this =
page
> could be taken down?
>
>
> 5) sourceforge.net/projects/numpy
>
> The download site for NumPy. This page doesn't contain a link to scipy.or=
g.
>
>
> 6) www.python.org/moin/NumericAndScientificnumpy.html
>
> Informationless webpage.
>
>
> 7) wiki.python.org/moin/NumericAndScientific
>
> Up-to-date webpage, but refers to numeric.scipy.org for NumPy.
>
>
> 8) www.scipy.org/
>
> And YES, finally... :o)
>
>
> Perhaps we could try to take scipy.org a bit higher in the Google ranking=
?
> I am not a HTML expert at all, but may a header in the www.scipy.org sour=
ce
> code like
>
> <meta name=3D"keywords" content=3D"numpy scipy">
>
> help?
>
> Cheers,
> Joris
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] Numpy PR

[Paul D. <pfd...@gm...>]

I killed pfdubois/numpy.

On 23 May 2006 07:18:32 -0700, jo...@st... <
jo...@st...> wrote:
>
> Hi,
>
> I was thinking about our PR for numpy. Imo, the best page that we can
> currently show to newcomers is www.scipy.org. There they find out what is
> Numpy, where you can download it, documentation, cookbook recipes,
> examples,
> libraries that build on NumPy like SciPy, etc. In addition, it's the page
> that, imho, looks the most professional.
>
>
> Googling for "numpy" gives:
>
> 1) numeric.scipy.org/
>
> Travis' webpage on Numpy. Travis, would you consider putting a much more
> pronounced link to scipy.org? The current link to is at the very bottom o=
f
> the page and has no further comments...
>
> 2) www.numpy.org/
>
> One is redirected to the sourceforge site. Question: why not to the
> scipy.org
> site? The reason why no wiki page is set up here is, I guess, because
> there
> is already one at scipy.org. So why not directly linking to it?
>
>
> 3) www.pfdubois.com/numpy/
>
> This site is actually closed. It only contains a short paragraph pointing
> to
> the page http://sourceforge.net/projects/numpy.
>
>
> 4) www.pfdubois.com/numpy/html2/numpy.html
>
> This is a potentially very confusing web page. It constantly talks about
> 'Numpy' but is actually refering to the obsolete 'Numeric'. Perhaps this
> page
> could be taken down?
>
>
> 5) sourceforge.net/projects/numpy
>
> The download site for NumPy. This page doesn't contain a link to scipy.or=
g
> .
>
>
> 6) www.python.org/moin/NumericAndScientificnumpy.html
>
> Informationless webpage.
>
>
> 7) wiki.python.org/moin/NumericAndScientific
>
> Up-to-date webpage, but refers to numeric.scipy.org for NumPy.
>
>
> 8) www.scipy.org/
>
> And YES, finally... :o)
>
>
> Perhaps we could try to take scipy.org a bit higher in the Google ranking=
?
> I am not a HTML expert at all, but may a header in the www.scipy.orgsourc=
e
> code like
>
> <meta name=3D"keywords" content=3D"numpy scipy">
>
> help?
>
> Cheers,
> Joris
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>

[Numpy-discussion] Numpy PR

[<jo...@st...>]

Hi,

I was thinking about our PR for numpy. Imo, the best page that we can
currently show to newcomers is www.scipy.org. There they find out what is
Numpy, where you can download it, documentation, cookbook recipes, examples,
libraries that build on NumPy like SciPy, etc. In addition, it's the page
that, imho, looks the most professional.


Googling for "numpy" gives:

1) numeric.scipy.org/ 

Travis' webpage on Numpy. Travis, would you consider putting a much more
pronounced link to scipy.org? The current link to is at the very bottom of 
the page and has no further comments...

2) www.numpy.org/

One is redirected to the sourceforge site. Question: why not to the scipy.org
site? The reason why no wiki page is set up here is, I guess, because there
is already one at scipy.org. So why not directly linking to it?


3) www.pfdubois.com/numpy/

This site is actually closed. It only contains a short paragraph pointing to
the page http://sourceforge.net/projects/numpy.


4) www.pfdubois.com/numpy/html2/numpy.html

This is a potentially very confusing web page. It constantly talks about
'Numpy' but is actually refering to the obsolete 'Numeric'. Perhaps this page
could be taken down?


5) sourceforge.net/projects/numpy

The download site for NumPy. This page doesn't contain a link to scipy.org.


6) www.python.org/moin/NumericAndScientificnumpy.html

Informationless webpage.


7) wiki.python.org/moin/NumericAndScientific

Up-to-date webpage, but refers to numeric.scipy.org for NumPy.


8) www.scipy.org/

And YES, finally... :o)


Perhaps we could try to take scipy.org a bit higher in the Google ranking? 
I am not a HTML expert at all, but may a header in the www.scipy.org source
code like

<meta name="keywords" content="numpy scipy">

help?

Cheers,
Joris


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm