from every other article I've read on the topic, which say that the measured mass of the Higgs boson is exactly where it should be if the Minimally Supersymmetric Standard Model is correct; and too low for any non-supersymmetric theory.
Also, as well as supporting 3D input of course , it has a "2D -> 3D" mode where it tries to automatically convert 2D footage to 3D. I guess it detects moving objects and brings them to foreground or something. Can anyone who's tried viewing this tell me if it is ever worth doing?
There's more than one way a particle can get mass. The Higgs Mechanism gives the rest mass to the quarks, leptons, and electroweak bosons. The Higgs boson itself, and the neutrinos, get their mass from other mechanisms (which are not fully understood)
What's wrong with C is the function call conventions. Where a function needs the first few arguments placed into specific registers or the stack, and returns things in a specific way. This can be a performance bottleneck, because data needs to be moved around just to place it in the correct positions, and back again.
So what optimizers to is inline the functions, so they can avoid all the rigid restrictions placed by calling conventions, and the performance problems that come with them.
Sure, calling conventions provide a standardized way to deal with unknown functions that aren't in the same source file, but the biggest advantage of hand-coded ASM is that you don't necessarily need to use them.
None of those things are anything to do with C. As you say, if you need to publish a library then you have to confirm to some particular ABI, this is the same for any language. And if you don't then you don't.
In many cases, you're correct. In others, not so. It varies by compiler. This is one of the problems with the C language; it isn't equipped to deal well with multiple address spaces that overlap....you define non-standard keywords such as ROM, or you do run-time translation of addresses...
Having used various embedded compilers, I don't agree with this. The C standard is carefully designed to support this situation, a pointer of "void *" must be able to point to any of the address spaces. This means it's got to have more bits in it than the size of the address space of course, but this is fine and works well. (example - overlapping 16bit address spaces, the void* pointer needs to be 3 octets at least).
In this example, the compiler can offer non-standard keywords as well, so the programmer can use pointers of 2 octets at his own risk if that optimization in storage space is needed; and the compiler should flag an error (compile time if possible; otherwise runtime) if pointers to different address spaces are mixed.
There's only trouble with sloppy coders who don't adhere to standards, but what can you do about that?
Incidentally, this thread is one of the reasons I hate C.
Yeah. The threads fill up with the same old misconceptions that are fixed on page 1 if the posters actually read a book on C (excluding books by H Schildt I guess). In before "NULL != 0 sometimes" or "arrays are implemented as pointers"
No, he's right. On systems where your constants exist in a different medium than your variables (such as microcontrollers where variables are in RAM but constants are in flash), declaring a string as const or not const can have a big impact on what resources you eat up.
He's right , but your reason is not:)
Whether "first" is stored in the const data area or not depends on your compiler/linker settings. You can legally write char *post = "first"; in either case, just your program goes balls up if it does get stored in const data and you later try to write that data through 'post'. The 'good form' version of the code, i.e. char const *post, goes a long way toward preventing you from trying to write the const data area.
In the US you can receive some negative attention for saying you don't believe in any gods, so it might be rational for someone (especially a German immigrant in the 1940s) to follow the old advice: when in Rome, do as the Romans do.
Actually, I usually find that Atheists have a much worse understanding of science and don't understand why science can't disprove God (one big reason being that science is based on OBSERVATION, and you can't observe a lack of something).
Can you disprove that all emeralds will turn blue in the year 2017?
Do you believe they won't, or do you believe they may or may not and we'll have to wait to see?
It's completely unclear from the article whether they mean:
* 22 GWh produced over the period in question
* 22 GW average production over the period in question
* 22 GW peak production over the period in question
I have seen journalists change "unit-hours" to "units per hour" before, perhaps failing to understand the unit and assuming that the "missing per" was a typo; so I'd actually favour the first of these options. It's hard to imagine a solar plant generating 20x as much electricity as a nuclear plant.
Surely this is no news at all; the Sun has been measured as accurately as possible (given that it doesn't have a well-defined edge) by satellite telemetry long ago. This should perhaps be titled 'most accurate calculation by amateur Japanese without modern equipment' or something
I read TFA.. the algorithm is not broken and the seed isn't deducible from the output; all they've done is read the seed out of software auth running on a general purpose computing device.
This has always been possible in theory -- obviously, the computer software has to generate the output so it must have the seed in an accessible form; probably under several layers of obfuscation and encryption (which ultimately adds no security, as the software still has to be able to wade through it to get to the seed). It's very similar in concept to someone being able to obtain your PGP or SSH private keys if they have local access to your system.
There is no risk to people with a hardware auth device, unless the server is compromised (in which case this form of authentication is useless anyway).
Slashdot Mirror
from every other article I've read on the topic, which say that the measured mass of the Higgs boson is exactly where it should be if the Minimally Supersymmetric Standard Model is correct; and too low for any non-supersymmetric theory.
http://motls.blogspot.com/2012/07/why-125-gev-higgs-boson-isnt-quite.html?m=1
Has "smart card" (chip) payment technology really benefited anyone except... hm, having trouble thinking of anyone at all actually
Also, as well as supporting 3D input of course , it has a "2D -> 3D" mode where it tries to automatically convert 2D footage to 3D. I guess it detects moving objects and brings them to foreground or something. Can anyone who's tried viewing this tell me if it is ever worth doing?
...but only because it was $50 cheaper than the exact same model but non-3D version.
The guy tried to sell me 2 pairs of active 3D glasses for $110.. no thanks
There's more than one way a particle can get mass. The Higgs Mechanism gives the rest mass to the quarks, leptons, and electroweak bosons. The Higgs boson itself, and the neutrinos, get their mass from other mechanisms (which are not fully understood)
You should go to the bazaar for a beer, not the cathedral
What's wrong with C is the function call conventions. Where a function needs the first few arguments placed into specific registers or the stack, and returns things in a specific way. This can be a performance bottleneck, because data needs to be moved around just to place it in the correct positions, and back again.
So what optimizers to is inline the functions, so they can avoid all the rigid restrictions placed by calling conventions, and the performance problems that come with them.
Sure, calling conventions provide a standardized way to deal with unknown functions that aren't in the same source file, but the biggest advantage of hand-coded ASM is that you don't necessarily need to use them.
None of those things are anything to do with C. As you say, if you need to publish a library then you have to confirm to some particular ABI, this is the same for any language. And if you don't then you don't.
for_each is pretty useless, annoying and unclear
I think it's pretty clear:
list x;
for_each( begin(x), end(x), bar );
Hopefully even non-C++ people will realize that this calls bar() once for each of the members of x.
This is sort of redundant in C++11 because you could just go:
for( foo &a: x )
bar(a);
but for_each allows you to use existing predicates (with for_each_if and so on) ,
and you can put a lambda expression instead of "bar".
In many cases, you're correct. In others, not so. It varies by compiler. This is one of the problems with the C language; it isn't equipped to deal well with multiple address spaces that overlap. ...you define non-standard keywords such as ROM, or you do run-time translation of addresses...
Having used various embedded compilers, I don't agree with this. The C standard is carefully designed to support this situation, a pointer of "void *" must be able to point to any of the address spaces. This means it's got to have more bits in it than the size of the address space of course, but this is fine and works well. (example - overlapping 16bit address spaces, the void* pointer needs to be 3 octets at least).
In this example, the compiler can offer non-standard keywords as well, so the programmer can use pointers of 2 octets at his own risk if that optimization in storage space is needed; and the compiler should flag an error (compile time if possible; otherwise runtime) if pointers to different address spaces are mixed.
There's only trouble with sloppy coders who don't adhere to standards, but what can you do about that?
Incidentally, this thread is one of the reasons I hate C.
Yeah. The threads fill up with the same old misconceptions that are fixed on page 1 if the posters actually read a book on C (excluding books by H Schildt I guess).
In before "NULL != 0 sometimes" or "arrays are implemented as pointers"
No, he's right. On systems where your constants exist in a different medium than your variables (such as microcontrollers where variables are in RAM but constants are in flash), declaring a string as const or not const can have a big impact on what resources you eat up.
He's right , but your reason is not :)
Whether "first" is stored in the const data area or not depends on your compiler/linker settings. You can legally write char *post = "first"; in either case, just your program goes balls up if it does get stored in const data and you later try to write that data through 'post'. The 'good form' version of the code, i.e. char const *post, goes a long way toward preventing you from trying to write the const data area.
It just signals that open source stuff beats proprietary crap
as Psion Flight Simulator??
The Speccy games you thought were good until you tried, oh, every other game
Then they would lose business. It's far better to sell something a bit more expensive to IE7 users, than to shut your door to them.
Agree, I don't really understand the comment you quoted. It's good that cheaters are unhappy and quit. What is the "arcane attitude" ?
Further information was given in the 2nd Anglo-Saxon Chronicle, or "ASCII"
The most shocking thing about this article, to me, is the number of people who think it's quite OK for children to view porn.
Did he believe in it, or just say that he did?
In the US you can receive some negative attention for saying you don't believe in any gods, so it might be rational for someone (especially a German immigrant in the 1940s) to follow the old advice: when in Rome, do as the Romans do.
Once you've seen an elephant, believing that elephants don't exist is highly irrational.
What if you were on LSD, and knew you were on LSD?
Actually, I usually find that Atheists have a much worse understanding of science and don't understand why science can't disprove God (one big reason being that science is based on OBSERVATION, and you can't observe a lack of something).
Can you disprove that all emeralds will turn blue in the year 2017?
Do you believe they won't, or do you believe they may or may not and we'll have to wait to see?
edit: checking other resources shows that they meant 22 GW peak production.
IYTM 1000 for one hour, 2000 for two hours, 4000 for four hours..
It's completely unclear from the article whether they mean:
* 22 GWh produced over the period in question
* 22 GW average production over the period in question
* 22 GW peak production over the period in question
I have seen journalists change "unit-hours" to "units per hour" before, perhaps failing to understand the unit and assuming that the "missing per" was a typo; so I'd actually favour the first of these options. It's hard to imagine a solar plant generating 20x as much electricity as a nuclear plant.
Surely this is no news at all; the Sun has been measured as accurately as possible (given that it doesn't have a well-defined edge) by satellite telemetry long ago. This should perhaps be titled 'most accurate calculation by amateur Japanese without modern equipment' or something
I read TFA.. the algorithm is not broken and the seed isn't deducible from the output; all they've done is read the seed out of software auth running on a general purpose computing device.
This has always been possible in theory -- obviously, the computer software has to generate the output so it must have the seed in an accessible form; probably under several layers of obfuscation and encryption (which ultimately adds no security, as the software still has to be able to wade through it to get to the seed). It's very similar in concept to someone being able to obtain your PGP or SSH private keys if they have local access to your system.
There is no risk to people with a hardware auth device, unless the server is compromised (in which case this form of authentication is useless anyway).