A Monday 07 April 2008, Charles R Harris escrigué:
> On Mon, Apr 7, 2008 at 12:19 AM, Rahul Garg <[EMAIL PROTECTED]> wrote:
> > Quoting [EMAIL PROTECTED]:
> > > What will be the licensing of this project? Do you know yet?
> >
> > I am thinking GPL for the compiler and LGPL for any runtime
> > comp
Hi Rahul,
Nice project. I think you are taking the right direction with type
annotations. I you get this working and reliable, you will be much loved
by the community.
On Sun, Apr 06, 2008 at 11:19:58PM -0500, Travis E. Oliphant wrote:
> > c) Strings as type declarations : Do you think I should
> (Though as the saying goes, little duplication is normal (and perhaps
> wanted) for open source software.)
Sorry! I meant "a little", completely reversing the meaning of my sentence.
Dag Sverre
___
Numpy-discussion mailing list
Numpy-discussion@scip
Am Dienstag, 11. März 2008 00:24:04 schrieb David Bolme:
> The steps you describe here are correct. I am putting together an
> open source computer vision library based on numpy/scipy. It will
> include an automatic PCA algorithm with face detection, eye detection,
> PCA dimensionally reduction,
> What is Spyke?
> In many performance critical projects, it is often necessary to
> rewrite parts of the application in C. However writing C wrappers can
> be time consuming. Spyke offers an alternative approach. You add
> annotations to your Python code as strings. These strings are
> discarded
On Sun, Apr 6, 2008 at 8:48 PM, Rahul Garg <[EMAIL PROTECTED]> wrote:
> function. This
> idea is directly copied from PLW (Python Language Wrapper) project.
> Once Python3k arrives, much of these declarations will be moved to
> function annotations and class decorators.
Python 3k alpha4 is av
Am Samstag, 05. April 2008 21:54:27 schrieb Anne Archibald:
> There's also a fourth option - raise an exception if any points are
> outside the range.
+1
I think this should be the default. Otherwise, I tend towards "exclude", in
order to have comparable bin sizes (when plotting, I always find
On Mon, 07 Apr 2008, Rahul Garg apparently wrote:
> I am thinking GPL for the compiler and LGPL for any
> runtime components which should be similar to GCC. Which
> version : Version 2 or version 3 of the license is
> undecided.
The author determines the license, of course.
But don't forget to
Anne, Travis,
I have no problem to get rid of varu and stdu in MaskedArray: they were
introduced for my own convenience, and they're indeed outdated with the
introduction of the ddof parameters. I'll get rid of them next time I post
something on the SVN.
+1 for an outlier keyword. Note, that this implies that when bins are passed
explicitly, the edges are given (nbins+1), not simply the left edges
(nbins).
While we are refactoring histogram, I'd suggest adding an axis keyword. This
is pretty straightforward to implement using the np.apply_along_ax
Dear Guys @list :
I wanna do some application with mulgrid method for electrostatic
problems,
is there some python package available for my purpose ?
Best,
--
Hai-Ping Lan
Department of Electronics ,
Peking University , Bejing, 100871
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
Hi,
Thanks David for pointing the piece of information I forgot to add in
my original email.
-1 for 'raise an exception' because, as Dan points out, the problem
stems from user providing bins.
+1 for the outliers keyword. Should 'exclude' distinguish points that
are too low and those that are too
2008/4/4, Joe Harrington <[EMAIL PROTECTED]>:
>
> import numpy as N
> import numpy.math as N.M
> import numpy.trig as N.T
> import numpy.stat as N.S
I don't think the issue is whether to put everything in the base namespace
// everything in individual namespace, but rather to find an optima
On 07/04/2008, David Huard <[EMAIL PROTECTED]> wrote:
>
> 2008/4/4, Joe Harrington <[EMAIL PROTECTED]>:
> > import numpy as N
> > import numpy.math as N.M
> > import numpy.trig as N.T
> > import numpy.stat as N.S
>
>
> I don't think the issue is whether to put everything in the base namespace
I know I'm off topic and maybe a day late, but I'm pained by the naming of
ddof.
It is simply not intuitive for anyone other than the person who thought it
up (and from my recollection, maybe not even for him).For one, most
stats folk use 'df' as the abbreviation for 'degrees of freedom'. Sec
On Mon, Apr 07, 2008 at 05:20:47PM +0200, Stéfan van der Walt wrote:
> I agree, and I think we can come to some compromise -- maybe a
> numpy.all namespace, that simply imports all the other subpackages.
For the beginner, "from numpy.all import *" is more confusing than "from
numpy import *" (whic
I am the lead developer of PyTrilinos, a python interface to the
Trilinos project: http://trilinos.sandia.gov.
Trilinos has many packages related to solvers, including ML, the
multilevel preconditioning package. There may be a little bit of a
learning curve, but there are example scripts to
BTW, I stumbled on something strange with the nose framework. If you from
numpy.testing import * in a test file, the nose framework will try to test
the testing module by calling every test* method.
I just mention it there because I think I'm not the only one to do this for
set_package_path, asser
Thank you, Bill. I will try to fill that curve .
On Mon, Apr 7, 2008 at 11:55 PM, Bill Spotz <[EMAIL PROTECTED]> wrote:
> I am the lead developer of PyTrilinos, a python interface to the
> Trilinos project: http://trilinos.sandia.gov.
>
> Trilinos has many packages related to solvers, including
On 07/04/2008, lan haiping <[EMAIL PROTECTED]> wrote:
> Dear Guys @list :
> I wanna do some application with mulgrid method for electrostatic
> problems,
> is there some python package available for my purpose ?
Nathan bell has a mesmerisingly beautiful webpage at
http://graphics.cs.uiuc.edu/~w
On 07/04/2008, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 07, 2008 at 05:20:47PM +0200, Stéfan van der Walt wrote:
> > I agree, and I think we can come to some compromise -- maybe a
> > numpy.all namespace, that simply imports all the other subpackages.
>
>
> For the beginner, "from
On 07/04/2008, Matthieu Brucher <[EMAIL PROTECTED]> wrote:
> BTW, I stumbled on something strange with the nose framework. If you from
> numpy.testing import * in a test file, the nose framework will try to test
> the testing module by calling every test* method.
>
> I just mention it there because
Hi,
On Mon, Apr 7, 2008 at 4:25 PM, Stéfan van der Walt <[EMAIL PROTECTED]> wrote:
> On 07/04/2008, Matthieu Brucher <[EMAIL PROTECTED]> wrote:
> > BTW, I stumbled on something strange with the nose framework. If you from
> > numpy.testing import * in a test file, the nose framework will try to
On Mon, Apr 07, 2008 at 06:22:28PM +0200, Stéfan van der Walt wrote:
> You're only a beginner for a short while, and after that the lack of
> namespaces really start to bite. I am all in favour of catering for
> those who are busy learning numpy, but should we do that at the cost
> of our advanced
On Mon, Apr 7, 2008 at 9:57 AM, Gael Varoquaux <
[EMAIL PROTECTED]> wrote:
> On Mon, Apr 07, 2008 at 06:22:28PM +0200, Stéfan van der Walt wrote:
> > You're only a beginner for a short while, and after that the lack of
> > namespaces really start to bite. I am all in favour of catering for
> > th
Hello,
I registered the Scipy and Numpy mailing lists at the Nabble Web Forums:
Scipy
http://www.nabble.com/Scipy-User-f33045.html
Numpy
http://www.nabble.com/Numpy-discussion-f33046.html
I still have to import the old emails from the archives.
Kind regards and happy communicating,
Tim Michelsen
On Mon, April 7, 2008 11:16, Timothy Hochberg wrote:
>
> If "from numpy.all import *" is really too complicated, which although
> possible, seems a little disheartening, I suspect it would be easy enough
> to
> have a separate module that pulled everything in so that you could use
> "from
> big_num
On Mon, Apr 07, 2008 at 10:16:22AM -0700, Timothy Hochberg wrote:
>I prefer 'all' for this since it has the correct meaning. 'api' assuming
>that one can remember what it means doesn't fit. The 'all' module would
>not contain the api, at least not the preferred api (in my book at least)
On Mon, Apr 7, 2008 at 10:30 AM, Gael Varoquaux <
[EMAIL PROTECTED]> wrote:
> On Mon, Apr 07, 2008 at 10:16:22AM -0700, Timothy Hochberg wrote:
> >I prefer 'all' for this since it has the correct meaning. 'api'
> assuming
> >that one can remember what it means doesn't fit. The 'all' module
Steven H. Rogers wrote:
> On Mon, April 7, 2008 11:16, Timothy Hochberg wrote:
>
>> If "from numpy.all import *" is really too complicated, which although
>> possible, seems a little disheartening, I suspect it would be easy enough
>> to
>> have a separate module that pulled everything in so tha
On Mon, Apr 7, 2008 at 12:54 AM, Francesc Altet <[EMAIL PROTECTED]> wrote:
> A Monday 07 April 2008, Charles R Harris escrigué:
> > On Mon, Apr 7, 2008 at 12:19 AM, Rahul Garg <[EMAIL PROTECTED]> wrote:
> > > Quoting [EMAIL PROTECTED]:
> > > > What will be the licensing of this project? Do you
On Mon, Apr 7, 2008 at 11:19 AM, Bruce Southey <[EMAIL PROTECTED]> wrote:
> Hi,
> I think that splitting the NumPy namespace should not happen within a
> major release series because it would cause too many breakages. Rather
> it should be in a forthcoming release like the 2.0 series where it
On Mon, Apr 07, 2008 at 11:29:41AM -0700, Robert Kern wrote:
> I would prefer not to do it at all. We've just gotten people moved
> over from Numeric; I'd hate to break their trust again.
+1.
Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy
On Mon, Apr 7, 2008 at 11:29 AM, Gael Varoquaux
<[EMAIL PROTECTED]> wrote:
> On Mon, Apr 07, 2008 at 11:29:41AM -0700, Robert Kern wrote:
> > I would prefer not to do it at all. We've just gotten people moved
> > over from Numeric; I'd hate to break their trust again.
+1
I also think we have a
On Montag 07 April 2008, Robert Kern wrote:
> I would prefer not to do it at all. We've just gotten people moved
> over from Numeric; I'd hate to break their trust again.
+1.
IMO, numpy has arrived at a state where there's just enough namespace clutter
to allow most use cases to get by without i
On Mon, Apr 7, 2008 at 11:02 AM, Timothy Hochberg <[EMAIL PROTECTED]> wrote:
> I'm at a bit of a disadvantage since the convention in question hasn't
> penetrated the parts of of Python land that I inhabit (which could either
> imply something about my experience or about the universality of the '
I checked out numpy from svn few hours ago, and created a site.cfg following
site.cfg.example. During the build process I am getting an warning that
unoptimized lapack in being used.
Machine: dual core amd64 running gentoo linux.
Relevant packages: python 2.5.1, blas-atlas-3.8.0, lapack-atlas-3.
Hi Nadav,
On Montag 07 April 2008, Nadav Horesh wrote:
> [snip]
Try something like this:
[atlas]
library_dirs = /users/kloeckner/mach/x86_64/pool/lib,/usr/lib
atlas_libs = lapack, f77blas, cblas, atlas
Andreas
signature.asc
Description: This is a digitally signed message part.
___
"Rahul Garg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Note this message has been posted to numpy-discussion and python-dev.
| Sorry for the multiple posting but I thought both python devs and
| numpy users will be interested. If you believe your list should not
| receive this
+1 for axis and +1 for a keyword to define what to do with values
outside the range.
For the keyword, ather than 'outliers', I would propose 'discard' or
'exclude', because it could be used to describe the four
possibilities :
- discard='low' => values lower than the range are discarded,
va
On 07/04/2008, Andreas Klöckner <[EMAIL PROTECTED]> wrote:
> On Montag 07 April 2008, Robert Kern wrote:
> > I would prefer not to do it at all. We've just gotten people moved
> > over from Numeric; I'd hate to break their trust again.
>
>
> +1.
>
> IMO, numpy has arrived at a state where there'
On Mon, Apr 07, 2008 at 10:16:57PM +0200, Stéfan van der Walt wrote:
> Would it therefore make sense to
> a) Reorganise numpy to expose functionality as numpy.api.*
> b) Do a series of imports in numpy.__init__ which pulls in from numpy.api.
> This way, numpy.* would look exactly as it does now,
On Apr 7, 2008, at 4:14 PM, LB wrote:
> +1 for axis and +1 for a keyword to define what to do with values
> outside the range.
>
> For the keyword, ather than 'outliers', I would propose 'discard' or
> 'exclude', because it could be used to describe the four
> possibilities :
> - discard='low'
> I wouldn't exactly call 494 functions "just enough namespace clutter";
> I'd much prefer to have a clean api to work with
I don't know. The 494 functions do not seem like many to me.
Apparently, I tend to come down in the "flat earth society" although I
do like some structure (after all th
On Mon, Apr 07, 2008 at 03:52:45PM -0500, Travis E. Oliphant wrote:
> This discussion is interesting, but it is really better suited for 1.1,
> isn't it?
Yes. The original dicussion was about adding simple financial functions
for Numpy.
I think the functions you wrote should land somewhere. We
On Montag 07 April 2008, Stéfan van der Walt wrote:
> I wouldn't exactly call 494 functions "just enough namespace clutter";
> I'd much prefer to have a clean api to work with.
Not to bicker, but...
>>> import numpy
>>> len(dir(numpy))
494
>>> numpy.__version__
'1.0.4'
>>> funcs = [s for s in di
On 07/04/2008, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
> > Would it therefore make sense to
> >
> > a) Reorganise numpy to expose functionality as numpy.api.*
> > b) Do a series of imports in numpy.__init__ which pulls in from numpy.api.
> >
> > This way, numpy.* would look exactly as it
On 07/04/2008, Andreas Klöckner <[EMAIL PROTECTED]> wrote:
> On Montag 07 April 2008, Stéfan van der Walt wrote:
> > I wouldn't exactly call 494 functions "just enough namespace clutter";
> > I'd much prefer to have a clean api to work with.
>
>
> Not to bicker, but...
>
> >>> import numpy
> >
On Mon, Apr 07, 2008 at 11:21:41PM +0200, Stéfan van der Walt wrote:
> It doesn't matter *what* these completions are -- they're still there.
> Sifting through 500 options isn't fun
I get more than that when I tab in an empty shell on my box.
:-}
Why do you expect to be able to inspect a module
On Mon, Apr 7, 2008 at 3:21 PM, Stéfan van der Walt <[EMAIL PROTECTED]>
wrote:
> On 07/04/2008, Andreas Klöckner <[EMAIL PROTECTED]> wrote:
> > On Montag 07 April 2008, Stéfan van der Walt wrote:
> > > I wouldn't exactly call 494 functions "just enough namespace
> clutter";
> > > I'd much prefe
On Apr 7, 2008, at 2:29 PM, Robert Kern wrote:
> On Mon, Apr 7, 2008 at 11:19 AM, Bruce Southey <[EMAIL PROTECTED]>
> wrote:
>> Hi,
>> I think that splitting the NumPy namespace should not happen
>> within a
>> major release series because it would cause too many breakages.
>> Rather
>>
> 3) Some don't like the bloat (in disk space or download sizes) of
> adding things to numpy. In my case, as long as the addition doesn't
> make installations any more difficult I don't care. For the great
> majority, the current size or anything within an order of magnitude
> is not an import
On Apr 7, 2008, at 5:54 PM, Brian Granger wrote:
>>
> The only problem is that if we keep adding things to numpy that could
> be in scipy, it will _never_ be clear to users where they can expect
> to find things. It is already bad enough. How do I explain to a
> user/student/scientist that ffts
On Mon, Apr 7, 2008 at 4:03 PM, Perry Greenfield <[EMAIL PROTECTED]> wrote:
>
> On Apr 7, 2008, at 5:54 PM, Brian Granger wrote:
> >>
> > The only problem is that if we keep adding things to numpy that could
> > be in scipy, it will _never_ be clear to users where they can expect
> > to find
Hi all,
here's the output difference between 32/64 bit tests run:
bic128[scipy]$ diff -u tests_32.txt tests_64.txt
--- tests_32.txt2008-04-07 15:54:29.0 -0700
+++ tests_64.txt2008-04-07 15:53:58.0 -0700
@@ -611,12 +611,6 @@
testip_types (numpy.core.tests.test_mult
On Mon, Apr 7, 2008 at 3:56 PM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> here's the output difference between 32/64 bit tests run:
>
> bic128[scipy]$ diff -u tests_32.txt tests_64.txt
> --- tests_32.txt2008-04-07 15:54:29.0 -0700
> +++ tests_64.txt2008-04-
Thanks everyone for suggestions and enthusiasm.
1. For type declarations moving from string based annotations to
decorators for functions.
(Function annotations in 3k: Well it should be easy to add them once
that feature comes out.)
2. License : Keeping it as GPLv3 for compiler. The "runtime
On Mon, Apr 7, 2008 at 5:28 PM, Rahul Garg <[EMAIL PROTECTED]> wrote:
> 2. License : Keeping it as GPLv3 for compiler. The "runtime" is just a
> python script that invokes the real compiler binary and can be
> licensed under LGPL or BSD if thats what people prefer.
Can you clarify this? That
On Mon, Apr 7, 2008 at 4:04 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> > On 32 bits, 869 are found and on Fedora x86_64, it's 863. Above is
> > the difference (requested by rkern).
>
> I think this is fine. The different arises because of extra scalar
> types on the 32 bit system that don
On Mon, Apr 7, 2008 at 6:29 PM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 7, 2008 at 4:04 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>
> > > On 32 bits, 869 are found and on Fedora x86_64, it's 863. Above is
> > > the difference (requested by rkern).
> >
> > I think this is
> On Apr 7, 2008, at 4:14 PM, LB wrote:
> > +1 for axis and +1 for a keyword to define what to do with values
> > outside the range.
> >
> > For the keyword, ather than 'outliers', I would propose 'discard' or
> > 'exclude', because it could be used to describe the four
> > possibilities :
> > - d
I tried:
[ALL]
library_dirs = /usr/lib64/lapack/atlas:/usr/lib64/blas/threaded-atlas:/usr/lib
include_dirs = /usr/include/atlas:/usr/include
[blas_opt]
library_dirs = /usr/lib64/blas/threaded-atlas:/usr/lib64
libraries = blas, cblas, atlas
[lapack_opt]
library_dirs = /usr/lib64/lapack/atlas:/usr/l
Nadav,
> [ALL]
> library_dirs =
> /usr/lib64/lapack/atlas:/usr/lib64/blas/threaded-atlas:/usr/lib
> include_dirs = /usr/include/atlas:/usr/include
I believe (contrary to my 'unix' intuition) that you should replace the colons
by commas.
ie:
include_dirs = /usr/include/atlas,/usr/include
library_d
63 matches
Mail list logo
