cannot install scipy
Hi, I am using a Debian system. I installed NumPy and everything works well. When I try to install SciPy, I get the following error. Any help would be appreciated. === [EMAIL PROTECTED]:~/scipy/scipy-0.4.4$ python setup.py install import core -> failed: /usr/lib/python2.3/site-packages/numpy/core/multiarray.so: undefined symbol: PyOS_ascii_strtod import random -> failed: 'module' object has no attribute 'dtype' import lib -> failed: /usr/lib/python2.3/site-packages/numpy/core/multiarray.so: undefined symbol: PyOS_ascii_strtod Fatal Python error: can't initialize module lapack_lite Aborted [EMAIL PROTECTED]:~/scipy/scipy-0.4.4$ === nitro -- http://mail.python.org/mailman/listinfo/python-list
Re: cannot install scipy
LOL! Thanks- ashamed :-) nitro -- http://mail.python.org/mailman/listinfo/python-list
Re: cannot install scipy
I just ran and had one test fail - any ideas? scipy.test(level=1, verbosity=2) == FAIL: check_cdf (scipy.stats.distributions.test_distributions.test_fatiguelife) -- Traceback (most recent call last): File "", line 10, in check_cdf AssertionError: D = 0.359837284568; pval = 0.000275693346129; alpha = 0.01 args = (1.0108978152946058,) -- http://mail.python.org/mailman/listinfo/python-list
Re: cannot install scipy
I should add the following informtion that it also printed out: === Ran 972 tests in 2.471s FAILED (failures=1) === -- http://mail.python.org/mailman/listinfo/python-list
Scope question
Hello, today I wrote this piece of code and I am wondering why it does not work the way I expect it to work. Here's the code: y = 0 def func(): y += 3 func() This gives an UnboundLocalError: local variable 'y' referenced before assignment If I change the function like this: y = 0 def func(): print y func() then no error is thrown and python apparently knows about 'y'. I don't understand why the error is thrown in the first place. Can somebody explain the rule which is causing the error to me? -Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: Scope question
Thanks a lot for clearing this up, Diez! -Matthias -- http://mail.python.org/mailman/listinfo/python-list
time.time() strangeness
Hello, today I encountered a very odd situation. I am on Windows Vista and using Python 2.5.2. Here's a code snippet to illustrate my problem: # uncomment the next line to trigger the problem # myExtensionModule.CreateDirect3D9Device() import time for i in range(0,100): print time.time() With the line commented time.time() returns a changing value which is what I expect. However, when I uncomment it and create a Direct3D9 Device [1][2] it keeps printing the very same number over and over! In my project I am using twisted which uses time.time() to schedule all calls. Since time.time() is completely screwed the whole application breaks. I took a look at [3], but I can't see any obivous way how this all interacts. Specifically I am not sure which API time.time() uses internally (timeGetTime maybe?). Knowing this could probably help me debug more. I feel like time.time() should not break (unless the vid card driver/directx has a major bug). Any idea what might be happening here? Replacing time.time() with time.clock() in twisted.python.runtime makes the problem disappear. I guess because it uses QueryPerformanceCounter. Thanks for your time, -Matthias References: [1] http://msdn2.microsoft.com/en-us/library/bb172527(VS.85).aspx [2] http://msdn2.microsoft.com/en-us/library/bb172527(VS.85).aspx [3] http://svn.python.org/view/python/trunk/Modules/timemodule.c?rev=59678&view=markup -- http://mail.python.org/mailman/listinfo/python-list
time.time() strangeness
> The granularity of time.time can be quite large, maybe as much > as 1 second in some systems. Also, if the user can set the time, > the output might not be monotone. They might set the clock backwards > if it has drifted ahead, or something like that. Better to use an > explicit counter if you need a monotonically increasing sequence. It's not the granularity, after all it works without the single CreateDevice. With the line uncommented the value doesn't even change after 2 minutes. I am not sure what you mean with explicit counter. I think I would still need to get some time delta to accumulate. However, time.time() - time.time() will always be 0 for obvious reasons. I agree it would probably be better to use time.clock() and an explicit counter to prevent time wrapping issues. Nevertheless time.time() shouldn't fail here unless DirectX is really badly tinkering with my system. Thanks for your answer, -Matthias -- http://mail.python.org/mailman/listinfo/python-list
time.time() strangeness
> Nevertheless time.time() shouldn't fail here unless DirectX is really > badly tinkering with my system. I can tell you more now. If I pass D3DCREATE_FPU_PRESERVE while creating the DirectX device the bug does not appear. This flag means "Direct3D defaults to single-precision round-to-nearest" (see [1]) mode. Unfortunately it is not an option to pass this flag, I need the performance boost it gives. Can somebody tell me how this interacts with python's time.time()? I suppose it's some kind of double vs. float thing or some fpu asm code issue... -Matthias References: [1] http://msdn2.microsoft.com/en-us/library/bb172527(VS.85).aspx -- http://mail.python.org/mailman/listinfo/python-list
time.time() strangeness
Ok, my final solution is to add the D3DCREATE_FPU_PRESERVE flag. It didn't harm performance in a noticeable way at all. I was under the impression SSE would be affected by this, too. Additionally I was under the impression that float precision would suffice for time.time(). Obviously I was blatantly wrong :-) Thanks to Gabriel, Ross and Roel for commenting on this and sharing their insights! They should really make the fpu preserve flag the default. It just causes very sneaky bugs. -Matthias -- http://mail.python.org/mailman/listinfo/python-list
cx_Oracle and NCLOBs
Greetings, I'm currently working in a Python project to create a multi-platform database replication tool, and cx_Oracle was the chosen provider to handle the Oracle connections. So far the results have been very interesting, but I've been experiencing some problems when inserting CLOB objects through executemany (meaning, using a pre-prepared statement and a dynamic list of parameters). Namely, somehow the provider seems to be converting the data to LONG rather than to CLOB, even though the statement explicitly calls out the TO_NCLOB function; therefore, we get ORA-01461 errors. Now, this may possibly not be an error, but instead a misusage (not many examples available, anyways). Any help/suggestion you can provide? Best regards, Nitro -- http://mail.python.org/mailman/listinfo/python-list
