On Fri, Apr 4, 2008 at 3:31 PM, Anne Archibald <[EMAIL PROTECTED]>
wrote:
> On 04/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> > On Fri, 4 Apr 2008, Gael Varoquaux apparently wrote:
> > > I really thing numpy should be as thin as possible, so
> > > that you can really say that it is only a
On 04/04/2008, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> On Fri, 4 Apr 2008, Gael Varoquaux apparently wrote:
> > I really thing numpy should be as thin as possible, so
> > that you can really say that it is only an array
> > manipulation package. This will also make it easier to
> > sell as a
On 16 Nov 2007, at 1:46 AM, Michael McNeil Forbes wrote:
> On 15 Nov 2007, at 8:23 PM, David Cournapeau wrote:
>
>> Could you try without atlas ? Also, how did you configure atlas when
>> building it ? It seems that atlas is definitely part of the problem
>> (everybody having the problem does use a
Nicolas Bigaouette wrote:
> So the next step would be to only read the needed data from the binary
> file...
You've gotten some suggestions, but another option is to use file.seek(0
to get where your data is, and numpy.fromfile() from there.
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
E
On Fri, Apr 4, 2008 at 9:49 AM, Travis E. Oliphant
<[EMAIL PROTECTED]> wrote:
> However, if clearly better interfaces can be discovered, then we could
> change it. For now, the functions are not imported into the numpy
> namespace but live in
>
> numpy.lib.financial
>
> I could see a future
On Fri, Apr 4, 2008 at 12:47 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 4, 2008 at 9:56 AM, Will Lee <[EMAIL PROTECTED]> wrote:
> > I understand the implication for the floating point comparison and the
> need
> > for allclose. However, I think in a doctest context, this behavior
>
On Fri, Apr 04, 2008 at 04:29:03PM -0400, Alan Isaac wrote:
> > import numpy as N
> > import numpy.math as N.M
> > import numpy.trig as N.T
> > import numpy.stat as N.S
> > ...
> > c = (N.T.sin(b) + N.M.exp(d)) / N.S.mean(g)
> I try to think of my students in such an environment.
> Frig
On Fri, 04 Apr 2008, Joe Harrington wrote:
> Wouldn't you rather do:
> import numpy as N
> ...
> c = (N.sin(b) + N.exp(d)) / N.mean(g)
> rather than:
> import numpy as N
> import numpy.math as N.M
> import numpy.trig as N.T
> import numpy.stat as N.S
> ...
> c = (N.T.sin(b) + N.M.exp(
Robert Kern wrote:
> On Fri, Apr 4, 2008 at 9:56 AM, Will Lee <[EMAIL PROTECTED]> wrote:
>
>> I understand the implication for the floating point comparison and the need
>> for allclose. However, I think in a doctest context, this behavior makes
>> the doc much harder to read.
>>
>
> Tabli
On Fri, Apr 4, 2008 at 9:56 AM, Will Lee <[EMAIL PROTECTED]> wrote:
> I understand the implication for the floating point comparison and the need
> for allclose. However, I think in a doctest context, this behavior makes
> the doc much harder to read.
Tabling the issue of the fact that we changed
Every once in a while the issue of how to split things into packages
comes up. In '04, I think, we had such a discussion regarding scipy
(with Numeric as its base at the time). One idea was a
core-plus-many-modules approach. We could then have metapackages that
just consisted of dependencies and
On Thu, 3 Apr 2008 23:02:24 -0700 (PDT)
harryos <[EMAIL PROTECTED]> wrote:
> i have a 1 dim numpy array
> D=array( [[ 3. , 2. , 1. , 4. , 5. , 1.5, 2.2]] )
> i need to get this sorted in descending order and then
>access the
> elements .
> D.sort() will make D as [[ 1. 1.5 2. 2.2 3.
Hi,
We are seeing the following error on both Solaris and Mac PPC when
running the numpy unittests:
On 04/04/2008, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
> Hey Anne,
>
> Do you currently have SVN access? Would you like it?
>
> I think the SciPy/NumPy sprint would be a good time to clean-up the
> committers list and add new people interested in helping.
I don't have SVN access. I'd b
Hi Tim,
Look at the thread posted a couple of weeks ago named: loadtxt and missing
values
I'm guessing you'll find answers to your questions, if not, don't hesitate
to ask.
David
2008/4/3, Tim Michelsen <[EMAIL PROTECTED]>:
>
> Hello!
>
> How can I load a data file (e.g. CSV, DAT) in ASCII whi
On Fri, Apr 4, 2008 at 10:17 AM, Joris De Ridder <
[EMAIL PROTECTED]> wrote:
>
> On 04 Apr 2008, at 16:11, Travis E. Oliphant wrote:
>
> >
> > There are only two reasons that I can think of right now to keep
> > them in
> > NumPy instead of moving them to SciPy.
> >
> > 1) These are "basic" funct
On 04 Apr 2008, at 16:11, Travis E. Oliphant wrote:
>
> There are only two reasons that I can think of right now to keep
> them in
> NumPy instead of moving them to SciPy.
>
> 1) These are "basic" functions and a scipy toolkit would contain
> much more.
Isn't this something you want to avoi
-1 for any functions added to numpy.
As only an end-user, I realize I have little right to a say in these
sorts of issues, but for whatever it may be worth, I strongly agree
with Gael's viewpoint. We should be aiming towards modular systems for
function distribution, and now that it seems that the
On Fri, 4 Apr 2008, Gael Varoquaux apparently wrote:
> I really thing numpy should be as thin as possible, so
> that you can really say that it is only an array
> manipulation package. This will also make it easier to
> sell as a core package for developpers who do not care
> about "calculator"
+1 for simple financial functions in numpy, and congrats that it's on
OLPC! If we have an FFT in numpy, we should have an internal rate of
return. Anyone with investments needs that, and that's more people
than those needing an FFT.
I agree that Excel will bring in the most familiarity, but thei
On Fri, Apr 04, 2008 at 09:11:37AM -0500, Travis E. Oliphant wrote:
> There are only two reasons that I can think of right now to keep them in
> NumPy instead of moving them to SciPy.
> 1) These are "basic" functions and a scipy toolkit would contain much more.
> 2) These are widely used and wou
A Friday 04 April 2008, Travis E. Oliphant escrigué:
> Sebastian Haase wrote:
> > Hi Travis,
> > This sounds of course very interesting, but could you elaborate on
> > the reasoning why this should not rather be "only" in SciPy !? I
> > thought many people think that numpy was already too crowded a
I understand the implication for the floating point comparison and the need
for allclose. However, I think in a doctest context, this behavior makes
the doc much harder to read. For example, if you have this in your doctest:
def doSomething(a):
'''
>>> print doSomething(0.0011)[0]
>>
Hi,
Note that at least under Python 2.5.1:
>>> a=0.0012
>>> a
0.0011999
>>> str(a)
'0.0012'
>>> repr(a)
'0.0011999'
From Python docs, repr(): 'Return a string containing a printable
representation of an object' and str(): 'Return a nice string
representation of the o
Sebastian Haase wrote:
> Hi Travis,
> This sounds of course very interesting, but could you elaborate on the
> reasoning why this should not rather be "only" in SciPy !?
> I thought many people think that numpy was already too crowded and
> should concentrate mostly on being a basic array handling
Sebastian Haase wrote:
> Hi Travis,
> This sounds of course very interesting, but could you elaborate on the
> reasoning why this should not rather be "only" in SciPy !?
> I thought many people think that numpy was already too crowded and
> should concentrate mostly on being a basic array handling
On Fri, Apr 04, 2008 at 03:58:39PM +0200, Sebastian Haase wrote:
> This sounds of course very interesting, but could you elaborate on the
> reasoning why this should not rather be "only" in SciPy !?
> I thought many people think that numpy was already too crowded and
> should concentrate mostly on
Hi Travis,
This sounds of course very interesting, but could you elaborate on the
reasoning why this should not rather be "only" in SciPy !?
I thought many people think that numpy was already too crowded and
should concentrate mostly on being a basic array handling facility.
I'm sure you have a go
Anne Archibald wrote:
> On 04/04/2008, Jarrod Millman <[EMAIL PROTECTED]> wrote:
>
>
>> Since I sent my email last night another 5+ tickets have been closed.
>> If we keep going at this rate, we should be able to release 1.0.5 next
>> Friday (4/11) with every ticket closed. Specifically, than
Bruce Southey wrote:
> Hi,
> This topic has come up many times and the only problem is the lack of
> understanding how computers store numbers and computer numerical precision.
>
> The NumPy output is consistent with Python on my x86_64 linux system
> with Python 2.5.1:
> >>> a=0.0012
> >>> a
>
Hi all,
Last night I put together some simple financial functions based on the
basic ones available in Excel (and on a financial calculator). It seems
to me that NumPy ought to have these basic functions.
There may be some disagreement about what to call them and what the
interface should be
Hi,
This topic has come up many times and the only problem is the lack of
understanding how computers store numbers and computer numerical precision.
The NumPy output is consistent with Python on my x86_64 linux system
with Python 2.5.1:
>>> a=0.0012
>>> a
0.0011999
Simply put, in
On 04/04/2008, Jarrod Millman <[EMAIL PROTECTED]> wrote:
> Since I sent my email last night another 5+ tickets have been closed.
> If we keep going at this rate, we should be able to release 1.0.5 next
> Friday (4/11) with every ticket closed. Specifically, thanks to
> Travis Oliphant, David H
Hi Will
On 03/04/2008, Will Lee <[EMAIL PROTECTED]> wrote:
> I seem to have problem with floating point printing with the latest numpy,
> python 2.5.2, gcc 4.1.4, and 64-bit linux:
>
> In [24]: print str(0.0012)
> 0.0012
>
> In [25]: a = numpy.array([0.0012])
>
> In [26]: print str(a[0])
> 0.0011
On Fri, Apr 4, 2008 at 11:33 AM, Jarrod Millman <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 4, 2008 at 1:50 AM, Sebastian Haase <[EMAIL PROTECTED]> wrote:
> > Hi,
> > Accidentally I'm exactly trying to do the same thing right now .
> >
> > What is the best way of memmapping into a file that
result = (egimgs.T * eval.flat).T
or, in place
E = egimgs.T
E *= eval.flat
(egimgs would updated)
Nadav.
-הודעה מקורית-
מאת: [EMAIL PROTECTED] בשם wilson
נשלח: ו 04-אפריל-08 08:58
אל: numpy-discussion@scipy.org
נושא: [Numpy-discussion] multiply array
hello
i have two arrays
#of sh
On Fri, Apr 4, 2008 at 1:50 AM, Sebastian Haase <[EMAIL PROTECTED]> wrote:
> Hi,
> Accidentally I'm exactly trying to do the same thing right now .
>
> What is the best way of memmapping into a file that is already open !?
>
> I have to read some text (header info) off the beginning of the
On Fri, Apr 4, 2008 at 2:14 AM, Nicolas Bigaouette
<[EMAIL PROTECTED]> wrote:
> 2008/4/3, Robert Kern <[EMAIL PROTECTED]>:
>
> > On Thu, Apr 3, 2008 at 6:53 PM, Nicolas Bigaouette
> > <[EMAIL PROTECTED]> wrote:
> > > Thanx for the fast response Robert ;)
> > >
> > > I changed my code to use the sli
Hello,
I have just organized a little NumPy/SciPy mini-sprint for next week.
David Cournapeau is visiting me for a week and several other
developers (Eric Jones, Robert Kern, Peter Wang, Jonathan Taylor, and
Karl Young) will be stopping by during the week to work with the
Berkeley team (Fernando P
> #of shape (1,6)
> eval=array([[3.,3.2,1.,1.1,5.,0.5]])
>
eval.shape=(-1,)
please not the correction..i need to multiply first row of egimgs with
3.0 ,second row with 3.2,last(sixth) row with 0.5 ..For that
purpose i made the above into a 1 dimensional array.
A for loop seems inefficient in
On Wed, Apr 2, 2008 at 9:36 PM, Jarrod Millman <[EMAIL PROTECTED]> wrote:
> Again, if you have any time to help close tickets or improve
> documentation, please take the time over the next few days to do so.
> And thank you to everyone who has been working to get this release
> ready!
Since I
41 matches
Mail list logo
