Stalling is a huge issue. In Air France Flight 447, pilots stalled a large Airbus, because they were used to the automated anti-stall system. With the system in place, if you pull back on the stick the plane goes up. The pitot tubes plugged briefly. The system went to a manual mode (alternate law) that the pilots were unfamiliar with. The pilots pulled up, put the plane into a stall, and crashed the plane. They did not understand why they were not gaining altitude.
On average, it uses less fuel and is safer to fly in automatic (while the automatic systems work). As such, airlines push pilots to fly in automatic almost all the time. This results in pilots not flying in manual often enough. Automatic modes and long periods of routine flying mean that pilots lack the instincts to "take over and fly manually".
The issue with planes flying in automatic too much creeps into the design of the planes and manual modes on those planes. As the manual modes are used 0.001% of the time, companies don't prioritize safe manual flight. For instance, the manual (alternate law) mode on the Airbus did some wonky things with the flight controls (they averaged the command inputs). This meant that the plane would only recover from a stall if both pilots simultaneously commanded a dive. Boeing tries to make things more pilot friendly, however the 737MAX plane design is such that it is difficult to fly without automatic stall warning systems.
With
a) stall being a major failure mode,
b) pilots not getting enough practice as stall recovery while flying manually,
c) aircraft operators and aircraft manufacturers not prioritizing manual flying, and
d) the possibility of the anti-stall system failing,
the end result is many crashes of many different planes involving stall and pilots reactions to it.
It is usually said that sound waves do not transport mass. They carry momentum and energy,but it is an accepted fact that the net mass transported by a sound wave vanishes. Here, we question this “fact”. A first indication that sound waves can carry a nonzero net mass is contained in the results...
The researchers are looking at net masses and the mass of the total material transported. These masses can be negative.
Contrary to the above summary, the researchers are not proposing that sound waves have a "negative gravitational mass". That would rewrite a whole bunch of physics.
"The net mass transported by a sound wave vanishes" is a result based on conventional simplifying assumptions that are frequently used in the field. My recollection is that much acoustics research assumes inertial reference frame, constant average pressure, etc., as these are really useful simplifying assumptions. The point in the paper is that making some different simplifying assumptions yields some interesting results.
To be fair: All crash landings* involve problems with vertical ascension, and takeoff is by far the riskiest portion of the flight. The lack of altitude results in little time to recover from any issue. Thus, it is unsurprising to see two accidents on takeoff in a row, often with completely different causes.
* - It is possible to crash a plane on the ground. However, those crashes aren't usually described as crash landings. It's also possible to land a plane and go off the end or side of a runway, etc.
The anti-collision system pretty much has to use LIDAR. It's the only current technology with sufficient spacial accuracy and reliability sufficient for a self-driving application.
The issue with using a camera system for anti-collision is that it doesn't work in many edge cases, as Tesla is experiencing.
The combination of the two systems does work well, and can cover off many edge cases where the Lidar or the camera system by themselves is inadequate.
While it is easily documented that a camera system responds differently to people with different skin tones, facial recognition cannot be used reliably for any form of vehicle navigation. There are many situations where people don't have camera-recognizable faces. People can be facing away from oncoming traffic. In cold weather, people may be wearing full gloves, goggles and face masks. This blocks facial recognition. Similarly, firemen wear face gear in all dangerous situations year round. Firemen and construction workers often carry gear that obscures their shape. There are lots of situations where the vehicle navigation system is going to have to deal with unusual obstacles, and facial recognition does not provide much useful information. At best, facial recognition only tells if a person is aware of the on-coming traffic. It does not predict how people will respond, to a sufficient accuracy for a safety system.
If you are willing to pay for news, you want good news. The problem is that if you subscribe to the Wall Street Journal, then you aren't going to get good local coverage, unless you live in Washington.
The holy grail is to develop a business model that pays for good investigative journalism, and can cover local, national, and international stories. This is what Apple is proposing. A funding model where you get premium local content as well as premium national and international content.
I can only see two ways for this to happen:
a) For someone like Apple or Google to create a paid news service, or
b) For someone like the Wall Street Journal or the New York Times to purchase large numbers of papers, and become so large that they control all the news: local, national and international.
Interestingly, whoever creates the service will have huge market power in the news industry. Personally, I think (a) will be more democratic, because they will likely reward people with good stories with more money. However, it is really hard to tell how this will shake out. The only given is that the local papers are dying with no long-term revenue model. Something like this has to happen for the local papers to survive as quasi-independent outfits.
Another issue is that if you know for certain that you have a 32-bit program that will always be a 32-bit program, then why wouldn't you make it a 32-bit program compatible with almost every 32-bit version of Linux out there?
When it launched, the people with 64-bit processors were purchasing them because they could reliably access more than 2 GB of RAM in user-space. Most of the operating systems and hardware architectures had configurations where the top 2 GB of RAM was reserved for operating system use. Sometime versions of operating systems permitted 3GB of user-space RAM. It was almost impossible to utilize a full 4GB of RAM on a 32-bit processor.
This created a hunger. If you have a program that might need more than 2 GB of RAM some point in the future, then 64-bit is the way to go.
Not much has changed since the 64-bit processors launched. If you have programs that will only require 32-bits, then the standard proven x86 and ARM architectures are the way to go. This applies in embedded systems too. In embedded, you want a well-proven tool chain.
If you have an intensively used data structure that is less than 2 GB in size, then it can often be represented as an 32-bit index into an array. This compiles cleanly with both 32-bit and 64-bit compilers. With the hardware support on modern processors, it has about the same execution speed as using 32-bit pointers.
This leaves the x32 ABI supporting non-price sensitive programs that need the speed of a 64-bit processor, do not have data structures that can be represented as an arrays, will not need 64-bits, and run on specific hardware/software stacks. It is a niche market at best. I imagine someone has used it for something, but it is hard to envision an application specifically requires the x32 ABI. For a 32-bit application, the 386 instruction set is good enough.
A common configuration for FTP servers was that they support all logins, both privileged and unprivileged. That means you can simply run a password guesser at it until you find the login for a privileged account. Alternatively, you can snoop on the traffic until someone logs in, steal there credentials, and hope they have privileged access. A privilege escalation attack works too.
If you had the ability to snoop and modify the traffic, then a good approach would be to wait until the wait until election day and modify the results in real-time. As long as there are no other checks, it would be very difficult to prove.
An interesting complication would be if multiple parties tried to hack the system simultaneously. A clever malicious hacker would keep the changes within the limits of statistical feasibility. A poor hacker would simply make everyone vote the same way. For the clever malicious hacker to be succeed, he would also need to secure the system against the poor hacker without being detected. Thus, for the malicious, there is an optimal level of security. Too much security, and the system can't be modified. Too little security, and it is possible that someone else will hack the system, and expose the flaws.
A malicious actor requires a very specific level of insecurity. A competently designed system with paper ballots won't work, because an audit-check on the paper ballots would expose tampering. The malicious actor requires a system that appears to be secure, but has no effective audit checks. If the system was completely insecure, then some script kiddy could break in, and the scheme would unravel. Similarly, the system can't have any deliberately engineered security holes, because the author of the software could turn states-witness and the scheme would unravel too. The system needs a set of security holes that can be attributable to design incompetence. Is an FTP server might be a suitable middle-ground? Maybe...
The movie industry fought hard against a CD-R style tax on DVD-R's and on internet streaming. Apparently the courts in Canada asked why the music industry was chasing pirates when they already had a tax to deal with piracy.
The movie industry noticed this decision and did not want the same thing to happen to them.
Much of the current copyright fee structure had been created by a few very large corporations guarding their profits on a relatively sma number of works, and they don't care about any other concerns, people or artists. It really doesn't surprise me that this proposal is coming from a group of smaller artists. The current system is completely broken for smaller works, orphan works, and near orphan works.
Try strlcpy and strlcat. They should be present on most Linux and Mac systems.
On Microsoft, try StringCchCopy or StringCchCopyEx.
Microsoft has written a large number of "better" versions of strcpy. Writing your own string functions will result in your code becoming like Microsoft's. Every programing team will have dozens of library functions, all very similar, and most with known security bugs.:-)
If you are Google it pays to purchase some cheap insurance against Microsoft doing something that could screw you.
Once you get to Google, Microsoft, Apple size, then you need people on all the key committees. These people purchase connections and goodwill. When an important decision comes up, you have the connections and goodwill to ensure it goes your way.
References to papers less than 5 years old help your fellow colleagues get tenure, and help your fellow students get Masters Degrees and PhDs.
Older references are essentially sites to influential papers. Those papers were written by influential people that already have tenure. Those people would prefer you help the junior faculty, the Master's and PhD students.
To be a friend, you need to cite the newer research.
In the elastic region, increasing strain increases stress / tension. When the member enters the plastic region, steel under tension starts to neck. In this region, increasing strain can result in decreased stress. Eventually, the member fails and you have lots of strain and no stress / tension.
When tensioning, the question every structural engineer must ask is: Am I in the elastic region? For sure?
Structural engineers tend to use ridiculously small assumptions for material strength to guarantee being in the elastic region. However, one good crack or subsurface fracture, and fracture can occur. High performance work tends to use fea to predict areas of stress concentration, and then eddy current, magnetic and x-ray inspections to prevent these failures. This is not common in structural applications.
While officially Microsoft supports static linking, in practice, it is necessary to use DLLs in many situations. The Microsoft official answer is at: Extension DLLs
The practical reasons that I have been forced to use DLLs are:
1. If you want your application to upgrade smoothly over the years, you have to use either the DLL calls or the windows system calls and avoid the statically linked C libraries. For instance, when the times and dates for daylight savings time change, only the windows calls get updated automatically. The statically linked libraries don't get updated. DLL libraries get updated when the DLL gets updated (which can lead to DLL Hell, but that is another story.)
2. If you have an application that allocates memory in one DLL and frees it in another, then it is vital that the library that does the memory management be a DLL. Otherwise, each DLL has it's own statically linked memory mapping library, and they don't know about each other's allocations.
3. (2) applies to applications that use new and delete. It also applies to applications that are ActiveX controls and using IMalloc.
4. Some of the cool Microsoft libraries link to DLLs, so it doesn't matter if you want to use static libraries. You are getting DLLs.
5. Only the really old languages like C++ and QuickBasic supports static linking. I'm pretty sure Visual Basic, C# and.NET all require DLLs.
The highest ranked government official routinely speaks random thoughts on Twitter. It's only the lower ranked officials that see the point in avoiding confusion, inflammatory statements, annoying nuclear-armed dictators, etc.
The reason why it is not "twice the work" is because a crude interval approach only works for linear equations. Consider: y=x^2, for small x. If the lower limit is x=-0.1, and the upper limit is x=0.1, y=0.01 in either case. However, consider the case where the actual x=0, with the actual y=0. It can be seen that for -0.1 < x < 0.1, y is outside the predicted range.
For many simple systems of equations, it is possible to get good error analysis by using some Calculus. Specifically, multiply the expected error in the inputs by the derivative (or an upper bound on the derivative).
Unfortunately, most of the people working in this area are solving complex systems of equations, often involving large matrices. This makes the problem difficult to detect with computationally fast approaches. Some people use Monte-Carlo simulations to get estimates of the likely error. These situations require far more computations than double (often thousands of runs). It is also possible to do some serious error analysis to determine when the linear interval analysis applies, and when it doesn't. However, this also requires far more calculations.
I've seen many hardware projects run into trouble because the selected hardware platform is too small for the software. The temptation is huge to start the hardware project early. However, if you don't know how fast the software is, how do you know if the hardware will be fast enough?
If the software is larger than the initial estimate (it usually is), and the hardware started too soon, then the hardware needs to be redesigned (often with software changes) and this is expensive.
5) It turns out there's a bad assumption shared by all the models, and if you correct it the extreme warming goes away.
Climate scientists assume that people will listen, and attempt to avert disaster. Unfortunately, if you look at the data, CO2 production keeps going up. As a result, the "assume humanity will take action" models consistently underestimate global warming.
It makes me begin to understand how civilizations collapse.
A key problem is that the IT industry lacks useful metrics. For instance:
- We have Big O notation, but the compiler doesn't automatically detect algorithmic complexity. As such, no one can easily tell if you have written a program (algorithm) that scales well, or scales poorly. This is a big problem for non-trivial pieces of code, because it is very easy to include an O(n^2) library function in a "tight" O(n^2) loop.
- Memory management is so well hidden in modern environments, that it is often impossible to tell how efficiently memory is used. It's a variation on the Big O notation problem. Thus, memory usage in a large framework (C# or Java) can obscure memory leaks and O(n^2) memory usage problems, until n becomes sufficiently large (in full production).
- What metric measures security? Security doesn't even have the benefit of Big O notation.
- In a big program, it is often not even possible to tell what code paths are actually being used. Run-time profiling helps a great deal, however there are privacy issues.
- There is an entire landmine about programs including interpreters (compilers) to execute user generated code block. For a program of sufficient size, it is necessary to do this. However, it is a security nightmare. How do you even tell, in the context of a large application, if it is possible for someone with normal use rights to execute malicious code?
- Almost every programming resume claims that the person is proficient in HTML, Java, and C++. How do you tell which programmers are good? In the context of a given project, what does good mean anyway?
Some metrics are present in software, but they are often ridiculed:
- # of lines of code
- Execution time. Specifically, execution time does not matter if the task is sufficiently fast that no one cares. If you have a Big O notation scaling problem, it is often possible to ship software and someone not notice until it is in production.
Many other industries have methods of measuring quality and suitability. Software, it exists, but not in an easy to use, obvious and mature form.
Academically, there are barriers that force polymath's to pick a specialty:
1. Everything in academics is based around papers. Usually, one does a conference paper before doing a full journal paper. The paper size limit for a conference paper is usually 6 pages. Conferences and journals are specialized - they only cover one field. Good luck introducing any moderately advanced concept from an unfamiliar field inside a 6 page conference paper. (Suggestion: Select a small sub-concept that can be explained in 6 pages.)
2. In academics, a key accomplishment is PhDs. At the start of an academic career, you need to get a PhD. As a professor, to graduate them. PhD's require a supervisory and examining committees. You need an institution with the people that can handle a PhD involving two (or more) specialized fields. Most professor's don't talk outside there fields. There can be a huge amount of academic warfare inside departments. (Suggestion: certain departments (applied math & statistics) are known for there abilities to co-operate in different fields. Also, certain universities (Oxford) are famous for handling more broadly trained scholars.)
3. Getting hired in academics. University departments hire people with skills that fit inside your department. If a two-field person is hired, the risk is that the second specialty will dominate and they won't really work in the department. Then one tenure position is "lost". It's a safer strategy to hire a clear fit.
4. Private sector hires strong academics. Multiple specialty people are usually well rewarded in the private sector. This means that the academic ranks tend to get raided for profitable talent. Universities tend to be dominated by people that have either retired from the private sector, or by people that didn't make it in the private sector. Every professor has some reason why they were not hired away for private sector work, including commercial prospects collapsed, commercial prospects don't exist, not a good corporate fit, people that dislike corporations, etc.
5. Academic Funding. In academics, you need to get funding to hire PhD students to write more papers. It is tough for one professor to fund his own efforts. I have heard numbers like only 1/3 of the professors in the US get meaningful research grants. With two specialties, you need to appeal to two grant committees, and be good enough to get funding in both fields. Any professor that is that good at getting funding will become the head of a research institute or a university funding initiative. They won't be doing research anymore.
The stock market does exactly the same thing. A companies valuation is based on the price of the last stock market transaction times the number of outstanding shares. The variance is also huge. This is the reason why one rogue trader can tank a companies stock. It is also the reason why a short selling hedge fund can also tank a companies stock.
The key difference between public and private sales is liquidity. The public market is much more liquid. An ecosystem of financial traders exist. These traders do clever financial transactions that try to find the optimal price to purchase / sell shares. This reduces the variance. Some people question the wisdom of these sophisticated trading algorithms (rightly). However, they do have the effect of ensuring that anyone selling a stock at the wrong price runs the risk of being gamed. A perceptive trader can simply purchase the trade at the lower price, and sell it later in the day at a higher price. These transactions correct the price of the shares to the true market value. On most days, this significantly reduces price volatility.
This doesn't mean that you can't game public shares, it only means that the variance will be less and that whoever is gaming the share prices must by much more clever about it. Whereas for private shares, it is possible to do whatever the seller / buyer want.
Every numerical methods text involving a scientific math library has warnings about the array-transposition bug. Huge math optimization work has gone into dealing with it. The problem is much worse in modern super-computers than in the older computers. In the old computers, memory accesses were fairly predictable. New supercomputers are clusters of computers. Each node can only hold a small section of a large array, and communication time is often a function of both the distance between nodes in hops and total communication load (saturated interconnects).
Huge work goes into figuring out how to do array operations in a fast manner. The work often becomes highly application dependent. Find special short-cuts that apply to particular matrices that allow one to make use of special theorems.
Slashdot Mirror
This means that I can't link to any legitimate news site. However, fake news sites are fair game ...
Stalling is a huge issue. In Air France Flight 447, pilots stalled a large Airbus, because they were used to the automated anti-stall system. With the system in place, if you pull back on the stick the plane goes up. The pitot tubes plugged briefly. The system went to a manual mode (alternate law) that the pilots were unfamiliar with. The pilots pulled up, put the plane into a stall, and crashed the plane. They did not understand why they were not gaining altitude.
On average, it uses less fuel and is safer to fly in automatic (while the automatic systems work). As such, airlines push pilots to fly in automatic almost all the time. This results in pilots not flying in manual often enough. Automatic modes and long periods of routine flying mean that pilots lack the instincts to "take over and fly manually".
The issue with planes flying in automatic too much creeps into the design of the planes and manual modes on those planes. As the manual modes are used 0.001% of the time, companies don't prioritize safe manual flight. For instance, the manual (alternate law) mode on the Airbus did some wonky things with the flight controls (they averaged the command inputs). This meant that the plane would only recover from a stall if both pilots simultaneously commanded a dive. Boeing tries to make things more pilot friendly, however the 737MAX plane design is such that it is difficult to fly without automatic stall warning systems.
With
a) stall being a major failure mode,
b) pilots not getting enough practice as stall recovery while flying manually,
c) aircraft operators and aircraft manufacturers not prioritizing manual flying, and
d) the possibility of the anti-stall system failing,
the end result is many crashes of many different planes involving stall and pilots reactions to it.
To quote from the paper's introduction:
The researchers are looking at net masses and the mass of the total material transported. These masses can be negative.
Contrary to the above summary, the researchers are not proposing that sound waves have a "negative gravitational mass". That would rewrite a whole bunch of physics.
"The net mass transported by a sound wave vanishes" is a result based on conventional simplifying assumptions that are frequently used in the field. My recollection is that much acoustics research assumes inertial reference frame, constant average pressure, etc., as these are really useful simplifying assumptions. The point in the paper is that making some different simplifying assumptions yields some interesting results.
To be fair: All crash landings* involve problems with vertical ascension, and takeoff is by far the riskiest portion of the flight. The lack of altitude results in little time to recover from any issue. Thus, it is unsurprising to see two accidents on takeoff in a row, often with completely different causes.
* - It is possible to crash a plane on the ground. However, those crashes aren't usually described as crash landings. It's also possible to land a plane and go off the end or side of a runway, etc.
The anti-collision system pretty much has to use LIDAR. It's the only current technology with sufficient spacial accuracy and reliability sufficient for a self-driving application.
The issue with using a camera system for anti-collision is that it doesn't work in many edge cases, as Tesla is experiencing.
The combination of the two systems does work well, and can cover off many edge cases where the Lidar or the camera system by themselves is inadequate.
While it is easily documented that a camera system responds differently to people with different skin tones, facial recognition cannot be used reliably for any form of vehicle navigation. There are many situations where people don't have camera-recognizable faces. People can be facing away from oncoming traffic. In cold weather, people may be wearing full gloves, goggles and face masks. This blocks facial recognition. Similarly, firemen wear face gear in all dangerous situations year round. Firemen and construction workers often carry gear that obscures their shape. There are lots of situations where the vehicle navigation system is going to have to deal with unusual obstacles, and facial recognition does not provide much useful information. At best, facial recognition only tells if a person is aware of the on-coming traffic. It does not predict how people will respond, to a sufficient accuracy for a safety system.
If you are willing to pay for news, you want good news. The problem is that if you subscribe to the Wall Street Journal, then you aren't going to get good local coverage, unless you live in Washington.
The holy grail is to develop a business model that pays for good investigative journalism, and can cover local, national, and international stories. This is what Apple is proposing. A funding model where you get premium local content as well as premium national and international content.
I can only see two ways for this to happen:
a) For someone like Apple or Google to create a paid news service, or
b) For someone like the Wall Street Journal or the New York Times to purchase large numbers of papers, and become so large that they control all the news: local, national and international.
Interestingly, whoever creates the service will have huge market power in the news industry. Personally, I think (a) will be more democratic, because they will likely reward people with good stories with more money. However, it is really hard to tell how this will shake out. The only given is that the local papers are dying with no long-term revenue model. Something like this has to happen for the local papers to survive as quasi-independent outfits.
This case would have been a good item for groklaw. That was a very good site for topics like this. I miss it.
Another issue is that if you know for certain that you have a 32-bit program that will always be a 32-bit program, then why wouldn't you make it a 32-bit program compatible with almost every 32-bit version of Linux out there?
When it launched, the people with 64-bit processors were purchasing them because they could reliably access more than 2 GB of RAM in user-space. Most of the operating systems and hardware architectures had configurations where the top 2 GB of RAM was reserved for operating system use. Sometime versions of operating systems permitted 3GB of user-space RAM. It was almost impossible to utilize a full 4GB of RAM on a 32-bit processor.
This created a hunger. If you have a program that might need more than 2 GB of RAM some point in the future, then 64-bit is the way to go.
Not much has changed since the 64-bit processors launched. If you have programs that will only require 32-bits, then the standard proven x86 and ARM architectures are the way to go. This applies in embedded systems too. In embedded, you want a well-proven tool chain.
If you have an intensively used data structure that is less than 2 GB in size, then it can often be represented as an 32-bit index into an array. This compiles cleanly with both 32-bit and 64-bit compilers. With the hardware support on modern processors, it has about the same execution speed as using 32-bit pointers.
This leaves the x32 ABI supporting non-price sensitive programs that need the speed of a 64-bit processor, do not have data structures that can be represented as an arrays, will not need 64-bits, and run on specific hardware/software stacks. It is a niche market at best. I imagine someone has used it for something, but it is hard to envision an application specifically requires the x32 ABI. For a 32-bit application, the 386 instruction set is good enough.
A common configuration for FTP servers was that they support all logins, both privileged and unprivileged. That means you can simply run a password guesser at it until you find the login for a privileged account. Alternatively, you can snoop on the traffic until someone logs in, steal there credentials, and hope they have privileged access. A privilege escalation attack works too.
If you had the ability to snoop and modify the traffic, then a good approach would be to wait until the wait until election day and modify the results in real-time. As long as there are no other checks, it would be very difficult to prove.
An interesting complication would be if multiple parties tried to hack the system simultaneously. A clever malicious hacker would keep the changes within the limits of statistical feasibility. A poor hacker would simply make everyone vote the same way. For the clever malicious hacker to be succeed, he would also need to secure the system against the poor hacker without being detected. Thus, for the malicious, there is an optimal level of security. Too much security, and the system can't be modified. Too little security, and it is possible that someone else will hack the system, and expose the flaws.
A malicious actor requires a very specific level of insecurity. A competently designed system with paper ballots won't work, because an audit-check on the paper ballots would expose tampering. The malicious actor requires a system that appears to be secure, but has no effective audit checks. If the system was completely insecure, then some script kiddy could break in, and the scheme would unravel. Similarly, the system can't have any deliberately engineered security holes, because the author of the software could turn states-witness and the scheme would unravel too. The system needs a set of security holes that can be attributable to design incompetence. Is an FTP server might be a suitable middle-ground? Maybe ...
It makes me feel so good to vote on Tuesday.
The movie industry noticed this decision and did not want the same thing to happen to them.
Much of the current copyright fee structure had been created by a few very large corporations guarding their profits on a relatively sma number of works, and they don't care about any other concerns, people or artists. It really doesn't surprise me that this proposal is coming from a group of smaller artists. The current system is completely broken for smaller works, orphan works, and near orphan works.
Try strlcpy and strlcat. They should be present on most Linux and Mac systems.
On Microsoft, try StringCchCopy or StringCchCopyEx.
Microsoft has written a large number of "better" versions of strcpy. Writing your own string functions will result in your code becoming like Microsoft's. Every programing team will have dozens of library functions, all very similar, and most with known security bugs. :-)
You need to design the systems such that they have a fall-back and can continue to operate without an internet connection.
Really ...
What are you going to do the next time a major blackout occurs, and the grid wants you to restart your turbines?
If you are Google it pays to purchase some cheap insurance against Microsoft doing something that could screw you.
Once you get to Google, Microsoft, Apple size, then you need people on all the key committees. These people purchase connections and goodwill. When an important decision comes up, you have the connections and goodwill to ensure it goes your way.
References to papers less than 5 years old help your fellow colleagues get tenure, and help your fellow students get Masters Degrees and PhDs.
Older references are essentially sites to influential papers. Those papers were written by influential people that already have tenure. Those people would prefer you help the junior faculty, the Master's and PhD students.
To be a friend, you need to cite the newer research.
BTW: I didn't invent this system.
In the elastic region, increasing strain increases stress / tension. When the member enters the plastic region, steel under tension starts to neck. In this region, increasing strain can result in decreased stress. Eventually, the member fails and you have lots of strain and no stress / tension.
When tensioning, the question every structural engineer must ask is: Am I in the elastic region? For sure?
Structural engineers tend to use ridiculously small assumptions for material strength to guarantee being in the elastic region. However, one good crack or subsurface fracture, and fracture can occur. High performance work tends to use fea to predict areas of stress concentration, and then eddy current, magnetic and x-ray inspections to prevent these failures. This is not common in structural applications.
While officially Microsoft supports static linking, in practice, it is necessary to use DLLs in many situations. The Microsoft official answer is at: Extension DLLs
The practical reasons that I have been forced to use DLLs are:
The highest ranked government official routinely speaks random thoughts on Twitter. It's only the lower ranked officials that see the point in avoiding confusion, inflammatory statements, annoying nuclear-armed dictators, etc.
Reader alert: The above post should be sarcastic.
The reason why it is not "twice the work" is because a crude interval approach only works for linear equations. Consider: y=x^2, for small x. If the lower limit is x=-0.1, and the upper limit is x=0.1, y=0.01 in either case. However, consider the case where the actual x=0, with the actual y=0. It can be seen that for -0.1 < x < 0.1, y is outside the predicted range.
For many simple systems of equations, it is possible to get good error analysis by using some Calculus. Specifically, multiply the expected error in the inputs by the derivative (or an upper bound on the derivative).
Unfortunately, most of the people working in this area are solving complex systems of equations, often involving large matrices. This makes the problem difficult to detect with computationally fast approaches. Some people use Monte-Carlo simulations to get estimates of the likely error. These situations require far more computations than double (often thousands of runs). It is also possible to do some serious error analysis to determine when the linear interval analysis applies, and when it doesn't. However, this also requires far more calculations.
I've seen many hardware projects run into trouble because the selected hardware platform is too small for the software. The temptation is huge to start the hardware project early. However, if you don't know how fast the software is, how do you know if the hardware will be fast enough?
If the software is larger than the initial estimate (it usually is), and the hardware started too soon, then the hardware needs to be redesigned (often with software changes) and this is expensive.
Climate scientists assume that people will listen, and attempt to avert disaster. Unfortunately, if you look at the data, CO2 production keeps going up. As a result, the "assume humanity will take action" models consistently underestimate global warming.
It makes me begin to understand how civilizations collapse.
It needs to report back, and wait for the reinforcements.
A key problem is that the IT industry lacks useful metrics. For instance:
- We have Big O notation, but the compiler doesn't automatically detect algorithmic complexity. As such, no one can easily tell if you have written a program (algorithm) that scales well, or scales poorly. This is a big problem for non-trivial pieces of code, because it is very easy to include an O(n^2) library function in a "tight" O(n^2) loop.
- Memory management is so well hidden in modern environments, that it is often impossible to tell how efficiently memory is used. It's a variation on the Big O notation problem. Thus, memory usage in a large framework (C# or Java) can obscure memory leaks and O(n^2) memory usage problems, until n becomes sufficiently large (in full production).
- What metric measures security? Security doesn't even have the benefit of Big O notation.
- In a big program, it is often not even possible to tell what code paths are actually being used. Run-time profiling helps a great deal, however there are privacy issues.
- There is an entire landmine about programs including interpreters (compilers) to execute user generated code block. For a program of sufficient size, it is necessary to do this. However, it is a security nightmare. How do you even tell, in the context of a large application, if it is possible for someone with normal use rights to execute malicious code?
- Almost every programming resume claims that the person is proficient in HTML, Java, and C++. How do you tell which programmers are good? In the context of a given project, what does good mean anyway?
Some metrics are present in software, but they are often ridiculed:
- # of lines of code
- Execution time. Specifically, execution time does not matter if the task is sufficiently fast that no one cares. If you have a Big O notation scaling problem, it is often possible to ship software and someone not notice until it is in production.
Many other industries have methods of measuring quality and suitability. Software, it exists, but not in an easy to use, obvious and mature form.
Academically, there are barriers that force polymath's to pick a specialty:
1. Everything in academics is based around papers. Usually, one does a conference paper before doing a full journal paper. The paper size limit for a conference paper is usually 6 pages. Conferences and journals are specialized - they only cover one field. Good luck introducing any moderately advanced concept from an unfamiliar field inside a 6 page conference paper. (Suggestion: Select a small sub-concept that can be explained in 6 pages.)
2. In academics, a key accomplishment is PhDs. At the start of an academic career, you need to get a PhD. As a professor, to graduate them. PhD's require a supervisory and examining committees. You need an institution with the people that can handle a PhD involving two (or more) specialized fields. Most professor's don't talk outside there fields. There can be a huge amount of academic warfare inside departments. (Suggestion: certain departments (applied math & statistics) are known for there abilities to co-operate in different fields. Also, certain universities (Oxford) are famous for handling more broadly trained scholars.)
3. Getting hired in academics. University departments hire people with skills that fit inside your department. If a two-field person is hired, the risk is that the second specialty will dominate and they won't really work in the department. Then one tenure position is "lost". It's a safer strategy to hire a clear fit.
4. Private sector hires strong academics. Multiple specialty people are usually well rewarded in the private sector. This means that the academic ranks tend to get raided for profitable talent. Universities tend to be dominated by people that have either retired from the private sector, or by people that didn't make it in the private sector. Every professor has some reason why they were not hired away for private sector work, including commercial prospects collapsed, commercial prospects don't exist, not a good corporate fit, people that dislike corporations, etc.
5. Academic Funding. In academics, you need to get funding to hire PhD students to write more papers. It is tough for one professor to fund his own efforts. I have heard numbers like only 1/3 of the professors in the US get meaningful research grants. With two specialties, you need to appeal to two grant committees, and be good enough to get funding in both fields. Any professor that is that good at getting funding will become the head of a research institute or a university funding initiative. They won't be doing research anymore.
The stock market does exactly the same thing. A companies valuation is based on the price of the last stock market transaction times the number of outstanding shares. The variance is also huge. This is the reason why one rogue trader can tank a companies stock. It is also the reason why a short selling hedge fund can also tank a companies stock.
The key difference between public and private sales is liquidity. The public market is much more liquid. An ecosystem of financial traders exist. These traders do clever financial transactions that try to find the optimal price to purchase / sell shares. This reduces the variance. Some people question the wisdom of these sophisticated trading algorithms (rightly). However, they do have the effect of ensuring that anyone selling a stock at the wrong price runs the risk of being gamed. A perceptive trader can simply purchase the trade at the lower price, and sell it later in the day at a higher price. These transactions correct the price of the shares to the true market value. On most days, this significantly reduces price volatility.
This doesn't mean that you can't game public shares, it only means that the variance will be less and that whoever is gaming the share prices must by much more clever about it. Whereas for private shares, it is possible to do whatever the seller / buyer want.
Every numerical methods text involving a scientific math library has warnings about the array-transposition bug. Huge math optimization work has gone into dealing with it. The problem is much worse in modern super-computers than in the older computers. In the old computers, memory accesses were fairly predictable. New supercomputers are clusters of computers. Each node can only hold a small section of a large array, and communication time is often a function of both the distance between nodes in hops and total communication load (saturated interconnects).
Huge work goes into figuring out how to do array operations in a fast manner. The work often becomes highly application dependent. Find special short-cuts that apply to particular matrices that allow one to make use of special theorems.