Sven Schreiber wrote:
> That would be fine with me. However, I'd like to point out that after
> some bug-squashing currently all numpy functions deal with
> numpy-matrices correctly, afaik. The current behavior of numpy.diag
> could be viewed as a violation of that principle. (Because if x has
> sh
Hello all
Another +1. When I build a Windows installer, I get:
numpy-1.0b2.dev2915.win32-py2.4.exe
This tells me everything I want to know.
Regards,
Albert
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:numpy-
> [EMAIL PROTECTED] On Behalf Of Sasha
> Sent: 27 July 2006 21:26
>
On 7/27/06, Andrew Straw <[EMAIL PROTECTED]> wrote:
[snip]
> The one system that I
> suggest we really try to work with out-of-the-box, however, is
> setuptools, which, luckily, attached special meaning to ".dev" in a
> release number, so that it sorts _before_ the release. (In setuptools
> jargon,
Travis Oliphant wrote:
> I'm still looking for ideas on version numbering.
>
> Right now, the trunk is at version 0.9.9 but this has bug-fixes from
> the 1.0b1 release. The next release will be 1.0b2 and should occur in
> about a week.
>
> I don't really like having the trunk use a 'lower' ver
On 7/27/06, Francesc Altet <[EMAIL PROTECTED]> wrote:
> Travis,
> Speaking on what we regularly do, I would choose a 1.0b2. for the
> trunk version. This is a way to say people: "Hey, you are using a version
> that will be the 1.0b2 in the future.". Of course, the same meaning can be
> achieved i
A factor of 2! Is that short for a factor of **2?On 7/27/06, Rolf Wester <[EMAIL PROTECTED]
> wrote:Hello,I have a program using Numeric and weave developed with
Python2.3. Ijust switched to Python2.4 and numpy. The Numeric/weave version isalmost a factor of 2 faster compared to numpy/weave. Is th
Hello,
I have a program using Numeric and weave developed with Python2.3. I
just switched to Python2.4 and numpy. The Numeric/weave version is
almost a factor of 2 faster compared to numpy/weave. Is that what is to
be expected or are there options to improve the speed of numpy/weave? I
would
Travis Oliphant wrote:
> When 1.0 comes out, then the trunk will be
>
> 1.0.
Shouldn't the trunk then become:
1.1.0. or 1.1
That would signify a development version, which I understand is what the
trunk would then be. And it would be a greater version than the released
one, which is what we'd
Travis,
A Dijous 27 Juliol 2006 18:22, Travis Oliphant va escriure:
> I'm still looking for ideas on version numbering.
>
> Right now, the trunk is at version 0.9.9 but this has bug-fixes from
> the 1.0b1 release. The next release will be 1.0b2 and should occur in
> about a week.
>
> I don't rea
On 7/27/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
[snip]
> I don't really like having the trunk use a 'lower' version number than
> the releases but I'm not sure what to do. The problem seems to stem
> from wanting to have the version number sort somewhat reasonably when
> the development num
I'm still looking for ideas on version numbering.
Right now, the trunk is at version 0.9.9 but this has bug-fixes from
the 1.0b1 release. The next release will be 1.0b2 and should occur in
about a week.
I don't really like having the trunk use a 'lower' version number than
the releases but
Gary Ruben wrote:
> Should
> >>> seed(1)
> act the same as
> >>> seed(array([1]))
> in the random module?
No. They use slightly different mechanisms to seed. The integer uses
RandomKit's
seeding routine. I borrowed Python's mechanism for seeding from an array of
integers. Now that it comes up
On 7/26/06, Robert Kern <[EMAIL PROTECTED]> wrote:
> If someone can explain the rules of engagement for Lightning Talks, I'm> thinking about presenting this at SciPy 2006. Then you'll see there is a> reason for my madness.Unfortunately, we only have scheduled 30 minutes of lightning talks this year
David M. Cooke wrote:
> That's one reason that I'm careful (or least try to be) in my change messages
> to mention the ticket number for the bug fixed in the first line, so that
> Trac will show it in the source browser, and to mention the revision number
> of the fix in the ticket itself. The comm
Robert Kern wrote:
> Let's not make a branch until 1.0 is actually out and we are making 1.0.x
> releases. It's confusing since at the moment, the trunk is not getting any
> activity. It's not the main trunk of development. Some people have already
> come
> to the list confused about where to g
Mike Ressler wrote:
> My apologies if this is a duplicate - my first attempt doesn't seem to
> have gone back to the list.
SF if being nasty with GMail. I'll have to speed up moving the list to
scipy.org.
> If someone can explain the rules of engagement for Lightning Talks, I'm
> thinking abou
Andrew Jaffe wrote:
> Hi-
>
> On PPC Mac OSX universal build 2.4.3, gcc 4.0,
>
>
> In [1]: import numpy as N
>
> In [2]: print N.__version__
> 1.0.2897
>
> In [3]: N.random.uniform(0,1)
> Segmentation fault
Travis recently (r2892) checked in a pretty major change to the distributions
to
all
Should
>>> seed(1)
act the same as
>>> seed(array([1]))
in the random module?
It generates a traceback with the Windows 1.0b1 binary.
Gary R.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Tech
18 matches
Mail list logo
