Legitimate use of the "is" comparison operator?
I just recently realized that the comparison operator "is" actually works for comparing numeric values. Now, I know that its intended use is for testing object identity, but I have used it for a few other things, such as type checking, and I was just wondering whether or not it is considered bad practice in the Python Community to use it for numerics as well. Example: a = range(5) b = range(5) if len(a) is len(b): print "They're the same size!" else: print "They're not the same size!" -- http://mail.python.org/mailman/listinfo/python-list
Re: Legitimate use of the "is" comparison operator?
Fredrik Lundh wrote: > > except that it doesn't work. > > writing broken code is never a good practice. > With all due respect, for some reason it seems to work on my machine. Because I certainly agree with you about writing broken code. Python 2.4.2 (#1, Jan 17 2006, 16:52:02) [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> a = range(5) >>> b = range(5) >>> >>> if len(a) is len(b): ... print "They're the same size!" ... else: ... print "They're not the same size!" ... They're the same size! >>> > > (the reason that it appears to work for small integers is that the > interpreter is caching the objects for some commonly used values, > including small integers and one-character strings. but that's an > interpreter implementation detail, not something you can rely on). > That's very interesting. Thank you for explaining :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Legitimate use of the "is" comparison operator?
Gary Herron wrote: > > >>> 100 is (99+1) > False > > >>> 2 is (1+1) > True > > >>> 100 is 100 > True > > This is highly implementation dependent. The current (C) implementation > of Python has a cache for small integers, so the attempt to compare > values with "is" works for some small integers, and fails for some large > integers, but curiously, not all instances of comparing large integers. > Ahh, thank you. That explains why Fredrick's and Jean-Paul's example did not work, but mine did (I was using *small* integers). Ok, well I definitely get the picture. Use the "is" operator for what it was intended for, or deal with broken code ;-) Thanks a lot guys. -- http://mail.python.org/mailman/listinfo/python-list
Re: Specifing arguments type for a function
Paolo Pantaleo wrote: > I have a function > > def f(the_arg): > ... > > and I want to state that the_arg must be only of a certain type > (actually a list). Is there a way to do that? I wrote a cool function decorator just for that purpose. It's posted on the Python Decorator Library at: http://wiki.python.org/moin/PythonDecoratorLibrary#head-308f2b3507ca91800def19d813348f78db34303e If you use it, you will be able to simply write: @accepts(list) def f(the_arg): ... and you will get a warning message if the_arg is not a list. Or, if you want an exception raised, then just: @accepts(list, debug=2) def f(the_arg): ... Let me know what you think, if you do end up using it. I'm eager for feedback. -- http://mail.python.org/mailman/listinfo/python-list
? on scipy.fftpack
I've been debugging a simulation I wrote a while ago, and it seems that
the problem is in the fft module itself. I'm trying a simple test by
just feeding the function a basic real gaussian. Obviously, I should
get back the same real gaussian, but what I get is not even close. Can
anyone help me? Thanks in advance.
from scipy import *
import pylab
fft, ifft = fftpack.rfft, fftpack.irfft
def main():
sigma = 50.
x = arange(-100, 100, 1, 'f')
g = exp(-x**2 / (2 * sigma)) / sqrt(2 * pi)
testFFT(x, g)
def testFFT(x, f):
pylab.plot(x, f)
pylab.title('Initial gaussian')
pylab.show()
pylab.clf()
f = fft(f)
pylab.plot(x, f)
pylab.title('After first FFT')
pylab.show()
pylab.clf()
f = fft(f)
pylab.plot(x, f)
pylab.title('After first iFFt')
pylab.show()
pylab.clf()
if __name__ == '__main__': main()
--
http://mail.python.org/mailman/listinfo/python-list
Re: ? on scipy.fftpack
Robert Kern wrote: > You will probably want to ask scipy questions on scipy-user. There aren't many > scipy people here. > >http://www.scipy.org/Mailing_Lists > > I haven't run your code, yet, but one of the things you are running into is > the > FFT packing convention for FFTs on real functions. Please read the docstring: Ok, thanks a lot. I was unaware of that mailing list, I will certainly go there next. I have read the documentation, but I'm not sure what packing convention you are referring to. -- http://mail.python.org/mailman/listinfo/python-list
Re: ? on scipy.fftpack
Oops, sorry. I see what you mean. I was reading the docs for the regular (complex) fft function, since that was what I was initially having the bug with. I was just using the rfft to simplify things, but I guess that was ironic. Anyway, I appreciate your help and don't mean to burden you. Again, I will suubmit this to the scipy list. -- http://mail.python.org/mailman/listinfo/python-list
