Re: [Numpy-discussion] nd_image.affine_transform edge effects
Hi, I notice now that we've been having this discussion on the wrong list -- oops! We're nearly done, though. On Mon, Mar 26, 2007 at 04:16:51AM -0400, James Turner wrote: For what it's worth, I'd agree with both of you that the numeric overflow should be documented if not fixed. It sounds like Stefan has figured out a solution for it though. If you make sense of the code in ni_interpolation.c, Stefan, I'd be very interested in how to make it calculate one less value at the edges :-). I fixed the overflow issue in SVN. I'd appreciate it if you could test and let me know whether everything works as expected. The output values are now simply clipped to the bounds of the numeric type, i.e. UInt8 to [0,255] etc. As for the values at the edges, I'm still working on it. Since we have a fundamental problem with the spline filter approach at the borders, we may also want to look at subdivision interpolation schemes, like the one described in this article: http://citeseer.ist.psu.edu/devilliers03dubucdeslauriers.html Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] matrix indexing question
Alan G Isaac wrote: On Tue, 27 Mar 2007, Robert Kern apparently wrote: Gram-Schmidt orthogonalization Alan G Isaac wrote: I take it from context that you consider it desirable to end up with a list of matrices? Robert wrote: Honestly, I don't care. You asked about iteration, and I gave you an example where it was important that the iterates were matrices (such that .T worked correctly). Please stop moving the goal posts. It is really not my intent to be irritating or to move the posts. But I had two reasons to ask. First, your claim is false that this was important in your example. (To see this, replace M[1:] with M.A[1:].) So actually your code would work the same if iteration over matrices were producing arrays (after replacing M[0] with M[0,:] to match that case). You're right, it does, but only because the first place it is used, it gets operated with the matrix row-vector base before it does anything else, gets coerced into a matrix, and then gets assigned back to rowv. I don't tolerate that kind of implicitness in my code. Second, when I spoke of *desirability*, the output is relevant. Try nump.mat(ortho) to see what I mean. shrug If I wanted something other than a list of matrix row-vectors (which I might), then I'd post-process. Keeping the clarity of the main algorithm is also important. If iteration were to produce arrays, the outcome of implementing the algorithm (e.g., using ``dot``) would be I suggest more desirable, in that numpy.mat(ortho) would work as hoped/expected. Ditto for not using matrix objects at all. In this sense, the example perhaps speaks against your intent. You offer code that would work just fine if iteration yielded arrays. Apologies in advance if this again seems tangential to my original request. To me it does not. If you really want iterates to be arrays, just use .A. I have mentioned that several times. It is orthogonal to the design issue I raised. (I suggested that under the current behavior you do not usually end up with what you want when iterating over matrices.) But again, I recognize that I am alone in that view. I am just trying to understand why. People have been giving you reasons, over and over again. You are simply refusing to listen to them. You have a use case for arrays being the iterates. You are presuming that the only argument that can beat that is another use case for matrix objects being the iterates. This is not true; there are other principles at work. If we were to make matrix objects behave in different ways for different methods to satisfy what one person thinks is the most convenient way to use each method, we would have a patchwork object with no overall principle that people can use to understand what is going on. They would simply have to remember which behavior someone thought was the most convenient for each thing. Remember the lessons of rand() and randn(). -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nd_image.affine_transform edge effects
On Wed, Mar 28, 2007 at 05:14:59PM +0200, Stefan van der Walt wrote: As for the values at the edges, I'm still working on it. OK, that was a one-line patch. Please test to see if there are any subtle conditions on the border that I may have missed. I know of one already, but I'd be glad if you can find any others :) Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] matlab, idle, interactivity and teaching
Hello to all, I've thread that apperead some time ago on this list about matlab and teaching. I've discovered python recently and translated part of the routine I use in python (www.chemometrics.it). Some of my collegue asked me if I could show them how to use python. For matlab user I guess the first problem is to setup everything, but I just fixed it preparing a directory with all the package I need and a matplotlibrc file for interactive mode + a shortcut for idle -n use. The second problem is that people now wants some bells and whistles of matlab that I have to admit sometime can be very helpful for saving time. The bells and whistles are about the workspace. It's difficult to cut and paste from gnumeric/excel (I generally use txt file but it's no so immediate) and also there is no visual workspace. I cannot succeed also in saving workspace (I know there is a function so iosave.mat but I didn't manage easily hot to use it) For overpass this problems I've tried to use QME-DEV which is in early stage of development (alpha) but promise well. What people like of python/matplot/scipy -its free ;) -they like a lot the plotting style and capabilities (they find the png and svg file very clear and accurate) -they like IDLE as editor (ehy it's has the same color of matlab ;) ! ) So my question is . Do you have a similar experience ? How do you help people in moving the first step ? do you use (and also does it exist) a more friendly environment than IDLE except from QME-DEV. I know that this question may look silly, but in my opinion also how much is user friendly a software is very important for getting new users. Cheers to all Giorgio ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Help with linear_least_squares
Brad Malone wrote: Hi, I'm running into an error with linear least squares that I'm not sure what to do about. For reference, I'm trying to fit a curve corresponding to the example at the bottom of this wikipedia page: http://en.wikipedia.org/wiki/Linear_least_squares You are mixing numpy arrays with a package from Numeric (which numpy replaces) You should instead use the linear algebra routines from numpy. Thus, eliminate import LinearAlgebrea Then, as the last line sol = linalg.lstsq(A,b) You also don't need to reshape the b array. It will work fine as a 1-d array. So, code is from numpy import * A = reshape([0,1,2,1,4,1,-1,1],(4,2)) b = array([3,3,4,2]) sol,resids,rank, s = linalg.lstsq(A,b) sol is your desired solution vector -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org 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 (final post)
On Wed, Mar 28, 2007 at 07:05:00PM -0500, Alan Isaac wrote: On Wed, 28 Mar 2007, Stefan van der Walt wrote: Matrices strike me as a bit of an anomaly. I would expect an N-dimensional container to contain (N-1)-dimensional objects. Yes indeed. Doesn't seem to be the way the matrix world works though: octave:2 x = zeros(3,3,5); octave:3 size(x) ans = 3 3 5 octave:4 size(x(:,:,1)) ans = 3 3 octave:5 size(x(:,1,1)) ans = 3 1 Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Windows binary release?
Hi, I wonder if anyone can tell me when the next release is planned? Or specifically, any idea when a new Windows binary installer will be released? I'm interested because we'd like to release a new version of our neural map-modeling software (which depends on numpy) soon, but the subtract.reduce bug (http://projects.scipy.org/scipy/numpy/ticket/413, now fixed) that we assume is in the current binary means we could not release a binary Windows installation ourselves. Thanks, Chris (Our software is at topographica.org) ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
