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
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
___
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
:
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
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
at a run-time,
That's what happens. You instantiate the RandomState class that you want.
> as far as I understood, and the only provided interface to query random
variates is one at a time, just like it is currently the case
> in numpy.random.
--
Robert Kern
__
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
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
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
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.
--
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
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
; >
>
> 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
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
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
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
ange are you referring to?
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
is how isclose(a, b) better than
abs(a-b)<=atol.
You just adjust the value by whichever tolerance is greatest in magnitude.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Sep 30, 2015 at 10:35 AM, Matthieu Brucher <
matthieu.bruc...@gmail.com> wrote:
>
> Yes, obviously, the code has NR parts, so it can't be licensed as BSD
> as it is...
It's not obvious to me, especially after Juha's further c
i Virtanen (assuming everyone on
that list is interested/willing to serve).]
>
> I would ask to be on this initial council by having the rule include
"original contributors of the code" which would basically include Robert
Kern and Pearu Peterson in addition to Chuck Harris (though Pearu&#x
author has agreed in principle to relicense the code as MIT, though has
not yet merged the PR that accomplishes this yet. That said, we'd probably
end up doing a significant amount of rewriting so that we will have a C
implementation of software-uint128 arithmetic.
--
Robert Kern
have a *source* release that
builds on Python 3.5, irrespective of whether or not we have binary wheels
for a couple of platforms up for Python 3.5. So I would encourage a quick
1.9.3 release that incorporates this patch.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Tim, ping me if you want to get dropped from the reply chain, as we are
liable to get more into numpy decision-making. I've dropped python-ideas.]
On Mon, Sep 14, 2015 at 4:34 AM, Tim Peters wrote:
>
> [Robert Kern ]
> >> ...
> >> I'll also recommend th
example.
See this thread:
http://mail.scipy.org/pipermail/numpy-discussion/2015-July/073196.html
Cast your 0 to a uint64 or other unsigned int type to avoid this.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.
On Fri, Jul 24, 2015 at 10:05 AM, wrote:
>
> On Fri, Jul 24, 2015 at 3:46 AM, Robert Kern
wrote:
>>
>> On Wed, Jul 22, 2015 at 7:45 PM, wrote:
>> >
>> > Is there an explanation somewhere of what different basic dtypes mean,
across platforms and pyt
of the numpy scalar
types, and the underscored aliases are convenient for that. Never use the
aliases to the Python builtin types.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
t the rules are concerned with.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
is oldarray.shape?
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
--
Robert Kern
___
NumPy-Discussion mailing
e accurate, it will also make a different number of calls to the
> entropy source, and hence the whole sequence will be affected, even if
> you do set a random seed.
Please reread the proposal at the top of the thread.
--
Robert Kern
___
NumPy-Discussion
d
make changes that allow a strictly wider domain of distribution parameters
(e.g. allowing b==0 where before we only allowed b>0), but we will not make
other enhancements that would change existing good output.
--
Robert Kern
___
NumPy-Discussion
on PyPI. Even with Intel's permission, we would be putting up
proprietary binaries on a page that is explicitly claiming that the files
linked therein are BSD-licensed. The binaries could not be redistributed
with any GPLed module, say, pygsl.
We could host them on numpy.org on t
ave root, try using `perf top` to see what C functions in user
space and kernel space are taking up the most time in your process. If you
see anything like `do_page_fault()`, this, or a similar issue, is your
problem.
--
Robert Kern
___
NumPy-Discuss
and give us just
the line of code with the expression (anecdotally, this is usually how this
scenario goes down). If we have to answer "it depends; is there an
@ortho_indexing decorator at the top of the function?", that's probably a
cure worse than the disease. The properties are
tention; this is nontrivial index manipulation; here is a googleable term
so you can look up what this means". I almost always use the default fancy
indexing, but I'd use the arr.fancy_ix property for the nontrivial cases
just for this alone.
--
Robert Kern
___
On Wed, Apr 8, 2015 at 8:05 PM, Eric Firing wrote:
> Now, can we please get back to consideration of reasonable options?
Sure, but I recommend going back to the actually topical thread (or a new
one), as this one is meta.
--
Robert Kern
___
Nu
On Wed, Apr 8, 2015 at 2:06 AM, Nathaniel Smith wrote:
>
> On Apr 5, 2015 7:04 AM, "Robert Kern" wrote:
> >
> > On Sat, Apr 4, 2015 at 10:38 PM, Nathaniel Smith wrote:
> > >
> > > On Apr 4, 2015 4:12 AM, "Todd" wrote:
> > > &
concrete
proposal in front of us to know what they are. There are ways to mitigate
these consequences, but there are no silver bullets that eliminate them.
And we can compare those consequences to approaches like Jaime's that
achieve a majority of the benefits of such a change without any of
ne sentence that we should tell
> people that we won't consider backcompat breaks, and then in the next
> sentence that of course we actually will consider them (even if we
> almost always reject them). Basically, I think saying one thing and
> doing another is not a good way to buil
System Engineer, Ph.D.
> Blog: http://matt.eifelle.com
> LinkedIn: http://www.linkedin.com/in/matthieubrucher
> Music band: http://liliejay.com/
> _______
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-
On Fri, Mar 13, 2015 at 5:59 PM, Neal Becker wrote:
>
> Robert Kern wrote:
>
> > On Fri, Mar 13, 2015 at 5:34 PM, Neal Becker
wrote:
> >>
> >> It is common that to guarantee good statistical independence between
> > various
> >> random generators,
can always subclass RandomState to override its __deepcopy__.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
nts interpreted?
Broadcast against each other. Roughly equivalent to:
uni = np.array([
np.random.uniform(-0.5, 201),
np.random.uniform(0.5, 201),
])
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman
included in scipy for example?
On the whole, I think I would prefer new functions for this. I assume you
only need variants for argmin() and argmax() and not min() and max(), since
all of the tied values for the latter two would be identical, so returning
the first one is just as good as any
pickle when it otherwise wouldn't,
which is not the intention.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
39/lenna-bug.ipynb
When plt.imshow() is given floating point RGB images, it assumes that each
channel is normalized to 1. You are mixing a 0..255 image with a 0..1
image. Divide `lenna` by 255.0 before you stack it with `_dct`. Or multiply
`_dct` by 255 and cast it t
; will
> use ascii for ascii text.
numpy's 'U' dtype is UCS-4, and this is what Thomas is referring to, not
Python's string type. It cannot have a flexible representation as it *is*
the representation. Python 3's `str` type is opaque, so it can freely
choose how to represe
On Thu, Feb 12, 2015 at 3:22 PM, Neal Becker wrote:
>
> Robert Kern wrote:
>
> > On Thu, Feb 12, 2015 at 3:00 PM, Neal Becker
wrote:
> >>
> >> Robert Kern wrote:
> >>
> >> > On Thu, Feb 12, 2015 at 2:21 PM, Neal Becker
> > wrote:
On Thu, Feb 12, 2015 at 3:00 PM, Neal Becker wrote:
>
> Robert Kern wrote:
>
> > On Thu, Feb 12, 2015 at 2:21 PM, Neal Becker
wrote:
> >>
> >> I need to transmit some data values. These values will be float and
long
> >> values. I need them encoded int
0], dtype=uint8)
>
> (which I'm not certain is correct)
>
> Also, I don't know how to reverse this process
You already had your string ready for transmission with `struct.pack('d',
pi)`.
--
Robert Kern
___
NumPy-Discussion
reWarning.
So VPython is the code that needs to be fixed to do an identity comparison
with None rather than an equality comparison.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Dec 11, 2014 at 4:17 PM, Sebastian Berg
wrote:
>
> On Do, 2014-12-11 at 16:56 +0100, Pierre Haessig wrote:
> > Le 11/12/2014 16:52, Robert Kern a écrit :
> > >
> > > And we already have a numpy.broadcast() function.
> > >
> > >
htt
wer). I don't know much beyond that, but it
is probably worth looking in
>
> AFAICT the cpu backend is a FFTW wrapper.
Indeed.
https://github.com/arrayfire/arrayfire/blob/devel/src/backend/cpu/fft.cpp#L16
--
Robert Kern
___
NumPy-Discussi
s there to give a clue that
this function is not symmetric, and rather has a specific goal in mind.
And we already have a numpy.broadcast() function.
http://docs.scipy.org/doc/numpy/reference/generated/numpy.broadcast.html
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
1 - 100 of 2838 matches
Mail list logo
