And COM/CORBA have been such a rousing success that Microsoft is now touting the CLR. I don't have much experience in developing applications that use CORBA (I think it's sufficient to equate CORBA and DCOM) but I did look at it at one point for the application we develop where I work. Our application depends on communications between devices over a network and we thought it would make developing easier if each instance of the application presented a set of objects that could have messages passed over the network relatively seamlessly. This seems to be exactly the problem CORBA was meant to solve but after looking at the amount of complexity using CORBA would require versus what we actually needed to do we decided against CORBA.
That's all aside from your point though, from what I can tell though, COM and CORBA work best for languages that are statically typed and classes are defined entirely at design time. Languages like Smalltalk, Dylan and ObjectiveC need not apply. Furthermore, I didn't get too far into the CORBA IDL capabilities but it seems that there is no provision for passing executable code as an argument. For languages like LISP, Haskell and ML this is one of the fundamental programming techniques used. I do believe CORBA had some support for generic programming of which C++ templates are an example.
So basically COM/CORBA work well for the relatively small number of ALGOL like languages with static typing and statically derived objects a la C, C++, Ada, Pascal etc. Languages that use different paradigms do not fit well with COM/CORBA nor has the CLR removed these limitations. However in Miguel's reply he stated that he believed using the CLR will allow GNOME developers to essentially use any language they felt like. While for a relatively small family of languages: C, C++, Java, C# and thier ALGOL derived cousins (Ada, Pascal, Modula) this is true for a much larger set of programming languages there are many features that will not interoperate with.NET causing one to write code that is inefficient when expressed in the idiom of those languages. I've seen what happens when FORTRAN programmers try to use Mathematica and very often they end up with Mathematica code that runs two orders of magnitude slower than people who use a more functional style. It is from stories like this that functional languages have developed a reputation for inefficiency. Writing LISP with a C# accent is similarly futile but that is essentially what the CLR enforces, LISP interfaces must use a C# idiom and even more importantly any LISP programmers using objects from the.NET framework will find C# idioms creeping through thier programs whether they export any objects or not.
Incidentally it's not only the paradigmatically different languages that are second class citizens in the CLR. There is not support in the CLR for Eiffel assertions which enforce the design by contract style favoured by Eiffel programmers even though Eiffel is ulimately a descendent on the infamous ALGOL tree.
Interface design is necessarily constrained by the constructs that can be used in an implementation. Procedural APIs are very efficient when used with imperative languages as in numerical codes for example, but for functional languages a style which passes functions as first class arguments and avoids side effects is much more efficient. So you can't define the interface independently of the implementation environment you expect to use and the CLR's environment is too restrictive to allow the types of interfaces used by a large number of programming languages.
As an everyday user of Mathematica which is essentially a LISP like language with pattern matching facilities I beg to differ. I also use Matlab, Ada, FORTRAN and C and can definitively state that my productivity is highest in Mathematica both for numeric and symbolic codes.
This is of course a horses for courses argument anyway, for many tasks (GUI implementation, manipulation of operating system objects, database interfacing) only a masochist would use Mathematica. However that does not mean Mathematica has not delivered on the advantages of functional programming. As for doing these other tasks in a functional paradigm, there are many Haskell, ML and CLOS developers who are happily writing GUIs and operating system level services but not so many database driven applications.
Before looking at what appears on the shelves of your local CompUSA, on the software list at Amazon.com, or the jobs advertised in your local paper or on HotJobs remember that 90% of all software is not developed for general consumption but to solve problems within a (usually) smaller organization.
The problem is not whether a compiler/interpreter for any language can use teh VM as the targeted back end. The problem is whether Microsoft's claim of language interoperability is true. So far the answer seems to be no. One can use all of their favourite languages features on a.NET compiler/interpreter but they cannot export any interfaces that may rely on some of those features: dynamic typing, closures, unsigned types etc. So what happens is Microsoft ends up effectively promoting a single programming style: essentialy C# except the syntax can be modified to look like your favourite language. No self respecting LISP, Scheme, ML, Haskell, Prolog etc. programmer is going to deliberately write inefficient code (and imperative style explicit looping is usually terribly inefficient in these languages as one example) simply because they are living withing the.NET CLR jail cell. Therefore they will use the language with the least impedance mismatch to the CLR: C#.
As has been mentioned often, the Java JVM has many of the same issues. However the developers of the Java JVM never claimed to efficiently support languages other than Java as first class citizens. The recent furor over the.NET CLR makes this seem like one tof the few wise choices they made so far.
So to reiterate, the issue is not whether a language can be targeted to the virtual machine, it's whether the object code produced from source code in two different languages can interoperate and the answer is simply no, only the subset of features shared by C# and other languages can interoperate.
First of all he is not being a petulant child. He points out a perfectly valid way of making a PLAINTEXT email message illegigible to Outlook users: start a line with the word begin. I would be pretty miffed if the provider of my mail client of choice has made decisions that dictate the manner in which I compose the body of an email. I think most rational Windows users would regard this "innovative" feature to be a flagrant abuse of power on the part of my email client vendor. The other tricks he plays are less insightful but bring to light a common complaint of non-Microsoft software vendors: Microsoft blatantly disregards many standards an hijacks others for personal gain.
The second point, exclusion of Outlook clients from his mailing list is also not without precedent. If I wish to create a locale where like minded people can gather I will definitely put up some simple barriers to entry for people who cannot share my opinions. In this case, he has made some decisions about how email clients should work and he only wishes to share his list with those with similar points of view. Since it is his list and not a general public utility it is his right.
First of all, I'd like to apologize for the "I can't believe someone asked this question!" tone most of the replies have.
Secondly, there seems to be a lot of confusion over object oriented programming versus languages which allow one to program in an object oriented style. It's been a while, but as far as I can remember there are three characteristics which define object oriented programing: encapsulation, polymorphism and inheritance. I am not going to define them here; any textbook can do that, but in general they are not terribly useful in a scientific/technical computing environment. For example, a lot of people get excited about making matrices or complex numbers into "objects". This is a poor choice in the case of matrices because it precludes the ability of a compiler/interpreter to make intelligent decisions about space/time tradoffs. For example A=A+B+C where A, B and C are matrices should avoid teomporary storage for B+C and simply accumulate the result in the storage allocated for A. Within the traditional object oriented paradigm there is no way to do this. Futhermore in packages which operate on values from the real, integer and complex sets the number of methods that need to be defined to handle the mixing of types is so large as to actually increase programming effort when done in a pure object oriented style. In general, binary operations and operations which change type like absolute value of a complex number are difficult to use efficiently in an object oriented style.
Generic programming which C++ supports through its template facility and therefore often gets lumped into the object oriented paradigm is generally more useful in these cases as one can define a single function like addition for example and not have to worry about the nature of the types being added. Functional languages also generally support this style hence the frequent recommendations to use that paradigm as well. However in my experience with languages that support a functional programming style: Mathematica and LISP primarily, you generally pay a price in memory usage for the ease of development.
That said, for programs with a lot of function entry points (ie, a large API), which is not generally the case in scientific/technical computing. The organizing principles of OO can be useful. Similarly for problem sets in which there are a few general operations applied to a wide variety of types functional programming techniques are useful, especially when intermediate results can be discarded. Scientific/technical programmers should be aware of all programming styles (as any programmer should) but the better programmers are aware of the tradeoffs involved in each style.
It seems a lot of people think all peripherals are created equal. Considering that many high end CPUs have more cache memory than the total memory of any PC produced before 1989 one could consider main memory to be "peripheral" already anyway.
At any rate, placing the FPGA on the memory bus allows the massive amount of communications required to reconfigure the board to occur in a reasonable time and also effectively gives you parallel processing for free. You treat part of the FPGA board as a second CPU (but not a general purpose one) and the rest of it as memory. When you've got an instruction stream that is better adapted to the FPGA's current confuguration, you write the data to it's memory, let it run and you can use the CPU for other tasks. Since most algorithms you'd want to run on the FPGA have a deterministic time of completion (even searches because you can bound the time it would take to search the entire data set) you just read the results off the FPGA memory after a little while.
Anyway I haven't read the article yet, so I'll go do that now.
But it should be noted this isn't anything new. The internal combustion engine is innefficient by nature. It takes a spherical
force (an explosion), redirects that into a vector force (up and down in a straight line), redirects that into a circular force,
which is redirected into another circular force, finally driving the car. Each of those redirections wastes energy.
Close but not quite. The problem is not with INTERNAL combustion engines in particular. All the engines being discussed here (except for fuel cells) are internal combustion engines. They change chemical energy to mechanical energy by burning their fuel directly. This is as opposed to EXTERNAL combustion engines which burn their fuel and use it to heat a working fluid usually steam which then is converted to mechanical energy by a thermodynamic process usually expansion of the heated working fluid against a piston. Steam engines are the usual example.
What makes the rotary concept interesting to engineers is the fact that the piston never has to change the direction of acceleration as much as it does in reciprocating engines. All else being equal: displacement, fuel, materials, etc. the way to get more power out of an engine is to make it turn faster. Because the pistons in reciprocating engines have to change their direction by 180 degrees at the top and bottom of a stroke there are mechanical limits on how high they can rev. Using exotic materials and small displacements Formula 1 engines can rev to about 18000rpm. The limits to revving these engines are actually the valves, but this technology would make a poor engine for a street car because the small displacement which is necessary to reduce the piston mass as well as being a result of F1 rules makes for very little torque at low revs. Think Honda S2000 (9000rpm redline 2.4 liter) versus Corvette (6500rpm redline 5.3 liter).
Anyway that's whats troubling about McMaster's claims. He says he can get rid of the transmission which is what allows you to rev the engine to a useful point in the power band at low speeds. So his rotary must produce a lot of torque which is not usually a characteristic of automotive rotaries, again compare the high revving but relatively slow off the line RX-7 to the big Detroit iron Vettes, Vipers and Mustangs.
Moreover,
the fact that you have carbon monoxide and other hydrocarbon emissions is a sign of innefficient combustion: complete
combustion of a carbon molecule goes all the way to carbon dioxide.
No, because of entropy combustion processes will produce a wide spectrum of byproducts. The more complex the thing you burn the more complex your end results. You can tune the spectrum, which is what most ULEV engines do, by carefully controlling the amount of fuel and temperature of combustion but you can never eliminate all byproducts. Hydrogen and oxygen combine to water alone only because hydroxide is unstable at the temperatures and pressures engines operate at, unlike carbon monoxide, and therefore if you add extra hydorgen the hydroxide will favourably combine into water too. Hydrogen burning internal combustion engines will also necessarily produce NHx and NOx (Nitrogen Hydrogen and Nitrogen Oxygen) compounds if they are obtaining their oxidant from the atmosphere but again thanks to favourable conditions we can limit the production of these by carefully controlling the temperature of combustion. Maybe that's why McMaster wants to use an oxygen cannister, that way he doesn't have to worry about nitrogen in his reaction.
The other technology discussed here is photovoltaic (solar-electric) conversion of water to hydrogen for combustion. I think
this is far more theoretical. Not that you can't very simply and reliably bang an electric current through water and get
combustible hydrogen and oxygen. But from what I know (and I do have some knowledge on this subject) I seriously
doubt whether existing photovoltaic cells are efficient enough to supply the power for even a very efficient automotive
engine by splitting water. It should be noted that like anything else, this conversion of electrical power into chemical power
represents a loss of efficiency, so the purpose for doing this is to get the benefit of a combustible fuel.
This may be inefficient but you can localize the inefficiency and optimise for it since electrolysis doesn't have to be done at the car. Although that raises the problems of hydrogen storage due to the low density of hydrogen. We already do this with refining plants for gasoline and other petroleum based products.
No volumetric pixels have nothing to do with this, you can render directly to screen coordinates after defining a transformation from world coordinates to screen coorfinates.
You have it backwards, if you want an exact or even a lossy representation of an image using fractals then compression is a very difficult problem. Decompression on the other hand is simply iterating a usually simple function, or a small set of functions. Since you can estimate the costs of calculating the function and the number off times you iterate is related to the level of detail you present you can calculate the level of detail you can represent given available compute power and time constraints.
The information is entirely parametric, you specify what region you are interested in and level of detail, then you get a texture back.
I'm a little lazy so I'm not going to give links, but a simplwe query (like "fractals" or "fractal compression") on Google should provide plenty of jumping off points.
You are correct in noting that funding is not generally an either/or problem but I have two nits to pick:
1) MRI is an outgrowth of NMR which is an application of quantum theory to chemistry. The basic research came out of the lab of R. Ernst in Switzerland and has little to do with radio research at all except for the fact that radio frequency signals are generated by the equipment.
Most radio researchers are either concerned with coding problems such as spread spectrum techniques, the related problem of signal interference or miniaturization of radio devices. Except for the last of these (and only slightly) none of it is of interest to NMR or MRI researchers. The means to produce high frequency radio signals was solved by Marconi, Tesla, Hertz and others at the turn of the century. It is an obvious step from the existence of radio frequency signals and the quantum physics of a system with a magnetic moment to NMR so no one was surprised the problems are mostly technical.
2) I don't have any evidence but I doubt most funded research can be considered "wasted". First of all most government research (and most research in general) is applied in nature. To get a grant you say I am going to develop a device (or method) that takes advantage of known physical principle X to solve problem Y. The most common example of "Blue Sky" research is the Apollo program (and the related Mercury and Gemini programs). In reality the Apollo program was far from "Blue Sky", the goal was to get to the moon using a rocket. Guess what they did after a long and painstaking development program?
The spinoffs were a nice side effect, (except for Tang, do they still make the stuff?) but by no means a reason to justify spending on science. A better example of "Blue Sky" research where the goal is ill defined and of unknown practicality is pure mathematics research. The funding levels for pure mathematics research are in the round off error if you use single precision floats to calculate the federal budget.
So one can argue whether the goals of government funded research are of benefit but to say that government funded science is by and large "a waste" is incorrect.
Smoothness is not a very helpful concept in dealing with friction. That is because smoothness is a question of scale, for example from the vantage point of the moon, Earth is (to a very good approximation) a smooth ball Himalayas notwithstanding. Incidentally, one of the highest coefficients of friction occurs when dealing with two highly polished metal plates moving across each other. If someone was silly enough to make teflon sandpaper smoothness would again not be an issue.
Really at the microscopic level friction is an electromagnetic phenomenon with some chemical exchange processes thrown in occasionally. There's just too much going on to try and think about it at that scale. That's what makes this research so remarkable: they have found a way of calculating a macroscopic quantity, namely the coefficient of friction, from a microscopic phenomenon, namely the propogation of cracks at an interface between two surfaces. The cracks themselves are created by the interactions of the electrons near the interface.
Incidentally, inelastic does not mean what you imply. Inelastic objects do not return to their original shape after deformation (think Silly Putty) so any force applied to an inelastic object would simply deform the object not move it.
Experimentally it can be shown that the force of friction is proportional to the force perpendicular to the interface or direction of travel. To make your interlocking mesh theory work you'd have to include terms for the depth of the valleys of the mesh to agree with experiment. I think Occam would say you really shouldn't waste your time.
I think that the reason physicists don't like to make a big deal of friction is that it is really an engineering exercise. To do any useful calculations for friction one has to consider too many ad hoc heuristic rules like the change in temperature due to energy exchanged, whether any chemical interactions occur at the surface, the changes in bulk structure due to shear forces (this is the big one for the tire on the road problem) etc. In the end though it usually suffices to average over the observed motion and make up a linear variable that explains what happens, hence the "coefficient of friction". Then like any good engineer rather than do an ab initio calculation you look up the value appropriate to your situation in a table or perform a quick and simple experiment to determine the value of the coefficient in your situation.
There is a lot more going on with tires than simply the area of the contact patch. Put simply, wider tires help with acceleration and braking because of the stiffer sidewalls of low profile tires (which is actually what's important) and the increased surface area which reduces tire heating making it less likely that the compound will break down and liquefy.
The better turn in performance of wider tires is primarily due to the shape of the contact patch (it's roughly elliptical) which on a wider tire provides a longer lever arm when turning. Actually on many high performance cars nowadays turn in is so abrupt that chassis engineers have to take other measures to reduce turn rate so normal drivers can control the cars.
Slashdot Mirror
And COM/CORBA have been such a rousing success that Microsoft is now touting the CLR. I don't have much experience in developing applications that use CORBA (I think it's sufficient to equate CORBA and DCOM) but I did look at it at one point for the application we develop where I work. Our application depends on communications between devices over a network and we thought it would make developing easier if each instance of the application presented a set of objects that could have messages passed over the network relatively seamlessly. This seems to be exactly the problem CORBA was meant to solve but after looking at the amount of complexity using CORBA would require versus what we actually needed to do we decided against CORBA.
.NET causing one to write code that is inefficient when expressed in the idiom of those languages. I've seen what happens when FORTRAN programmers try to use Mathematica and very often they end up with Mathematica code that runs two orders of magnitude slower than people who use a more functional style. It is from stories like this that functional languages have developed a reputation for inefficiency. Writing LISP with a C# accent is similarly futile but that is essentially what the CLR enforces, LISP interfaces must use a C# idiom and even more importantly any LISP programmers using objects from the .NET framework will find C# idioms creeping through thier programs whether they export any objects or not.
That's all aside from your point though, from what I can tell though, COM and CORBA work best for languages that are statically typed and classes are defined entirely at design time. Languages like Smalltalk, Dylan and ObjectiveC need not apply. Furthermore, I didn't get too far into the CORBA IDL capabilities but it seems that there is no provision for passing executable code as an argument. For languages like LISP, Haskell and ML this is one of the fundamental programming techniques used. I do believe CORBA had some support for generic programming of which C++ templates are an example.
So basically COM/CORBA work well for the relatively small number of ALGOL like languages with static typing and statically derived objects a la C, C++, Ada, Pascal etc. Languages that use different paradigms do not fit well with COM/CORBA nor has the CLR removed these limitations. However in Miguel's reply he stated that he believed using the CLR will allow GNOME developers to essentially use any language they felt like. While for a relatively small family of languages: C, C++, Java, C# and thier ALGOL derived cousins (Ada, Pascal, Modula) this is true for a much larger set of programming languages there are many features that will not interoperate with
Incidentally it's not only the paradigmatically different languages that are second class citizens in the CLR. There is not support in the CLR for Eiffel assertions which enforce the design by contract style favoured by Eiffel programmers even though Eiffel is ulimately a descendent on the infamous ALGOL tree.
Interface design is necessarily constrained by the constructs that can be used in an implementation. Procedural APIs are very efficient when used with imperative languages as in numerical codes for example, but for functional languages a style which passes functions as first class arguments and avoids side effects is much more efficient. So you can't define the interface independently of the implementation environment you expect to use and the CLR's environment is too restrictive to allow the types of interfaces used by a large number of programming languages.
As an everyday user of Mathematica which is essentially a LISP like language with pattern matching facilities I beg to differ. I also use Matlab, Ada, FORTRAN and C and can definitively state that my productivity is highest in Mathematica both for numeric and symbolic codes.
This is of course a horses for courses argument anyway, for many tasks (GUI implementation, manipulation of operating system objects, database interfacing) only a masochist would use Mathematica. However that does not mean Mathematica has not delivered on the advantages of functional programming. As for doing these other tasks in a functional paradigm, there are many Haskell, ML and CLOS developers who are happily writing GUIs and operating system level services but not so many database driven applications.
Before looking at what appears on the shelves of your local CompUSA, on the software list at Amazon.com, or the jobs advertised in your local paper or on HotJobs remember that 90% of all software is not developed for general consumption but to solve problems within a (usually) smaller organization.
The problem is not whether a compiler/interpreter for any language can use teh VM as the targeted back end. The problem is whether Microsoft's claim of language interoperability is true. So far the answer seems to be no. One can use all of their favourite languages features on a .NET compiler/interpreter but they cannot export any interfaces that may rely on some of those features: dynamic typing, closures, unsigned types etc. So what happens is Microsoft ends up effectively promoting a single programming style: essentialy C# except the syntax can be modified to look like your favourite language. No self respecting LISP, Scheme, ML, Haskell, Prolog etc. programmer is going to deliberately write inefficient code (and imperative style explicit looping is usually terribly inefficient in these languages as one example) simply because they are living withing the .NET CLR jail cell. Therefore they will use the language with the least impedance mismatch to the CLR: C#.
.NET CLR makes this seem like one tof the few wise choices they made so far.
As has been mentioned often, the Java JVM has many of the same issues. However the developers of the Java JVM never claimed to efficiently support languages other than Java as first class citizens. The recent furor over the
So to reiterate, the issue is not whether a language can be targeted to the virtual machine, it's whether the object code produced from source code in two different languages can interoperate and the answer is simply no, only the subset of features shared by C# and other languages can interoperate.
First of all he is not being a petulant child. He points out a perfectly valid way of making a PLAINTEXT email message illegigible to Outlook users: start a line with the word begin. I would be pretty miffed if the provider of my mail client of choice has made decisions that dictate the manner in which I compose the body of an email. I think most rational Windows users would regard this "innovative" feature to be a flagrant abuse of power on the part of my email client vendor. The other tricks he plays are less insightful but bring to light a common complaint of non-Microsoft software vendors: Microsoft blatantly disregards many standards an hijacks others for personal gain. The second point, exclusion of Outlook clients from his mailing list is also not without precedent. If I wish to create a locale where like minded people can gather I will definitely put up some simple barriers to entry for people who cannot share my opinions. In this case, he has made some decisions about how email clients should work and he only wishes to share his list with those with similar points of view. Since it is his list and not a general public utility it is his right.
First of all, I'd like to apologize for the "I can't believe someone asked this question!" tone most of the replies have.
Secondly, there seems to be a lot of confusion over object oriented programming versus languages which allow one to program in an object oriented style. It's been a while, but as far as I can remember there are three characteristics which define object oriented programing: encapsulation, polymorphism and inheritance. I am not going to define them here; any textbook can do that, but in general they are not terribly useful in a scientific/technical computing environment. For example, a lot of people get excited about making matrices or complex numbers into "objects". This is a poor choice in the case of matrices because it precludes the ability of a compiler/interpreter to make intelligent decisions about space/time tradoffs. For example A=A+B+C where A, B and C are matrices should avoid teomporary storage for B+C and simply accumulate the result in the storage allocated for A. Within the traditional object oriented paradigm there is no way to do this. Futhermore in packages which operate on values from the real, integer and complex sets the number of methods that need to be defined to handle the mixing of types is so large as to actually increase programming effort when done in a pure object oriented style. In general, binary operations and operations which change type like absolute value of a complex number are difficult to use efficiently in an object oriented style.
Generic programming which C++ supports through its template facility and therefore often gets lumped into the object oriented paradigm is generally more useful in these cases as one can define a single function like addition for example and not have to worry about the nature of the types being added. Functional languages also generally support this style hence the frequent recommendations to use that paradigm as well. However in my experience with languages that support a functional programming style: Mathematica and LISP primarily, you generally pay a price in memory usage for the ease of development.
That said, for programs with a lot of function entry points (ie, a large API), which is not generally the case in scientific/technical computing. The organizing principles of OO can be useful. Similarly for problem sets in which there are a few general operations applied to a wide variety of types functional programming techniques are useful, especially when intermediate results can be discarded. Scientific/technical programmers should be aware of all programming styles (as any programmer should) but the better programmers are aware of the tradeoffs involved in each style.
It seems a lot of people think all peripherals are created equal. Considering that many high end CPUs have more cache memory than the total memory of any PC produced before 1989 one could consider main memory to be "peripheral" already anyway.
At any rate, placing the FPGA on the memory bus allows the massive amount of communications required to reconfigure the board to occur in a reasonable time and also effectively gives you parallel processing for free. You treat part of the FPGA board as a second CPU (but not a general purpose one) and the rest of it as memory. When you've got an instruction stream that is better adapted to the FPGA's current confuguration, you write the data to it's memory, let it run and you can use the CPU for other tasks. Since most algorithms you'd want to run on the FPGA have a deterministic time of completion (even searches because you can bound the time it would take to search the entire data set) you just read the results off the FPGA memory after a little while.
Anyway I haven't read the article yet, so I'll go do that now.
Let's take things one at a time
But it should be noted this isn't anything new. The internal combustion engine is innefficient by nature. It takes a spherical force (an explosion), redirects that into a vector force (up and down in a straight line), redirects that into a circular force, which is redirected into another circular force, finally driving the car. Each of those redirections wastes energy.
Close but not quite. The problem is not with INTERNAL combustion engines in particular. All the engines being discussed here (except for fuel cells) are internal combustion engines. They change chemical energy to mechanical energy by burning their fuel directly. This is as opposed to EXTERNAL combustion engines which burn their fuel and use it to heat a working fluid usually steam which then is converted to mechanical energy by a thermodynamic process usually expansion of the heated working fluid against a piston. Steam engines are the usual example.
What makes the rotary concept interesting to engineers is the fact that the piston never has to change the direction of acceleration as much as it does in reciprocating engines. All else being equal: displacement, fuel, materials, etc. the way to get more power out of an engine is to make it turn faster. Because the pistons in reciprocating engines have to change their direction by 180 degrees at the top and bottom of a stroke there are mechanical limits on how high they can rev. Using exotic materials and small displacements Formula 1 engines can rev to about 18000rpm. The limits to revving these engines are actually the valves, but this technology would make a poor engine for a street car because the small displacement which is necessary to reduce the piston mass as well as being a result of F1 rules makes for very little torque at low revs. Think Honda S2000 (9000rpm redline 2.4 liter) versus Corvette (6500rpm redline 5.3 liter).
Anyway that's whats troubling about McMaster's claims. He says he can get rid of the transmission which is what allows you to rev the engine to a useful point in the power band at low speeds. So his rotary must produce a lot of torque which is not usually a characteristic of automotive rotaries, again compare the high revving but relatively slow off the line RX-7 to the big Detroit iron Vettes, Vipers and Mustangs.
Moreover, the fact that you have carbon monoxide and other hydrocarbon emissions is a sign of innefficient combustion: complete combustion of a carbon molecule goes all the way to carbon dioxide.
No, because of entropy combustion processes will produce a wide spectrum of byproducts. The more complex the thing you burn the more complex your end results. You can tune the spectrum, which is what most ULEV engines do, by carefully controlling the amount of fuel and temperature of combustion but you can never eliminate all byproducts. Hydrogen and oxygen combine to water alone only because hydroxide is unstable at the temperatures and pressures engines operate at, unlike carbon monoxide, and therefore if you add extra hydorgen the hydroxide will favourably combine into water too. Hydrogen burning internal combustion engines will also necessarily produce NHx and NOx (Nitrogen Hydrogen and Nitrogen Oxygen) compounds if they are obtaining their oxidant from the atmosphere but again thanks to favourable conditions we can limit the production of these by carefully controlling the temperature of combustion. Maybe that's why McMaster wants to use an oxygen cannister, that way he doesn't have to worry about nitrogen in his reaction.
The other technology discussed here is photovoltaic (solar-electric) conversion of water to hydrogen for combustion. I think this is far more theoretical. Not that you can't very simply and reliably bang an electric current through water and get combustible hydrogen and oxygen. But from what I know (and I do have some knowledge on this subject) I seriously doubt whether existing photovoltaic cells are efficient enough to supply the power for even a very efficient automotive engine by splitting water. It should be noted that like anything else, this conversion of electrical power into chemical power represents a loss of efficiency, so the purpose for doing this is to get the benefit of a combustible fuel.
This may be inefficient but you can localize the inefficiency and optimise for it since electrolysis doesn't have to be done at the car. Although that raises the problems of hydrogen storage due to the low density of hydrogen. We already do this with refining plants for gasoline and other petroleum based products.
No volumetric pixels have nothing to do with this, you can render directly to screen coordinates after defining a transformation from world coordinates to screen coorfinates.
You have it backwards, if you want an exact or even a lossy representation of an image using fractals then compression is a very difficult problem. Decompression on the other hand is simply iterating a usually simple function, or a small set of functions. Since you can estimate the costs of calculating the function and the number off times you iterate is related to the level of detail you present you can calculate the level of detail you can represent given available compute power and time constraints.
The information is entirely parametric, you specify what region you are interested in and level of detail, then you get a texture back.
I'm a little lazy so I'm not going to give links, but a simplwe query (like "fractals" or "fractal compression") on Google should provide plenty of jumping off points.
You are correct in noting that funding is not generally an either/or problem but I have two nits to pick:
1) MRI is an outgrowth of NMR which is an application of quantum theory to chemistry. The basic research came out of the lab of R. Ernst in Switzerland and has little to do with radio research at all except for the fact that radio frequency signals are generated by the equipment.
Most radio researchers are either concerned with coding problems such as spread spectrum techniques, the related problem of signal interference or miniaturization of radio devices. Except for the last of these (and only slightly) none of it is of interest to NMR or MRI researchers. The means to produce high frequency radio signals was solved by Marconi, Tesla, Hertz and others at the turn of the century. It is an obvious step from the existence of radio frequency signals and the quantum physics of a system with a magnetic moment to NMR so no one was surprised the problems are mostly technical.
2) I don't have any evidence but I doubt most funded research can be considered "wasted". First of all most government research (and most research in general) is applied in nature. To get a grant you say I am going to develop a device (or method) that takes advantage of known physical principle X to solve problem Y. The most common example of "Blue Sky" research is the Apollo program (and the related Mercury and Gemini programs). In reality the Apollo program was far from "Blue Sky", the goal was to get to the moon using a rocket. Guess what they did after a long and painstaking development program?
The spinoffs were a nice side effect, (except for Tang, do they still make the stuff?) but by no means a reason to justify spending on science. A better example of "Blue Sky" research where the goal is ill defined and of unknown practicality is pure mathematics research. The funding levels for pure mathematics research are in the round off error if you use single precision floats to calculate the federal budget.
So one can argue whether the goals of government funded research are of benefit but to say that government funded science is by and large "a waste" is incorrect.
Smoothness is not a very helpful concept in dealing with friction. That is because smoothness is a question of scale, for example from the vantage point of the moon, Earth is (to a very good approximation) a smooth ball Himalayas notwithstanding. Incidentally, one of the highest coefficients of friction occurs when dealing with two highly polished metal plates moving across each other. If someone was silly enough to make teflon sandpaper smoothness would again not be an issue.
Really at the microscopic level friction is an electromagnetic phenomenon with some chemical exchange processes thrown in occasionally. There's just too much going on to try and think about it at that scale. That's what makes this research so remarkable: they have found a way of calculating a macroscopic quantity, namely the coefficient of friction, from a microscopic phenomenon, namely the propogation of cracks at an interface between two surfaces. The cracks themselves are created by the interactions of the electrons near the interface.
Incidentally, inelastic does not mean what you imply. Inelastic objects do not return to their original shape after deformation (think Silly Putty) so any force applied to an inelastic object would simply deform the object not move it.
Experimentally it can be shown that the force of friction is proportional to the force perpendicular to the interface or direction of travel. To make your interlocking mesh theory work you'd have to include terms for the depth of the valleys of the mesh to agree with experiment. I think Occam would say you really shouldn't waste your time.
I think that the reason physicists don't like to make a big deal of friction is that it is really an engineering exercise. To do any useful calculations for friction one has to consider too many ad hoc heuristic rules like the change in temperature due to energy exchanged, whether any chemical interactions occur at the surface, the changes in bulk structure due to shear forces (this is the big one for the tire on the road problem) etc. In the end though it usually suffices to average over the observed motion and make up a linear variable that explains what happens, hence the "coefficient of friction". Then like any good engineer rather than do an ab initio calculation you look up the value appropriate to your situation in a table or perform a quick and simple experiment to determine the value of the coefficient in your situation.
There is a lot more going on with tires than simply the area of the contact patch. Put simply, wider tires help with acceleration and braking because of the stiffer sidewalls of low profile tires (which is actually what's important) and the increased surface area which reduces tire heating making it less likely that the compound will break down and liquefy. The better turn in performance of wider tires is primarily due to the shape of the contact patch (it's roughly elliptical) which on a wider tire provides a longer lever arm when turning. Actually on many high performance cars nowadays turn in is so abrupt that chassis engineers have to take other measures to reduce turn rate so normal drivers can control the cars.