<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 9, 2015 at 7:29 PM, Andrew Barnert <span dir="ltr"><<a href="mailto:abarnert@yahoo.com.dmarc.invalid" target="_blank">abarnert@yahoo.com.dmarc.invalid</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Jan 9, 2015, at 14:36, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
<br>
> (Although the actual signature of linspace gives me a headache. :-)<br>
<br>
</span>I'm assuming you're not talking about the rested and dtype args (which the stdlib wouldn't need), but rather the fact that endpoint changes the meaning of num (you effectively generate num+1 points and discard the last, instead of generating num points).<br></blockquote><div><br></div><div>All of the above, plus the default to n=50. :-)<br><br></div><div>Oh, and the name is odd-sounding for someone not from your world.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I've stumbled over that before, and helped other people with it. But the other way around would be confusing just as often. And the confusion wouldn't be flagged as quickly as it is in numpy (broadcasting mismatched arrays is an error; zipping mismatched sequences is not). And of course it would be a gratuitous incompatibility between the stdlib and numpy.<br>
<br>
All of this implies that there's probably some better way to specify half-open ranges for linspace that nobody has thought of yet. Hopefully someone can think of it now. :)<br>
<br>
Or, failing that, maybe we just don't need half-open linspace in the stdlib. You can always do linspace(0, 1, 5+1)[:-1] or, if you want the other, linspace(0, 1, 5)[:-1]. Either way, what you're asking for is explicit and obvious. And if linspace is a sequence-like view akin to range, this doesn't cost anything. And it's even briefer than using the endpoint argument (especially since in real life you almost always use it as a keyword arg).<br>
<br>
Since Chris seems to have a better intuition than me on how you're usually thinking when you need linspace, hopefully he can chime in on whether this would be intuitive enough, or if we need an actual solution.</blockquote></div><br></div><div class="gmail_extra">I'm guessing that in terms of implementation you might start with this:<br><br>    def  linspace(start, stop, num):<br>        return [(stop*i + start*(num-i)) / num for i in range(num+1)]<br><br></div><div class="gmail_extra">and then refine as follows:<br><br></div><div class="gmail_extra">- make it a lazy sequence, with slicing ability, etc.<br></div><div class="gmail_extra">- numeric tricks to avoid intermediate overflows or numeric instabilities, plus optimizations<br></div><div class="gmail_extra">- while still returning exactly the endpoints at the extremes(*)<br></div><div class="gmail_extra">- and better error checking (num must be an integer > 0)<br></div><div class="gmail_extra">- and support for start/stop being other numeric types (e.g. complex, Fraction, Decimal)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Then bikeshed about the module it should live in. At least you can shut down the bikeshed about the name with "that's what numpy calls it", and ditto about the argument order. Just don't add any of the other features of the numpy version. :-)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">(*) I was going to give the equally naive definition [start + i*step for i in range(num+1)] where step is (stop-start)/num, but that would give away my naiveté even quicker. :-)<br><br></div><div class="gmail_extra">-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>
</div></div>