A big problem is that C and C++ don't have real multidimensional arrays. There are arrays of arrays, and fixed-sized multidimensional arrays, but not general multidimensional arrays.
FORTRAN was designed from the beginning to support multidimensional arrays efficiently. They can be declared, passed to subroutines, and iterated over efficiently along any axis. The compilers know a lot about the properties of arrays, allowing efficient vectorization, parallization, and subscript optimization.
C people do not get this. There have been a few attempts to bolt multidimensional arrays as parameters or local variables onto C, (mostly in C99) but they were incompatible with C++, Microsoft refused to implement them, and they're deprecated in the latest revision of C.
Go isn't any better. I spent some time trying to convince the Go crowd to support multdimensional arrays properly. But the idea got talked to death and lost under a pile of little-used nice features.
Here's a a critique. (It's on arxiv; no need to sign up for "Medium")
The paper isn't impressive. It make the assumption that human (other mammals, too?) memory isn't compressed, and is somehow "integrated" with all other information. We've been through this before. Last time, the buzzword was "holographic". We've been here before.
The observation that damage to part of the brain may not result in the loss of specific memories still seems to confuse many philosophers and neurologists. That shouldn't be mysterious at this point. A compact disk has the same property. You can obscure a sizeable area on a CD without making it unreadable. There's redundancy in the data, but it's a lot less than 2x redundant. The combination of error correction and spreading codes allows any small part of the disk to be unreadable without losing any data. (Read up on how CDs work if you don't know this. It's quite clever. First mass-market application of really good error correction.)
SF used to have homeless people selling parking spaces. You'd see guys standing in empty parking spaces, waving you in, and expecting to be paid. That's been stopped; it's extortion.
So you need a computer, or at least a power supply with a USB port, to power a heater and motor? I have some doubts about the thing being cool enough to hold, too. Your fingers are about 3mm from a 180C heat source.
3D Doodler already has one of these things. Theirs seems to work, although they speed up the video too. For both, the results look like Silly String.
The article had no thesis, and really was just mindless rambling.
Agreed. The ad-driven tech bubble will burst at some point, but not for any of those reasons.
Bank of America was bought by North Carolina National Bank in 1998. So that issue was 16 years ago. SF has a sizable homeless population because SF isn't that homeless-hostile. Compare San Diego.
Earthquakes are a real worry. SF prepares for them. All new buildings get serious reinforcement, and most of the old ones have been retrofitted. All through SF, you see huge diagonal steel braces in buildings. (In some retrofits, these block windows.) The San Francisco Bay Bridge from the island to Oakland was completely replaced because one short section broke in the 1989 earthquake. The Golden Gate Bridge was reinforced in the 1950s. Freeway supports are huge compared to what you see in the rest of the country, and many that were not damaged at all by the 1989 quake were beefed up. Now SF is starting a mandatory earthquake retrofit program for wood-frame buildings with 5 or more dwelling units. Unreinforced masonry buildings (i.e. brick) were dealt with years ago; there were about 2000 in 1990, and all but 125 have been reinforced or torn down. That's definitely a problem that's not being ignored.
I'd suggest knowing more history rather than more literature.
Russia's advance into Ukraine is much like Germany moving into Poland in 1939. This is a very big deal. Yet it isn't even on the front page of CNN today. It's a one-line entry on Fox. On Reuters, it's the top story.
The technology in question is the "magazine safety". It blocks the trigger press unless a magazine is fully inserted.
A magazine safety isn't for "gun grab" protection. It's to prevent a supposedly unloaded weapon from firing when there's still a round in the chamber. California requires it on new handguns. Prevents the "But I didn't know it was loaded" problem.
The U.S. Army often puts a barrel of sand outside mess halls and such in war zones. Entering the area, soldiers must unload their weapon, then try to fire it into the sand barrel. For a large mess hall, about once a day, on average, "bang".
When Col. Dave Hackworth was working on the Army's project to replace the 1911A1, he discovered that, over the Army's history of that weapon, it had killed more US troops through accidents than enemy. Sidearms are carried by troops who don't plan to use them. If you expect to need a weapon, you take something bigger. So the Army really wants sidearms that don't go off by accident.
it's an old idea, but worth trying now because electric power conversion works very well now. This thing generates AC at some variable frequency and voltage depending on fuel flow and load. The waveform that comes out is awful. (See the article). Two successive cycles can be quite different. There's no flywheel or rotating mass to smooth out the motion.
Today, converting that irregular electrical output into something more consistent is straightforward. The output is going to be fed into some kind of switching power supply, probably with an ultracapacitor to smooth things out. This beats trying to stablize the thing mechanically.
Example from article: "Privateness has not been and undoubtedly never will be lauded, precarious, and decent.".
There are too many comments on news sites which read like that.
A better LIDAR sensor is needed. Something more like the Advanced Scientific Concepts flash LIDAR. Right now, it costs too much (about $100K) but that's because they're hand-made in Santa Barbara for DoD and space applications. It has custom ICs made in volumes of tens. Volume production would bring that way down. You don't get the full circle field of view of the Velodyne, so it may take multiple sensors.
To deal with rain and snow, you need "first and last" return data. This is used in air to ground sensing to sense both the top of tree cover and the ground underneath. With that, and a good frame rate, you'll be able to distinguish rain and snow noise from solid objects. You'll lose range in heavy rain and snow, and will have to slow down. That's OK; humans can't see through it either.
Radars can. What's Google doing on the radar front? Off the shelf automotive radars are getting pretty good. Modern millimeter radars can see pedestrians. The older units from the Grand Challenge days could only see car-sized obstacles, maybe motorcycles.
- Overall, there are many, *many* programs out there that, justifiably, do not use threads at all. To require these programs to incur the overhead associated with threading even though they don't use it, seems a bit much.
That's why threading needs language support. The compiler can identify many objects that are not being shared across thread boundaries, and optimize out locking. Libraries can't do that; they can't do global analysis.
This is also true of subscript checking. Most subscript checks can be optimized out, if the compiler knows they're subscript checks. This is especially true of inner loops, where most subscript checks can be hoisted to the top of the loop, and often optimized out entirely. But compilers have to be allowed to report subscript out of range conditions "early" for this to work. That is, if a FOR loop is going to overflow an array, the compiler has to be allowed to report it at the start of the loop, instead of being required to execute all the iterations up to the buffer overflow and then report it.
One of the Go compilers does that subscript checking optimization.
It's frustrating. Functional programming is painful when you actually have to do something, not just compute some result. But the real problem is older. We never got concurrency right in imperative languages.
Classic pthread-type concurrency suffers from the problem that the language has no idea what's locked by a lock. This problem is in C, wasn't fixed in C++, and isn't even fixed properly in Go. It was addressed more seriously in Modula and Ada, where the language knew which variables where shared and which were not. The Ada rendezvous approach was too limiting for anything otther than hard real-time, but it was on the right track.
Java addressed this with synchronized objects. This was a step in the right direction. The basic concept of a synchronized object is that, when executing a method of the object, nothing else can affect the state of the object. Java's synchronized objects don't quite get that right - you can call out of an object, then back into it, from within the same thread. This can break the object's invariant, in that the callback function is entered while the object is not in its stable, nobody-inside state. This is a classic cause of trouble in GUI systems, which involve lots of objects calling each other through dynamically changing collections. (If some unusual order of clicks crashes a program, there's a good chance the bug is of this type.)
The inside/outside issue for state protected by locks is a big one. This also comes up when a thread blocks. Many programs have sections where a thread unlocks a lock, blocks, then relocks the lock. This constitutes control leaving the block, but the compiler doesn't understand this. There's no syntax that says "I am now leaving this object to wait", with the language checks to insure that no internal object state gets passed to the code outside the object. The Spec# group at Microsoft (Spec# is a proof of correctness project using a form of C#) attacked this problem, and came up with a solution of sorts, but it never went mainstream. It's hard to fix this with a language bolt-on.
Objects ought to be either immutable, synchronized, or part of something that's synchronized. Then you're safe from low level race conditions. (You can still deadlock. However, deadlock bugs tend to be detectable and repeatable, unlike race condition bugs. So they get caught and fixed.) if this is built into the language, the compiler can check and optimize. Compilers are good at catching things like a local variable being passed to something that might save a reference to it and mess with it concurrently. Humans suck at that. Machines are good at global analysis of big data.
I had great hopes that the Go crowd would have a solution. They claim to, but there's a lot of hand-waving. They claim "share by communicating, not by sharing memory", but the examples in "Effective Go" all share memory. It's also really easy to share memory between goroutines in Go inadvertantly, because slices and dicts are reference objects. Pass them through a pipe and you've shared data and can have race conditions. The problem is bad enough that Google AppEngine limits Go programs to one thread.
Mixed functional/imperative programming has all these problems, plus the illusion that the problem has been solved. It hasn't.
After a long history of failures, from Hamburger Helper to VitaPro, this stuff apparently tastes more or less like processed chicken. It's sold at Whole Foods. It's not cheap.
Chicken tends to be chopped up and extruded anyway. ("McNuggets"). Matching the taste of breaded chicken nuggets seems do-able.
Nutrition is an issue. The nutritional composition of this is entirely determined by the manufacturer. The mix of proteins, carbohydrates, vitamins, and minerals is a manufacturer choice. There are few standards on the required nutritional value for human food products. Most concerns about food safety involve excluding undesired or toxic components. It's quite possible to sell something that tastes like meat, is harmless, but has little nutritional value.
On the contrary, if we flatline our population at a low enough level, we can maintain a high tech society indefinitely on this planet.
Possibly, but estimates of that number tend to be below 1 billion. The world population is expected to peak around 2050 at 8.7 billion, and decline to 8 billion by 2100. Remember, most of the developed world is already below replacement rate.
The future may involve a lot more biotechnology, which isn't that resource intensive, and a lot less mining, refining, smelting, heavy manufacturing, and long distance transport. That means less of the resources required for space travel.
Slashdot Mirror
A big problem is that C and C++ don't have real multidimensional arrays. There are arrays of arrays, and fixed-sized multidimensional arrays, but not general multidimensional arrays.
FORTRAN was designed from the beginning to support multidimensional arrays efficiently. They can be declared, passed to subroutines, and iterated over efficiently along any axis. The compilers know a lot about the properties of arrays, allowing efficient vectorization, parallization, and subscript optimization.
C people do not get this. There have been a few attempts to bolt multidimensional arrays as parameters or local variables onto C, (mostly in C99) but they were incompatible with C++, Microsoft refused to implement them, and they're deprecated in the latest revision of C.
Go isn't any better. I spent some time trying to convince the Go crowd to support multdimensional arrays properly. But the idea got talked to death and lost under a pile of little-used nice features.
Here's a a critique. (It's on arxiv; no need to sign up for "Medium")
The paper isn't impressive. It make the assumption that human (other mammals, too?) memory isn't compressed, and is somehow "integrated" with all other information. We've been through this before. Last time, the buzzword was "holographic". We've been here before.
The observation that damage to part of the brain may not result in the loss of specific memories still seems to confuse many philosophers and neurologists. That shouldn't be mysterious at this point. A compact disk has the same property. You can obscure a sizeable area on a CD without making it unreadable. There's redundancy in the data, but it's a lot less than 2x redundant. The combination of error correction and spreading codes allows any small part of the disk to be unreadable without losing any data. (Read up on how CDs work if you don't know this. It's quite clever. First mass-market application of really good error correction.)
SF used to have homeless people selling parking spaces. You'd see guys standing in empty parking spaces, waving you in, and expecting to be paid. That's been stopped; it's extortion.
So is this.
So you need a computer, or at least a power supply with a USB port, to power a heater and motor? I have some doubts about the thing being cool enough to hold, too. Your fingers are about 3mm from a 180C heat source.
3D Doodler already has one of these things. Theirs seems to work, although they speed up the video too. For both, the results look like Silly String.
The article had no thesis, and really was just mindless rambling.
Agreed. The ad-driven tech bubble will burst at some point, but not for any of those reasons.
Bank of America was bought by North Carolina National Bank in 1998. So that issue was 16 years ago. SF has a sizable homeless population because SF isn't that homeless-hostile. Compare San Diego.
Earthquakes are a real worry. SF prepares for them. All new buildings get serious reinforcement, and most of the old ones have been retrofitted. All through SF, you see huge diagonal steel braces in buildings. (In some retrofits, these block windows.) The San Francisco Bay Bridge from the island to Oakland was completely replaced because one short section broke in the 1989 earthquake. The Golden Gate Bridge was reinforced in the 1950s. Freeway supports are huge compared to what you see in the rest of the country, and many that were not damaged at all by the 1989 quake were beefed up. Now SF is starting a mandatory earthquake retrofit program for wood-frame buildings with 5 or more dwelling units. Unreinforced masonry buildings (i.e. brick) were dealt with years ago; there were about 2000 in 1990, and all but 125 have been reinforced or torn down. That's definitely a problem that's not being ignored.
I'm calling bullshit on that unless you have a citation.
It's in his autobiography, "About Face".
I'd suggest knowing more history rather than more literature.
Russia's advance into Ukraine is much like Germany moving into Poland in 1939. This is a very big deal. Yet it isn't even on the front page of CNN today. It's a one-line entry on Fox. On Reuters, it's the top story.
The technology in question is the "magazine safety". It blocks the trigger press unless a magazine is fully inserted.
A magazine safety isn't for "gun grab" protection. It's to prevent a supposedly unloaded weapon from firing when there's still a round in the chamber. California requires it on new handguns. Prevents the "But I didn't know it was loaded" problem.
The U.S. Army often puts a barrel of sand outside mess halls and such in war zones. Entering the area, soldiers must unload their weapon, then try to fire it into the sand barrel. For a large mess hall, about once a day, on average, "bang".
When Col. Dave Hackworth was working on the Army's project to replace the 1911A1, he discovered that, over the Army's history of that weapon, it had killed more US troops through accidents than enemy. Sidearms are carried by troops who don't plan to use them. If you expect to need a weapon, you take something bigger. So the Army really wants sidearms that don't go off by accident.
Is this a new movie, or a re-release of Spider-Man 2 from 2004? I thought this was just the 2004 version, run through 3D conversion.
it's an old idea, but worth trying now because electric power conversion works very well now. This thing generates AC at some variable frequency and voltage depending on fuel flow and load. The waveform that comes out is awful. (See the article). Two successive cycles can be quite different. There's no flywheel or rotating mass to smooth out the motion.
Today, converting that irregular electrical output into something more consistent is straightforward. The output is going to be fed into some kind of switching power supply, probably with an ultracapacitor to smooth things out. This beats trying to stablize the thing mechanically.
Example from article: "Privateness has not been and undoubtedly never will be lauded, precarious, and decent.". There are too many comments on news sites which read like that.
This isn't teaching computer science. This is teaching web site business logic implementation. That's a useful skill, but somewhat specialized.
You can get the price of every crap pink sheet stock on a Bloomberg terminal. It's not an endorsement of an investment.
Cute little box, but kind of expensive.
A better LIDAR sensor is needed. Something more like the Advanced Scientific Concepts flash LIDAR. Right now, it costs too much (about $100K) but that's because they're hand-made in Santa Barbara for DoD and space applications. It has custom ICs made in volumes of tens. Volume production would bring that way down. You don't get the full circle field of view of the Velodyne, so it may take multiple sensors.
To deal with rain and snow, you need "first and last" return data. This is used in air to ground sensing to sense both the top of tree cover and the ground underneath. With that, and a good frame rate, you'll be able to distinguish rain and snow noise from solid objects. You'll lose range in heavy rain and snow, and will have to slow down. That's OK; humans can't see through it either.
Radars can. What's Google doing on the radar front? Off the shelf automotive radars are getting pretty good. Modern millimeter radars can see pedestrians. The older units from the Grand Challenge days could only see car-sized obstacles, maybe motorcycles.
Solved problem. See 2005 DARPA Grand Challenge. Dirt roads with no guardrails, no problem.
NASA, doing what they do best - issuing press releases.
sometimes you want to go outside while maintaining the lock.
That's OK. What's not OK is coming back in.
This is difficult to get right, which is why pthreads offer "recursive locks". Go doesn't.
- Overall, there are many, *many* programs out there that, justifiably, do not use threads at all. To require these programs to incur the overhead associated with threading even though they don't use it, seems a bit much.
That's why threading needs language support. The compiler can identify many objects that are not being shared across thread boundaries, and optimize out locking. Libraries can't do that; they can't do global analysis.
This is also true of subscript checking. Most subscript checks can be optimized out, if the compiler knows they're subscript checks. This is especially true of inner loops, where most subscript checks can be hoisted to the top of the loop, and often optimized out entirely. But compilers have to be allowed to report subscript out of range conditions "early" for this to work. That is, if a FOR loop is going to overflow an array, the compiler has to be allowed to report it at the start of the loop, instead of being required to execute all the iterations up to the buffer overflow and then report it.
One of the Go compilers does that subscript checking optimization.
It's frustrating. Functional programming is painful when you actually have to do something, not just compute some result. But the real problem is older. We never got concurrency right in imperative languages.
Classic pthread-type concurrency suffers from the problem that the language has no idea what's locked by a lock. This problem is in C, wasn't fixed in C++, and isn't even fixed properly in Go. It was addressed more seriously in Modula and Ada, where the language knew which variables where shared and which were not. The Ada rendezvous approach was too limiting for anything otther than hard real-time, but it was on the right track.
Java addressed this with synchronized objects. This was a step in the right direction. The basic concept of a synchronized object is that, when executing a method of the object, nothing else can affect the state of the object. Java's synchronized objects don't quite get that right - you can call out of an object, then back into it, from within the same thread. This can break the object's invariant, in that the callback function is entered while the object is not in its stable, nobody-inside state. This is a classic cause of trouble in GUI systems, which involve lots of objects calling each other through dynamically changing collections. (If some unusual order of clicks crashes a program, there's a good chance the bug is of this type.)
The inside/outside issue for state protected by locks is a big one. This also comes up when a thread blocks. Many programs have sections where a thread unlocks a lock, blocks, then relocks the lock. This constitutes control leaving the block, but the compiler doesn't understand this. There's no syntax that says "I am now leaving this object to wait", with the language checks to insure that no internal object state gets passed to the code outside the object. The Spec# group at Microsoft (Spec# is a proof of correctness project using a form of C#) attacked this problem, and came up with a solution of sorts, but it never went mainstream. It's hard to fix this with a language bolt-on.
Objects ought to be either immutable, synchronized, or part of something that's synchronized. Then you're safe from low level race conditions. (You can still deadlock. However, deadlock bugs tend to be detectable and repeatable, unlike race condition bugs. So they get caught and fixed.) if this is built into the language, the compiler can check and optimize. Compilers are good at catching things like a local variable being passed to something that might save a reference to it and mess with it concurrently. Humans suck at that. Machines are good at global analysis of big data.
I had great hopes that the Go crowd would have a solution. They claim to, but there's a lot of hand-waving. They claim "share by communicating, not by sharing memory", but the examples in "Effective Go" all share memory. It's also really easy to share memory between goroutines in Go inadvertantly, because slices and dicts are reference objects. Pass them through a pipe and you've shared data and can have race conditions. The problem is bad enough that Google AppEngine limits Go programs to one thread.
Mixed functional/imperative programming has all these problems, plus the illusion that the problem has been solved. It hasn't.
Another vulnerability due to C's poor handling of pointers.
A material that does this has been sold in the US since 2013. The consumer version is Rust-Oleum Never-Wet. When new, the surface really will not retain water or mud. But the Rust-Oleum product doesn't provide a tough surface, and the effect doesn't last if the surface is touched or rubbed much.
It might make sense for cars. For this to work, you need a surface that you want clean, gets dirty, but isn't a working surface. That's a car body.
After a long history of failures, from Hamburger Helper to VitaPro, this stuff apparently tastes more or less like processed chicken. It's sold at Whole Foods. It's not cheap. Chicken tends to be chopped up and extruded anyway. ("McNuggets"). Matching the taste of breaded chicken nuggets seems do-able.
Nutrition is an issue. The nutritional composition of this is entirely determined by the manufacturer. The mix of proteins, carbohydrates, vitamins, and minerals is a manufacturer choice. There are few standards on the required nutritional value for human food products. Most concerns about food safety involve excluding undesired or toxic components. It's quite possible to sell something that tastes like meat, is harmless, but has little nutritional value.
Ball screws are available on Amazon, Alibaba, etc. Prices on Alibaba start around $25.
On the contrary, if we flatline our population at a low enough level, we can maintain a high tech society indefinitely on this planet.
Possibly, but estimates of that number tend to be below 1 billion. The world population is expected to peak around 2050 at 8.7 billion, and decline to 8 billion by 2100. Remember, most of the developed world is already below replacement rate.
The future may involve a lot more biotechnology, which isn't that resource intensive, and a lot less mining, refining, smelting, heavy manufacturing, and long distance transport. That means less of the resources required for space travel.