The scipy.stats.qqplot and scipy.stats.probplot functions plot expected values
versus actual data values for visualization of fit to a distribution. First a
one-D array of expected percentiles is generated for a sample of size N; then
that is passed to dist.ppf, the per cent point function
On Fri, Jun 10, 2016 at 7:42 AM, Nathaniel Smith wrote:
> On Mon, Jun 6, 2016 at 1:17 PM, Charles R Harris
> wrote:
>>
>> ...
>>
>> It looks to me like users want floats, while developers want the
>> easy path of raising an error. Darn those users, they just make
>> life sooo difficult...
>
> I d
Hi,
I really tried to do my homework before asking this here, but I just
couldn't find the relevant information anywhere...
My question is about the rationale behind forbidding indexing with
floats, i.e.:
>>> x[2.]
__main__:1: VisibleDeprecationWarning: using a non-integer number
instead o
On Fri, Jun 10, 2016 at 12:15 PM, Fabien wrote:
>
> Hi,
>
> I really tried to do my homework before asking this here, but I just
couldn't find the relevant information anywhere...
>
> My question is about the rationale behind forbidding indexing with
floats, i.e.:
>
> >>> x[2.]
> __main__:1: Visib
On 06/10/2016 01:48 PM, Robert Kern wrote:
https://mail.scipy.org/pipermail/numpy-discussion/2012-December/064705.html
https://github.com/numpy/numpy/issues/2810
https://github.com/numpy/numpy/pull/2891
https://github.com/numpy/numpy/pull/3243
https://mail.scipy.org/pipermail/numpy-discussion/201
On 6/10/2016 2:42 AM, Nathaniel Smith wrote:
I dunno, with my user hat on I'd be incredibly surprised / confused /
annoyed if an innocent-looking expression like
np.arange(10) ** 2
started returning floats... having exact ints is a really nice feature
of Python/numpy as compared to R/Javascri
+1 to Alan's point. Having different type behaviour depending on the values
of x and y for np.arange(x) ** y would be awful, and it would also be awful
to have to worry about overflow here...
...
Having said that, it would be equally annoying to not have a way to define
integer powers...
From:
On 06/10/2016 08:10 AM, Alan Isaac wrote:
> Is np.arange(10)**10 also "innocent looking" to a Python user?
This doesn't bother me much because numpy users have to be aware of
overflow issues in lots of other (simple) cases anyway, eg plain
addition and multiplication.
I'll add my +1 for integer p
On Fri, Jun 10, 2016 at 12:42 AM Nathaniel Smith wrote:
> On Mon, Jun 6, 2016 at 1:17 PM, Charles R Harris
> wrote:
> >
> >
> >
> > On Mon, Jun 6, 2016 at 2:11 PM, Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
> >>
> >> Hi Chuck,
> >>
> >> I consider either proposal an improvement, b
On 6/10/2016 1:20 PM, Ian Henriksen wrote:
forcing float output for people who actually want integers is not at all ideal
Yes, there definitely should be a function supporting this.
Alan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On Jun 10, 2016 05:11, "Alan Isaac" wrote:
>
> On 6/10/2016 2:42 AM, Nathaniel Smith wrote:
>>
>> I dunno, with my user hat on I'd be incredibly surprised / confused /
>> annoyed if an innocent-looking expression like
>>
>> np.arange(10) ** 2
>>
>> started returning floats... having exact ints i
On 6/10/2016 1:20 PM, Allan Haldane wrote:
numpy users have to be aware of
overflow issues in lots of other (simple) cases anyway, eg plain
addition and multiplication.
This is not comparable because *almost all* integer combinations
overflow for exponentiation. See the discussion at
https://
On 6/10/2016 1:34 PM, Nathaniel Smith wrote:
You keep pounding on this example. It's a fine example, but, c'mon. **2 is
probably at least 100x more common in real source code. Maybe 1000x more
common. Why should we break the
common case for your edge case?
It is hardly an "edge case".
Again,
On Jun 10, 2016 10:50, "Alan Isaac" wrote:
>
> On 6/10/2016 1:34 PM, Nathaniel Smith wrote:
>>
>> You keep pounding on this example. It's a fine example, but, c'mon. **2
is probably at least 100x more common in real source code. Maybe 1000x more
common. Why should we break the
>> common case for y
On Fri, Jun 10, 2016 at 2:00 PM, Nathaniel Smith wrote:
> On Jun 10, 2016 10:50, "Alan Isaac" wrote:
> >
> > On 6/10/2016 1:34 PM, Nathaniel Smith wrote:
> >>
> >> You keep pounding on this example. It's a fine example, but, c'mon. **2
> is probably at least 100x more common in real source code.
I guess I have one more question; sorry.
Suppose we stipulate that `np.int_(9)**np.int__(10)` should
just overflow, since that appears to be the clear intent of
the (informed) user.
When a Python 3 user writes `np.arange(10)**10`,
how are we to infer the intended type of the output?
(I specify P
Hi,
I just released a new version of the Datarray package:
https://pypi.python.org/pypi/datarray/0.1.0
https://github.com/BIDS/datarray
It's a very lightweight implementation of arrays with labeled axes and
ticks, that allows you to do stuff like:
>>> narr = DataArray(np.zeros((1,2,3)), axes=('
On 06/10/2016 01:50 PM, Alan Isaac wrote:
> Again, **almost all** integer combinations overflow: that's the point.
Don't almost all integer combinations overflow for multiplication as well?
I estimate that for unsigned 32 bit integers, only roughly 1 in 2e8
combinations don't overflow.
The fract
On Fri, Jun 10, 2016 at 12:01 PM Nathaniel Smith wrote:
> On Jun 10, 2016 10:50, "Alan Isaac" wrote:
> >
> > On 6/10/2016 1:34 PM, Nathaniel Smith wrote:
> >>
> >> You keep pounding on this example. It's a fine example, but, c'mon. **2
> is probably at least 100x more common in real source code.
On Fri, Jun 10, 2016 at 12:51 PM, Matthew Brett
wrote:
> If you like the general idea, and you don't mind the pandas
> dependency, `xray` is a much better choice for production code right
> now, and will do the same stuff and more:
>
> https://pypi.python.org/pypi/xray/0.4.1
>
>
Hi Matthew,
Con
On Fri, Jun 10, 2016 at 1:19 PM, Stephan Hoyer wrote:
> On Fri, Jun 10, 2016 at 12:51 PM, Matthew Brett
> wrote:
>>
>> If you like the general idea, and you don't mind the pandas
>> dependency, `xray` is a much better choice for production code right
>> now, and will do the same stuff and more:
>
On 06/10/2016 03:38 PM, Alan Isaac wrote:
np.find_common_type([np.int8],[np.int32])
> dtype('int8')
(np.arange(10,dtype=np.int8)+np.int32(2**10)).dtype
> dtype('int16')
>
> And so on. If these other binary operators upcast based
> on the scalar value, why wouldn't exponentiation?
> I su
I do think one of the main arguments for returning float remains the
analogy with division. I don't know about the rest of you, but it has been
such a relief not to have to tell students any more "you should add a ".",
otherwise it does integer division". For most purposes, it simply shouldn't
matt
23 matches
Mail list logo
