From stefan at sun.ac.za Sun Apr 1 12:47:26 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 1 Apr 2012 09:47:26 -0700 Subject: [OT] pass a C callback function to a cythom module via python In-Reply-To: References:

Message-ID: Hi Nadav On Sun, Apr 1, 2012 at 6:42 AM, Nadav Horesh wrote: > A nice idea. As is, it can not replace the link to C code linking because it > contains to much yellow lines ("cython -a" output) in the main loop, so > there is a speed penalty, and also I suspect it wouldn't be possible to > parallelise that function call. Anyway I plan to add this option. Could you share your benchmark code? This should be very nearly as fast as the C pointer call. And with an appropriate "with nogil" statement, I think it should parallelize? St?fan From nadavh.horesh at gmail.com Sun Apr 1 09:42:52 2012 From: nadavh.horesh at gmail.com (Nadav Horesh) Date: Sun, 1 Apr 2012 16:42:52 +0300 Subject: [OT] pass a C callback function to a cythom module via python In-Reply-To: References:

Message-ID: A nice idea. As is, it can not replace the link to C code linking because it contains to much yellow lines ("cython -a" output) in the main loop, so there is a speed penalty, and also I suspect it wouldn't be possible to parallelise that function call. Anyway I plan to add this option. About ctypes: I am not a ctypes fond either, neither I think that my use is elegant or very portable. The ctypes is used for one purpose: load a shared library and provide a pointer to an object within that library. It seems to be that it is inevitable that there is a simpler way to to that, but I am clueless. Nadav. ?????? 28 ???? 2012 00:03, ??? St?fan van der Walt : > >> Hi Nadav >> >> I just had a chat with Dag, a core Cython contributor. He mentioned >> to me another alternative, which is to encapsulate the callback >> function in a class: >> >> >> https://github.com/dagss/cython-pydata12/blob/master/examples/oointegrate/integrate.pyx >> >> You can import this class from Python, and pass it along as the >> callback object. There may be some work on improving this >> functionality in the future, but for now I think that's the cleanest >> route (and helps us to avoid ctypes!). >> >> St?fan >> >> >> On Tue, Mar 20, 2012 at 1:02 AM, Nadav Horesh >> wrote: >> > >> > Can you explain in more details how can I implement it? Any case I am >> > attaching an scheme that may clarify my intend. Soon I'll post a code >> > demonstrating the problem. >> > >> > Thank you, >> > Nadav, >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sccolbert at gmail.com Mon Apr 2 14:37:50 2012 From: sccolbert at gmail.com (Chris Colbert) Date: Mon, 2 Apr 2012 13:37:50 -0500 Subject: [OT] pass a C callback function to a cythom module via python In-Reply-To: References:

Message-ID: On Mon, Apr 2, 2012 at 1:29 PM, Nadav Horesh wrote: > I do not have a benchmark code yet. I am working now on unpythonising the > in-loop buffer copy (the line "neigh[:] = self.padded[i:i+ks0, > j:j+ks1].ravel()" in filter_iter.pyx)/ When I'll finish this and include > your suggestion, I'll be ready for the benchmarking. > > My experience with the bilateral filter showed that yellowish lines do > not comply with nogil, but it is easy to verify again. > > More specifically, anything that makes a call into the Python C-Api is not compatible with nogil. Since, Cython highlights these lines in yellow, your understanding is correct. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nadavh.horesh at gmail.com Mon Apr 2 14:29:48 2012 From: nadavh.horesh at gmail.com (Nadav Horesh) Date: Mon, 2 Apr 2012 21:29:48 +0300 Subject: [OT] pass a C callback function to a cythom module via python In-Reply-To: References:

Message-ID: I do not have a benchmark code yet. I am working now on unpythonising the in-loop buffer copy (the line "neigh[:] = self.padded[i:i+ks0, j:j+ks1].ravel()" in filter_iter.pyx)/ When I'll finish this and include your suggestion, I'll be ready for the benchmarking. My experience with the bilateral filter showed that yellowish lines do not comply with nogil, but it is easy to verify again. Nadav. ?????? 1 ?????? 2012 19:47, ??? St?fan van der Walt : > Hi Nadav > > On Sun, Apr 1, 2012 at 6:42 AM, Nadav Horesh > wrote: > > A nice idea. As is, it can not replace the link to C code linking > because it > > contains to much yellow lines ("cython -a" output) in the main loop, so > > there is a speed penalty, and also I suspect it wouldn't be possible to > > parallelise that function call. Anyway I plan to add this option. > > Could you share your benchmark code? This should be very nearly as > fast as the C pointer call. And with an appropriate "with nogil" > statement, I think it should parallelize? > > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nadavh.horesh at gmail.com Mon Apr 2 14:35:36 2012 From: nadavh.horesh at gmail.com (Nadav Horesh) Date: Mon, 2 Apr 2012 21:35:36 +0300 Subject: Platform for filters development In-Reply-To: References:

Message-ID: Thank you for shaping it up. I'll base the next updates on this form. Nadav. N.B I deliberately use cython-0.15(.1) as employing openmp (via prange) in on my todo list. ?????? 27 ???? 2012 06:08, ??? Tony Yu : > >> >> >> On Wed, Mar 21, 2012 at 12:05 PM, Nadav Horesh wrote: >> >>> (I think I missed the attachment) >>> >>> >>> Attached here a concept code showing my attempt to produce in improved >>> (over ndimage.generic_filter) platform for filters development. The code is >>> very preliminary and needs a lot of extension as well as rewrite. My main >>> questions are: >>> >>> 1. Is there is already a mature package for this purpose? >>> 2. Is there is need for such a module inside scikits? >>> >>> Any comment is welcome. >>> >>> Nadav >>> >> >> Hey Nadav, >> >> I had some problems building this example. (Actually, I couldn't even >> unzip it at first.) In case anyone else wants to try this out, I posted a version >> of your package to my github >> account with some build modifications. I think the build requires Cython >> 0.15 (or at least, I think so: I was getting some build errors with 0.14 >> and upgrading seemed to fix it (although I may have made other changes >> along the way).) >> >> I haven't yet had time to play around with the code, so I don't have >> anything constructive to say about the code yet. >> >> Cheers, >> -Tony >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Wed Apr 4 18:53:38 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 4 Apr 2012 15:53:38 -0700 Subject: bug in radon transform? In-Reply-To: <20120404213149.GC7717@phare.normalesup.org> References: <20120404213149.GC7717@phare.normalesup.org> Message-ID: On Wed, Apr 4, 2012 at 2:31 PM, Emmanuelle Gouillart wrote: > ? ? ? ?I have the impression that the center of rotation used for > computing the radon transform (skimage.transform.radon) is not correct: In [8]: tf.radon(z, theta=[0, 90]) Out[8]: array([[ 0., 0.], [ 0., 0.], [ 0., 1.], [ 0., 0.], [ 0., 0.], [ 0., 0.], [ 1., 0.], [ 0., 0.], [ 0., 0.], [ 0., 0.]]) Hrm, you're right; that looks fishy. I wonder if this has to do with the padding that happens beforehand? I don't have access to MATLAB--does their "radon" give similar results? St?fan From emmanuelle.gouillart at nsup.org Wed Apr 4 17:31:49 2012 From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart) Date: Wed, 4 Apr 2012 23:31:49 +0200 Subject: bug in radon transform? Message-ID: <20120404213149.GC7717@phare.normalesup.org> Hello, I have the impression that the center of rotation used for computing the radon transform (skimage.transform.radon) is not correct: >>> import numpy as np >>> from skimage.transform import radon, iradon >>> >>> a = np.zeros((3, 3)) >>> a[1, 1] = 1 >>> projs = radon(a, [0, 45, 90, 135]) >>> projs array([[ 0. , 0. , 0. , 0. ], [ 0. , 0. , 0. , 0.13603897], [ 0. , 0.46446609, 1. , 0.79289322], [ 1. , 0.46446609, 0. , 0. ], [ 0. , 0. , 0. , 0. ], [ 0. , 0. , 0. , 0. ], [ 0. , 0. , 0. , 0. ]]) (the projection at 90??????C, that is projs[2], should have the non-zero coefficient centered). Before I try to modify this, I'd like to be sure that it is not the expected behaviour, and a bug indeed... Cheers, Emmanuelle From emmanuelle.gouillart at nsup.org Mon Apr 9 12:41:58 2012 From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart) Date: Mon, 9 Apr 2012 18:41:58 +0200 Subject: bug in radon transform? In-Reply-To: References: <20120404213149.GC7717@phare.normalesup.org> Message-ID: <20120409164158.GA20175@phare.normalesup.org> Yes, it looks weird. I don't have access to the corresponding toolbox in Matlab either. I could "symmetrize" the result by the following change in radon: - shift0 = np.array([[1, 0, -w/2.], - [0, 1, -h/2.], + shift0 = np.array([[1, 0, -w/2. + 0.5], + [0, 1, -h/2. + 0.5], [0, 0, 1]]) - shift1 = np.array([[1, 0, w/2.], - [0, 1, h/2.], + shift1 = np.array([[1, 0, w/2. - 0.5], + [0, 1, h/2. - 0.5], [0, 0, 1]]) but then I'm not sure whether the behavior of iradon is correct either, so I haven't committed this change yet. Pieter, if you're around, would you mind having a quick look? Also, iradon crashes for arrays with less than 64 lines (due to an int that should be a float, resulting in a division by zero error -- I just made a small pull request to correct that). I also noticed that for the array used in test_radon_transform.test_radon_iradon, applying radon and then iradon does not give back the correct original array, but an array that looks shifted by one line and one column. Try for example >>> from skimage.transform import radon, iradon >>> size = 70 >>> image = np.tri(size) + np.tri(size)[::-1] >>> reconstructed = iradon(radon(image), filter="ramp", >>> interpolation="linear") >>> close('all') >>> plt.matshow(image) >>> plt.matshow(reconstructed) I very much suspect that the center of rotation is not correct either in radon, or in iradon, or maybe in both... I started having a look at the code, but maybe it would be easier for Pieter than for me to fix it... Cheers, Emmanuelle On Wed, Apr 04, 2012 at 03:53:38PM -0700, St??????fan van der Walt wrote: > On Wed, Apr 4, 2012 at 2:31 PM, Emmanuelle Gouillart > wrote: > > ?????? ?????? ?????? ??????I have the impression that the center of rotation used for > > computing the radon transform (skimage.transform.radon) is not correct: > In [8]: tf.radon(z, theta=[0, 90]) > Out[8]: > array([[ 0., 0.], > [ 0., 0.], > [ 0., 1.], > [ 0., 0.], > [ 0., 0.], > [ 0., 0.], > [ 1., 0.], > [ 0., 0.], > [ 0., 0.], > [ 0., 0.]]) > Hrm, you're right; that looks fishy. I wonder if this has to do with > the padding that happens beforehand? I don't have access to > MATLAB--does their "radon" give similar results? > St??????fan From guillaume at mitotic-machine.org Fri Apr 13 06:18:13 2012 From: guillaume at mitotic-machine.org (Guillaume Gay) Date: Fri, 13 Apr 2012 12:18:13 +0200 Subject: Unexpected behaviour in peak_local_max In-Reply-To: <20120404213149.GC7717@phare.normalesup.org> References: <20120404213149.GC7717@phare.normalesup.org> Message-ID: <4F87FD65.5040602@mitotic-machine.org> Hi all, When calling feature.peak_local_max() on a flat image, all the points of the image are returned: >>> test_image = np.ones((10,10)) >>> coords = feature.peak_local_max() >>> len(coords) 100 I wouldn't expect that... It originates from two things in the code: 1. The calculated thershold can be higher than the min of the image: corner_threshold = np.max(image.ravel()) * threshold 2. All points higher *or equal* to the threshold are retrieved: image_t = (image >= corner_threshold) * 1 So for me this is a bit strange, and is really bad when you have an empty frame on a sequence, which tends to happen. Also I think the threshold argument is a bit unusual, I more often expect an absolute value for the threshold, not a relative one. -------------- next part -------------- A non-text attachment was scrubbed... Name: guillaume.vcf Type: text/x-vcard Size: 282 bytes Desc: not available URL: From stefan at sun.ac.za Sun Apr 15 18:27:30 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 15 Apr 2012 15:27:30 -0700 Subject: Unexpected behaviour in peak_local_max In-Reply-To: References: <20120404213149.GC7717@phare.normalesup.org> <4F87FD65.5040602@mitotic-machine.org> Message-ID: On Sun, Apr 15, 2012 at 2:23 PM, Tony Yu wrote: > That said, I think that it'd be worthwhile to have both absolute and > relative thresholding. I'm not sure about the naming though: > > - `athresh` and `rthresh` > - `absthresh` and `relthresh` > - `abs_thresh` and `rel_thresh` > - `abs_threshold` and `rel_threshold` `threshold_abs` and `threshold_rel` perhaps? My personal preference is to have the specialization afterwards. St?fan From tsyu80 at gmail.com Sun Apr 15 17:23:56 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Sun, 15 Apr 2012 17:23:56 -0400 Subject: Unexpected behaviour in peak_local_max In-Reply-To: <4F87FD65.5040602@mitotic-machine.org> References: <20120404213149.GC7717@phare.normalesup.org> <4F87FD65.5040602@mitotic-machine.org> Message-ID: Hey Guillaume, Thanks for the report. See below: On Fri, Apr 13, 2012 at 6:18 AM, Guillaume Gay < guillaume at mitotic-machine.org> wrote: > Hi all, > > When calling feature.peak_local_max() on a flat image, all the points of > the image are returned: > > >>> test_image = np.ones((10,10)) > >>> coords = feature.peak_local_max() > >>> len(coords) > 100 > > I wouldn't expect that... It originates from two things in the code: > > 1. The calculated thershold can be higher than the min of the image: > > corner_threshold = np.max(image.ravel()) * threshold > You mean: the calculated threshold can be *less than* the min of the image, correct? Hmm, I'm not sure if this is necessarily a bug: using a relative threshold can be problematic, but the same is true for absolute thresholds (you can easily set the absolute threshold below the min of the image). One alternative would be to calculate the relative threshold based on the range of input values. For example, setting `threshold=0.5` would given a threshold that's half-way between the minimum and maximum pixel intensities. (BTW, I was wondering why I named this "corner"_threshold; then I remembered that I refactored this from the Harris corners implementation) > > 2. All points higher *or equal* to the threshold are retrieved: > > image_t = (image >= corner_threshold) * 1 > > So for me this is a bit strange, and is really bad when you have an empty > frame on a sequence, which tends to happen. This is a good point. I'd be happy to change `>=` to `>`: I think it would help avoid some corner-cases, and I can't see any significant side-effects. In addition, I think it may be worthwhile to raise an error if all values are equal. > Also I think the threshold argument is a bit unusual, I more often expect > an absolute value for the threshold, not a relative one. > > I think relative thresholding is really useful. Sometimes you don't know the strength of your peak (esp. in some image transforms), and it's easy to just say that valid peaks are some fraction of the maximum peak. That said, I think that it'd be worthwhile to have both absolute and relative thresholding. I'm not sure about the naming though: - `athresh` and `rthresh` - `absthresh` and `relthresh` - `abs_thresh` and `rel_thresh` - `abs_threshold` and `rel_threshold` Thoughts? -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsyu80 at gmail.com Mon Apr 16 00:29:39 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Mon, 16 Apr 2012 00:29:39 -0400 Subject: Unexpected behaviour in peak_local_max In-Reply-To: References: <20120404213149.GC7717@phare.normalesup.org> <4F87FD65.5040602@mitotic-machine.org> Message-ID: 2012/4/15 St?fan van der Walt > On Sun, Apr 15, 2012 at 2:23 PM, Tony Yu wrote: > > That said, I think that it'd be worthwhile to have both absolute and > > relative thresholding. I'm not sure about the naming though: > > > > - `athresh` and `rthresh` > > - `absthresh` and `relthresh` > > - `abs_thresh` and `rel_thresh` > > - `abs_threshold` and `rel_threshold` > > `threshold_abs` and `threshold_rel` perhaps? My personal preference > is to have the specialization afterwards. > > St?fan > Sounds good. I've added these parameters (along w/ a few other changes) in PR #176 . -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaume at mitotic-machine.org Mon Apr 16 03:45:03 2012 From: guillaume at mitotic-machine.org (Guillaume Gay) Date: Mon, 16 Apr 2012 09:45:03 +0200 Subject: Unexpected behaviour in peak_local_max In-Reply-To: References: <20120404213149.GC7717@phare.normalesup.org> <4F87FD65.5040602@mitotic-machine.org> Message-ID: <4F8BCDFF.2090909@mitotic-machine.org> Great, Thank's Tony for the fixes Best, Guillaume Le 16/04/2012 06:29, Tony Yu a ?crit : > > > 2012/4/15 St?fan van der Walt > > > On Sun, Apr 15, 2012 at 2:23 PM, Tony Yu > wrote: > > That said, I think that it'd be worthwhile to have both absolute and > > relative thresholding. I'm not sure about the naming though: > > > > - `athresh` and `rthresh` > > - `absthresh` and `relthresh` > > - `abs_thresh` and `rel_thresh` > > - `abs_threshold` and `rel_threshold` > > `threshold_abs` and `threshold_rel` perhaps? My personal preference > is to have the specialization afterwards. > > St?fan > > > Sounds good. I've added these parameters (along w/ a few other > changes) in PR #176 > . > > -Tony > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: guillaume.vcf Type: text/x-vcard Size: 282 bytes Desc: not available URL: From david.stolarsky at gmail.com Fri Apr 20 15:41:57 2012 From: david.stolarsky at gmail.com (David Stolarsky) Date: Fri, 20 Apr 2012 12:41:57 -0700 (PDT) Subject: HoG bug? Message-ID: <20695422.1012.1334950917855.JavaMail.geo-discussion-forums@ynbv36> It looks to me like the HoG computation ignores half of the possible gradient values (see attached image). There are 15 lines visible in the attached HoG visualization, likewise there are 15 non-zero values in the feature vector returned by feature.hog(). Is this a bug? Am I doing something wrong? I'm using the hog example script from http://scikits-image.org/docs/0.5/auto_examples/plot_hog.html , modified to take a file from the command line. Best, David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hog.png Type: image/png Size: 8467 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hog.py Type: text/x-python Size: 763 bytes Desc: not available URL: From stefan at sun.ac.za Fri Apr 20 18:50:36 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 20 Apr 2012 15:50:36 -0700 Subject: HoG bug? In-Reply-To: <20695422.1012.1334950917855.JavaMail.geo-discussion-forums@ynbv36> References: <20695422.1012.1334950917855.JavaMail.geo-discussion-forums@ynbv36> Message-ID: Hi David On Fri, Apr 20, 2012 at 12:41 PM, David Stolarsky wrote: > It looks to me like the HoG computation ignores half of the possible > gradient values (see attached image). There are 15 lines visible in the > attached HoG visualization, likewise there are 15 non-zero values in the > feature vector returned by feature.hog(). Is this a bug? Am I doing > something wrong? I'm using the hog example script > from?http://scikits-image.org/docs/0.5/auto_examples/plot_hog.html?, > modified to take a file from the command line. I don't have access to your input image, but I suspect what's happening is that when the image is divided up into 8x8 cells, the top edges fall on the boundaries of cells, while the bottom ones fall inside. If you send me the input image, I can verify, or you can modify the cell shape to see what happens. St?fan From tsyu80 at gmail.com Tue Apr 24 23:00:03 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Tue, 24 Apr 2012 23:00:03 -0400 Subject: vbench Message-ID: I just uploaded a PR to add the basic setup for code profiling using Wes McKinney's `vbench` : PR 180. (You'll have to install vbench to actually run the benchmarks.) This PR adds the basic infrastructure for benchmarking; I'm thinking that the benchmarks themselves can be added incrementally. Right now it takes a surprisingly-long time to run; this may be an issue with how I've set it up, but I'm not sure. These files are from the pandas vbench suite with a bit of modification. For a direct comparison with the pandas suite, I've renamed: suite.py -> settings.py run_suite.py -> run_benchmarks.py and instead of putting the test files in the same directory as these files, I've dumped them into the "suite" subdirectory. If you want to try it out, you'll have to install vbench, and you'll probably want to uncomment the alternate start date in settings.py (even so, it still takes a surprisingly long time to run on my system). Running `make` will generate a "source" directory, which contains restructuredtext files for displaying the benchmarking output (source->vbench->figures contains the relevant plots). As an example, I've attached the result for calling `img_as_ubyte` on an `int` image. Note the sharp drop in execution time in early February: this is when Christophe Gohlke's PR for dtype conversion (PR #99) was finally merged. Cheers, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: img_as_ubyte_on_int.png Type: image/png Size: 41751 bytes Desc: not available URL: From stefan at sun.ac.za Mon Apr 30 23:43:53 2012 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 30 Apr 2012 20:43:53 -0700 Subject: Bizarre error In-Reply-To: References: Message-ID: Hey Tony On Mon, Apr 30, 2012 at 8:01 PM, Tony Yu wrote: > Can anyone reproduce this? (Script below will print an array when it fails; > otherwise it exits without printing anything) I've run this script a few times, and I don't see anything. Very strange! St?fan From tsyu80 at gmail.com Mon Apr 30 23:01:10 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Mon, 30 Apr 2012 23:01:10 -0400 Subject: Bizarre error Message-ID: Sorry for the cryptic title, but I don't know a better way to describe it. While I was playing around with the PR to add a structural similarity function , I found that summing over an array doesn't give consistent results on my system (example script below). The example script is pulled from the structural similarity function. The test is run in a loop because the error appears randomly---running the test with the *exact* same arrays will fail on one attempt but not another. Random observations: - the failure is more likely to occur with large arrays - the failure *does not occur* without the subtraction of `ux` (see script) - this seems like some sort of memory alignment error (maybe something to do with `as_strides`, which is used by view_as_windows) Can anyone reproduce this? (Script below will print an array when it fails; otherwise it exits without printing anything) I know this is probably more of numpy issue (if it's reproducible), but I want to try to reproduce it before rewriting the example without calling `view_as_windows`. Thanks, -Tony #~~~ # requires somewhat-recent master because of call to view_as_windows. import sys import numpy as np from skimage.util.shape import view_as_windows def test_func(X, Y, win_size=7): XW = view_as_windows(X, (win_size, win_size)) ux = np.mean(np.mean(XW, axis=2), axis=2) XWM = XW - ux[..., None, None] # Repeat *exact same calculation* and check that they give the same value. vx1 = np.sum(np.sum(XWM, axis=2), axis=2) vx2 = np.sum(np.sum(XWM, axis=2), axis=2) if not np.allclose(vx1, vx2): diff = vx1 - vx2 print diff[np.nonzero(diff)] sys.exit() X = np.random.uniform(size=(30, 30)) Y = np.random.uniform(size=(30, 30)) for i in xrange(100): test_func(X, Y) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsyu80 at gmail.com Mon Apr 30 23:51:02 2012 From: tsyu80 at gmail.com (Tony Yu) Date: Mon, 30 Apr 2012 23:51:02 -0400 Subject: Bizarre error In-Reply-To: References:

Message-ID: On Mon, Apr 30, 2012 at 11:43 PM, St?fan van der Walt wrote: > Hey Tony > > On Mon, Apr 30, 2012 at 8:01 PM, Tony Yu wrote: > > Can anyone reproduce this? (Script below will print an array when it > fails; > > otherwise it exits without printing anything) > > I've run this script a few times, and I don't see anything. Very strange! > > St?fan > Actually I'm not too surprised that you can't reproduce this since you never got a failure with the SSIM tests. But, yes, this is very strange. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: