The correct leg work for a client using Win95 is not to bend at both the knees, but to extend one foot toward their lame backsides.
Doing all the compatibility leg work sounds very client centric in theory, but it leads to a chocolate chip cookie with no chocolate in it.
Writing a book which communicates effectively is a very hard task.
I recommend that all authors put in the special effort to figure out how to set up two Win95 workstations to produce identical output under MS Office. It will make the writing process *so* much easier and the clients of your client will be very impressed that all the ligatures have come out perfectly. So impressed that they'll believe everything you say even if you didn't get your facts straight.
When people talk causually about XML they usually mean XML under a domain-appropriate DTD even if they don't realize it. Suppose I said I was going to write a book in ASCII and everyone jumped in to warn me that it is possible to encode proprietary content in ASCII. Are those comments all that helpful?
When I researched this issue I came up with the same answer: XML + the DocBook DTD. I didn't try XMetaL because I wanted something that ran under BSD as well as NT. So I'm using the PSGML plug-ins for emacs. These are helpful, but not entirely adequate.
I also asked around about XML transformators. Jade and DSSSL are reported to be reliable if you don't need to mess around with the style sheets. DSSSL style sheets are written in a subset of the Scheme language, which is a LISP derrivative.
Some died in the wool SGML people regard DSSSL as the densest, most impenetrable jungle going. Pitch out SGML and then adopt SGML's big scary brother instead. Well, I was warned.
In the pure XML sphere you have the immature XSLT technologies. These are supposed to be easier than DSSSL. You could spend a year of your life really getting up to speed with XSLT.
It's ends up not being a choice of technology and more a choice of civilization. MS has zero sales base on planet Vulcan and Spock really *likes* DSSSL. Convinced? It works for me.
I'm not convinced. Suppose the game is white-to-win. Then what we need is a single "killer response" to each position black is able to reach. We already have one useful degree of freedom: we can select the set of killer responses based on some heuristic for minimizing the total number of positions which black can force us into (based on fore knowledge of our own responses). The first approximation for white is to select, whenever possible, moves which reduce the board "complexity" (number of pieces remaining, pawn advancement, legal castles, etc.) and responses which "force" a known response from black.
It's not at all an easy matter to estimate how much white, playing from within a set of unlosable moves, can curtail black's daliances.
Most likely we only need to store responses for the portion of this space where black plays a sensible defense. Any positions where Deep Blue can compute mate for white in under two minutes will not need to be stored in the kill database. Attempts by black to explode the size of the kill tree by playing "scambled eggs" are likely to soon lead us to a position where we can fall back to a computation in real time.
And finally, the most important asset is that we aren't tying to compute winning moves. We merely need to find a killer response which lies within the curtailed space which white's kill strategy permits the game to reach.
For example, we might examine this space and discover that white can always force victory without certain pawn structures ever being attained. All positions containing these excluded pawn structures are excluded, as are all positions allowing black to reach such an excluded position.
A recursive mini-max heuristic to "guess" the killer response can be devised on this principle trading off between space and speed. A recursive search returns an ordered list of moves for white ranking according to the probability that the move is the desired killer move. Bear in mind that this heuristic is equivalent to the heuristic which Deep Blue uses to play chess exceptionally well already, but with the benefit of a vastly more powerful set of pruning rules.
This computational heuristic could conceivably produce on computational terms the desired killer move in 99.99% of all positions we might need to evaluate, and 95% of all positions which might regard as constituting a "spirited defense". In one out of twenty positions our killer response database might need to store an override suggesting that the second (or third) ranked estimate be used in favor of the top ranked default.
The storage requirements would then be a small fraction of a bit for each position reachable within a space which is vastly constrained relative to the open game of chess. Computing the killer perimeter in the first place is vastly more difficult than contriving to make perfect moves from within this space accessible in real time.
I can't resist the urge to stick a pin in some sloppy thinking which permeates this chess thread.
Suppose we invent a new game called Chess' (chess prime). In this game white either opens with a valid move according to the rules of Chess, or white simply announces "checkmate" and wins instantly. Chess' has the same size position tree as Chess but I think we can all agree that Chess' is a bit easier to solve. Some people are way too size-centric in their approach to life.
Re:Computer Vision - the real problem.
on
Solving Chess?
·
· Score: 1
The average dog distinguishes between a leg and a tree with his eyes closed and probably thinks a peg is closer to a tree than a leg.
Only a small percentage of the traditional bound manual deserves to be on paper. If some people find it unattractive to read a manual on a computer screen (I don't much mind), consider what it's like trying to read a screen shot printed in a book!
I've received a lot of printed manuals over the years where I've never even cracked the cover.
These days I usually find what I scrape off the internet to be more valuable than what the vendor supplies anyway. Web pages often say something along the lines of "if you try to X in the obvious way it will blow up in your face because the vendor screwed the pooch on concept Y".
I haven't read a lot of vendor manuals that show the same concern for saving the victim (user of the product) from experiencing unnecessary grief.
Just an hour before this story broke I was reading the Squid user manual concerning the issue of "caching Real Audio". Basically what Squid says is that only the http "psuedo streaming" mode of operation is cachable.
I have no enthusiasm to see a Linux client which can play a bunch of proprietary formats which don't interact cleanly with *everything else* that makes Linux what it is.
I think these formats are the disease, not the cure.
In the last few weeks I've come across two opinion pieces which suggested that the pursuit of "intuitive" interfaces is one of the worst goose chases in the history of computing. One of the authors was Tog, the other was one of the original Xerox luminaries (the mouse guy I think).
Intuitive for a "golden surfer" who sits down to a computer for the first time in their life and intuitive for someone who has used computers, consoles, Palm pilots etc. from a young age are "effectively" irreconcilable.
A quick sanity check on "intuitive design" is Merlin Donald's "Origin of the Modern Mind". He talks about the evolution of human language as beginning with mimetic (gestural) culture and evolving toward a more abstract (and expressive) semantic culture.
Why is it that "interface" specialists insist on boiling down interface elements to the lowest common denominator of human linguistic evolution? Why is it that we are still aflicted, a full generation after the personal computer was invented, with the "Quest for Fire" one-button mouse with an "expressive" vocabulary limited to point and grunt?
We should get rid of the entire concept of "intuitive" and focus instead on accessible, expressive, and effective design choices.
From the point of view of genericity, adding guaranteed integer sizes (such as int32) would be a highly retrograde act.
On a practical level, if the platform supplies the desired integers these can be easily typedefed as described within a header file (the numeric_limits facility allows this to be done quite robustly with little or no platform specific code). There is no need to embed these conventions within the language at this late point in time.
On a deeper level, the use of "guaranteed" types completely misses the point.
There are certain kinds of integer computations which depend upon a precise modulo behaviour. Most cyphers contain such operations.
Then there are other contexts where the size of the integer used does not affect the end result of the computation depending only on the integer type being of a "sufficient" size. Within this category are two distinct situations: one where having a larger integer type extends the allowable range of the computation (a side benefit) and another situation where using an integer type "larger than necessary" confers no benefit at all.
And finally, there are situations where space issues are more important than size issues and where smaller sizes should be used regardless of whether the platform computes efficiently on the smaller size. Usually in this kind of code there is a carefully chosen compact representation type used within the large data structures, and a distinct integer type defined for computing with these values.
So we break this down along a number of axes: whether the integer is compact or fast (as chosen by the platform) whether a precise size is required to achieve correct results whether "padding" the integer to a larger size can be considered to be a "side benefit"
These semantics can already be captured quite well within C++ using the template facility.
Any system with even a slight pretense of genericity will end up mapping the platform types through several type indirections anyway.
The worst thing would be to have programs where int32 is plastered everywhere with no distinction present about which of the above considerations dictated the final choise.
Likewise with all the other suggestions: C++ already contains features which make it possible (and satisfactory) for any of the features cited to be implemented in libraries rather than in the base language.
C++ templates are not an "implementation of parametric polymorphism". I don't recall C++ filling out an entry form to compete in that pageant.
The template mechanism began life as an effort to capture Ada-like genericity, and they continued to evolve in response to issues which originated within the C++ language.
Along the way, the originators of the STL discovered that C++ templates had sufficient expressive power to capture a more advanced approach to genericity--despite the fact that the template mechanism had evolved in response to issues within the language rather than as an "implementation" of some formal theory hatched at a university.
With the benefit of a little bit of extra tweaking, C++ implements the STL concept of genericity rather nicely.
Then along came people like Todd Veldhuizen (Blitz++) who discovered that these same template mechanisms were *capable of* supporting parametric polymorphism to the extent that practical programs could be written based on these concepts.
Despite many outrageous potholes in the C++ template system (most especially the inability to compute a static type in a declaration using the same syntax as the expression which produces the desired value, and the amazing oversight which lead to the lack of a template typedef), C++ has produced some good results in this area. Because of the way that C++ was designed, most of the expressive defects of the language can be hidden within library code and has little impact on the end user.
In fact, if you really wanted to say that C++ is the "implementation of some concept X" it would be fair to say that C++ is the implementation of "compartmentalized abstraction". What I mean by this is that people who implement libraries such as Blitz++ and Pooma are free to work within the language at a much higher level of detail and abstraction than is imposed of necessity on the application programmer.
Equally important, the evolution of C++ is a response to what people learn by actually writing programs in the language. C++ as it stands has enough support for genericity and PP to allow the community to experiment with the language in practical settings.
There is nothing that bothers me more than to see the failings of C++ "exposed" against the academic standard of "designed by concept".
Neither are we talking about a language designed by committee. What we are really talking about here is a language "designed by community"--equal measures of wisdom and warts pureed into a fine paste which nevertheless seems to get the job done.
Five years down the road it will be time for that community to reflect on the experience gained with genericity as it now exists and, hopefully, continue to listen and respond to the issues which arise from within.
It's a big mistake to presume that everything in the river which feels the same tug is destined to wind up on the same beach.
This same thing has applied to 3D imaging for audio systems for years. Someone announces incredible realism that bites you on the earlobes and then you find out your head has to be placed in a sweet spot the size of a grapefruit in order to hear the effect.
I sometimes wear prisms to compensate for a lazy eye. You quickly realize that the whole vision thing is a lot more complicated than the doctor lets on. First of all, there is a chromatic effect where red and blue colours are on focal plains 5mm apart (at monitor distance). Then there is the fact that the two lenses have a different field size because my near-sightedness is slightly different in each eye--which further complicates the problems I have keeping my eyes pointed in the same direction.
I'll believe in these new technologies when the description is precise enough that I can calculate what effect my prisms would have when viewing these screens.
Completely contrary to the implications of the post, even if the government had successfully broken M's encryption, they would still press for him to publicly disclose his keys. The life blood of an intelligence service is to create ambiguity and uncertainty about what capabilities and resources you have at your disposal.
Until they obtain or manufacture a plausible cover, they must at least pretend that they can't break these codes.
Even as far back as Enigma, the vast majority of the vital intelligence gathered on German activities was concealed operationally, often at great cost.
It has been a theme in BS's writings for a long time that cryptanalysis is difficult, expertise is rare, and the process is long and expensive.
On the basis of that argument it would seem that one could make a good case to see a proliferation of diverse algorithms for niche purposes. This is not protection via obscurity, but rather a direct attack on one of Mallet's most limited resources: the number of good analysts he is able to employ.
The opposing side of the argument seems to be that it is difficult to construct a strong cypher. I've never understood this argument.
What is indeed difficult is to contruct a strong cypher within the parameters of the NIST guidelines: small, fast, and dense.
But what about a custom cypher with a 512 byte disk sector as the underlying block and no desire to run in all the fancy cypher block modes or error recovery properties? What about applying 16 circular rounds on 8-byte subblocks with a data-directed component somewhere in the middle? (The usually rejoiner is that the theory of data-directed methods is not well understood; but that's precisely the property I'm seeking).
It seems to me that all the important criteria (bit diffusion, non-linearity, differential cryptanalysis) are easier to achieve given a larger mixing bowl (e.g. 512 bytes) with a much deeper chain length on the primitive cypher operations.
So why is it that the "large mixing bowl" approach, which seems to require much less expertise, is rarely seen in practice or commended for the advantage is appears to offer?
It seems to me that diversity is an unfair causualty in the war against obscurity by virtue of the exact reason why it should be desired: that cryptanalsysts just don't have the time to cope with it.
Totally flawed. She can't pay tax on something she has never received. And what has she received?
At best you could argue that she has received $70,000 in the form of pleasure on taking risks. It sure sounds dumb. But you could argue this based on a commodity market for gambling as a form of entertainment.
However, if she engaged in this activity knowing that her debts were not legally enforceable she has in fact not taken any risk at all. It then becomes difficult to argue that she has received $70,000 in pleasure from a risk she never took.
And she hasn't received any nbet cash gain either. So there's not much here to pay taxes on and I don't see that the IRS has anything to do with it.
Even the investment industry is regulated as to what kinds of investments one is able to make "on margin". Gambling on margin is the worst of all.
I see no reason at all why gambling and credit need to be linked. The whole concept of credit is that it enables a deferred return to the person obtaining the credit. A sane society requires a balance between risk and reward.
People who extend credit by throwing money into a burning house ought not be relying on the instruments of society to extract it again.
One has to bear in mind that what we are calling "gambling" here is not symmetric: only one party is gambling in any real sense; the other party is reaping highly predictable profits.
However, when the casino extends credit to the unworthy the situation does in fact become pleasingly symmetric. Fair enough. But let's not waste the resources of the court defending the stupidity of the casino.
Bonehead. Anyone who can type at a half decent speed suffers auxiliary verb lossage. Chomsky's theory of traces partially explains this phenomena: parts of the sentence structure which vary based on how the sentence is cast happen late enough in the process that sometimes it doesn't catch up to fast moving fingers.
Anyone who can type fast enough to lose an auxiliary is most likely to be highly literate.
I guess it seems obvious to you that any variety of mechanical imperfection implies a defective intelligence. But strangely, people smarter than you don't hold to the same view.
What is it that makes everyone think that the government agencies don't already have this technology?
If you don't think these agencies are capable of keeping important technologies all to themselves you should dig up the history of undersea channel microphones.
And what is this business about machines suddenly overtaking humans on a "perceptual" basis? Technology has long held the advantage over humans in most fundamental categories.
The historical problems with noise filtering were entirely due to the fact that we didn't know how to solve the problem. Finally these cloistered scientists have got off their asses and figured out what they were doing wrong all along.
The only "breakthrough" here is that we learn that the "insurmountable" human advantage accrues to a neuronal system which can be replicated (and even improved) with a model consisting of eleven neurons.
Wow. What a huge edge the human being has over the machine.
But don't worry. Our "innate" advantage in searching complex problem spaces is probably safe for another ten years.
What is it that makes everyone think that the government agencies don't already have this technology? If you don't think these agencies are capable of keeping important technologies all to themselves you should dig up the history of undersea channel microphones. And what is this business about machines suddenly overtaking humans on a "perceptual" basis? Technology has long held the advantage over humans in most fundamental categories. The historical problems with noise filtering were entirely due to the fact that we didn't know how to solve the problem. Finally these cloistered scientists have got off their asses and figured out what they were doing wrong all along. The only "breakthrough" here is that we learn that the "insurmountable" human advantage accrues to a neuronal system which can be replicated (and even improved) with a model consisting of eleven neurons. Wow. What a huge edge the human being has over the machine. But don't worry. Our "innate" advantage in searching complex problem spaces is probably safe for another ten years.
I've had the Shaw service for 18 months and so far it has been mostly excellent. There was a couple of weeks of DNS irregularity and two or three days of network downtime altogether.
I *frequently* see 600KB/s (bytes!) when downloading from big sites such as Intel or ESPN or AltaVista.
The Shaw network uses the Terayon technology which is based on spread spectrum concepts. This means that all the available upstream channels broadcast simultaneously on the same frequencies and the head node sorts it all out.
The algorithm for allocating the available spread spectrum downstream channels can be a bit of problem when playing Quake in the evening. There are something like 128 64K-bit channels each of which can be assigned to a different user on 10mS slices (I forget the exact numbers and I haven't even checked the arithmetic). But it works out to a situation where a very large number of low-bandwidth streams become a bit choppy (you don't get slices quite as often as you might like).
I've also heard a rumour that you hack the box somewhat with SNMP protocol but I don't know the details of how this is done.
I'm not sure that Shaw is any better than Rogers and I was ready to find lots of faults with this offering and there simply haven't been any worth mentioning for as long as I've subscribed.
Futhermore, the representatives have insisted that they are not in the process of implementing upstream bandwidth caps. It might that the Terayon technology is less sensitive to the abuses which I know are going on (e.g. sharing copies of the Phantom Menace).
We are fortunate to also have ADSL here but the economics are such that only businesses make much use of it.
We really have nothing much to complain about--yet.
Slashdot Mirror
The correct leg work for a client using Win95 is not to bend at both the knees, but to extend one foot toward their lame backsides.
Doing all the compatibility leg work sounds very client centric in theory, but it leads to a chocolate chip cookie with no chocolate in it.
Writing a book which communicates effectively is a very hard task.
I recommend that all authors put in the special effort to figure out how to set up two Win95 workstations to produce identical output under MS Office. It will make the writing process *so* much easier and the clients of your client will be very impressed that all the ligatures have come out perfectly. So impressed that they'll believe everything you say even if you didn't get your facts straight.
When people talk causually about XML they usually mean XML under a domain-appropriate DTD even if they don't realize it. Suppose I said I was going to write a book in ASCII and everyone jumped in to warn me that it is possible to encode proprietary content in ASCII. Are those comments all that helpful?
When I researched this issue I came up with the same answer: XML + the DocBook DTD. I didn't try XMetaL because I wanted something that ran under BSD as well as NT. So I'm using the PSGML plug-ins for emacs. These are helpful, but not entirely adequate.
I also asked around about XML transformators. Jade and DSSSL are reported to be reliable if you don't need to mess around with the style sheets. DSSSL style sheets are written in a subset of the Scheme language, which is a LISP derrivative.
Some died in the wool SGML people regard DSSSL as the densest, most impenetrable jungle going. Pitch out SGML and then adopt SGML's big scary brother instead. Well, I was warned.
In the pure XML sphere you have the immature XSLT technologies. These are supposed to be easier than DSSSL. You could spend a year of your life really getting up to speed with XSLT.
It's ends up not being a choice of technology and more a choice of civilization. MS has zero sales base on planet Vulcan and Spock really *likes* DSSSL. Convinced? It works for me.
I'm not convinced. Suppose the game is white-to-win. Then what we need is a single "killer response" to each position black is able to reach. We already have one useful degree of freedom: we can select the set of killer responses based on some heuristic for minimizing the total number of positions which black can force us into (based on fore knowledge of our own responses). The first approximation for white is to select, whenever possible, moves which reduce the board "complexity" (number of pieces remaining, pawn advancement, legal castles, etc.) and responses which "force" a known response from black.
It's not at all an easy matter to estimate how much white, playing from within a set of unlosable moves, can curtail black's daliances.
Most likely we only need to store responses for the portion of this space where black plays a sensible defense. Any positions where Deep Blue can compute mate for white in under two minutes will not need to be stored in the kill database. Attempts by black to explode the size of the kill tree by playing "scambled eggs" are likely to soon lead us to a position where we can fall back to a computation in real time.
And finally, the most important asset is that we aren't tying to compute winning moves. We merely need to find a killer response which lies within the curtailed space which white's kill strategy permits the game to reach.
For example, we might examine this space and discover that white can always force victory without certain pawn structures ever being attained. All positions containing these excluded pawn structures are excluded, as are all positions allowing black to reach such an excluded position.
A recursive mini-max heuristic to "guess" the killer response can be devised on this principle trading off between space and speed. A recursive search returns an ordered list of moves for white ranking according to the probability that the move is the desired killer move. Bear in mind that this heuristic is equivalent to the heuristic which Deep Blue uses to play chess exceptionally well already, but with the benefit of a vastly more powerful set of pruning rules.
This computational heuristic could conceivably produce on computational terms the desired killer move in 99.99% of all positions we might need to evaluate, and 95% of all positions which might regard as constituting a "spirited defense". In one out of twenty positions our killer response database might need to store an override suggesting that the second (or third) ranked estimate be used in favor of the top ranked default.
The storage requirements would then be a small fraction of a bit for each position reachable within a space which is vastly constrained relative to the open game of chess. Computing the killer perimeter in the first place is vastly more difficult than contriving to make perfect moves from within this space accessible in real time.
I can't resist the urge to stick a pin in some sloppy thinking which permeates this chess thread.
Suppose we invent a new game called Chess' (chess prime). In this game white either opens with a valid move according to the rules of Chess, or white simply announces "checkmate" and wins instantly. Chess' has the same size position tree as Chess but I think we can all agree that Chess' is a bit easier to solve. Some people are way too size-centric in their approach to life.
The average dog distinguishes between a leg and a tree with his eyes closed and probably thinks a peg is closer to a tree than a leg.
Only a small percentage of the traditional bound manual deserves to be on paper. If some people find it unattractive to read a manual on a computer screen (I don't much mind), consider what it's like trying to read a screen shot printed in a book!
I've received a lot of printed manuals over the years where I've never even cracked the cover.
These days I usually find what I scrape off the internet to be more valuable than what the vendor supplies anyway. Web pages often say something along the lines of "if you try to X in the obvious way it will blow up in your face because the vendor screwed the pooch on concept Y".
I haven't read a lot of vendor manuals that show the same concern for saving the victim (user of the product) from experiencing unnecessary grief.
Just an hour before this story broke I was reading the Squid user manual concerning the issue of "caching Real Audio". Basically what Squid says is that only the http "psuedo streaming" mode of operation is cachable.
I have no enthusiasm to see a Linux client which can play a bunch of proprietary formats which don't interact cleanly with *everything else* that makes Linux what it is.
I think these formats are the disease, not the cure.
In the last few weeks I've come across two opinion pieces which suggested that the pursuit of "intuitive" interfaces is one of the worst goose chases in the history of computing. One of the authors was Tog, the other was one of the original Xerox luminaries (the mouse guy I think).
Intuitive for a "golden surfer" who sits down to a computer for the first time in their life and intuitive for someone who has used computers, consoles, Palm pilots etc. from a young age are "effectively" irreconcilable.
A quick sanity check on "intuitive design" is Merlin Donald's "Origin of the Modern Mind". He talks about the evolution of human language as beginning with mimetic (gestural) culture and evolving toward a more abstract (and expressive) semantic culture.
Why is it that "interface" specialists insist on boiling down interface elements to the lowest common denominator of human linguistic evolution? Why is it that we are still aflicted, a full generation after the personal computer was invented, with the "Quest for Fire" one-button mouse with an "expressive" vocabulary limited to point and grunt?
We should get rid of the entire concept of "intuitive" and focus instead on accessible, expressive, and effective design choices.
From the point of view of genericity, adding guaranteed integer sizes (such as int32) would be a highly retrograde act.
On a practical level, if the platform supplies the desired integers these can be easily typedefed as described within a header file (the numeric_limits facility allows this to be done quite robustly with little or no platform specific code). There is no need to embed these conventions within the language at this late point in time.
On a deeper level, the use of "guaranteed" types completely misses the point.
There are certain kinds of integer computations which depend upon a precise modulo behaviour. Most cyphers contain such operations.
Then there are other contexts where the size of the integer used does not affect the end result of the computation depending only on the integer type being of a "sufficient" size. Within this category are two distinct situations: one where having a larger integer type extends the allowable range of the computation (a side benefit) and another situation where using an integer type "larger than necessary" confers no benefit at all.
And finally, there are situations where space issues are more important than size issues and where smaller sizes should be used regardless of whether the platform computes efficiently on the smaller size. Usually in this kind of code there is a carefully chosen compact representation type used within the large data structures, and a distinct integer type defined for computing with these values.
So we break this down along a number of axes:
whether the integer is compact or fast (as chosen by the platform)
whether a precise size is required to achieve correct results
whether "padding" the integer to a larger size can be considered to be a "side benefit"
These semantics can already be captured quite well within C++ using the template facility.
Any system with even a slight pretense of genericity will end up mapping the platform types through several type indirections anyway.
The worst thing would be to have programs where int32 is plastered everywhere with no distinction present about which of the above considerations dictated the final choise.
Likewise with all the other suggestions: C++ already contains features which make it possible (and satisfactory) for any of the features cited to be implemented in libraries rather than in the base language.
C++ templates are not an "implementation of parametric polymorphism". I don't recall C++ filling out an entry form to compete in that pageant.
The template mechanism began life as an effort to capture Ada-like genericity, and they continued to evolve in response to issues which originated within the C++ language.
Along the way, the originators of the STL discovered that C++ templates had sufficient expressive power to capture a more advanced approach to genericity--despite the fact that the template mechanism had evolved in response to issues within the language rather than as an "implementation" of some formal theory hatched at a university.
With the benefit of a little bit of extra tweaking, C++ implements the STL concept of genericity rather nicely.
Then along came people like Todd Veldhuizen (Blitz++) who discovered that these same template mechanisms were *capable of* supporting parametric polymorphism to the extent that practical programs could be written based on these concepts.
Despite many outrageous potholes in the C++ template system (most especially the inability to compute a static type in a declaration using the same syntax as the expression which produces the desired value, and the amazing oversight which lead to the lack of a template typedef), C++ has produced some good results in this area. Because of the way that C++ was designed, most of the expressive defects of the language can be hidden within library code and has little impact on the end user.
In fact, if you really wanted to say that C++ is the "implementation of some concept X" it would be fair to say that C++ is the implementation of "compartmentalized abstraction". What I mean by this is that people who implement libraries such as Blitz++ and Pooma are free to work within the language at a much higher level of detail and abstraction than is imposed of necessity on the application programmer.
Equally important, the evolution of C++ is a response to what people learn by actually writing programs in the language. C++ as it stands has enough support for genericity and PP to allow the community to experiment with the language in practical settings.
There is nothing that bothers me more than to see the failings of C++ "exposed" against the academic standard of "designed by concept".
Neither are we talking about a language designed by committee. What we are really talking about here is a language "designed by community"--equal measures of wisdom and warts pureed into a fine paste which nevertheless seems to get the job done.
Five years down the road it will be time for that community to reflect on the experience gained with genericity as it now exists and, hopefully, continue to listen and respond to the issues which arise from within.
It's a big mistake to presume that everything in the river which feels the same tug is destined to wind up on the same beach.
This same thing has applied to 3D imaging for audio systems for years. Someone announces incredible realism that bites you on the earlobes and then you find out your head has to be placed in a sweet spot the size of a grapefruit in order to hear the effect.
I sometimes wear prisms to compensate for a lazy eye. You quickly realize that the whole vision thing is a lot more complicated than the doctor lets on. First of all, there is a chromatic effect where red and blue colours are on focal plains 5mm apart (at monitor distance). Then there is the fact that the two lenses have a different field size because my near-sightedness is slightly different in each eye--which further complicates the problems I have keeping my eyes pointed in the same direction.
I'll believe in these new technologies when the description is precise enough that I can calculate what effect my prisms would have when viewing these screens.
Completely contrary to the implications of the post, even if the government had successfully broken M's encryption, they would still press for him to publicly disclose his keys. The life blood of an intelligence service is to create ambiguity and uncertainty about what capabilities and resources you have at your disposal.
Until they obtain or manufacture a plausible cover, they must at least pretend that they can't break these codes.
Even as far back as Enigma, the vast majority of the vital intelligence gathered on German activities was concealed operationally, often at great cost.
It has been a theme in BS's writings for a long time that cryptanalysis is difficult, expertise is rare, and the process is long and expensive.
On the basis of that argument it would seem that one could make a good case to see a proliferation of diverse algorithms for niche purposes. This is not protection via obscurity, but rather a direct attack on one of Mallet's most limited resources: the number of good analysts he is able to employ.
The opposing side of the argument seems to be that it is difficult to construct a strong cypher. I've never understood this argument.
What is indeed difficult is to contruct a strong cypher within the parameters of the NIST guidelines: small, fast, and dense.
But what about a custom cypher with a 512 byte disk sector as the underlying block and no desire to run in all the fancy cypher block modes or error recovery properties? What about applying 16 circular rounds on 8-byte subblocks with a data-directed component somewhere in the middle? (The usually rejoiner is that the theory of data-directed methods is not well understood; but that's precisely the property I'm seeking).
It seems to me that all the important criteria (bit diffusion, non-linearity, differential cryptanalysis) are easier to achieve given a larger mixing bowl (e.g. 512 bytes) with a much deeper chain length on the primitive cypher operations.
So why is it that the "large mixing bowl" approach, which seems to require much less expertise, is rarely seen in practice or commended for the advantage is appears to offer?
It seems to me that diversity is an unfair causualty in the war against obscurity by virtue of the exact reason why it should be desired: that cryptanalsysts just don't have the time to cope with it.
Totally flawed. She can't pay tax on something she has never received. And what has she received?
At best you could argue that she has received $70,000 in the form of pleasure on taking risks. It sure sounds dumb. But you could argue this based on a commodity market for gambling as a form of entertainment.
However, if she engaged in this activity knowing that her debts were not legally enforceable she has in fact not taken any risk at all. It then becomes difficult to argue that she has received $70,000 in pleasure from a risk she never took.
And she hasn't received any nbet cash gain either. So there's not much here to pay taxes on and I don't see that the IRS has anything to do with it.
The reasoning here lacks depth.
Even the investment industry is regulated as to what kinds of investments one is able to make "on margin". Gambling on margin is the worst of all.
I see no reason at all why gambling and credit need to be linked. The whole concept of credit is that it enables a deferred return to the person obtaining the credit. A sane society requires a balance between risk and reward.
People who extend credit by throwing money into a burning house ought not be relying on the instruments of society to extract it again.
One has to bear in mind that what we are calling "gambling" here is not symmetric: only one party is gambling in any real sense; the other party is reaping highly predictable profits.
However, when the casino extends credit to the unworthy the situation does in fact become pleasingly symmetric. Fair enough. But let's not waste the resources of the court defending the stupidity of the casino.
If you are seeking perfection: Glenn Gould plays Bach or the Bach cello suites.
Bonehead. Anyone who can type at a half
decent speed suffers auxiliary verb
lossage. Chomsky's theory of traces
partially explains this phenomena: parts
of the sentence structure which vary
based on how the sentence is cast happen
late enough in the process that sometimes
it doesn't catch up to fast moving fingers.
Anyone who can type fast enough to lose
an auxiliary is most likely to be highly
literate.
I guess it seems obvious to you that
any variety of mechanical imperfection
implies a defective intelligence. But
strangely, people smarter than you don't
hold to the same view.
What is it that makes everyone think that the government agencies don't already have this technology?
If you don't think these agencies are capable of keeping important technologies all to themselves you should dig up the history of undersea channel microphones.
And what is this business about machines suddenly overtaking humans on a "perceptual" basis? Technology has long held the advantage over humans in most fundamental categories.
The historical problems with noise filtering were entirely due to the fact that we didn't know how to solve the problem. Finally these cloistered scientists have got off their asses and figured out what they were doing wrong all along.
The only "breakthrough" here is that we learn that the "insurmountable" human advantage accrues to a neuronal system which can be replicated (and even improved) with a model consisting of eleven neurons.
Wow. What a huge edge the human being has over the machine.
But don't worry. Our "innate" advantage in searching complex problem spaces is probably safe for another ten years.
What is it that makes everyone think that the government agencies don't already have this technology? If you don't think these agencies are capable of keeping important technologies all to themselves you should dig up the history of undersea channel microphones. And what is this business about machines suddenly overtaking humans on a "perceptual" basis? Technology has long held the advantage over humans in most fundamental categories. The historical problems with noise filtering were entirely due to the fact that we didn't know how to solve the problem. Finally these cloistered scientists have got off their asses and figured out what they were doing wrong all along. The only "breakthrough" here is that we learn that the "insurmountable" human advantage accrues to a neuronal system which can be replicated (and even improved) with a model consisting of eleven neurons. Wow. What a huge edge the human being has over the machine. But don't worry. Our "innate" advantage in searching complex problem spaces is probably safe for another ten years.
I've had the Shaw service for 18 months and so far it has been mostly excellent. There was a couple of weeks of DNS irregularity and two or three days of network downtime altogether.
I *frequently* see 600KB/s (bytes!) when downloading from big sites such as Intel or ESPN or AltaVista.
The Shaw network uses the Terayon technology which is based on spread spectrum concepts. This means that all the available upstream channels broadcast simultaneously on the same frequencies and the head node sorts it all out.
The algorithm for allocating the available spread spectrum downstream channels can be a bit of problem when playing Quake in the evening. There are something like 128 64K-bit channels each of which can be assigned to a different user on 10mS slices (I forget the exact numbers and I haven't even checked the arithmetic). But it works out to a situation where a very large number of low-bandwidth streams become a bit choppy (you don't get slices quite as often as you might like).
I've also heard a rumour that you hack the box somewhat with SNMP protocol but I don't know the details of how this is done.
I'm not sure that Shaw is any better than Rogers and I was ready to find lots of faults with this offering and there simply haven't been any worth mentioning for as long as I've subscribed.
Futhermore, the representatives have insisted that they are not in the process of implementing upstream bandwidth caps. It might that the Terayon technology is less sensitive to the abuses which I know are going on (e.g. sharing copies of the Phantom Menace).
We are fortunate to also have ADSL here but the economics are such that only businesses make much use of it.
We really have nothing much to complain about--yet.