I'm not as bothered by the lack of randomness as the violation of the constraints for a comparison function, as covered in the blog entry. It's like the newbies who want to write a comparison for a structure with two integer members, and write the is_less as (x.i y.i) || (x.j y.j) (or some such simplistic incorrect version).
I had an old just-a-phone get ran over by a loaded 18-wheeler. I had laid it down on the tire when I climbed the side to check the load and forgot it. It cracked the screen, but still made calls.
Oh well, I guess they can't survive everything. Pretty worthless if you can only make calls, and can't watch videos, play games, view photos anymore.
By average file, I meant mean, not median. If average must mean median, then I guess I'd have to write
You want the sector size to be less than the mean file size or you're going to waste a lot of space. If your mean file size is great, and writes are sequential, you want the largest possible sectors.
My main point was that a size is a magnitude; it has no size (or weight or temperature) itself. When I read smaller size, I picture a size printed in a smaller font. If you mean smaller, just write smaller.
1 byte = N bits, not necessarily 8. You're probably thinking of an octet, which is always 8 bits (except in universes where the oct prefix doesn't mean 8).
You want the sector size to be smaller than the average file size or you're going to waste a lot of space. If your average file size is large, and writes are sequential, you want the largest possible sector sizes.
Please take a few moments to notice the amount of redundancy above, and the lack of it in this rewritten version:
You want the sectors to be smaller than average files or you're going to waste a lot of space. If your average files are large, and writes are sequential, you want the largest possible sectors.
In other words, the adjective small implicitly refers to size, so you don't need to say small size, and the same for large.
Exactly. This is an OS issue, not a legal one. What, your OS doesn't allow you to control what programs are installed? Talk to the OS maker, not a politician.
they're offering to install a software update that would cause 'the brake pedal to take precedence over the gas pedal if both were pressed' or, as their latest notice states, 'would cut power to the engine if both pedals were pressed.'
Hmmm, so this update won't cut power to the engine if I'm pressing the brake and the accelerator isn't depressed, but the engine is running near maximum for some reason?
[...] the documents also gave reassurance about privacy policies used in those services, mainly that MS isn't logging chat between people in Messenger and that when you move the email from their servers to your local computer email box, it isn't kept on MS servers. While in contrast, in my understating, for example Google keeps even deleted email somewhere in their networked file system for many many months.
Or maybe this "leak" was to make you believe that MS doesn't log everything and keep it around for months. Perhaps they just store the logs on their Danger servers.
That was well worth reading. It touches on some interesting things, like how they originally kept power usage down to allow a cheaper plastic body for the chip, and how we don't have good profilers to find power usage hotspots in code.
Heh, I had to deal with this structure padding issue in some of my "portable" libraries. For convenience, I define a struct that matches a file header format. It's all char/unsigned char/arrays of such, so most compilers shouldn't pad it. But apparently on ARM it was being padded at the end to a multiple of 4 bytes. I solved this by not relying on sizeof(Mystruct).
In all versions, I have assertions to be sure the compiler isn't inserting any padding. That's how I originally found out about the ARM issue, due to one of these failing. So you can chastise me for relying on lack of padding between members, but not for assuming it, because I don't. In my current code, I assert that offsetof(Mystruct,last_member) is correct, BTW.
Hell, never mind rape, what about murder? Apparently murder is encouraged in many of these 3D games, and yet goes almost completely unpunished! We need some virtual law and order.
Several people have spoken about "linear" RGB. That's nice and gets rid of some small level of distortion introduced by the non-linearity. However, it only starts there. For example, the eye sees R, G, and B differently. It is more sensitive to green than red, and to red more than blue, but it's not even that simple as the equations in your eye's processor are much more complicated.
Actually, you've got it backwards. Image scaling is just simulating moving closer to or farther from the image, not the eye. But most images are stored in sRGB (or similar), which accommodates the eye's non-linear sensitivity. Thus, when scaling, this a image must be converted to linear first, in order to eliminate this accommodation.
Every time I hear "identity theft" and other referrals of uninvolved parties as victims of a crime, the lie bothers me.
Same here. The Mitchell & Webb Identity Theft parody perfectly illustrates how it's the bank who's had money stolen and been tricked, but is trying to reframe it as if it has something to do with you.
Slashdot Mirror
I'm not as bothered by the lack of randomness as the violation of the constraints for a comparison function, as covered in the blog entry. It's like the newbies who want to write a comparison for a structure with two integer members, and write the is_less as (x.i y.i) || (x.j y.j) (or some such simplistic incorrect version).
Yep. I've been reading some old Apple magazines from 1983 and many advertisements list a particular feature of their product: normal, copyable disks.
Excellent, I forgot about those acronyms as well. I was drawing a blank in my original post.
Oh well, I guess they can't survive everything. Pretty worthless if you can only make calls, and can't watch videos, play games, view photos anymore.
Hey, I'll take your never-needs-charging phone if you don't want it.
This one second booting will be perfect for ATM machines, so you don't have to wait to enter your PIN number.
Your post deserves a funny mod.
And as I understand it, this year == 2010 for all people that 1. are members of the general public and 2. are not crazy.
By average file, I meant mean, not median. If average must mean median, then I guess I'd have to write
My main point was that a size is a magnitude; it has no size (or weight or temperature) itself. When I read smaller size, I picture a size printed in a smaller font. If you mean smaller, just write smaller.
1 byte = N bits, not necessarily 8. You're probably thinking of an octet, which is always 8 bits (except in universes where the oct prefix doesn't mean 8).
Please take a few moments to notice the amount of redundancy above, and the lack of it in this rewritten version:
In other words, the adjective small implicitly refers to size, so you don't need to say small size, and the same for large.
Exactly. This is an OS issue, not a legal one. What, your OS doesn't allow you to control what programs are installed? Talk to the OS maker, not a politician.
Hmmm, so this update won't cut power to the engine if I'm pressing the brake and the accelerator isn't depressed, but the engine is running near maximum for some reason?
Or maybe this "leak" was to make you believe that MS doesn't log everything and keep it around for months. Perhaps they just store the logs on their Danger servers.
That was well worth reading. It touches on some interesting things, like how they originally kept power usage down to allow a cheaper plastic body for the chip, and how we don't have good profilers to find power usage hotspots in code.
Heh, I had to deal with this structure padding issue in some of my "portable" libraries. For convenience, I define a struct that matches a file header format. It's all char/unsigned char/arrays of such, so most compilers shouldn't pad it. But apparently on ARM it was being padded at the end to a multiple of 4 bytes. I solved this by not relying on sizeof(Mystruct).
In all versions, I have assertions to be sure the compiler isn't inserting any padding. That's how I originally found out about the ARM issue, due to one of these failing. So you can chastise me for relying on lack of padding between members, but not for assuming it, because I don't. In my current code, I assert that offsetof(Mystruct,last_member) is correct, BTW.
Hell, never mind rape, what about murder? Apparently murder is encouraged in many of these 3D games, and yet goes almost completely unpunished! We need some virtual law and order.
Get your virtual character 3 virtual years in a virtual jail, which of course you can try to virtually break out of.
I bet they'll still reject useful apps left and right, things like
Did you miss the fact that 66.67% and 27% don't add up to 100%?
I predict you're in a non-mathematical field, perhaps banking.
Actually, you've got it backwards. Image scaling is just simulating moving closer to or farther from the image, not the eye. But most images are stored in sRGB (or similar), which accommodates the eye's non-linear sensitivity. Thus, when scaling, this a image must be converted to linear first, in order to eliminate this accommodation.
In general, one should assume sRGB unless the file/format specifies otherwise.
I guess they're about to ban the iPhone itself for being too sexy. And here I thought Apple's goal was to make sexy products.
Same here. The Mitchell & Webb Identity Theft parody perfectly illustrates how it's the bank who's had money stolen and been tricked, but is trying to reframe it as if it has something to do with you.