e the new parser in 2.5 (Parser/spark.py). It's
just not included when installed :)
--
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
On Jan 8, 2008, at 07:16 , David Cournapeau wrote:
> David M. Cooke wrote:
>> AFAIK, all the tools can specify a svn revision to start from, if you
>> don't need history (or just recent history).
>>
> Are you sure ? bzr-svn does not do it (logically, since bzr-svn
; faster)
> to do the mirrors locally (or from the file:// method, or from a svn
> dump; both mercurial and bzr have methods to import from those)
At least for mercurial's convert command, it's a one-time thing -- you
can't update a created repo from svn.
pository. IIRC, sharing changegroups or pulling patches
between hg repos requires that they have a common ancestor repo (as
opposed to two developers independently converting the svn repo).
--
|>|\/|<
/------\
|David M. Cook
ch don't exist in the module. Looks like a regression
in r4659; fixed in SVN now as r4674.
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
_
es
>>>> radians.__doc__
> radians(x) -> converts angle x from degrees to radians
>
> Not a big deal, but handy. As I generally like to think if numpy as a
> superset of the math module, perhaps is should include these too.
Done.
--
|>|\/|<
/---------
faster, really. And
netlib's BLAS is slow. Now, if there is a BLAS that's easier to
compile than ATLAS on windows, that'd be improvement.
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
> there any reason that a patch shouldn't be submitted?
>>
>> Thanks,
>>
>> --
>> Jarrod Millman
>> Computational Infrastructure for Research Labs
>> 10 Giannini Hall, UC Berkeley
>> phone: 510.643.4014
>> http://cirl.berkeley.edu/
>>
be removed, and system_info.py could be cut
down. Although you can make up for the extra space it uses by removing
Numeric (2MB).
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAI
sandbox, so only
those who enable it will use it (or use it through PyTables). One
problem with moving it out is that Tim reports the compile times on
Windows are ridiculous (20 mins!). Maybe numexpr should become a
scikit? It certainly doesn't need the rest of scipy.
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
om the
source directory). Installing numpy before running the tests is good
practice, anyways.
--
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
_
cipy, most
non-testing classes are already CamelCase (one exception is weave).
--
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
_
susing the test?
Should be fixed now. There wasn't a test for the Pentium M, so it was
being caught by the Pentium III test (of which the M is based on).
--
|>|\/|<
/--\
|David M. Cooke http:/
hich are documented as user accessible). Poking
through the rest, it looks like only the system_info classes are ones
that we would expect users to subclass. We could document the lower_case
names as deprecated, and alias them to CamlCase versions.
--
|>|\/|<
/-
p/waf/) instead of distutils,
which looks like an interesting alternative.
--
|>|\/|<
/------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
that page -- you mean 2006, not 2007 :-)
So yes, a year out of date instead of a month.
--
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca
-dozen
platforms that I can't test on :-) So, it's slow going.
I've got a list of my current goals at
http://scipy.org/scipy/numpy/wiki/DistutilsRevamp.
--
|>|\/|<
/--\
|David M. Cooke ht
C) are better now, it's
still something of a quagmire.
--
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
_
is for Numeric, but last I checked, they
> have not upgraded to numpy.
Even then, their wrappers went through the Python interface, not the C
API. So, it's no faster than using Python straight.
--
|>|\/|<
/-----------
cs even has a
'python' C style -- do "C-c . python").
--
|>|\/|<
/------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
_
o me to be much more mnemonic names...
>
I've added support in r3882 for aliases, so --fcompiler=gfortran
works as --fcompiler=gnu95 (and g77 for gnu, and ifort for intel).
--
|>|\/|<
/---
.#QNAN0',-nan)])
def string_to_number(x):
if x in special_numbers:
return special_numbers[x]
return float(x) if ("." in x) or ("e" in x) else int(x)
Is there a simpler way that I missed?
Best Regards,
//Torgil
_______
On Mon, Jun 18, 2007 at 09:16:06AM -0700, Christopher Barker wrote:
> David M. Cooke wrote:
> > Awesome. I've got a iBook (PPC G4) running OS X that can be used as a slave
> > (it's just being a server right now).
>
> It looks like they already have a PPC OS-X box.
OS X that can be used as a slave
(it's just being a server right now).
--
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
ut it doesn't work. There is an error message:
> "Running from numpy source directory.
^ don't do that :)
Instead, change out of the source directory, and rerun.
--
|>|\/|<
/------\
|David M. Cooke
-g by itself implies -O0 and
-fno-omit-frame-pointer, so it will be slower. However, -g -O2
-fomit-frame-pointer shouldn't be any slower than without the -g.
For gcc, -g does what you said.
--
|>|\/|<
/--\
y laid-out
framework, that is in need of serious refactoring. However, that's a
lot of work, and I'm not going to do it right away...
--
|>|\/|<
/----------\
|David M. Cooke
doesn't require FORTRAN I
> found this surprising. Has there been a change in policy? I'm
> attaching the build log to this message.
Fixed in r3858
--
|>|\/|<
/----------\
|David M. Cooke
nt on the feasibility of this approach? I guess what I'm
> wondering is what dependencies there are on the installation directory.
For numpy and scipy, it should be fine.
An alternate approach would be to use eggs. All the above can be built
as eggs (I just added a setupegg.py script to
On Thu, May 31, 2007 at 02:32:21AM +0200, Albert Strasheim wrote:
> Hello all
>
> - Original Message -
> From: "David M. Cooke" <[EMAIL PROTECTED]>
> To: "Discussion of Numerical Python"
> Sent: Thursday, May 31, 2007 2:08 AM
> Subject:
akage :(
> - Original Message -
> From: "Albert Strasheim" <[EMAIL PROTECTED]>
> To: "Discussion of Numerical Python"
> Sent: Tuesday, May 29, 2007 10:22 PM
> Subject: Re: [Numpy-discussion] build problem on RHE3 machine
>
>
> > Hel
On May 29, 2007, at 08:56 , Albert Strasheim wrote:
> Hello all
>
> - Original Message -
> From: "David M. Cooke" <[EMAIL PROTECTED]>
> To: "Discussion of Numerical Python"
> Sent: Friday, May 25, 2007 7:50 PM
> Subject: Re: [Numpy-discussi
> your $PATH variable when you are building numpy if a full path name is
> not given in the CC line to see what compiler will be picked up.
Also, check that you don't have a CC environment variable defined (i.e.,
echo $CC should be blank), as that will overrride the Python Makefile
On Fri, May 25, 2007 at 12:45:32PM -0500, Robert Kern wrote:
> David M. Cooke wrote:
> > On Fri, May 25, 2007 at 07:25:15PM +0200, Albert Strasheim wrote:
> >> I'm still having problems on Windows with r3828. Build command:
> >>
> >> python setup.py -v con
m numpy source directory.
> error: don't know how to compile Fortran code on platform 'nt'
>
> - Original Message -
> From: "Christopher Hanley" <[EMAIL PROTECTED]>
> To: "Discussion of Numerical Python"
> Sent: Friday, May 25,
n
> Could not locate executable f95
> customize G95FCompiler
> Could not locate executable g95
> error: don't know how to compile Fortran code on platform 'posix'
>
> This problem is new this morning.
Could you send me the results of running with the -v flag?
i.e., python setup.py -v build
--
|&g
ze Gnu95FCompiler
> Could not locate executable gfortran
> Could not locate executable f95
> customize G95FCompiler
> Could not locate executable g95
> error: don't know how to compile Fortran code on platform 'posix'
>
> This problem is new this morning.
Hmm, my fault. I'll have a look.
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
w do I change out of that directory and try again?
cd ..
--
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
N
so appending each value is
amortized to O(1) time. A list though would use more memory
per element as each element is a full Python object.
--
|>|\/|<
/----------\
|David M. Cooke http://ar
The same goes for numpy.sum, which, at the least, should be
modified so that the function signatures are compatible:
numpy.sum(x, axis=None, dtype=None, out=None)
vs.
sum(sequence, start=0)
--
|>|\/|<
/--\
|Dav
0.0
In [3]: product([])
Out[3]: 1.0
--
|>|\/|<
/------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://
2., 3.])
In [3]: a[:,newaxis]
Out[3]:
array([[ 1.],
[ 2.],
[ 3.]])
In [4]: a[newaxis,:]
Out[4]: array([[ 1., 2., 3.]])
When newaxis is used as an index, a new axis of dimension 1 is added.
--
|>|\/|<
/--------
/ticket/469
I've added a 1.0.3 milestone and set these to them (or to 1.1, according
to Travis's comments).
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAI
mplete list of what we want to accept :-)
On the other side of the coin, I'd argue the string representations of
our float scalars should also be platform-agnostic (standardising on Inf
and NaN would be best, I think).
--
|>|\/|<
/--
the
floating-point types, checking first if the string matches inf or nan
patterns would be sufficient.
There's a bug in fromfile anyways: because it passes the separator
directly to fscanf to skip over it, using a % in your separator will not
work.
--
|>|\/|<
/
On Apr 23, 2007, at 21:35 , David M. Cooke wrote:
Python defines x // y as returning the floor of the division, and x
% y has the same sign as y. However, in C89, it is implementation-
defined (i.e., portability-pain-in-the-ass) whether the floor or
ceil is used when the signs of x and y
ulo so that the invariant holds, but we don't
agree with Python in either / or %. Comments?
On Mon, 23 Apr 2007, David M. Cooke wrote:
On Apr 23, 2007, at 16:41 , Christian Marquardt wrote:
On Mon, April 23, 2007 22:29, Christian Marquardt wrote:
Actually,
it happens for normal i
n of longs? I
would
think both should give the same, really... (Python 2.5, numpy
1.0.3dev3725,
Linux, Intel compilers...)
Many thanks for any ideas / advice,
Christian
--
|>|\/|<
/------\
|David M. Cooke
On Apr 21, 2007, at 09:03 , Christian Marquardt wrote:
Yes,
that worked - many thanks!
FWIW, svn should work out of the box now.
On Thu, April 19, 2007 22:38, David M. Cooke wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Marquardt wrote:
Dear David,
the svn version of
ipt there when switching the linker.
- --
|>|\/|<
/------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG
or can I just bypass that (somehow) and link the .so and go on
> my merry way?
I think you should be fine with a C compiler. You'd probably have to
fiddle with the definitions of the blas_info and lapack_info classes in
numpy.distutils.system_info -- they hardcode using Fortran.
At some p
;
> Can anyone offer an opinion as to the severity of this failure?
Only serious if you're using long doubles. I'm not sure where the extra
is coming from (it's about an error of 2^-60). Could be that Solaris's
support for long doubles isn't quit
; (Is it OK to report Numexpr bugs in the SciPy Trac instance? And,
> what's the right capitalisation of "Numexpr"? ;) )
Yes; open a bug for #3 on the SciPy Trac, and assign them to me
(cookedm), so I don't forget about them. You can open a bug for adding
string expressi
es is different from what's normally
> done (and it's a pain...)
Already fixed in svn :)
- --
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
-BEGIN PGP SIGNA
faster than the
python expression, and comparable to that of weave. I've been thinking
of making a JIT for it, but I haven't had the time :)
- --
|>|\/|<
/------\
|David M. Cooke http://arbutus.physics.mcmaster
) (or #if 0 if that strikes your fancy).
- --
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Using Gnu
ot find it (it shouldn't be including it anyway, as you said). This
>> time it fails when trying to compile "_capi.c". Thanks for all your
>> help so far!
Try this updated patch. It replaces the defined(linux) tests with
defined(__GLIBC__).
- --
|>|\/|&
cluded, as the system is only included when one of
__GLIBC__, __APPLE__, or __MINGW32__ is defined.
See if the attached patch helps.
- --
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.c
Yes; the Accelerate framework exists on all installations of OS X, so we
can use it with no problems.
- --
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http
W, you can use attributes on flags too:
In [1]: eye(2).flags.c_contiguous
Out[1]: True
In [2]: eye(2).T.flags.f_contiguous
Out[2]: True
- --
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL
On Tue, Mar 20, 2007 at 12:57:45PM -0500, Jeff Strunk wrote:
> On Tuesday 20 March 2007 11:54 am, David M. Cooke wrote:
> > On Mon, Mar 19, 2007 at 12:54:51PM -0500, Jeff Strunk wrote:
> > > Good afternoon,
> > >
> > > By request, I have installed the Tr
[[ReST(/numpy/trunk/doc/CAPI.txt)]]
--
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
;
I just do
a = numpy.array([1,2,3], dtype=float)
The Python types int, float, and bool translate to numpy.int_,
numpy.double, and numpy.bool (i.e., the C equivalents of the Pythonn
types; note that int_ is a C long).
--
|>|\/|<
/--
worth adding the
complexity.
--
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
Numpy-discussion mailing li
d).
Wow! I wonder if lowering the optimisation level would help.
--
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
d be true in general.
--
|>|\/|<
/----------\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
PGP.sig
Description: This is a digitally signed message part
___
Numpy-discussion mailing list
Numpy
res += a.tolist()
else:
raise ValueError("arguments to row must be row-like")
return array(res)
then
b = array([ row(1,2,3,a), row(5,a,6,7), row(0,2-a,3,4) ])
--
|>|\/|<
/--\
|David M. Cooke
d 15 decimal digit real
used internally. All calculations are done in base 10.
The exponent e for the 12-digit real is in the range -500 < e < 500,
and for the 15-digit, -5 < e < 5.
AFAIK, most of HP's calculators are like this.
--
|>|\/|<
/---
apack_opt_info in the setup.py. AFAIK, that's only used
when debugging ATLAS installs in scipy).
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
are being used for scipy.
>
> I have attached my site.cfg. Any help would be much appreciated.
No, they're only in there for scipy (and for other packages that
would like to use them). They're not required for Numpy.
--
|>|\/|<
/----------
On Jan 10, 2007, at 13:52 , Charles R Harris wrote:
> On 1/10/07, David M. Cooke <[EMAIL PROTECTED]> wrote: On
> Jan 7, 2007, at 00:16 , Charles R Harris wrote:
> >
> > That brings up the main question I have about how to break up the C
> > files. I note
d level (files).
Some of the functions, however, are quite large, and could do with
breaking up into smaller functions.
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
outines not in numpy.linalg.
(It's on my list to add a faster xgemm routine when BLAS isn't used...)
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
__
73 matches
Mail list logo
