Scientists demonstrate quantum nature of entanglement swapping from PhysOrg.com
As if plain old quantum entanglement weren’t strange enough for modern physics, now physicists are entangling already entangled particles. In entanglement swapping, one particle of an entangled pair becomes entangled with a third particle, which itself becomes entangled with the other particle in the first pair, even though the two never interact. Here’s how physicists are unraveling this behavior and manipulating it for use in quantum communications and high-speed computing.
Discussion of the Essence# programming language, and related issues and technologies.
|Blog Timezone:||America/Los_Angeles [Winter: -0800 hhmm | Summer: -0700 hhmm]|
|Your local time:|
New String-Theory Notion Redefines the Big Bang from PhysOrg.com
String theory — the concept that all particles can be represented as strings or string-loops of incredibly minute length, oscillating at various frequencies — was initially developed to help explain why quarks, the tiny fundamental particles that make up protons and neutrons, are always confined within larger composite particles. However, string theory has evolved to allow scientists to deal with some wider issues. For example, they can use string theory to devise explanations for some grand problems in cosmology, such as the state of the universe — its shape, size, etc. — just after the Big Bang, when quarks roamed freely.
“Our brane model allows us to mathematically address what might have happened at the Big Bang, and also gives a novel interpretation of time in string theory,”
Posted by Alan Lovejoy at 3/31/2006 02:06:00 PM
IBM scientists have developed a powerful new technique for exploring and controlling magnetism at its fundamental atomic level.
The new method promises to be an important tool in the quest not only to understand the operation of future computer circuit and data-storage elements as they shrink toward atomic dimensions, but also to lay the foundation for new materials and computing devices that leverage atom-scale magnetic phenomena.
Link to the rest of the story: IBM Scientists Develop New Way To Explore And Control Atom-scale Magnetism.
Posted by Alan Lovejoy at 3/31/2006 01:48:00 PM
If the experimental result announced today by the European Space Agency holds up to srutiny, a whole new technological domain has been born: gravitomagnetics.
Perhaps those anti-grav "skateboards" from "Back to the Future II" may exist one day after all.
Posted by Alan Lovejoy at 3/24/2006 05:40:00 PM
An XML-encoded version of the Chronos Time Zone Repository is now available from date-time-zone.com. The XML schema is defined by an annotated XSD. The information in the Chronos Time Zone Repository is produced by the Chronos Time Zone Compiler using the Olson Time Zone Database zoneinfo source files.
The Olson Time Zone Database defines the rulesets of over 400 time zones, each identified by a unique key. The rule model of the Chronos Time Zone Repository is based on that of the Olson zoneinfo source files, but extends it with the ability to specify the calendar in which the date of each zone offset transition is specified (currently, the calendar is always the Gregorian calendar, but that may change in the future, since some countries use other calendars to specify annually-recurring zone offset transition dates.)
The Chronos Time Zone Repository also provides the geographic coordinates of the city whose name identifies the time zone (if there is one,) and a default (English) name for about 75 of the most commonly used time zones (based on the name used by Windows.)
The date-time-zone.com site provides links to download the XML version of the Chronos Time Zone Repository (download link: XML version of the Chronos Time Zone Repository) and also the "native to Chronos" version of the Chronos Time Zone Repository (dowload link: native-to-Chronos version of the Chronos Time Zone Repository.)
Chronos itself uses only its own proprietary version of the time zone repository, which is not encoded as XML. The XML-encoded version is intended for the general use of other applications and libraries.
The main advantages of the Chronos Time Zone Repository over other distributions of time zone repositories based on the Olson data are that a) the Chronos rule model preserves the original transition ruleforms based on annually-recurring dates (and the date and time of zone offset transitions is specified in a way that is independent of issues such as leap days and leap seconds,) b) the Chronos ruleset files contain all the information for each time zone--there is no need to cross reference with information from other files, nor to deal with the complex rule macros used in Olson's zoneinfo source files, c) it's available in XML, with syntax governed by a fully-annotated XSD, and d) there's a machine-consumable Atom feed for the announcement of new versions.
Olson publishes a new version of the time zone data about once a month. When that happens, the Chronos Time Zone Compiler is used to generate a new version of the Chronos Time Respository from the new Olson zoneinfo source files, a new version of the Chronos XML Time Zone Repository is then generated, and finally the Atom feed is updated to announce the new version.
Posted by Alan Lovejoy at 3/22/2006 12:30:00 PM
[Note: Due to problems encountered when installing this version of Chronos into versions of Squeak prior to 3.8, the installation instructions have changed]
Thanks to Avi Bryant, who published a preliminay port of Chronos to Squeak which I have used as the basis for further refinement, there is now a highly functional version of Chronos for Squeak.
I am very appreciative of the contribution that Avi has made towards porting Chronos to Squeak (which includes, in addition to actual code, advice and problem reports.) I believe he intends to continue to contribute improvements. We would both welcome contributions from others.
The new version, unlike the version initially published, can read reference data from the file system--especially including time zone rulesets. It can also persist reference data in the local file system. The Chronos Time Zone Compiler can be installed, and it can be used to compile Chronos time zone rule files from the Olson zoneinfo source files.
However, the current Squeak version still does not have all the functionality of the VisualWorks version--although what's there and working provides a level of functionality that substantially exceeds that provided by the native (as packaged by the vendor/distributor) date/time libraries of either VisualWorks or Squeak (or the "out of the box" date/time libraries of any other programming language, for that matter.)
Here's what's currently not working/implemented in the Squeak version of Chronos:
- Determination of the host system time zone (this would require new primitives or FFI function libraries--and is something that is not at all on my to-do list)
- Support for any Locale other than #en_US--I may (or may not) decide to use the data published by the Common Locale Data Repository (CLDR) Project to provide such functionality for Squeak (and for other Smalltalk implementations as well,) but that won't happen for many months yet, if it happens at all
- Convenience methods implemented in Squeak classes that leverage Chronos (e.g., String>>asTimezone, Number>>hours, etc.)--the issue here, of course, is interference with the native Chronology library's own such convenience methods (Note: Implementing such convenience methods for Chronos is the sole responsibility of the Squeak community)
- Type-compatibility of Chronos classes with the analogous Chronology classes (Note: Implementing such type-compatibility methods for Chronos (or Chronos-compatibility for Chronology, for that matter) is the sole responsibility of the Squeak community)
If you browse the Chronos code, you will come accross example methods, and/or comments with executable example code, that depend upon Chronos functionality that is not currently implemented for the Squeak version (as specified above.) But the only missing functionality that is at all likely to impact most users (who stick with Chronos' default Locale and native API, don't expect there to be "convenience methods" that leverage Chronos in non-Chronos classes, and don't try to use Chronos and Chronology objects interchangeably) is the fact that the current version does not (and in fact, cannot, because Squeak cannot) determine the local time zone from the host operating system.
Of course, Squeak's native Chronology library also lacks such functionality--so Squeakers should be used to not having Squeak automatically determine their local time zone (by the way, that's a hard problem--although having Chronos installed makes it a much easier problem than it would be otherwise--as the VW version of Chronos demonstrates.)
Further mitigating the inability to discover the host system's local time zone is the fact that Squeak's system clock runs in local time, and not in Universal Time--which means that Squeak correctly reports the current date and time without needing to know what time zone it's in. Nevertheless, not knowing the local time zone can be a problem in some situations--especially when there are multiple users and/or machines in multiple time zones all trying to collaborate with each other. But that never happens, right? </sarcasm>
The new version of Chronos for Squeak can be obtained from the Chronos web site. Or you can use the following direct link to download the Chronos Date/Time Library for Squeak (based on Chronos version B1.150 for VisualWorks.)
- Extract all files from the downloaded archive file (Chronos.zip.) All the files start with the path-prefix "Chronos-B1.150/".
- Set up a folder with the image into which you will be installing Chronos.
- Move or copy the "Chronos-B1.150/time-zones" folder to the directory containing the image into which you will be installing Chronos, so that the "time-zones" folder is an immediate subdirectory of the directory containing your image (alternatively, move/copy your image into <wherever-you-extracted-the-files>/Chronos-B1.150/).
- Remove any previously-installed version of Chronos from your image (or use a "virgin" image.)
- File in Chronos-B1.150/Chronos.st. Answer "yes" both times the pop-up menu asks whether to auto-declare a shared-pool Dictionary. If you get the complaint that "English" is already defined, just "proceed." Save your image.
- File in either Chronos-B1.150/Chronos-System-Squeak.st or Chronos-B1.150/Chronos-System-SqueakClassic.st (but not both!) Chronos-System-Squeak.st is for Squeak 3.7 and later. Chronos-System-SqueakClassic.st is for versions of Squeak prior to 3.7. A Transcript window should open, and successful installation should then be reported to the Transcript window--along with other information, such as the pathnames to various sub-folders in the "time-zones" folder, and the selected language and country codes (which for Squeak, will always be English (#en) and United States (#US.)) Two warning messages may also be displayed about the inability to define the globals DateAndTime and Duration--that's not a problem, as long as the programmer understands that he must use the globals ScientificDuration and Timepoint instead of the ANSI-specified names (both of which are already taken by Chronology classes with the names at issue.)
- Older versions of Squeak may lack some of the VW-compatibility methods on which Chronos depends. One likely symptom of this problem would the error "Message not understood: #writeStream." One solution would be to backport the VW-compatibility methods from a later version of Squeak. Another solution would be to use a later version of Squeak.
- Save your image. Note that, although the reported date/time of installation will be the same as that reported by your operating system as local time, the offset and zone identification will probably not be correct for your location. That's what happens when a) the system clock reports local time, and b) there's no way to determine the local time zone from the host operating system. If the class "TimeZone" is resident in the image (a class belonging to Squeak's native Chronology date/time library,) Chronos uses the abbreviation and/or offset of the "DateAndTime localTimeZone" to do the best it can at setting the Chronos system time zone. Of course, if the Chronology time zone hasn't been set, that won't help you much.
- Set your local time zone, if the one chosen by Chronos is not correct. Here are some example expressions that can be evaluated as "do its" to set Chronos' system time zone (setting the Chronos system time zone will also set the Chronology local time zone to have the same offset, name and abbreviation as are currently in effect for the selected time zone):
(Timezone at: #'Australia/Sydney') beSystem
(Timezone at: #'Asia/Tokyo') beSystem
(Timezone at: #'Asia/Calcutta') beSystem
(Timezone at: #'Europe/Moscow') beSystem
(Timezone at: #'Europe/Athens') beSystem
(Timezone at: #'Europe/Berlin') beSystem
(Timezone at: #'Europe/London') beSystem
(Timezone at: #'America/New_York') beSystem
(Timezone at: #'America/Chicago') beSystem
(Timezone at: #'America/Denver') beSystem
(Timezone at: #'America/Phoenix') beSystem
(Timezone at: #'America/Los_Angeles') beSystem
To see the full list of time zone keys, open an inspector on the result of evaluating 'Timezone allCanonicalKeys'.
Instances of Chronos' Timepoint, YearMonthDay, TimeOfDay, ScientificDuration and ChronosTimezone classes can all be converted into their native Squeak equivalents by sending the message #asNative to the instance. Instances of Squeak's DateAndTime, Date, Time, Duration and TimeZone classes can be converted into their Chronos equivalents by sending the message #asChronosValue to the instance.
Because Chronos has both ScientificDurations (purely a number of fractional seconds, just like a Squeak Duration) and CivilDurations (which independently specify the number years, months, days, hours, minutes, seconds and fractions of a second represented by a temporal extent,) Chronos does not need any classes that are analogous to Squeak's Year, Month or Week classes. Instead, Chronos just uses the single class Timeperiod, with an appropriate CivilDuration, to provide the same functionality.
A Chronos YearMonthDay is more or less equivalent to a Squeak Date, except that a YearMonthDay is a point-in-time value whose resolution is one calendar day (civil time,) whereas a Squeak Date is implemented as an interval whose duration is one day (of exactly 86400 seconds, even when there are more or less than that many seconds in the day due to DST transitions and/or leap seconds.)
A Chronos Timepoint may be either invariant to Universal Time (same semantics as a java.util.Date--as required by the ANSI Smalltalk Standard) or invariant to nominal time (same semantics as a VisualWorks Timestamp.) A Timepoint that is invariant to Universal Time uses its value in Universal Time as its invariant, and compares as equal to all others whose value in Universal Time is the same. A Timepoint that is invariant to nominal time uses its nominal ("local") time as its invariant, and compares as equal to all others having the same nominal ("local") time. When the two types of time-invariance are mixed in the same expression, nominal-time-invariant semantics takes precedence. Universal-Time invariance is the default.
Posted by Alan Lovejoy at 3/19/2006 10:53:00 PM
Nanotechnologists demonstrate artificial muscles powered by highly energetic fuels from PhysOrg.com
University of Texas at Dallas nanotechnologists have made alcohol- and hydrogen-powered artificial muscles that are 100 times stronger than natural muscles, able to do 100 times greater work per cycle and produce, at reduced strengths, larger contractions than natural muscles. Among other possibilities, these muscles could enable fuel-powered artificial limbs, "smart skins" and morphing structures for air and marine vehicles, autonomous robots having very long mission capabilities and smart sensors that detect and self-actuate to change the environment.
Posted by Alan Lovejoy at 3/16/2006 12:40:00 PM
Chronos Version B1.140 has been publised ("Beta Release 1--build 140".) Chronos B1.140 is available for VisualWorks only--although the Chronos Seed Archive for B1.140 is also available (the "Chronos Seed" is the platform-independent Chronos codebase, used for porting Chronos from VisualWorks to other Smalltalk pltatforms.) The Squeak version (maintained by Avi Bryant) hasn't changed.
Chronos Version B1.140 can be obtained from the Chronos Web Site, or from the Cincom Public StORE Repository. Or you can use the direct download link.
You should also obtain and install the latest version of the Chronos Time Zone Repository, according to the Chronos Installation Instructions. Otherwise, much of Chronos' time zone functionality will not be available. The latest version of the Chronos Time Zone Repository is included in the archive file that contains the Chronos codebase ("Chronos.zip.") Formerly, that was not the case.
About Chronos Version B1.140
Version B1.140 includes a few bug fixes, but no new functionality. It does include some significant reengineering/refactoring of Chronos' "infrastructure code." Specifically, the changed code deals with the initializatation of Chronos, and also with the management/retrieval of Chronos reference data, such as time zone rules and locale information. None of the date/time logic was touched (and after extensive testing, I can find no bugs in that code.)
The substantive changes in Version B1.140 are two:
1. Chronos can now be published as a VisualWorks parcel. Parcels for the date/time library (Chronos.pcl) and for the time zone compiler (Chronos-Utilities.pcl) are now included in the download archive (Chronos.zip,) along with the the two file-ins (Chronos.st and Chronos-Utilities.st.) Note that the Chronos parcels, just like the file-ins, should not be loaded into an image in which a different version of Chronos is already resident. It is necessary to first uninstall ("remove," "unload") the already-resident Chronos bundle (or the already-resident Chronos-Utilities bundle, as the case may be) before installing a parcel (or file-in) containing a different version.
2. The "Chronos.zip" archive file now also contains the Chronos Time Zone Repository. So it is now only necessary to download that separately when a) there's a new version of the time zone repository you'd like to use, and/or b) you're installing Chronos from the Cincom Public PostGreSQL StORE Repository (or Monticello, once the Squeak version is able to read from disk files.)
Posted by Alan Lovejoy at 3/15/2006 10:51:00 PM
Chronos Version B1.120 has been publised ("Beta Release 1--build 120".) Chronos B1.120 is available for VisualWorks only--although the Chronos Seed Archive for B1.120 is also available (the "Chronos Seed" is the platform-independent Chronos codebase, used for porting Chronos from VisualWorks to other Smalltalk pltatforms.) The Squeak version (maintained by Avi Bryant) hasn't changed.
Chronos Version B1.120 can be obtained from the Chronos Web Site, or from the Cincom Public StORE Repository. Or you can use the direct download link.
You should also obtain and install the latest version of the Chronos Time Zone Repository, according to the Chronos Installation Instructions. Otherwise, much of Chronos' time zone functionality will not be available. The latest version of the Chronos Time Zone Repository provides additional data about time zones that was absent from earlier versions. The new data will be invisible to versions of Chronos previous to B1.120. Version B1.120 can use older versions of the Chronos Time Zone Repository--but some of the new functionality will be disabled in that case.
About Chronos Version B1.120
Version B1.120 includes a few bug fixes, some new functionality, and most importantly a significantly-improved design/implementation of the infrastructure for accessing persistent/remote resources (such as time zone rule sets.) The goal of this redesign is to enable accessing time zone rule sets, time zone localization policies, locale data and holiday rule definitions from reference data servers over the internet (or perhaps just over a LAN from an organization's own private servers.)
New functionality includes default zone names (in English only) for about 75 of the most commonly used time zones (e.g., "Eastern Time" for "America/New_York") and geographic coordinates for most Olson time zones.
Finally, I have further refined Chronos's ability to handle reinstallation/reinitialization of a new version on top of an already-installed earlier version. This not only makes it easier to change versions (there is no need to migrate one's whole codebase to a new image, nor to first uninstall the old version of Chronos before installing the new version--provided one uses a version/module manager such as StORE; file-ins always require deinstallation of the old Chronos version before filing-in a new version,) it also makes it easier to do significant refactorings of the Chronos codebase.
I highly recommend using Chronos version B1.120 as a "waypoint" for migrating from earlier versions of Chronos to later versions. The testing I have done gives me great confidence that StORE can be used to do a live update to version B1.120 from any previous version of Chronos. Such may not always be the case for future versions. From this point forward, I will only be testing for StORE updatability from version B1.120 and later to future versions, and do not guarantee that versions prior to B1.120 will be hot-swappable (using StORE) with versions later than B1.120.
Posted by Alan Lovejoy at 3/13/2006 02:26:00 AM
Chronos Version B1.101 has been publised ("Beta Release 1--build 101".) Chronos B1.101 is available for VisualWorks only--although the Chronos Seed Archive for B1.101 is also available (the "Chronos Seed" is the platform-independent Chronos codebase, used for porting Chronos from VisualWorks to other Smalltalk pltatforms.) The Squeak version (maintained by Avi Bryant) hasn't changed.
Chronos Version B1.101 can be obtained from the Chronos Web Site, or from the Cincom Public StORE Repository. Or you can use the direct download link.
NOTE: Unless you have done so previously, you will also need to obtain and install the Chronos Time Zone Repository, according to the Chronos Installation Instructions. Otherwise, much of Chronos' time zone functionality will not be available.
About Chronos Version B1.101
Version B1.101 includes a few bug fixes, but mostly the changes from the last released version were motivated by the following issue: What happens when a different (whether newer or older) version of Chronos is installed on top of a version already resident in the image?
First, let me level set: The issue is what happens when one uses a module/version management tool such as StORE or Monticello. I have no expectation that it would ever be possible to file in one version on top of another, unless the "new" version were in the form of a "change set" (i.e, the file-in onlly included the changes between the old and new versions.) I do not distribute "change sets" for Chronos. Those can always be generated on demand by StORE (and also, I hope but don't actually know, by Monticello,) should anyone need such a thing. When using file-ins, it is necessary to first totally remove the previously-installed version from the target image (or just use a new image.)
I believe I have solved all the issues that I was able to discover or discern. I have tested installing version B1.101 (using StORE) on top of various older versions--including the very first version available from the Cincom Public StORE Repository. Every older version I have tried (and I tried many of them) all work, when going to version B1.101--and that's not true for any previous version of Chronos.
The reason I decided to focus on this issue is because I will soon be making fundamental changes in order to fully support not just leap seconds, but mutiple alternative time scales: apparent solar time, time on Mars, etc. Or more precisely, to enable such timescales to be supported simply by subclassing Timescale.
Posted by Alan Lovejoy at 3/08/2006 10:09:00 PM
Experimental atomic clock uses ytterbium 'pancakes' from PhysOrg.com
Scientists at the National Institute of Standards and Technology working with Russian colleagues have significantly improved the design of optical atomic clocks that hold thousands of atoms in a lattice made of intersecting laser beams.
Well, I had to blog this one, I guess :-)
Posted by Alan Lovejoy at 3/06/2006 11:42:00 PM
Chronos Version B1.80 has been publised ("Beta Release 1--build 80".) Chronos B1.80 is available for VisualWorks only--although the Chronos Seed Archive for B1.80 is also available. The Squeak version hasn't changed. Avi Bryant (who is responsible for the Squeak distribution) has been busy getting well-deserved awards and recognition (go Avi!)
Unless you have done so previously, you will also need to obtain and install the Chronos Time Zone Repository, according to the Chronos Installation Instructions.
Chronos Version B1.80 can be obtained from the Chronos Web Site, or from the Cincom Public StORE Repository. Or you can use the direct download link.
About Chronos Version B1.80
Mostly, B1.80 fixes bugs. I have spent considerable time over the past few days running tests, thinking up new things to test, and browsing the code for inspiration about what might go wrong. I found a few things, too--some of them surprised me.
Also, I have been working on making Chronos more robust with respect to having a new version loaded from a module/version management system such as StORE or Monticello. It's actually much harder to correctly reinstall a new version on top of an old one, than it is to do a clean install from the ground state. It's something I always test before I promote the blessing level to Released.
Finally, I have been working on making it possible to load time zone rule sets from a remote server over the internet. In connection with that, I have also been working on an XML representation of time zone rulesets, so that even non-Chronos systems could consume the information. This issue is driving a rethinking of the Chronos time zone rule model, to ensure it's as general and comprehensive as it ought to be for general use over the internet. The requirements for a public interchange format are not the same as those of an internal, private repository.
As part of that project, I have implemented the Visitor design pattern for Chronos time zones. It can be used to convert a Chronos time zone into something else, such as a serialized object stream for network transmission, XML files for the same purpose, or binary tz files (Unix.)
Posted by Alan Lovejoy at 3/05/2006 11:59:00 PM