The.so name of a shared library under Linux encodes not only whether the library has been revised, but also indicates ABI compatibility.
If the library authors know what they are doing, when they release a new version of a library they will set the.so version number (different from the human-targeted source-code version number) to reflect which previous versions of the library the new release is compatible with. As a result, ABI-compatible software does not need to be recompiled.
LyX has built-in templates for RevTeX, so it works well with most physics journals. I occasionally run into a journal that uses a custom non-RevTeX stylesheet not supported by LyX, but it's always possible to get it to work with LyX. The easiest thing is to just format it for the journal at the very end, right before submission, by exporting LyX to LaTeX and then switching it over to the new style file (and any minor changes that requires). (It's also not too hard to write a new LyX template to use a new stylesheet if you want to do everything in LyX.)
I was talking about the MIT group (who explicitly discuss the differences between what they are doing and what Tesla considered), not the group in the article here. And you're right that Tesla also looked at non-radiative schemes for very short distances, e.g. Tesla coils, but at the time of Tesla most of the interest was in long-range power delivery (which never worked out because of the problems with radiative transfer, and in any case such schemes were supplanted by the wired electrical grid).
Tesla coils involve large electric fields between the source and receiver device, and so (a) are quite different from the magnetically-coupled resonators the MIT group proposes and (b) are impractical for the short-distance power-delivery applications considered here because they can dissipate too much energy into the environment.
The MIT group is not proposing to use omnidirectional (or directional) radiative energy transfer, which indeed would radiate most of the energy into the environment, and only a small fraction into the receiver, and even that could be eliminated if something (e.g. a person) walks between the source and receiver.
They are proposing non-radiative resonant energy transfer, in which both the source and receiver are resonant oscillators at a particular frequency coupled via the near field (non radiatively), and hence preferentially transfer energy compared to anything else that is not resonant (with a long lifetime) at the same frequency. Furthermore, they are using resonators that only couple through their magnetic fields (the electric fields are largely within capacitors inside the device), which further reduces absorption of energy by the environment (because most materials are non-magnetic, energy dissipation is largely via ohmic heating, i.e. by the electric fields). Because of this, almost all of the losses take the form of resistive heating in the devices themselves; only a miniscule fraction is dissipated in the surrounding environment (e.g. a person).
Of course, this being Slashdot, it's not surprising that most posters never RTFAed and post nonsense "it's just like an inductive transformer" (nope, those don't use resonance) or "it's just like an antenna" (nope, that is radiative transfer) or "Tesla looked at this a century ago" (nope, people like Tesla were concerned with power transfer over long distances, which necessitates radiative mechanisms and hence low efficiency).
They lost my vote when Obama voted for immunity for Telco's.
Um, Obama actually voted against immunity for telcos regarding the wiretap issue. (See e.g. this news article) McCain, on the other hand, voted for immunity.
But don't let facts get in the way of your voting decisions.
Um from what I can see, Scilab has been providing open software since 1994. That would be 4 years before OSI even existed. So who is flouting who? Not to mention that the term "open" has been in use for decades to describe just about anything in the technical domain...
According to the Internet Archive, Scilab only began calling their software "open source" in 2004, well after the "open source" term had been popularized for software by OSI with a specific meaning that people trusted (cluetrain: the older uses of the term "open source" were primarily for non-software). It sure looks like they were trying to exploit this popularity, even though the result ends up being deceptive because they don't grant the same freedoms that people have come to expect from "open source" code.
The Scilab example points out a huge problem with the OSI's personal definition of "open source", BTW. The point of Scilab is to provide a shared standardized environment for collaborating applications. If they allow anyone to modify the code willy-nilly, there is no standardized environment and the sharing can't happen. This is a case where the developers need to retain control for the good of the user community and the OSI model doesn't allow for that.
Sorry, but this old myth about FLOSS software being vulnerable to forking of incompatible versions has been debunked over and over again. (Think about it for a moment: if this were really a "huge problem", the same thing would have popped up for Python, Perl, PHP, and every other standardized language popularized by free software.) As long as the original author maintains the software and keeps it free/open-source, any incompatible forks will be ignored.
I have been on the board of the OSI for more than 5 years, and until last year it was fairly easy for us to police the term open source: once every 2-3 months we'd receive notice that some company or another was advertising that their software was "open source" when the license was not approved by the OSI board and, upon inspection, was clearly not open source. [...] Most of the time they would say "Oops! Thanks for letting us know--we'll promote our software in some other way." And they did, until last year.
But what about Scilab, which on its home page prominently claims to be The open source platform for numerical computation (and has been doing so for years)? Scilab clearly does not qualify for the (widely agreed-upon) OSI definition of "open source", because the license prohibits commercial redistribution of modified versions. And yet I've never heard of an OSI campaign to pressure Scilab to either change its license or stop calling itself "open source". As a result, there are manyexamplesofpeoplewhohaveconfused Scilab's license with the usual definition of "open source".
I release things under licenses that fail arbitrary clauses in their definition by being too liberal - I don't make several of the asinine restrictions their supposed "definition" requires me to make, such as the GPL source redistribution clause.
Um, sorry, but you obviously haven't read (or at least, haven't comprehended) the definition. Neither the OSI definition of "open source" (or, for that matter, the FSF definition of "free software") requires you to make any restrictions in your license, much less GPL-like restrictions. The definitions only prohibit license restrictions more than a certain amount, but say nothing about less restrictions.
I hope the fact that you have obviously built a passionate position on top of ignorance and falsehood causes you to go back and re-think some of your opinions.
First, Britannica is also a tertiary source, just like Wikipedia aims to be; just because they employ experts doesn't mean that they publish any new results or interpretations. (Don't confuse a summary, which simply repeats known information in a condensed form, with a novel synthesis, which combines information in order to draw new conclusions and reveal new relationships. Tertiary sources like Wikipedia and Britannica do the former but not the latter.)
Second, regardless of how Wikipedia is perceived by people who don't understand its policies, as long as Wikipedia does not permit editors to publish novel theories, analyses, interpretations, information, etcetera, then there will be a market for reputable sources that do provide original research. If I'm a scientist and I want to publish a research paper, then I have to go to a scientific journal, regardless of how good Wikipedia's reputation (currently nowhere near that of professional journals, with good reason) becomes. If I'm a reader and I want up-to-date, original reporting of the news, I have to go to a newspaper or other media outlet, because I won't find that information in Wikipedia (except as an abbreviated summary, after the fact). In fact, I would argue that Wikipedia helps to drive more traffic towards quality sources, because it provides links and references (at least, this is the policy), which readers must follow in order to find more in-depth information than the general overview found in an encyclopedia (however specialized or comprehensive). I often find Wikipedia articles more useful than Google searches, precisely because their links are the result of a human being scouring the Web for the most useful sources.
Wikipedia has never claimed, or aimed, to be a replacement for newspapers, scientific journals, textbooks, and so on, and there is no danger of its doing so, much less "logical inconsistency".
One of the biggest logical problems I've found with the wikipedia is the inconsistent way that the movement treats traditional scholarship. On one hand, we're supposed to revel in the way that the wikipedia is often better than traditional mechanisms, but on the other hand the wikipedia gives more weight to outside sources. [...] If the wikis become good enough to rival if not replace original sources, where will the wikis find the outside beacons of authority? Any strict logician will realize that there's a danger of proving 1=0 with this system [...].
Any strict logician will realize that the English language is imprecise enough that it is easy to make fallacious claims of "logic" or "paradox" based on naive parsing and superficial interpretation.
In this case, there is no inconsistency. Wikipedia aims to become a premier tertiary source (i.e., merely summarizing established knowledge), fulfilling the role of both traditional and specialized encyclopedias. It does not seek to replace primary and secondary sources (those which provide new information and interpretation). In fact, any attempt to do so in Wikipedia will be deleted because it is against their official policy. So, even if it succeeds in eliminating all competing tertiary sources (which seems unlikely), there is no reason why Wikipedia should lack reliable primary and secondary sources to cite and summarize.
It is precisely this distinction that the reviewer fails to grasp in his complaint about deletion of (unspecified) "good information" on the grounds of non-notability. Because Wikipedia is not a primary or secondary source, it is not the appropriate place for "knowledge" that appears almost nowhere else, or cannot be found in any independent, reputable, published source—this is precisely what is meant by "non-notability" in Wikipedia.
VC++ is not worth its salt, especially for numerical work. (Not too surprising, as Microsoft is the same entity that decreed Windows wouldn't set the x86 FPU in extended -precision mode.) And the other languages you cited are not C/C++. It's no problem to find a C/C++ compiler for x86 that compiles long double to extended precision on x86.
Not really. Take a look at the performance, addressing modes, and so on. The support for 80-bit on Intel boxes is not the same as the support for 64-bit, at least in practical terms.
I can compile a single x86 code that uses extended precision and works on all x86 CPUs in recent memory. Of course, the speed varies, but you are stretching to argue that the extended precision isn't widely supported.
it doesn't mean you have to use its entire toolbox in every application you develop
Lots of people have made the same argument about C++. The problem is that every programmer uses a different subset of the language, so you end up having to deal with the whole mess in a program of any real size.
It's a bad sign if you have a language that is so large, you have to start imposing artificial constraints like intentionally subsetting the language or following "design patterns" in order to manage the complexity.
Long double floating point (80bit) —
This is just desperation. Pretty much no-one uses 80-bit floating point arithmetic IME (and yes, I do work in the field). The portability hazards and lack of true support from almost every mainstream architecture make them almost irrelevant, except perhaps for a few very small niches.
Um, considering that the vast majority of the world's floating-point hardware is x86 and supports extended precision, saying that it lacks "true support from almost every mainstream architecture" is comical.
(I agree that relatively few numerical applications need extended precision on a regular basis, but it is awfully useful on occasion. A very simple use is to assess the impact of roundoff error on a double-precision program: by far the easiest way is to increase the precision and see how much the answer changes, but this requires a floating-point type with greater than double precision. Yes, you could drop in an arbitrary-precision type, but this may be too slow in a large computation.)
In any case, D's claim to this feature is a bit odd, since every x86 C/C++ compiler worth its salt already compiles long double to extended precision.
...is obviously the birthplace of D. Heavens, it's the union of C++ (already a nightmarishly huge language), C99, and C#, along with dozens of other features halfway borrowed from functional languages and other inspirations. More features must be better, never mind that the language becomes insanely complicated! (Next they'll be throwing in the Fortran 2000 standard.)
My feeling is that languages shouldn't try to satisfy all possible needs. Rather, we should have small and clean languages, use the right tool for each job, and combine code libraries from different languages when needed. (I regularly use 3-6 languages in a single project and my life is much happier for it.)
(Legacy support is critically important too, but it is vastly better to provide legacy support by providing ways to call older languages, especially the lingua franca of C, rather than demanding that the new language be a superset of the old. I still call numerical libraries written in pre-1970 Fortran, but that doesn't mean I have to write my code in a Fortran derivative.)
Sorry, I missed your comment about the absolute error. The L2 norm of the data for an unnormalized DFT scales like sqrt(N), not like N, so your N log N is still not correct. In any case, the absolute error is totally meaningless: if you multiply all of the data points by 16, the error doesn't get worse by 16 (in floating-point, anyway)
The error analysis was published by Gentleman and Sande; the reference can be found on the link I gave previously (click on the "commentary" link).
Although it is not plotted, the same page has links to the complete datasets which include L-infinity errors. For example, on a POWER5 with gcc and FFTW 3.1 in single precision, the L-inf relative forward error for size 16 is 6.68e-8, whereas for size 262144=2^18 it is 3.6e-7. This is an increase by a factor of 5.4, which is close enough to the prediction of 4.5 from the O(log N) error bound.
Perhaps you have something wrong with your code. For example, if you use an trigonometric recurrence, your error will likely have worse scaling (depending on which recurrence you use), as explained in the commentary page mentioned above.
The Cooley-Tukey FFT algorithm and its variants, which is what they are using, has much better error characteristics than you think.
In floating-point arithmetic, the algorithm was proved in 1966 to have an upper bound for the error that grows only as O(log N), and the mean (rms) error grows only as O(log N). (See this page for more info.) (Errors in fixed-point arithmetic are worse, going as N.)
Even in single precision, the errors for their FFT sizes are probably quite reasonable, assuming they haven't done something silly like use an unstable trigonometric recurrence.
Be under a BSD-ish license, so it could be linked in to commercial and non-commercial products. Be a LIBRARY, not a stand-alone executable, so it can be linked into anything at all.
Or it could be that most people don't really understand the need for encryption, are hopelessly confused by key management, and won't use it until it is bundled with their computer and employed by default in their email program.
I'm not claiming it's impossible to make a rational argument opposing the FSF's views. It's quite possible for reasonable people to disagree about these things, and I'd be happy to see people do so; rational discussion is a healthy thing. (But I'm not interested in arguing the matter myself in this forum, so don't try to drag me into a GNU/Linux debate, please.)
My main point is that some of the best examples of reasoned argument are to be found in the FSF's essays, and often not in the writings of those who accuse them of zealotry and irrationality.
How about this. The one thing guaranteed to be common about all Linux distributions is the kernel...
Nice try, but this in in their FAQ (although "Frequently Made Arguments" would be a better name). You are free to disagree, but you have to respond to their counter-arguments or things will just go in a circle.
Secondly, things are named by the people who drive their development.
This isn't an argument, this is a statement of fact. The FSF doesn't dispute that people do, in fact, call the system Linux, and they even support people's free-speech right to call it whatever they choose (this is a FAQ, too). Their argument is over what the system should be called.
From what I know, the FSF didn't lead development of operating systems based on the Linux kernel.
The whole purpose of the GNU project, starting in 1984, was to develop a free operating system. It's hard to say that they didn't "lead" the development when they were the people to start it. This in, in fact, the FSF's main argument, which you have still failed to address. (They also respond specifically to suggestions that the GNU name only be used for those components they particularly developed.)
I don't really want to have to argue the side of the FSF here; I'm not their spokesperson, and my views are not identical theirs. I just find it frustrating to watch people argue in circles about this all of the time because they don't respond to counter-arguments. Still, your post is much better than the vast majority on the topic.
The sad thing is that most people on here who criticize RMS for being irrational are demonstrably far more so than he. For example, name-calling (e.g. "zealot," "ranting") is an ad hominem attack. Putting words in someone's mouth is little better. (I've never read a single criticism of the FSF's position on "GNU/Linux" that responds to their actual arguments on the issue. Usually, people create strawmen and/or make arguments that the FSF has already responded to in writing.)
It is quite possible to disagree with Richard Stallman's views, especially if you don't start with the same values as axioms. And, in person, he is not always the most suave and charming character, to say the least. But if you actually read anything he has written, you'll find that his essays never make personal attacks, almost always try to directly respond with reasons to the actual arguments of those who disagree with him, and maintain a calm tone.
It is unfair to base your opinion of him on the strawmen propped up continually at Slashdot, and embarrassing that his strongest critics don't measure up to RMS's level of rationality.
(To be fair, the particular post I'm responding to is pretty mild; it doesn't make any arguments, it simply takes the Slashdot characterization of RMS as a given.)
Nope, if all the claims are allowed, then the patent's coverage is determined by the language of the broadest claim by itself. The more-specific "dependent" claims are only fallback positions if the broad claims are thrown out (by the patent office or later, by a a court).
See also my other post in reply to another person who was similarly confused about patent law.
That's not how patents work. You make a set of "independent" claims, which attempt to be very broad and stand on their own. If one of these is allowed (i.e. it doesn't cover any prior art, etcetera), then your patent covers anything described by just the language of that claim by itself.
In addition to the independent claims, you have a set of "dependent" claims, which are like "The device of claim 1, where [some more specific requirement]." These dependent claims serve three purposes:
If the patent office denies your independent claim, it can still allow one or more of the dependent claims...these will be less broad, but at least you still get some coverage.
If the patent office accepts your independent claim, but someone challenges it in court, the dependent claims give you a fallback position in case a judge throws out the independent claim (because of prior art or whatever).
The dependent claims help prevent someone from claiming some specific variation on your invention...they would still need a license from you for the broad claim, but you would then need a license from them as well for that specific case.
I am not a lawyer, but I have worked with a number of lawyers to draft (non-software) patent claims and to deal with US and international patent examiners.
Slashdot Mirror
The .so name of a shared library under Linux encodes not only whether the library has been revised, but also indicates ABI compatibility.
If the library authors know what they are doing, when they release a new version of a library they will set the .so version number (different from the human-targeted source-code version number) to reflect which previous versions of the library the new release is compatible with. As a result, ABI-compatible software does not need to be recompiled.
See, for example, the shared-lib versioning documentation for GNU libtool.
LyX has built-in templates for RevTeX, so it works well with most physics journals. I occasionally run into a journal that uses a custom non-RevTeX stylesheet not supported by LyX, but it's always possible to get it to work with LyX. The easiest thing is to just format it for the journal at the very end, right before submission, by exporting LyX to LaTeX and then switching it over to the new style file (and any minor changes that requires). (It's also not too hard to write a new LyX template to use a new stylesheet if you want to do everything in LyX.)
I was talking about the MIT group (who explicitly discuss the differences between what they are doing and what Tesla considered), not the group in the article here. And you're right that Tesla also looked at non-radiative schemes for very short distances, e.g. Tesla coils, but at the time of Tesla most of the interest was in long-range power delivery (which never worked out because of the problems with radiative transfer, and in any case such schemes were supplanted by the wired electrical grid).
Tesla coils involve large electric fields between the source and receiver device, and so (a) are quite different from the magnetically-coupled resonators the MIT group proposes and (b) are impractical for the short-distance power-delivery applications considered here because they can dissipate too much energy into the environment.
The MIT group is not proposing to use omnidirectional (or directional) radiative energy transfer, which indeed would radiate most of the energy into the environment, and only a small fraction into the receiver, and even that could be eliminated if something (e.g. a person) walks between the source and receiver.
They are proposing non-radiative resonant energy transfer, in which both the source and receiver are resonant oscillators at a particular frequency coupled via the near field (non radiatively), and hence preferentially transfer energy compared to anything else that is not resonant (with a long lifetime) at the same frequency. Furthermore, they are using resonators that only couple through their magnetic fields (the electric fields are largely within capacitors inside the device), which further reduces absorption of energy by the environment (because most materials are non-magnetic, energy dissipation is largely via ohmic heating, i.e. by the electric fields). Because of this, almost all of the losses take the form of resistive heating in the devices themselves; only a miniscule fraction is dissipated in the surrounding environment (e.g. a person).
Of course, this being Slashdot, it's not surprising that most posters never RTFAed and post nonsense "it's just like an inductive transformer" (nope, those don't use resonance) or "it's just like an antenna" (nope, that is radiative transfer) or "Tesla looked at this a century ago" (nope, people like Tesla were concerned with power transfer over long distances, which necessitates radiative mechanisms and hence low efficiency).
They lost my vote when Obama voted for immunity for Telco's.
Um, Obama actually voted against immunity for telcos regarding the wiretap issue. (See e.g. this news article) McCain, on the other hand, voted for immunity.
But don't let facts get in the way of your voting decisions.
According to the Internet Archive, Scilab only began calling their software "open source" in 2004, well after the "open source" term had been popularized for software by OSI with a specific meaning that people trusted (cluetrain: the older uses of the term "open source" were primarily for non-software). It sure looks like they were trying to exploit this popularity, even though the result ends up being deceptive because they don't grant the same freedoms that people have come to expect from "open source" code.
Sorry, but this old myth about FLOSS software being vulnerable to forking of incompatible versions has been debunked over and over again. (Think about it for a moment: if this were really a "huge problem", the same thing would have popped up for Python, Perl, PHP, and every other standardized language popularized by free software.) As long as the original author maintains the software and keeps it free/open-source, any incompatible forks will be ignored.
But what about Scilab, which on its home page prominently claims to be The open source platform for numerical computation (and has been doing so for years)? Scilab clearly does not qualify for the (widely agreed-upon) OSI definition of "open source", because the license prohibits commercial redistribution of modified versions. And yet I've never heard of an OSI campaign to pressure Scilab to either change its license or stop calling itself "open source". As a result, there are many examples of people who have confused Scilab's license with the usual definition of "open source".
Um, sorry, but you obviously haven't read (or at least, haven't comprehended) the definition. Neither the OSI definition of "open source" (or, for that matter, the FSF definition of "free software") requires you to make any restrictions in your license, much less GPL-like restrictions. The definitions only prohibit license restrictions more than a certain amount, but say nothing about less restrictions.
I hope the fact that you have obviously built a passionate position on top of ignorance and falsehood causes you to go back and re-think some of your opinions.
First, Britannica is also a tertiary source, just like Wikipedia aims to be; just because they employ experts doesn't mean that they publish any new results or interpretations. (Don't confuse a summary, which simply repeats known information in a condensed form, with a novel synthesis, which combines information in order to draw new conclusions and reveal new relationships. Tertiary sources like Wikipedia and Britannica do the former but not the latter.)
Second, regardless of how Wikipedia is perceived by people who don't understand its policies, as long as Wikipedia does not permit editors to publish novel theories, analyses, interpretations, information, etcetera, then there will be a market for reputable sources that do provide original research. If I'm a scientist and I want to publish a research paper, then I have to go to a scientific journal, regardless of how good Wikipedia's reputation (currently nowhere near that of professional journals, with good reason) becomes. If I'm a reader and I want up-to-date, original reporting of the news, I have to go to a newspaper or other media outlet, because I won't find that information in Wikipedia (except as an abbreviated summary, after the fact). In fact, I would argue that Wikipedia helps to drive more traffic towards quality sources, because it provides links and references (at least, this is the policy), which readers must follow in order to find more in-depth information than the general overview found in an encyclopedia (however specialized or comprehensive). I often find Wikipedia articles more useful than Google searches, precisely because their links are the result of a human being scouring the Web for the most useful sources.
Wikipedia has never claimed, or aimed, to be a replacement for newspapers, scientific journals, textbooks, and so on, and there is no danger of its doing so, much less "logical inconsistency".
Any strict logician will realize that the English language is imprecise enough that it is easy to make fallacious claims of "logic" or "paradox" based on naive parsing and superficial interpretation.
In this case, there is no inconsistency. Wikipedia aims to become a premier tertiary source (i.e., merely summarizing established knowledge), fulfilling the role of both traditional and specialized encyclopedias. It does not seek to replace primary and secondary sources (those which provide new information and interpretation). In fact, any attempt to do so in Wikipedia will be deleted because it is against their official policy. So, even if it succeeds in eliminating all competing tertiary sources (which seems unlikely), there is no reason why Wikipedia should lack reliable primary and secondary sources to cite and summarize.
It is precisely this distinction that the reviewer fails to grasp in his complaint about deletion of (unspecified) "good information" on the grounds of non-notability. Because Wikipedia is not a primary or secondary source, it is not the appropriate place for "knowledge" that appears almost nowhere else, or cannot be found in any independent, reputable, published source—this is precisely what is meant by "non-notability" in Wikipedia.
VC++ is not worth its salt, especially for numerical work. (Not too surprising, as Microsoft is the same entity that decreed Windows wouldn't set the x86 FPU in extended -precision mode.) And the other languages you cited are not C/C++. It's no problem to find a C/C++ compiler for x86 that compiles long double to extended precision on x86.
I can compile a single x86 code that uses extended precision and works on all x86 CPUs in recent memory. Of course, the speed varies, but you are stretching to argue that the extended precision isn't widely supported.
Lots of people have made the same argument about C++. The problem is that every programmer uses a different subset of the language, so you end up having to deal with the whole mess in a program of any real size.
It's a bad sign if you have a language that is so large, you have to start imposing artificial constraints like intentionally subsetting the language or following "design patterns" in order to manage the complexity.
Um, considering that the vast majority of the world's floating-point hardware is x86 and supports extended precision, saying that it lacks "true support from almost every mainstream architecture" is comical.
(I agree that relatively few numerical applications need extended precision on a regular basis, but it is awfully useful on occasion. A very simple use is to assess the impact of roundoff error on a double-precision program: by far the easiest way is to increase the precision and see how much the answer changes, but this requires a floating-point type with greater than double precision. Yes, you could drop in an arbitrary-precision type, but this may be too slow in a large computation.)
In any case, D's claim to this feature is a bit odd, since every x86 C/C++ compiler worth its salt already compiles long double to extended precision.
My feeling is that languages shouldn't try to satisfy all possible needs. Rather, we should have small and clean languages, use the right tool for each job, and combine code libraries from different languages when needed. (I regularly use 3-6 languages in a single project and my life is much happier for it.)
(Legacy support is critically important too, but it is vastly better to provide legacy support by providing ways to call older languages, especially the lingua franca of C, rather than demanding that the new language be a superset of the old. I still call numerical libraries written in pre-1970 Fortran, but that doesn't mean I have to write my code in a Fortran derivative.)
Sorry, I missed your comment about the absolute error. The L2 norm of the data for an unnormalized DFT scales like sqrt(N), not like N, so your N log N is still not correct. In any case, the absolute error is totally meaningless: if you multiply all of the data points by 16, the error doesn't get worse by 16 (in floating-point, anyway)
Although it is not plotted, the same page has links to the complete datasets which include L-infinity errors. For example, on a POWER5 with gcc and FFTW 3.1 in single precision, the L-inf relative forward error for size 16 is 6.68e-8, whereas for size 262144=2^18 it is 3.6e-7. This is an increase by a factor of 5.4, which is close enough to the prediction of 4.5 from the O(log N) error bound.
Perhaps you have something wrong with your code. For example, if you use an trigonometric recurrence, your error will likely have worse scaling (depending on which recurrence you use), as explained in the commentary page mentioned above.
That should be O(sqrt(log N)) for the rms error and O(sqrt(N)) for fixed point. (My sqrt symbols didn't post properly somehow)
In floating-point arithmetic, the algorithm was proved in 1966 to have an upper bound for the error that grows only as O(log N), and the mean (rms) error grows only as O(log N). (See this page for more info.) (Errors in fixed-point arithmetic are worse, going as N.)
Even in single precision, the errors for their FFT sizes are probably quite reasonable, assuming they haven't done something silly like use an unstable trigonometric recurrence.
Those GNU folks are just evil; that's why they would never agree with something like the Vorbis BSD license.
Or it could be that most people don't really understand the need for encryption, are hopelessly confused by key management, and won't use it until it is bundled with their computer and employed by default in their email program.
My main point is that some of the best examples of reasoned argument are to be found in the FSF's essays, and often not in the writings of those who accuse them of zealotry and irrationality.
Nice try, but this in in their FAQ (although "Frequently Made Arguments" would be a better name). You are free to disagree, but you have to respond to their counter-arguments or things will just go in a circle.
This isn't an argument, this is a statement of fact. The FSF doesn't dispute that people do, in fact, call the system Linux, and they even support people's free-speech right to call it whatever they choose (this is a FAQ, too). Their argument is over what the system should be called.
The whole purpose of the GNU project, starting in 1984, was to develop a free operating system. It's hard to say that they didn't "lead" the development when they were the people to start it. This in, in fact, the FSF's main argument, which you have still failed to address. (They also respond specifically to suggestions that the GNU name only be used for those components they particularly developed.)
I don't really want to have to argue the side of the FSF here; I'm not their spokesperson, and my views are not identical theirs. I just find it frustrating to watch people argue in circles about this all of the time because they don't respond to counter-arguments. Still, your post is much better than the vast majority on the topic.
It is quite possible to disagree with Richard Stallman's views, especially if you don't start with the same values as axioms. And, in person, he is not always the most suave and charming character, to say the least. But if you actually read anything he has written, you'll find that his essays never make personal attacks, almost always try to directly respond with reasons to the actual arguments of those who disagree with him, and maintain a calm tone.
It is unfair to base your opinion of him on the strawmen propped up continually at Slashdot, and embarrassing that his strongest critics don't measure up to RMS's level of rationality.
(To be fair, the particular post I'm responding to is pretty mild; it doesn't make any arguments, it simply takes the Slashdot characterization of RMS as a given.)
See also my other post in reply to another person who was similarly confused about patent law.
In addition to the independent claims, you have a set of "dependent" claims, which are like "The device of claim 1, where [some more specific requirement]." These dependent claims serve three purposes:
I am not a lawyer, but I have worked with a number of lawyers to draft (non-software) patent claims and to deal with US and international patent examiners.