Actually, your rule 0 is implied by rule 2: Rule 2 says that not more information should be revealed than necessary. For retrieving a web page, the only identifying information needed is the IP number to send it to.
I'd propose to add three months instead of two. This would save another month of daylight. And while at it, just add two months at the beginning as well. Also, to simplify remembering the day, set the start of DST to the first day of the month, and the end of DST to the last (so a month is either completely DST, or not at all). Doing all those, DST will start at Jan 1, and end at Dec 31. Now just let it start at the beginning of Jan 1, and end at the end of Dec 31. This will simplify DST, as you have only to remember one time, where you set the clock back, and immediatly undo that operation. Of course you could also simply note that this combination is a no-op anyway and skip it completely.:-)
In Soviet Russia, chess plays you. Imagine a Beowulf cluster of chess-playing spam filters. 1. Train a spam filter to play chess. 2. ??? 3. Profit! But does a bayesian spam filter run Linux?
You misunderstand. You should look up game #42 in the appropriately sorted list of all possible games. It is the game where both parties choose the best move each time.
... to digitally sign the web page, and give a key fingerprint on paper to the customers (so they can check they are really installing the correct public key and not a fake). Signing the page would not only ensure that the page comes truly from the bank, but also that there's no malicious change in it (as might be done through a man-in-the-middle attack, e.g. to send the data to another than the bank's server).
Does HTTP support signed web pages (as opposed to just encrypted transmission)?
Note that the authenticity verification would not depend on some third-party certificate (where you have to trust some certification agency possibly unknown to you), but on a paper sent to you on paper by the bank itself. Thus you have only to trust your bank (if you don't trust that, you'd better change it anyway), and fraud would need to intercept both the bank web site and the postal delivery. Which I think will be beyond the ability of the typical phisher.
I don't see why the fact that vtune isn't supported for non-Intel CPUs has any relation about what the Intel compiler supports.
But more to the point: If the Intel compiler is done as product for Intel processors only, then it would be nonsense to add a completely separate codepath for other processors. The most logical thing would be to ignore the possibility of other processors completely (after all, if someone tries to run the code on non-Intel processors, he's outside the published specifications anyway). One could also argue that a test followed by an error message for non-Intel CPUs could be meaningful. But providing a different code path for an architecture which you simply do not support is nothing any sane programmer would do. Which means the different code path must serve another purpose.
Live insurance doesn't actually compensate for the life. It compensates for financial losses which are caused as side effect of a death.
Of course there are some people who see that differently. Those are the people killing someone to get their life insurance. Fortunately that is not a generally accepted value judgement.
teach young children about crime and punishment - make them understand that engaging in criminal activity will result in capture and they will be punished severely
More importantly: Teach them that criminal activity is wrong, immoral, and causes harm. I don't write viruses not because of fearing to be caught if I did, but because I know it does much damage to other people, and I'm moral enough to not want to do that.
Fear of punishment is only the last line of defense. As soon as you start relying on it as only line of defense, your doomed. Because it is only effective as long as one believes he'll get caught.
If you had the opportunity to kill someone whom you definitely don't like, and that opportunity would be 100% safe (i.e. there's no imaginable way anyone would find out that you did it). That is, you'd just know that this would not be punished, ever. Would you actually do it? I hope not.
I never liked the comma-separated list method. The problem is that it doesn't work like it seems to work. Anyone "unsuspecting" who sees
v += 1, 2, 3, 4, 5, 6, 7, 8, 9
immediatly thinks
v += (1, 2, 3, 4, 5, 6, 7, 8, 9)
i.e. the list of those numbers is added to v. But don't try to type the second line! It will compile quite fine. But it will not do what you want, but rather only append 9 to the vector. However the "intuitiveness" of the method completely relies on that wrong intuition. The true mechanism at work isn't quite intuitive.
BTW, I consider using operator+= for this purpose a bad idea, too.
template<class Float> class Vector { // math vector using arbitrary float type }
template<class Float1, class Float2>
Vector<typeof(Float1() + Float2())> operator+(Vector<Float1> const& a,
Vector<Float2> const& b) { //... }
//...
int main() {
Vector<double> v;
Vector<MyHighPrecisionUserDefinedFloat> w; //...
Vector<MyHighPrecisionUserDefinedFloat> x = v + w; // there's an operator+ for double+MyHighPrecisionUserDefinedFloat // returning MyHighPrecisionUserDefinedFloat //... }
Yes, there's the possibility to do type traits, but that doesn't scale (even with only built-in types you have char, signed char, unsigned char, short, unsigned short, int, unsigned int, long, unsigned long, float, double and long double, that makes 12 entries for one argument; given that + has two of them and any two of them can be added, you'd actually need 144 traits specializations to cover all built-in types. And for the first user-defined type, you'll likely add 25 more: 12 with built-in as first operand and user-defined as second, 12 the other way round, and one for sum of two user-defined). And all of that just to state something which the compiler already knows anyway.
Well, for cars, the applied solution is the driving license. You have to proof that you are able to drive safely to get it, and if you are caught to drive dangerously, the police can take it away. So going by your analogy, maybe there should be a drug license? (And BTW, drinking too much alcoholics can be dangerous, too, so maybe there should be a drinking license. However, this could cause problems with drunken driving: Should they take away the driving license, the drinking license, or both?:-)
Well, I actually plan to be at the top of the list of the world's richest people in 2015. Unfortunately I too have no idea how I'll get there.:-)
Re:I'm all for science/technology/astronomy but...
on
Back to Moon in 2015?
·
· Score: 1
Also, since there's gravity on the moon, working there is probably much easier than working in zero gravity. Not to mention that long stays in zero gravity don't do good to your body.
It sounds a bit similar to that new Microsoft keyboard, you know the one where it moves the keys round depending on which are most frequently used, and begins to hide those that haven't been used for a while.
Actually it can't (because your multiplication might overflow even if the result doesn't). But I already posted what I think is the optimal version (without loops, and without overflow issues).
Thinking about it, the branch might be more costly than an addition and an xor, so here's another version which also avoids the if:
As my previous version, this doesn't suffer from possible overflow.
According to the cost of parallelization: It's of course true that it has memory cost. And of course it would be silly to make N threads (which each would do exactly 1 addition, namely adding their value of i to 0, which of course could be easily optimized away), and then add all those values together (which would be exactly the work of the single-threaded version anyway). I'd expect the number of threads to be vastly less than N.
According to the time cost: This just means that parallelization only makes sense for N much larger than the number of threads. if N is of the order of a milliard, then the time to synchronize the four threads should be negligible (after all, you don't synchronize in every loop cycle, but only the ends of the thread). All of course under the (sensible) assumption that N_threads << N.
Yes, compilers are not parallelizable. But multithreading doesn't necessarily mean parallelization.
I could for example imagine the parser to run on one thread, and the single-function optimizer on another thread. Every time the aprser has finished parsing a function, it tells the optimizer thread, which then immediatly starts optimizing it, while the parser starts parsing the next function. The later inter-function optimization passes then work with the pre-optimized functions which were mostly optimized during parse (given that parsing includes getting the source from disk, which will most likely block, I really wonder if a multithreaded compiler would even be an advantage on a single-core system).
Now make the code parallel. Simple: If there are 4 threads,
thread 1 adds 1, 5, 9,... into accumulator_1,
thread 2 adds 2, 6, 10,... into accumulator_2,
thread 3 adds 3, 7, 11,... into accumulator_3,
thread 4 adds 4, 8, 12,... into accumulator_4.
After all threads have finished, just do accumulator = accumulator_1 + accumulator_2 + accumulator_3 + accumulator_4.
Of course, for this specific piece of code, the perfect optimization would be:
void AccumulateLoopCount(int N) {
register int tmp = N>>1;
if (N%2)
return tmp*(N+1);
else
return N*(tmp+1); }
This code of course is hardly parallelizable;-)
If you want explicitly unparallelizable code, you'll have to use a non-associative operation, e.g.
double nest(double (*f)(double), int n, double x) {
for (int i=0; i<n; ++i)
x = f(x);
return x; }
This can still be (partially) unrolled e.g. like this:
double nest(double (*f)(double), int n, double x) {
for (int i=0; i < (n>>2); ++i)
{
x = f(x);
x = f(x);
x = f(x);
x = f(x);
}
switch (n&3)
{
case 3:
x = f(x);
case 2:
x = f(x);
case 1:
x = f(x);
case 0:
break;
}
return x; }
Slashdot Mirror
The fact that Microsoft doesn't make money from it :-)
Actually, your rule 0 is implied by rule 2: Rule 2 says that not more information should be revealed than necessary. For retrieving a web page, the only identifying information needed is the IP number to send it to.
I'd propose to add three months instead of two. This would save another month of daylight. And while at it, just add two months at the beginning as well. Also, to simplify remembering the day, set the start of DST to the first day of the month, and the end of DST to the last (so a month is either completely DST, or not at all). Doing all those, DST will start at Jan 1, and end at Dec 31. Now just let it start at the beginning of Jan 1, and end at the end of Dec 31. This will simplify DST, as you have only to remember one time, where you set the clock back, and immediatly undo that operation. Of course you could also simply note that this combination is a no-op anyway and skip it completely. :-)
In Soviet Russia, chess plays you.
Imagine a Beowulf cluster of chess-playing spam filters.
1. Train a spam filter to play chess. 2. ??? 3. Profit!
But does a bayesian spam filter run Linux?
Did I forget any?
You misunderstand. You should look up game #42 in the appropriately sorted list of all possible games. It is the game where both parties choose the best move each time.
... to digitally sign the web page, and give a key fingerprint on paper to the customers (so they can check they are really installing the correct public key and not a fake). Signing the page would not only ensure that the page comes truly from the bank, but also that there's no malicious change in it (as might be done through a man-in-the-middle attack, e.g. to send the data to another than the bank's server).
Does HTTP support signed web pages (as opposed to just encrypted transmission)?
Note that the authenticity verification would not depend on some third-party certificate (where you have to trust some certification agency possibly unknown to you), but on a paper sent to you on paper by the bank itself. Thus you have only to trust your bank (if you don't trust that, you'd better change it anyway), and fraud would need to intercept both the bank web site and the postal delivery. Which I think will be beyond the ability of the typical phisher.
I don't see why the fact that vtune isn't supported for non-Intel CPUs has any relation about what the Intel compiler supports.
But more to the point: If the Intel compiler is done as product for Intel processors only, then it would be nonsense to add a completely separate codepath for other processors. The most logical thing would be to ignore the possibility of other processors completely (after all, if someone tries to run the code on non-Intel processors, he's outside the published specifications anyway). One could also argue that a test followed by an error message for non-Intel CPUs could be meaningful. But providing a different code path for an architecture which you simply do not support is nothing any sane programmer would do. Which means the different code path must serve another purpose.
Live insurance doesn't actually compensate for the life. It compensates for financial losses which are caused as side effect of a death.
Of course there are some people who see that differently. Those are the people killing someone to get their life insurance. Fortunately that is not a generally accepted value judgement.
More importantly: Teach them that criminal activity is wrong, immoral, and causes harm.
I don't write viruses not because of fearing to be caught if I did, but because I know it does much damage to other people, and I'm moral enough to not want to do that.
Fear of punishment is only the last line of defense. As soon as you start relying on it as only line of defense, your doomed. Because it is only effective as long as one believes he'll get caught.
If you had the opportunity to kill someone whom you definitely don't like, and that opportunity would be 100% safe (i.e. there's no imaginable way anyone would find out that you did it). That is, you'd just know that this would not be punished, ever. Would you actually do it? I hope not.
Easy: Filter all words which have any of 'd', 'e', 'm', 'o', 'c', 'r', 'a' or 'y' in it.
:-)
Of course the above sentence would then just read: "in it".
I guess encrypted e-mail will be censored because they cannot check it.
But steganography may help.
I never liked the comma-separated list method. The problem is that it doesn't work like it seems to work. Anyone "unsuspecting" who sees
v += 1, 2, 3, 4, 5, 6, 7, 8, 9
immediatly thinks
v += (1, 2, 3, 4, 5, 6, 7, 8, 9)
i.e. the list of those numbers is added to v. But don't try to type the second line! It will compile quite fine. But it will not do what you want, but rather only append 9 to the vector. However the "intuitiveness" of the method completely relies on that wrong intuition. The true mechanism at work isn't quite intuitive.
BTW, I consider using operator+= for this purpose a bad idea, too.
... which in itself is a quite innovative way of innovating ;-)
Clippy? <gd&r>
To which the correct answer would be: I prefer web pages designed for visitors. If it's a commercial web site, replace "visitors" with "customers".
Which of course raises the question: Was it profitably viable?
Well, for cars, the applied solution is the driving license. You have to proof that you are able to drive safely to get it, and if you are caught to drive dangerously, the police can take it away. So going by your analogy, maybe there should be a drug license? (And BTW, drinking too much alcoholics can be dangerous, too, so maybe there should be a drinking license. However, this could cause problems with drunken driving: Should they take away the driving license, the drinking license, or both? :-)
Well, I actually plan to be at the top of the list of the world's richest people in 2015. Unfortunately I too have no idea how I'll get there. :-)
Also, since there's gravity on the moon, working there is probably much easier than working in zero gravity. Not to mention that long stays in zero gravity don't do good to your body.
That's still bad. I'l easily show you a keyboard design where all words can be typed from the home row. And the numbers, too!
... :-)
Ok, having 36 keys in a row isn't exactly convenient for typing
Yes, that's really impressive. I've seen an image of how it looks after some use. Note how the number of keys is reduced to the essential ones!
Actually it can't (because your multiplication might overflow even if the result doesn't). But I already posted what I think is the optimal version (without loops, and without overflow issues).
Thinking about it, the branch might be more costly than an addition and an xor, so here's another version which also avoids the if:As my previous version, this doesn't suffer from possible overflow.
According to the cost of parallelization: It's of course true that it has memory cost. And of course it would be silly to make N threads (which each would do exactly 1 addition, namely adding their value of i to 0, which of course could be easily optimized away), and then add all those values together (which would be exactly the work of the single-threaded version anyway). I'd expect the number of threads to be vastly less than N.
According to the time cost: This just means that parallelization only makes sense for N much larger than the number of threads. if N is of the order of a milliard, then the time to synchronize the four threads should be negligible (after all, you don't synchronize in every loop cycle, but only the ends of the thread). All of course under the (sensible) assumption that N_threads << N.
Yes, compilers are not parallelizable. But multithreading doesn't necessarily mean parallelization.
I could for example imagine the parser to run on one thread, and the single-function optimizer on another thread. Every time the aprser has finished parsing a function, it tells the optimizer thread, which then immediatly starts optimizing it, while the parser starts parsing the next function. The later inter-function optimization passes then work with the pre-optimized functions which were mostly optimized during parse (given that parsing includes getting the source from disk, which will most likely block, I really wonder if a multithreaded compiler would even be an advantage on a single-core system).