the resulting functions.
>
> This code grew out of a research project at The Australian National
> University,
> Department of Physics, which involved computing bounds on geodesics in
> relativistic space-time's.
--
|>|\/|<
/-
dules by setting CC to your cross compiler, and
doing 'python build_ext build_py' (Almost; looks like one config test
is done in build_ext).
Hope that helps; patches to make this cleaner are welcome.
--
|>|\/|<
/-
rlier don't build on Intel Macs. g77 (and gcc 3.x)
won't build either, unfortunately.
If you're using MacPorts (previously DarwinPorts), you'll want the gcc42
port. Or, you can grab binaries at http://hpc.sourceforge.net/
--
|>|\/|<
/-----
coerces float32 to float64, and one that
does the reverse (this would be invisible to the user, of course). The same
would handle int32 and int64.
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
---
y, so that the opcodes
always work on contiguous data. The copy can be another opcode. One advantage
of operating on contiguous data is that it's easier to use the processor's
vector instructions, if applicable.
--
|>|\/|<
/-
On Thu, 21 Sep 2006 11:34:42 -0700
Tim Hochberg <[EMAIL PROTECTED]> wrote:
> Tim Hochberg wrote:
> > Robert Kern wrote:
> >
> >> David M. Cooke wrote:
> >>
> >>
> >>> On Wed, Sep 20, 2006 at 03:01:18AM -0500, Robert Kern wro
are in reST format, so the comments should/could be. At some point
I've got to through and add more :-)
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
---
re all the data points), but
are slightly worse than doing two passes. Kahan summation would probably
also be good here too.
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dm
us ways to do
this. I'm not familiar with them, but scipy has packages to handle sparse
matrices. A lot of work happens in this field (those finite-element methods
tend to make sparse matrices).
Note that you could simulate an irregular array (with a maximum size in the
dimen
the C99 standard, I
believe). I don't know what to use on other machines (esp. Windows with MSVC),
although the Boost Interval library looks like a good place to start:
http://boost.cvs.sourceforge.net/boost/boost/boost/numeric/interval/detail/
--
|>|\/|<
/-----
now several others use amd64 boxes too.
--
|>|\/|<
/------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
-
Using Tomc
x.__iadd__(10)
> One could make a whole reverse polish translator out of such operations and
> a few parenthesis. I have in mind some sort of code optimizer.
It wouldn't be anymore efficient than the other way. For a code optimizer,
you'll either have to parse the pyt
d be a source of bugs (at least, it would mean keeping two different
ideas of .sort() in my head).
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
-
erlying numerical library (i.e. numpy)
> goes on the sister site, http://projects.scipy.org/scipy/numpy/
> """
It's a wiki; you can add it yourself :-) (if you're logged in, of
course.)
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.ph
terruptOccurred(void)
{
if (!interrupted)
return 0;
interrupted = 0;
return 1;
}
(where interrupted is a static int).
--
|>|\/|<
/----------\
|David M. Cooke ht
riginal subject:
> a) "absolute" is impractically too much typing and
> b) I just thought some (module-) functions might be "forgotten" to be put
> in as (object-) methods ... !?
Four-line change, so I added a.abs() (three lines for array, one
for MaskedArray).
--
UPTABLE
where NPY_CHECK_SIGINT would do a longjmp().
Or come up with a good (fast) way to run stuff in another process :-)
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL P
> PS: is there any performace hit in using the built-in abs function ?
Shouldn't be: abs(x) looks for the x.__abs__() method (which arrays have).
--
|>|\/|<
/---
defined in this
> function. Appeared to build fine w/o it.
Whoops, missed that one. Fixed in svn.
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
--
e)))
> TypeError: __array_wrap__() takes exactly 3 arguments (2 given)
>
> <
>
> Is this a known problem, and if so, what is the fix?
It looks like the problem is that numpy.core.ma.MaskedArray.__array_map__
expects a "context" argument, but none
ike 1.0.1.
--
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
-
Take Surveys. Earn Cash
ake
sure your email address is in there.
--
|>|\/|<
/------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
ns nobody tried to apply the patch until part of
> it was obsoleted by changes of David M. Cooke to system_info.py. As I
> didn't keep track of David's changes to the build system I asked him for
> advice regarding the integration of my patch, but I never got a reply.
> Seems
ussion on c.l.py a few years ago about trying to come
up with a standard API for graphs. I don't believe they came up with
anything, but that page contains ideas to consider.
--
|>|\/|<
/----------
space clashes with other libraries, we've switched to adding a
unique prefix 'npy_' to types (and NPY_ to #defines). You can either change
your code to use 'npy_intp', or add
#include "numpy/noprefix.h"
to the top.
--
|>|\/|<
/---
see
http://www.python.org/sf/445484). I guess your best alternative would be to
use a numpy scalar object (like double) instead of a Python float for NaN's.
--
|>|\/|<
/--
iginal
branch (again, on the first line so Trac will see it). If applicable, add the
merge to the ticket also.
Merging a bug fix between trunks as soon as possible is a good idea too!
Then it's a relatively simple matter to browse through Trac and see what's
been merged, and what commits f
__ with something that understands version
> numbers.
...and we've already got something for that: distutils.version.LooseVersion
(or StrictVersion).
--
|>|\/|<
/--\
|David M. Cooke http://arb
ases, odd for development
releases, like for Linux kernels? e.g., make 1.1 the dev branch (current
trunk), and make 1.2 the next stable release after 1.0.
Or, make the trunk 1.0.99.
The .99 usually makes it pretty clear that it's the development branch.
--
|>|\/|<
/--
t; FAILED (failures=2)
> Out[2]:
I'm aware of this (http://projects.scipy.org/scipy/numpy/ticket/183). It's a
problem on PPC macs also. Travis thinks it may be a compiler problem. I've
had a look, and can't see anything obvious.
It *could* be that somewhere there's a ty
t; I've never heard that the short names MATLAB uses for some very common
> operations are a liability. So, when a common operation has a short,
> easily-remembered name that is in common usage, why not use it?
>
> That's basically the underlying philosophy. NumPy has too many very
&g
just enough to email the committer (me, in this case).
Or, at least, I don't mind.
[this kind of error sneaking by is b/c we don't have enough test cases :-)]
--
|>|\/|<
/---
; Well, the problem is not really the capital 'C', but rather the
> lack of
> quotation marks...
Guess I've got more work to do to get rid of the typecodes there...
--
|>|\/|<
/------\
|David M. C
f the functions.
I don't know about svn write access (that's not up to me), but we're
perfectly willing to take patches made with 'svn diff', and uploaded
to our bug tracker.
> In general, we found the conversion to numpy quite straightforward
> and would like to thank you a
've fixed it in svn (I think -- I don't have a Windows box to test on).
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
-
uch in favor of .T, but it should be a full .transpose(), not
> > just swap the last two axes. I don't care so much for the others.
>
> +1 for .T == .transpose()
Another +1 from me. If transpose was a shorter word I wouldn't care :-)
--
|>|\/|<
/-
"lib/python2.3/site-packages/numpy/linalg/linalg.py", line 454, in
> lstsq
> bstar[:b.shape[0],:n_rhs] = b.copy()
> TypeError: array cannot be safely cast to required type
That would be a better error.
I'm going to leave it like this for now, though. Instead, the lin
columns do not line up:
>
> matrix([[0, 0],
>[0, 0]])
Fixed in SVN.
--
|>|\/|<
/------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
Using Tomcat but need to d
---
TOTAL8982 376441%
(I filtered out all the *.tests.* modules). Note that you have to import
numpy after starting the coverage, because we use a lot of module-level code
that wouldn't be caught otherwise.
--
|>|\/|<
/----
On Wed, 28 Jun 2006 13:46:07 -0600
"Fernando Perez" <[EMAIL PROTECTED]> wrote:
> On 6/28/06, David M. Cooke <[EMAIL PROTECTED]> wrote:
>
> > [Really, distutils sucks. I think (besides refactoring) it needs it's API
> > documented better, or
t == double
complex == cdouble (also complex128)
Personally, I'd suggest using "single", "float", and "longdouble" in numpy
code.
[While we're on the subject, for portable code don't use float96 or float128:
one or other or both probab
On Wed, 28 Jun 2006 13:18:35 -0600
"Fernando Perez" <[EMAIL PROTECTED]> wrote:
> On 6/28/06, David M. Cooke <[EMAIL PROTECTED]> wrote:
>
> > Done. I've also added a 'setupegg.py' module that wraps running 'setup.py'
> > with
l__
> __doc__ += """
> Contents
>
>
> and scipy's test suite still passes (modulo the test_cobyla thingie
> Nils is currently fixing, which is not related to this).
>
> Should I apply this patch, so we push the cleaned-up API even a bit harder?
up
>
> Tested patches welcome.
Done. I've also added a 'setupegg.py' module that wraps running 'setup.py'
with an import of setuptools (it's based on the one used in matplotlib).
easy_install still works, also.
--
|>|\/|<
/-
for LAPACK that Debian uses; the maintainer, Camm
Maguire, has done a bunch of work adding patches to fix routines that have
been floating around. For instance, eigenvalues works better than before (lot
fewer segfaults).
With this, the hard part is writing the wrapper routines. If someone wants t
ric :-) It hasn't been
touched much.
--
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
Using Tomcat but need to do more? Need to support web services, secu
Python types) are the generic 'float' and 'int'
types.
--
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
__
That would keep most of the benefits of an explicit "this is an array
interface" CObject token, but is lighter to check, and doesn't impose any
constraints on implementers for their desc fields.
One of the design goals for the C interface was speed; doing a check that the
fir
On Wed, Jun 14, 2006 at 11:46:27PM -0400, Sasha wrote:
> On 6/14/06, David M. Cooke <[EMAIL PROTECTED]> wrote:
> > After working with them for a while, I'm going to go on record and say that
> > I
> > prefer the long names from Numeric and numarray (like linear_lea
27;m guessing its a 2.3/2.4 difference.
>
> Ted
Who gets the award for "breaks the build most often"? That'd be me!
Sorry, I hardly ever test with 2.3. But, I fixed it (and found a
generator that had snuck in :)
--
|>|\/|<
/----
t;
> FAILED (failures=1)
I'm guessing the C powl function isn't good enough on your machine.
What OS are you running?
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.c
ind is
showing up nothing for me.
A complex128scalar is a complex number made up of doubles (float64); a
complex64 is one of floats (float32).
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics
my Rainbow 100 had a restriction like that!)
My 2 cents...
--
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
Num
there's always subroutine threading (each
opcode is a function, and the program is a list of function pointers).
We won't know until we try :)
> Or perhaps
> David can come with a better solution (vmgen from gforth? no idea what this
> is, but the name sounds sexy;-)
The docs
ler.
My thinking too.
> For large arrays, this should have most of the benfits of giving each
> type it's own opcode, since the memory bandwidth is still small, while
> keeping the interpreter relatively simple.
>
> Unfortunately, int64 doesn't fit under this s
On Tue, 13 Jun 2006 00:42:06 +0200
Steve Schmerler <[EMAIL PROTECTED]> wrote:
> David M. Cooke wrote:
>
> >
> > Sorry about that; I noticed and fixed it last night, but forgot to check
> > it in. It should work now.
> >
> [...]
> Thanks for
(Admittedly, I'm not
sure why we went with the short names instead of the self-descriptive long
ones. It's in the archives somewhere.)
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mc
=
>
> I removed the old /build dir and even did a complete fresh checkout but
> it still fails to build.
>
> cheers,
> steve
>
Sorry about that; I noticed and fixed it last night, but forgot to check it
in. It should work now.
--
|>|\/|<
/
at might not be correct
(but it could be used as a hint).
What about iterables that return, say, tuples? Maybe add a shape argument,
so that fromiter(iterable, dtype, count, shape=(None, 3)) expects elements
from iterable that can be turned into arrays of shape (3,)? That could
replace count,
nsistent handling
of special cases. Packages wouldn't need it if they don't interact: you could
conditionally import it when __array_interface__ is requested, and fail if
you don't have it. It would just be required if you want to do sharing.
--
|>|\/|<
/---
On Fri, 9 Jun 2006 15:19:14 -0600
"Fernando Perez" <[EMAIL PROTECTED]> wrote:
> On 6/9/06, David M. Cooke <[EMAIL PROTECTED]> wrote:
> > On Thu, Jun 08, 2006 at 11:28:04PM -0600, Fernando Perez wrote:
>
> > > Anyone object to this patch against curre
On Fri, 09 Jun 2006 12:08:51 -0600
Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Tim Hochberg wrote:
>
> > Sasha wrote:
> >
> >> On 6/8/06, David M. Cooke <[EMAIL PROTECTED]> wrote:
>
> >>>
> >>
> >> My problem with _
on't think belong in a library. (Now,
if we defined a logging framework, that'd be ok with me!)
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
Numpy-disc
o
> fire a command-line subsystem of its own, so users can simply run
>
> python /path/to/system_info > system_info.log
>
> for further analysis.
Agree; I'll look at it.
--
|>|\/|<
/------\
|
got 0.0
>
> --
> Ran 370 tests in 0.510s
>
> FAILED (failures=1)
> Out[4]:
>
>
> Anyone has any idea?? or Anyone ever successfully did that?
It's new; something's missing in
is does.
> > I would like to eliminate all the other array protocol attributes before
> > NumPy 1.0 (and re-label those such as __array_data__ that are useful in
> > other contexts --- like ctypes).
> +1
+1 also
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Can you give us a specific matrix where it fails? What
platform are you running on?
Lapack_lite probably doesn't get much testing from the developers, because we
probably all have optimized versions of blas and lapack.
--
|>|\/|<
/------
On Tue, 06 Jun 2006 14:15:14 -0700
Christopher Barker <[EMAIL PROTECTED]> wrote:
> David M. Cooke wrote:
> > If you want the dtype
> > used, it's spelled with an appended _.
> >
> > So in this case you'd want dtype=N.object_. N.object0 works too.
ppropriate dtype. If you want the dtype
used, it's spelled with an appended _.
So in this case you'd want dtype=N.object_. N.object0 works too.
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.m
On Tue, 6 Jun 2006 10:44:20 +0200
David Douard <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 05, 2006 at 05:10:23PM -0400, David M. Cooke wrote:
> > I just ran into the fact that the power function for integer types
> > isn't handled in scalarmath yet. I'm going to add
is converted to that type.
Otherwise, I would choose #1.
--
|>|\/|<
/------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
of things to-do. I don't have much
time for it now, unfortunately.
--
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
Numpy-discussion mailing lis
er bugs than the version of LAPACK
available off of netlib.org, as I used the latest patches I could
scrounge up (mostly from Debian).
--
|>|\/|<
/----------\
|David M. Cooke
http://arbutus.ph
rposes.
But I think is this the best option, considering how much crossover
there is.
--
|>|\/|<
/--\
|David M. Cooke
http://arbutus.physics.mcmaster.ca/dmc/ |[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
74 matches
Mail list logo
