2008/8/18 Andrew Dalke <[EMAIL PROTECTED]>:
> How do users know that those are present? How do users
> view those docs? You're the one who added that directory, yes?,
> so you've probably got the most experience with it. I
> couldn't figure out it, and the README in the doc/ directory
> wasn't h
2008/8/18 Travis E. Oliphant <[EMAIL PROTECTED]>:
>> I still think we are going about this the wrong way. We have two
>> different sets of expectations, and we can't satisfy both by ripping
>> everything apart. I'd much prefer two entry points into NumPy: one
>> for people who need speed, and one
On Aug 19, 2008, at 1:48 AM, Stéfan van der Walt wrote:
> Wouldn't we want users to have access with
> the doc framework without doing anything special? And, yes, some of
> the documents are empty, but a number of them have already been
> written.
How do users know that those are present? How do
Stéfan van der Walt wrote:
> 2008/8/18 Travis E. Oliphant <[EMAIL PROTECTED]>:
>
>> I say go ahead including changing #1 and #4. Let's leave 5 for the moment.
>>
>
> I ran several benchmarks and made sure that these imports take a
> minimal amount of time. Wouldn't we want users to have a
2008/8/18 Travis E. Oliphant <[EMAIL PROTECTED]>:
> I say go ahead including changing #1 and #4. Let's leave 5 for the moment.
I ran several benchmarks and made sure that these imports take a
minimal amount of time. Wouldn't we want users to have access with
the doc framework without doing anyth
On Mon, Aug 18, 2008 at 15:04, Travis E. Oliphant
<[EMAIL PROTECTED]> wrote:
> I say go ahead including changing #1 and #4. Let's leave 5 for the moment.
I think we can just delete all of the test() and bench() functions
except for numpy.{bench,test}(). That way, there is no code
duplication.
--
Andrew Dalke wrote:
> Andrew Dalke:
>
>> Any chance of someone reviewing my suggestions for
>> making the import somewhat faster still?
>>
>>http://scipy.org/scipy/numpy/ticket/874
>>
>>
>
>
> Travis E. Oliphant:
>
>> In sum: I think 2, 3, 6, 7, 8, and 9 can be done immediately. 1)
Andrew Dalke:
> Any chance of someone reviewing my suggestions for
> making the import somewhat faster still?
>
>http://scipy.org/scipy/numpy/ticket/874
>
Travis E. Oliphant:
> In sum: I think 2, 3, 6, 7, 8, and 9 can be done immediately. 1) and
> 4) could be O.K. but 1) does break code and
On Aug 15, 2008, at 11:18 PM, Travis E. Oliphant wrote:
> Where would that be, in the C-code? The reason for add_newdocs is to
> avoid writing docstrings in C-code which is a pain.
That was my thought. I could see that the code might useful
during module development, where you don't want text cha
On Aug 15, 2008, at 11:18 PM, Travis E. Oliphant wrote:
> I've removed this loop. Are there other places in numpy.core that
> depend on numpy.lib?
That fixed the loop I identified. I removed the "import lib" in
add_newdocs.py
and things imported fine.
I then commented out the following line
2008/8/15 Andrew Dalke <[EMAIL PROTECTED]>:
> On Aug 15, 2008, at 6:41 PM, Andrew Dalke wrote:
>> I don't think it's enough. I don't like environmental
>> variable tricks like that. My tests suggest:
>>current SVN: 0.12 seconds
>>my patch: 0.10 seconds
>>removing some top-level import
On Aug 15, 2008, at 6:41 PM, Andrew Dalke wrote:
> I don't think it's enough. I don't like environmental
> variable tricks like that. My tests suggest:
>current SVN: 0.12 seconds
>my patch: 0.10 seconds
>removing some top-level imports: 0.09 seconds
>my patch and removing some
>
Andrew Dalke wrote:
>
> Can that be made quicker? Not easily. "lib" is
> first imported in "add_newdocs". Personally, I
> want to get rid of add_newdocs and move the
> docstrings into the correct locations.
>
Where would that be, in the C-code? The reason for add_newdocs is to
avoid writing
On Fri, Aug 15, 2008 at 11:41 AM, Andrew Dalke
<[EMAIL PROTECTED]> wrote:
>
> It's possible to clean up the code so this loop
> doesn't exist, and fix things so that fewer things
> are imported when some environment variable is set,
> but it doesn't look easy. Modules depend on other
> modules a b
2008/8/15 Andrew Dalke <[EMAIL PROTECTED]>:
> I don't think it's enough. I don't like environmental
> variable tricks like that. My tests suggest:
> current SVN: 0.12 seconds
> my patch: 0.10 seconds
> removing some top-level imports: 0.09 seconds
> my patch and removing some
> addit
Andrew Dalke wrote:
> I forgot to mention..
>
>
> On Aug 15, 2008, at 9:00 AM, Travis E. Oliphant wrote:
>
>> 1) Removing ctypeslib import
>>
>> * Can break code if somebody has been doing import numpy and then
>> using
>> numpy.ctypeslib
>> * I'm fine with people needing to import numpy.ctype
I forgot to mention..
On Aug 15, 2008, at 9:00 AM, Travis E. Oliphant wrote:
> 1) Removing ctypeslib import
>
> * Can break code if somebody has been doing import numpy and then
> using
> numpy.ctypeslib
> * I'm fine with people needing to import numpy.ctypeslib to use the
> capability as long
On Fri, Aug 15, 2008 at 10:41 AM, Andrew Dalke <[EMAIL PROTECTED]>wrote:
> On Aug 15, 2008, at 4:38 PM, Pauli Virtanen wrote:
> > I think you can still do something evil, like this:
> >
> > import os
> > if os.environ.get('NUMPY_VIA_API', '0') != '0':
> > from numpy.lib.fro
Jarrod Millman wrote:
> NumPy 1.2.0b2 is now available. Please test this so that we can
> uncover any problems ASAP.
> Mac binary:
> https://cirl.berkeley.edu/numpy/numpy-1.2.0b2-py2.5-macosx10.5.dmg
Ran 1715 tests in 12.671s
OK (SKIP=1)
OS-X 10.4.11
Dual G5 PPC
Python version 2.5.2 (r252:6091
On Aug 15, 2008, at 4:38 PM, Pauli Virtanen wrote:
> I think you can still do something evil, like this:
>
> import os
> if os.environ.get('NUMPY_VIA_API', '0') != '0':
> from numpy.lib.fromnumeric import *
> ...
>
> But I'm not sure how many milliseconds must be
On Fri, Aug 15, 2008 at 4:21 AM, Jon Wright <[EMAIL PROTECTED]> wrote:
> It seems the new release breaks matplotlib, for those pauvres who are
> using pre-compiled at least. If this means all C-modules compiled
> against numpy have to be recompiled, then this will make me very unhappy.
Yes, the ne
On Thu, Aug 14, 2008 at 3:58 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> Two odd failures in test_print.py.
> Platform: Win XP SP3 on Intel T2600.
> Alan Isaac
>
I got the fixes to make numpy buildable again with VS 2003, and the
errors are mingw specific. Either a compiler bug or more likely a
Fri, 15 Aug 2008 15:30:20 +0200, Gael Varoquaux wrote:
> On Fri, Aug 15, 2008 at 02:59:43AM -0500, Stéfan van der Walt wrote:
[clip]
>> 1) Expose a new interface to numpy, called numpy.api 2) If a certain
>> environment variable is set, the numpy namespace is not populated, and
>> numpy.api becomes
On Fri, Aug 15, 2008 at 02:59:43AM -0500, Stéfan van der Walt wrote:
> 2008/8/15 Robert Kern <[EMAIL PROTECTED]>:
> > The devil is in the details. What exactly do you propose? When we
> > discussed this last time, the participants more or less agreed that
> > environment variables could cause more
Jarrod Millman wrote:
> Hey,
>
> NumPy 1.2.0b2 is now available. Please test this so that we can
> uncover any problems ASAP.
>
> Windows binary:
> http://www.enthought.com/~gvaroquaux/numpy-1.2.0b2-win32.zip
>
Hello Again,
It seems the new release breaks matplotlib, for those pauvres who ar
2008/8/15 Robert Kern <[EMAIL PROTECTED]>:
> I'm afraid that I still don't understand. Please expand on the
Sorry, it's late. My explanation is probably not too lucid.
The variable should rather read something like NUMPY_VIA_API, but here goes.
> 1) NUMPY_FAST_IMPORT=0 (or simply absent)
> i
On Fri, Aug 15, 2008 at 02:59, Stéfan van der Walt <[EMAIL PROTECTED]> wrote:
> 2008/8/15 Robert Kern <[EMAIL PROTECTED]>:
>> The devil is in the details. What exactly do you propose? When we
>> discussed this last time, the participants more or less agreed that
>> environment variables could cause
2008/8/15 Robert Kern <[EMAIL PROTECTED]>:
> The devil is in the details. What exactly do you propose? When we
> discussed this last time, the participants more or less agreed that
> environment variables could cause more fragility than they're worth.
> It also breaks the first time you try to impo
On Fri, Aug 15, 2008 at 02:30, Stéfan van der Walt <[EMAIL PROTECTED]> wrote:
> 2008/8/15 Travis E. Oliphant <[EMAIL PROTECTED]>:
>> So, what is the attitude of people here? Here's my take:
>
> I wonder if we are going about this process the right way. We will
> forever be adjusting imports to i
2008/8/15 Travis E. Oliphant <[EMAIL PROTECTED]>:
> So, what is the attitude of people here? Here's my take:
I wonder if we are going about this process the right way. We will
forever be adjusting imports to improve load times. Why don't we
provide an alternate API, something like numpy.api fr
On Aug 15, 2008, at 9:00 AM, Travis E. Oliphant wrote:
> 5) The testing code seems like a lot of duplication to save .01
> seconds
Personally I want to get rid of all in-body test code
and use nosetests or something similar. I know that's
not going to happen at the very least because I was
told
Andrew Dalke wrote:
> On Aug 14, 2008, at 11:07 PM, Alan G Isaac wrote:
>
>> Btw, numpy loads noticeably faster.
>>
>
>
> Any chance of someone reviewing my suggestions for
> making the import somewhat faster still?
>
>http://scipy.org/scipy/numpy/ticket/874
>
>
So, what is the attit
On Aug 14, 2008, at 11:07 PM, Alan G Isaac wrote:
> Btw, numpy loads noticeably faster.
Any chance of someone reviewing my suggestions for
making the import somewhat faster still?
http://scipy.org/scipy/numpy/ticket/874
Andrew
>> is it really necessary to label these dmg's for 10.5 only?
> No. This is done automatically by the tool used to build the mpkg.
> I'll look at changing this to 10.4, thanks for the reminder.
If the dmg name is generated from the distribution name that the
python distutils makes (e.g. macosx-
On Thu, Aug 14, 2008 at 6:45 PM, Les Schaffer <[EMAIL PROTECTED]> wrote:
> is it really necessary to label these dmg's for 10.5 only?
No. This is done automatically by the tool used to build the mpkg.
I'll look at changing this to 10.4, thanks for the reminder.
> will this dmg install on 10.4 if
Jarrod Millman wrote:
> Mac binary:
> https://cirl.berkeley.edu/numpy/numpy-1.2.0b2-py2.5-macosx10.5.dmg
>
is it really necessary to label these dmg's for 10.5 only? i assume more
than myself run 10.4 but have python 2.5.X installed on their machine.
will this dmg install on 10.4 if py2.5 i
Jarrod Millman wrote:
> Hey,
>
> NumPy 1.2.0b2 is now available. Please test this so that we can
> uncover any problems ASAP.
>
> Windows binary:
> http://www.enthought.com/~gvaroquaux/numpy-1.2.0b2-win32.zip
>
As well as the ones from Alan, if you add the "-O" for optimise flag to
your pytho
Btw, numpy loads noticeably faster.
Alan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Two odd failures in test_print.py.
Platform: Win XP SP3 on Intel T2600.
Alan Isaac
>>> np.test()
Running unit tests for numpy
NumPy version 1.2.0b2
NumPy is installed in C:\Python25\lib\site-packages\numpy
Python version 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32
bit (Intel)]
nose
Hey,
NumPy 1.2.0b2 is now available. Please test this so that we can
uncover any problems ASAP.
SVN tag:
http://svn.scipy.org/svn/numpy/tags/1.2.0b2
Mac binary:
https://cirl.berkeley.edu/numpy/numpy-1.2.0b2-py2.5-macosx10.5.dmg
Windows binary:
http://www.enthought.com/~gvaroquaux/numpy-1.2.0b2
40 matches
Mail list logo
