One risk with this is that it builds an infrastructure of content rating, marking and censorship. Such an infrastructure would have a lot more uses than just age control.
I disagree with your basic assertion that these things are Mathematics, i.e. the "scary mathematics". I think that's only true if you consider that any discipline that uses any algorithms that are based on knowledge derived from mathematics, that that discipline *is* mathematics. By the same principles, baseball would famously be a mathematical discipline, since much equation solving must be performed to algorithmically catch a ball.
It's simply not true! Take compilers and data structures. These are two fundamental things that it's hard to get a deep understanding of programming without. But compilers are easy to understand *intuitively*, without any recourse to mathematics - and I should know, I work on a compiler. Similarly, understanding data structures is a requirement of being a competent programmer. The basic techniques, such as lists, trees, graphs, basic sorting, searching and pattern matching, are all intuitively learnable in empirical, practical terms. For example, quicksort is easily understood once you've mastered recursion and how it splits problems into smaller, simpler problems, and similarly all sorts of tree, parsing and pattern-matching problems, and various combinatoric searching solutions build on nothing more than basic recursion.
My point is that these things can easily be understood, applied and extended without any formal mathematics. I think that labeling these things as "mathematics" is only useful if you're intent on point-scoring in favour of deeper mathematical training.
This is not to disparage mathematical training, of course. I just wanted to point out that your premises don't support your arguments.
The most important thing to do is use rxvt as your terminal, making sure you add some appropriate lines to your.Xdefaults file to customize it. It's far superior to the console window in Windows.
These days I live in bash on cygwin. Mount your C: drive on/c, and write a few wrapper utilties using cygstart and $(cygpath -w ), and you'll soon be in a much better place.
Definitely. And anyone with a variation on "but if you don't have anything to hide, you've got nothing to fear", well, everybody has at least something to hide. And even then, "evidence" could be fabricated.
Quis custodiet ipsos custodes? The USA is due a real scandal on data privacy: not just identity theft risk like the leaking of credit card details, but a real miscarriage of justice. It's just a matter of time, and better laws won't come until after the scandal.
The point you miss is that computers don't need to get faster. All they need to do is simulate the human brain; brain scanning combined with neuron simulation on a massively parallel scale permits a lot of possibilities, especially if you play a little loose with ethics.
A lambda expression is compiled as either an anonymous delegate (just like C# 2.0), or an Expression> tree, depending on the declaration of the method you're passing the lambda expression to.
So, c => c.City == "London" translates to: delegate(City c) { return c.City == "London"; }. That is, 'c' is an argument passed in when the method you're calling calls the delegate (a.k.a. lambda expression) you've passed in.
However, (c.City == "London") is simply an expression using 'c' which is in scope already, in the scope of the outer caller.
The neat think about the lambda expressions is that if the callee desires, it can take in an expression tree instead of a delegate reference. This means it can package up the expression tree and export it across the network to process it elsewhere, for example: this is the case for DLINQ, where the packaged format is a dynamically generated SQL expression.
All good SF simply uses SF as a prop, an artistic device, to pose a question that wouldn't be reasonable if "real life" applied.
If "Hard SF" doesn't do this, and instead tries to be "cutting edge", or "predict the future" (as many other non-SF fans try to judge SF), then I don't think many "Hard SF" are what they think they are!
If you'd used Delphi, you'd realize you were wrong. Delphi's class libraries can teach one an awful lot about OO design in an unmanaged world; how to create a useful design-time architecture in an object model; how a good PME (properties, methods, events) environment should look. Also, there's some features in Pascal that aren't really replicated in other modern imperative languages apart from Ada (subrange types, sets, truly typesafe enums).
Before Anders Heiljsberg (the guy behind Delphi) moved on and created C#, Delphi was the source of the One True Way of UI programming on Windows.
You talk about Java's threading support blowing C/C++ out of the water. It's interesting: Delphi has extremely easy to use threads.
However, I do agree that it's important that more people learn the basics of functional languages, their semantics and implementation details (in terms of compilation and runtime libraries). I'd also throw in declarative rule-based languages: learn something like Prolog as well. Finally, one cannot be a truly well-rounded programmer without implementing at least one compiler from scratch.
For a stable Linux distribution, you should experiment with Debian.
I do have some recent version of Debian (R3, I think) on 7 CDs, although I had difficulty trying to get the installer to install all packages. There were some issues, I don't recall them now, it was several months ago.
The best feature of Debian is the way is the fabled system update feature: apt.
None of my Linux systems have ever been connected to the Internet, seeing as I don't have Internet access at home.
This is the reason I'm looking for single stable quality distro to experiment with: something I can play with without finding out I have to upgrade X to Y in order to try out feature y, but in order to get Y I must download Z, A & B, while B requires C & D, and C requires... etc. You get the idea. When your system doesn't have Internet access it isn't clear what to download at work to bring home and install. Invariably I end up with some package missing, and eventually I just give up.
Are there any Linux distributions which specialize in modern, up to date, bug-free, non-beta, only >1.0 software?
I've played around with dozens of distributions, only to be turned off them by discovering various half-baked flaky apps mixed in with more polished apps. In other words, I should never see a core dump more than (say) once a month, while trying out *all* the programs in the distro.
I'm looking for a distro with consistently high QC, in terms of feature completeness and bug-free implementation. Who should I be going with?
It would be great if GCC (or more to the point, GDB) didn't pessimize the co-development of an intelligent IDE, and in particular, a good debugger. That would require a lot of stability for debugger symbol formats along with lots of extra symbol table information, such as class structures etc.
"If no one claims the copyright in a work," they write, "it appears likely that the public benefit of having access to the work would outweigh whatever copyright interest there might be."
This indicates that the copyright office leans extremely strongly towards copyright interests. Is there any indication that they (the US copyright office) have the same perspective as most of the rest of us re copyright as enforced monopoly etc.?
This is multiple Linuxes running on a VMM: Virtual Machine Monitor. The Linuxes run side by side, none run inside each other.
The technique takes advantage of the multiple rings (0-3) on Intel. Normally Linux (and other kernels) run on ring 0, but with Xen the Xen VMM runs on ring 0 while Linux and other guest OSs run on ring 1, while user-mode programs continue to run on ring 3.
Eclipse is crap with the CDT plugin. Debugging just plain doesn't work well in a project of any significant complexity, with any C++ data types of anything approaching something realistic.
cpu core simulators, c compilers, hardware synthesis
These are all areas where functional programming can be successfully applied (though compilers more than any).
However, my broader point was that a language with an intermediate level of concurrency will be best placed to harness these multiple cores.
Most of our current languages and application architectures aren't embarrassingly parallel like (for instance) a software build process.
When programs are written with the von Neumann architecture in mind they end up being more serial than they could be. With more cores on the die, frequency speedups are going to be constrained, and these kind of programs aren't going to get faster.
The quote you've posted is generally true of any self-measured benchmark result posted by any interested party. I'm not sure it's relevant in the context of general purpose computing program parallelism.
I know personally that for the kind of applications that will run on the (software) architecture I'm currently co-designing will hugely benefit from multi-core systems.
Speaking very generally, the challenge in most concurrent applications, whether they use EPIC / instruction level parallelism or thread/process-level parallelism, is making sure that the things that work in parallel don't touch the same data, or if they do it's on a read-only basis. Applications can be speeded up roughly proportional to how disconnected / compartmentalized the data is and how local to the data the actions are.
Considering that, I'm not sure that scientific computing applications are as amenable to parallelism as general purpose computing is, since scientific computing is typically very dependent on large matrix operations, and of course matrix operations are essentially non-local and very-connected by definition.
To reiterate and summarize, I would be more optimistic on massively multi-core chips on the general-purpose computing front, rather than the scientific-computing front.
Sure, that's going to fail because it effectively gives disproportionate weight to the low bits in the random number.
Shuffling should look more like:
for (int i = 0; i < list.Length; ++i)
list.Swap(i, Random(list.Length));
where Random(int x) looks somewhat like:
return (int) (random() * x);
where random() returns a double.
Ideally (with a long enough list) you'd leave the next few songs out of the shuffle, but do the next shuffle sooner than a full rotation, to get two effects:
Using Amdahl's Law as an argument against massively parallel processing is not valid. This is because (F, the fraction of the calculation that is sequential only) can be very close to zero for many practical applications. Thus very high speedups are possible using massively many processors. Gustafson's experiments are just examples of these applications.
Slashdot Mirror
... The only teeth strong enough to eat other teeth.
That's what I'm holding out for.
One risk with this is that it builds an infrastructure of content rating, marking and censorship. Such an infrastructure would have a lot more uses than just age control.
I disagree with your basic assertion that these things are Mathematics, i.e. the "scary mathematics". I think that's only true if you consider that any discipline that uses any algorithms that are based on knowledge derived from mathematics, that that discipline *is* mathematics. By the same principles, baseball would famously be a mathematical discipline, since much equation solving must be performed to algorithmically catch a ball.
It's simply not true! Take compilers and data structures. These are two fundamental things that it's hard to get a deep understanding of programming without. But compilers are easy to understand *intuitively*, without any recourse to mathematics - and I should know, I work on a compiler. Similarly, understanding data structures is a requirement of being a competent programmer. The basic techniques, such as lists, trees, graphs, basic sorting, searching and pattern matching, are all intuitively learnable in empirical, practical terms. For example, quicksort is easily understood once you've mastered recursion and how it splits problems into smaller, simpler problems, and similarly all sorts of tree, parsing and pattern-matching problems, and various combinatoric searching solutions build on nothing more than basic recursion.
My point is that these things can easily be understood, applied and extended without any formal mathematics. I think that labeling these things as "mathematics" is only useful if you're intent on point-scoring in favour of deeper mathematical training.
This is not to disparage mathematical training, of course. I just wanted to point out that your premises don't support your arguments.
My one - Ireland.
The most important thing to do is use rxvt as your terminal, making sure you add some appropriate lines to your .Xdefaults file to customize it. It's far superior to the console window in Windows.
/c, and write a few wrapper utilties using cygstart and $(cygpath -w ), and you'll soon be in a much better place.
These days I live in bash on cygwin. Mount your C: drive on
The problem with the "pay up" strategy is that it will encourage more of these cockroaches out of the shadows.
Definitely. And anyone with a variation on "but if you don't have anything to hide, you've got nothing to fear", well, everybody has at least something to hide. And even then, "evidence" could be fabricated.
Quis custodiet ipsos custodes? The USA is due a real scandal on data privacy: not just identity theft risk like the leaking of credit card details, but a real miscarriage of justice. It's just a matter of time, and better laws won't come until after the scandal.
The point you miss is that computers don't need to get faster. All they need to do is simulate the human brain; brain scanning combined with neuron simulation on a massively parallel scale permits a lot of possibilities, especially if you play a little loose with ethics.
A lambda expression is compiled as either an anonymous delegate (just like C# 2.0), or an Expression> tree, depending on the declaration of the method you're passing the lambda expression to.
So, c => c.City == "London" translates to:
delegate(City c) { return c.City == "London"; }. That is, 'c' is an argument passed in when the method you're calling calls the delegate (a.k.a. lambda expression) you've passed in.
However, (c.City == "London") is simply an expression using 'c' which is in scope already, in the scope of the outer caller.
The neat think about the lambda expressions is that if the callee desires, it can take in an expression tree instead of a delegate reference. This means it can package up the expression tree and export it across the network to process it elsewhere, for example: this is the case for DLINQ, where the packaged format is a dynamically generated SQL expression.
You can use VS2005 Beta 2 in a release environment: it's got a Go Live license.
I'm currently writing a large project in C# 2.0, for real-world deployment. Can't wait for C# 3.0.
A 6-bit counter only counts to 63 unsigned.
All good SF simply uses SF as a prop, an artistic device, to pose a question that wouldn't be reasonable if "real life" applied.
If "Hard SF" doesn't do this, and instead tries to be "cutting edge", or "predict the future" (as many other non-SF fans try to judge SF), then I don't think many "Hard SF" are what they think they are!
If you'd used Delphi, you'd realize you were wrong. Delphi's class libraries can teach one an awful lot about OO design in an unmanaged world; how to create a useful design-time architecture in an object model; how a good PME (properties, methods, events) environment should look. Also, there's some features in Pascal that aren't really replicated in other modern imperative languages apart from Ada (subrange types, sets, truly typesafe enums).
Before Anders Heiljsberg (the guy behind Delphi) moved on and created C#, Delphi was the source of the One True Way of UI programming on Windows.
You talk about Java's threading support blowing C/C++ out of the water. It's interesting: Delphi has extremely easy to use threads.
However, I do agree that it's important that more people learn the basics of functional languages, their semantics and implementation details (in terms of compilation and runtime libraries). I'd also throw in declarative rule-based languages: learn something like Prolog as well. Finally, one cannot be a truly well-rounded programmer without implementing at least one compiler from scratch.
But that's only my opinion.
For a stable Linux distribution, you should experiment with Debian.
... etc. You get the idea. When your system doesn't have Internet access it isn't clear what to download at work to bring home and install. Invariably I end up with some package missing, and eventually I just give up.
I do have some recent version of Debian (R3, I think) on 7 CDs, although I had difficulty trying to get the installer to install all packages. There were some issues, I don't recall them now, it was several months ago.
The best feature of Debian is the way is the fabled system update feature: apt.
None of my Linux systems have ever been connected to the Internet, seeing as I don't have Internet access at home.
This is the reason I'm looking for single stable quality distro to experiment with: something I can play with without finding out I have to upgrade X to Y in order to try out feature y, but in order to get Y I must download Z, A & B, while B requires C & D, and C requires
Are there any Linux distributions which specialize in modern, up to date, bug-free, non-beta, only >1.0 software?
I've played around with dozens of distributions, only to be turned off them by discovering various half-baked flaky apps mixed in with more polished apps. In other words, I should never see a core dump more than (say) once a month, while trying out *all* the programs in the distro.
I'm looking for a distro with consistently high QC, in terms of feature completeness and bug-free implementation. Who should I be going with?
It would be great if GCC (or more to the point, GDB) didn't pessimize the co-development of an intelligent IDE, and in particular, a good debugger. That would require a lot of stability for debugger symbol formats along with lots of extra symbol table information, such as class structures etc.
"If no one claims the copyright in a work," they write, "it appears likely that the public benefit of having access to the work would outweigh whatever copyright interest there might be."
This indicates that the copyright office leans extremely strongly towards copyright interests. Is there any indication that they (the US copyright office) have the same perspective as most of the rest of us re copyright as enforced monopoly etc.?
This is multiple Linuxes running on a VMM: Virtual Machine Monitor. The Linuxes run side by side, none run inside each other.
The technique takes advantage of the multiple rings (0-3) on Intel. Normally Linux (and other kernels) run on ring 0, but with Xen the Xen VMM runs on ring 0 while Linux and other guest OSs run on ring 1, while user-mode programs continue to run on ring 3.
Visual Studio
Eclipse is crap with the CDT plugin. Debugging just plain doesn't work well in a project of any significant complexity, with any C++ data types of anything approaching something realistic.
Richard Grimes wrote a book on writing .NET apps with Managed C++.
Microsoft are changing the Managed C++ syntax to a "C++/CLI binding", in a way which is completely incompatible with Managed C++.
I think Richard Grimes is just really pissed off that Microsoft screwed him.
cpu core simulators, c compilers, hardware synthesis
These are all areas where functional programming can be successfully applied (though compilers more than any).
However, my broader point was that a language with an intermediate level of concurrency will be best placed to harness these multiple cores.
Most of our current languages and application architectures aren't embarrassingly parallel like (for instance) a software build process.
When programs are written with the von Neumann architecture in mind they end up being more serial than they could be. With more cores on the die, frequency speedups are going to be constrained, and these kind of programs aren't going to get faster.
Until the language changes.
The quote you've posted is generally true of any self-measured benchmark result posted by any interested party. I'm not sure it's relevant in the context of general purpose computing program parallelism.
I know personally that for the kind of applications that will run on the (software) architecture I'm currently co-designing will hugely benefit from multi-core systems.
Speaking very generally, the challenge in most concurrent applications, whether they use EPIC / instruction level parallelism or thread/process-level parallelism, is making sure that the things that work in parallel don't touch the same data, or if they do it's on a read-only basis. Applications can be speeded up roughly proportional to how disconnected / compartmentalized the data is and how local to the data the actions are.
Considering that, I'm not sure that scientific computing applications are as amenable to parallelism as general purpose computing is, since scientific computing is typically very dependent on large matrix operations, and of course matrix operations are essentially non-local and very-connected by definition.
To reiterate and summarize, I would be more optimistic on massively multi-core chips on the general-purpose computing front, rather than the scientific-computing front.
Shuffling should look more like:where Random(int x) looks somewhat like:where random() returns a double.
Ideally (with a long enough list) you'd leave the next few songs out of the shuffle, but do the next shuffle sooner than a full rotation, to get two effects:
Trouble is, the sequential-only fraction used in Amdahl's law is a lot smaller than it's usually given credit for.
. html
For example, from http://www.cis.temple.edu/~shi/docs/amdahl/amdahl
Using Amdahl's Law as an argument against massively parallel processing is not valid. This is because (F, the fraction of the calculation that is sequential only) can be very close to zero for many practical applications. Thus very high speedups are possible using massively many processors. Gustafson's experiments are just examples of these applications.