Mailman 3 December 2004 - Distutils-SIG

The limitation of the Photon Hypothesis
by bill 20 Dec '04

20 Dec '04

The limitation of the Photon Hypothesis According to the electromagnetic theory of light, its energy is related to the amplitude of the electric field of the electromagnetic wave, W=eE^2V(where E is the amplitude and V is the volume). It apparently has nothing to do with the light's frequency f. To explain the photoelectric effect, Einstein put forward the photon hypothesis. His paper hypothesized light was made of quantum packets of energy called photons. Each photon carried a specific energy related to its frequency f, W=hf. This has nothing to do with the amplitude of the electromagnetic wave E. For the electromagnetic wave that the amplitude E has nothing to do with the light's frequency f, if the light's frequency f is high enough, the energy of the photon in light is greater than the light's energy, hf>eE^2V. Apparently, this is incompatible with the electromagnetic theory of light. THE UNCERTAINTY PRINCIPLE IS UNTENABLE By re-analysing Heisenberg's Gamma-Ray Microscope experiment and one of the thought experiment from which the uncertainty principle is demonstrated, it is actually found that the uncertainty principle cannot be demonstrated by them. It is therefore found to be untenable. Key words: uncertainty principle; Heisenberg's Gamma-Ray Microscope Experiment; thought experiment The History Of The Uncertainty Principle If one wants to be clear about what is meant by "position of an object," for example of an electron., then one has to specify definite experiments by which the "position of an electron" can be measured; otherwise this term has no meaning at all. --Heisenberg, in uncertainty paper, 1927 Are the uncertainty relations that Heisenberg discovered in 1927 just the result of the equations used, or are they really built into every measurement? Heisenberg turned to a thought experiment, since he believed that all concepts in science require a definition based on actual, or possible, experimental observations. Heisenberg pictured a microscope that obtains very high resolution by using high-energy gamma rays for illumination. No such microscope exists at present, but it could be constructed in principle. Heisenberg imagined using this microscope to see an electron and to measure its position. He found that the electron's position and momentum did indeed obey the uncertainty relation he had derived mathematically. Bohr pointed out some flaws in the experiment, but once these were corrected the demonstration was fully convincing. Thought Experiment 1 The corrected version of the thought experiment Heisenberg's Gamma-Ray Microscope Experiment A free electron sits directly beneath the center of the microscope's lens (please see AIP page http://www.aip.org/history/heisenberg/p08b.htm or diagram below) . The circular lens forms a cone of angle 2A from the electron. The electron is then illuminated from the left by gamma rays--high-energy light which has the shortest wavelength. These yield the highest resolution, for according to a principle of wave optics, the microscope can resolve (that is, "see" or distinguish) objects to a size of dx, which is related to and to the wavelength L of the gamma ray, by the expression: dx = L/(2sinA) (1) However, in quantum mechanics, where a light wave can act like a particle, a gamma ray striking an electron gives it a kick. At the moment the light is diffracted by the electron into the microscope lens, the electron is thrust to the right. To be observed by the microscope, the gamma ray must be scattered into any angle within the cone of angle 2A. In quantum mechanics, the gamma ray carries momentum as if it were a particle. The total momentum p is related to the wavelength by the formula, p = h / L, where h is Planck's constant. (2) In the extreme case of diffraction of the gamma ray to the right edge of the lens, the total momentum would be the sum of the electron's momentum P'x in the x direction and the gamma ray's momentum in the x direction: P' x + (h sinA) / L', where L' is the wavelength of the deflected gamma ray. In the other extreme, the observed gamma ray recoils backward, just hitting the left edge of the lens. In this case, the total momentum in the X direction is: P''x - (h sinA) / L''. The final x momentum in each case must equal the initial X momentum, since momentum is conserved. Therefore, the final X moment are equal to each other: P'x + (h sinA) / L' = P''x - (h sinA) / L'' (3) If A is small, then the wavelengths are approximately the same, L' ~ L" ~ L. So we have P''x - P'x = dPx ~ 2h sinA / L (4) Since dx = L/(2 sinA), we obtain a reciprocal relationship between the minimum uncertainty in the measured position, dx, of the electron along the X axis and the uncertainty in its momentum, dPx, in the x direction: dPx ~ h / dx or dPx dx ~ h. (5) For more than minimum uncertainty, the "greater than" sign may added. Except for the factor of 4pi and an equal sign, this is Heisenberg's uncertainty relation for the simultaneous measurement of the position and momentum of an object. Re-analysis The original analysis of Heisenberg's Gamma-Ray Microscope Experiment overlooked that the microscope cannot see the object whose size is smaller than its resolving limit, dx, thereby overlooking that the electron which relates to dx and dPx respectively is not the same. According to the truth that the microscope can not see the object whose size is smaller than its resolving limit, dx, we can obtain that what we can see is the electron where the size is larger than or equal to the resolving limit dx and has a certain position, dx = 0. The microscope can resolve (that is, "see" or distinguish) objects to a size of dx, which is related to and to the wavelength L of the gamma ray, by the expression: dx = L/(2sinA) (1) This is the resolving limit of the microscope and it is the uncertain quantity of the object's position. The microscope cannot see the object whose size is smaller than its resolving limit, dx. Therefore, to be seen by the microscope, the size of the electron must be larger than or equal to the resolving limit. But if the size of the electron is larger than or equal to the resolving limit dx, the electron will not be in the range dx. Therefore, dx cannot be deemed to be the uncertain quantity of the electron's position which can be seen by the microscope, but deemed to be the uncertain quantity of the electron's position which can not be seen by the microscope. To repeat, dx is uncertainty in the electron's position which cannot be seen by the microscope. To be seen by the microscope, the gamma ray must be scattered into any angle within the cone of angle 2A, so we can measure the momentum of the electron. But if the size of the electron is smaller than the resolving limit dx, the electron cannot be seen by the microscope, we cannot measure the momentum of the electron. Only the size of the electron is larger than or equal to the resolving limit dx, the electron can be seen by the microscope, we can measure the momentum of the electron. According to Heisenberg's Gamma-Ray Microscope Experiment, the electron��s momentum is uncertain, the uncertainty in its momentum is dPx. dPx is the uncertainty in the electron's momentum which can be seen by microscope. What relates to dx is the electron where the size is smaller than the resolving limit. When the electron is in the range dx, it cannot be seen by the microscope, so its position is uncertain, and its momentum is not measurable, because to be seen by the microscope, the gamma ray must be scattered into any angle within the cone of angle 2A, so we can measure the momentum of the electron. If the electron cannot be seen by the microscope, we cannot measure the momentum of the electron. What relates to dPx is the electron where the size is larger than or equal to the resolving limit dx .The electron is not in the range dx, so it can be seen by the microscope and its position is certain, its momentum is measurable. Apparently, the electron which relates to dx and dPx respectively is not the same. What we can see is the electron where the size is larger than or equal to the resolving limit dx and has a certain position, dx = 0. Quantum mechanics does not rely on the size of the object, but on Heisenberg's Gamma-Ray Microscope experiment. The use of the microscope must relate to the size of the object. The size of the object which can be seen by the microscope must be larger than or equal to the resolving limit dx of the microscope, thus the uncertain quantity of the electron's position does not exist. The gamma ray which is diffracted by the electron can be scattered into any angle within the cone of angle 2A, where we can measure the momentum of the electron. What we can see is the electron which has a certain position, dx = 0, so that in no other position can we measure the momentum of the electron. In Quantum mechanics, the momentum of the electron can be measured accurately when we measure the momentum of the electron only, therefore, we have gained dPx = 0. And, dPx dx =0. (6) Thought Experiment 2 Single Slit Diffraction Experiment Suppose a particle moves in the Y direction originally and then passes a slit with width dx(Please see diagram below) . The uncertain quantity of the particle's position in the X direction is dx, and interference occurs at the back slit . According to Wave Optics , the angle where No.1 min of interference pattern can be calculated by following formula: sinA=L/2dx (1) and L=h/p where h is Planck's constant. (2) So the uncertainty principle can be obtained dPx dx ~ h (5) Re-analysis The original analysis of Single Slit Diffraction Experiment overlooked the corpuscular property of the particle and the Energy-Momentum conservation laws and mistook the uncertain quantity of the particle's position in the X direction is the slit's width dx. According to Newton first law , if an external force in the X direction does not affect the particle, it will move in a uniform straight line, ( Motion State or Static State) , and the motion in the Y direction is unchanged .Therefore , we can learn its position in the slit from its starting point. The particle can have a certain position in the slit and the uncertain quantity of the position is dx =0. According to Newton first law , if the external force at the X direction does not affect particle, and the original motion in the Y direction is not changed , the momentum of the particle in the X direction will be Px=0 and the uncertain quantity of the momentum will be dPx =0. This gives: dPx dx =0. (6) No experiment negates NEWTON FIRST LAW. Whether in quantum mechanics or classical mechanics, it applies to the microcosmic world and is of the form of the Energy-Momentum conservation laws. If an external force does not affect the particle and it does not remain static or in uniform motion, it has disobeyed the Energy-Momentum conservation laws. Under the above thought experiment , it is considered that the width of the slit is the uncertain quantity of the particle's position. But there is certainly no reason for us to consider that the particle in the above experiment has an uncertain position, and no reason for us to consider that the slit's width is the uncertain quantity of the particle. Therefore, the uncertainty principle, dPx dx ~ h (5) which is demonstrated by the above experiment is unreasonable. Conclusion Every physical principle is based on the Experiments, not based on MATHEMATICS, including heisenberg uncertainty principle. Einstein said, One Experiment is enough to negate a physical principle. >From the above re-analysis , it is realized that the thought experiment demonstration for the uncertainty principle is untenable. Therefore, the uncertainty principle is untenable. Reference: 1. Max Jammer. (1974) The philosophy of quantum mechanics (John wiley & sons , Inc New York ) Page 65 2. Ibid, Page 67 3. http://www.aip.org/history/heisenberg/p08b.htm Single Particles Do Not Exhibit Wave-Like Behavior Through a qualitative analysis of the experiment, it is shown that the presumed wave-like behavior of a single particle contradicts the energy-momentum conservation laws and may be expained solely through particle interactions. DUAL SLIT INTERFERENCE EXPERIMENT PART I If a single particle has wave-like behavior, it will create an interference image when it has passed through a single slit. But the experimental result shows that this is not the case Only a large number of particles can create an interference image when they pass through the two slits. PART II In the dual slit interference experiment, the single particle is thought to pass through both slits and interfere with itself at the same time due to its wave-like behavior. The motion of the wave is the same direction as the particle. If the particle passes through a single slit only, it can not be assumed that it has wave-like behavior. If it passes through two slits, it, and also the acompanying wave must be assumed to have motion in two directions. But a wave only has one direction of motion. PART III If one slit is obstructed in the dual slit interference experiment and a particle is launched in this direction, then according to Newton��s first law, (assuming no external forces,) it will travel in a uniform straight line. It will not pass through the closed slit and will not make contact with the screen. If it has wavelike behavior, there is a probability that it will make contact. But this will negate Newton��s first law and the law of conservation of energy and momentum. Both quantum mechanics and classical mechanics are dependent on this law. THE EXPLANATION FOR THE WAVE-LIKE BEHAVIOR OF THE PARTICLE In the dual slit interference experiment, if one slit is unobstructed, particles will impact at certain positions on the screen. But when two slits are open, the particles cannot reach these positions. This phenomenon brings us to the greatest puzzle regarding the image of the particle. But when we consider that the particle may experience two or more reflections, the puzzle may be resolved. As indicated, when one of the slits is obstructed, the particles that move towards this slit cannot get to the screen. However, they can return to the particle source by reflection and then pass through the open slit and reach the above positions since they have different paths when one or two slits are open. This indicates that wave-like behavior may be explained solely on the basis of particle interactions. EXPERIMENTAL TEST The above may be tested by an experiment that can absorb all the particles that move towards the closed slit. If one slit is obstructed by the stuff that can absorb all the particles that move towards it, the intensity of some positions on the screen should decrease THE CONCLUSION Single particles do not exhibit wave-like behavior. The similarity of wave and particle behavior may be attributed to initial impulse and path. The quantum mechanical explanation is suspect, since the probability of one particle and one particle among a large quantity reaching the screen is equal in mathematics and physics. Author : BingXin Gong Postal address : P.O.Box A111 YongFa XiaoQu XinHua HuaDu GuangZhou 510800 P.R.China E-mail: hdgbyi(a)public.guangzhou.gd.cn Tel: 86---20---86856616

1 0

Import extensions from zipfiles (windows only)
by Thomas Heller 16 Dec '04

16 Dec '04

I have a first working version of an importer which can import extension modules from zipfiles, avoiding to unpack them to the file system. License is still LGPL, unfortunately. Subscribers to the py2exe-users list already know that it uses this code which simulates the windows LoadLibrary call: http://www.joachim-bauch.de/tutorials/load_dll_memory.html It works in simple cases, the only ones that I have tested so far. Shall I publish it for experimentation? Thomas

3 6

Standardizing distribution of "plugins" for extensible apps
by Phillip J. Eby 09 Dec '04

09 Dec '04

Many applications need or want to be able to support extension via dynamic installation of "plugin" code, such as Zope Products, Chandler Parcels, and WSGI servers' "application" objects. Frequently, these plugins may require access to other plugins or to libraries of other Python code. Currently, application platforms must create their own binary formats to address their specific requirements, but these formats are of course specific to the platform and not portable, so it's not possible to package a third-party module just once, and deploy it in any Python application platform. Although each platform may have its own additional requirements for the contents of such a "plugin", the minimum basis for such plugins is that they include Python modules and other files, and import and export selected modules. Although the standard distutils pattern is to use a platform's own packaging system, this really only makes sense if you are dealing with Python as a language, and not as an application platform. Platform packaging doesn't make sense for applications that are end-user programmable, because even if the core application can be installed in one location, each instance of use of that application (e.g. per user on a multi-user system) may have its own plugins installed. Therefore, I would like to propose the creation of: * a binary package format optimized for "plugin" use (probably just a specific .zip layout) * a distutils "bdist" command to package a set of modules in this format * A PEP 302 importer that supports running of code directly from plugin distributions, and which can be configured to install or extract C extension modules. (This will serve as a base for platform developers to create their platform-specific plugin registries, installation mechanisms, etc., although there will be opportunity for standardization/code sharing at this level, too.) * additions to setup() metadata to support declaration of: * modules required/provided, with version information * platform metadata for C extensions contained in the plugin distribution * ability to specify metadata files to be included in the distribution, that are specific to the target application platform (e.g. Zope config files, Chandler parcel schemas, WSGI deployment configuration, etc.) (This is actually only "level 1" of the standardization that I'd like to do; levels 2 and 3 would address runtime issues like startup/shutdown of plugins, automatic dependency resolution, isolation between plugins, and mediated service discovery and service management across plugins. However, these other levels are distinct deliverables that don't necessarily relate to the distutils, except insofar as those levels may influence requirements for the first level. Also, it's important to note that even without those higher levels of standardization, the availability of a "plug and play" distribution format should be beneficial to the Python community, in making it easier for applications to bundle arbitrary libraries. Indeed, tools like py2exe and py2app might grow the ability to automatically "link" bundles needed by an application, and there will likely be many other spin-off uses of this technology once it's available.) My main idea is to expand the existing PKG-INFO format, adding some formally-defined fields for system processing, that are supplied by the setup script or in additional files. The additional metadata should be syntactically validated (and semantically, to the extent possible), and the distutils should not knowingly produce a plugin package with invalid execution metadata. The specific kinds of metadata needed (that I know of currently) are: * Static imports (module names and specification of compatible versions) * Dynamic imports (wildcard masks) * Exports (module names and versions) * Platform requirements for included extension modules * Other platform requirements * Entry point for dynamic integration (technically a level 2 feature, but it'd be nice to reserve the header and define its syntax) * Update URL (for obtaining the "latest" version of the plugin) There are several issues that would have to be hammered out, here. Versioning, for example, both in the sense of formats and qualifiers, and in the sense of versioning a module/package versus versioning a distribution. Gathering information about imports is also tricky. Tools like py2exe try to gather some of this information automatically, but that info doesn't include version requirements. (It may be that we can get by without version requirements, taking the default state to mean, "any version will do.") Platform specs are another dicey issue, since we're talking about trying to define binary compatibility here. This includes the issue that it might be necessary to include shared libraries other than the C extensions themselves. (For example, like the wxWidgets libraries that ship with wxPython.) While researching a deployment strategy for WSGI, I discovered the OSGi specifications for Java, which address all of these issues and more. Where OSGi's solutions are directly usable, I'd like to apply them, rather than re-inventing wheels... not to mention axles, brakes, and transmissions! However, their syntax for these things is often weird and verbose, and could probably use some "Pythonizing". Anyway, I would see the deliverables here as being a PEP documenting the format, and a prototype implementation in setuptools (for current Python versions), that would then migrate to an official implementation in the distutils for Python 2.5. I'd like to find out "who's with me" at this stage in having an interest in any aspect of this project, especially if you have requirements or issues I haven't thought of. Thanks!

4 19

[ANN] py2app 0.1.6
by Bob Ippolito 07 Dec '04

07 Dec '04

I've rolled together a new 0.1.6 release of py2app <http://undefined.org/python/#py2app> that includes the following feature enhancements and probably a few bug fixes: modulegraph: - This is now a top-level package and should be cross-platformish and not at all py2app specific (if someone wants a project, integrate this into py2exe/cx_Freeze/etc.) altgraph: - Some common code between modulegraph and macholib was moved into altgraph (the ObjectGraph data structure, for example) macholib: - Lots of code in its supporting library, ptypes, was removed, rewritten and optimized for performance and simplicity. - The API has totally been changed (I don't think anyone else uses it, so I don't feel bad about it :) - It uses altgraph for its data structure now - More correct algorithms for locating dylibs and frameworks based upon a thorough reading of the dyld source code bdist_mpkg: - Made the dependency checking more specific for better Installer compatibility - Fixed some minor bugs py2app: - New "plugin" target for building loadable bundles (i.e. Interface Builder palettes). This is a crazy hack, and will never work perfectly due to the icky globalness of the Python interpreter, but works well enough in practice. - Plugin example - Sets a new ARGVZERO environment variable that points to the argv[0] that was passed to main(...). - Sets a new EXECUTABLEPATH environment variable that points to the actual path of the executable that was run (which will be == to ARGVZERO most of the time) - suboptimal PyQt support (sip and PyQt are built in really strange ways and have lots of interdependencies at the C/C++ level so whenever you use ANY sip module you use ALL sip modules) - PyQt example - suboptimal PyOpenGL support (PyOpenGL has a stupid way of finding its version that prevents it from being easily bundled) - PyOpenGL example - py2applet command line tool (performs the same function as the GUI app) -bob

1 0

Embedding C with Python
by Terry Ware 04 Dec '04

04 Dec '04

I work on windows platforms and I have a collection of C routines that are distributed via a DLL. These routines have embedded python calls. Currently I have to distribute the python modules separately from the C DLL. Is there a way using distutils for me to combine the python scripts with the C code in the C DLL so that all I have to distribute is my C DLL along with the pythonxx.dll? Thanks for your time, Terry Terry Ware Sr. Software Engineer BAE Systems Advanced Information Technologies Suite 500 3811 North Fairfax Drive Arlington Va. 22203 office: (703)284-8425 fax: (703)524-6280 terry.ware(a)baesystems.com

4 3