Both AMD and nVidia have been doing this for years with their Windows drivers. Why? Because apps like 3DMark and games like CS, Quake are used to benchmark video cards by reviewers.
AFAIK, none of those issues had anything to do with Bitcoins itself but a number of exchange sites which went belly up. BT might be a lousy currency (or not) but the protocol and its implementation is surprisingly well though out.
We (the responsible R/C helicopter community) have been asking, in fact begging, for regulation for some time now. Even going so far as to have pseudo-regulation via AMA. Unfortunately the FAA has continually put the issue on the back-burner....
I'm aware of this. Sadly, this won't change until there's money involved, like Amazon's recent research on using quads for package delivery. These regulations are strict and hard to change, but, again, there's good reason for it.
Also, the analogy of radio-controlled cars is absurdly non-sequitur as cars are 3,000lbs of steel/aluminum and multi-rotors are 27 oz. of plastic/carbon fiber.
The thing is, you don't need a lot of mass to damage something that flies. A RC car can wreck havoc if stepped over by a car going 70MPH on a highway, just like a quad can do even more damage if sucked into the jet intake of an airliner / helicopter. Or the propeller / attack surfaces of a small airplane - incidents with birds, for example, are sadly common.
That's right, these people are just pretending they're in a real helicopter. IS that so wrong? I mean the stuff of little boy dreams is now possible.
It is if you get in the way of an actual manned helicopter. If drone/RPV usage keeps going up regulation will be needed, sooner or later. A good part of a private pilot license exam is regarding regulations and air traffic rules. Even if you only plan to spin around a runway in a small Cessna these still apply.
Imagine what would happen if people started putting radio controlled cars in a highway. Now imaginge the highway is 3,000FT above the ground.
They aren't. When you start adding up a lot of cents you end up, invariably, with rounding errors. FPs are not intended for this task.
The way they intended to deal with this issue back then was to round down results to x decimals, just to make sure the clients weren't charged extra. And even that wasn't enough.
Ditto. Not only that, i'm amazed by the number of programmers who don't properly understand floating point arithmetic either.
A long time ago i had to write a C/C++ fixed-point arithmetic library for a (major) telecom company because their billing processes would routinely output totals with cent errors; over a full year these added up to a significant ammount of money, a-la-Superman III. No one even had a clue of why their processes failed.
Some idiot researcher who expects Excel or an FPU instruction to be accurate for sin to more than 10 decimal places is going to crop up SO MANY anomalies in their data that they'll stick out like a sore thumb.
Unless the processor's documentation explicitly promises that accuracy.
Because I have every right to use the network as the guy making it impossible for me to use it.
Then, by your own logic, you're not justified to use bithammer. I hate to play the devil's advocate here, but OzPeter makes a damn good point. If a BT user really prevents you from feeding your family then you should consider an alternative other than McDonalds in the first place.
I was actually being facetious, but this is not far off from the truth. Nokia was already hurting when iOS and Android gained momentum, but it really took a nosedive pretty much the second the decided to support Windows exclusively.
A crying shame, because they sell some very nice hardware.
In ways you cannot undersand, evidently. The distinction on C when comparing type-casted operands is precisely because casting is guaranteed to destroy precision - operands are effectively modified in the process. This has NOTHING to do with the way relational operators work: they behave in a sane way, like they do in every other language on Earth.
Now contrast that with the idiotic PHP decision of setting rules for relational operators leading to circular logic. I know the "this might fool the typical PHP developer" warning went over your head, but ponder on this: on my original PHP code snippet, where's the "loss of precision"?
Where's the casting?
Hell, where do you apply your "object has precedence" mantra on it?
I really can't believe that someone could not only defend this madness so vehemently, but also without really understanding what he/she is talking about. Try a new language, son. It will open your horizons.
Dude, you are the one who's flat out wrong. Not only C has transitive relationship operators, but the language specification actually states that value comparison operators must be transitive except in cases where precision is lost in type-casting of operands.
So, for example, this might fool the typical PHP developer...
int main(void) { unsigned long a = 98765UL; int b = -12345; short c = 1;
if (a < b) printf("a < b!\n"); if (b < c) printf("b < c!\n"); if (c < a) printf("c < a!\n"); }
...while you're simply rounding off (modifying!) operands in the process. This can be easily show by controlling how casting is performed:
int main(void) { unsigned long a = 98765UL; int b = -12345; short c = 1;
if (a < (long)b) printf("a < b!\n"); if (b < (int)c) printf("b < c!\n"); if (c < (short)a) printf("c < a!\n"); }
No, it should not be complicated. It does not make sense - PHP is the only, and i mean only language i found with comparison rules that are non-transitive. And even worse, circular.
Oh, and by the way. Why do people insists on comparing PHP to C? Isn't PHP supposed to be a high-level, website oriented scripting language?
I ask because i've seen bugs about PHP segfaulting reliably rejected only because "this behavior is consistent with what lower level languages like C do". It's like watching an exploit slowly growing from its infancy.
I see. You're just confused by dynamic languages. Try the same operations in C, with the relevant casts, and note the results. Hey, look at that! Not quite so "nonsensical" now, is it?
Like I said, give that article a good fact-check. You'll regret ever recommending it.
"Dynamic languages" eh? Show me a "dynamic language" where i can do this (blatantly stolen from this site):
Really? Most, if not all of it, is stuff i've ran into in the past. The nonsensical comparison operator results and the so-called "arrays" pop into my mind right now...
get a life.. for real. Always easy to play MMQB, harder to actually *do* something.
I've worked with PHP and its assorted web frameworks enough times to completely relate to what that site tells.
That an amateur language like PHP holds 80% of the web marketshare seems insane until you actually realize that 80% of the web is hardly professionally developed either.
Slashdot Mirror
Both AMD and nVidia have been doing this for years with their Windows drivers. Why? Because apps like 3DMark and games like CS, Quake are used to benchmark video cards by reviewers.
Hey. Just saying.
The compiler? Why would you want to run that on an embedded system?
Indeed. The worst one i can remember was, by far, Will Smith raving about his "retro" Converse shoes in I, Robot. That was cringe worthy.
That's painful to read :( Say what you want about Perl 5, but it is by far the fastest interpreted (ok ok, "byte-compiled") language around.
AFAIK, none of those issues had anything to do with Bitcoins itself but a number of exchange sites which went belly up. BT might be a lousy currency (or not) but the protocol and its implementation is surprisingly well though out.
We (the responsible R/C helicopter community) have been asking, in fact begging, for regulation for some time now. Even going so far as to have pseudo-regulation via AMA. Unfortunately the FAA has continually put the issue on the back-burner....
I'm aware of this. Sadly, this won't change until there's money involved, like Amazon's recent research on using quads for package delivery. These regulations are strict and hard to change, but, again, there's good reason for it.
Also, the analogy of radio-controlled cars is absurdly non-sequitur as cars are 3,000lbs of steel/aluminum and multi-rotors are 27 oz. of plastic/carbon fiber.
The thing is, you don't need a lot of mass to damage something that flies. A RC car can wreck havoc if stepped over by a car going 70MPH on a highway, just like a quad can do even more damage if sucked into the jet intake of an airliner / helicopter. Or the propeller / attack surfaces of a small airplane - incidents with birds, for example, are sadly common.
That's right, these people are just pretending they're in a real helicopter. IS that so wrong? I mean the stuff of little boy dreams is now possible.
It is if you get in the way of an actual manned helicopter. If drone/RPV usage keeps going up regulation will be needed, sooner or later. A good part of a private pilot license exam is regarding regulations and air traffic rules. Even if you only plan to spin around a runway in a small Cessna these still apply.
Imagine what would happen if people started putting radio controlled cars in a highway. Now imaginge the highway is 3,000FT above the ground.
They aren't. When you start adding up a lot of cents you end up, invariably, with rounding errors. FPs are not intended for this task.
The way they intended to deal with this issue back then was to round down results to x decimals, just to make sure the clients weren't charged extra. And even that wasn't enough.
Ditto. Not only that, i'm amazed by the number of programmers who don't properly understand floating point arithmetic either.
A long time ago i had to write a C/C++ fixed-point arithmetic library for a (major) telecom company because their billing processes would routinely output totals with cent errors; over a full year these added up to a significant ammount of money, a-la-Superman III. No one even had a clue of why their processes failed.
Some idiot researcher who expects Excel or an FPU instruction to be accurate for sin to more than 10 decimal places is going to crop up SO MANY anomalies in their data that they'll stick out like a sore thumb.
Unless the processor's documentation explicitly promises that accuracy.
Because I have every right to use the network as the guy making it impossible for me to use it.
Then, by your own logic, you're not justified to use bithammer. I hate to play the devil's advocate here, but OzPeter makes a damn good point. If a BT user really prevents you from feeding your family then you should consider an alternative other than McDonalds in the first place.
I was actually being facetious, but this is not far off from the truth. Nokia was already hurting when iOS and Android gained momentum, but it really took a nosedive pretty much the second the decided to support Windows exclusively.
A crying shame, because they sell some very nice hardware.
Look at Nokia. Those phones will only be able to access the Microsoft cloud.
That nicely explains Nokia sales figures lately. Something like 30% down this last year.
sigh...
Whatever kid. You win. I have actual work to do.
In ways you cannot undersand, evidently. The distinction on C when comparing type-casted operands is precisely because casting is guaranteed to destroy precision - operands are effectively modified in the process. This has NOTHING to do with the way relational operators work: they behave in a sane way, like they do in every other language on Earth.
Now contrast that with the idiotic PHP decision of setting rules for relational operators leading to circular logic. I know the "this might fool the typical PHP developer" warning went over your head, but ponder on this: on my original PHP code snippet, where's the "loss of precision"?
Where's the casting?
Hell, where do you apply your "object has precedence" mantra on it?
I really can't believe that someone could not only defend this madness so vehemently, but also without really understanding what he/she is talking about. Try a new language, son. It will open your horizons.
PS: I'm a he, not a she.
Just like PHP!
Just like PHP, where comparison operators are transitive except in cases where precision is lost in type-casting of operands.
Yeah. I'm dying to know what the "loss of precision" is when comparing a float to an array to an object.
No, you know what? I don't. Go have fun with your toy websites.
Dude, you are the one who's flat out wrong. Not only C has transitive relationship operators, but the language specification actually states that value comparison operators must be transitive except in cases where precision is lost in type-casting of operands.
So, for example, this might fool the typical PHP developer...
int main(void) {
unsigned long a = 98765UL;
int b = -12345;
short c = 1;
if (a < b) printf("a < b!\n");
...while you're simply rounding off (modifying!) operands in the process. This can be easily show by controlling how casting is performed:
if (b < c) printf("b < c!\n");
if (c < a) printf("c < a!\n");
}
int main(void) {
unsigned long a = 98765UL;
int b = -12345;
short c = 1;
if (a < (long)b) printf("a < b!\n");
if (b < (int)c) printf("b < c!\n");
if (c < (short)a) printf("c < a!\n");
}
Compare this to the brainfuck that is PHP, where comparison rules are well stablished but still manage to produce this crap. I can't believe i'm actually discussing this.
No, it should not be complicated. It does not make sense - PHP is the only, and i mean only language i found with comparison rules that are non-transitive. And even worse, circular.
Because it's a language that others are likely to already understand. PHP is also written in C, which likely influenced the language.
So are Python, Perl, Ruby and Java, and you won't see anyone comparing them to C. That's a poor argument.
Oh, and by the way. Why do people insists on comparing PHP to C? Isn't PHP supposed to be a high-level, website oriented scripting language?
I ask because i've seen bugs about PHP segfaulting reliably rejected only because "this behavior is consistent with what lower level languages like C do". It's like watching an exploit slowly growing from its infancy.
I see. You're just confused by dynamic languages. Try the same operations in C, with the relevant casts, and note the results. Hey, look at that! Not quite so "nonsensical" now, is it?
Like I said, give that article a good fact-check. You'll regret ever recommending it.
"Dynamic languages" eh? Show me a "dynamic language" where i can do this (blatantly stolen from this site):
$ cat circular.php
<?php
$a = INF;
$b = array();
$c = (object)array();
var_dump($a < $b);
var_dump($b < $c);
var_dump($c < $a);
$ php circular.php
bool(true)
bool(true)
bool(true)
You're right though. Nonsense confuses me.
Really? Most, if not all of it, is stuff i've ran into in the past. The nonsensical comparison operator results and the so-called "arrays" pop into my mind right now...
get a life.. for real. Always easy to play MMQB, harder to actually *do* something.
I've worked with PHP and its assorted web frameworks enough times to completely relate to what that site tells.
That an amateur language like PHP holds 80% of the web marketshare seems insane until you actually realize that 80% of the web is hardly professionally developed either.
Is that thing still around?