On Sat, 14 May 2011 09:45:12 -0600, Charles R Harris wrote:
[clip]
> These are generated by the .. autosummary:: command, so the error
> probably lies there.
The problem is that the signature of these routines is written as
remainder(x1, x2[, out])
and not as
remainder(x1, x2, o
On Sun, 15 May 2011 10:32:17 +0200, Ralf Gommers wrote:
>> OK, the format for that part of the signature is in line 4910 in
>> ufunc_object.c. The question is, which should we fix, the format or the
>> autosummary?
>
> The format please. That [, out] never made sense to me.
The problem here is tha
Wed, 18 May 2011 07:39:18 -0400, Neal Becker wrote:
> The file is pickle saved on i386 and loaded on x86_64. It contains a
> numpy array (amoungst other things).
>
> On load it says:
>
> RuntimeError: invalid signature
There's no such message in Numpy source code, so the error does
not come dir
On Wed, 18 May 2011 15:09:31 -0700, G Jones wrote:
[clip]
> import numpy as np
>
> x = np.memmap('mybigfile.bin',mode='r',dtype='uint8') print x.shape #
> prints (42940071360,) in my case ndat = x.shape[0]
> for k in range(1000):
> y = x[k*ndat/1000:(k+1)*ndat/1000].astype('float32') #The ast
these issues.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
hange intentional, or should I file a bug? I couldn't find
> any reference to it in the changelog or release notes.
Looks like a bug -- the change was not intentional.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Tue, 24 May 2011 11:41:28 +0200, Jan Wuyts wrote:
>bmidata=np.asarray([x for x in data if x['paramname']=='bmi'],
> dtype=data.dtype)
Use indexing:
bmidata = data[data['paramname'] == 'bmi']
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.
continued in 2005.
You can find it here:
http://sourceforge.net/projects/numpy/files/Old%20Numeric/24.2/
No pre-made binaries for Python 2.7, for obvious reasons, however.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
he same error, you can try asking the Scienomics support
how to have another Python version installed at the same time as their
product.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
. After
saving the edit, click this new link to create the new page.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Fri, 27 May 2011 21:06:45 +0300, Talla wrote:
[clip: AbinitBandStructuremaker.py]
FYI: try getting a newer version of the abinit software from abinit.org
They seem to have an updated version of this particular script
in their source package.
Any further discussion should probably go to their for
Tue, 31 May 2011 11:44:15 -0500, Mark Wiebe wrote:
[clip]
>> I find very commendable to strive for consistency, mind you. I'm just
>> not not very comfortable with the idea of modifying old records a
>> posteriori to adjust to new policies...
>
> I was under the impression this already was the pol
o do with
science, I'm sure nobody will object to its existence.
Naming your package scikits.something may give it a small
boost in visibility, but apart from that, it's just an ordinary
Python package.
--
Pauli Virtanen
___
NumPy-Discussion ma
s, so it's not so easy to make
one point to another. Maybe they can be memcpy'd to make aliases,
although that sounds dirty...
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, 10 Jun 2011 18:51:14 -0700, Keith Goodman wrote:
[clip]
> Maybe this is the same question, but are you maybe yes, maybe no on this
> too:
>
> >>> type(np.sum([1, 2, 3], dtype=np.int32)) == np.int32
> False
Note that this is a comparison between two Python types...
> Ben, what hap
On Mon, 13 Jun 2011 11:08:18 -0500, Bruce Southey wrote:
[clip]
> OSError:
> /usr/local/lib/python3.2/site-packages/numpy/core/multiarray.pyd: cannot
> open shared object file: No such file or directory
I think that's a result of Python 3.2 changing the extension module
file naming scheme (IIRC to
On Tue, 14 Jun 2011 15:37:36 -0500, Mark Wiebe wrote:
[clip]
> It would be nice to get a fix to this newly reported regression in:
>
> http://projects.scipy.org/numpy/ticket/1867
I see that regression only in master, not in 1.6.x, so I don't think
it will delay 1.6.1.
Pauli
On Fri, 17 Jun 2011 15:39:21 -0500, Robert Kern wrote:
[clip]
>> File
>> "/home/bvr/Programs/scipy/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py",
>> line 378 in test_ticket_1459_arpack_crash
>
> Well, if it's testing that it crashes, test passed!
>
> Here is the referenced ticket and the
Tue, 21 Jun 2011 16:43:13 -0500, Mark Wiebe wrote:
[clip: __array_wrap__]
> Those could stay as they are, and just the ufunc usage of __array_wrap__
> can be deprecated. For classes which currently use __array_wrap__, they
> would just need to also implement _numpy_ufunc_ to eliminate any
> depreca
Hi,
Fri, 01 Jul 2011 16:45:47 +0200, Marc Labadens wrote:
> I am trying to interface some python code using numpy array with some C
> code.
You can read:
http://docs.scipy.org/doc/numpy/user/c-info.how-to-extend.html#writing-an-extension-module
However, using Cython often saves you from writing
Sat, 16 Jul 2011 12:42:36 +0200, Stefan Krah wrote:
> x = ndarray(buffer=bytearray([1,2,3,4,5,6,7,8,9,10]),
> shape=[10], strides=[-1], dtype="B", offset=9)
[clip]
> I do not understand the PyBUF_SIMPLE result. According to the C-API docs
> a consumer would be allowed to access buf[9],
Tue, 19 Jul 2011 11:05:18 +0200, Carlos Becker wrote:
> Hi, I started with numpy a few days ago. I was timing some array
> operations and found that numpy takes 3 or 4 times longer than Matlab on
> a simple array-minus-scalar operation.
> This looks as if there is a lack of vectorization, even thou
On Tue, 19 Jul 2011 17:49:14 +0200, Carlos Becker wrote:
> I made more tests with the same operation, restricting Matlab to use a
> single processing unit. I got:
>
> - Matlab: 0.0063 sec avg
> - Numpy: 0.026 sec avg
> - Numpy with weave.blitz: 0.0041
To check if it's an issue with building witho
ng on -- on my machine, the Numpy operation
runs exactly at the same speed as C, so this issue must have
a platform-dependent explanation.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Tue, 19 Jul 2011 21:55:28 +0200, Ralf Gommers wrote:
> On Sun, Jul 17, 2011 at 11:48 PM, Darren Dale
> wrote:
>> In numpy.distutils.system info:
>>
>>default_x11_lib_dirs = libpaths(['/usr/X11R6/lib','/usr/X11/lib',
>> '/usr/lib'], platform_bits)
>>defau
location, how come I get the same speed
as an equivalent C implementation, which *does* pre-allocation, using
exactly the same benchmark codes as you have posted?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail
Wed, 20 Jul 2011 09:04:09 +, Pauli Virtanen wrote:
> Wed, 20 Jul 2011 08:49:21 +0200, Carlos Becker wrote:
>> Those are very interesting examples. I think that pre-allocation is
>> very important, and something similar happens in Matlab if no
>> pre-allocation is done:
Wed, 20 Jul 2011 09:04:09 +, Pauli Virtanen wrote:
> Wed, 20 Jul 2011 08:49:21 +0200, Carlos Becker wrote:
>> Those are very interesting examples. I think that pre-allocation is
>> very important, and something similar happens in Matlab if no
>> pre-allocation is done:
Wed, 20 Jul 2011 11:31:41 +, Pauli Virtanen wrote:
[clip]
> There is a sharp order-of-magnitude change of speed in malloc+memset of
> an array, which is not present in memset itself. (This is then also
> reflected in the Numpy performance -- floating point operations probably
> don
hing obvious?
Cython doesn't vectorize the slice operations such as
b[:,j-g]
but falls back to Numpy on them. You'll need to convert the slice
notation to a loop to get speed gains.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumP
Fri, 29 Jul 2011 10:52:12 +0200, Yoshi Rokuko wrote:
[clip]
A, B = mod.meth(C, prob=.95)
>
> is ith possible to return two arrays?
The way to do this in Python is to build a tuple with
Py_BuildValue("OO", A, B) and return that.
___
NumPy-Discussi
the warnings
module,
warnings.simplefilter("ignore", RuntimeWarning)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Sat, 13 Aug 2011 18:14:11 +0200, Ralf Gommers wrote:
[clip]
> We should check if there's still any code in SVN branches that is
> useful.
> If so the people who are interested in it should move it somewhere else.
> Anyone?
All the SVN branches are available in Git, though some are hidden. Do
Sat, 13 Aug 2011 22:00:33 -0400, josef.pktd wrote:
[clip]
> Does Trac require svn access to dig out old information? for example
> links to old changesets, annotate/blame, ... ?
It does not require HTTP access to SVN, as it looks directly at the
SVN repo on the local disk.
It also probably doesn'
Fri, 19 Aug 2011 12:48:29 +0200, Ralf Gommers wrote:
[clip]
> Hi Ognen,
>
> Could you please disable http access to numpy and scipy svn?
Turns out also I had enough permissions to disable this. Now:
$ svn co http://svn.scipy.org/svn/numpy/trunk numpy
svn: Repository moved permanently to 'http://
specified number of lines instead of a number of bytes?
First use standard Python I/O functions to determine the number of
bytes to skip at the beginning and the number of data items. Then pass
in `offset` and `shape` parameters to numpy.memmap.
-
consider heavy-weighedness is distribution:
does your target audience have these libraries already installed
(they are pre-installed in several Python-for-science distributions),
and how difficult would it be for you to ship them with your stuff,
or to require the users to install them.
--
Pa
Hey,
Sat, 27 Aug 2011 12:28:14 +0200, David Cournapeau wrote:
> I am finally at a stage where bento can do most of what numscons could
> do. I would rather avoid having 3 different set of build scripts
> (distutils+bento+numscons) to maintain in the long term, so I would
> favor removing numscons
certain matrix
is singular in exact arithmetic, for a computer it may still be
invertible (by a given algorithm). This type of things are not
unusual in floating-point computations.
The matrix condition number (`np.linalg.cond`) is a better measure
of whether a matrix is invertible or not.
Wed, 07 Sep 2011 12:52:44 -0700, Chris.Barker wrote:
[clip]
> In [9]: temp['x'] = 3
>
> In [10]: temp['y'] = 4
>
> In [11]: temp['z'] = 5
[clip]
> maybe it wouldn't be any faster, but with re-using temp, and one less
> list-tuple conversion, and fewer python type to numpy type conversions,
> mayb
Sun, 11 Sep 2011 03:03:26 -0500, Pengkui Luo wrote:
[clip]
> However, converting a large sparse matrix to dense would easily eat up
> the memory. Is there a way for np.sign (as well as other ufunc) to take
> a sparse matrix as parameter, and return a sparse matrix?
For CSR, CSC, and DIA you can do
Thu, 22 Sep 2011 08:12:12 +0200, Han Genuit wrote:
[clip]
> I also noticed that it does strange things when using a list:
>
c[[True, False, True]]
> array([[3, 4, 5],
>[0, 1, 2],
>[3, 4, 5]])
It casts the list with booleans to an integer array. Probably shouldn't
work like t
Hi,
Thu, 22 Sep 2011 13:09:51 +0200, Marijn Verkerk wrote:
[clip]
> ImportError: libptf77blas.so.3: cannot open shared object file: No such
> file or directory
>
> In the __config.py file the folder where libptf77 should be is present.
>
> Any suggestions?
You need to make the dynamic linker ab
On Fri, 23 Sep 2011 11:57:15 -0600, Charles R Harris wrote:
[clip]
> We're falling behind. The real world is impacting hard at the moment.
> Matthew's suggestion is a good one.
Should we stop recommending using Trac for contributions, and just
say "use git"? (I think we recommend it somewhere.)
I
be a string or open file
> **
Yes, this is a known shortcoming of .tofile().
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
mpy is kept intentionally bare-bones.
There is one question, though: your qrupdate code is licensed under the
GPL. To include it in Scipy, we need to have it distributable under a
BSD-compatible license. Would you be willing to relicense it?
--
Pauli Virtanen
___
# ye mighty FORTRAN, we beseech thee
for j, word in enumerate(words):
i = np.arange(len(word))
canvas[i+j, 2*i] = list(word)
canvas[:,-1] = '\n'
return canvas.tostring().rstrip()
--
Pauli Virtanen
___
NumPy-Disc
10.10.2011 23:02, Jesper Larsen kirjoitti:
> Hi numpy-users
>
> I have a 2d array of shape (ny, nx). I want to broadcast (copy) this
> array to a target array of shape (nt, nz, ny, nz) or (nt, ny, nx) so
> that the 2d array is repeated for each t and z index (corresponding to
> nt and nz). I am not
eformulate the problem so that it can be vectorized. Without knowing
more about the actual algorithm you are trying to implement, it's not
easy to give more detailed help.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
pe is known in
> advance, but this is not very efficient as all the lattice points inside
> the bounding box are checked.
The only way to vectorize this I see is to do write the floodfill
algorithm on rectangular supercells, so that the constant costs are
amortized. Sounds
guration --- the one with the letter 'i' in it on the upper right
corner of the page.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
sk] = b[mask]
> TypeError: array cannot be safely cast to required type
Seems to be fixed in Git master
>>> import numpy as np
>>> a = np.arange(10)
>>> b = np.ones(10, dtype=np.uint8)
>>> mask = a < 5
>>> b[mask] = b[mask]
>>> b[mask]
13.10.2011 12:59, Alex van der Spek kirjoitti:
> gives me a confusing result. I only asked to name the columns and change
> their
> types to half precision floats.
Structured arrays shouldn't be thought as an array with named columns,
as they are somewhat different.
> What am I missing? How to
17.10.2011 15:48, josef.p...@gmail.com kirjoitti:
> On Mon, Oct 17, 2011 at 6:17 AM, Pauli Virtanen wrote:
[clip]
>>> What am I missing? How to do this?
>>
>> np.rec.fromarrays(arr.T, dtype=dt)
>
> y.astype(float16).view(dt)
I think this will give surprises if
> somewhere else? Or something else I'm not thinking of? Please help me
> understand.
No, master is supposed to be the integration branch with only finished
stuff in it.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
d results (or explicitly creates masked arrays), but
as far as I understand that's about the same situation as with np.ma.
.. [1] http://docs.scipy.org/doc/numpy/reference/arrays.maskna.html
--
Pauli Virtanen
___
NumPy-Discussion mailing lis
25.10.2011 06:59, Matthew Brett kirjoitti:
> res = np.longdouble(2)**64
> res-1
> 36893488147419103231.0
Can you check if long double works properly (not a given) in C on that
platform:
long double x;
x = powl(2, 64);
x -= 1;
printf("%g %Lg\n", (double)x, x);
or,
* of long doubles that's
broken. Note how the value cast as double prints the correct result,
whereas the %Lg format code gives something wrong.
Can you try to check this by doing something like:
- do some set of calculations using np.longdouble in N
, or in the "cast to doubles
before formatting" one. In the latter case, one would have to maintain a
list of broken C libraries (ugh).
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ime datatypes is not implemented.
There's a faster code path that is triggered for small selection arrays,
and that does not require argsort, and that's why the error occurs in
only some of the cases.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
26.10.2011 10:07, Nathaniel Smith kirjoitti:
> On Tue, Oct 25, 2011 at 4:49 PM, Matthew Brett
> wrote:
>> I guess from your answer that such a warning would be complicated to
>> implement, and if that's the case, I can imagine it would be low
>> priority.
>
> I assume the problem is more that it
f that involved ripping
the innards of Numpy out to a more reusable C library. It's been in a
merge-limbo for some time now, however.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
31.10.2011 09:44, mark florisson kirjoitti:
[clip]
> Ah, that's too bad. Is it anywhere near ready, or was it abandoned for
> ironclad? Could you point me to the code?
It's quite ready and working, and as far as I understand, Enthought is
shipping it. I haven't used it, though.
The code is here:
04.11.2011 17:31, Gary Strangman kirjoitti:
[clip]
> The question does still remain what to do when performing operations like
> those above in IGNORE cases. Perform the operation "underneath"? Or not?
I have a feeling that if you don't start by mathematically defining the
scalar operations first
04.11.2011 19:59, Pauli Virtanen kirjoitti:
[clip]
> This makes inline binary ops
> behave like Nn. Reductions are N. (Assignment: dC, reductions: N, binary
> ops: PX, unary ops: PC, inline binary ops: Nn).
Sorry, inline binary ops are also PdX, not Nn.
--
Pauli
= 99)
>>> x.data
array([5, 2, 3])
Let's call this (since I botched and already reserved the letter "n" :)
(m) mark-ignored
a := SPECIAL_1
# -> a == SPECIAL_a ; the payload of the RHS is neglected,
# the assigned value has the original LHS
#
followed by assignment
>>> x[:] = x + y
as far as the missing values are concerned.
> However, doesn't this have the issue that Nathaniel brought up earlier:
> commutativity
>
> unignore(x + y) != unignore(y + x)
As the definition concerns only what
readability:
Well, np.ma implements "d" semantics, but because of the way binary ops
are noncommutative, in-place binary ops behave as if they were not mutating.
Assignments do actually change the masked data:
>>> a[:] = b
which changes also masked values in `a`. That may b
04.11.2011 23:29, Pauli Virtanen kirjoitti:
[clip]
> As the definition concerns only what happens on assignment, it does not
> have problems with commutativity.
This is of course then not really true in a wider sense, as an example
from "T J" shows:
a = 1
a += IGNORE(3)
# ->
least for me it was not clear before this formulation that
there was a reason why binary ops in np.ma were not commutative! Now I
kind of see that there is an asymmetry in assignment into masked arrays,
and there is a conflict with commuting operations and with "what you'd
expect ignored
roperties of arrays with ignored values?
Is there a real-word need to have (a) be true?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
de.
It seems that having `a += b` have `a[j]` unchanged if it's ignored, and
having ignored values propagate creates the problem.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
expected behavior on assignment, while retaining commutativity, and they
would also behave as expected in reductions. It's a somewhat different
concept from np.ma, but I'm wondering if there would be real-world uses
for tagging values with "this number is not really here, act as
23.11.2011 15:01, Fabrice Silva kirjoitti:
> Hi folks,
> how should I specify a PEP3118 buffer format that could be understand by
> numpy as the following dtype:
>
> dtype = [('t11', '|f8'), ('t22', '|f8'), ('t33', '|f8'),
> ('t23', '|f8'), ('t13', '|f8'), ('t12', '|f8')]
>
> so that I c
y`.
Workarounds: copy-paste the glossary list from `glossary.py` to
`doc/source/glossary.txt` in place of `automodule:: numpy.doc.glossary`
If that doesn't help, then something in the formatting of the glossary
list that makes Sphinx to choke (and it's certainly t
01.12.2011 03:31, josef.p...@gmail.com kirjoitti:
[clip]
> I thought np.dot is Lapack based and favors fortran order, but if the
> second array is fortran ordered, then dot takes twice as long.
It uses C-LAPACK, and will make copies if the arrays are not in C-order.
--
Pauli Vi
--- it does not make sense to explain
basic Numpy concepts in every docstring, especially `axis` and `shape`
are very common.
However, an example with the axis keyword could be useful.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy
If Numpy indeed is linked against MKL (check the build log), then one
possible reason could be different threading options passed to MKL.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
.org/c-api/objbuffer.html .
[clip]
Since Numpy version 1.5, the new buffer protocol is supported.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
> The problem is I don't really know what is supposed to happen if the new
> buffer protocol is supported by some class named say Foo. Could I then
> do
>
> x=Foo([1,2,3])
>
> numpy.array([2,2,2])+x
>
> and such operations?
Yes. You can try it out with Pyt
19.01.2012 18:21, Travis Oliphant kirjoitti:
> I think the problem here is one of delegation and information.
>
> I'm not even sure how the web-pages get updated at this point.
> Does anyone on this list know? I think it would be a great idea
> to move to github pages for the NumPy project at lea
ehavior is not a bug, but a documented feature that has
been around probably already since Numeric.
However, adding a new function could be possible.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/ma
Hi,
06.02.2012 20:41, Ralf Gommers kirjoitti:
[clip]
> I've created https://github.com/scipy/scipy.github.com and gave you
> permissions on that. So with that for the built html and
> https://github.com/scipy/scipy.org-new for the sources, that should do it.
>
> On the numpy org I don't have the
Hi,
08.02.2012 11:22, Scott Sinclair kirjoitti:
[clip]
> I see that you've added the CNAME file. Now numpy.github.com is being
> redirected to numpy.scipy.org (the old site).
>
> As I understand it, whoever controls the scipy.org DNS settings needs
> point numpy.scipy.org at numpy.github.com so t
owever, have the heuristics in place for elementwise operations.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
11.02.2012 20:44, Travis Oliphant kirjoitti:
> How to people feel about moving the issue tracking for NumPy to Github?
>It looks like they have improved their issue tracking quite a bit and
> the workflow and integration with commits looks quite good from what I
> can see.
The lack of attachm
11.02.2012 22:02, Jason Grout kirjoitti:
[clip]
> Are there any good github trac plugins? For example:
>
> http://davglass.lighthouseapp.com/projects/21212/home
>
> http://trac-hacks.org/wiki/GitPlugin (git, not github, but still maybe
> useful)
The Numpy & Scipy Trac is currently running on t
ence/c-api.array.html#import_array
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
t of 3: 4.07 us per loop
I think the linear growth here is expected, as
i = arange(n)
a[i].shape == i.shape
It's probably possible to cut the overhead, though.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi,
15.02.2012 14:59, Ognen Duzlevski kirjoitti:
[clip]
> Alright, it will happen sometime today and I will post a message announcing
> so.
> Ognen
Great! Once you have changed the records, we can adjust [1] the
numpy.github.com page [1] to deal with the new virtual host name.
Thanks,
Pauli
[1
ta alignment, which can affect rounding error.
See http://www.nccs.nasa.gov/images/FloatingPoint_consistency.pdf
That would explain why the pattern you see is quasi-deterministic. The
other explanation would be using uninitialized memory at some point, but
that seems quite unlike
16.02.2012 14:14, josef.p...@gmail.com kirjoitti:
[clip]
> We had other cases of several patterns in quasi-deterministic linalg
> before, but as far as I remember only in the final digits of
> precision, where it didn't matter much except for reducing test
> precision in my cases.
>
> In the rando
16.02.2012 14:54, josef.p...@gmail.com kirjoitti:
[clip]
> If I interpret you correctly, this should be a svd ticket, or an svd
> ticket as "duplicate" ?
I think it should be a multivariate normal ticket.
"Fixing" SVD is in my opinion not sensible: its only guarantee is that A
= U S V^H down to n
Hi,
16.02.2012 18:00, Nathaniel Smith kirjoitti:
[clip]
> I agree, but the behavior is still surprising -- people reasonably
> expect something like svd to be deterministic. So there's probably a
> doc bug for alerting people that their reasonable expectation is, in
> fact, wrong :-).
The problem
Hi,
16.02.2012 23:39, Travis Oliphant kirjoitti:
[clip]
> * NumPy 1.8 to come out in July which will have as many ABI-compatible
> feature enhancements as we can add while improving test coverage and code
> cleanup. I will post to this list more details of what we plan to address
> with
cky messing with the C API. The backwards
compatibility issue is also just a documentation issue, so nothing drastic.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
us is probably correct --- perhaps UTC all the way
would be a safer (and simpler) choice?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
#x27;t care about DST etc.). It seems it could
be made to work by interpreting timezoneless input as UTC dates.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Dealing with actual TZ handling could be left to be the
responsibility of the users, maybe with some helper conversion
functions on the Numpy side.
This still leaves open the question how leap seconds should be
handled, or if we should just ignore the results and let
people live with
datetime64(&#
though.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
101 - 200 of 1087 matches
Mail list logo
