Actually, it's unknown whether integer factorization (into primes) is an NP problem. Although a P-time solution to an NP-complete problem class (e.g. 3-SAT) would result in a P-time solution to integer factorization, the converse (polynomial time factorization implying P=NP) isn't known to hold. (And seems unlikely to be the case given the number of complexity classes that would collapse together. (ibid.))
For a long time, it was believed that even just testing an integer for primality might require super-polynomial (equiv. sub-exponential) time, which would have made the problem of just testing a candidate factor for primality not lie in P-time. But Agrawal et al. produced a P-time primality test algorithm in 2002. This result made it less clear that integer factorization into primes was necessarily not P-time. (If it were provable that testing for primality was impossible in P-time then integer factoring is not in P-time, because otherwise an integer could be tested for primality by trying to factor it and this would either return "is prime" (i.e. the trivial factorization n = 1*n) or would return "is composite" (i.e. the nontrivial factorization n = p*q) in polynomial time.) So a P-time primality test made it less clear which time complexity class integer factorization (into primes) lived in.
In spite of this nit-picking, your basic idea is right.:-)
I have been involved in experimental science ranging in scale from preliminary survey of the support variable space to rigorously designed (as in design of experiment = "DoX") production support runs. The short answer to your question is: It depends.
Mostly it depends on two things:
How similar is the space of experiments you are performing?
What sorts of questions do you intend to answer from your data?
As an example of the former: The patches of experiment space containing "measure the lifetime of the bottom quark" and "estimate the average length of 5 year old blue whales" are strongly disjoint and there is essentially no description reduction scheme that can handle such a broad range of inputs. Equivalently, "estimate the resistivity of the population of salt bridges I've experimented with" and "estimate the total data production of Earth in 2010" are questions drawn from experiments that are too different to have a unified data reduction description.
I've led programs to address this range of problems in several ways:
Don't bother with links. Like any other "two representations of the data" problems, it WILL go out of sync as soon as something is reorganized.
Data goes in the leaf folders. Subsequent processing, folding, spindling, mutilating, and hand-waving with statistics occurs in parent folders. This typically includes interim reports and similar information. This leads to a strong visual model of data being hoisted from lower directories to higher directories by means of the data analysis tools that are *in* those directories. (This pins the version of the analysis tool that was used, so that the analysis can be replicated together with whatever oddities in processing were in that version of the tools.)
For back-of-the-envelope experiments (preliminary support variable space surveys), we tend to store the data in single directories named for the category of experiment, distinct instrumental data streams are stored in folders by instrument name (yeah, yeah, I know, that sounds transverse, but it solves any number of "process all the spectrometer data the same way" sorts of problems because all the spectrometer data is together in one place instead of trying to solve a potentially intractable programmatic data format recognition problem) and files from one "run" are named identically. For small support spaces, the variables values are logged right in the file names. For medium experiments (typically too many variables to make workable filenames) a meta-data file is created. This file either has a rigorous layout of support variable information separated by known section boundaries, or uses a form of pidgin markup (required for, for example, optical filter stacks, where a not-previously-specified number of filters may be electrical taped in a stack) that's not really too complicated, only brackets unformatted strings, but makes automatic parsing of the metadata file feasible.
For medium sized experiments, with a specific ending condition (makes more sense in the context of items a couple of bullets down), the pidgin metadata file can be used, but it tends to transmogrify into a *real* (strict) markup language. I'm not pushing XML, but there are plenty of tools out there for automatically parsing XML. However, most of them are broken in that they require loading the *entire* XML file before they start parsing. Oddly, for large experiments (next item), the metadata can be oppressively large.
For large experiments, the strict markup metadata file tends to transmogrify into an (actual) relational database. It really doesn't matter which one you use, they are all equally inaccessible to your data analysis tools. You will find yourself writing an export or report routine that dumps the database into something like the strict markup metadata file just so your other tools can access it. This is especially true for large DoX runs, with data gathering occurring in parallel in multiple labs where management wants to see something
I use Synergy ( http://synergy2.sourceforge.net/ ) to share one keyboard and mouse among several computers' displays. This should allow you to share one keyboard and mouse among multiple X servers running on your machine (and provide the opportunity for future expansion). It can even be used to do nonintuitive things like placing the "screen" of a VM (visible in a window on one of your screens) on an edge of one of your physical screens. (I'm still not sure that was a good idea.)
Comments like this remind me that Fat32 is also useless for retaining owners, rights, and permissions from the Windows side as well. Maybe if MS could settle on a FS that was readable on more than one OS?...
If you know where this magic software is that knows almost every useful property of almost every known material, I and my employer would pay huge amounts of money for it. Because the reality is:
* Most materials haven't had any meaningful measurements made for any property that is actually interesting.
* Most measurements are crap. Many published measurements are crap. The amount of practice and control necessary to make useful measurements is outlandish.
* Published data for any but the most lavishly studied materials range wildly. What's the vapor pressure of, for example, RDX at STP. Checking the published sources, you'll find answers ranging over 6 orders of magnitude. So,..., where does "somewhere between 1 millisquat and 1 nanosquat" fall on this sorted list?
This idea that there's a giant database of materials properties that contains accurate and precise data for all technologically interesting properties of most materials is bunk.
And then,..., what's hair? Since when did hair become a specific material? Thick hair? Thin hair? Oily hair? Dry hair? Which property were you asking about? Is the hair split? Follicle attached? Old and dessicated? New and slightly less dessicated?
Yes, I think the claim made in the article is bunk. And I bet no one here can provide a single (real) citation to a source for the current-voltage relationship for hair.
I recommend C or C++ as a first Linux programming language, not for the reasons given above, but because there is a large ecosystem of tools to act on C/C++ source, object files, libraries, headers, and executables. There is nothing wrong with learning the *rest* of the GNU toolchain as well.
In addition and outside the scope of your question, develop a preference for two languages -- the "guts" implementation language and the "pretty" UI language. They *can* be the same language, but I haven't found that this is a workable situation. The tools that you've used on Windows make it possible to write UIs and nuts and bolts in the same language, but even there it's somewhat easier to write "big", "complicated", and/or "performance" code in VC++ and then paste up an UI in VB. I would strongly recommend developing this separation -- always having a text-only interface and additional interfaces that interact with the core through the command line and/or over a network socket. This is one of the few aha/gotcha issues that I was very happy to figure out and sad that no one mentioned it previously.
Finally, learn some "odd" languages: Lojban, Malbolge, Scheme, Erlang, Prolog, m4, INTERCAL, and so Forth, for many reasons, including becoming familiar with some of the other tools potentially in the toolchest.
I'd recommend that you start with
Sagan, Boundary and Eigenvalue Problems in Mathematical Physics. II.1 The Vibrating String (with derivation from principles). II.2 The Vibrating Membrane (with derivation). II.3 The Equation of Heat Conduction and the Potential Equation (with derivations).
I'd also include Crank, The Mathematics of Diffusion. You have to get all the way to eqn. 1.9 on p. 5 before starting to treat anisotropic media. This derives from and extends Carslaw and Jaeger, Conduction of Heat in Solids.
You will want to eventually read (but not during your class), Frankel, The Geometry of Physics. Bridging the gap between the the Exterior Calculus and what you will see in a PDE class is too much work. However, much like the algebra-based-physics student taking differential calculus realizing how many equations he could have *not* memorized if only he had known how to take a derivative, realizing how much second order differential physics follows directly from the properties of certain forms/bundles/et c. is very enlightening (although somewhat opaque at first).
Running my finger down my math/phys shelf (and skipping those that won't provide much physical basis for the setups):
Jackson, Classical Electrodynamics
White, Fluid Mechanics
Ozisik, Boundary Value Problems of Heat Conduction
Segel, Mathematics Applied to Continuum Mechanics
Shankar, Principles of Quantum Mechanics
Boon and Yip, Molecular Hydrodynamics
Hayes and Probstein, Hypersonic Inviscid Flow
and a seemingly endless supply of books by Greiner.
Misner, Wheeler, and Thorne, Gravitation is probably more index gymnastics than you want to try to absorb for PDE. But it's a fun read, is all about PDEs, and they more than completely ground their derivations in the physics.
You might also want to thumb through Brouwer, Studies In Logic And The Foundations Of Mathematics: The Axiomatic Method With Special Reference To Geometry And Physics, Part II.
I'm used to the terms:
"observable universe" -- everything in your past light cone.
"universe" -- your observable universe plus everything accessible to it through space-like paths. This is probably what most normal people should be taken to mean when they use this word.
"Universe" -- Everything. Really. Even that.
... and it will come as no surprise to other/. readers that I'm too lazy to check my references on this usage.
nVidia moved into chipsets in order to support their core business of graphics -- the busses had become bottlenecks. When Intel controls the busses and Intel only makes crap-tastic video, then the busses are only crap-tastic. Being able to vastly outperform Intel's video "offerings" required taking control of the busses and making them something that could actually do the job. This required going into the chipset business.
I use Mathematica for this problem. It cannot cover *all* the bases covered by {La}TeX, but it handles all of my technical document preparation needs (including equations, tables, et c.). Almost all charts/plots I generate directly (although sometimes in a separate notebook to separate implementation from result). Import of random graphics is also possible. In fact, there is TeX import/export, but since I have never used this feature I will not comment on its usefulness.
It's also kinda handy for some of that crazy computation stuff I do in preparation for document creation.
However, do not trust its PDF export. It does not embed relevant fonts in the PDF (thereby producing a potentially malformed document, depending on the font set on the recipient's/viewer's machine). Of course, I use PDFCreator for this purpose and just "print" it.
I'm a math (and physics/computer science/hardware/network administration/security, and therefore wildly defocused) geek who successfully throws parties for geeks. So clearly my experiences will be entirely incompatible for the group you're thinking of hosting.
Things that have worked:
* Memorial/Labor Day parties, at the lake, one or two weeks before or after Memorial/Labor Day. Everyone has an easy time getting to the lake/beach, the places aren't nearly so crowded, and there's a sense of (George Carlin, Iceboxman-esque), "feel[ing] really intelligent."
* Game night, as suggested above a few times, preferably with games that can be played by more than two or four people, and preferably ones that are not logical/deductive (e.g. Clue). Winners have been Settlers of Catan, Ticket to Ride, RoboRally (breaking the advice I just gave), Taboo, Quelf, Dilbert Corporate Shuffle (q.v. The Great Dalmutihttp://en.wikipedia.org/wiki/The_Great_Dalmuti and Presidenthttp://en.wikipedia.org/wiki/President_(game) ), Primordial Soup, Trivial Pursuit (various editions), and I'm sure there are others that aren't popping off the top of my head. Other less formal games are Botticellihttp://en.wikipedia.org/wiki/Botticelli_(game) and variants where instead of people, the subject matter is movies, bands, albums, television shows, and/or quotes from any of the above.
* Sports (shock!) although the difference between vaguely active games (like Quelf) and sedate sports can be a bit tricky -- typically a little quirky, like bowling, archery, curling, bocce, horseshoes, lawn bowls, croquet, lawn darts, et al.
* Movie night -- preferably on several screens in several rooms, with a mix of "good geeky movies" (e.g. Lord of the Rings, Sneakers, Flash Gordon) and "bad geeky movies" (e.g. The Lost Skeleton of Cadavra, Jesus Christ Vampire Hunter, Flash Gordon).
* Obscure alcohol night -- bring something odd you found or something you made. Expect to provide craploads of small (probably paper) cups for tasting.
* Coffee House Takeover -- if you have a large group, plan to take over a coffee house, and chat/game/whatever. For ideas with a smaller group, start here: http://improveverywhere.com/2003/03/22/the-moebius/
That's not an exhaustive list, and even the items are incomplete, but it's not a bad leaping off point to go in whatever direction you like.
The Prime 50 series used segment 07777, offset 0 for the null pointer, at least for PL/I. Later models used segment 0, offset 0 for null pointers in C, necessitating new instructions such as TCNP (Test C Null Pointer), evidently as a sop to all the extant poorly-written C code which made incorrect assumptions. Older, word-addressed Prime machines were also notorious for requiring larger byte pointers (char *'s) than word pointers (int *'s).
The Eclipse MV series from Data General has three architecturally supported pointer formats (word, byte, and bit pointers), two of which are used by C compilers: byte pointers for char * and void *, and word pointers for everything else.
Some Honeywell-Bull mainframes use the bit pattern 06000 for (internal) null pointers.
The CDC Cyber 180 Series has 48-bit pointers consisting of a ring, segment, and offset. Most users (in ring 11) have null pointers of 0xB00000000000.
The Symbolics Lisp Machine, a tagged architecture, does not even have conventional numeric pointers; it uses the pair (basically a nonexistent handle) as a C null pointer.
Depending on the "memory model" in use, 80*86 processors (PC's) may use 16 bit data pointers and 32 bit function pointers, or vice versa.
The old HP 3000 series computers use a different addressing scheme for byte addresses than for word addresses; void and char pointers therefore have a different representation than an int (structure, etc.) pointer to the same address would have.
So, yes, there are real machines whose implementation of the NULL pointer was not "all zeroes". And no, there has never been a C/C++ standards compliant compiler that didn't represent the null pointer with the syntax "NULL" or "0". Don't confuse the language specified syntax, "0", with the value generated to implement the semantics.
In fact, implementing "NULL"/"0" with zero would be incorrect. On most architectures, there can be a valid object at (real) memory address zero, e.g., an interrupt table, although many other examples exist. The compiler has to implement "NULL"/"0" with an address that absolutely cannot be the address of a valid object. This means that it has to be some address that the running code can actually control and so very likely is not the address zero.
Although it's common to imagine that a "0" in source means a zero in implementation, in this one instance the C/C++ standards are very clear that they need not *and* that the programmer has no need to know what the implementation form is.
Although "# define NULL 0" means replace source instances of "NULL" with source of "0", this doesn't mean what you think it means. The constant "0" used in a pointer context is syntax for the semantic "null pointer". It provides no insight into the representation of the null pointer. This is a common error because "null" and "NULL" are overloaded in the syntax, semantics, and description of C and C++. These words can mean:
A) The abstract language concept "the NULL pointer", defined to be a pointer that specifically points *no where*. It is language illegal for there to be an object at the target in this use of "the NULL pointer".
B) The internal or run-time representation of "the NULL pointer", which may or may not be zero when interpreted as the bit pattern of an integer, and which may be different for different pointer types. This representation is implementation defined and shouldn't be visible to programmers because they use...
C) The language syntax for "the NULL pointer" which is "0" used in any pointer context -- initialization, assignment, comparison, or argument in a prototyped not-varargs-ed function call -- except for un-prototyped function calls and varargs arguments, where "0" or should be cast to the correct type.
D) The NULL macro, which you mention, which only works because the language is already performing the translation magic on the source "0".
E) And other unrelated uses as (1) "the null character", ASCII NUL, whose magic syntax is '\0'; and (2) "the null string", "\0" (as a sequence of ASCII values), whose magic syntax is "".
The fundamental *failure* of representing the NULL pointer with a value whose integer interpretation is zero is that you can't point at physical address zero with a non-NULL pointer. So, a v86 pointer to the interrupt table (starting at physical address zero) is a NULL pointer on any compiler that represents NULL as an all-zeroes address.
Sane *implementations* pick some valid address in the subsequent object code to be the implementation address of the NULL pointer. Then comparisons are to an address that can actually be guaranteed to not be the address of an object. This breaks passing NULLs between separately bound object modules (binding is typically rolled into the last stage of linking-to-an-executable in current PC compilers) unless NULL will live in a common library (in which case it can live in the binding library). Passing NULLs between processes is entirely outside the scope of the C/C++ standards and therefore any guarantees have to be made by whatever mechanism marshalls/unmarshalls values for inter-process calls. (This can be done by having a special encoding for a pointer that compares NULL in this process, that is unwrapped to the NULL representation in that process.)... and I've wandered a bit off-topic.
In any event, you've over-assumed what "0" means in the code you cite.
Nope. No ambiguity is introduced. The "or any later version" clause allows subsequent distributors to bump the version of the license that they subsequently distribute under. For instance, source contributed to the Samba project under "v2 or later" can be distributed *in* Samba under "v3", "v4", "v3 or later", or other similarly phrased terms.
FAT32 does not have a 4 GB filesize limit. This is a common misconception. The filesystem allows the whole disk to be linked into a single file, giving a filesize limit of a bit under 8 TB (gotta have room for the FAT(s)). Whether or not your application produces or driver accepts > 4 GB offsets into a file is a different problem entirely. If you could replace your FAT32 driver, the redirector chain attached to it, and your compiler's stdio lib, then you could recompile your apps and this "limit" would evaporate. (This was relatively easy to do in Linux, under the name "Large File Support" around the time of the 2.2 to 2.4 kernel jump.)
MAC addresses aren't guaranteed to be unique. MAC addresses are only guaranteed to be unique on a given PHY. So a 802.2 and an 802.11 interface could have the same MAC. (... and this doesn't break anything since those two interfaces can't see each otehr.)
So,..., where's the follow-up paper estimating the temperatures of the baryonic and non-baryonic components as they "relax" out into the shallower gravitational wells left after being separated?
Zeroeth, this is definitional. Dark matter is defined as all the matter that we don't see photons reflecting off of nor do we see producing photons. Photons do not reflect other photons nor do they produce photons (except possibly at absurdly high energies or if QED is ridculously more nonlinear than all available data would suggest). So photons are dark matter. So are neutrinos and almost all other particles that mediate forces. Almost all "non-dark matter" is atoms/ions and free electrons.
Second, there's about one baryon per 5 cubic meters in the universe and the ratio of photons to baryons is about 10^10. The 3 K background radiation has a peak wavelength of ~1 mm, so an energy of 1.2 meV. The energy equivalence (E=mc^2) of a baryon is ~1 MeV, about 10^9 times as great as that of the photon. So the the 10^10 photons have about 10-times as much mass equivalence as do the baryons in the Universe. However, photons are "hot particles", moving at the speed of light. Hot particles move too fast to be trapped in pedestrian gravitational wells, like those of stars and galaxies. So, where we expect to find that baryons are clumped together with densities several orders of magnitude higher in galaxies and stars, the photons should be evenly distributed. Thus, the huge photon mass provides a uniform, flat background that cannot explain anomalous galactic rotation data. Similarly, there are no good stories about other massless or light particles (like neutrinos) providing the additional mass to make galactic rotation curves work.
The parent and sibling (both to this reply) address one of the more difficult aspects: context, access, validity, integration, and cross-linking. Perhaps of more interest is some of the *invisible* (meta-) information in these e-Mails.
Say, for instance a PDF is attached to a message. That PDF contains a document with redacted information. That information can be retrieved by cutting and pasting the document. What do you store in the archive? The redacted text? the unredacted text? both? Clearly, "direct conversion" posters completely miss this issue. But those more technically competent who recognize that "dump in standard formats" is a non-solution may not be thinking along these lines either.
Sadly, the only reliable way to capture all of the data and metadata that may reside in these e-Mails and in attachments is in the original format and with original document readers. I.e., you can't just store the nouns, you must also store the verbs. Converting formats quite evidently risk destruction of information and must only be undertaken with extreme care. Even careful format conversion risks loss of information (edit sequences ("Where was that sentence when the speech was first drafted and how did it move around during drafting?"), editors ("Who deleted that paragraph?"), deleted text ("What's in the other 80% of this DOC file?"), et al.). While admittedly, not all documents store all this information, those that do and which were released as official government documents containing that information, are a deeply insightful glimpse into an Administration and into the processes of that Administration -- precisely the insight to be engendered by this collection of documents.
Interestingly, this suggests that it is important that the Office of the President and any member of the government who may provide documents which appear in the Archives use file formats that may readily be archived. Perhaps these are ODFs and perhaps not.
Perhaps more interesting is how contextual information will be collected. Can you universally convert "From:" addresses into real people's names? You can probably get most with some work, but all? Assuming 1% of e-Mails have a new address on them, this requires tracking down 1M addresses. (Perhaps we can skip the "home loan" and "Viagra" et c. new addresses, reducing the number to a few thousand, but that's still an exorbitant amount of manual effort just to put the "From:" fields in context. Now let's move onto the "CC:" field...)
MACs are only unique per physical layer. I first had problems with this when I found we had both a Token-Ring device and an Ethernet device with the same MACs. The utter confusion entailed for one of our applications (that identified users by MAC) was replicated recently when we found an 802.11 card that duplicated one of our wired Ethernet MACs. Fortunately, I'd seen this problem before.
Perhaps more worrisome than IP address space depletion is MAC address space leakage. The first half (24 bits) are fixed by the manufacturer (at least a batch ID and perhaps a couple of context sensitive capability bits) and the second half (24 bits) are constrained by an obsure parity requirement.
MAC depletion is at least as imminent as IPv4 depletion...
Have you looked at Zimbra http://www.zimbra.com/. It seems to aim to be an Outlook/Exchange replacement, is implemented "in" AJAX, and is open source. So the (/.-ish) geek factor should be biggish.
Slashdot Mirror
Actually, it's unknown whether integer factorization (into primes) is an NP problem. Although a P-time solution to an NP-complete problem class (e.g. 3-SAT) would result in a P-time solution to integer factorization, the converse (polynomial time factorization implying P=NP) isn't known to hold. (And seems unlikely to be the case given the number of complexity classes that would collapse together. (ibid.))
For a long time, it was believed that even just testing an integer for primality might require super-polynomial (equiv. sub-exponential) time, which would have made the problem of just testing a candidate factor for primality not lie in P-time. But Agrawal et al. produced a P-time primality test algorithm in 2002. This result made it less clear that integer factorization into primes was necessarily not P-time. (If it were provable that testing for primality was impossible in P-time then integer factoring is not in P-time, because otherwise an integer could be tested for primality by trying to factor it and this would either return "is prime" (i.e. the trivial factorization n = 1*n) or would return "is composite" (i.e. the nontrivial factorization n = p*q) in polynomial time.) So a P-time primality test made it less clear which time complexity class integer factorization (into primes) lived in.
In spite of this nit-picking, your basic idea is right. :-)
As an example of the former: The patches of experiment space containing "measure the lifetime of the bottom quark" and "estimate the average length of 5 year old blue whales" are strongly disjoint and there is essentially no description reduction scheme that can handle such a broad range of inputs. Equivalently, "estimate the resistivity of the population of salt bridges I've experimented with" and "estimate the total data production of Earth in 2010" are questions drawn from experiments that are too different to have a unified data reduction description. I've led programs to address this range of problems in several ways:
I use Synergy ( http://synergy2.sourceforge.net/ ) to share one keyboard and mouse among several computers' displays. This should allow you to share one keyboard and mouse among multiple X servers running on your machine (and provide the opportunity for future expansion). It can even be used to do nonintuitive things like placing the "screen" of a VM (visible in a window on one of your screens) on an edge of one of your physical screens. (I'm still not sure that was a good idea.)
FAT32 has no such limit. Broken formatting tools in XP and subsequent Windowss do.
Comments like this remind me that Fat32 is also useless for retaining owners, rights, and permissions from the Windows side as well. Maybe if MS could settle on a FS that was readable on more than one OS?...
* Most materials haven't had any meaningful measurements made for any property that is actually interesting.
* Most measurements are crap. Many published measurements are crap. The amount of practice and control necessary to make useful measurements is outlandish.
* Published data for any but the most lavishly studied materials range wildly. What's the vapor pressure of, for example, RDX at STP. Checking the published sources, you'll find answers ranging over 6 orders of magnitude. So, ..., where does "somewhere between 1 millisquat and 1 nanosquat" fall on this sorted list?
This idea that there's a giant database of materials properties that contains accurate and precise data for all technologically interesting properties of most materials is bunk.
And then, ..., what's hair? Since when did hair become a specific material? Thick hair? Thin hair? Oily hair? Dry hair? Which property were you asking about? Is the hair split? Follicle attached? Old and dessicated? New and slightly less dessicated?
Yes, I think the claim made in the article is bunk. And I bet no one here can provide a single (real) citation to a source for the current-voltage relationship for hair.
In addition and outside the scope of your question, develop a preference for two languages -- the "guts" implementation language and the "pretty" UI language. They *can* be the same language, but I haven't found that this is a workable situation. The tools that you've used on Windows make it possible to write UIs and nuts and bolts in the same language, but even there it's somewhat easier to write "big", "complicated", and/or "performance" code in VC++ and then paste up an UI in VB. I would strongly recommend developing this separation -- always having a text-only interface and additional interfaces that interact with the core through the command line and/or over a network socket. This is one of the few aha/gotcha issues that I was very happy to figure out and sad that no one mentioned it previously.
Finally, learn some "odd" languages: Lojban, Malbolge, Scheme, Erlang, Prolog, m4, INTERCAL, and so Forth, for many reasons, including becoming familiar with some of the other tools potentially in the toolchest.
I'd recommend that you start with Sagan, Boundary and Eigenvalue Problems in Mathematical Physics. II.1 The Vibrating String (with derivation from principles). II.2 The Vibrating Membrane (with derivation). II.3 The Equation of Heat Conduction and the Potential Equation (with derivations).
I'd also include Crank, The Mathematics of Diffusion. You have to get all the way to eqn. 1.9 on p. 5 before starting to treat anisotropic media. This derives from and extends Carslaw and Jaeger, Conduction of Heat in Solids.
You will want to eventually read (but not during your class), Frankel, The Geometry of Physics. Bridging the gap between the the Exterior Calculus and what you will see in a PDE class is too much work. However, much like the algebra-based-physics student taking differential calculus realizing how many equations he could have *not* memorized if only he had known how to take a derivative, realizing how much second order differential physics follows directly from the properties of certain forms/bundles/et c. is very enlightening (although somewhat opaque at first).
Running my finger down my math/phys shelf (and skipping those that won't provide much physical basis for the setups):
Jackson, Classical Electrodynamics
White, Fluid Mechanics
Ozisik, Boundary Value Problems of Heat Conduction
Segel, Mathematics Applied to Continuum Mechanics
Shankar, Principles of Quantum Mechanics
Boon and Yip, Molecular Hydrodynamics
Hayes and Probstein, Hypersonic Inviscid Flow
and a seemingly endless supply of books by Greiner.
Misner, Wheeler, and Thorne, Gravitation is probably more index gymnastics than you want to try to absorb for PDE. But it's a fun read, is all about PDEs, and they more than completely ground their derivations in the physics.
You might also want to thumb through Brouwer, Studies In Logic And The Foundations Of Mathematics: The Axiomatic Method With Special Reference To Geometry And Physics, Part II.
I'm used to the terms: /. readers that I'm too lazy to check my references on this usage.
"observable universe" -- everything in your past light cone.
"universe" -- your observable universe plus everything accessible to it through space-like paths. This is probably what most normal people should be taken to mean when they use this word.
"Universe" -- Everything. Really. Even that.
... and it will come as no surprise to other
nVidia moved into chipsets in order to support their core business of graphics -- the busses had become bottlenecks. When Intel controls the busses and Intel only makes crap-tastic video, then the busses are only crap-tastic. Being able to vastly outperform Intel's video "offerings" required taking control of the busses and making them something that could actually do the job. This required going into the chipset business.
There really was no alternative.
I use Mathematica for this problem. It cannot cover *all* the bases covered by {La}TeX, but it handles all of my technical document preparation needs (including equations, tables, et c.). Almost all charts/plots I generate directly (although sometimes in a separate notebook to separate implementation from result). Import of random graphics is also possible. In fact, there is TeX import/export, but since I have never used this feature I will not comment on its usefulness.
It's also kinda handy for some of that crazy computation stuff I do in preparation for document creation.
However, do not trust its PDF export. It does not embed relevant fonts in the PDF (thereby producing a potentially malformed document, depending on the font set on the recipient's/viewer's machine). Of course, I use PDFCreator for this purpose and just "print" it.
This sounds like a job for Core Wars! http://en.wikipedia.org/wiki/Core_War
Things that have worked:
That's not an exhaustive list, and even the items are incomplete, but it's not a bad leaping off point to go in whatever direction you like.
/etc/hosts
c:\windows\system32\drivers\etc\hosts
(your system's location may vary)
66.35.250.150 www.hotbabes.com
(directs to /. )
So, yes, there are real machines whose implementation of the NULL pointer was not "all zeroes". And no, there has never been a C/C++ standards compliant compiler that didn't represent the null pointer with the syntax "NULL" or "0". Don't confuse the language specified syntax, "0", with the value generated to implement the semantics.
In fact, implementing "NULL"/"0" with zero would be incorrect. On most architectures, there can be a valid object at (real) memory address zero, e.g., an interrupt table, although many other examples exist. The compiler has to implement "NULL"/"0" with an address that absolutely cannot be the address of a valid object. This means that it has to be some address that the running code can actually control and so very likely is not the address zero.
Although it's common to imagine that a "0" in source means a zero in implementation, in this one instance the C/C++ standards are very clear that they need not *and* that the programmer has no need to know what the implementation form is.
Although "# define NULL 0" means replace source instances of "NULL" with source of "0", this doesn't mean what you think it means. The constant "0" used in a pointer context is syntax for the semantic "null pointer". It provides no insight into the representation of the null pointer. This is a common error because "null" and "NULL" are overloaded in the syntax, semantics, and description of C and C++. These words can mean:
... and I've wandered a bit off-topic.
A) The abstract language concept "the NULL pointer", defined to be a pointer that specifically points *no where*. It is language illegal for there to be an object at the target in this use of "the NULL pointer".
B) The internal or run-time representation of "the NULL pointer", which may or may not be zero when interpreted as the bit pattern of an integer, and which may be different for different pointer types. This representation is implementation defined and shouldn't be visible to programmers because they use...
C) The language syntax for "the NULL pointer" which is "0" used in any pointer context -- initialization, assignment, comparison, or argument in a prototyped not-varargs-ed function call -- except for un-prototyped function calls and varargs arguments, where "0" or should be cast to the correct type.
D) The NULL macro, which you mention, which only works because the language is already performing the translation magic on the source "0".
E) And other unrelated uses as (1) "the null character", ASCII NUL, whose magic syntax is '\0'; and (2) "the null string", "\0" (as a sequence of ASCII values), whose magic syntax is "".
The fundamental *failure* of representing the NULL pointer with a value whose integer interpretation is zero is that you can't point at physical address zero with a non-NULL pointer. So, a v86 pointer to the interrupt table (starting at physical address zero) is a NULL pointer on any compiler that represents NULL as an all-zeroes address.
Sane *implementations* pick some valid address in the subsequent object code to be the implementation address of the NULL pointer. Then comparisons are to an address that can actually be guaranteed to not be the address of an object. This breaks passing NULLs between separately bound object modules (binding is typically rolled into the last stage of linking-to-an-executable in current PC compilers) unless NULL will live in a common library (in which case it can live in the binding library). Passing NULLs between processes is entirely outside the scope of the C/C++ standards and therefore any guarantees have to be made by whatever mechanism marshalls/unmarshalls values for inter-process calls. (This can be done by having a special encoding for a pointer that compares NULL in this process, that is unwrapped to the NULL representation in that process.)
In any event, you've over-assumed what "0" means in the code you cite.
Nope. No ambiguity is introduced. The "or any later version" clause allows subsequent distributors to bump the version of the license that they subsequently distribute under. For instance, source contributed to the Samba project under "v2 or later" can be distributed *in* Samba under "v3", "v4", "v3 or later", or other similarly phrased terms.
FAT32 does not have a 4 GB filesize limit. This is a common misconception. The filesystem allows the whole disk to be linked into a single file, giving a filesize limit of a bit under 8 TB (gotta have room for the FAT(s)). Whether or not your application produces or driver accepts > 4 GB offsets into a file is a different problem entirely. If you could replace your FAT32 driver, the redirector chain attached to it, and your compiler's stdio lib, then you could recompile your apps and this "limit" would evaporate. (This was relatively easy to do in Linux, under the name "Large File Support" around the time of the 2.2 to 2.4 kernel jump.)
MAC addresses aren't guaranteed to be unique. MAC addresses are only guaranteed to be unique on a given PHY. So a 802.2 and an 802.11 interface could have the same MAC. (... and this doesn't break anything since those two interfaces can't see each otehr.)
So, ..., where's the follow-up paper estimating the temperatures of the baryonic and non-baryonic components as they "relax" out into the shallower gravitational wells left after being separated?
Zeroeth, this is definitional. Dark matter is defined as all the matter that we don't see photons reflecting off of nor do we see producing photons. Photons do not reflect other photons nor do they produce photons (except possibly at absurdly high energies or if QED is ridculously more nonlinear than all available data would suggest). So photons are dark matter. So are neutrinos and almost all other particles that mediate forces. Almost all "non-dark matter" is atoms/ions and free electrons.
First, I'd recommend reading the Dark Matter article http://en.wikipedia.org/wiki/Missing_mass.
Second, there's about one baryon per 5 cubic meters in the universe and the ratio of photons to baryons is about 10^10. The 3 K background radiation has a peak wavelength of ~1 mm, so an energy of 1.2 meV. The energy equivalence (E=mc^2) of a baryon is ~1 MeV, about 10^9 times as great as that of the photon. So the the 10^10 photons have about 10-times as much mass equivalence as do the baryons in the Universe. However, photons are "hot particles", moving at the speed of light. Hot particles move too fast to be trapped in pedestrian gravitational wells, like those of stars and galaxies. So, where we expect to find that baryons are clumped together with densities several orders of magnitude higher in galaxies and stars, the photons should be evenly distributed. Thus, the huge photon mass provides a uniform, flat background that cannot explain anomalous galactic rotation data. Similarly, there are no good stories about other massless or light particles (like neutrinos) providing the additional mass to make galactic rotation curves work.
The parent and sibling (both to this reply) address one of the more difficult aspects: context, access, validity, integration, and cross-linking. Perhaps of more interest is some of the *invisible* (meta-) information in these e-Mails.
Say, for instance a PDF is attached to a message. That PDF contains a document with redacted information. That information can be retrieved by cutting and pasting the document. What do you store in the archive? The redacted text? the unredacted text? both? Clearly, "direct conversion" posters completely miss this issue. But those more technically competent who recognize that "dump in standard formats" is a non-solution may not be thinking along these lines either.
Sadly, the only reliable way to capture all of the data and metadata that may reside in these e-Mails and in attachments is in the original format and with original document readers. I.e., you can't just store the nouns, you must also store the verbs. Converting formats quite evidently risk destruction of information and must only be undertaken with extreme care. Even careful format conversion risks loss of information (edit sequences ("Where was that sentence when the speech was first drafted and how did it move around during drafting?"), editors ("Who deleted that paragraph?"), deleted text ("What's in the other 80% of this DOC file?"), et al.). While admittedly, not all documents store all this information, those that do and which were released as official government documents containing that information, are a deeply insightful glimpse into an Administration and into the processes of that Administration -- precisely the insight to be engendered by this collection of documents.
Interestingly, this suggests that it is important that the Office of the President and any member of the government who may provide documents which appear in the Archives use file formats that may readily be archived. Perhaps these are ODFs and perhaps not.
Perhaps more interesting is how contextual information will be collected. Can you universally convert "From:" addresses into real people's names? You can probably get most with some work, but all? Assuming 1% of e-Mails have a new address on them, this requires tracking down 1M addresses. (Perhaps we can skip the "home loan" and "Viagra" et c. new addresses, reducing the number to a few thousand, but that's still an exorbitant amount of manual effort just to put the "From:" fields in context. Now let's move onto the "CC:" field...)
MACs are only unique per physical layer. I first had problems with this when I found we had both a Token-Ring device and an Ethernet device with the same MACs. The utter confusion entailed for one of our applications (that identified users by MAC) was replicated recently when we found an 802.11 card that duplicated one of our wired Ethernet MACs. Fortunately, I'd seen this problem before.
Perhaps more worrisome than IP address space depletion is MAC address space leakage. The first half (24 bits) are fixed by the manufacturer (at least a batch ID and perhaps a couple of context sensitive capability bits) and the second half (24 bits) are constrained by an obsure parity requirement.
MAC depletion is at least as imminent as IPv4 depletion...
Have you looked at Zimbra http://www.zimbra.com/. It seems to aim to be an Outlook/Exchange replacement, is implemented "in" AJAX, and is open source. So the (/.-ish) geek factor should be biggish.
Yeah? Where's Outlook for Mac?
Umm... Somewhere else, not infecting everyone in your addressbook with the latest script-kiddie virus?