Resolution of the film is limited to resolution of the scanner, unless that negative is all that you will ever need.
My cheapo Epson negative scanner will handle up to 12,000 dots per inch. The largest negatives I'm dealing with are around 3" x 3.5". This gives me a theoretical resolution of 36,000 x 42,000 (1.512 gigapixels). Since there are many better scanners and many larger film formats, this cannot be considered the upper end.
Ultimately, all cameras (digital or otherwise) are limited by the lenses. A foot square negative plate with a low-grade lens will capture no information not available with a much smaller negative and the same lens.
CCDs have one major problem - most are accessed serially. This means the time interval you're reading for the first pixel is NOT the same as the time interval for the last pixel. This doesn't matter for small CCDs - the number of high-energy particles and photons that can get through the shutter over a very small time interval is insignificant. Even so, scientific CCD devices will take background readings before and after, then adjust. If you were to build a 1.5 gigapixel CCD, that difference is going to become more significant. You can build cameras that compensate, but that is going to add to the price.
Film is parallel. So whatever the background levels, it will affect the film evenly. Well, unless there's a radioactive source in the room.
The next problem is the ADC. Technically, here digital should be far better than film. You can certainly get 24-bit ADCs and although film is analogue, it is not truly continuous. The reality, though, is that a lot of digital cameras use 8-bit ADCs per colour, which film can certainly beat without breaking into a sweat.
Yes, digital cameras have a great many advantages and -could- be better in every area. My point is not that digital is "bad" (it isn't) but that film still has an edge in certain domains and that within those domains the correct choice is always to go with what is currently best. Eventually, 3CCD cameras with 24-bit ADCs and 1.5 gigabit CCDs will become the norm. Those will be so far beyond anything film could realistically achieve that digital will then be absolutely ideal.
For now, digital is "correct" for general home usage, where massive numbers of pictures is more important than a few great images. But general home users aren't the only ones who want cameras.
No, film is extremely valuable because there are markets that digital CANNOT operate in at present and are unlikely to operate in in the foreseeable future. Kodak should have worked more in those niches and less in the trashy markets.
Many of the Japanese companies that are currently very profitable and successful have existed for hundreds of years. At least two are around 1,500 years old.
Companies don't need to be immortal, but they don't need to be mortal either. Companies aren't "alive", aren't "people" and aren't subject to decay. They are systems.
Yes, that is true. But it's for a very stupid reason. To buy a digital camera that has the resolution of a film camera still costs many thousands of dollars. To buy one that also has the dynamic range is even more costly That is unlikely to change within the next decade. (The odds of being able to buy a digital camera with a sensor large enough to compete with medium format film, never mind large format, is practically zero.)
As for longevity of media - I am currently working through family archives of negatives going back to 1909. Is your flash card guaranteed to hold data 103+ years?
You could argue that most people don't care about quality that high or longevity that great. That is true, but those same people are happy to bitch about the crappy quality of archival material that does interest them. I don't know if the irony is lost on them (the photos they are taking will be someone else's archival material) or if they just don't give a flying about how much it'll seriously bother other people.
Agreed, but with one proviso -- most people are incredibly lazy. There MUST be a distinction between cases:
What needs protecting (IMHO):
Conserving material that the studios and/or holding companies destroy (or incompetently archive)
Taking existing material (eg: software) and either improving upon it or reusing it in some way
Taking existing material and using it for educational purposes (and this can include introducing people to new ideas, new directions, etc)
Copying material for genuinely therapeutic reasons
"Incidental" distribution (eg: radio up too loud, installing software on a shared computer, etc, where violations are more technical than real)
Research
Access to material otherwise restricted for prejudicial/political purposes (ie: no rational intent and no interest in rational discussion)
What should NOT be protected:
Rebranding of identical products (particularly if the constraints are more onerous)
Theft for the purpose of inflicting harm on the author(s)/artist(s) -- note: nothing here about publishing companies or studios
Theft for the purpose of inflicting harm on the audience -- note: still nothing here about publishing companies or studios
Theft for the purpose of avoiding originality
I'd abolish copyright, trademark and patent laws, then create a single, standardized system that actually tried to achieve the effect that is supposed to be intended.
1) No, only some map the model direct to disk. Oh, and except on one or two very primitive databases, views aren't mapped into a physical form on disk. MySQL only does so when you tell it to use a storage engine that allows you to map the model that way AND you configure it to. In the example you gave, you could use 1 table and 1 view (or, indeed, 1 table and 1 table-returning function) for almost every relational database out there. More sophisticated databases will let you generate an index from a function and order the table through an index. You still have the view/function, but you don't have to access anything through it for your example.
NoSQL databases can use any underlying structure (relational, hierarchical, flat file, object-oriented, etc), although they are more often coded as flat file. From Wikipedia:
Carlo Strozzi used the term NoSQL in 1998 to name his lightweight, open-source relational database that did not expose the standard SQL interface.
No, you don't lay them out. You have absolutely bugger all idea where Memcached or MungoDB has put your data - it could be in any file on any disk in any computer in the database structure.
2) SQL is nothing more than a wrapper. NotallexistingrelationaldatabasesuseSQL. And those that do - well, which SQL are you referring to? ANSI? T-SQL? Some other kind?
SQL isn't, however, restricted to relational databases. Ingres is not a relational database, it is a star database. Ingres uses SQL. Well, at least as one option.
3) I've never had any problems refactoring a database live. But, then, I use design tools. Which prevent me from needing to refactor in the first place by making it easy to design things correctly to begin with. That's the great thing about being a software engineer/computer scientist/database admin/system admin -- I know all about the RASDIT methodology and know how to apply it in everyday activities. I pity the poor sods who try to code blind and have to do any refactoring at all. A good design is so easy to create, so easy to implement and a wondrous thing to maintain.
It is a non-issue. Even in the debates over whether the Y chromosome was decaying, those supporting the idea that it did pointed to the fact that not all species with genders even use X and Y chromosomes, clearly demonstrating that the Y chromosome isn't that important even to the "male" gender. Alternative genes can and do emerge.
It was also noted that the Y chromosome is mostly non-coding DNA anyway. The Y is essentially a malformed X chromosome with almost everything the X does ripped out and a very small bit of extra coding added in. The main benefit the Y chromosome offers is a means to do family history via DNA sequencing companies. Since we know that regions of DNA can be switched on and off via soft-coding (the epigenome) and that DNA can also be reorganized on-the-fly (transposons), the coding regions of the Y could be pushed into the X and then activated/deactivated as needed. In the case of the San Fernando Valley, this has apparently already happened.
I would argue that the X chromosome is too heavily loaded and isn't subject to enough mutations, so some deliberate refactoring of the X and Y might actually be a very good thing. A third gender, preferably female with a desire for geeks, would be helpful.
There are permutations of the concepts in database theory that have not been tried, at least not that I know of, but NoSQL and this NoSQL 2.0 idea are not amongst them.
A truly novel combination of existing structures and access methods would be worthy of a new name. A truly novel form of structure or file organization - assuming it is actually useful - is worthy of not just a new name but a new name writ large on the front page. A repackaged version of an existing combination might want a new marketing name, but it should be recognized that that is all it is - a name to sell by.
NoSQL 1.0 is usually not much more than a hash-accessed flat-table database. GDBM, QDBM and BerkeleyDB are all hash-accessed flat-table databases. The refinements mentioned as being added to NoSQL databases (such as searchable indexes) are simply sequential indexes that associate some indexed parameters with the hash value.
NoSQL generally works by you pushing an item into the database and getting one or more hash values back. You want the item back, you give the database the hash values and you get the item. Object-oriented and object-based NoSQL both work by allowing objects to point to other objects. This gives you inheritance. (Basically you have a hash value that points to another record, where the structure of that other record is fixed rather than chosen at run-time via a join statement.)
Basically, database theory describes all the various forms of database you can have: flat-file, hierarchical, network, relational, object/relational, relational, semi-structured, associative, entity-attribute-value, transactional and star (aka data warehouse). A description of some of these can be found here.
This describes how the data is actually laid out, but does NOT necessarily describe how the data is accessed.
Database theory also describes the following underlying methods of accessing data: sequential, indexed, hash. Any combination of these is permitted, so you can have an index that points into sections of a database that are then searched sequentially for example. Or you can have indexes that point to other indexes that in turn point to a hash value. And so on.
SQL is just a meta-language that allows you to apply a restricted form of set theory on the underlying access methods. There were arguments at the time SQL appeared that it should allow all of set theory - and those arguments still go on, with some SQL alternatives using actual set theory notation as opposed to SQL notation.
NoSQL, in some cases, is just direct access to hash tables for directly accessing items. In other cases, it's a lightweight abstraction layer.
In the example advertised in the summary, an object is referenced through a set of indexes. If you have a partial set of indexes, you reference multiple objects but they will be related in some way. There is nothing X.0 about it, it's just a NoSQL database that uses a network database topology rather than a flat-file topology. It is nothing new.
I recognize that marketspeak is what sells things, that calling the systems by what they actually are would not be nearly as impressive to managers. Managers do not, as a rule, read Slashdot. Geeks and Nerds read Slashdot. Geeks and Nerds know Database Theory. (Well, if they don't, they damn well should -- either that, or they can use Google to look the terms up.) The two additions to database theory in the past 30 years have been the Object-Relational and Object-Oriented models.
It is not the only solution, although it would be a very effective one if you could achieve it.
An alternative is to simply out-compete. In everything. Man--made islands are all very cute, but you're not going to build the next MIT on one, let alone the next Boeing, the next NASA, the next Volvo and the next farming community you're going to need (because if you want to out-compete in everything, you have got to DO everything).
The benefit in out-competing is that isolating all the corporations and military entities simultaneously would require something approaching 90% cooperation by the world's population, whereas simply finding a relatively isolated already-democratic nation of sufficient size and wealth then co-opting it merely requires 51% support of the locals. A considerably easier target to achieve. Oh, and then developing the intellectual, technological and biochemical industries to the point that the nation can survive any likely threat. Again, a much easier proposition than storming the Bastielle, since the US has already declared that it will use nuclear weapons in the event of being defeated even by a non-nuclear adversary and it is very unlikely in the extreme that any other nation would use less than total war if significantly threatened.
Old, established companies will claim that old, established standards are best - until they devise a new product. New companies and old ones with new products will claim that new standards are best. The consumers -- the ones actually USING the product -- don't get to say what it is they need or want. Rather, they are told what they should need and want.
The intelligent consumers (all three of them) should ignore what the companies are saying and should define metrics in terms of value. One option would use zero as no product and 1 as being the absolute baseline requirement for that parameter. All metrics should be non-linear and should either tend to a limit, following the law of diminishing returns, or it should reach a peak and then fall off to zero. (You can't always say for certain what the limit should be, but you can guess. The best vision and best hearing are still finite quantities, for example, and no matter how good 3D pictures become, no person will need a 5D display for a very long time.)
A second option would be to do something similar but instead of defining the baseline requirement, define the maximum instead (let's say 100). The current baseline requirement can then be marked on the curve, together with where the product ranks.
Functionally, these two are the same. The difference is that one is scaled according to how usable the product is in relation to actual need, the second according to how usable the product is in relation to theoretical limits.
That is still correct. What has changed is the weighting given to any given instruction. (In the Olde Dayes of Yore, it was sufficient to run a million lightweight instructions, such as ADD or MOV, and see how long it took. After caches started being added, benchmark programs that were any good simulated typical function sizes and typical arc lengths. These days, things are so complex that full applications are generally run from a known start point to a known end point.)
In your case of a 22kHz sine wave, the two points might be measured at any point along the wave, which means you can't tell where you are along the wave. Assuming the signal varies between +/-1, there will be two possible locations on the wave (other than at the peak and trough) which will give the same numeric values. That will play merry hell with phase. You can get infinitely close to 2 samples per wave, because you only need to establish one further point somewhere along that wave that doesn't correspond to those two samples, otherwise you're guaranteed an alias. Usually, if you're mucking with controlled signals, v(t=0)=0 for a sine wave. That's a perfectly valid extra point and from there, only two samples per wave are needed. You can even use this technique in audio, so that there's a hard-coded third point, although you are likely to get artifacts in the sound as a result. Mind you, at a 44KHz sampling rate, only freaks like myself will actually hear them.
When it comes to very complex signals, it's a mess. You can certainly decompose everything into sine waves (Fourier analysis), albeit an infinite number of them. However, that is exceedingly difficult to do. One popular method is to sample a godawful number of points and then linearly interpolate. This works because you can approximate very very tiny portions of any sine curve with a straight line segment. But then you are going from having to sample three points to uniquely define a sine wave to having to sample hundreds. It is popular because it is easy, not because it is any good. At two points, you will get a straight line. At 3, you get a triangle.
Well, in those cases, you'd get breaks (gaps in the data where the error-correction couldn't figure out the values so dumped them) rather than noise.
I have taken up making my own cables. In part, this is because finding cables for some of my sound systems is.... difficult. (I am the proud hardware hacker of a functional Marconi R1155 - not the one shown there, but the same model). Not exactly a digital system, but the reception is amazing. Well, for the vintage.
Slashdot Mirror
Huh? Capabilities would offer far more fine-grained control over the degree of punishment.
Papyrus? Pah! Youngsters! Back in my day, we had to find a granite boulder to carve the letters into. With a herring!
My cheapo Epson negative scanner will handle up to 12,000 dots per inch. The largest negatives I'm dealing with are around 3" x 3.5". This gives me a theoretical resolution of 36,000 x 42,000 (1.512 gigapixels). Since there are many better scanners and many larger film formats, this cannot be considered the upper end.
Ultimately, all cameras (digital or otherwise) are limited by the lenses. A foot square negative plate with a low-grade lens will capture no information not available with a much smaller negative and the same lens.
CCDs have one major problem - most are accessed serially. This means the time interval you're reading for the first pixel is NOT the same as the time interval for the last pixel. This doesn't matter for small CCDs - the number of high-energy particles and photons that can get through the shutter over a very small time interval is insignificant. Even so, scientific CCD devices will take background readings before and after, then adjust. If you were to build a 1.5 gigapixel CCD, that difference is going to become more significant. You can build cameras that compensate, but that is going to add to the price.
Film is parallel. So whatever the background levels, it will affect the film evenly. Well, unless there's a radioactive source in the room.
The next problem is the ADC. Technically, here digital should be far better than film. You can certainly get 24-bit ADCs and although film is analogue, it is not truly continuous. The reality, though, is that a lot of digital cameras use 8-bit ADCs per colour, which film can certainly beat without breaking into a sweat.
Yes, digital cameras have a great many advantages and -could- be better in every area. My point is not that digital is "bad" (it isn't) but that film still has an edge in certain domains and that within those domains the correct choice is always to go with what is currently best. Eventually, 3CCD cameras with 24-bit ADCs and 1.5 gigabit CCDs will become the norm. Those will be so far beyond anything film could realistically achieve that digital will then be absolutely ideal.
For now, digital is "correct" for general home usage, where massive numbers of pictures is more important than a few great images. But general home users aren't the only ones who want cameras.
No, film is extremely valuable because there are markets that digital CANNOT operate in at present and are unlikely to operate in in the foreseeable future. Kodak should have worked more in those niches and less in the trashy markets.
Many of the Japanese companies that are currently very profitable and successful have existed for hundreds of years. At least two are around 1,500 years old.
Companies don't need to be immortal, but they don't need to be mortal either. Companies aren't "alive", aren't "people" and aren't subject to decay. They are systems.
Yes, that is true. But it's for a very stupid reason. To buy a digital camera that has the resolution of a film camera still costs many thousands of dollars. To buy one that also has the dynamic range is even more costly That is unlikely to change within the next decade. (The odds of being able to buy a digital camera with a sensor large enough to compete with medium format film, never mind large format, is practically zero.)
As for longevity of media - I am currently working through family archives of negatives going back to 1909. Is your flash card guaranteed to hold data 103+ years?
You could argue that most people don't care about quality that high or longevity that great. That is true, but those same people are happy to bitch about the crappy quality of archival material that does interest them. I don't know if the irony is lost on them (the photos they are taking will be someone else's archival material) or if they just don't give a flying about how much it'll seriously bother other people.
Agreed, but with one proviso -- most people are incredibly lazy. There MUST be a distinction between cases:
What needs protecting (IMHO):
What should NOT be protected:
I'd abolish copyright, trademark and patent laws, then create a single, standardized system that actually tried to achieve the effect that is supposed to be intended.
Yes, but there's a severe danger here. The courts could rule that birds are infringing on copyright and order them all shot.
Rumblefish has hired bird-brains, so of course there will be similarity.
No, I'm absolutely right.
Ok, these "problems" of which you speaketh:
1) No, only some map the model direct to disk. Oh, and except on one or two very primitive databases, views aren't mapped into a physical form on disk. MySQL only does so when you tell it to use a storage engine that allows you to map the model that way AND you configure it to. In the example you gave, you could use 1 table and 1 view (or, indeed, 1 table and 1 table-returning function) for almost every relational database out there. More sophisticated databases will let you generate an index from a function and order the table through an index. You still have the view/function, but you don't have to access anything through it for your example.
NoSQL databases can use any underlying structure (relational, hierarchical, flat file, object-oriented, etc), although they are more often coded as flat file. From Wikipedia:
No, you don't lay them out. You have absolutely bugger all idea where Memcached or MungoDB has put your data - it could be in any file on any disk in any computer in the database structure.
2) SQL is nothing more than a wrapper. Not all existing relational databases use SQL. And those that do - well, which SQL are you referring to? ANSI? T-SQL? Some other kind?
SQL isn't, however, restricted to relational databases. Ingres is not a relational database, it is a star database. Ingres uses SQL. Well, at least as one option.
3) I've never had any problems refactoring a database live. But, then, I use design tools. Which prevent me from needing to refactor in the first place by making it easy to design things correctly to begin with. That's the great thing about being a software engineer/computer scientist/database admin/system admin -- I know all about the RASDIT methodology and know how to apply it in everyday activities. I pity the poor sods who try to code blind and have to do any refactoring at all. A good design is so easy to create, so easy to implement and a wondrous thing to maintain.
It is a non-issue. Even in the debates over whether the Y chromosome was decaying, those supporting the idea that it did pointed to the fact that not all species with genders even use X and Y chromosomes, clearly demonstrating that the Y chromosome isn't that important even to the "male" gender. Alternative genes can and do emerge.
It was also noted that the Y chromosome is mostly non-coding DNA anyway. The Y is essentially a malformed X chromosome with almost everything the X does ripped out and a very small bit of extra coding added in. The main benefit the Y chromosome offers is a means to do family history via DNA sequencing companies. Since we know that regions of DNA can be switched on and off via soft-coding (the epigenome) and that DNA can also be reorganized on-the-fly (transposons), the coding regions of the Y could be pushed into the X and then activated/deactivated as needed. In the case of the San Fernando Valley, this has apparently already happened.
I would argue that the X chromosome is too heavily loaded and isn't subject to enough mutations, so some deliberate refactoring of the X and Y might actually be a very good thing. A third gender, preferably female with a desire for geeks, would be helpful.
There are permutations of the concepts in database theory that have not been tried, at least not that I know of, but NoSQL and this NoSQL 2.0 idea are not amongst them.
A short, and not comprehensive, list of underlying database structures
Another short list, describing a few others
A short list of some file organization methods (ie: access methods)
A truly novel combination of existing structures and access methods would be worthy of a new name. A truly novel form of structure or file organization - assuming it is actually useful - is worthy of not just a new name but a new name writ large on the front page. A repackaged version of an existing combination might want a new marketing name, but it should be recognized that that is all it is - a name to sell by.
NoSQL 1.0 is usually not much more than a hash-accessed flat-table database. GDBM, QDBM and BerkeleyDB are all hash-accessed flat-table databases. The refinements mentioned as being added to NoSQL databases (such as searchable indexes) are simply sequential indexes that associate some indexed parameters with the hash value.
NoSQL generally works by you pushing an item into the database and getting one or more hash values back. You want the item back, you give the database the hash values and you get the item. Object-oriented and object-based NoSQL both work by allowing objects to point to other objects. This gives you inheritance. (Basically you have a hash value that points to another record, where the structure of that other record is fixed rather than chosen at run-time via a join statement.)
Basically, database theory describes all the various forms of database you can have: flat-file, hierarchical, network, relational, object/relational, relational, semi-structured, associative, entity-attribute-value, transactional and star (aka data warehouse). A description of some of these can be found here.
This describes how the data is actually laid out, but does NOT necessarily describe how the data is accessed.
Database theory also describes the following underlying methods of accessing data: sequential, indexed, hash. Any combination of these is permitted, so you can have an index that points into sections of a database that are then searched sequentially for example. Or you can have indexes that point to other indexes that in turn point to a hash value. And so on.
SQL is just a meta-language that allows you to apply a restricted form of set theory on the underlying access methods. There were arguments at the time SQL appeared that it should allow all of set theory - and those arguments still go on, with some SQL alternatives using actual set theory notation as opposed to SQL notation.
NoSQL, in some cases, is just direct access to hash tables for directly accessing items. In other cases, it's a lightweight abstraction layer.
In the example advertised in the summary, an object is referenced through a set of indexes. If you have a partial set of indexes, you reference multiple objects but they will be related in some way. There is nothing X.0 about it, it's just a NoSQL database that uses a network database topology rather than a flat-file topology. It is nothing new.
I recognize that marketspeak is what sells things, that calling the systems by what they actually are would not be nearly as impressive to managers. Managers do not, as a rule, read Slashdot. Geeks and Nerds read Slashdot. Geeks and Nerds know Database Theory. (Well, if they don't, they damn well should -- either that, or they can use Google to look the terms up.) The two additions to database theory in the past 30 years have been the Object-Relational and Object-Oriented models.
50% lethality + uncontrolled spread = the original version of Survivors.
It is not the only solution, although it would be a very effective one if you could achieve it.
An alternative is to simply out-compete. In everything. Man--made islands are all very cute, but you're not going to build the next MIT on one, let alone the next Boeing, the next NASA, the next Volvo and the next farming community you're going to need (because if you want to out-compete in everything, you have got to DO everything).
The benefit in out-competing is that isolating all the corporations and military entities simultaneously would require something approaching 90% cooperation by the world's population, whereas simply finding a relatively isolated already-democratic nation of sufficient size and wealth then co-opting it merely requires 51% support of the locals. A considerably easier target to achieve. Oh, and then developing the intellectual, technological and biochemical industries to the point that the nation can survive any likely threat. Again, a much easier proposition than storming the Bastielle, since the US has already declared that it will use nuclear weapons in the event of being defeated even by a non-nuclear adversary and it is very unlikely in the extreme that any other nation would use less than total war if significantly threatened.
That's why the real warranty clause actually kicks in at the 37th picosecond.
Nice quote, but scientifically wrong. Retrotranspons alter the coding sequence on a cell-by-cell basis constantly.
It's not full, just fragmented. Push the continents back together and you'll be fine.
I thought a Supercenturion was a Centurion who wore underpants on the outside.
Old, established companies will claim that old, established standards are best - until they devise a new product.
New companies and old ones with new products will claim that new standards are best.
The consumers -- the ones actually USING the product -- don't get to say what it is they need or want. Rather, they are told what they should need and want.
The intelligent consumers (all three of them) should ignore what the companies are saying and should define metrics in terms of value. One option would use zero as no product and 1 as being the absolute baseline requirement for that parameter. All metrics should be non-linear and should either tend to a limit, following the law of diminishing returns, or it should reach a peak and then fall off to zero. (You can't always say for certain what the limit should be, but you can guess. The best vision and best hearing are still finite quantities, for example, and no matter how good 3D pictures become, no person will need a 5D display for a very long time.)
A second option would be to do something similar but instead of defining the baseline requirement, define the maximum instead (let's say 100). The current baseline requirement can then be marked on the curve, together with where the product ranks.
Functionally, these two are the same. The difference is that one is scaled according to how usable the product is in relation to actual need, the second according to how usable the product is in relation to theoretical limits.
That is still correct. What has changed is the weighting given to any given instruction. (In the Olde Dayes of Yore, it was sufficient to run a million lightweight instructions, such as ADD or MOV, and see how long it took. After caches started being added, benchmark programs that were any good simulated typical function sizes and typical arc lengths. These days, things are so complex that full applications are generally run from a known start point to a known end point.)
I honestly don't see anything wrong with any of these games. I regard them as exceptionally good for the time.
Thanks! (Curses, Old Age! You haven't defeated me yet!)
Yes...ish.
In your case of a 22kHz sine wave, the two points might be measured at any point along the wave, which means you can't tell where you are along the wave. Assuming the signal varies between +/-1, there will be two possible locations on the wave (other than at the peak and trough) which will give the same numeric values. That will play merry hell with phase. You can get infinitely close to 2 samples per wave, because you only need to establish one further point somewhere along that wave that doesn't correspond to those two samples, otherwise you're guaranteed an alias. Usually, if you're mucking with controlled signals, v(t=0)=0 for a sine wave. That's a perfectly valid extra point and from there, only two samples per wave are needed. You can even use this technique in audio, so that there's a hard-coded third point, although you are likely to get artifacts in the sound as a result. Mind you, at a 44KHz sampling rate, only freaks like myself will actually hear them.
When it comes to very complex signals, it's a mess. You can certainly decompose everything into sine waves (Fourier analysis), albeit an infinite number of them. However, that is exceedingly difficult to do. One popular method is to sample a godawful number of points and then linearly interpolate. This works because you can approximate very very tiny portions of any sine curve with a straight line segment. But then you are going from having to sample three points to uniquely define a sine wave to having to sample hundreds. It is popular because it is easy, not because it is any good. At two points, you will get a straight line. At 3, you get a triangle.
Well, in those cases, you'd get breaks (gaps in the data where the error-correction couldn't figure out the values so dumped them) rather than noise.
I have taken up making my own cables. In part, this is because finding cables for some of my sound systems is.... difficult. (I am the proud hardware hacker of a functional Marconi R1155 - not the one shown there, but the same model). Not exactly a digital system, but the reception is amazing. Well, for the vintage.