If Microsoft's moves were harming Android adoption, the time to act would be now. If Google/Android loses handset manufacturer allegiance then it might be hard/impossible to regain it later.
Of course the reverse is true too - if Microsoft's shakedown of the handset manufacturers doesn't appear to be having much affect on Android usage, then why should Google care?
Another consideration is that Android truly might be infringing on Microsoft's patents, in which case there's not much short-term alternative to paying one way or another.
What they do in Phoenix, Arizona to cool out door areas is have tall hollow cooling towers with openings at top and bottom (at ground level), and something akin to blankets hanging at the top kept wet.
Hot air comes in at the top of the tower, cools via evaporation of the water, and therefore becomes heavier/denser and falls down the inside of the tower then comes out of the openings at the bottom under it's own momentum.
I guess in a country where labor is super cheap you could have humans keeping the "blankets" wet rather than using a water feed, if that was a construction issue.
The fact that people care about the out-of-box experience presumably reflects the fact that nowadays more people are interested in actually using Linux and not just playing with it (endlessly reconfiguring to get the ultimate desktop, etc).
While people don't reinstall their OS every week, I think most folks do reinstall Ubuntu relatively often - whenever there's a major release. Reinstall is always more reliable than potentially flakey upgrade.
Buy your last one first only makes sense where it will be your "last" one - i.e. something that you figure on keeping/using for a lot longer than most folks keep computers.
For stuff like computers that you're periodically updating, a better rule of thumb is buy the price/performance sweet spot, not the bleeding edge.
But what difference does it make having the latest/greatest vs a computer that's 3-5 years old? Games are the only thing where it may make a difference for any everyday application, and even there it's the graphics card that needs to be up-to-date, not the rest.
I live and breathe computers - soldered together my first 8-bitter in 1978, have been programming professionally since '82, and develop speech recognition/brain simulation software as a hobby.... BUT, I still only upgrade my computer when it'll get me a factor of 10x faster or if something fails, and even then I don't buy bleeding edge, which is a waste of money. When my mobo died last 5 months ago I got a Core i3 3GHz (with 8GB of RAM since it's ridiculously cheap, and in my application I do use lots of it).
In additition to the default Compiz-based Unity-3D interface, there's also an alternative Qt-based Unity-2D one, which I assume does not require OpenGL.
I've seen reviews saying that Unity-2D is much preferable, if you like the Unity interface in the first place.
Seems like Ubuntu have decided to abandon desktop Linux and go for the tablet market with Unity. Good luck to them... I guess I'll be switching to Linux Mint (Ubuntu based, but with traditional GNOME/KDE/Xfce desktop alternatives).
His "short form" birth certificate was released way back when he was a presidential candidate, and should have been enough for anybody (it was certainly enough to proive his citizenship to allow him to run).
The "long form" version has no more/less authority than the short form version - it was provided by the exact same agency in Hawaii. Getting the long form version released (an unusual request for which you require an specific reason) was really just political theater.
What next? Maybe Donald trump will deny that Hawaii is a legitimate US state, and demand that they produce paperwork to prove it? The man's a loon, as are the birthers. If you don't even trust your own government to check the eligibility of presidential candidates then why do you (anybody) even bother to vote or care about the process?!
Yes - artificial global demand (reserve, oil purchase use) for the US dollar does mean there's a large sponge to soak up the output of the US mints printing presses, but this is my no means a good thing.
US dollars ultimately are shares in America (even if in the short term currencies act as commodities or investment vehicles in their own right), and by printing more you're just diluting their value. It's going to lead to inflation, and possibly extremely bad inflation if (or rather when) that artificial demand (reserve, oil use) significantly dries up.
The US is totally dependent on other countries using our currency, because it creates demand for it thereby keeping it's value (hence purchasing power) high.
The best example of this is Oil which is almost universally priced in US dollars thereby forcing other countries to buy huge amounts of dollars to pay for it. If this ever stops, then watch out - the dollar will plummet and foreign goods will get a LOT more expensive (double, triple?). Note how oil-producing US adversaries such as Iraq, Iran and Venezuela have switched to the Euro to try to screw us.
Russia and Chna (especially) are large and growing economies... this isn't at all a positive thing for the US.
The density of dot pattern is necessarily regular (so that reflected displacements can be attributed to the surface they are projected onto). Given that it's a radial pattern (radiating outward in all directions from the source), what's fixed is essentially the angular seperation of the dots, from which some simple trig will give you the nominal seperation at any given distance from the camera, with any difference from that attributable to the angle (local depth difference) of the surface it's projected onto.
Of course a given dot displacement could be caused by a sharp angle close to the source or a less sharp one further away, but presumably they use the average displacment withing a region to guage approximate distance, and interpret any differences accordingly.
- Kinect doesn't have stereo cameras (it has an IR camera for depth perception and a visible light camera for other usage)
- Kinect doesn't use the visible light camera for body recognition. Recognition is based on the depth map provided by the IR grid projector and IR camera.
- Kinect doesn't operate like a laser rangefinder (it operates via structured light displacements, not via light pulse reflection times)
- Kinect doesn't track a wireframe (it tracks independent body parts)
How you got modded as "4 - informative" is beyond me. The blind leading the blind.
The way Kinect works is by projecting a dense evenly-spaced grid of IR dots (i.e. structured light) on the scene, then using it's IR camera (horizontally offset from the grid projector) to pick up the reflected dot pattern.
Due to depth differences in the scene, and the offset of the IR camera from the IR projector, the reflected dot pattern is not evenly spaced - the dots are horizontally displaced based on depth. To understand this, consider shining two parallel beams of light at a) a flat surface, and b) a surface angled at 45 degrees away from the light source. If you took a step sideways away from the light beams and looked at their reflections of the two objects, the dot (beam) separation on the flat surface would be the same as the true beam separation, but the dot separation on the angled surface would be increased. by an amount you could calculate using simple trig.
In order to operate in real-time with low cost, a dedicated chip processes the IR camera image and converts the dot displacements into the corresponding depth map.
The clever, and somewhat counter-intuitive, part is how Kinect then turns this depth map into a body part map. The basic idea is that it probabilistically maps local clusters of depths to body parts (via having been trained on a huge manually body-part-labelled image set), then converts these local probabilities into larger scale body part labels (i.e. if 60% of the local clusters in a region say "hand" , then the region is labelled as a hand). This way it doesn't track overall body postion or a wireframe, but rather independently tracks body parts (which is why it has no trouble correctly tracking muliple partially occluded people in frame).
There's no reference image involved. The IR camera is offset from IR projector, and therefore sees the horizontal dot displacements caused by differences in depth.
Back in the day Woz's crucial role in creating Apple was as a creative and accomplished electronics designer. Creating things like the Apple ][ color display or floppy controller with minimal chip counts, and thereby making the product more functional/compitetive than most of the competition.
However, the market niche that Apple has nowadays carved for itself isn't based on low cost or unique functionality (even if a wizard designer could nowadays make much difference), but rather based on design and user experience - coming from Job's design sensibility, obsessive attention to detail, and desire to sell "appliances", It's very much Jobs company, and presumably will flounder when he's no longer there.
What does Woz have to offer Apple nowadays? I'm sure there are other Apple executives that understand Apple's market niche way better than Woz does, and he's certainly no Jobs replacement as a marketeer - there doesn't appear to be a drop of slickness or aesthetic sensibility in his blood.
Advanced math is way over the head of 99.9% of the population, so in the same spirit we could say that math is based on faith for that (majority) portion of the population.
However, I'm not sure what the point of making such an observation is though, especially using the emotionally-charged term "faith" rather than the more neutral and better applicable term "trust".
Science isn't the same as religion. Science is not based on faith (or trust), but it goes without saying that if you're not smart enough to reproduce an experiment or test a theory yourself, then you do need to trust the results reported by others who are capable.
Yep - this is certainly a very impressive product. MIcrosoft have an absolutely world-class reseach lab/staff, but it seems rare so far for their work to make it into products (same as was the case with Xerox PARC).
Inheritance is just a tool, and needs to be used appropriately. It's a classic beginners mistake in C++ to think that classes should mostly inherit from each other - presumably because of some notion of that being the right C++/O-O way of designing things. Overuse of multiple inheritance (rarely useful) is even worse.
In reality most classes need not and should not inherit from each other - don't just create a hierarchy because you can or because you think you should. Inheritence should only be used when there's a real need - e.g. for polymorphism (baseclass with virtual methods), or to subclass a callback class to add context.
Most of the time (outside of textbook examples) you're not designing hierarchies but rather stand-alone classes.
The only real (and rare) use for multiple inheritance that comes to mind is polymorphism where you need a class to be able to variously be treated as more than one base class. If you using M-I just to inherit functionality you're probably better off just using composition.
C++ template programming has nothing to do with O-O - they are orthogonal techniques. Template programming is better referred to as generic programming - writing type-generic code that still provides type-safety (e.g. the C++ STL).
Well, programming "in the large" is for the most part beyond the scope of an undergrad course. If you're lucky you may do one final year project of sufficient complexity (e.g. write a toy compiler) that high level design becomes the key issue, but for the most part you're just going to be doing simple assignments.
Big projects, where you can experiment with design techniques, take time to implement, so there's no escaping the fact that this (high level design) is necessarily something that you're only (hopefully!) going to learn over an extended period of time after you graduate.
Not sure where that notion comes from, and I've been programming professionally for 30 years...
One of the earliest languages to encourage modular programming was Modula-2 (a successor to Pascal, popular in the early 80's), which defined a module as a collection of types, data and functions with a public definition similar to a C/C++ include file (bt withing a namespace), and a private implemention. Most C (not C++) programmers arrive at a similar style with a related collection (aka module) of types, functions etc defined by a header file with the corresponding implementation in a seperate.c file.
C++'s classes (or C#, or Java - all very similar) at the most basic level formalize this type of modular programming by collecting related types, functions etc together and separating the public interface (definition) from the private implementation. This is what modularization is all about - divide and conquor complexity by grouping of related functions together and seperating interface from the more complex implementation.
Of course O-O languages and design go beyond mere modularization, but still that's at their core, and to say that O-O design is anti-modular is ridiculous.
The objection of O-O programming being "anti-parallel" may have a sligght graiin of truth to it to the extent that parallel programming is still a very fluid field and imposing any other methodology does impose some structure that might not be helpful. However, modularization and O-O classes are not inherently anti-parallel by any means... classes that encapsulate and hide the implementation of parallelism from the user are a very powerful technique.
Why would you want to tax hybrids and other more fuel-efficient vehicles equally?!! That's totally non-progressive, as well as being expensive to implement,
Increase the gas tax - the US should be doing this anyway as a way to reduce demand, hence dependence on gas. I say this as the owner of a gas-guzzling SUV.. It's my choice and I'm happy to pay for it, and I'd also expect to benefit from lower costs if I chose to buy a more fuel efficient vehicle!
If folks want to believe in ghosts and want to pay people to check for them then why not? The service being provided is really just roleplay anyway... humoring the customers desire to believe in ghosts.
A smart service provider would report results based on the customers hope to prove/disprove the presence of ghosts.
Personally, my reading of GPLv2 tells me that simply including GPLv2 header files does not mean that your application must also be GPLv2 (otherwise a large part of the embedded market simply wouldn't exist). So I'm marking this one down as FUD.
Most applications don't include kernel (GPL) header files - they include glibc (LGPL) header files, which is why closed-source Linux apps are possible.
Yes, but that's a bit too simplistic.
If Microsoft's moves were harming Android adoption, the time to act would be now. If Google/Android loses handset manufacturer allegiance then it might be hard/impossible to regain it later.
Of course the reverse is true too - if Microsoft's shakedown of the handset manufacturers doesn't appear to be having much affect on Android usage, then why should Google care?
Another consideration is that Android truly might be infringing on Microsoft's patents, in which case there's not much short-term alternative to paying one way or another.
What they do in Phoenix, Arizona to cool out door areas is have tall hollow cooling towers with openings at top and bottom (at ground level), and something akin to blankets hanging at the top kept wet.
Hot air comes in at the top of the tower, cools via evaporation of the water, and therefore becomes heavier/denser and falls down the inside of the tower then comes out of the openings at the bottom under it's own momentum.
I guess in a country where labor is super cheap you could have humans keeping the "blankets" wet rather than using a water feed, if that was a construction issue.
The fact that people care about the out-of-box experience presumably reflects the fact that nowadays more people are interested in actually using Linux and not just playing with it (endlessly reconfiguring to get the ultimate desktop, etc).
While people don't reinstall their OS every week, I think most folks do reinstall Ubuntu relatively often - whenever there's a major release. Reinstall is always more reliable than potentially flakey upgrade.
They also had a "SHIT BURGERS" (in English) label on the fridge he got them out of! Has to be an old April fools joke.
Buy your last one first only makes sense where it will be your "last" one - i.e. something that you figure on keeping/using for a lot longer than most folks keep computers.
For stuff like computers that you're periodically updating, a better rule of thumb is buy the price/performance sweet spot, not the bleeding edge.
But what difference does it make having the latest/greatest vs a computer that's 3-5 years old? Games are the only thing where it may make a difference for any everyday application, and even there it's the graphics card that needs to be up-to-date, not the rest.
I live and breathe computers - soldered together my first 8-bitter in 1978, have been programming professionally since '82, and develop speech recognition/brain simulation software as a hobby.... BUT, I still only upgrade my computer when it'll get me a factor of 10x faster or if something fails, and even then I don't buy bleeding edge, which is a waste of money. When my mobo died last 5 months ago I got a Core i3 3GHz (with 8GB of RAM since it's ridiculously cheap, and in my application I do use lots of it).
Nah - the pilot is the *engine*. The fuel is his lunch.
I really hope this makes it to market. The projected price is a killer.
With the small size and low price, this would be awesome for low-cost robotics - maybe schools or FIRST could buy them in volume.
All you need to add is a small powered USB hub and then you can add a USB servo controller, bluetooth/wifi, camera etc.
In additition to the default Compiz-based Unity-3D interface, there's also an alternative Qt-based Unity-2D one, which I assume does not require OpenGL.
I've seen reviews saying that Unity-2D is much preferable, if you like the Unity interface in the first place.
Seems like Ubuntu have decided to abandon desktop Linux and go for the tablet market with Unity. Good luck to them... I guess I'll be switching to Linux Mint (Ubuntu based, but with traditional GNOME/KDE/Xfce desktop alternatives).
How did Obama handle this poorly?
His "short form" birth certificate was released way back when he was a presidential candidate, and should have been enough for anybody (it was certainly enough to proive his citizenship to allow him to run).
The "long form" version has no more/less authority than the short form version - it was provided by the exact same agency in Hawaii. Getting the long form version released (an unusual request for which you require an specific reason) was really just political theater.
What next? Maybe Donald trump will deny that Hawaii is a legitimate US state, and demand that they produce paperwork to prove it? The man's a loon, as are the birthers. If you don't even trust your own government to check the eligibility of presidential candidates then why do you (anybody) even bother to vote or care about the process?!
Yes - artificial global demand (reserve, oil purchase use) for the US dollar does mean there's a large sponge to soak up the output of the US mints printing presses, but this is my no means a good thing.
US dollars ultimately are shares in America (even if in the short term currencies act as commodities or investment vehicles in their own right), and by printing more you're just diluting their value. It's going to lead to inflation, and possibly extremely bad inflation if (or rather when) that artificial demand (reserve, oil use) significantly dries up.
That's not at all true.
The US is totally dependent on other countries using our currency, because it creates demand for it thereby keeping it's value (hence purchasing power) high.
The best example of this is Oil which is almost universally priced in US dollars thereby forcing other countries to buy huge amounts of dollars to pay for it. If this ever stops, then watch out - the dollar will plummet and foreign goods will get a LOT more expensive (double, triple?). Note how oil-producing US adversaries such as Iraq, Iran and Venezuela have switched to the Euro to try to screw us.
Russia and Chna (especially) are large and growing economies... this isn't at all a positive thing for the US.
The density of dot pattern is necessarily regular (so that reflected displacements can be attributed to the surface they are projected onto). Given that it's a radial pattern (radiating outward in all directions from the source), what's fixed is essentially the angular seperation of the dots, from which some simple trig will give you the nominal seperation at any given distance from the camera, with any difference from that attributable to the angle (local depth difference) of the surface it's projected onto.
Of course a given dot displacement could be caused by a sharp angle close to the source or a less sharp one further away, but presumably they use the average displacment withing a region to guage approximate distance, and interpret any differences accordingly.
No - wrong on all counts.
- Kinect doesn't have stereo cameras (it has an IR camera for depth perception and a visible light camera for other usage)
- Kinect doesn't use the visible light camera for body recognition. Recognition is based on the depth map provided by the IR grid projector and IR camera.
- Kinect doesn't operate like a laser rangefinder (it operates via structured light displacements, not via light pulse reflection times)
- Kinect doesn't track a wireframe (it tracks independent body parts)
How you got modded as "4 - informative" is beyond me. The blind leading the blind.
The way Kinect works is by projecting a dense evenly-spaced grid of IR dots (i.e. structured light) on the scene, then using it's IR camera (horizontally offset from the grid projector) to pick up the reflected dot pattern.
Due to depth differences in the scene, and the offset of the IR camera from the IR projector, the reflected dot pattern is not evenly spaced - the dots are horizontally displaced based on depth. To understand this, consider shining two parallel beams of light at a) a flat surface, and b) a surface angled at 45 degrees away from the light source. If you took a step sideways away from the light beams and looked at their reflections of the two objects, the dot (beam) separation on the flat surface would be the same as the true beam separation, but the dot separation on the angled surface would be increased. by an amount you could calculate using simple trig.
In order to operate in real-time with low cost, a dedicated chip processes the IR camera image and converts the dot displacements into the corresponding depth map.
The clever, and somewhat counter-intuitive, part is how Kinect then turns this depth map into a body part map. The basic idea is that it probabilistically maps local clusters of depths to body parts (via having been trained on a huge manually body-part-labelled image set), then converts these local probabilities into larger scale body part labels (i.e. if 60% of the local clusters in a region say "hand" , then the region is labelled as a hand). This way it doesn't track overall body postion or a wireframe, but rather independently tracks body parts (which is why it has no trouble correctly tracking muliple partially occluded people in frame).
There's no reference image involved. The IR camera is offset from IR projector, and therefore sees the horizontal dot displacements caused by differences in depth.
Back in the day Woz's crucial role in creating Apple was as a creative and accomplished electronics designer. Creating things like the Apple ][ color display or floppy controller with minimal chip counts, and thereby making the product more functional/compitetive than most of the competition.
However, the market niche that Apple has nowadays carved for itself isn't based on low cost or unique functionality (even if a wizard designer could nowadays make much difference), but rather based on design and user experience - coming from Job's design sensibility, obsessive attention to detail, and desire to sell "appliances", It's very much Jobs company, and presumably will flounder when he's no longer there.
What does Woz have to offer Apple nowadays? I'm sure there are other Apple executives that understand Apple's market niche way better than Woz does, and he's certainly no Jobs replacement as a marketeer - there doesn't appear to be a drop of slickness or aesthetic sensibility in his blood.
Advanced math is way over the head of 99.9% of the population, so in the same spirit we could say that math is based on faith for that (majority) portion of the population.
However, I'm not sure what the point of making such an observation is though, especially using the emotionally-charged term "faith" rather than the more neutral and better applicable term "trust".
Science isn't the same as religion. Science is not based on faith (or trust), but it goes without saying that if you're not smart enough to reproduce an experiment or test a theory yourself, then you do need to trust the results reported by others who are capable.
Yep - this is certainly a very impressive product. MIcrosoft have an absolutely world-class reseach lab/staff, but it seems rare so far for their work to make it into products (same as was the case with Xerox PARC).
Inheritance is just a tool, and needs to be used appropriately. It's a classic beginners mistake in C++ to think that classes should mostly inherit from each other - presumably because of some notion of that being the right C++/O-O way of designing things. Overuse of multiple inheritance (rarely useful) is even worse.
In reality most classes need not and should not inherit from each other - don't just create a hierarchy because you can or because you think you should. Inheritence should only be used when there's a real need - e.g. for polymorphism (baseclass with virtual methods), or to subclass a callback class to add context.
Most of the time (outside of textbook examples) you're not designing hierarchies but rather stand-alone classes.
The only real (and rare) use for multiple inheritance that comes to mind is polymorphism where you need a class to be able to variously be treated as more than one base class. If you using M-I just to inherit functionality you're probably better off just using composition.
C++ template programming has nothing to do with O-O - they are orthogonal techniques. Template programming is better referred to as generic programming - writing type-generic code that still provides type-safety (e.g. the C++ STL).
Well, programming "in the large" is for the most part beyond the scope of an undergrad course. If you're lucky you may do one final year project of sufficient complexity (e.g. write a toy compiler) that high level design becomes the key issue, but for the most part you're just going to be doing simple assignments.
Big projects, where you can experiment with design techniques, take time to implement, so there's no escaping the fact that this (high level design) is necessarily something that you're only (hopefully!) going to learn over an extended period of time after you graduate.
Well, I you need to familarize yourself with the available tools before you're in a position to choose which tool is best for the job.
These single focusfunctional/imperative/O-O programming classes are teaching tools (techniques), not tool selection.
Not sure where that notion comes from, and I've been programming professionally for 30 years...
One of the earliest languages to encourage modular programming was Modula-2 (a successor to Pascal, popular in the early 80's), which defined a module as a collection of types, data and functions with a public definition similar to a C/C++ include file (bt withing a namespace), and a private implemention. Most C (not C++) programmers arrive at a similar style with a related collection (aka module) of types, functions etc defined by a header file with the corresponding implementation in a seperate .c file.
C++'s classes (or C#, or Java - all very similar) at the most basic level formalize this type of modular programming by collecting related types, functions etc together and separating the public interface (definition) from the private implementation. This is what modularization is all about - divide and conquor complexity by grouping of related functions together and seperating interface from the more complex implementation.
Of course O-O languages and design go beyond mere modularization, but still that's at their core, and to say that O-O design is anti-modular is ridiculous.
The objection of O-O programming being "anti-parallel" may have a sligght graiin of truth to it to the extent that parallel programming is still a very fluid field and imposing any other methodology does impose some structure that might not be helpful. However, modularization and O-O classes are not inherently anti-parallel by any means... classes that encapsulate and hide the implementation of parallelism from the user are a very powerful technique.
Why would you want to tax hybrids and other more fuel-efficient vehicles equally?!! That's totally non-progressive, as well as being expensive to implement,
Increase the gas tax - the US should be doing this anyway as a way to reduce demand, hence dependence on gas. I say this as the owner of a gas-guzzling SUV.. It's my choice and I'm happy to pay for it, and I'd also expect to benefit from lower costs if I chose to buy a more fuel efficient vehicle!
If folks want to believe in ghosts and want to pay people to check for them then why not? The service being provided is really just roleplay anyway... humoring the customers desire to believe in ghosts.
A smart service provider would report results based on the customers hope to prove/disprove the presence of ghosts.
Personally, my reading of GPLv2 tells me that simply including GPLv2 header files does not mean that your application must also be GPLv2 (otherwise a large part of the embedded market simply wouldn't exist). So I'm marking this one down as FUD.
Most applications don't include kernel (GPL) header files - they include glibc (LGPL) header files, which is why closed-source Linux apps are possible.