The color is actually better on the glossy screens, as they trade off some glare for a better contrast ratio and gamut. I have a 17" glossy MBP and do a ton of photography work on it, it's wonderful. I also have a matte-screen 15" MBP for coding on (given to me by the office), so I have some basis for comparison here.
Only 2 are used for bare metal apps and 95% of firmware (C, C++)
Personally, i wouldn't be caught dead using C++. C, only when the project values portability over performance. If you're writing for speed on bare metal, there's only one tool to use, and you didn't list it.
No, they have sued sites before that posted information leaked by someone under NDA. Which may also be bad thing, but is very different from suing someone for posting speculation, where no insider knowledge is present.
Who publicized it as fact? Dan Lyons didn't. His entire friggin' blog is satire, and anyone reading it should know that.
I do feel bad for the slashtards who can't figure that out, though.
On second thought, no I don't. I'm laughing my ass off at them. And at the people who are saying this is "irresponsible " of FSJ. The whole this is wonderfully Andy Kaufman-esque. If it upsets people to be tricked, they should exercise due diligence so it doesn't happen as frequently.
Yeah, contributing commercial OS source code to the OSS community is a terrible, terrible thing. Apple uses a lot of OSS code, but Apple gives back even more. The whole BSD layer, which includes a lot of superb library code developed at Apple -- not brought in from outside -- is available under APSL. Apple is also a major contributor to a number of other open source projects. My, what a terrible, terrible company. They really should steal OSS and not tell anyone else they're using it like the rest of the industry.
Apple doesn't "do this bullshit" either. If you bothered to actually do any research, it would be obvious this story is fake. (The fact that it's posted on the "FAKE steve jobs" weblog should be a big smoking clue, too). It's more like:
1 - 14. Various defense contractors
15. Sony (willful evilness)
16 - 99. Members of RIAA/MPAA, Utility companies, etc
100. Microsoft (stunning incompetence)
101 - 499. Energy companies, smaller defense contractors that you've never heard of
500. Google ("don't get caught doing evil, or turning over bloggers to totalitarian regimes")
1000. Apple ("Oh noes, they sued a blogger!!11one")
You might be tipped off by the fact that it's at the website "fakesteve.blogspot.com". You might also be tipped off if you, oh, I don't know, READ THE EFFING LINKS before commenting?
Judging from your other posts up above, you're just disappointed that you spent all that effort vilifying Apple over a story that turns out to be bogus.
Proof like... some frigtard not being able to tell satire from reality and posting to slashdot about how Oh Noes The Big Evil Company Is Going to Pwnzor The Blooger?
With proof like this, who needs a defense?
IEEE-754 is from 1985. It took 4 years for the rest of the world to get on board. 2007 - 1985 > 20. For the record, Excel's arithmetic is *not* IEEE-754 compliant, much to the numerical community's chagrin.
Now we have hardware to do floating-point maths, there probably is more consistency from one machine to another.
Yes, IEEE-754 (or IEC-60559:1989, for non-americans) pinned down single and double precision floating-point arithmetic over 20 years ago (up to a couple very rarely encountered corner cases).
Floating-point numbers are not 2s-complement integers, but neither are they sign-magnitude integers. They are a completely separate format. Double precision numbers have a 64-bit encoding, made up of a single sign bit, an 11-bit exponent, and a 52 bit significand. If you assign each field it's value as an unsigned integer, the floating point number has the value:
(Note that the floating point number with sign = 0, exponent = 1076, and significand = 0x1 has value 2^53 + 2, so there is no floating point representation of 2^53 + 1. Ditto for -2^53 - 1).
[pedantic]53 bits, actually. Double precision has an explicit 52 bit significand with one implicit bit for normal numbers. So all integers that can be represented in 53 bits are exactly representable in double, but half of the 54 bit integers are not -- those with the least significant bit set.
I'm not sure what you mean by "the exponent gets denormalized for this case." Denormal, when used to talk about floating-point, refers to numbers with the smallest exponent, for which there is no implicit leading bit. In double, these numbers range from just below 2^-1022 to 2^-1074 -- i.e., way smaller than any integer.[/pedantic]
Floating point can be used, as you noted, to do integer arithmetic on systems that don't have efficient 64-bit integer operations, and IEEE-754 provides the inexact flag to confirm that no roundings occured in the course of a sequence of floating-point computations. That said, 53 bits (or even 64 bits, using the x87 fpu) isn't nearly large enough for serious cryptographic work.
I code everything in assembly. It's much easier to debug than C, C++, C#, Java, or damn near any other language you can name. The only drawbacks to assembly is that it's insidiously non-portable, and you need to keep in mind all kinds of issues that a good compiler can deal with for you -- it takes me about 3 times longer to write a complex assembly function than it takes me to write the C analogue.
So why code in assembly? What I get in return is completely transparent debugging -- I can step through my code per instruction in a debugger, not have any mysteries about execution order, what the optimizer is doing, etc. The resulting code is typically between 30% and 200% faster than compiled C code. That's a huge win for system library functions or core computational routines that will be used in tight loops.
I can't speak for the grandparent, but I don't "avoid using useful tools merely because those tools aren't 100% perfect". I avoid using tools which are the wrong tool for the job. The question I have is: what job is Java/C# the right tool for? I can't think of one. If performance matters, really really matters (I mean, lives and dies by cycle count), then they're too slow. If performance isn't so important, there are more powerful languages in which it's easier to write clean code. These guys at Princeton probably could have written everything in OCaml / Python / Lisp and had no troubles at all.
As for getting left behind as progress marches on... I'm a young guy. I'm the only young guy I know who writes production quality assembly. Interestingly, I also get paid more than my other friends who are software engineers, and I have no worries at all about my job being shipped out to Elbonia. I look at the output of bleeding edge compilers, and work with compiler guys to try to improve their backend codegen. I know they told you in school that compilers were smart, and you should just lay out your algorithm properly and trust the compiler. They lied. My job's not going anywhere.
He's a leftist. He wants to know why so many nerds are libertarian. At no point does he say that Libertarian = Leftist.
Did your libertarian ideals prevent you from taking advantage of the free public education that the leftists tried to give you?
A group at Columbia (some people from Phil Kim's group, I think) published something along these lines in Physical Review Letters back in... May? I don't have access to my copies at the moment, so I don't know for sure. I believe that their paper references an even earlier paper (January?) on arxiv by a group from Thomas Watson. I haven't read the IBM paper, but I remember the Columbia paper being interesting.
Did you seriously just mention Bose in the same sentence that you were trying to make a statement about build quality and against things that are "trendy"?
Insert audiophile rants here
Seriously, though, buy some grados.
yep, your exactly right, but from a tech perspective these phoense are "equal" hell the iPhone competitor could be superior and still loose ("No wifi, less space than a nomad... lame"). The difference is in attention to detail (response time, no trying to touch a scroll bar, ect) and specifically the features that the target markets wants instead of what some engineer thought would be cool.
"Attention to detail (response time, no trying to touch a scroll bar, ect)" is the entirety of a "tech perspective". Attention to detail is what separates engineering from programming. You either do things right from the ground up or you don't. The little details like "response time" aren't something you can strap on after the fact.
Pizza-wheel of death != kernel panic. You'll know one if you see one, and the fact that you say "Remember the good old 10.1 days where you were lucky to go a week without a kernel panic?" means that you've probably never seen one. Unless you're severely abusive of your hardware and OS, or testing seed builds, you're not going to see them with a frequency of anything close to 1/week.
I get irritated by the pizza wheel too, but that's *far* from a kernel panic.
it does have the short-term impact of creating a class of apps where gcc isn't going to be as good as the industrial and research compilers That class already exists, and the impact isn't short-term. Sorry, gcc is quite good, but it's not as good as the industrial and research compilers on anything more complex than hello world.
Note that I use gcc regularly, and I believe it to be "good enough" in the vast majority of cases. But from a performance standpoint, it still has a long way to go.
Slashdot Mirror
The color is actually better on the glossy screens, as they trade off some glare for a better contrast ratio and gamut. I have a 17" glossy MBP and do a ton of photography work on it, it's wonderful. I also have a matte-screen 15" MBP for coding on (given to me by the office), so I have some basis for comparison here.
Mac OS 10.5 is UNIX when run on Intel. On PPC it is not, for somewhat convoluted legacy reasons.
Um, in this case... it's SATIRE. As in, "not real", or "fake", like "fake steve jobs".
No, they have sued sites before that posted information leaked by someone under NDA. Which may also be bad thing, but is very different from suing someone for posting speculation, where no insider knowledge is present.
Who publicized it as fact? Dan Lyons didn't. His entire friggin' blog is satire, and anyone reading it should know that.
I do feel bad for the slashtards who can't figure that out, though.
On second thought, no I don't. I'm laughing my ass off at them. And at the people who are saying this is "irresponsible " of FSJ. The whole this is wonderfully Andy Kaufman-esque. If it upsets people to be tricked, they should exercise due diligence so it doesn't happen as frequently.
"Riding the backs of FOSS"??!
Yeah, contributing commercial OS source code to the OSS community is a terrible, terrible thing. Apple uses a lot of OSS code, but Apple gives back even more. The whole BSD layer, which includes a lot of superb library code developed at Apple -- not brought in from outside -- is available under APSL. Apple is also a major contributor to a number of other open source projects. My, what a terrible, terrible company. They really should steal OSS and not tell anyone else they're using it like the rest of the industry.
Apple doesn't "do this bullshit" either. If you bothered to actually do any research, it would be obvious this story is fake. (The fact that it's posted on the "FAKE steve jobs" weblog should be a big smoking clue, too). It's more like: 1 - 14. Various defense contractors 15. Sony (willful evilness) 16 - 99. Members of RIAA/MPAA, Utility companies, etc 100. Microsoft (stunning incompetence) 101 - 499. Energy companies, smaller defense contractors that you've never heard of 500. Google ("don't get caught doing evil, or turning over bloggers to totalitarian regimes") 1000. Apple ("Oh noes, they sued a blogger!!11one")
You might be tipped off by the fact that it's at the website "fakesteve.blogspot.com". You might also be tipped off if you, oh, I don't know, READ THE EFFING LINKS before commenting?
Judging from your other posts up above, you're just disappointed that you spent all that effort vilifying Apple over a story that turns out to be bogus.
Proof like... some frigtard not being able to tell satire from reality and posting to slashdot about how Oh Noes The Big Evil Company Is Going to Pwnzor The Blooger? With proof like this, who needs a defense?
C'mon people, think! It's the FAKE Steve Jobs blog. Did it occur to you that the stories there might be FAKE? This is satire, and you're all fools.
IEEE-754 is from 1985. It took 4 years for the rest of the world to get on board. 2007 - 1985 > 20. For the record, Excel's arithmetic is *not* IEEE-754 compliant, much to the numerical community's chagrin.
Floating-point numbers are not 2s-complement integers, but neither are they sign-magnitude integers. They are a completely separate format. Double precision numbers have a 64-bit encoding, made up of a single sign bit, an 11-bit exponent, and a 52 bit significand. If you assign each field it's value as an unsigned integer, the floating point number has the value:
(-1)^(sign) * 2^(exponent - 1023) * (1 + 2^(-52)*significand)
for exponents that are neither zero nor 2047 (the maximum possible exponent). If the exponent is zero, then the floating point number has the value:
(-1)^(sign) * 2^(-1074) * significand
if the exponent is 2047, then the floating-point number is either an infinity or NaN.
The wikipedia page has a decent description of the format, I encourage you to read it: http://en.wikipedia.org/wiki/IEEE_754
What's the point of all this? All integers between -2^53 and 2^53 really are representable as double precision numbers:
-2^53: sign = 1, exponent = 1076, significand = 0x0.
-2^53 + 1: sign = 1, exponent = 1075, significand = 0xfffffffffffff.
-2^53 + 2: sign = 1, exponent = 1075, significand = 0xffffffffffffe.
.
.
.
-2^52 - 1: sign = 1, exponent = 1075, significand = 0x1.
-2^52: sign = 1, exponent = 1075, significand = 0x0.
.
.
.
-3: sign = 1, exponent = 1024, significand = 0x8000000000000.
-2: sign = 1, exponent = 1024, significand = 0x0.
-1: sign = 1, exponent = 1023, significand = 0x0.
-0: sign = 1, exponent = 0, significand = 0x0.
+0: sign = 0, exponent = 0, significand = 0x0.
1: sign = 0, exponent = 1023, significand = 0x0.
2: sign = 0, exponent = 1024, significand = 0x0.
3: sign = 0, exponent = 1024, significand = 0x8000000000000.
4: sign = 0, exponent = 1025, significand = 0x0.
5: sign = 0, exponent = 1025, significand = 0x4000000000000.
6: sign = 0, exponent = 1025, significand = 0x8000000000000.
7: sign = 0, exponent = 1025, significand = 0xc000000000000.
.
.
.
2^53 - 1: sign = 0, exponent = 1075, significand = 0xfffffffffffff.
2^53: sign = 0, exponent = 1076, significand = 0x0.
(Note that the floating point number with sign = 0, exponent = 1076, and significand = 0x1 has value 2^53 + 2, so there is no floating point representation of 2^53 + 1. Ditto for -2^53 - 1).
[pedantic]53 bits, actually. Double precision has an explicit 52 bit significand with one implicit bit for normal numbers. So all integers that can be represented in 53 bits are exactly representable in double, but half of the 54 bit integers are not -- those with the least significant bit set.
I'm not sure what you mean by "the exponent gets denormalized for this case." Denormal, when used to talk about floating-point, refers to numbers with the smallest exponent, for which there is no implicit leading bit. In double, these numbers range from just below 2^-1022 to 2^-1074 -- i.e., way smaller than any integer.[/pedantic]
Floating point can be used, as you noted, to do integer arithmetic on systems that don't have efficient 64-bit integer operations, and IEEE-754 provides the inexact flag to confirm that no roundings occured in the course of a sequence of floating-point computations. That said, 53 bits (or even 64 bits, using the x87 fpu) isn't nearly large enough for serious cryptographic work.
I code everything in assembly. It's much easier to debug than C, C++, C#, Java, or damn near any other language you can name. The only drawbacks to assembly is that it's insidiously non-portable, and you need to keep in mind all kinds of issues that a good compiler can deal with for you -- it takes me about 3 times longer to write a complex assembly function than it takes me to write the C analogue. So why code in assembly? What I get in return is completely transparent debugging -- I can step through my code per instruction in a debugger, not have any mysteries about execution order, what the optimizer is doing, etc. The resulting code is typically between 30% and 200% faster than compiled C code. That's a huge win for system library functions or core computational routines that will be used in tight loops. I can't speak for the grandparent, but I don't "avoid using useful tools merely because those tools aren't 100% perfect". I avoid using tools which are the wrong tool for the job. The question I have is: what job is Java/C# the right tool for? I can't think of one. If performance matters, really really matters (I mean, lives and dies by cycle count), then they're too slow. If performance isn't so important, there are more powerful languages in which it's easier to write clean code. These guys at Princeton probably could have written everything in OCaml / Python / Lisp and had no troubles at all. As for getting left behind as progress marches on... I'm a young guy. I'm the only young guy I know who writes production quality assembly. Interestingly, I also get paid more than my other friends who are software engineers, and I have no worries at all about my job being shipped out to Elbonia. I look at the output of bleeding edge compilers, and work with compiler guys to try to improve their backend codegen. I know they told you in school that compilers were smart, and you should just lay out your algorithm properly and trust the compiler. They lied. My job's not going anywhere.
He's a leftist. He wants to know why so many nerds are libertarian. At no point does he say that Libertarian = Leftist. Did your libertarian ideals prevent you from taking advantage of the free public education that the leftists tried to give you?
A group at Columbia (some people from Phil Kim's group, I think) published something along these lines in Physical Review Letters back in... May? I don't have access to my copies at the moment, so I don't know for sure. I believe that their paper references an even earlier paper (January?) on arxiv by a group from Thomas Watson. I haven't read the IBM paper, but I remember the Columbia paper being interesting.
Did you seriously just mention Bose in the same sentence that you were trying to make a statement about build quality and against things that are "trendy"? Insert audiophile rants here Seriously, though, buy some grados.
Actually, that was one of Steve Jobs' design requirements. Actually, it was the only one.
Pizza-wheel of death != kernel panic. You'll know one if you see one, and the fact that you say "Remember the good old 10.1 days where you were lucky to go a week without a kernel panic?" means that you've probably never seen one. Unless you're severely abusive of your hardware and OS, or testing seed builds, you're not going to see them with a frequency of anything close to 1/week. I get irritated by the pizza wheel too, but that's *far* from a kernel panic.
Note that I use gcc regularly, and I believe it to be "good enough" in the vast majority of cases. But from a performance standpoint, it still has a long way to go.
Works perfectly in safari 3 on a mac. Windows bug?