Re: [Numpy-discussion] Integers to negative integer powers, time for a decision.
On 10/7/2016 9:12 PM, Charles R Harris wrote: *Always return a float * /Pluses/ * Computational convenience Is the behavior of C++11 of any relevance to the choice? http://www.cplusplus.com/reference/cmath/pow/ Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] coordinate bounds
Is there a numpy equivalent to Mma's CoordinateBounds command? http://reference.wolfram.com/language/ref/CoordinateBounds.html Thanks, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] weighted random choice in Python
On 8/16/2016 4:06 AM, Ralf Gommers wrote: The whole enhancement request doesn't look very interesting imho. Because the functionality is already in NumPy, or because it is easily user-written? Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] weighted random choice in Python
It seems that there may soon be movement on this enhancement request: http://bugs.python.org/issue18844 The API is currently under discussion. If this decision might interact with NumPy in any way, it would be good to have that documented now. (See Raymond Hettinger's comment today.) Cheers, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Picking rows with the first (or last) occurrence of each key
1. This is not a NumPy question; StackExchange would be more appropriate. 2. Do some bookkeeping: def initialKeyFilter(data, length, invert=False): result = list() seen = set() if invert: data = reversed(data) for datum in data: k = tuple(datum[:length]) if (k not in seen): result.append(datum) seen.add(k) if invert: result.reverse() return result Cheers, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers, let's make a decision
On 6/20/2016 5:59 PM, Nathaniel Smith wrote: If you have the time to check for existing bug reports about this, and file a new bug if you don't find one, then it'd be appreciated. https://github.com/numpy/numpy/issues/7770 Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers, let's make a decision
On 6/10/2016 8:28 PM, Allan Haldane wrote:
My understanding is that numpy never upcasts based on the values, it
upcasts based on the datatype ranges.
http://docs.scipy.org/doc/numpy-1.10.1/reference/ufuncs.html#casting-rules
>>> (np.int64(2**6)*np.arange(5,dtype=np.int8)).dtype
dtype('int8')
>>> (np.int64(2**7)*np.arange(5,dtype=np.int8)).dtype
dtype('int16')
fwiw,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers, let's make a decision
On 6/13/2016 1:54 PM, Marten van Kerkwijk wrote: 1. What in principle is the best return type for int ** int (which Josef I think most properly rephrased as whether `**` should be thought of as a float operator, like `/` in python3 and `sqrt` etc.); Perhaps the question is somewhat different. Maybe it is: what type should a user expect when the exponent is a Python int? The obvious choices seem to be an object array of Python ints, or an array of floats. So far, nobody has proposed the former, and concerns have been expressed about the latter. More important, either would break the rule that the scalar type is not important in array operations, which seems like a good general rule (useful and easy to remember). How much commitment is there to such a rule? E.g., np.int64(2**7)*np.arange(5,dtype=np.int8) violates this. One thing that has come out of this discussion for me is that the actual rules in play are hard to keep track of. Are they all written down in one place? I suspect there is general support for the idea that if someone explicitly specifies the same dtype for the base and the exponent then the result should also have that dtype. I think this is already true for array exponentiation and for scalar exponentiation. One other thing that a user might expect, I believe, is that any type promotion rules for scalars and arrays will be the same. This is not currently the case, and that feels like an inconsistency. But is it an inconsistency? If the rule is that that array type dominates the scalar type, that may be understandable, but then it should be a firm rule. In this case, an exponent that is a Python int should not affect the dtype of the (array) result. In sum, as a user, I've come around to Chuck's original proposal: integers raised to negative integer powers raise an error. My reason for coming around is that I believe it meshes well with a general rule that in binary operations the scalar dtypes should not influence the dtype of an array result. Otoh, it is unclear to me how much commitment there is to that rule. Thanks in advance to anyone who can help me understand better the issues in play. Cheers, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers, let's make a decision
On 6/13/2016 4:47 AM, Antoine Pitrou wrote: Currently, the choice is simple: if you want an int output, have an int input; if you want a float output, have a float output. That is a misunderstanding, which may be influencing the discussion. Examples of complications: >>> type(np.int8(2)**2) >>> type(np.uint64(2)**np.int8(2)) I don't think anyone has proposed first principles from which the desirable behavior could be deduced. I do think reference to the reasoning used by other languages in making this decision could be helpful. Alan Isaac (on Windows) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers, let's make a decision
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 Python 3, since it has a unified treatment of integers.)
Of course:
>>> np.find_common_type([np.int32],[int])
dtype('int32')
If this were indeed an enforced numpy convention, I would
see better the point of view on the integer exponentiation
case. But how does that reconcile with:
>>> 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 suppose the answer is: they upcast only insofar
as necessary to fit the scalar value, which I see is
a simple and enforceable rule. However, that seems the wrong
rule for exponentiation, and in fact it is not in play:
>>> (np.int8(2)**2).dtype
dtype('int32')
OK, my question to those who have argued a**2 should
produce an int32 when a is an int32: what if a is an int8?
(Obviously the overflow problem is becoming extremely pressing ...)
Thanks,
Alan
PS Where are these casting rules documented?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers, let's make a decision
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, **almost all** integer combinations overflow: that's the point. If you were promoting to a Python long integer, that would change things. But hobbling a whole operator so that people don't have to say `a*a` seems absurdly wasteful. Additionally, returning floats provides a better match to Python's behavior (i.e., it allows sensible handling of negative powers). Users who really want in output and understand overflow should be supported with a function. Anyway, I've said my piece and will shut up now. Cheers, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers, let's make a decision
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://wiki.haskell.org/Power_function http://stackoverflow.com/questions/6400568/exponentiation-in-haskell Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers, let's make a decision
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 https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers, let's make a decision
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/Javascript, and while it's true that int64 can overflow, there are also large powers that can be more precisely represented as int64 than float. Is np.arange(10)**10 also "innocent looking" to a Python user? Also, I am confused by what "large powers" means in this context. Is 2**40 a "large power"? Finally, is np.arange(1,3)**-2 "innocent looking" to a Python user? Cheers, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers, let's make a decision
On 6/4/2016 10:23 PM, Charles R Harris wrote: From my point of view, backwards compatibility is the main reason for choosing 1, otherwise I'd pick 2. If it weren't so easy to get floating point by using floating exponents I'd probably choose differently. As an interested user, I offer a summary of some things I believe are being claimed about the two proposals on the table (for int**int), which are are: 1. raise an error for negative powers 2. always return float Here is a first draft comparison (for int**int only) Proposal 1. effectively throws away an operator - true in this: np.arange(10)**10 already overflows even for int32 much less smaller sizes, and negative powers are now errors - fale in this: you can change an argument to float Proposal 1. effectively behaves more like Python - true in this: for a very small range of numbers, int**int will return int in Python 2 - false in this: In Python, negative exponents produce floats, and int**int does not overflow Proposal 1 is more backwards compatible: true, but this really only affects int**2 (larger arguments quickly overflow) Proposal 2 is a better match for other languages: basically true (see e.g., C++'s overloaded `pow`) Proposal 2 better satisfies the principle of least surprise: probably true for most users, possibly false for some Feel free to add, correct, modify. I think there is a strong argument to always return float, and the real question is whether it is strong enough tosacrifice backwards compatibility. Hope this summary is of some use and not too tendentious, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers
On 5/24/2016 3:57 PM, Eric Moore wrote: Changing np.arange(10)**3 to have a non-integer dtype seems like a big change. What about np.arange(100)**5? Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers
On 5/24/2016 1:41 PM, Matthew Brett wrote: It's a well-understood promise though - you always have to be careful of integer overflow. Of course. But **almost all** cases overflow. And "well understood" assume a certain sophistication of the user, while `arange` will certainly be used by beginners. Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers
On 5/24/2016 1:36 PM, Eric Moore wrote: How much code will break if we make that change? Since even arange(10)**10 is already broken, there will probably not be much new breakage. But under any of the new proposals, *something* will break. So the question is, which shows the most foresight? Having (**) actually work seems worth quite a lot. Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers
On 5/24/2016 1:19 PM, Stephan Hoyer wrote: the int ** 2 example feels quite compelling to me Yes, but that one case is trivial: a*a And at least as compelling is not have a**-2 fail and not being tricked by say np.arange(10)**10. The latter is a promise of hidden errors. Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers
On 5/24/2016 10:03 AM, Marten van Kerkwijk wrote:
The error on int ** (-int) is OK with me too (even though I prefer just
returning floats).
What exactly is the argument against *always* returning float
(even for positive integer exponents)? Relevant context is:
- int ** int will often ("usually") overflow
- a numpy function cd meet specialized exponentiation needs
Thanks,
Alan Isaac
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers
Yes, I was referring to `pow`, but I had in mind the C++ version, which is overloaded: http://www.cplusplus.com/reference/cmath/pow/ Cheers, Alan On 5/20/2016 4:27 PM, Warren Weckesser wrote: C doesn't have an exponentiation operator. The C math library has pow, powf and powl, which (like any C functions) are explicitly typed. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Integers to integer powers
On 5/19/2016 11:30 PM, Nathaniel Smith wrote: the last bad option IMHO would be that we make int ** (negative int) an error in all cases, and the error message can suggest that instead of writing np.array(2) ** -2 they should instead write np.array(2) ** -2.0 (And similarly for np.int64(2) ** -2 versus np.int64(2) ** -2.0.) Fwiw, Haskell has three exponentiation operators because of such ambiguities. I don't use C, but I think the contrasting decision there was to always return a double, which has a clear attraction since for any fixed-width integral type, most of the possible input pairs overflow the type. My core inclination would be to use (what I understand to be) the C convention that integer exponentiation always produces a double, but to support dtype-specific exponentiation with a function. But this is just a user's perspective. Cheers, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndarray.T2 for 2D transpose
On 4/8/2016 5:13 PM, Nathaniel Smith wrote: he doesn't want 2d matrices, he wants tools that make it easy to work with stacks of 2d matrices stored in 2-or-more-dimensional arrays. Like `map`? Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndarray.T2 for 2D transpose
On 4/8/2016 4:28 PM, Ian Henriksen wrote: The biggest things to me are having a broadcasting 2D transpose and having some form of transpose that doesn't silently pass 1D arrays through unchanged. This comment, like much of this thread, seems to long for the matrix class but not want to actually use it. It seems pretty simple to me: if you want everything forced to 2d, always use the matrix class. If you want to use arrays, they work nicely now, and they work as expected once you understand what you are working with. (I.e., *not* matrices.) Btw, numpy.outer(a, b) produces an outer product. This may be off topic, but it seemed to me that some of the discussion overlooks this. I suggest that anyone who thinks numpy is falling short in this area point out how Mma has addressed this shortcoming. Wolfram will never be accused of a reluctance to add functions when there is a perceived need ... Cheers, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndarray.T2 for 2D transpose
On 4/6/2016 1:47 PM, Todd wrote: My suggestion is that this explicitly increases the number of dimensions to at least 2. The result will always have at least 2 dimensions. So 0D -> 2D, 1D -> 2D, 2D -> 2D, 3D -> 3D, 4D -> 4D, etc. So this would be equivalent to the existing `atleast_2d` function. I truly hope nothing is done like this. But underlying the proposal is apparently the idea that there be an attribute equivalent to `atleast_2d`. Then call it `d2p`. You can now have `a.d2p.T` which is a lot more explicit and general than say `a.T2`, while requiring only 3 more keystrokes. (It's still horribly ugly, though, and I hope this too is dismissed.) Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndarray.T2 for 2D transpose
On 4/5/2016 10:11 PM, Todd wrote: When you try to transpose a 1D array, it does nothing. This is the correct behavior, since it transposing a 1D array is meaningless. However, this can often lead to unexpected errors since this is rarely what you want. You can convert the array to 2D, using `np.atleast_2d` or `arr[None]`, but this makes simple linear algebra computations more difficult. I propose adding an argument to transpose, perhaps called `expand` or `expanddim`, which if `True` (it is `False` by default) will force the array to be at least 2D. A shortcut property, `ndarray.T2`, would be the same as `ndarray.transpose(True)`. Use `dot`. E.g., m.dot(a) hth, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] proposal: new logspace without the log in the argument
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, so this doesn't violate the van Rossum Rule of Function Signatures. Would such a new function correct the apparent mistake (?) of `linspace` including the endpoint by default? Or is the current API justified by its Matlab origins? (Or have I missed the point altogether?) If this query is annoying, please ignore it. It is not meant to be. Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] making "low" optional in numpy.randint
On 2/17/2016 7:01 PM, Juan Nunez-Iglesias wrote: Notice the limitation "1D array-like". http://docs.scipy.org/doc/numpy-1.10.0/reference/generated/numpy.random.choice.html "If an int, the random sample is generated as if a was np.arange(n)" hth, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] making "low" optional in numpy.randint
On 2/17/2016 6:48 PM, Juan Nunez-Iglesias wrote: Also fwiw, I think the 0-based, half-open interval is one of the best features of Python indexing and yes, I do use random integers to index into my arrays and would not appreciate having to litter my code with "-1" everywhere. http://docs.scipy.org/doc/numpy-1.10.0/reference/generated /numpy.random.choice.html fwiw, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] making "low" optional in numpy.randint
On 2/17/2016 3:42 PM, Robert Kern wrote: random.randint() was the one big exception, and it was considered a mistake for that very reason, soft-deprecated in favor of random.randrange(). randrange also has its detractors: https://code.activestate.com/lists/python-dev/138358/ and following. I think if we start citing persistant conventions, the persistent convention across *many* languages that the bounds provided for a random integer range are inclusive also counts for something, especially when the names are essentially shared. But again, I am just trying to be clear about what is at issue, not push for a change. I think citing non-existent standards is not helpful. I think the discrepancy between the Python standard library and numpy for a function going by a common name is harmful. (But then, I teach.) fwiw, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] making "low" optional in numpy.randint
On 2/17/2016 12:28 PM, G Young wrote: Perhaps, but we are not coding in Haskell. We are coding in Python, and the standard is that the endpoint is excluded, which renders your point moot I'm afraid. I am not sure what "standard" you are talking about. I thought we were talking about the user interface. Nobody is proposing changing the behavior of `range`. That is an entirely separate question. I'm not trying to change any minds, but let's not rely on spurious arguments. Cheers, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] making "low" optional in numpy.randint
On 2/17/2016 11:46 AM, Robert Kern wrote: some at least are 1-based indexing, so closed intervals do make sense. Haskell is 0-indexed. And quite carefully thought out, imo. Cheers, Alan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] making "low" optional in numpy.randint
Behavior of random integer generation: Python randint[a,b] MATLAB randi [a,b] Mma RandomInteger [a,b] haskell randomR [a,b] GAUSS rndi[a,b] Maple rand[a,b] In short, NumPy's `randint` is non-standard (and, I would add, non-intuitive). Presumably was due due to relying on a float draw from [0,1) along with the use of floor. The divergence in behavior between the (later) Python function of the same name is particularly unfortunate. So I 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. If there is any playing with the interface, I think Mma provides a pretty good model. If I were designing the interface, I would always require a tuple argument (for the inclusive range), with possible `None` values to imply datatype extreme values. Proposed name (after `randint` deprecation): `randints`. Cheers, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy release
On Wed, 23 Apr 2008, Stéfan van der Walt wrote: Done in r5072. Much appreciated. I have updated URL:http://www.scipy.org/MatrixIndexing to reflect this change (and its provisional status). Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On Wed, 16 Apr 2008, Gael Varoquaux wrote: let us pretend A[:, 1] returns a 1D array, as you seem to be wanting Where did I say anything like that?? Please look at the proposal. It affects **only** scalar indexing (and thereby iteration). Recall how emphatically I agreed with you: Multiple indexes should always return submatrices, and the right way to get submatrices is with multiple indexes. I have proposed no change in the behavior of non-scalar indexes. None. I specify an actual code change on the page you asked me to create. It is a trivial change in __getitem__. It does not lead to any of the breakage you suggest, because it does not change the behavior you consider. Please look: it changes *only* the processing of a scalar index. Since I'm not familiar with NumPy internals, I offer this only to pin down what I am talking about, not as a proposed code change. But it should make it clear that I am not asking what you suggest. AND (!!) my proposed change means that A[x][y] == A[x, y] which is not currently true. One good thing has come out of this discussion: as far as I can tell, everyone agrees that there should be a change such that A[x][y] == A[x, y] I believe I am proposing the simplest change, which leaves matrices as much like ndarrays as possible. My main objection to Stefan's proposal is that it adds substantial complexity for no apparent gain. Charles may have been suggesting that he can see a substantial gain: his comment was too cryptic for me. If so, I would be interested. Cheers, Alan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy
On 16/04/2008, Alan G Isaac [EMAIL PROTECTED] wrote: The rule is: to get a submatrix, use multiple indices. On Wed, 16 Apr 2008, Stéfan van der Walt wrote: That is not the rule for arrays; you argued the compatibility point yourself. Sorry, I do not understand. I am saying only: I propose no change in current matrix behavior in response to nonscalar indexes. On Wed, 16 Apr 2008, Stéfan van der Walt wrote: Are you opposed to fixing the problem the way Tim suggested? It seems lots of complexity for a payoff I do not see. My proposal is simpler and stays closer to ndarray behavior. But having a matrix be a container of such RowVectors is better than the current behavior. I do not see that it gets in the way of anything desirable, as long as the array attribute of your vectors will return a 1d array. Why would linear algebra users prefer 1d arrays instead of vectors? What is a vector? To me a vector is an element of a vector space. As far as I can tell, a 1d array *is* a vector. If you mean by vector what people mean when they say row vector or column vector, this is just short hand for special matrices. If I want these special matrices, I can have them right now. Of course I cannot index the elements with a scalar... Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] vander() docstring
On Wed, 9 Apr 2008, Charles R Harris wrote: It would affect polyfit, where the powers correspond to the numpy polynomial coefficients. That can be fixed, and as far as I can determine that is the only numpy function that uses vander, but it might break some software out there in the wild. Maybe we can put it on the list for 1.1. I'd like to change numpy polynomials also, but that is probably a mod too far. How about tagging the coefficient order, so everyone can use these the way they prefer. Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Fri, 04 Apr 2008, Joe Harrington wrote: Wouldn't you rather do: import numpy as N ... c = (N.sin(b) + N.exp(d)) / N.mean(g) rather than: import numpy as N import numpy.math as N.M import numpy.trig as N.T import numpy.stat as N.S ... c = (N.T.sin(b) + N.M.exp(d)) / N.S.mean(g) I try to think of my students in such an environment. Frightening. Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] loadtxt broken if file does not end in newline
On Wed, 27 Feb 2008, Christopher Barker wrote: The issue here is a result of what I consider a wart in python's string methods -- string.find() returns a valid index( -1 ) when it fails to find anything. Use index instead? Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] data transit
It sounds like you want a new class X that does three things: knows where the data is and how to access it, knows how the data are to be processed and can do this when asked, is able to provide a results object when requested. The results object can store who made it and with what processing module, thus indirectly linking to the data and techniques (which the X instance may or may not store, as is convenient). fwiw, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] howto convert float array to array of integers
On Fri, 05 Oct 2007, dmitrey wrote:
I have an array like array([ 1., 0., 2., -10.])
what is most efficient (i.e. fastest) way to convert the one to array of
integers?
array([ 1, 0, 2, -10])
Use ``astype``.
Cheers,
Alan Isaac
import numpy as N
x = N.array([1,2,3],dtype='float')
x
array([ 1., 2., 3.])
x.astype('int')
array([1, 2, 3])
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] additional thanks
I know thanks have already been offered, but I hope one more on the list will be acceptable. I start classes next week, in Economics. It is easy to discourage some of my students, if the getting started part of new software is rough. The new compatible NumPy and SciPy binaries are VERY HELPFUL!!! Thanks! Alan Isaac PS Just a warning to others in my position: students using VISTA are reporting install difficulties for Python 2.5.1. It sounds like a fix is to proceed as at URL:http://www.sephiroth.it/weblog/archives/2006/06/installing_python_msi_on_windo.php but as I do not have access to a VISTA machine I have not been able to test this. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Should bool_ subclass int?
On Tue, 10 Jul 2007, Timothy Hochberg wrote: 1. +,- are arithmetic operators and return ints not booleans 2. *,** are arithmetic operators on scalars and arrays and return ints as above. 3. ,|,^ are the logical operators and return booleans. 4. *,** are defined on matrices to perform logical matrix multiplication and exponation. I am not objecting to this, but I want to make sure the costs are not overlooked. Will multiplication of boolean matrices will be different than `dot`? (It will certainly be different than `dot` for equivalent 2-d arrays). If I understand, unary complementation (using `-`) will be lost: so there will be no operator for unary complementation. (You might say, what about `~`, which currently works, but if we are to match Python's behavior, that is lost too.) Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)
On Fri, 27 Apr 2007, Jeffrey Yasskin wrote: Then again, doubles aren't a group either because of this imprecision, and I'm suggesting claiming they're a subclass of that, so maybe there's room in a practical language to make them a subclass of the rationals too. Would using language from the Scheme report be useful when discussing this? http://www-swiss.ai.mit.edu/projects/scheme/documentation/scheme_5.html Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] index of minimum of array
On 4/13/07, Tommy Grav [EMAIL PROTECTED] wrote: how do I find the index of the minimum value of an numpy array? Example a = array([1.,2.,0.4,3.]) I want the i=2 since a[i] = 0.4 is the smallest value in a. On Fri, 13 Apr 2007, Timothy Hochberg wrote: argmin Just a reminder that there exist a very useful example list http://www.scipy.org/Numpy_Example_List#argmin and a wonderful reference: http://www.tramy.us/ Cheers, Alan Isaac ___ Numpy-discussion mailing list [EMAIL PROTECTED] http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix indexing question
On Tue, 27 Mar 2007, Zachary Pincus wrote: M[i], which equals M[i,:] Of course this equality must break. That was stated at the outset. As I said before, this may be impossible or undesirable. But, as I said before, it seems prima facie natural for M[i] to be ordinary Python indexing while M[i,:] is numpy indexing, each with its own natural interpretation. In any case, you may be spending too much energy on this. I am not a developer, and no developer has expressed a desire to make such a change. The current behavior is currently safe (if odd). Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix indexing question
On Mon, 26 Mar 2007, Travis Oliphant wrote: It actually has been offered. You just don't accept it. Matrices are containers of matrices. If M is an (mxn) matrix then M[0] is a (1xn) matrix. Viewing this 1xn matrix as a 1-d array loses it's row-vectorness. This seems perfectly logical and acceptable to me. I'm waiting for a better explanation as to why this is not acceptable. Arguments that rest on what is and what isn't Pythonic are not very persuasive as this is very often in the eye of the beholder. Again, I only raised a *question* about whether there might be a design problem here. My goal was only to have this explored, and I've tried to explain why. The evidence I offer: - it is surprising (at least to some) that iterating over a matrix yields matrices - I believe it is unexpected (prior to instruction) and that there is a natural more expected behavior - if that is right, deviation from the expected should have a good justification - this behavior has tripped up at least a couple people and I expect that to happen to many others over time (because I believe the behavior is unexpected) - when I desire to iterate over a matrix I always want the arrays. (Of course there is a way to have them; that's not the point). I'm interested to see a use case where the rows are desired as matrices As you indicate, none of this constitutes an argument. And since nobody appears to agree, I should shut up. This will be my last post on this subject. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix indexing question
On 3/27/07, Alan Isaac [EMAIL PROTECTED] wrote: May I see a use case where the desired return when iterating through a matrix is rows as matrices? That has never been what I wanted. On Tue, 27 Mar 2007, Bill Baxter wrote: AllMyPoints = mat(rand(100,2)) # 100 two-d points for pt in AllMyPoints: xformedPt = pt * TransformMatrix # do something to transformed point This seems artificial to me for several reasons, but here is one reason: AllxformedPts = AllMyPoints * TransformMatrix Note that I am no longer disputing the convention, just trying to understand its usefulness. Cheers, Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Variable String Format
lechtlr wrote:
I would very much appreciate, if someone can give suggestions to implement
a loop to generate a string in the following format.
Variables with assigned values are given in A:
A = {a1:2.0, a2:4.0,………,an:5.0}
I want to transform what is in the dictionary into a string in the
following format:
X = ‘a1:2.0, a2:4.0, ……,an:5.0’
I want to implement a loop to generate X for a given A with varying n.
Is there a way to do this in python..?
Is this good enough?
A = dict(a1=2.0, a2=4.0, a3=3.0, a4=4.0, a5=5.0)
A
{'a1': 2.0, 'a3': 3.0, 'a2': 4.0, 'a5': 5.0, 'a4': 4.0}
str(A)
{'a1': 2.0, 'a3': 3.0, 'a2': 4.0, 'a5': 5.0, 'a4': 4.0}
If not, just strip out what you do not like.
Cheers,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
