On Tue, Apr 26, 2011 at 4:21 PM, Ralf Gommers
wrote:
> On Mon, Apr 25, 2011 at 1:16 PM, Thiago Franco Moraes
> wrote:
> > Hi,
> >
> > Has anyone confirmed if this is a bug? Should I post this in the bug
> tracker?
>
> I see the same thing with recent master. Something very strange is
> going on i
On Mon, Apr 25, 2011 at 1:16 PM, Thiago Franco Moraes
wrote:
> Hi,
>
> Has anyone confirmed if this is a bug? Should I post this in the bug tracker?
I see the same thing with recent master. Something very strange is
going on in the memmap.__array_finalize__ method under Windows. Can
you file a bu
On 4/26/11 3:29 PM, Pauli Virtanen wrote:
> On Tue, 26 Apr 2011 14:52:52 -0500, Jason Grout wrote:
> [clip]
>> The updated rwork calculation makes no difference with a 3x4 matrix
>> (both the old calculation and the new calculation give 66 in the 3x4
>> case), so I don't think that is affecting any
On Tue, 26 Apr 2011 14:52:52 -0500, Jason Grout wrote:
[clip]
> The updated rwork calculation makes no difference with a 3x4 matrix
> (both the old calculation and the new calculation give 66 in the 3x4
> case), so I don't think that is affecting anything.
Actually, there *is* a difference for the
On Tue, Apr 26, 2011 at 20:31, Daniel Lepage wrote:
> You need PIL no matter what; scipy.misc.imread, scipy.ndimage.imread,
> and scikits.image.io.imread all call PIL.
I believe there are two pure python readers:
http://code.google.com/p/pylibtiff/
http://www.lfd.uci.edu/~gohlke/code/tifffile.py.
On 4/26/11 11:49 AM, Pauli Virtanen wrote:
> But apparently either there's a bug, or the LAPACK man page needs to
> be understood as you say.
I've posted a question to the Lapack forum:
http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=2402
Thanks,
Jason
__
On 4/26/11 11:49 AM, Pauli Virtanen wrote:
> Tue, 26 Apr 2011 11:36:19 -0500, Jason Grout wrote:
> [clip]
>> Okay, just one more data point. Our people that are seeing the problem
>> with numpy returning a non-unitary V also see a non-unitary V being
>> returned by the test C call to zgesdd. In o
On Tue, Apr 26, 2011 at 9:09 PM, Mathew Yeates wrote:
> is scikits.image.io documented anywhere?
http://stefanv.github.com/scikits.image/api/scikits.image.io.html
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman
is scikits.image.io documented anywhere?
On Tue, Apr 26, 2011 at 11:45 AM, Zachary Pincus
wrote:
>
> On Apr 26, 2011, at 2:31 PM, Daniel Lepage wrote:
>
>> You need PIL no matter what; scipy.misc.imread, scipy.ndimage.imread,
>> and scikits.image.io.imread all call PIL.
>
> scikits.image.io also
On 04/26/2011 11:25 AM, Pauli Virtanen wrote:
> I think it is worth testing if this change fixes it. Note that current
> LAPACK docs have the number 7 there instead of 5, so there may really be
> a bug here.
It appears to me the problem is more subtle than just a strict comparison
between the num
On Apr 26, 2011, at 2:31 PM, Daniel Lepage wrote:
> You need PIL no matter what; scipy.misc.imread, scipy.ndimage.imread,
> and scikits.image.io.imread all call PIL.
scikits.image.io also has a ctypes wrapper for the freeimage library.
I prefer these (well, I wrote them), though apparently the
On Tue, Apr 26, 2011 at 8:31 PM, Daniel Lepage wrote:
> You need PIL no matter what; scipy.misc.imread, scipy.ndimage.imread,
> and scikits.image.io.imread all call PIL.
Scikits.image has a plugin system for IO and can use FreeImage to load
images. PIL's Tiff image handling is pretty buggy (espec
You need PIL no matter what; scipy.misc.imread, scipy.ndimage.imread,
and scikits.image.io.imread all call PIL.
Theoretically there's no difference between any of them, although in
actuality some use "import Image" and others use "from PIL import
Image"; one of these may fail depending on how you
On Tue, 26 Apr 2011 10:33:07 -0500, Jason Grout wrote:
[clip]
> I was just looking up the documentation for ZGESDD and noticed that the
> value we have for rwork in the numpy call [1] does not match the Lapack
> docs. This was changed in Lapack 3.2.2 [2]. I've submitted a pull
> request:
>
> htt
Hi
What is current method of using ndiimage on a Tiff file? I've seen
different methods using ndimage itself, scipy.misc and Pil.
Mathew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 04/26/2011 10:19 AM, Ralf Gommers wrote:
> If it is an Accelerate bug it got fixed on OS X 10.6. Below is the
> output with both current master and 1.5.1. It may be worth checking
> this on 10.5 with the binary Numpy installer from Sourceforge to make
> sure it's not the Sage build process causi
On Tue, Apr 26, 2011 at 6:36 PM, Jason Grout
wrote:
> On 4/26/11 11:22 AM, Jason Grout wrote:
>> On 4/26/11 11:12 AM, Jason Grout wrote:
>>> On 4/26/11 11:07 AM, Jason Grout wrote:
And indeed, I get a 0 row as the last row of the V**H matrix
>>>
>>> I just double-checked things one last time
Tue, 26 Apr 2011 11:36:19 -0500, Jason Grout wrote:
[clip]
> Okay, just one more data point. Our people that are seeing the problem
> with numpy returning a non-unitary V also see a non-unitary V being
> returned by the test C call to zgesdd. In other words, it really
> appears that zgesdd follow
On 4/26/11 11:22 AM, Jason Grout wrote:
> On 4/26/11 11:12 AM, Jason Grout wrote:
>> On 4/26/11 11:07 AM, Jason Grout wrote:
>>> And indeed, I get a 0 row as the last row of the V**H matrix
>>
>> I just double-checked things one last time and saw that I actually
>> hadn't changed the first argument
On 4/26/11 11:12 AM, Jason Grout wrote:
> On 4/26/11 11:07 AM, Jason Grout wrote:
>> And indeed, I get a 0 row as the last row of the V**H matrix
>
> I just double-checked things one last time and saw that I actually
> hadn't changed the first argument of zgesdd to "A" in the program that I
> actua
On 4/26/11 11:07 AM, Jason Grout wrote:
> And indeed, I get a 0 row as the last row of the V**H matrix
I just double-checked things one last time and saw that I actually
hadn't changed the first argument of zgesdd to "A" in the program that I
actually ran. So with this change, I get a nonzero l
On 4/25/11 12:57 PM, Pauli Virtanen wrote:
> The Numpy routine is a very thin wrapper of LAPACK's ZGESDD, and probably
> cannot have any bugs of this kind,
As noted in my other message, I've been digging through the ZGESDD docs
to understand it better. Here is the doc string for what becomes the
On 4/25/11 12:57 PM, Pauli Virtanen wrote:
> On Mon, 25 Apr 2011 10:16:13 -0700, Rob Beezer wrote:
> [clip]
>> Many more details and complete transcripts are at:
>> http://trac.sagemath.org/sage_trac/ticket/11248
>>
>> Any thoughts or advice to help us understand this would be greatly
>> appreciate
23 matches
Mail list logo
