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.

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.

It's been done. The results were crap.

The guy who posted on this blog is wrong:

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.

1/0 is indeed infinity.

No, it's undefined.

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.

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:

Ariane 5 explosion:

USS Yorktown

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.

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:

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.

It's not foolish because you don't get to select the songs that play on these radio sites. If you enjoy only 10-30% of songs on radio, you're the foolish one wasting your life to save $10.

you might use several times past that value

What happens in this case? Does Apple still pay some fixed amount to the copyright holders for each song played or does it reduce payment per song?