I have always put my docs on Amazon S3 (examples: http://mdtraj.org/1.8.0/
, .http://msmbuilder.org/3.7.0/) For static webpages, you can't beat the
cost, and there's a lot of tooling in the wild for uploading pages to S3.
It might be an option to consider.
-Robert
On Thu, Mar 16, 20
recipe (thanks to Daniel Wheeler)
- fixes for Python 3.6
For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1
(rather long and technical).
Cheers,
Robert Cimrman
---
Contributors to this release in alphabetical order:
Siwei Chen
Robert Cimrman
Jan Heczko
Vladimir Lukes
>>
>> A dict of arrays?
>>
>> -n
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>>
>> ___
e wants to dabble in it
they are welcome to.
Robert
On Sun, Feb 19, 2017 at 4:19 AM, Juan Nunez-Iglesias
wrote:
> Hi everyone,
>
> Thanks for this. It looks absolutely fantastic. I've been putting off
> using numexpr but it looks like I don't have a choice anymore. ;)
>
Hi David,
Thanks for your comments, reply below the fold.
On Fri, Feb 17, 2017 at 4:34 PM, Daπid wrote:
> This is very nice indeed!
>
> On 17 February 2017 at 12:15, Robert McLeod wrote:
> > * bytes and unicode support
> > * reductions (mean, sum, prod, std)
>
> I
lease don't hesitate to open
an issue at the Github repo. Although unit tests have been run over the
operation space there are undoubtedly a number of bugs to squash.
Sincerely,
Robert
--
Robert McLeod, Ph.D.
Center for Cellular Imaging and Nano Analytics (C-CINA)
Biozentrum der Universität
Instead of trying to decipher what someone wrote on a Wikipedia, why don't
you look at a working piece of source code?
e.g.
https://github.com/3dem/relion/blob/master/src/euler.cpp
Robert
On Wed, Feb 1, 2017 at 4:27 AM, Seb wrote:
> On Tue, 31 Jan 2017 21:23:55 -0500,
>
On Mon, Jan 23, 2017 at 9:41 AM, Nadav Har'El wrote:
>
> On Mon, Jan 23, 2017 at 4:52 PM, aleba...@gmail.com
wrote:
>>
>> 2017-01-23 15:33 GMT+01:00 Robert Kern :
>>>
>>> I don't object to some Notes, but I would probably phrase it more like
we are p
On Mon, Jan 23, 2017 at 9:22 AM, Anne Archibald
wrote:
>
>
> On Mon, Jan 23, 2017 at 3:34 PM Robert Kern wrote:
>>
>> I don't object to some Notes, but I would probably phrase it more like
we are providing the standard definition of the jargon term "sampling
with
, and I would have been incredibly surprised if it did
anything else. If the option were named "unique=True", then I would have
needed some more documentation to let me know exactly how it was
implemented.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
u would only use a
generic dense matrix if you know that there isn't structure in the matrix.
So there are no routines for detecting that structure in generic dense
matrices.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
ran LAPACK, if you have a special structured matrix, you usually
explicitly use packed storage and call the appropriate function type on it.
It's only when you go to a system that only has a generic, unstructured
dense matrix data type that it makes sense to do those kinds of c
technical).
Cheers,
Robert Cimrman
---
Contributors to this release in alphabetical order:
Robert Cimrman
Vladimir Lukes
Matyas Novak
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
ons are just so sweet.
> >>
> >> But I imagine this isn't particularly efficient.
> >>
> >
> > Right. Using a generator and np.fromiter() will avoid the creation of
the
> > intermediate list. Something like:
> >
> > np.fromiter(
; build_utils/src/apple_sgemv_fix.c
>
>
> Sturla
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
--
Robert Kern
___
for
example, since it only has a limited subset of numpy functionality. In the
example provided that or linspace is likely the natural input for the
variable 't'.
--
Robert McLeod, Ph.D.
Center for Cellular Imaging and Nano Analytics (C-CINA)
Biozentrum der Universität Basel
M
nce of this tangent to Oleksander's
contributions.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Releasing NumPy under GPL would make it incompatible with SciPy, which may
be _slightly_ inconvenient to the scientific Python community:
https://scipy.github.io/old-wiki/pages/License_Compatibility.html
https://mail.scipy.org/pipermail/scipy-dev/2013-August/019149.html
Robert
On Thu, Oct 27
:
https://github.com/numpy/numpy/blob/master/numpy/random/mtrand/distributions.c#L262-L397
>
> Perhaps the point should be that the numpy devs won't want to maintain
two nearly identical versions of that code.
Indeed. That's how the algorithm was published. The /* sigh ... */ is m
On Wed, Oct 26, 2016 at 9:36 AM, Sebastian Berg
wrote:
>
> On Mi, 2016-10-26 at 09:29 -0700, Robert Kern wrote:
> > On Wed, Oct 26, 2016 at 9:10 AM, Julian Taylor > mail.com> wrote:
> > >
> > > On 10/26/2016 06:00 PM, Julian Taylor wrote:
> >
> >
ent backend drop-in like np.linalg being built against an optimized
BLAS, just a separate module that is inoperative without MKL.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Oct 25, 2016 at 10:22 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
>
> On Tue, Oct 25, 2016 at 10:41 PM, Robert Kern
wrote:
>>
>> On Tue, Oct 25, 2016 at 9:34 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
>> >
>> > Hi
andomstate is for.
https://github.com/bashtage/ng-numpy-randomstate
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
etain it,
though (for example, if .T is contiguous then we might well serialize the
transposed data linearly and return a view on that data upon
deserialization). I don't believe that we guarantee that the unpickled
result is contiguous.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
[[1,2]]
>
> Numpy arrays are different but references are forgotten after
pickle/unpickle. Shared objects do not remain shared. Based on the quote
below it could be considered bug with numpy/pickle.
Not a bug, but an explicit design decision on numpy's part.
--
Robert Kern
___
not [view, base], so it's probably not going to be all that
useful outside of special situations. It would make a neat recipe, but I
probably would not provide it in numpy itself.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Oct 5, 2016 at 1:11 PM, srean wrote:
> Thanks Francesc, Robert for giving me a broader picture of where this fits
> in. I believe numexpr does not handle slicing, so that might be another
> thing to look at.
>
Dereferencing would be relatively simple to add into numexpr,
ily grow into thousands if
more functions are added, so I also built a reverse lookup tree (based on
collections.defaultdict) for the Python-side of numexpr.
Robert
--
Robert McLeod, Ph.D.
Center for Cellular Imaging and Nano Analytics (C-CINA)
Biozentrum der Universität Basel
Mattenst
homogenized coefficients
- using argparse instead of optparse
For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1
(rather long and technical).
Cheers,
Robert Cimrman
---
Contributors to this release in alphabetical order:
Robert Cimrman
Jan Heczko
Thomas Kluyver
Vladimir
Pavlyk,
NumExpr optionally includes MKL's VML at compile-time. You may want to
look at its implementation. From what I recall it relies on a function in
a bootstrapped __config__.py to determine if MKL is present.
Robert
On Thu, Sep 29, 2016 at 7:27 PM, Pavlyk, Oleksandr <
oleks
committing to backwards compatibility.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
ure about:
> >
> > 1. Is `__getitem__` in some way special to make this difficult (also
> > considering some new ideas like allowing object[a=4]?
>
> OK; I think the C-side slot cannot get the kwarg likely, but probably
> you can find a solution for that
Well, the so
you had "0.3001 0.0 20.0" as a row, but all
of the other "x=0.3" rows had "0.3", then that row would get sorted out of
order. You would have to clean up the grid coordinates a bit first.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
aped[..., 2]
[~/scratch]
|10> x
array([[ 0. , 0. , 0. ],
[ 0.3, 0.3, 0.3],
[ 0.6, 0.6, 0.6]])
[~/scratch]
|11> y
array([[ 0. , 0.3, 0.6],
[ 0. , 0.3, 0.6],
[ 0. , 0.3, 0.6]])
[~/scratch]
|12> values
array([[ 10., 11., 12.],
[ 20., 2
On Wed, Aug 31, 2016 at 1:34 PM, Matti Viljamaa wrote:
>
> On 31 Aug 2016, at 15:22, Robert Kern wrote:
>
> On Wed, Aug 31, 2016 at 12:28 PM, Matti Viljamaa
wrote:
> >
> > Is there a clean way to include the last element when subindexing numpy
arrays?
> > Since
n, then hand over some pointers to existing buffers containing
vector data, then start the computation, and finally read back the data.
The library also can use MPI to parallelize.
I usually reach for Cython:
http://cython.org/
http://docs.cython.org/en/latest/src/userguid
up to Nyquist, so np.fft.rfftfreq()
must give you the frequencies to match. I'm not sure if there is another
misunderstanding lurking that needs to be clarified.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mai
6, 7, 8, 9])
> >>> A[0:5]
> array([0, 1, 2, 3, 4])
A[5:]
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
rds.max(axis=0)])
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
to np.set_printoptions().
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Jul 15, 2016 at 2:53 AM, Pavlyk, Oleksandr <
oleksandr.pav...@intel.com> wrote:
>
> Hi Robert,
>
> Thank you for the pointers.
>
> I think numpy.random should have a mechanism to choose between methods
for generating the underlying randomness dynamically, at a
e:
https://github.com/numpy/numpy/issues/6967
And the current effort for adding new core PRNGs here:
https://github.com/bashtage/ng-numpy-randomstate
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
org/pipermail/numpy-discussion/2015-July/073125.html
Note that the future is coming in the next numpy release:
https://github.com/numpy/numpy/pull/6271
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
dding. Probably it's faster to make a new zeros array of the
appropriate padded size and do 2*ndim copies?
Robert
On Wed, May 25, 2016 at 9:35 PM, Allen Welkie
wrote:
> I'd like to get some feedback on my [pull request](
> https://github.com/numpy/numpy/pull/7593).
>
> This p
On Mon, May 23, 2016 at 5:41 PM, Chris Barker wrote:
>
> On Sun, May 22, 2016 at 2:35 AM, Robert Kern
wrote:
>>
>> Well, I mean, engineers want lots of things. I suspect that most
engineers *really* just want to call `numpy.random.seed(8675309)` at the
start and never expl
On Wed, May 18, 2016 at 7:56 PM, Nathaniel Smith wrote:
>
> On Wed, May 18, 2016 at 5:07 AM, Robert Kern
wrote:
> > On Wed, May 18, 2016 at 1:14 AM, Nathaniel Smith wrote:
> >> ...anyway, the real reason I'm a bit grumpy is because there are solid
> >> engine
On Wed, May 18, 2016 at 6:20 PM, wrote:
>
> On Wed, May 18, 2016 at 12:01 PM, Robert Kern
wrote:
>>
>> On Wed, May 18, 2016 at 4:50 PM, Chris Barker
wrote:
>> >>
>> >> > ...anyway, the real reason I'm a bit grumpy is because there are
solid
>
notice if they were using the same PRN stream -- because they
are used differently. So a "fairly low probability of a clash" would be
totally fine.
Well, the main question is: do you need to be able to spawn dependent
streams at arbitrary points to an arbitrary depth without coordinat
On Wed, May 18, 2016 at 1:14 AM, Nathaniel Smith wrote:
>
> On Tue, May 17, 2016 at 10:41 AM, Robert Kern
wrote:
> > On Tue, May 17, 2016 at 6:24 PM, Nathaniel Smith wrote:
> >>
> >> On May 17, 2016 1:50 AM, "Robert Kern" wrote:
> >> >
> &
On Tue, May 17, 2016 at 6:24 PM, Nathaniel Smith wrote:
>
> On May 17, 2016 1:50 AM, "Robert Kern" wrote:
> >
> [...]
> > What you want is a function that returns many RandomState objects that
are hopefully spread around the MT19937 space enough that they are
t; numpy.random.pop_seed.
I don't think that addresses the issues brought up here. It's just more
global state to worry about.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, May 17, 2016 at 9:09 AM, Stephan Hoyer wrote:
>
> On Tue, May 17, 2016 at 12:18 AM, Robert Kern
wrote:
>>
>> On Tue, May 17, 2016 at 4:54 AM, Stephan Hoyer wrote:
>> > 1. When writing a library of stochastic functions that take a seed as
an input argument,
o be *some* barrier to entry, but just grabbing
it to use as a default RandomState object is definitely an intended use of
it. It's not going to disappear.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
computation of homogenized coefficients
- clean up of elastic terms
- read support for msh file mesh format of gmsh
For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1
(rather long and technical).
Best regards,
Robert Cimrman on behalf of the SfePy development team
---
Contributors
of either input type (for that matter,
the actual *values* of the inputs are also never considered). In the case
of uint64 and int64, there is no really good common type (the integer
hierarchy has to top out somewhere), but float64 merely loses resolution
rather than cutting off half of the range
I'm a purist.
Consider using PRNGs that actually expose truly independent streams instead
of a single shared stream:
https://github.com/bashtage/ng-numpy-randomstate
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.
s to expose the underlying rk_state* pointer.
https://docs.python.org/2.7/c-api/capsule.html
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
clock
cycles saved by manylinux wheels.
-Robert
On Thu, Mar 24, 2016 at 10:46 PM, Nathaniel Smith wrote:
> On Thu, Mar 24, 2016 at 11:44 AM, Peter Cock
> wrote:
> > On Thu, Mar 24, 2016 at 6:37 PM, Nathaniel Smith wrote:
> >> On Mar 24, 2016 8:04 AM, "Peter Cock"
checking of shapes of term arguments
- improved mesh parametrization code and documentation
- support for fieldsplit preconditioners of PETSc
For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1
(rather long and technical).
Best regards,
Robert Cimrman on behalf of the
exact number of points needed.
At the risk of extending the twisty little maze of names, all alike, I
would probably call a function with this signature geomrange() instead. It
is more akin to arange(start, stop, step) than linspace(start, stop,
num_steps).
--
Robert Kern
___
On Thu, Feb 18, 2016 at 10:19 PM, Alan Isaac wrote:
>
> On 2/18/2016 2:44 PM, Robert Kern wrote:
>>
>> In a new function not named `linspace()`, I think that might be fine. I
do occasionally want to swap between linear and logarithmic/geometric
spacing based on a parameter,
linear and logarithmic/geometric spacing
based on a parameter, so this doesn't violate the van Rossum Rule of
Function Signatures.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
to index into
>> my arrays and would not appreciate having to litter my code with "-1"
>> everywhere.
>>
>> On Thu, Feb 18, 2016 at 10:29 AM, Alan Isaac > > wrote:
>>
>>> On 2/17/2016 3:42 PM, Robert Kern wrote:
>>>
>>>&
7;s reader in mind, not the code's writer.
As a reader of other people's code (and I count 6-months-ago-me as one such
"other people"), I am sure to eventually encounter all of the different
variants, so I will need to know all of them.
--
Robert Kern
_
..), particularly those that end up related to
indexing; e.g. `x[np.random.randint(0, len(x))]` to pull a random sample
from an array.
random.randint() was the one big exception, and it was considered a mistake
for that very reason, soft-deprecated in favor of random.randrange().
--
Robert Kern
suggest further work on this function is
> not called for, and use of `random_integers`
> should be encouraged. Probably NumPy's `randint`
> should be deprecated.
Not while I'm here. Instead, `random_integers()` is discouraged and perhaps
might eventually be deprecated.
--
On Mon, Feb 15, 2016 at 10:43 AM, Gregor Thalhammer <
gregor.thalham...@gmail.com> wrote:
>
> Dear Robert,
>
> thanks for your effort on improving numexpr. Indeed, vectorized math
> libraries (VML) can give a large boost in performance (~5x), except for a
> couple of ba
On Mon, Feb 15, 2016 at 7:28 AM, Ralf Gommers
wrote:
>
>
> On Sun, Feb 14, 2016 at 11:19 PM, Robert McLeod
> wrote:
>
>>
>> 4.) I took a stab at converting from distutils to setuputils but this
>> seems challenging with numpy as a dependency. I wonder if anyon
be
adversely impacted by retaining the status quo.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
ing so that setup.py build_ext uses distutils and then pass the
interpreter.pyd/so as a data file, or some other such chicanery?
(I was going to ask about attaching a debugger, but I just noticed:
https://wiki.python.org/moin/DebuggingWithGdb )
Ciao,
Robert
--
Robert McLeod, Ph.D.
Center for
le approach to y'all?
>
> Cheers,
>
> Matthew
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
declares all of the shared library
dependencies it actually needs.
-Robert
On Sat, Feb 6, 2016 at 3:42 PM, Michael Sarahan wrote:
> FWIW, we (Continuum) are working on a CI system that builds conda
> recipes. Part of this is testing not only individual packages that change,
> but al
ithub with some typos fixed:
https://github.com/manylinux/manylinux/blob/master/pep-513.rst
- Email archive:
https://mail.python.org/pipermail/distutils-sig/2016-January/027997.html
-Robert
On Tue, Jan 19, 2016 at 10:05 AM, Ralf Gommers
wrote:
>
>
> On Tue, Jan 19, 2016 at 5:57 PM, Chris
; >
>
> Well, actually random.uniform docstring says:
>
> Get a random number in the range [a, b) or [a, b] depending on
> rounding.
Which docstring are you looking at? The current one says [low, high)
http://docs.scipy.org/doc/numpy/r
On Thu, Jan 21, 2016 at 7:06 AM, Jaime Fernández del Río <
jaime.f...@gmail.com> wrote:
>
> There doesn't seem to be much of a consensus on the way to go, so leaving
things as they are and have been seems the wisest choice for now, thanks
for all the feedback. I will work with Greg on documenting t
On Tue, Jan 19, 2016 at 5:40 PM, Charles R Harris
wrote:
>
> On Tue, Jan 19, 2016 at 10:36 AM, Robert Kern
wrote:
>>
>> On Tue, Jan 19, 2016 at 5:27 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
>> >
>>
>> > On Tue, Jan 19, 2016 at
On Tue, Jan 19, 2016 at 5:36 PM, Robert Kern wrote:
>
> On Tue, Jan 19, 2016 at 5:27 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
> >
>
> > On Tue, Jan 19, 2016 at 9:23 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> >>
&
ntent. ;-)
With floating point and general intervals, there is not really a good way
to guarantee that the generated results avoid the "open" end of the
specified interval or even stay *within* that interval. This function is
definitely no
I would like to see Linux have feature parity with OS X and Windows with
respect to pip and PyPI.
- I want the PyPA tools like pip to be as good as possible.
- I'm confident that the manylinux proposal will work, and it's very
straightforward.
-Robert
_
ames/notation,
but really can't tell either way for sure without knowing what exactly they
are.
In particular check if your operations can be expressed with einsum()
http://docs.scipy.org/doc/numpy-1.10.1/reference/generated/numpy.einsum.html
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
reluctant to migrate. I was forever responding on comp.lang.python, "It's
because scalar arithmetic hasn't been optimized yet. We know how to do it,
we just need a volunteer to do the work. Contributions gratefully
accepted!" The most critical areas tended to
k I've made a pretty good start on the tooling for a wheel
ABI tag for a LSB-style base system that represents a common set of shared
libraries and symbols versions provided by "many" linuxes (previously
discussed by Nathaniel here:
https://code.activestate.com/lists/python-distutils-
enuts, is here:
https://github.com/rmcgibbo/deloc8.
It's currently fairly modest and can only list non-whitelisted external
shared library dependencies, and verify that sufficiently old versioned
symbols for glibc and its ilk are used.
-Robert
On Sun, Jan 10, 2016 at 1:19 AM, Robert McGibbo
y strict
policy here, or at least
not ones that is enforced by tooling. The sonames I listed here
<https://mail.scipy.org/pipermail/numpy-discussion/2016-January/074602.html>
cover
all of the external
dependencies used by the latest Anaconda release,
ibgcc_s.so.1, libstdc++.so.6, libXext.so.6, libSM.so.6,
libgthread-2.0.so.0, libgobject-2.0.so.0, libglib-2.0.so.0, libICE.so.6,
libXrender.so.1, and libGL.so.1.
Most of these are parts of X11 required by Qt (
http://doc.qt.io/qt-5/linux-requirements.html).
-Robert
On Sat, Jan 9, 2016 at 4:42
pularity-contests and the package graph. I
will report back when I have more info.
-Robert
On Sat, Jan 9, 2016 at 3:04 PM, Nathaniel Smith wrote:
> On Sat, Jan 9, 2016 at 3:52 AM, Robert McGibbon
> wrote:
> > Hi all,
> >
> > I went ahead and tried to collect a list of all of t
or dlopen to dynamically load
shared libraries that are actually just optional (and catch the error and
recover gracefully if the library can't be loaded).
-Robert
On Sat, Jan 9, 2016 at 4:20 AM, Julian Taylor wrote:
> On 09.01.2016 12:52, Robert McGibbon wrote:
> > Hi all,
> &
gnize that shouldn't be part of
the base system, like libatlas.so.3.
This gist https://gist.github.com/rmcgibbo/a13e7623c38ec54fcc93 contains
some more detailed data -- for each of libraries in the list above, it
gives a list of names of the packages that depend on this library. For
example, for libatlas.so.3, the there is only a single package which
depends on it, ["scikit-learn-0.11-np16py27_ce0"]. So, probably a bug.
"libgfortran.so.1" is also in the list. It's depended on by
["cvxopt-1.1.6-py27_0", "cvxopt-1.1.7-py27_0", "cvxopt-1.1.7-py34_0",
"cvxopt-1.1.7-py35_0", "numpy-1.5.1-py27_1", "numpy-1.5.1-py27_3",
"numpy-1.5.1-py27_4", "numpy-1.5.1-py27_ce0", "numpy-1.6.2-py27_1",
"numpy-1.6.2-py27_3", "numpy-1.6.2-py27_4", "numpy-1.6.2-py27_ce0",
"numpy-1.7.0-py27_0", "numpy-1.7.0b2-py27_ce0", "numpy-1.7.0rc1-py27_0",
"numpy-1.7.1-py27_0", "numpy-1.7.1-py27_2", "numpy-1.8.0-py27_0",
"numpy-1.8.1-py27_0", "numpy-1.8.1-py34_0", "numpy-1.8.2-py27_0",
"numpy-1.8.2-py34_0", "numpy-1.9.0-py27_0", "numpy-1.9.0-py34_0",
"numpy-1.9.1-py27_0", "numpy-1.9.1-py34_0", "numpy-1.9.2-py27_0",
"numpy-1.9.2-py34_0"].
Note that this list of numpy versions doesn't include the latest ones --
all of the numpy-1.10 binaries made by Continuum pick up libgfortan from a
conda package and don't depend on it being provided by the system. Also,
the final '_0' or '_1' segment of many of these package names is the build
number, which is to make a new release of the same release of a package,
usually because of a packaging problem. So many of these packages were
probably built incorrectly and superseded by new builds with a higher build
number.
So it's not perfect. But it might be a useful starting place.
-Robert
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
#x27;t be that hard...
right?
-Robert
On Fri, Jan 8, 2016 at 8:03 PM, Nathaniel Smith wrote:
> On Fri, Jan 8, 2016 at 7:41 PM, Robert McGibbon
> wrote:
> >> Doesn't building on CentOS 5 also mean using a quite old version of gcc?
> >
> > I have had pretty good luc
old libc).
I'm not 100% sure how it works, but it's quite nice. For example, you can
use c++11 and still keep all the binary compatibility benefits of CentOS 5.
-Robert
On Fri, Jan 8, 2016 at 7:38 PM, Nathaniel Smith wrote:
> On Fri, Jan 8, 2016 at 7:17 PM, Nathan Goldbaum
>
ne upload numpy-1.9.2-cp27-none-linux_x86_64.whl \
--yes-yes-i-know-this-is-dangerous-but-i-know-what-i'm-doing
```
that this would potentially be able to let packages like numpy serve their
linux
users better without risking too much junk being uploaded to PyPI.
-Robert
On Fri, Jan 8,
h compiled extensions. But
it's categorically ruled out by the PyPI policy, IIUC.
Perhaps this is OT for this thread, and I should ask on distutils-sig.
-Robert
On Fri, Jan 8, 2016 at 12:12 PM, Oscar Benjamin
wrote:
>
> On 8 Jan 2016 19:07, "Robert McGibbon" wrote:
> >
>
lem,
there shouldn't be much technically different for Linux wheels.
-Robert
On Fri, Jan 8, 2016 at 9:12 AM, Matthew Brett
wrote:
> Hi,
>
> On Fri, Jan 8, 2016 at 4:28 PM, Yuxiang Wang wrote:
> > Dear Nathaniel,
> >
> > Gotcha. That's very helpful. Thank you so
troduction and promotion of random.randrange() instead.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
reat! Do we have any concrete plans for spending that money,
yet?
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Dec 14, 2015 at 5:41 PM, Benjamin Root wrote:
>
> Heh, never noticed that. Was it implemented more like a
generator/iterator in older versions of Python?
No, it predates generators and iterators so it has always had to be
implemented like that.
--
Rober
an being a generic container.
>>> len(xrange(10))
10
>>> xrange(10)[5]
5
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
combination boundary conditions
- balloon inflation example
For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1
(rather long and technical).
Best regards,
Robert Cimrman on behalf of the SfePy development team
---
Contributors to this release in alphabetical order:
Robert
On Nov 17, 2015 6:53 PM, "Sebastian Berg"
wrote:
>
> On Di, 2015-11-17 at 13:49 -0500, Neal Becker wrote:
> > Robert Kern wrote:
> >
> > > On Tue, Nov 17, 2015 at 3:48 PM, Neal Becker
wrote:
> > >>
> > >> I have an array of sha
them
>
> [0,0,0,0] -> [0,0,0]
> [0,0,0,1] -> [0,0,1]
> [0,0,0,2] -> [0,0,2]
> ...
> [0,0,1,0] -> [0,0,1024]
> [0,0,1,1] -> [0,0,1025]
> [0,0,1,2] -> [0,0,1026]
> ...
A.reshape(A.shape[:-2] + (-1,))
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
1 - 100 of 3145 matches
Mail list logo
