If you write to that location using a float* (or char* which is allowed to alias anything) then the compiler must not assume that the value has not changed. If you write to that location through an int*, it is entirely legal for the compiler to not bother re-reading the memory and to instead use a cached value.
These two sentences seem to be saying exactly the opposite. If the compiler does not ever assume that the value has not changed then it may assume that it *HAS* changed, and would not use a cached value.
This is the normal behaviour in C. You can get the latter with certain optimizations enabled, but in cases where you do, the code won't perform any worse than Fortran produced code anyways. Even then, a modern compiler may be able to detect that a person has used pointer aliasing in a context and disable those optimizations in that context, while in Fortran, the language structure does not permit such things to happen, and thus produces code that makes the assumption it will never happen.
The optimizations that Fortran makes can be explicitly disabled by using a union type, but then it will not ever be any faster than what a C or C++ compiler could produce for manipulating such values.
If you alias one type of object to another through pointer casting in C, and change what is there through the other pointer, when you access the original, the value will have changed. This is the correct behavior (however implementation-defined) because those are the steps that were given. Fortran, when producing optimized code, will not do this unless you use a union type, which explicitly disables such optimizations in the first place.
Using the restrict keyword causes modern C and C++ compilers to produce code no slower than Fortran.... but the side effect of using the keyword is that pointer aliasing will have unexpected side effects, just as it would in Fortran.
The fact that the side effects of pointer aliasing are often not what a programmer may have intended does not change the fact that those effects are still what the computer was instructed to do, and therefore the correct behavior. Compensating for such side effects is what makes more recent compilers produce slower code without the usage of optimizing that allows such side effects to remain unaccounted for.
The C standard specifies strict aliasing in that a float* cannot alias an int*.
In C, if I am using a float variable, and then write some other content into the memory occupied by the float without using the variable (possibly a bit pattern that corresponds to a specific float value) and then try to use the float again, its content will have changed... which is the correct behavior, because that's what was instructed. In Fortran, with appropriate speed optimizations enabled, the compiler does not assume this is possible, and the float variable may not necessarily appear to be changed when it is used after the memory it supposedly occupied was overwritten (in Fortran, you'd generally have to do some weird tricks to even make this happen without explicitly using a union type which would disable such optimizations in the first place, while in C all you would have to do is cast a pointer to a different type).
The reason this is true is that Fortran compiler output, when appropriate optimizations are turned on, is not actually concerned with producing correct output... and although it is certainly faster, the resulting code will be less robust than code output by a modern most modern C compilers. Modern compilers generally focus on producing correct output at all times, and may make compromises in efficiency for correctness.
The main differences involve pointer aliasing... and a C or C++ compiler with the appropriate optimizations switches to ignore pointer aliasing possibilities, as Fortran does, will produce code that is just as fast as that which a Fortran compiler can produce.
The only reason no language since matches its speed is because all of the focus on optimization in modern languages is to increase speed while still focusing on producing correct output from whatever inputs are given, while Fortran optimization does not concern itself with the latter. In practice, this is only an issue when pointers to different types of objects could possibly have overlapping content... Fortran compilers would not necessarily produce the correct output from a given input when this is the case.
Disabling the requirement for correctness, the output of a modern C or C++ compiler with appropriate optimizations can very easily match the speed of what is produced by any Fortran compiler.
In all honesty, it probably wouldn't have been worth it in my case... It was just a philosophy course which I needed to fulfill arts elective requirements.
I passed the class quite easily with a final grade of A-.
Which means that it would take two sunny days in a row, with very little driving in between to "fill up". In practice it would be even more, since this is the amount of energy that you'd get assuming that the solar panels were 100% efficient, so you can probably double that time or worse.
Compare this to spending 5 minutes at a gas station to fill up an empty tank with gasoline.
No.... they should be watched for suggesting it, and only arrested if they actually implement it. Otherwise you get into the realm of effectively making it illegal to even *think* about breaking the law.
This is what I was thinking as well... I can see people who conspire to do this losing their license if they are caught. Shouldn't be too difficult since they've actually admitted they are intending on doing it publicly.
By creating such congestion, *NOBODY* will be able to transport people... even those who have nothing to do with Uber.
Also, this would interfere with emergency vehicles and public transportation as well.
I'm quite sure that they could face serious fines if they actually implement this... up to and including losing their license to operate as a business if they continue.
assuming, of course, that said ET's don't have any kind of technology which can effectively fold space, making faster than light transportation possible.
Regardless of how infrequent the demand for it might be, it is always going to be more convenient to own your own vehicle than it will be to deal with trying to rent one that meets your needs.
And hey... not everyone has a three-car garage, so there's probably not going to be the space for a vehicle that's hardly ever used.
On the probably very rare occasions that you do need to take an extended trip, rent a car.
Owning is more convenient than renting. I own a bicycle that I hardly ever use. That doesn't mean I'd want to get rid of it and deal with the hassle of renting one whenever I want to go for a bike ride.
And of course, garage space is limited... there's only room in there for the cars that we actually use. I don't think that in this respect, I misrepresent the majority of drivers.
Then all the gene does is determine a difference, its presence or absence doesn't actually "boost" or "depress" anything. It *determines* the existence of a higher IQ, it doesn't boost IQ at all.
My point is that nobody's IQ has actually been boosted in the first place... things just start out that way and stay that way. "boosting" would imply that it could be changed from being lower to being higher.
Slashdot Mirror
These two sentences seem to be saying exactly the opposite. If the compiler does not ever assume that the value has not changed then it may assume that it *HAS* changed, and would not use a cached value. This is the normal behaviour in C. You can get the latter with certain optimizations enabled, but in cases where you do, the code won't perform any worse than Fortran produced code anyways. Even then, a modern compiler may be able to detect that a person has used pointer aliasing in a context and disable those optimizations in that context, while in Fortran, the language structure does not permit such things to happen, and thus produces code that makes the assumption it will never happen.
The optimizations that Fortran makes can be explicitly disabled by using a union type, but then it will not ever be any faster than what a C or C++ compiler could produce for manipulating such values.
Exactly.
If you alias one type of object to another through pointer casting in C, and change what is there through the other pointer, when you access the original, the value will have changed. This is the correct behavior (however implementation-defined) because those are the steps that were given. Fortran, when producing optimized code, will not do this unless you use a union type, which explicitly disables such optimizations in the first place.
Using the restrict keyword causes modern C and C++ compilers to produce code no slower than Fortran.... but the side effect of using the keyword is that pointer aliasing will have unexpected side effects, just as it would in Fortran.
The fact that the side effects of pointer aliasing are often not what a programmer may have intended does not change the fact that those effects are still what the computer was instructed to do, and therefore the correct behavior. Compensating for such side effects is what makes more recent compilers produce slower code without the usage of optimizing that allows such side effects to remain unaccounted for.
In C, if I am using a float variable, and then write some other content into the memory occupied by the float without using the variable (possibly a bit pattern that corresponds to a specific float value) and then try to use the float again, its content will have changed... which is the correct behavior, because that's what was instructed. In Fortran, with appropriate speed optimizations enabled, the compiler does not assume this is possible, and the float variable may not necessarily appear to be changed when it is used after the memory it supposedly occupied was overwritten (in Fortran, you'd generally have to do some weird tricks to even make this happen without explicitly using a union type which would disable such optimizations in the first place, while in C all you would have to do is cast a pointer to a different type).
Because that correctness comes at a cost... a small loss of speed.
Fortran code ignores the very possibility that pointer content can overlap. Modern compilers do not.
The reason this is true is that Fortran compiler output, when appropriate optimizations are turned on, is not actually concerned with producing correct output... and although it is certainly faster, the resulting code will be less robust than code output by a modern most modern C compilers. Modern compilers generally focus on producing correct output at all times, and may make compromises in efficiency for correctness.
The main differences involve pointer aliasing... and a C or C++ compiler with the appropriate optimizations switches to ignore pointer aliasing possibilities, as Fortran does, will produce code that is just as fast as that which a Fortran compiler can produce.
The only reason no language since matches its speed is because all of the focus on optimization in modern languages is to increase speed while still focusing on producing correct output from whatever inputs are given, while Fortran optimization does not concern itself with the latter. In practice, this is only an issue when pointers to different types of objects could possibly have overlapping content... Fortran compilers would not necessarily produce the correct output from a given input when this is the case.
Disabling the requirement for correctness, the output of a modern C or C++ compiler with appropriate optimizations can very easily match the speed of what is produced by any Fortran compiler.
Maybe it's just me... but that arm seems to be close enough to lifelike that it looks a kind of creepy..
COBOL is a newer language than Fortran.
[nt]
It's always been about what will make the company the most money.
Mos game companies don't give a crap about making games players will enjoy, they only want to make games that will improve their own bottom line.
And the free-to-play model, or more accurately titled "play to win" model, will get you there with the least amount of effort.
In all honesty, it probably wouldn't have been worth it in my case... It was just a philosophy course which I needed to fulfill arts elective requirements.
I passed the class quite easily with a final grade of A-.
The teacher was still a bit of a douche, however.
Which means that it would take two sunny days in a row, with very little driving in between to "fill up". In practice it would be even more, since this is the amount of energy that you'd get assuming that the solar panels were 100% efficient, so you can probably double that time or worse.
Compare this to spending 5 minutes at a gas station to fill up an empty tank with gasoline.
No.... they should be watched for suggesting it, and only arrested if they actually implement it. Otherwise you get into the realm of effectively making it illegal to even *think* about breaking the law.
This is what I was thinking as well... I can see people who conspire to do this losing their license if they are caught. Shouldn't be too difficult since they've actually admitted they are intending on doing it publicly.
By creating such congestion, *NOBODY* will be able to transport people... even those who have nothing to do with Uber.
Also, this would interfere with emergency vehicles and public transportation as well.
I'm quite sure that they could face serious fines if they actually implement this... up to and including losing their license to operate as a business if they continue.
assuming, of course, that said ET's don't have any kind of technology which can effectively fold space, making faster than light transportation possible.
Regardless of how infrequent the demand for it might be, it is always going to be more convenient to own your own vehicle than it will be to deal with trying to rent one that meets your needs.
And hey... not everyone has a three-car garage, so there's probably not going to be the space for a vehicle that's hardly ever used.
Owning is more convenient than renting. I own a bicycle that I hardly ever use. That doesn't mean I'd want to get rid of it and deal with the hassle of renting one whenever I want to go for a bike ride.
And of course, garage space is limited... there's only room in there for the cars that we actually use. I don't think that in this respect, I misrepresent the majority of drivers.
Anything within a single standard deviation is rarely considered statistically significant unless the distribution is extremely flat.
Then all the gene does is determine a difference, its presence or absence doesn't actually "boost" or "depress" anything. It *determines* the existence of a higher IQ, it doesn't boost IQ at all.
Not really... that's just another verb that still suggests it somehow can change within a given individual.
It's not really a myth, but using single number can be misleading.
Kind of like how that on average, a human being will have 1 testicle. It's stastically true, just not very useful.
My point is that nobody's IQ has actually been boosted in the first place... things just start out that way and stay that way. "boosting" would imply that it could be changed from being lower to being higher.
How does something that's genetic "boost" anything? This is a gene, not a drug.