On 01/29/2015 09:58 AM, Chris Barker wrote:
> > I was thinking elapsed time. Nanoseconds can be rather crude for that
> > depending on the measurement.
>
> Wouldn't the user just keep elapsed time as a
> count, or floating point number, in whatever units the instrument spits
>
Hi All,
So I have a need to use longdouble numpy scalars in an application, and
I need to be able to reliably set long-double precision values in them.
Currently I don't see an easy way to do that. For example:
In [19]: numpy.longdouble("1.12345678901234567890")
Out[19]: 1.123456789012345691
On 05/10/2012 02:23 PM, Chris Barker wrote:
> On Thu, May 10, 2012 at 2:38 AM, Dag Sverre Seljebotn
> wrote:
>> What would serve me? I use NumPy as a glorified "double*".
>
>> all I want is my glorified
>> "double*". I'm probably not a representative user.)
>
> Actually, I think you are represent
On 10/23/2011 04:07 PM, Robert Kern wrote:
> On Sun, Oct 23, 2011 at 20:58, Matthew Brett wrote:
>> Hi,
>>
>> On Sun, Oct 23, 2011 at 12:53 PM, Charles R Harris
>> wrote:
>>>
>>>
>>> On Sun, Oct 23, 2011 at 12:54 PM, Matthew Brett
>>> wrote:
Hi,
On Sun, Oct 23, 2011 at 11:21
If you use already vectorized functions (like special.iv) you often don't
need to use vectorization()
For example:
-
import numpy as num
import scipy.special as special
def funct(order, t, power):
return special.iv(order, t)**power
order = num.arange(4.0)
ts = n
I have an updated version of ppgplot.c as part of a larger astronomical
package. You can get the ppgplot code here:
http://github.com/scottransom/presto/tree/master/python/ppgplot_src/
Scott
On Monday, June 21, 2010 12:32:37 pm Jun Liu wrote:
> follow http://www.dur.ac.uk/physics.astrolab/ppgp
On Wed, Dec 09, 2009 at 05:54:07PM -0800, Dr. Phillip M. Feldman wrote:
>
> Pauli Virtanen-3 wrote:
> >
> > Nevertheless, I can't really regard dropping the imaginary part a
> > significant issue.
> >
>
> I am amazed that anyone could say this. For anyone who works with Fourier
> transforms, o
Me too.
S
On Wednesday 15 October 2008 11:31:44 am Paul Barrett wrote:
> I'm behind Travis on this one.
>
> -- Paul
>
> On Wed, Oct 15, 2008 at 11:19 AM, David Cournapeau
<[EMAIL PROTECTED]> wrote:
> > On Wed, Oct 15, 2008 at 11:45 PM, Travis E. Oliphant
> >
> > <[EMAIL PROTECTED]> wrote:
> >>
On Tue, Aug 19, 2008 at 01:57:20AM +0200, Andrew Dalke wrote:
> BTW, it's *fun* to modify an existing language and
> afterwards it you know a secret - that programming
> languages are just flimsy facades held together by
> a shared hallucination. Like in a dream, change
> things too much or leave
On Thu, Jul 31, 2008 at 07:46:20AM -0500, Nathan Bell wrote:
> On Thu, Jul 31, 2008 at 7:31 AM, Hanni Ali <[EMAIL PROTECTED]> wrote:
> >
> > I would just to highlight an alternate use of numpy to interactive use. We
> > have a cluster of machines which process tasks on an individual basis where
> >
On Wednesday 28 May 2008 10:51:20 am Alan McIntyre wrote:
> On Wed, May 28, 2008 at 10:30 AM, Keith Goodman <[EMAIL PROTECTED]>
wrote:
> > Does anyone else get this seg fault?
> >
> >>> def fn():
> >
> >x = np.random.rand(5,2)
> >x.cumsum(None, out=x)
> >return x
> >
> > :
> >>>
Hmmm. Interesting. I'm on a 64-bit Debian Unstable system with numpy
1.0.4 and python 2.5.2 and I don't get this:
In [1]: import numpy as np
In [2]: np.__version__
Out[2]: '1.0.4'
In [3]: def fn():
...: x = np.random.rand(5,2)
...: x.cumsum(None, out=x)
...: return x
.
Hi David et al,
Very interesting. I thought that the 64-bit gcc's automatically
aligned memory on 16-bit (or 32-bit) boundaries. But apparently
not. Because running your code certainly made the intrinsic code
quite a bit faster. However, another thing that I noticed was
that the "simple" code
Here are results under 64-bit linux using gcc-4.3 (which by
default turns on the various sse flags). Note that -O3 is
significantly better than -O2 for the "simple" calls:
nimrod:~$ cat /proc/cpuinfo | grep "model name" | head -1
model name : Intel(R) Xeon(R) CPU E5450 @ 3.00GHz
On Sat, Mar 15, 2008 at 07:33:51PM -0400, Anne Archibald wrote:
> ...
> To answer the OP's question, there is a relatively small number of C
> inner loops that could be marked up with OpenMP #pragmas to cover most
> matrix operations. Matrix linear algebra is a separate question, since
> numpy/scip
. Code (like mine) that depended on an exception being
thrown at EOF will break. I've fixed my code, but this could bite
others.
Thanks for the prompt fix.
Scott
On Sun, Mar 02, 2008 at 10:36:05AM -0600, Travis E. Oliphant wrote:
> Scott Ransom wrote:
> >
> >
> > Seem
Hi All,
So I've just come upon a new(ish?) bug in fromfile. I'm running
numpy from subversion rev 4839.
Seems that if you try to read a number of items from a binary file
but none are read (i.e. you are already at the EOF), you get the
following:
4096 items requested but only 0 read
*** glibc d
On Wednesday 13 February 2008 02:37:37 pm Francesc Altet wrote:
> So, I'd say that the guilty is the gcc 4.2.1, 64-bit (or at very
> least, AMD Opteron architecture) and that newqsort performs really
> well in general (provided that the compiler can find the best path
> for optimizing its code). A
On a side note, given that I've seen quite a few posts about
vectorize() over the past several months...
I've written hundreds or thousands of functions that are intended
to work with numeric/numpy arrays and/or scalars and I've _never_
(not once!) found a need for the vectorize function. Python'
On Monday 07 January 2008 02:13:56 pm Charles R Harris wrote:
> On Jan 7, 2008 12:00 PM, Travis E. Oliphant <[EMAIL PROTECTED]>
wrote:
> > Charles R Harris wrote:
> > > Hi All,
> > >
> > > I'm thinking that one way to make the automatic type conversion a
> > > bit safer to use would be to add a CA
On Fri, Jan 04, 2008 at 04:31:53PM -0700, Timothy Hochberg wrote:
> On Jan 4, 2008 3:28 PM, Scott Ransom <[EMAIL PROTECTED]> wrote:
>
> > On Friday 04 January 2008 05:17:56 pm Stuart Brorson wrote:
> > > >> I realize NumPy != Matlab, but I'd wager that most u
On Friday 04 January 2008 05:17:56 pm Stuart Brorson wrote:
> >> I realize NumPy != Matlab, but I'd wager that most users would
> >> think that this is the natural behavior..
> >
> > Well, that behavior won't happen. We won't mutate the dtype of the
> > array because of assignment. Matlab has c
Hmmm. When I try to load:
http://planet.scipy.org/
I get: "Unknown host planet.scipy.org"
However, http://planet.scipy.org (without the final slash)
resolves fine.
Scott
On Wed, Jan 02, 2008 at 04:45:36PM +0200, Albert Strasheim wrote:
> Hello
>
> I also seem to be experiencing this probl
> What are people's opinions about the value of NumPy and SciPy on the
> CLR?
As someone who uses Numpy/Scipy almost exclusively on Linux workstations
or on clusters (in coordination with lots of C code), I wouldn't value
NumPy and SciPy on the CLR at all.
I am kind of curious, though, to see
On a 64-bit Intel Core2 Duo running Debian unstable with atlas3 (there
is no specific atlas3-sse2 for AMD64 Debian, although I think that it
is included) everything checks out fine:
eiger:~$ uname -a
Linux eiger 2.6.18-3-amd64 #1 SMP Sun Dec 10 19:57:44 CET 2006 x86_64
GNU/Linux
eiger:~$ cat /
25 matches
Mail list logo
