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 hos
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 w
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
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:
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
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,
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 t
also that copies
break assumptions 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
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.
urse, 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 dire
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@
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
base refcounting.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
dify 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.
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 yourselv
ntation 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
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
> <
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
___
N
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 can take advantage of ex
added value this is compared to travis matrix, 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
'm necessarily 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
31.01.2016, 14:41, Daπid kirjoitti:
> On 31 Jan 2016 13:08, "Pauli Virtanen" wrote:
>> For example, automated test rig that does the following:
>>
>> - run tests of a given downstream project version, against
>> previous numpy version, record output
&g
d take 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
py/commit/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
html
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
26.08.2015, 14:14, Francesc Alted kirjoitti:
[clip]
> 2015-08-25 12:03 GMT+02:00 Nathaniel Smith :
>> 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, l
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 c
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 b
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
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.
runte
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
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=N
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 ho
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 pas
28.05.2015, 20:35, Sturla Molden kirjoitti:
> Pauli Virtanen 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
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
>
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 t
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 chan
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 di
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
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
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 i
Arnd Baecker 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 as str and att
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 benc
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 (just like other
> changes require tests).
Thi
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
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
==
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
rpolation compatible 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
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'):
...
___
ly arpack is doing
> different but I also did not have time yet to look at the testcase david
> created.
David's test case is this:
n = 4
x = np.zeros(n * 3, dtype="D")
_dummy.zfoo(x, n)
where the argument is declared as "double complex, dimension(3*n),
intent(inout)"
all* f2py code
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
___
.
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. It
assures?
If not, the second option is a bit nasty, since I'd believe many people
have f2py code out 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
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
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 PyArray_IS_C_CO
changes are possible only in
the context of adding new attributes telling Numpy what to do.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
ve 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 Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
so run automatically after pushing the merge 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
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 wrote:
[clip]
>> Presumably all the commits that we miss on the first pass and end up
>> backporting the hard way later :-)
>
&g
19.07.2014 01:49, Nathaniel Smith kirjoitti:
> On Fri, Jul 18, 2014 at 11:44 PM, Pauli Virtanen 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 bugfix
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
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
ies it in a very cumbersome log10
basis...)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
18.07.2014 19:35, Julian Taylor kirjoitti:
> On Fri, Jul 18, 2014 at 6:23 PM, Nathaniel Smith
> wrote:
>> On 18 Jul 2014 15:36, "Julian Taylor"
>> wrote:
>>>
>>> git rebase --onto $(git merge-base master maintenance/1.9.x)
>>> HEAD^
>>
>> As a potential refinement, this might be simpler if we d
18.07.2014 19:33, Chris Barker kirjoitti:
> On Fri, Jul 18, 2014 at 9:07 AM, Pauli Virtanen
> 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
hould for
backward compatibility continue returning dtype='S'. Moreover,
already existing code does not make use of it.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 alon
so weak +0. 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/
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,
ion routines contain 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
oblematic. 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
problem here can be the
accurate determination of the convergence region for each parameter value.
[1] http://www.ams.org/journals/mcom/2007-76-259/S0025-5718-07-01918-7/
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
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-Discussio
akes use of the capability for > 2-dim arrays is
something 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-Discussi
but it seems to me that it could 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
___
for bug test cases.
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
tten in C, and
using one of them 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
-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 G
Hi,
08.02.2014 06:16, Stéfan van der Walt kirjoitti:
> On 8 Feb 2014 04:51, "Ralf Gommers" 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 DiPy's
> rec
as the multi-argument
hyp* functions are challenging to evaluate in floating point. (mpmath
and Mathematica can 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 th
the 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=num
Sturla Molden gmail.com> writes:
> Pauli Virtanen 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
ropriately.
Another way to achieve similar thing 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 ndarr
gebra code in Python is muddled. This should be fixed, and deprecating
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-Discussio
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)
>>
ever be removed, but it would be useful to point 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
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
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'?
matrices and others 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
_
they're with Atlas too.
If you are suggesting bundling 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
___
e Unicode strings, right? Thanks
to Py2 automatic Unicode encoding/decoding, they might also be usable
in interactive etc. 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&#
ific encoding dtype.
Note 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
__
at 'S' give you
>
'S' is bytes.
dtype='S', dtype=bytes, and dtype=np.bytes_ are all equivalent.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 Vi
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
&g
"About Scipy"
in the sidebar, it takes you 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
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 tha
an improvement over Moinmoin, though.
One option would be to separate the navigation tree 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
elying on a Python distribution 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
1 - 100 of 1087 matches
Mail list logo
