[Numpy-discussion] Behavior of np.random.uniform

[Jaime Fernández del Río]

Hi all,

There is a PR (#7026 ) that
documents the current behavior of np.random.uniform when the low and high
parameters it takes do not conform to the expected low < high. Basically:

   - if low < high, random numbers are drawn from [low, high),
   - if low = high, all random numbers will be equal to low, and
   - if low > high, random numbers are drawn from (high, low] (notice the
   change in the open side of the interval.)

My only worry is that, once we document this, we can no longer claim that
it is a bug.  So I would like to hear from others what do they think.  The
other more or less obvious options would be to:

   - Raise an error, but this would require a deprecation cycle, as people
   may be relying on the current undocumented behavior.
   - Check the inputs and draw numbers from [min(low, high), max(low, high)),
   which is minimally different from current behavior.

I will be merging the current documentation changes in the next few days,
so it would be good if any concerns were voiced before that.

Thanks,

Jaime

-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Behavior of np.random.uniform

[Robert Kern]

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 9:23 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
>> >>
>> >> What does the standard lib do for rand range? I see that randint Is
closed on both ends, so order doesn't matter, though if it raises for b> >
>> > randint is not closed on the high end. The now deprecated
random_integers is the function that does that.
>> >
>> > For floats, it's good to have various interval options. For instance,
in generating numbers that will be inverted or have their log taken it is
good to avoid zero. However, the names 'low' and 'high' are misleading...
>>
>> They are correctly leading the users to the manner in which the author
intended the function to be used. The *implementation* is misleading by
allowing users to do things contrary to the documented intent. ;-)
>>
>> 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 not intended to be used as `uniform(closed_end, open_end)`.
>
> Well, it is possible to make that happen if one is careful or directly
sets the bits in ieee types...

For the unit interval, certainly. For general bounds, I am not so sure.

--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Behavior of np.random.uniform

[Charles R Harris]

On Tue, Jan 19, 2016 at 10:42 AM, Robert Kern  wrote:

> On Tue, Jan 19, 2016 at 5:40 PM, Charles R Harris <
> charlesr.har...@gmail.com> 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 9:23 AM, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
> >> >>
> >> >> What does the standard lib do for rand range? I see that randint Is
> closed on both ends, so order doesn't matter, though if it raises for b then that's a precedent we could follow.
> >> >
> >> > randint is not closed on the high end. The now deprecated
> random_integers is the function that does that.
> >> >
> >> > For floats, it's good to have various interval options. For instance,
> in generating numbers that will be inverted or have their log taken it is
> good to avoid zero. However, the names 'low' and 'high' are misleading...
> >>
> >> They are correctly leading the users to the manner in which the author
> intended the function to be used. The *implementation* is misleading by
> allowing users to do things contrary to the documented intent. ;-)
> >>
> >> 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 not intended to be used as `uniform(closed_end, open_end)`.
> >
> > Well, it is possible to make that happen if one is careful or directly
> sets the bits in ieee types...
>
> For the unit interval, certainly. For general bounds, I am not so sure.
>

Point taken.

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

Re: [Numpy-discussion] Behavior of np.random.uniform

[josef.pktd]

On Tue, Jan 19, 2016 at 12:43 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:

>
>
> On Tue, Jan 19, 2016 at 10:42 AM, Robert Kern 
> wrote:
>
>> On Tue, Jan 19, 2016 at 5:40 PM, Charles R Harris <
>> charlesr.har...@gmail.com> 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 9:23 AM, Chris Barker - NOAA Federal <
>> chris.bar...@noaa.gov> wrote:
>> >> >>
>> >> >> What does the standard lib do for rand range? I see that randint Is
>> closed on both ends, so order doesn't matter, though if it raises for b> then that's a precedent we could follow.
>> >> >
>> >> > randint is not closed on the high end. The now deprecated
>> random_integers is the function that does that.
>> >> >
>> >> > For floats, it's good to have various interval options. For
>> instance, in generating numbers that will be inverted or have their log
>> taken it is good to avoid zero. However, the names 'low' and 'high' are
>> misleading...
>> >>
>> >> They are correctly leading the users to the manner in which the author
>> intended the function to be used. The *implementation* is misleading by
>> allowing users to do things contrary to the documented intent. ;-)
>> >>
>> >> 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 not intended to be used as `uniform(closed_end, open_end)`.
>> >
>> > Well, it is possible to make that happen if one is careful or directly
>> sets the bits in ieee types...
>>
>> For the unit interval, certainly. For general bounds, I am not so sure.
>>
>
> Point taken.
>

What's the practical importance of this. The boundary points have
probability zero, theoretically.

What happens if low and high are only a few nulps apart?

If you clip the distribution to obey boundary rules you create mass points
:)

Josef


>
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] FeatureRequest: support for array construction from iterators

[Stephan Sahm]

just to not prevent it from the black hole - what about integrating
fromiter into array? (see the post by Benjamin Root)

for me personally, taking the first element for deducing the dtype would be
a perfect default way to read generators. If one wants a specific other
dtype, one could specify it like in the current fromiter method.

On 15 December 2015 at 08:08, Stephan Sahm  wrote:

> I would like to further push Benjamin Root's suggestion:
>
> "Therefore, I think it is not out of the realm of reason that passing a
> generator object and a dtype could then delegate the work under the hood to
> np.fromiter()? I would even go so far as to raise an error if one passes a
> generator without specifying dtype to np.array(). The point is to reduce
> the number of entry points for creating numpy arrays."
>
> would this be ok?
>
> On Mon, Dec 14, 2015 at 6:50 PM Robert Kern  wrote:
>
>> 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.
>>
>> --
>> Robert Kern
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Behavior of np.random.uniform

[Chris Barker]

On Tue, Jan 19, 2016 at 9:27 AM, Charles R Harris  wrote:

> On Tue, Jan 19, 2016 at 9:23 AM, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
>
>> What does the standard lib do for rand range? I see that randint Is
>> closed on both ends, so order doesn't matter, though if it raises for b> then that's a precedent we could follow.
>>
>
> randint is not closed on the high end. The now deprecated random_integers
> is the function that does that.
>

I was referring to the stdlib randint:

In [*7*]: [random.randint(2,5) for i in range(10)]

Out[*7*]: [5, 5, 2, 4, 5, 5, 3, 5, 2, 2]
thinking that compatibility with that would be good -- but that ship has
sailed.

randrange is open on the high end, as range is, (duh!)

 [random.randrange(2,5) for i in range(10)]

Out[*9*]: [3, 3, 4, 3, 3, 2, 4, 2, 3, 3]
but you get an exception is low >=high:

In [*10*]: random.randrange(5,2)

ValueError: empty range for randrange() (5,2, -3)
I like the exception idea best -- but backward compatibility and all that.

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should I use pip install numpy in linux?

[Ralf Gommers]

On Tue, Jan 19, 2016 at 5:57 PM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:

>
> > 2) continue to support those users fairly poorly, and at substantial
> > ongoing cost
>
> I'm curious what the cost is for this poor support -- throw the source
> up on PyPi, and we're done. The cost comes in when trying to build
> binaries...
>

I'm sure Nathaniel means the cost to users of failed installs and of numpy
losing users because of that, not the cost of building binaries.

> Option 1 would require overwhelming consensus of the community, which
> > for better or worse is presumably not going to happen while
> > substantial portions of that community are still using pip/PyPI.
>
> Are they? Which community are we talking about? The community I'd like
> to target are web developers that aren't doing what they think of as
> "scientific" applications, but could use a little of the SciPy stack.
> These folks are committed to pip, and are very reluctant to introduce
> a difficult dependency.  Binary wheels would help these folks, but
> that is not a community that exists yet ( or it's small, anyway)
>
> All that being said, I'd be happy to see binary wheels for the core
> SciPy stack on PyPi. It would be nice for people to be able to do a
> bit with Numpy or pandas, it MPL, without having to jump ship to a
> whole new way of doing things.
>

This is indeed exactly why we need binary wheels. Efforts to provide those
will not change our strong recommendation to our users that they're better
off using a scientific Python distribution.

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

[Numpy-discussion] maintenance/1.11.x branched

[Charles R Harris]

Hi All,

I've branched 1.11.x. There is still work to be done, but the branch draws
the line for PRs to be included in 1.11. Experience  teaches that fixups
will needed, but new work/enhancements will be in 1.12.0-dev0.

Please run tests on this branch if you have the time. Travis CI has begun
failing for Python 3.2 due to a bug in pip. I don't know if this is on our
account or something on the Travis end. Thoughts on that are welcome.

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

Re: [Numpy-discussion] Behavior of np.random.uniform

[G Young]

Of the methods defined in *numpy/mtrand.pyx* (excluding helper functions
and *random_integers*, as they are all related to *randint*), *randint* is
the only other function with *low* and *high* parameters.  However, it
enforces *high* > *low*.

Greg

On Tue, Jan 19, 2016 at 1:36 PM, Benjamin Root  wrote:

> Are there other functions where this behavior may or may not be happening?
> If it isn't consistent across all np.random functions, it probably should
> be, one way or the other.
>
> Ben Root
>
> On Tue, Jan 19, 2016 at 5:10 AM, Jaime Fernández del Río <
> jaime.f...@gmail.com> wrote:
>
>> Hi all,
>>
>> There is a PR (#7026 ) that
>> documents the current behavior of np.random.uniform when the low and high
>> parameters it takes do not conform to the expected low < high. Basically:
>>
>>- if low < high, random numbers are drawn from [low, high),
>>- if low = high, all random numbers will be equal to low, and
>>- if low > high, random numbers are drawn from (high, low] (notice
>>the change in the open side of the interval.)
>>
>> My only worry is that, once we document this, we can no longer claim that
>> it is a bug.  So I would like to hear from others what do they think.  The
>> other more or less obvious options would be to:
>>
>>- Raise an error, but this would require a deprecation cycle, as
>>people may be relying on the current undocumented behavior.
>>- Check the inputs and draw numbers from [min(low, high), max(low,
>>high)), which is minimally different from current behavior.
>>
>> I will be merging the current documentation changes in the next few days,
>> so it would be good if any concerns were voiced before that.
>>
>> Thanks,
>>
>> Jaime
>>
>> --
>> (\__/)
>> ( O.o)
>> ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
>> de dominación mundial.
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Behavior of np.random.uniform

[Benjamin Root]

Are there other functions where this behavior may or may not be happening?
If it isn't consistent across all np.random functions, it probably should
be, one way or the other.

Ben Root

On Tue, Jan 19, 2016 at 5:10 AM, Jaime Fernández del Río <
jaime.f...@gmail.com> wrote:

> Hi all,
>
> There is a PR (#7026 ) that
> documents the current behavior of np.random.uniform when the low and high
> parameters it takes do not conform to the expected low < high. Basically:
>
>- if low < high, random numbers are drawn from [low, high),
>- if low = high, all random numbers will be equal to low, and
>- if low > high, random numbers are drawn from (high, low] (notice the
>change in the open side of the interval.)
>
> My only worry is that, once we document this, we can no longer claim that
> it is a bug.  So I would like to hear from others what do they think.  The
> other more or less obvious options would be to:
>
>- Raise an error, but this would require a deprecation cycle, as
>people may be relying on the current undocumented behavior.
>- Check the inputs and draw numbers from [min(low, high), max(low,
>high)), which is minimally different from current behavior.
>
> I will be merging the current documentation changes in the next few days,
> so it would be good if any concerns were voiced before that.
>
> Thanks,
>
> Jaime
>
> --
> (\__/)
> ( O.o)
> ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
> de dominación mundial.
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Behavior of np.random.uniform

[Marten van Kerkwijk]

For what it is worth, the current behaviour seems the most logical to me,
i.e., that the first limit is always the one that is included in the
interval, and the second is not. -- Marten
​
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Behavior of np.random.uniform

[G Young]

In rand range, it raises an exception if low >= high.

I should also add that AFAIK enforcing low >= high with floats is a lot
trickier than it is for integers.  I have been knee-deep in corner cases
for some time with *randint* where numbers that are visually different are
cast as the same number by *numpy* due to rounding and representation
issues.  That situation only gets worse with floats.

Greg

On Tue, Jan 19, 2016 at 4:23 PM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:

> What does the standard lib do for rand range? I see that randint Is closed
> on both ends, so order doesn't matter, though if it raises for b that's a precedent we could follow.
>
> (Sorry, on a phone, can't check)
>
> CHB
>
>
>
> On Jan 19, 2016, at 6:21 AM, G Young  wrote:
>
> Of the methods defined in *numpy/mtrand.pyx* (excluding helper functions
> and *random_integers*, as they are all related to *randint*), *randint* is
> the only other function with *low* and *high* parameters.  However, it
> enforces *high* > *low*.
>
> Greg
>
> On Tue, Jan 19, 2016 at 1:36 PM, Benjamin Root 
> wrote:
>
>> Are there other functions where this behavior may or may not be
>> happening? If it isn't consistent across all np.random functions, it
>> probably should be, one way or the other.
>>
>> Ben Root
>>
>> On Tue, Jan 19, 2016 at 5:10 AM, Jaime Fernández del Río <
>> jaime.f...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> There is a PR (#7026 ) that
>>> documents the current behavior of np.random.uniform when the low and
>>> high parameters it takes do not conform to the expected low < high.
>>> Basically:
>>>
>>>- if low < high, random numbers are drawn from [low, high),
>>>- if low = high, all random numbers will be equal to low, and
>>>- if low > high, random numbers are drawn from (high, low] (notice
>>>the change in the open side of the interval.)
>>>
>>> My only worry is that, once we document this, we can no longer claim
>>> that it is a bug.  So I would like to hear from others what do they think.
>>> The other more or less obvious options would be to:
>>>
>>>- Raise an error, but this would require a deprecation cycle, as
>>>people may be relying on the current undocumented behavior.
>>>- Check the inputs and draw numbers from [min(low, high), max(low,
>>>high)), which is minimally different from current behavior.
>>>
>>> I will be merging the current documentation changes in the next few
>>> days, so it would be good if any concerns were voiced before that.
>>>
>>> Thanks,
>>>
>>> Jaime
>>>
>>> --
>>> (\__/)
>>> ( O.o)
>>> ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus
>>> planes de dominación mundial.
>>>
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@scipy.org
>>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>>>
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should I use pip install numpy in linux?

[Chris Barker - NOAA Federal]

> Last month, numpy had ~740,000 downloads from PyPI,

Hm, given that Windows and Linux wheels have not been available, then
that's mostly source installs anyway. Or failed installs  -- no
shortage of folks trying to pip install numpy on Windows and then
having questions about why it doesn't work. Unfortunately, there is no
way to know if pip downloads are successful, or if people pip install
Numpy, then find out they need some other non-pip-installable
packages, and go find another system.

> and there are
> probably hundreds of third-party projects that distribute via PyPI and
> depend on numpy.

I'm not so sure -- see above--as pip install has not been reliable for
Numpy for ages, I doubt it. Not that they aren't there, but I doubt
it's the primary distribution mechanism. There's been an explosion in
the use of conda, and there have been multiple other options for ages:
Canopy, python(x,y), Gohlke's builds, etc.

So at this point, I think the only people using pip are folks that are
set up to build -- mostly Linux. (though Mathew's efforts with the Mac
wheels may have created a different story on the Mac).



> So concretely our options as a project are:
> 1) drop support for pip/PyPI and abandon those users

There is no one to abandon -- except the Mac users -- we haven't
supported them yet.

> 2) continue to support those users fairly poorly, and at substantial
> ongoing cost

I'm curious what the cost is for this poor support -- throw the source
up on PyPi, and we're done. The cost comes in when trying to build
binaries...


> Option 1 would require overwhelming consensus of the community, which
> for better or worse is presumably not going to happen while
> substantial portions of that community are still using pip/PyPI.

Are they? Which community are we talking about? The community I'd like
to target are web developers that aren't doing what they think of as
"scientific" applications, but could use a little of the SciPy stack.
These folks are committed to pip, and are very reluctant to introduce
a difficult dependency.  Binary wheels would help these folks, but
that is not a community that exists yet ( or it's small, anyway)

All that being said, I'd be happy to see binary wheels for the core
SciPy stack on PyPi. It would be nice for people to be able to do a
bit with Numpy or pandas, it MPL, without having to jump ship to a
whole new way of doing things.

But we should be realistic about how far it can go.

> If
> folks interested in pushing things forward can convince them to switch
> to conda instead then the calculation changes, but that's just not the
> kind of thing that numpy-the-project can do or not do.

We can't convince anybody, but we can decide where to expend our efforts.

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

Re: [Numpy-discussion] Behavior of np.random.uniform

[Chris Barker - NOAA Federal]

What does the standard lib do for rand range? I see that randint Is closed
on both ends, so order doesn't matter, though if it raises for b wrote:

Of the methods defined in *numpy/mtrand.pyx* (excluding helper functions
and *random_integers*, as they are all related to *randint*), *randint* is
the only other function with *low* and *high* parameters.  However, it
enforces *high* > *low*.

Greg

On Tue, Jan 19, 2016 at 1:36 PM, Benjamin Root  wrote:

> Are there other functions where this behavior may or may not be happening?
> If it isn't consistent across all np.random functions, it probably should
> be, one way or the other.
>
> Ben Root
>
> On Tue, Jan 19, 2016 at 5:10 AM, Jaime Fernández del Río <
> jaime.f...@gmail.com> wrote:
>
>> Hi all,
>>
>> There is a PR (#7026 ) that
>> documents the current behavior of np.random.uniform when the low and high
>> parameters it takes do not conform to the expected low < high. Basically:
>>
>>- if low < high, random numbers are drawn from [low, high),
>>- if low = high, all random numbers will be equal to low, and
>>- if low > high, random numbers are drawn from (high, low] (notice
>>the change in the open side of the interval.)
>>
>> My only worry is that, once we document this, we can no longer claim that
>> it is a bug.  So I would like to hear from others what do they think.  The
>> other more or less obvious options would be to:
>>
>>- Raise an error, but this would require a deprecation cycle, as
>>people may be relying on the current undocumented behavior.
>>- Check the inputs and draw numbers from [min(low, high), max(low,
>>high)), which is minimally different from current behavior.
>>
>> I will be merging the current documentation changes in the next few days,
>> so it would be good if any concerns were voiced before that.
>>
>> Thanks,
>>
>> Jaime
>>
>> --
>> (\__/)
>> ( O.o)
>> ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
>> de dominación mundial.
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should I use pip install numpy in linux?

[Chris Barker]

hmm -- didn't mean to rev this up quite so much -- sorry!

But it's a good conversation to have, so...


On Fri, Jan 15, 2016 at 1:08 PM, Benjamin Root  wrote:

> That being said... I take exception to your assertion that anaconda is
> *the* solution to the packaging problem.
>

I think we need to keep some things straight here:

 "conda" is a binary package management system.

"Anaconda" is a python (and other stuff) distribution, built with conda.

In practice, everyone ( I know of ) uses the Anaconda distribution (or at
least the default conda channel) when using conda, but in theory, you could
maintain your an entirely distinct distribution with conda as the tool.

Also in practice, conda is so easy because continuum has done the hard work
of building a lot of the packages we all need -- there are still a lot
being maintained by the community in various ways, but frankly, we do
depend on continuum for all the hard work. But working on/with conda does
not lock you into that if you think it's not serving your needs.

And this discussion, (for me anyway) is about tools and the way forward,
not existing packages.

So onward!


> I still have a number of issues, particularly with the interactions of
> GDAL, shapely, and Basemap (they all seek out libgeos_c differently), and I
> have to use my own build of GDAL to enable many of the features that we use
> (the vanilla GDAL put out by Continuum just has the default options, and is
> quite limited).
>

Yeah, GDAL/OGR is a F%$#ing nightmare -- and I do wish that Anaconda had a
better build, but frankly, there is no system that's going to make that any
easier -- do any of the Linux distros ship a really good compatible, up to
date set of these libs -- and OS-X and Windows? yow! (Though Chris Gohlke
is a wonder!)


> If I don't set up my environment *just right* one of those packages will
> fail to import in some way due to being unable to find their particular
> version of libgeos_c. I haven't figure it out exactly why this happens, but
> it is very easy to break such an environment this way after an update.
>

Maybe conda could be improved to make this easier, I don't know (though do
checkout out the IOOS channel on anaconda.org Filipe has done some nice
work on this)



>  In a clutch, we had our IT staff manually build mod_wsgi against
> anaconda's python, but they weren't too happy about that, due to mod_wsgi
> no longer getting updated via yum.
>

I'm not sure how pip helps you out here, either. Sure for easy-to-compile
from source packages, you can just pip install, and you'll get a package
compatible with your (system) python. But binary wheels will give you the
same headaches -- so you're back to expecting your linux dstro to provide
everything, which they don't :-(

I understand that the IT folks want everything to come from their OS vendor
-- they like that -- but it simply isn't practical for scipy-based web
services. And once you've got most of your stack coming from another
source, is it really a big deal for python to come from somewhere else also
(and apache, and ???) -- conda at least is a technology that _can_ provide
an integrated system that includes all this -- I don't hink you're going to
be pip-installling apache anytime soon! (or node, or ???)


> If anaconda was the end-all, be-all solution, then it should just be a
> simple matter to do "conda install mod_wsgi". But the design of conda is
> that it is intended to be a user-space package-manager.
>

Then you can either install it as the web user (or apache user), or install
it as a system access. I haven't done this, but I don't think it all that
hard -- you're then going to need to sudo to install/upgrade anything new,
but that's expected.

So, again, I love conda for what it can do when it works well. I only take
> exception to the notion that it can address *all* problems, because there
> are some problems that it just simply isn't properly situated for.
>

But pip isn't situated for any of these either -- I'm still confused as to
the point here.

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Behavior of np.random.uniform

[Alan G Isaac]

In principle, if we are describing an *interval*, that is
the right thing to do:
https://en.wikipedia.org/wiki/Interval_(mathematics)#Including_or_excluding_endpoints

Alan Isaac


On 1/19/2016 9:21 AM, G Young wrote:

Of the methods defined in *numpy/mtrand.pyx* (excluding helper functions and 
*random_integers*, as they are all related to *randint*), *randint*//is
the only other function with /low/ and /high/ parameters.  However, it enforces 
/high/ > /low/.


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

Re: [Numpy-discussion] Behavior of np.random.uniform

[Charles R Harris]

On Tue, Jan 19, 2016 at 9:23 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:

> What does the standard lib do for rand range? I see that randint Is closed
> on both ends, so order doesn't matter, though if it raises for b that's a precedent we could follow.
>

randint is not closed on the high end. The now deprecated random_integers
is the function that does that.

For floats, it's good to have various interval options. For instance, in
generating numbers that will be inverted or have their log taken it is good
to avoid zero. However, the names 'low' and 'high' are misleading...

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

Re: [Numpy-discussion] Behavior of np.random.uniform

[Charles R Harris]

On Tue, Jan 19, 2016 at 10:27 AM, 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:
>
>> What does the standard lib do for rand range? I see that randint Is
>> closed on both ends, so order doesn't matter, though if it raises for b> then that's a precedent we could follow.
>>
>
> randint is not closed on the high end. The now deprecated random_integers
> is the function that does that.
>
> For floats, it's good to have various interval options. For instance, in
> generating numbers that will be inverted or have their log taken it is good
> to avoid zero. However, the names 'low' and 'high' are misleading...
>
>
Note that we also have both arange and linspace for floats. What works well
for integers is not always the best for floats.

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

Re: [Numpy-discussion] Behavior of np.random.uniform

[Sebastian Berg]

On Di, 2016-01-19 at 16:28 +, G Young wrote:
> In rand range, it raises an exception if low >= high.
> 
> I should also add that AFAIK enforcing low >= high with floats is a
> lot trickier than it is for integers.  I have been knee-deep in
> corner cases for some time with randint where numbers that are
> visually different are cast as the same number by numpy due to
> rounding and representation issues.  That situation only gets worse
> with floats.
> 

Well, actually random.uniform docstring says:

Get a random number in the range [a, b) or [a, b] depending on
rounding.

and is true to the word, it does not care about the relative value of a
vs. b. So my guess it is identical to your version (though one could
check a bit more careful with corner cases)
Quick check would suggests it is the same (though I guess if there was
a slight rounding issue somewhere, it could be different):


>>> np.random.set_state(('MT19937', random.getstate()[1][:-1], 
>>> random.getstate()[1][-1]))

Will enable you to draw the same numbers with random.uniform and
np.random.uniform.

- Sebastian


> Greg
> 
> On Tue, Jan 19, 2016 at 4:23 PM, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
> > What does the standard lib do for rand range? I see that randint Is
> > closed on both ends, so order doesn't matter, though if it raises
> > for b > 
> > (Sorry, on a phone, can't check)
> > 
> > CHB
> > 
> > 
> > 
> > On Jan 19, 2016, at 6:21 AM, G Young  wrote:
> > 
> > > Of the methods defined in numpy/mtrand.pyx (excluding helper
> > > functions and random_integers, as they are all related to
> > > randint), randint is the only other function with low and high
> > >  parameters.  However, it enforces high > low.
> > > 
> > > Greg
> > > 
> > > On Tue, Jan 19, 2016 at 1:36 PM, Benjamin Root <
> > > ben.v.r...@gmail.com> wrote:
> > > > Are there other functions where this behavior may or may not be
> > > > happening? If it isn't consistent across all np.random
> > > > functions, it probably should be, one way or the other.
> > > > 
> > > > Ben Root
> > > > 
> > > > On Tue, Jan 19, 2016 at 5:10 AM, Jaime Fernández del Río <
> > > > jaime.f...@gmail.com> wrote:
> > > > > Hi all,
> > > > > 
> > > > > There is a PR (#7026) that documents the current behavior of
> > > > > np.random.uniform when the low and high parameters it takes
> > > > > do not conform to the expected low < high. Basically:
> > > > > if low < high, random numbers are drawn from [low, high),
> > > > > if low = high, all random numbers will be equal to low, and 
> > > > > if low > high, random numbers are drawn from (high, low]
> > > > > (notice the change in the open side of the interval.)
> > > > > My only worry is that, once we document this, we can no
> > > > > longer claim that it is a bug.  So I would like to hear from
> > > > > others what do they think.  The other more or less obvious
> > > > > options would be to:
> > > > > Raise an error, but this would require a deprecation cycle,
> > > > > as people may be relying on the current undocumented
> > > > > behavior.
> > > > > Check the inputs and draw numbers from [min(low, high),
> > > > > max(low, high)), which is minimally different from current
> > > > > behavior.
> > > > > I will be merging the current documentation changes in the
> > > > > next few days, so it would be good if any concerns were
> > > > > voiced before that.
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Jaime
> > > > > 
> > > > > -- 
> > > > > (\__/)
> > > > > ( O.o)
> > > > > ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale
> > > > > en sus planes de dominación mundial.
> > > > > 
> > > > > ___
> > > > > NumPy-Discussion mailing list
> > > > > NumPy-Discussion@scipy.org
> > > > > https://mail.scipy.org/mailman/listinfo/numpy-discussion
> > > > > 
> > > > 
> > > > ___
> > > > NumPy-Discussion mailing list
> > > > NumPy-Discussion@scipy.org
> > > > https://mail.scipy.org/mailman/listinfo/numpy-discussion
> > > > 
> > > ___
> > > NumPy-Discussion mailing list
> > > NumPy-Discussion@scipy.org
> > > https://mail.scipy.org/mailman/listinfo/numpy-discussion
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > https://mail.scipy.org/mailman/listinfo/numpy-discussion
> > 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion

signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Behavior of np.random.uniform

[Robert Kern]

On Tue, Jan 19, 2016 at 5:27 PM, Charles R Harris 
wrote:
>

> On Tue, Jan 19, 2016 at 9:23 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
>>
>> What does the standard lib do for rand range? I see that randint Is
closed on both ends, so order doesn't matter, though if it raises for b
> randint is not closed on the high end. The now deprecated random_integers
is the function that does that.
>
> For floats, it's good to have various interval options. For instance, in
generating numbers that will be inverted or have their log taken it is good
to avoid zero. However, the names 'low' and 'high' are misleading...

They are correctly leading the users to the manner in which the author
intended the function to be used. The *implementation* is misleading by
allowing users to do things contrary to the documented intent. ;-)

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 not intended to be used as `uniform(closed_end, open_end)`.

--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Behavior of np.random.uniform

[Charles R Harris]

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 9:23 AM, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
> >>
> >> What does the standard lib do for rand range? I see that randint Is
> closed on both ends, so order doesn't matter, though if it raises for b then that's a precedent we could follow.
> >
> > randint is not closed on the high end. The now deprecated
> random_integers is the function that does that.
> >
> > For floats, it's good to have various interval options. For instance, in
> generating numbers that will be inverted or have their log taken it is good
> to avoid zero. However, the names 'low' and 'high' are misleading...
>
> They are correctly leading the users to the manner in which the author
> intended the function to be used. The *implementation* is misleading by
> allowing users to do things contrary to the documented intent. ;-)
>
> 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 not intended to be used as `uniform(closed_end, open_end)`.
>

Well, it is possible to make that happen if one is careful or directly sets
the bits in ieee types...

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

Re: [Numpy-discussion] Behavior of np.random.uniform

[Robert Kern]

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:
> >>
> >> What does the standard lib do for rand range? I see that randint Is
closed on both ends, so order doesn't matter, though if it raises for b >
> > randint is not closed on the high end. The now deprecated
random_integers is the function that does that.
> >
> > For floats, it's good to have various interval options. For instance,
in generating numbers that will be inverted or have their log taken it is
good to avoid zero. However, the names 'low' and 'high' are misleading...
>
> They are correctly leading the users to the manner in which the author
intended the function to be used. The *implementation* is misleading by
allowing users to do things contrary to the documented intent. ;-)
>
> 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 not intended to be used as `uniform(closed_end, open_end)`.

There are special cases that *can* be implemented and are worth doing so as
they are building blocks for other distributions that do need to avoid 0 or
1 as you say. Full-featured RNG suites do offer these:

  [0, 1]
  [0, 1)
  (0, 1]
  (0, 1)

--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion