Re: [Numpy-discussion] Move scipy.org docs to Github?

Thu, 16 Mar 2017 08:15:08 +0100, Didrik Pinte kirjoitti: >> The advantage of something like github pages is that it's big enough >> that it *does* have dedicated ops support. > > Agreed. One issue is that we are working with a lot of legacy. Github > will more than likely be a great solution to

Re: [Numpy-discussion] Move scipy.org docs to Github?

Wed, 15 Mar 2017 14:56:52 -0700, Nathaniel Smith kirjoitti: [clip] > As long as we can fit under the 1 gig size limit then GH pages seems > like the best option so far... it's reliable, widely understood, and all > of the limits besides the 1 gig size are soft limits where they say > they'll work

Re: [Numpy-discussion] Move scipy.org docs to Github?

Wed, 15 Mar 2017 12:11:09 -0400, Marten van Kerkwijk kirjoitti: > Astropy uses readthedocs quite happily (auto-updates on merges to master > too). AFAIK, scipy cannot be built on readthedocs. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org

Re: [Numpy-discussion] Ensuring one can operate on array-like argument in place

Sat, 12 Nov 2016 17:00:07 +, Pavlyk, Oleksandr kirjoitti: [clip] > if x_arr is not x: >in_place = 1 # a copy was made, so we can work in place. > > The logic is of the last line turns out to be incorrect, because the > input x can be a class with an array interface. Please see:

Re: [Numpy-discussion] automatically avoiding temporary arrays

Mon, 03 Oct 2016 15:07:28 -0400, Benjamin Root kirjoitti: > With regards to arguments about holding onto large arrays, I would like > to emphasize that my original suggestion mentioned weakref'ed numpy > arrays. > Essentially, the idea is to claw back only the raw memory blocks during > that limbo

Re: [Numpy-discussion] New iterator APIs (nditer / MapIter): Overlap detection in NumPy

Mon, 12 Sep 2016 11:31:07 +0200, Sebastian Berg kirjoitti: >> * NPY_ITER_COPY_IF_OVERLAP, NPY_ITER_OVERLAP_NOT_SAME >>   flags for NpyIter_New. >> >> * New API function PyArray_MapIterArrayCopyIfOverlap, >>   as ufunc.at needs to check overlaps for index arrays before >>   constructing iterators,

[Numpy-discussion] New iterator APIs (nditer / MapIter): Overlap detection in NumPy

Hi, In the end some further API additions turn out to appear needed: * NPY_ITER_COPY_IF_OVERLAP, NPY_ITER_OVERLAP_NOT_SAME flags for NpyIter_New. * New API function PyArray_MapIterArrayCopyIfOverlap, as ufunc.at needs to check overlaps for index arrays before constructing iterators, and

Re: [Numpy-discussion] New iterator API (nditer): Overlap detection in NumPy

sumptions also there. It might be possible to turn it on by default for operands with COPY or UPDATEIFCOPY flags --- but I'm not sure if that's helpful (now you'd need to set the flags to all input operands). -- Pauli Virtanen ___ NumPy-Discussion mailing

Re: [Numpy-discussion] test_closing_fid (in test_io.py) on PyPy

Fri, 05 Aug 2016 10:06:02 +0300, Matti Picus kirjoitti: [clip] > I can submit a pull request to skip on pypy, or should this be solved in > a more substantial way? Should also be safe to just skip it on Pypy, it's testing that the wrong way to use np.load also works on CPython. --

Re: [Numpy-discussion] StackOverflow documentation

course, working on that requires a somewhat different level of committment than editing what's essentially Stackexchange-provided wiki (where content gets relicensed with attribution clauses where you have to reference stackexchange and not the original author directly). --

Re: [Numpy-discussion] deterministic, reproducible matmul / __matmult_

emory alignment --- not in dot products, but in other computations. Out of curiosity, what is the application where this is necessary? Maybe there is a numerically stable formulation? -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@

[Numpy-discussion] Benchmark regression feeds

Hi, In case someone is interested in getting notifications of performance regressions in the Numpy and Scipy benchmarks, this is available as Atom feeds at: https://pv.github.io/numpy-bench/regressions.xml https://pv.github.io/scipy-bench/regressions.xml -- Pauli Virtanen

Re: [Numpy-discussion] Why does asarray() create an intermediate memoryview?

unting. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ATLAS build errors

fy the build to avoid > them? Maybe the ATLAS binaries supplied were compiled with g77 instead of gfortran. If so, they should not be used with gfortran --- need to recompile. Also, in the past ATLAS binaries shipped by distributions had severe bugs. However, 3.8.x may be a new enough version. --

Re: [Numpy-discussion] GSoC?

Thu, 11 Feb 2016 00:02:52 +0100, Ralf Gommers kirjoitti: [clip] > OK first version: > https://github.com/scipy/scipy/wiki/GSoC-2016-project-ideas I kept some > of the ideas from last year, but removed all potential mentors as the > same people may not be available this year - please re-add

Re: [Numpy-discussion] Numpy 1.11.0rc1 released.

agmentation in the 2GB address space available? If dt==float64, that requires 250MB contiguous. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Numpy 1.11.0rc1 released.

23.02.2016, 03:47, Charles R Harris kirjoitti: > I'm delighted to announce the release of Numpy 1.11.0rc1. Hopefully the > issues discovered in 1.11.0b3 have been dealt with and this release can go > on to become the official release. Source files and documentation can be > found on Sourceforge >

Re: [Numpy-discussion] NumPy 1.11.0b3 released.

10.02.2016, 04:09, Charles R Harris kirjoitti: > I'm pleased to announce the release of NumPy 1.11.0b3. This beta contains [clip] > Please test, hopefully this will be that last beta needed. FWIW, https://travis-ci.org/pv/testrig/builds/108384173 ___

Re: [Numpy-discussion] Numpy 1.11.0b2 released

05.02.2016, 19:55, Nathaniel Smith kirjoitti: > On Feb 5, 2016 8:28 AM, "Chris Barker - NOAA Federal" > wrote: >> >>> An extra ~2 hours of tests / 6-way parallelism is not that big a deal >>> in the grand scheme of things (and I guess it's probably less than >>> that if we

Re: [Numpy-discussion] Numpy 1.11.0b2 released

atrix, eg. https://travis-ci.org/pv/testrig/ Of course, if the suggestion is that the results are generated on somewhere else than on travis, then that's a different matter. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Numpy 1.11.0b2 released

cessarily volunteering to maintain the setup, though, but if it seems useful, move it under numpy org. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Downstream integration testing

e some understanding of the downstream package, but this would at least ensure we are aware of stuff breaking. Provided it's covered by downstream test suite, of course. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org

Re: [Numpy-discussion] Downstream integration testing

31.01.2016, 14:41, Daπid kirjoitti: > On 31 Jan 2016 13:08, "Pauli Virtanen" <p...@iki.fi> wrote: >> For example, automated test rig that does the following: >> >> - run tests of a given downstream project version, against >> previous numpy version,

Re: [Numpy-discussion] Compilation problems npy_float64

mmit/832baa20f0b5 so you may have better luck with the dev version. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Cython-based OpenMP-accelerated quartic polynomial solver

However, since it's piecewise, there's purposefully support only for real-valued roots. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

26.08.2015, 14:14, Francesc Alted kirjoitti: [clip] 2015-08-25 12:03 GMT+02:00 Nathaniel Smith n...@pobox.com: Let's focus on evolving numpy as far as we can without major break-the-world changes (no numpy 2.0, at least in the foreseeable future). And, as a target for that evolution,

Re: [Numpy-discussion] py2/py3 pickling

25.08.2015, 01:15, Chris Laumann kirjoitti: Would it be possible then (in relatively short order) to create a py2 - py3 numpy pickle converter? You probably need to modify the pickle stream directly, replacing *STRING opcodes with *BYTES opcodes when it comes to objects that are needed for

Re: [Numpy-discussion] py2/py3 pickling

24.08.2015, 01:02, Chris Laumann kirjoitti: [clip] Is there documentation about the limits and workarounds for py2/py3 pickle/np.save/load compatibility? I haven't found anything except developer bug tracking discussions (eg. #4879 in github numpy). Not sure if it's written down somewhere

Re: [Numpy-discussion] Development workflow (not git tutorial)

14.08.2015, 20:45, Allan Haldane kirjoitti: [clip] Related to this, does anyone know how to debug numpy in gdb with proper symbols/source lines, like I can do with other C extensions? I've tried modifying numpy distutils to try to add the right compiler/linker flags, without success.

Re: [Numpy-discussion] Development workflow (not git tutorial)

15.08.2015, 01:44, Chris Barker kirjoitti: [clip] numpy doesn't use namespace packages, so develop mode works there. The develop mode is mainly useful with a virtualenv. Otherwise, you install work-in-progress development version into your ~/.local which then breaks everything else. In addition

Re: [Numpy-discussion] Numpy, BLAS, and CBLAS questions

13.07.2015, 20:08, Nathaniel Smith kirjoitti: [clip] Keep in mind that any solution needs to support weird systems too, including Windows. I'm not sure we can assume that all BLAS libraries are ABI compatible either. Debian/Ubuntu make sure that this is true for the ones they ship, but not all

Re: [Numpy-discussion] Numpy, BLAS, and CBLAS questions

13.07.2015, 19:44, Eric Martin kirjoitti: It seems to me that a potentially better route than add code to Numpy to support BLAS library for each library is to make Numpy easy to configure to compile with an arbitrary BLAS library (like what I've been doing). Does this work: export ATLAS=None

Re: [Numpy-discussion] Homu

15.06.2015, 12:00, Nathaniel Smith kirjoitti: [clip] http://homu.io/ One thing to consider is the disadvantage from security POV: this gives full write access to the Numpy repository to that someone who is running the bot. I don't see information on who this person (or these persons) is and

Re: [Numpy-discussion] Verify your sourceforge windows installer downloads

28.05.2015, 20:35, Sturla Molden kirjoitti: Pauli Virtanen p...@iki.fi wrote: Is it possible to host them on github? I think there's an option to add release notes and (apparently) to upload binaries if you go to the Releases section --- there's one for each tag. And then Sourceforge

Re: [Numpy-discussion] Verify your sourceforge windows installer downloads

28.05.2015, 20:05, David Cournapeau kirjoitti: [clip] In any case I've always been surprised that NumPy is distributed through SourceForge, which has been sketchy for years now. Could it simply be hosted on PyPI? They don't accept arbitrary binaries like SF does, and some of our installer

Re: [Numpy-discussion] Verify your sourceforge windows installer downloads

28.05.2015, 21:52, Julian Taylor kirjoitti: there is no guarantee that github will not do this stuff in future too, also PyPI or self hosting do not necessarily help as those resources can be compromised. The main thing that should be learned this and the many similar incidents in the past is

Re: [Numpy-discussion] Numpy compilation error

12.04.2015, 17:15, Peter Kerpedjiev kirjoitti: [clip] numpy/random/mtrand/distributions.c:892:1: internal compiler error: Illegal instruction An internal compiler error means your compiler (in this case, gcc) is broken. The easiest solution is to use a newer version of the compiler, assuming

Re: [Numpy-discussion] Advanced indexing: fancy vs. orthogonal

03.04.2015, 04:09, josef.p...@gmail.com kirjoitti: [clip] I think numpy indexing is not too difficult and follows a consistent pattern, and I completely avoid mixing slices and index arrays with ndim 2. I think it should be DOA, except as a discussion topic for numpy 3000. If you change

Re: [Numpy-discussion] numpy pickling problem - python 2 vs. python 3

07.03.2015, 01:29, Julian Taylor kirjoitti: On 07.03.2015 00:20, Pauli Virtanen wrote: 06.03.2015, 22:43, Eric Firing kirjoitti: On 2015/03/06 10:23 AM, Pauli Virtanen wrote: 06.03.2015, 20:00, Benjamin Root kirjoitti: A slightly different way to look at this is one of sharing data. If I am

Re: [Numpy-discussion] numpy pickling problem - python 2 vs. python 3

06.03.2015, 22:23, Pauli Virtanen kirjoitti: 06.03.2015, 20:00, Benjamin Root kirjoitti: A slightly different way to look at this is one of sharing data. If I am working on a system with 3.4 and I want to share data with others who may be using a mix of 2.7 and 3.3 systems, this problem makes

Re: [Numpy-discussion] numpy pickling problem - python 2 vs. python 3

06.03.2015, 22:43, Eric Firing kirjoitti: On 2015/03/06 10:23 AM, Pauli Virtanen wrote: 06.03.2015, 20:00, Benjamin Root kirjoitti: A slightly different way to look at this is one of sharing data. If I am working on a system with 3.4 and I want to share data with others who may be using a mix

Re: [Numpy-discussion] numpy pickling problem - python 2 vs. python 3

Arnd Baecker arnd.baecker at web.de writes: [clip] Still I would have thought that this should be working out-of-the box, i.e. without the pickle.loads trick? Pickle files should be considered incompatible between Python 2 and Python 3. Python 3 interprets all bytes objects saved by Python 2

Re: [Numpy-discussion] numpy pickling problem - python 2 vs. python 3

06.03.2015, 20:00, Benjamin Root kirjoitti: A slightly different way to look at this is one of sharing data. If I am working on a system with 3.4 and I want to share data with others who may be using a mix of 2.7 and 3.3 systems, this problem makes npz format much less attractive. pickle is

Re: [Numpy-discussion] GSoC'15 - mentors ideas

25.02.2015, 19:59, Pauli Virtanen kirjoitti: 25.02.2015, 07:11, Nathaniel Smith kirjoitti: Not sure if this is a full GSoC but it would be good to get the benchmarks into the numpy repository, so we can start asking people who submit optimizations to submit new benchmarks as part of the PR

Re: [Numpy-discussion] Matrix Class

11.02.2015, 21:57, Alan G Isaac kirjoitti: [clip] I think gains could be in lazy evaluation structures (e.g., a KroneckerProduct object that never actually produces the product unless forced to.) This sounds like an abstract linear operator interface. Several attempts have been made to this

[Numpy-discussion] ANN: Scipy 0.15.1

it is available again in Scipy 0.15.1, using it is deprecated and it may be removed again in a future Scipy release. Source tarballs, binaries, and full release notes are available at https://sourceforge.net/projects/scipy/files/scipy/0.15.1/ Best regards, Pauli Virtanen == SciPy

[Numpy-discussion] ANN: Scipy 0.15.0 release

notes are available at https://sourceforge.net/projects/scipy/files/scipy/0.15.0/ Best regards, Pauli Virtanen == SciPy 0.15.0 Release Notes == SciPy 0.15.0 is the culmination of 6 months of hard work. It contains several new features, numerous bug

[Numpy-discussion] ANN: Scipy 0.14.1 release

with numpy relaxed strides - - gh-4225 Off-by-one error in PPoly shape checks - - gh-4248 Fix issue with incorrect use of closure for slsqp Source tarballs and binaries are available at https://sourceforge.net/projects/scipy/files/SciPy/0.14.1/ Best regards, Pauli Virtanen -BEGIN PGP SIGNATURE

Re: [Numpy-discussion] Context manager for seterr

15.12.2014, 02:12, Stefan van der Walt kirjoitti: Since the topic of context managers recently came up, what do you think of adding a context manager for seterr? with np.seterr(divide='ignore'): frac = num / denom There's this: with np.errstate(divide='ignore'): ...

Re: [Numpy-discussion] Scipy 0.15.0 beta 1 release

this. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [SciPy-Dev] ANN: Scipy 0.15.0 beta 1 release

that is out there. Everyone who uses double complex, intent(inout) in their f2py wrapped code will start getting random exceptions on Windows. Users of double complex, intent(in) pay a performance penalty. -- Pauli Virtanen ___ NumPy-Discussion mailing

[Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release

. Source tarballs and full release notes are available at https://sourceforge.net/projects/scipy/files/SciPy/0.15.0b1/ Binary installers should also be up soon. Best regards, Pauli Virtanen - SciPy 0.15.0 is the culmination of 6 months of hard work

Re: [Numpy-discussion] Numpy 1.9.1, zeros and alignement

there with complex inout arrays, and I think no-one uses special aligned allocators... -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Detect if array has been transposed

12.10.2014, 20:19, Mads Ipsen kirjoitti: Is there any way for me to detect (on the Python side) that transpose() has been invoked on the matrix, and thereby only do the copy operation when it really is needed? The correct way to do this is to, either: In your C code check

Re: [Numpy-discussion] Detect if array has been transposed

12.10.2014, 22:16, Eric Firing kirjoitti: On 2014/10/12, 8:29 AM, Pauli Virtanen wrote: 12.10.2014, 20:19, Mads Ipsen kirjoitti: Is there any way for me to detect (on the Python side) that transpose() has been invoked on the matrix, and thereby only do the copy operation when it really

Re: [Numpy-discussion] @ operator

what to do. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] __numpy_ufunc__ and 1.9 release

Scipy only rules out the option that ndarray.__mul__(other) should unconditionally call `np.add(self, other)`. We have some freedom how to solve the binop vs. subclass issues. It's possible to e.g. retain the __array_priority__ stuff as a backward compatibility measure as we do currently. -- Pauli

Re: [Numpy-discussion] proposal: new commit guidelines for backportable bugfixes

commits, so test failures can be caught (although after the fact). This is also the case for directly pushed cherry-picked commits. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo

Re: [Numpy-discussion] String type again.

18.07.2014 19:33, Chris Barker kirjoitti: On Fri, Jul 18, 2014 at 9:07 AM, Pauli Virtanen p...@iki.fi wrote: Another approach would be to add a new 1-byte unicode you can't do unicode in 1-byte -- so what does this mean, exactly? The first 256 unicode code points, which happen to coincide

Re: [Numpy-discussion] proposal: new commit guidelines for backportable bugfixes

18.07.2014 19:35, Julian Taylor kirjoitti: On Fri, Jul 18, 2014 at 6:23 PM, Nathaniel Smith n...@pobox.com wrote: On 18 Jul 2014 15:36, Julian Taylor jtaylor.deb...@googlemail.com wrote: git rebase --onto $(git merge-base master maintenance/1.9.x) HEAD^ As a potential refinement, this

Re: [Numpy-discussion] `allclose` vs `assert_allclose`

authors who relied on that the default was atol=0 is not so big. (In other news, we should discourage use of assert_almost_equal, by telling people to use assert_allclose instead in the docstring at the least. It has only atol= and it specifies it in a very cumbersome log10 basis...) -- Pauli

Re: [Numpy-discussion] `allclose` vs `assert_allclose`

18.07.2014 22:13, Chris Barker kirjoitti: [clip] but an appropriate rtol would work there too. If only zero testing is needed, then atol=0 makes sense as a default. (or maybe atol=eps) There's plenty of room below eps, but finfo(float).tiny ~ 3e-308 (or some big multiple) is also reasonable in

Re: [Numpy-discussion] proposal: new commit guidelines for backportable bugfixes

18.07.2014 23:53, Julian Taylor kirjoitti: On 18.07.2014 19:47, Pauli Virtanen wrote: [clip] The other well-known alternative to bugfixes is to first commit it in the earliest maintenance branch where you want to have it, and then merge that branch forward to the newer maintenance branches

Re: [Numpy-discussion] proposal: new commit guidelines for backportable bugfixes

19.07.2014 01:49, Nathaniel Smith kirjoitti: On Fri, Jul 18, 2014 at 11:44 PM, Pauli Virtanen p...@iki.fi wrote: 18.07.2014 23:53, Julian Taylor kirjoitti: On 18.07.2014 19:47, Pauli Virtanen wrote: [clip] The other well-known alternative to bugfixes is to first commit it in the earliest

Re: [Numpy-discussion] proposal: new commit guidelines for backportable bugfixes

19.07.2014 02:10, Pauli Virtanen kirjoitti: 19.07.2014 01:49, Nathaniel Smith kirjoitti: On Fri, Jul 18, 2014 at 11:44 PM, Pauli Virtanen p...@iki.fi wrote: [clip] Presumably all the commits that we miss on the first pass and end up backporting the hard way later :-) If those are just

Re: [Numpy-discussion] __numpy_ufunc__ and 1.9 release

Hi, 15.07.2014 21:06, Julian Taylor kirjoitti: [clip: __numpy_ufunc__] So I'm wondering if we should delay the introduction of this feature to 1.10 or is it important enough to wait until there is a consensus on the remaining issues? My 10c: The feature is not so much in hurry that it alone

Re: [Numpy-discussion] Short-hand array creation in `numpy.mat` style

. Preferably, the name should be quite short to type. On the other hand, unlike r_ and c_, I haven't seen or used mat() in real code. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo

Re: [Numpy-discussion] Slightly off-topic - accuracy of C exp function?

statements of the form `if a b: ...` with floating point numbers, so that the execution path can be sensitive to rounding error if you're unlucky, and the chances go up as the iteration count increases. -- Pauli Virtanen ___ NumPy-Discussion mailing list

Re: [Numpy-discussion] 64-bit windows numpy / scipy wheels for testing

Hi, 25.04.2014 00:56, Matthew Brett kirjoitti: Thanks to Cark Kleffner's toolchain and some help from Clint Whaley (main author of ATLAS), I've built 64-bit windows numpy and scipy wheels for testing. Where can I get your numpy.patch scipy.patch and what's in them? Cheers,

Re: [Numpy-discussion] 64-bit windows numpy / scipy wheels for testing

. OSX is somewhat saner in this respect. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSOC

23.02.2014 11:30, Ralf Gommers kirjoitti: [clip] 1. fix up ideas page with scipy/numpy descriptions, idea difficulty levels and preferably some more ideas. Here's a start: https://github.com/scipy/scipy/wiki/GSoC-project-ideas ___ NumPy-Discussion

Re: [Numpy-discussion] How exactly ought 'dot' to work?

that should definitely be discussed. But I think this is a problem mainly interesting for Numpy devs, and not for CPython devs. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy

Re: [Numpy-discussion] Automatic issue triage.

. This would also solve the issue of how to add attachments to bug reports in one way. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Automatic issue triage.

be maintained by normal PR processes just fine. Yes. However, using a separate repository might make this more easy to deal with. This also does not have the running arbitrary code problem. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy

Re: [Numpy-discussion] Suggestions for GSoC Projects

in scipy.special could bring better evaluation performance even if the algorithm is the same. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] GSOC

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 13.02.2014 20:59, josef.p...@gmail.com kirjoitti: [clip] I assume numpy/scipy will participate under the PSF umbrella. So this deadline is for the PSF. However, Terri, the organizer for the PSF, asked for links to Ideas pages to be able to show

Re: [Numpy-discussion] deprecate numpy.matrix

as your suggestion is to add a coercion function in the vein of scipy.sparse.aslinearoperator. It could deal with known-failure cases (np.matrix, scipy.sparse matrices) and for the rest just assume the object satisfies the ndarray API and pass them through. -- Pauli Virtanen

Re: [Numpy-discussion] deprecate numpy.matrix

Sturla Molden sturla.molden at gmail.com writes: Pauli Virtanen pav at iki.fi wrote: It is not a good thing that there is no well defined domain specific language for matrix algebra in Python. Perhaps Python should get some new operators? It might still be possible to advocate

Re: [Numpy-discussion] deprecate numpy.matrix

interface, for example as in https://github.com/cvxgrp/cvxpy/tree/master/cvxpy/interface/numpy_interface. Here's some more data: http://nullege.com/codes/search?cq=numpy.matrix http://nullege.com/codes/search?cq=numpy.array -- Pauli Virtanen ___ NumPy

Re: [Numpy-discussion] Suggestions for GSoC Projects

evaluate them in most parameter regimes, but AFAIK both require arbitrary-precision methods for this.) So I think there would be a large number of possible things to do here, and help would be appreciated. - -- Pauli Virtanen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux

Re: [Numpy-discussion] Suggestions for GSoC Projects

Hi, 08.02.2014 06:16, Stéfan van der Walt kirjoitti: On 8 Feb 2014 04:51, Ralf Gommers ralf.gomm...@gmail.com wrote: Members of the dipy team would also be interested. That's specifically for the spherical harmonics topic right? Right. Spherical harmonics are used as bases in many of

Re: [Numpy-discussion] deprecate numpy.matrix

not. With some hyberbole added, one could say that from the developer point of view, np.matrix is doing and has already done evil just by existing, by messing up the unstated rules of ndarray semantics in Python. -- Pauli Virtanen ___ NumPy-Discussion

Re: [Numpy-discussion] deprecate numpy.matrix

10.02.2014 23:13, Alan G Isaac kirjoitti: On 2/10/2014 4:03 PM, Pauli Virtanen wrote: What sparked this discussion (on Github) is that it is not possible to write duck-typed code that works correctly for: Do you mean one must start out with an 'asarray'? Or more than that? Starting

Re: [Numpy-discussion] deprecate numpy.matrix

10.02.2014 23:40, Alan G Isaac kirjoitti: On 2/10/2014 4:28 PM, Pauli Virtanen wrote: Starting with asarray won't work: sparse matrices are not subclasses of ndarray. I was focused on the `matrix` object. For this object, an initial asarray is all it takes to use array code

Re: [Numpy-discussion] deprecate numpy.matrix

new users to use the interface with the ndarray convention. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] deprecate numpy.matrix

11.02.2014 00:31, Alan G Isaac kirjoitti: On 2/10/2014 5:11 PM, Pauli Virtanen wrote: The existence of np.matrix messes up the general agreement on ndarray semantics in Python. The meaning of very basic code such as A * B A.sum(0) A[0] where A and B are NxN matrices of some

Re: [Numpy-discussion] deprecate numpy.matrix

np.matrix would point the way. (I also suspect that this argument has been raised before, but as long as there's no canonical write-up...) -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman

Re: [Numpy-discussion] MKL and OpenBLAS

OpenBLAS with Numpy source releases --- arguments against: OpenBLAS is big, and still rapidly moving. Moreover, bundling it with Numpy does not really make it any easier to build. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion

Re: [Numpy-discussion] using loadtxt to load a text file in to a numpy array

equivalent. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] using loadtxt to load a text file in to a numpy array

that the rename 'S' - 'B' was not done in the Python 3 port, because 'B' already denotes uint8, np.array([1], dtype='B') array([1], dtype=uint8) -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman

Re: [Numpy-discussion] using loadtxt to load a text file in to a numpy array

. use on Py2. Adding new data types in Numpy codebase takes some work, but it's possible to do. There's also an issue (as noted in the Github ticket) that array([u'foo'], dtype=bytes) encodes silently via the ASCII codec. This is probably not how it should be. -- Pauli Virtanen

Re: [Numpy-discussion] -ffast-math

29.11.2013 22:15, Dan Goodman kirjoitti: Is it possible to get access to versions of ufuncs like sin and cos but compiled with the -ffast-math compiler switch? You can recompile Numpy with -ffast-math in OPT environment variable. Caveat emptor. -- Pauli Virtanen

Re: [Numpy-discussion] official binaries on web page.

on Windows and OSX is a good idea, and needs to be emphasized over needs of advanced users, who should have enough patience to read the bottom of the page. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org

Re: [Numpy-discussion] official binaries on web page.

of the scipy library part from the entry page. This would likely make things much clearer. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] official binaries on web page.

23.10.2013 21:06, Pauli Virtanen kirjoitti: 23.10.2013 17:51, Chris Barker - NOAA Federal kirjoitti: [clip] But it sounds like the real problem is with the surrounding pages--that's the page you find when you try to figure out how to get numpy--if that page is about the stack, it should

Re: [Numpy-discussion] official binaries on web page.

to an explanation that says that the scipy exists and what it is. A newcomer may possibly read that. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] official binaries on web page.

23.10.2013 23:24, Pauli Virtanen kirjoitti: 23.10.2013 22:50, Chris Barker kirjoitti: [clip] This makes me think: apparently there is an offical scipy stack -- and I even found it with a quick google: http://www.scipy.org/stackspec.html If you click More information... on the front page

Re: [Numpy-discussion] official binaries on web page.

. The links are there: http://www.scipy.org/install.html#custom -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Is there a contributors agreement for numypy?

the documentation has a separate license; also BSD. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Is there a contributors agreement for numypy?

21.10.2013 22:36, Mounir E. Bsaibes kirjoitti: On Mon, 2013-10-21 at 21:23 +0300, Pauli Virtanen wrote: 21.10.2013 21:00, Charles R Harris kirjoitti: [clip] There is no agreement needed, but all numpy is released under the simplified BSD license and any contributions need to be compatible

  1   2   3   4   5   6   7   8   9   10   >