Wait... Are you saying that people who make weapons don't get paid a lot of money for their weapons? Because they do actually make a lot of money.
I'm not so sure about that. Iron Man may make billions from his military inventions, because it's a movie. In the real world, Tony Stark's inventions would make billions, but that money would go to the corporation hiring him, while Tony himself would only make between $200K to $1M max/year for his work.
So my point is, the money goes to the businessmen running these weapon companies and to the govt who profit from winning wars using these weapons. But the person actually responsible for winning the war through good weapon-design makes diddly squat, relatively speaking.
They already are. Here is some legal stuff stating Intel licensing copyright of x86 instructions to AMD:
3.4 Intel Copyright License to AMD. Subject to the terms of this Agreement, including without limitation Section 5.2(e), Intel grants to AMD, for use in or with an AMD Licensed Product, licenses under Intelâ(TM)s copyrights in any Processor instruction mnemonic for an instruction developed by Intel, and the related opcodes, instruction operand mnemonics, byte format depictions and short form description (not to exceed 100 words) for those instructions, to copy, have copied, import, prepare derivative works of, perform, display and sell or otherwise distribute such mnemonics, opcodes and descriptions in user manuals and other technical documentation. No other copyright license to AMD is provided by this Agreement other than as set forth in this paragraph, either directly or by implication or estoppel.
The same could be said of pretty much every advancement. Guys with clubs are cowards because the barehanded guys don't have a chance. Guys with swords are cowards because the guys with clubs don't stand a chance. Guys with arrows are cowards because the guys with swords across the field don't stand a chance. So on and so forth.
You seem to agree to the philosophy that: weapons are of much greater importance than the soldier using it
If that's true, why aren't the inventors (or IP creators) of these weapons not rulers of countries or at least receive a sizable royalties from the spoils of war? Don't these weapons win wars? Why do administrator type politicians and capitalist businessmen divvy up lion's share of a country's output and war profit, leaving only scraps for others?
This is especially true where today's drone operators are not much more than video game players wielding very powerful weapons.
How is this any different than Intel copyrighting x86 instruction code.
It's not very different: APIs are interface to library systems layered below the app whereas CPU instructions are interface from app to CPU below the app.
AMD has a license to use the interface (CPU instruction API) whereas Google does not for Java. The fair use argument is totally bullshit, because under that excuse some company could build an x86 CPU without paying Intel for the x86 instruction set.
Really? Class API declarations are not code? The API declarations were copied, but not the implementation, and that's still copying code exactly. Google just has a habit of not paying for copyrighted content. Let's look at some examples:
* The content Google search displays when you use a search phrase -- this might be okay because of fair use. * Google Images * Google Books * Google News
So they followed the same routine and copied the API of Java (because copying code implementing API will lead to a guaranteed loss in a lawsuit).
When a user touches the screen, the x, y touch position is passed to the app. With force touch, the amount of pressure the finger exerts on the screen is also passed to the app allowing for all kinds of interesting behavior.
Why don't the cab drivers move to Uber so they don't have to pay the licensing fees
Why should taxi drivers pay thousands of Euros for the privilege of driving a taxi? That seems excessive and non-democratic. The taxi driver in turn has to charge the passenger extra to cover the high cost of the license.
The license fees should be cheap and nominal. If there are more drivers than licenses, there should be a lottery system (not a bribe system) to select which driver wins the (non-transferable) license.
where the professor, as far as we knew, existed only on some VHS tapes in the corner of the room.
Why do you need a $80-100k professor to repeat the same words over and over for 10 or 20 years? A video recording can do the job an order of magnitude better (assuming high-quality graphic models shown to augment the audio portion of the professor).
I ended up having to go to my physics TA to figure out what was going on. I remember feeling ripped off and pretty much disgusted.
With a flesh-and-blood professor, how many times can you interrupt him in class with a question before he throws you out? No many, I assume. I wish each lecture video had a youtube-like comment section where students could ask questions about a certain issue s/he is facing in that particular video as opposed to a general forum to discuss all problems.
If only Flash had been implemented in a safer programming language, like Pascal, these bugs would've been rare and few. But all the macho programmers love C/C++, so more vulnerabilities and updates for you every day.
The study, conducted by internet activists BattlefortheNet, looked at the results from 300,000 internet users and found significant degradations on the networks of the five largest internet service providers (ISPs), representing 75% of all wireline households across the US.
When 5 companies have 75% market share, it's a highly monopolistic market, which will result in very high prices because of lack of competition.
You need to figure out how (politically and technically) only five companies are allowed to profit from a commodity service. Imagine if only 5 vendors made and sold all t-shirts. How high would the price of t-shirts be then?
You want to prevent a private company from offering a product for sale? I am not sure that I agree.
Why not? There are plenty of restrictions on the sale of weapons, like guns and you can't buy machine guns or bazookas. These Glass-like products are worse than guns because they can be used way more often.
I hate the very idea of Google Glass and what it could become but I do not want to ban it. I would be okay with restricting some uses of it, I would have to think about the uses carefully before I agreed with them,
The user of Glass (usually a glasshole) does not care about the privacy of others. Cameras were more benign (used mainly for security) before the advent of computers+networking. With networking, you can now permanently store images of people even if these people don't want to. Therefore the age old law of no privacy in public is no longer valid and needs to be revisited. The new laws would set boundaries as to what can and cannot be recorded in public.
But what if there's a hit and run, and some bystander witnesses the accident? What if a driver in a sports car speeds away from the cops while breaking the speed limit? There are plenty of such cases where license plates are necessary but these plate readers are abusing this requirement. I guess you can commit crimes openly when you write the laws.
It's time to rewrite the laws: the public has a right to privacy, even in public places. Stop evil, criminal technologies like license plate readers, CCTV cameras on streets, Oregon's GPS car tracking and Google Glass.
How will they know you read a page in an ebook unless they have 24/7 access to what you are reading with your ereader/tablet.
Well, the book reader software will just store the pages you read (and perhaps how much time you spent on each page) into flash storage. When you connect online, it will upload the data to amazon's servers. I gotta agree with you, fuck this shit. These people need to be forced to stop this and fined tens of millions for privacy violation.
does that mean I don't have to pay Amazon unless I read each page?
No, it's like cable TV where you pay the monthly fee even if you don't turn on the TV.
All subscriber monthly payments go into a big pot and authors get paid proportional to how many pages of their books have been read. But here's the odd thing: all authors make the same amount per page regardless of quality of writing, difficulty of the subject matter or whether it's in a niche market. That's just communistic and greedy of Amazon. Imagine a doctor, an engineer, a nurse and a bus driver getting the same wage, even though the doctor and engineer worked very hard to get where they were.
This type of pricing will encourage creation of cheap novels and reference material a lot.
"once it's bought, the seller and author are right the fuck out of the picture, and the owner can do whatever they want with it," as it should be.
That's fine as long as "whatever they want it," does not include distributing 200 free copies to other people. Because that would mean each reader only paid an average of 10 cents for the book, i.e., consumers being cheap and greedy.
A more robust solution would be using the highest bit in the variable to denote integer NaN. That would reduce your signed int32 into a signed 31 bit integer, the unsigned 32 bit var would become unsigned 31 bits, the signed 64-bit would become signed 63-bit integer and so on.
-iNaN = iNaN iNaN + var -> iNaN iNaN - var -> iNaN iNaN * var -> iNaN iNaN / var -> iNaN iNaN | var -> iNaN iNaN & var -> iNaN iNaN ^ var -> iNaN ~iNaN -> iNaN
where var is either a valid integer or an iNaN.
But the more I think about it, it seems there are very few instances where we have integer divBy0 in a real program. Since most divide instructions belong to equations that are usually implemented in floating point code, there is no need to have any type of integer NaN.
For non-zero/0, infinity is the "correct" answer and anything else will give strange results.
It is not the correct answer since the correct answer is NaN. It's just a hack to avoid having to write exception handlers for every other line of FP code.
If we had to do tons of integer division, we would need an integer NaN too.
you have an easy alternative, which is a try/catch structure.
That's not easy, instead it's a nightmare. If you add try/catch near the point of division, you have to add these try-catch boilerplate code all over your code base. If you add the try-catch at a higher level (near your main()), that too causes headaches because now you have to restart and reinitialize the parts that got discarded after the exception was thrown.
It is precisely to handle these types of problems that the IEEE 754 standard uses NaN or Infinity for div-by-zero (because divisions are extremely common in FP code). That is, it is better to generate and propagate the wrong result (NaN) than it is to filter inputs and other data that cause div-by-zero, or handle exceptions in try/catch.
I do actually agree with you and would propose that signed integer formats should reserve 0x8000000
Yes, the highest bit should be reserved for nullity/NaN. Any arithmetic operation on a nullity variable should result in a nullity. There won't be any drop in performance if the CPU supports it, but the range of integers will be halved (from 2 billion to 1 billion for int32 variables). But that's not a big deal in a world where 64 bit integers are common.
If you haven't read the article linked within the blog, nullity is supposed the new number that results when you divide something by 0.
It's been done. The results were crap.
The guy who posted on this blog is wrong:
1. That currently, dividing by zero on a computer causes problems because division by zero is undefined. But if computers adopted nullity, then division by zero errors could be gotten rid of, because they'll produce nullity. Except of course that modern floating point hardware already *does* have a NaN value, and it *doesn't help* with the kind of problem he's talking about!
But we're not talking about floating-point hardware. Integer hardware still does not have a NaN, so the programmer has to add extra code to handle divide by zero.
The 754 model encourages robust programs. It is intended not only for numerical analysts but also for spreadsheet users, database systems, or even coffee pots. The propagation rules for NaNs and infinities allow inconsequential exceptions to vanish. Similarly, gradual underflow maintains error properties over a precision's range.
The IEEE 754 model treats 0 as very small positive numbers, resulting in infinity when you do divide by zero. Of course, that hack results in much more robust and safer programs as you don't have to deal with (dozens/hundreds) of exceptions in a program.
INT_MAX and INT_MIN are not infinity and would be dangerous incorrect to treat them as such
It is a very rare program that has INT_MAX/INT_MIN as valid values. If your program even reaches close to INT32_MAX/MIN, you usually change the type of variable to a signed 64 bit variable. So, as with IEEE 754, we should have a default value for div by zero by int32 or int64 to allow "inconsequential exceptions to vanish."
And in almost 20 years of its existence, how many Java programmers have complained about not being able to trap divide by zero in floating point? Java has already implemented a default value (+/-infinity) for floating point divide by zeros, as requested by the submitter of this/. story, and it's a success. Let's face it, returning +/- infinity has huge benefits in code simplicity. And therefore the same thing should be done for signed integers.
In a typical case, the int div-by-zero should return MAX_INT or MIN_INT. Down the line, garbage results caused by this div by zero alert the programmer to find the bug and fix it. As you can see, no div by zero exception handlers peppered throughout your code base.
Let's look at the catastrophes caused by integer/floating point exceptions:
A data conversion from 64-bit floating point value to 16-bit signed integer value to be stored in a variable representing horizontal bias caused a processor trap (operand error)[29] because the floating point value was too large to be represented by a 16-bit signed integer.
Technically, the result in undefined, hence the exception is generated. However, practically speaking, for divisors close to zero but not zero, the result is +/- infinity, which is what happens in floating point code.
Well in Java, integer div by zero causes an ArithmeticException, whereas div by a floating-point zero results in +/-Infinity but no exception. Why should only integer code generate exceptions and not floating point code? Do floating point errors not matter?
I think this not generating an exception has something to do with the huge range of numbers floating point types have compared to integers. But integers are quite big now, so int32 or int64 (signed integers) should have compile time option to return INT_MAX or INT_MIN instead of generating an exception. Unsigned integers should still generate an exception.
If a pizza delivery driver doesn't show up at their job as scheduled or decides they won't deliver a particular pizza, they can expect to lose their job.
That's okay, because Uber has other pizza drivers to deliver the pizzas.
Uber owns these drivers because, like employees, they have to bow down and follow Uber's rules:
But the commission said Uber controls the tools driver use, monitors their approval ratings and terminates their access to the system if their ratings fall below 4.6 stars.
Monitoring and firing people based on their performance sounds like a boss/employees type of relationship. That sounds more like dealing with an underling/employee rather than partnering with an independent contractor, the term Uber usually uses to describe its relationship to the taxi drivers.
Slashdot Mirror
I'm not so sure about that. Iron Man may make billions from his military inventions, because it's a movie. In the real world, Tony Stark's inventions would make billions, but that money would go to the corporation hiring him, while Tony himself would only make between $200K to $1M max/year for his work.
So my point is, the money goes to the businessmen running these weapon companies and to the govt who profit from winning wars using these weapons. But the person actually responsible for winning the war through good weapon-design makes diddly squat, relatively speaking.
They already are. Here is some legal stuff stating Intel licensing copyright of x86 instructions to AMD:
3.4 Intel Copyright License to AMD. Subject to the terms of this Agreement, including without limitation Section 5.2(e), Intel grants to AMD, for use in or with an AMD Licensed Product, licenses under Intelâ(TM)s copyrights in any Processor instruction mnemonic for an instruction developed by Intel, and the related opcodes, instruction operand mnemonics, byte format depictions and short form description (not to exceed 100 words) for those instructions, to copy, have copied, import, prepare derivative works of, perform, display and sell or otherwise distribute such mnemonics, opcodes and descriptions in user manuals and other technical documentation. No other copyright license to AMD is provided by this Agreement other than as set forth in this paragraph, either directly or by implication or estoppel.
http://www.sec.gov/Archives/ed...
It is therefore logical that Google should also obtain a license to use Oracle's Java API.
You seem to agree to the philosophy that:
weapons are of much greater importance than the soldier using it
If that's true, why aren't the inventors (or IP creators) of these weapons not rulers of countries or at least receive a sizable royalties from the spoils of war? Don't these weapons win wars? Why do administrator type politicians and capitalist businessmen divvy up lion's share of a country's output and war profit, leaving only scraps for others?
This is especially true where today's drone operators are not much more than video game players wielding very powerful weapons.
It's not very different: APIs are interface to library systems layered below the app whereas CPU instructions are interface from app to CPU below the app.
AMD has a license to use the interface (CPU instruction API) whereas Google does not for Java. The fair use argument is totally bullshit, because under that excuse some company could build an x86 CPU without paying Intel for the x86 instruction set.
Really? Class API declarations are not code? The API declarations were copied, but not the implementation, and that's still copying code exactly. Google just has a habit of not paying for copyrighted content. Let's look at some examples:
* The content Google search displays when you use a search phrase -- this might be okay because of fair use.
* Google Images
* Google Books
* Google News
So they followed the same routine and copied the API of Java (because copying code implementing API will lead to a guaranteed loss in a lawsuit).
When a user touches the screen, the x, y touch position is passed to the app. With force touch, the amount of pressure the finger exerts on the screen is also passed to the app allowing for all kinds of interesting behavior.
Why should taxi drivers pay thousands of Euros for the privilege of driving a taxi? That seems excessive and non-democratic. The taxi driver in turn has to charge the passenger extra to cover the high cost of the license.
The license fees should be cheap and nominal. If there are more drivers than licenses, there should be a lottery system (not a bribe system) to select which driver wins the (non-transferable) license.
Why do you need a $80-100k professor to repeat the same words over and over for 10 or 20 years? A video recording can do the job an order of magnitude better (assuming high-quality graphic models shown to augment the audio portion of the professor).
With a flesh-and-blood professor, how many times can you interrupt him in class with a question before he throws you out? No many, I assume. I wish each lecture video had a youtube-like comment section where students could ask questions about a certain issue s/he is facing in that particular video as opposed to a general forum to discuss all problems.
If only Flash had been implemented in a safer programming language, like Pascal, these bugs would've been rare and few. But all the macho programmers love C/C++, so more vulnerabilities and updates for you every day.
The study, conducted by internet activists BattlefortheNet, looked at the results from 300,000 internet users and found significant degradations on the networks of the five largest internet service providers (ISPs), representing 75% of all wireline households across the US.
When 5 companies have 75% market share, it's a highly monopolistic market, which will result in very high prices because of lack of competition.
You need to figure out how (politically and technically) only five companies are allowed to profit from a commodity service. Imagine if only 5 vendors made and sold all t-shirts. How high would the price of t-shirts be then?
Why not? There are plenty of restrictions on the sale of weapons, like guns and you can't buy machine guns or bazookas. These Glass-like products are worse than guns because they can be used way more often.
The user of Glass (usually a glasshole) does not care about the privacy of others. Cameras were more benign (used mainly for security) before the advent of computers+networking. With networking, you can now permanently store images of people even if these people don't want to. Therefore the age old law of no privacy in public is no longer valid and needs to be revisited. The new laws would set boundaries as to what can and cannot be recorded in public.
But what if there's a hit and run, and some bystander witnesses the accident? What if a driver in a sports car speeds away from the cops while breaking the speed limit? There are plenty of such cases where license plates are necessary but these plate readers are abusing this requirement. I guess you can commit crimes openly when you write the laws.
It's time to rewrite the laws: the public has a right to privacy, even in public places. Stop evil, criminal technologies like license plate readers, CCTV cameras on streets, Oregon's GPS car tracking and Google Glass.
Well, the book reader software will just store the pages you read (and perhaps how much time you spent on each page) into flash storage. When you connect online, it will upload the data to amazon's servers. I gotta agree with you, fuck this shit. These people need to be forced to stop this and fined tens of millions for privacy violation.
No, it's like cable TV where you pay the monthly fee even if you don't turn on the TV.
All subscriber monthly payments go into a big pot and authors get paid proportional to how many pages of their books have been read. But here's the odd thing: all authors make the same amount per page regardless of quality of writing, difficulty of the subject matter or whether it's in a niche market. That's just communistic and greedy of Amazon. Imagine a doctor, an engineer, a nurse and a bus driver getting the same wage, even though the doctor and engineer worked very hard to get where they were.
This type of pricing will encourage creation of cheap novels and reference material a lot.
That's fine as long as "whatever they want it," does not include distributing 200 free copies to other people. Because that would mean each reader only paid an average of 10 cents for the book, i.e., consumers being cheap and greedy.
A more robust solution would be using the highest bit in the variable to denote integer NaN. That would reduce your signed int32 into a signed 31 bit integer, the unsigned 32 bit var would become unsigned 31 bits, the signed 64-bit would become signed 63-bit integer and so on.
-iNaN = iNaN
iNaN + var -> iNaN
iNaN - var -> iNaN
iNaN * var -> iNaN
iNaN / var -> iNaN
iNaN | var -> iNaN
iNaN & var -> iNaN
iNaN ^ var -> iNaN
~iNaN -> iNaN
where var is either a valid integer or an iNaN.
But the more I think about it, it seems there are very few instances where we have integer divBy0 in a real program. Since most divide instructions belong to equations that are usually implemented in floating point code, there is no need to have any type of integer NaN.
It is not the correct answer since the correct answer is NaN. It's just a hack to avoid having to write exception handlers for every other line of FP code.
If we had to do tons of integer division, we would need an integer NaN too.
That's not easy, instead it's a nightmare. If you add try/catch near the point of division, you have to add these try-catch boilerplate code all over your code base. If you add the try-catch at a higher level (near your main()), that too causes headaches because now you have to restart and reinitialize the parts that got discarded after the exception was thrown.
It is precisely to handle these types of problems that the IEEE 754 standard uses NaN or Infinity for div-by-zero (because divisions are extremely common in FP code). That is, it is better to generate and propagate the wrong result (NaN) than it is to filter inputs and other data that cause div-by-zero, or handle exceptions in try/catch.
Yes, the highest bit should be reserved for nullity/NaN. Any arithmetic operation on a nullity variable should result in a nullity. There won't be any drop in performance if the CPU supports it, but the range of integers will be halved (from 2 billion to 1 billion for int32 variables). But that's not a big deal in a world where 64 bit integers are common.
That's like saying, "after 20 years of programming, your programs should not have bugs." That's just silly and wrong.
If you haven't read the article linked within the blog, nullity is supposed the new number that results when you divide something by 0.
The guy who posted on this blog is wrong:
1. That currently, dividing by zero on a computer causes problems because division by
zero is undefined. But if computers adopted nullity, then division by zero errors could be gotten rid of, because they'll produce nullity. Except of course that modern floating point hardware already *does* have a NaN value, and it *doesn't help* with the kind of problem he's talking about!
But we're not talking about floating-point hardware. Integer hardware still does not have a NaN, so the programmer has to add extra code to handle divide by zero.
No, it's undefined.
The 754 model encourages robust programs. It is intended not only for numerical analysts but also for spreadsheet users, database systems, or even coffee pots. The propagation rules for NaNs and infinities allow inconsequential exceptions to vanish. Similarly, gradual underflow maintains error properties over a precision's range.
http://stackoverflow.com/quest...
The IEEE 754 model treats 0 as very small positive numbers, resulting in infinity when you do divide by zero. Of course, that hack results in much more robust and safer programs as you don't have to deal with (dozens/hundreds) of exceptions in a program.
It is a very rare program that has INT_MAX/INT_MIN as valid values. If your program even reaches close to INT32_MAX/MIN, you usually change the type of variable to a signed 64 bit variable. So, as with IEEE 754, we should have a default value for div by zero by int32 or int64 to allow "inconsequential exceptions to vanish."
And in almost 20 years of its existence, how many Java programmers have complained about not being able to trap divide by zero in floating point? Java has already implemented a default value (+/-infinity) for floating point divide by zeros, as requested by the submitter of this /. story, and it's a success. Let's face it, returning +/- infinity has huge benefits in code simplicity. And therefore the same thing should be done for signed integers.
In a typical case, the int div-by-zero should return MAX_INT or MIN_INT. Down the line, garbage results caused by this div by zero alert the programmer to find the bug and fix it. As you can see, no div by zero exception handlers peppered throughout your code base.
Let's look at the catastrophes caused by integer/floating point exceptions:
Ariane 5 explosion:
A data conversion from 64-bit floating point value to 16-bit signed integer value to be stored in a variable representing horizontal bias caused a processor trap (operand error)[29] because the floating point value was too large to be represented by a 16-bit signed integer.
USS Yorktown
Smart ship USS Yorktown was left dead in the water in 1997 for nearly 3 hours after a divide by zero error.
I think a default divide by zero value would have prevented this.
Technically, the result in undefined, hence the exception is generated. However, practically speaking, for divisors close to zero but not zero, the result is +/- infinity, which is what happens in floating point code.
Well in Java, integer div by zero causes an ArithmeticException, whereas div by a floating-point zero results in +/-Infinity but no exception. Why should only integer code generate exceptions and not floating point code? Do floating point errors not matter?
I think this not generating an exception has something to do with the huge range of numbers floating point types have compared to integers. But integers are quite big now, so int32 or int64 (signed integers) should have compile time option to return INT_MAX or INT_MIN instead of generating an exception. Unsigned integers should still generate an exception.
That's okay, because Uber has other pizza drivers to deliver the pizzas.
Uber owns these drivers because, like employees, they have to bow down and follow Uber's rules:
But the commission said Uber controls the tools driver use, monitors their approval ratings and terminates their access to the system if their ratings fall below 4.6 stars.
Monitoring and firing people based on their performance sounds like a boss/employees type of relationship. That sounds more like dealing with an underling/employee rather than partnering with an independent contractor, the term Uber usually uses to describe its relationship to the taxi drivers.