The standard applications work alright, but as soon as you want to step outside of the box you have to download the Developer Tools (1GB+ download)
The full set of developer tools for OS X have shipped on the install disc for every recent OS X version (including the install discs you get when you buy a new system), as well as being available as a free download.
High gas prices aren't a crisis, they're a natural consequence of demand outstripping supply. Boohoo, I can't afford to commute to work because I bought a McMansion 80 miles away with an ARM because gas was cheap for my Hummer. It's not like anyone with a minimal capacity for rational thought couldn't have seen this coming.
Wait for winter. When people can't afford heating oil because the price is still being driven up by idiots who commute 80 miles so they can live in their McMansion, then I'll call it a crisis (and expect the government to do something about it). Right now it's just a bunch of whiny brats complaining that oil is no longer cheaper than water, and I'm perfectly happy to watch the free market punish them for it.
What is proven is that a quantum computer can outperform a classical computer polynomially (in algorithms based on unstructured search) and that it can outperform the best currently known classical algorithms for some problems (factoring, quantum simulation) exponentially.
Not even for factoring, actually. Factoring is known to be sub-exponential. =)
Actually, it doesn't matter how fast a classical computer operates, a quantum computer WILL go exponentially faster regardless.
I really, really hope that you failed whatever course the report was for. There is not, at present, any known problem which for which a quantum-computing algorithm is known to be exponentially faster than the fastest classical algorithm.
Factoring is known to be sub-exponential, so Shor's O(n^3) quantum algorithm does not provide an exponential speedup.
The strongest known result in terms of speedup for quantum algorithms is for unordered search, from O(n) to O(sqrt(n)), which, again, is not an exponential speedup.
There are some intuitive arguments for why an exponential speedup might be possible. There are also some intuitive arguments for why it shouldn't be. There is no proof either way, as things currently stand.
(Note: I am not an expert in the field. This reflects my understanding, which was current as of about 5 years ago. To the best of my knowledge, things have not changed, but I don't read the literature like I do in other areas).
Is there any particular reason to believe it's buggy? Is there something special about Apple's engineers that makes them more likely to find a bug than the Xiph community?
Only that it's their job to do so. When something is a hobby, it's easy to say "it works well enough for my purposes, let's ship it". It's much harder to justify that when you're actually selling a product.
I haven't used the Xiph stuff, it could be excellent, as some open source projects are. It also could... not be, as is the case for other open source projects.
By this logic, regression tests either were written at the start of time, or don't exist. When you add a component to a project, you (hopefully) add regression tests for it. Writing those tests requires work.
I'm still missing something here. A codec is about as simple an interface as you can get -- encoded data in, decoded data out. What would make the Ogg tests different than the AAC tests?
Does floating-point division require a different set of tests than floating-point multiplication? They both take two floating-point values as arguments and return one. (Hint: that's a rhetorical question).
Suppose that every song were 4MB. They're not, but just suppose they were. There are more than 2^(32,000,000) possible 4MB blocks of data. You can't even begin to hope to test that a codec does the right thing with all of them (and the vast bulk are probably just garbage anyway). You need to pick some meaningful subset that is likely to reveal bugs. Do you really expect that that subset is exactly the same for OGG and MP3 and AAC?
Or are you assuming there would be a number of quirky bugs that Apple would immediately have to fix in the codec itself?
I think there's a decent chance of that, yes. Do you have some reason to believe that the code is bug-free? (Certainly, Apple ships software with bugs, but there is such a thing as software too buggy to ship).
And yes, when people can patent a mathematical function, I call bullshit.
I might agree with you about this, but it's neither here nor there.
Apple doesn't do routine security audits -- or that this one feature would require its own audit.
I assume Apple does routine security audits. This "one feature" (actually a good sized chunk of code, and codecs are notoriously prone to security flaws) would almost certainly require its own audit.
Apple doesn't have a rigorous regression suite for iTunes.
I assume they do. But it doesn't include tests for a component of the code that doesn't currently exist. I'm suggesting that it will take time to write a good set of tests for the specific codecs that you propose to add, not for iTunes as a whole.
Apple's code -- or the open source code -- is written so poorly that integrating the two would instantly cause 100 crashers.
Nope, I'm suggesting that there could be crashers in the open source code even without doing any hacks for integration. Is it tested on all possible input data? Obviously not (it would be impossible). I might reasonably hope that it is at least well tested, but there are (almost) always bugs, even in well tested code.
That basically leaves legal BS. But at this point, how much damage would they cause? It cost you almost nothing to implement it, and it'll cost you almost nothing to remove it.
They have a responsibility to the shareholders to perform legal due diligence. That isn't "legal BS", it's doing your job.
What I don't understand is why there is such an insane gap between the prototype and the working product.
For me, this pretty much sums up why OS X is OS X and Linux is Linux. Reasonably people may disagree.
Anyone who says "because it would cost money" is a moron. All of these formats have free implementations -- in fact, as far as I know, all of them have free, patent-free, royalty-free, and MIT license at worst, which means if iTunes is at all pluggable, it should take one engineer maybe two hours to add support for them, if that.
A couple hours to prototype. A couple weeks to optimize playback so that it doesn't kill a laptop's battery life.* A couple weeks to optimize for playback on an itty-bitty iPhone / iPod processor.* A couple weeks to do a complete security audit. A couple weeks to bring up a rigorous regression suite. A couple weeks to fix the 100-something crashers that the test suite turned up. A couple weeks to clear everything with legal and do a search for submarine patents.
(*) I honestly don't know what the performance of open source ogg decoding is like these days, but I would stake a wager that whatever it is, it could be improved on. I suppose it's possible that it's already quite excellent, in which case you might be able to skip these two steps. Still, you're looking at many engineer-weeks to bring to market a feature that almost nobody needs.
Apple sells an upscale urban life-style. Microsoft solid middle class value.
Apple has the boutique in Manhattan. Microsoft the big-box retailer in every township populous enough to rate a single traffic light.
Long term and with the economy in recession, who do you think holds the stronger cards?
Upscale urban buyers are going to be relatively unaffected by a recession. It's the middle class that gets pinched.
This was true once (before Wilkinson/Kahan/others showed that you could do meaningful error analysis for floating-point all those years ago). It's not really true anymore. The vast bulk of scientific computing is now done in floating-point, except for specialized problems that require more than double precision, or problems that are fundamentally discrete in nature and are best performed in integer.
The performance benefit from using hardware floating-point vs. soft float is simply too huge to be left on the table. Double precision is rarely "perfect", as you say, but it is by far the most used format for scientific computing:
Consider that EVERY computation in MATLAB is done in double, and you've already got one giant slice of the scientific market. On top of that, most of the most heavily used libraries for scientific computing (BLAS, LAPACK, FFTW, for example) provide double and single precision routines (not integer).
Single precision only, non IEEE-754 arithmetic isn't a "real win for scientific computing". It's a win for getting the wrong answers really, really quickly.
Yes, I know that there are problems for which the limitations of the SPEs don't kill the accuracy of the solution, but people (even scientists) rarely do a complete analysis of whether or not their problem is one of those before they set off to use the new faster hotness.
Bullshit. All I was saying was that the skills that qualify people for writing math libraries don't qualify them for working for ad placement. Are you joking? This might have been all you were trying to say when you started, but it's not what you actually *did* say, and you've since spewed so much nonsense and zealotry that whatever point you might have been trying to make is long gone in the wash. Some of my personal favorites:
Apple is all about design and marketing fluff, with a little engineering thrown in.
I doubt it will get you a job at all if implementation of transcendental functions is your primary skill.
Darwin's libm is based on Berkeley's, and the last release seems to have been in 2006
If Apple engineers are re-implementing transcendental functions or encryption routines for OS X, they are fools. Do you actually think that any of this has to do with what you claim to be arguing about? Hell, I agree with the point that you say you were originally trying to make. Writing transcendental function libraries is very different from doing statistics.
What I disagree with is that implementing transcendental functions requires no mathematical knowledge, and all of the other nonsense that you've posted since then. I'm just trying to refute some obviously misinformed opinions. If that comes across as being an Apple zealot, I'm sorry that you feel that way. Sometimes the world isn't the way you think it is.
Darwin's libm is based on Berkeley's, and the last release seems to have been in 2006 Darwin's Libm is almost entirely *not* based on BSD, and is pretty damn easy to find with Google (you may need to register at opensource.apple.com in order to grab the sources from there):
A quick search didn't find any direct benchmarks comparing Apple's libm to glibc, but does turn up plentiful evidence that the GNU libm is lousy enough that Apple would be very well motivated to write their own:
Have a look at the performance and accuracy tables comparing the GNU libm to the Intel libm on pages 17 and 18. The GNU library is 3 times slower and orders of magnitude less accurate than the Intel library.
You haven't shown any benchmarks, there are no papers, nothing. It's all just a bunch of hot air. Neither have you. I wouldn't get too indignant.
If they don't publish, they aren't contributing to science or research, it's that simple. If they make some researcher's climate simulation run 10% faster, or give more accurate results than the scientist can get from the GNU libm, then yes, they're contributing to science and research. Far more so than we are by having this discussion.
The standard Linux ones would be a good start. Heck, Apple might even contribute to them if they actually were doing anything interesting in the area (which they don't seem to be).
Apple makes their libm available under APSL. If you are interested in such things, I suggest you look at it.
Does Apple provide accuracy proofs for their libraries? No.
Does Apple provide evidence that their libraries achieve (near-) optimal performance on Apple's current hardware? No.
Does Apple provide any evidence that their hardware/software combo is higher performance than equivalent Linux machines? No.
They don't have to -- they're not trying to convince you to use their library, whereas you seem to take it as gospel that they should use the Linux library. I'm merely asking you for evidence to support that assertion.
Have Apple employees published any significant papers on mathematics, numerical algorithms, or statistics recently? No.
I am highly doubtful that you know this with any certainty. It may or may not be true, I honestly have no idea. I know of a few relevant patents, and that several Apple employees played important roles in the IEEE 754 revision process, which I would argue is more important than most research papers as it has a direct effect on state of scientific computing. I don't believe that any of the linux libm maintainers chose to participate in the process -- apparently the fundamental standard for machine arithmetic isn't important to them?
Apple is a dead end when it comes to mathematics or computer science; there is little that's interesting happening there. Apple is all about design and marketing fluff, with a little engineering thrown in.
I know a few Math PhDs at Apple who would take pretty severe exception to this claim. It's not academia. They don't publish tons of papers -- they work on real products, and often patent their work. It's a tradeoff; they chose to directly benefit millions of users immediately in exchange for forgoing a chance at someday being remembered as one of the great names of Mathematics via their publications. You may not agree with the choice, but that doesn't make it wrong.
The fact that they don't go out of their way to publicize their work doesn't mean that it isn't happening, or that they aren't rewarded for it internally.
Yes, but only a little, plus a bag of tricks and hacks that don't generalize to anything else.
It is very easy to write an libm that works. It is hard to write a libm that works *fast*, to say nothing of FFT or vector math libraries (both of which Apple ships in the Accelerate.framework). It requires a pretty substantial amount of low-level performance understanding, and that generalizes to other low-level performance problems. Suppose you have two candidate parts for the CPU of an iPod. Part A is 10 cents cheaper than part B, but executes some critical software path 10% too slowly. If said engineer can apply his or her low-level performance knowledge to get a 15% speedup to the critical path while maintaining accuracy (which is an entirely reasonable speedup for a low-level performance specialist to be able to produce), they just saved Apple 5 million dollars a year.
No, I don't think there'd be any demand for that sort of thing either.
Well, you're entitled to your opinions. But whatever your opinion, fact is that knowledge of how to write a double precision log function won't get you a machine learning or statistics job. In fact, I doubt it will get you a job at all if implementation of transcendental functions is your primary skill.
I have a couple published papers on machine learning. Nothing incredible, but one is now well into the hundreds of citations. A good, respectable paper. I have more respect for the guys writing math libraries at Intel, Apple and HP than I have for all but a handful of people in the field of machine learning, and they cer
If Apple engineers are re-implementing transcendental functions or encryption routines for OS X, they are fools. "re-implementing" from what exactly? Which state-of-the art transcendental function or encryption libraries should Apple be using instead of writing their own? Do you have references for accuracy proofs of said libraries? What evidence do you have that said routines achieve (near-) optimal performance on Apple's current hardware?
You don't huh?
Then I don't think you're in any position to call them fools.
And, you're right, that requires little mathematical knowledge and even less mathematical understanding. I was at a conference a few months ago for Beresford Parlett's birthday (since you're such an authority on mathematical computation, you surely know who he is), and at the end of his plenary talk, he took a few minutes to bemoan the fact that in a room filled with PhDs in Applied Mathematics and Computer Science, there were probably no more than one or two who could quickly and correctly implement the double-precision log function with good accuracy and performance (in the words of one professor who is a numerical analyst, "I wouldn't even know where to begin"). So, yes, I'd say it requires a little mathematical knowledge and understanding. Certainly more than the elementary statistical analysis necessary to sell Advertisements.
OS engineers do not write "cool apps". We write the kernel and libraries that enable other people to write "cool apps".
All the "features" that you're talking about aren't part of an operating system, and thus have no place in a discussion of how easy or hard it would be for Apple to add significant features to a future OS. They are applications. It's possible that an apps team at Apple might write them and include them for free with the OS, but they aren't part of the OS in any meaningful way.
When an OS vendor says that they're focusing on stability and performance, they mean that the engineers who work on the system libraries and kernel aren't going to spend their time making it do fundamentally new things, they're going to focus instead on making it do the thing it already does faster and more correctly (which may require a complete rewrite of huge sections of code).
This has essentially nothing to do with the sort of "features" that you're talking about. Trivial little toy applications are neither here nor there.
I'd be interested to read your references for the "historical fact that Mohammad dictated the Koran while in what modern people would call a seizer."
Not a lot of historical documents from that time period have survived, so I'm curious about your hidden stash of medical records. I'm also curious about your apparent collection of criminal (or are they professional?) records establishing the prophet as a baby-raper.
The God you worship may not like baby-rapers, but does he know how to spell "seizure"? I don't really care about the answer; I just want to use this opportunity to be a condescending punk and point out that you're not only delusional, but also can't spell properly.
You may also want to review the rules of English capitalization.
I don't know what you've done to your terminal preferences, but on mine there's a little button at the bottom of the "Settings" pane that says "Default". If I click that, then new windows will open with the selected style. This has been in place since 10.5.0, at least.
Slashdot Mirror
The standard applications work alright, but as soon as you want to step outside of the box you have to download the Developer Tools (1GB+ download)
The full set of developer tools for OS X have shipped on the install disc for every recent OS X version (including the install discs you get when you buy a new system), as well as being available as a free download.
What crisis?
High gas prices aren't a crisis, they're a natural consequence of demand outstripping supply. Boohoo, I can't afford to commute to work because I bought a McMansion 80 miles away with an ARM because gas was cheap for my Hummer. It's not like anyone with a minimal capacity for rational thought couldn't have seen this coming.
Wait for winter. When people can't afford heating oil because the price is still being driven up by idiots who commute 80 miles so they can live in their McMansion, then I'll call it a crisis (and expect the government to do something about it). Right now it's just a bunch of whiny brats complaining that oil is no longer cheaper than water, and I'm perfectly happy to watch the free market punish them for it.
I just threw up a little bit in my mouth.
What is proven is that a quantum computer can outperform a classical computer polynomially (in algorithms based on unstructured search) and that it can outperform the best currently known classical algorithms for some problems (factoring, quantum simulation) exponentially.
Not even for factoring, actually. Factoring is known to be sub-exponential. =)
Actually, it doesn't matter how fast a classical computer operates, a quantum computer WILL go exponentially faster regardless.
I really, really hope that you failed whatever course the report was for. There is not, at present, any known problem which for which a quantum-computing algorithm is known to be exponentially faster than the fastest classical algorithm.
Factoring is known to be sub-exponential, so Shor's O(n^3) quantum algorithm does not provide an exponential speedup.
The strongest known result in terms of speedup for quantum algorithms is for unordered search, from O(n) to O(sqrt(n)), which, again, is not an exponential speedup.
There are some intuitive arguments for why an exponential speedup might be possible. There are also some intuitive arguments for why it shouldn't be. There is no proof either way, as things currently stand.
(Note: I am not an expert in the field. This reflects my understanding, which was current as of about 5 years ago. To the best of my knowledge, things have not changed, but I don't read the literature like I do in other areas).
Is there any particular reason to believe it's buggy? Is there something special about Apple's engineers that makes them more likely to find a bug than the Xiph community?
Only that it's their job to do so. When something is a hobby, it's easy to say "it works well enough for my purposes, let's ship it". It's much harder to justify that when you're actually selling a product.
I haven't used the Xiph stuff, it could be excellent, as some open source projects are. It also could... not be, as is the case for other open source projects.
Which makes those not regression tests.
By this logic, regression tests either were written at the start of time, or don't exist. When you add a component to a project, you (hopefully) add regression tests for it. Writing those tests requires work.
I'm still missing something here. A codec is about as simple an interface as you can get -- encoded data in, decoded data out. What would make the Ogg tests different than the AAC tests?
Does floating-point division require a different set of tests than floating-point multiplication? They both take two floating-point values as arguments and return one. (Hint: that's a rhetorical question).
Suppose that every song were 4MB. They're not, but just suppose they were. There are more than 2^(32,000,000) possible 4MB blocks of data. You can't even begin to hope to test that a codec does the right thing with all of them (and the vast bulk are probably just garbage anyway). You need to pick some meaningful subset that is likely to reveal bugs. Do you really expect that that subset is exactly the same for OGG and MP3 and AAC?
Or are you assuming there would be a number of quirky bugs that Apple would immediately have to fix in the codec itself?
I think there's a decent chance of that, yes. Do you have some reason to believe that the code is bug-free? (Certainly, Apple ships software with bugs, but there is such a thing as software too buggy to ship).
And yes, when people can patent a mathematical function, I call bullshit.
I might agree with you about this, but it's neither here nor there.
Apple doesn't do routine security audits -- or that this one feature would require its own audit.
I assume Apple does routine security audits. This "one feature" (actually a good sized chunk of code, and codecs are notoriously prone to security flaws) would almost certainly require its own audit.
Apple doesn't have a rigorous regression suite for iTunes.
I assume they do. But it doesn't include tests for a component of the code that doesn't currently exist. I'm suggesting that it will take time to write a good set of tests for the specific codecs that you propose to add, not for iTunes as a whole.
Apple's code -- or the open source code -- is written so poorly that integrating the two would instantly cause 100 crashers.
Nope, I'm suggesting that there could be crashers in the open source code even without doing any hacks for integration. Is it tested on all possible input data? Obviously not (it would be impossible). I might reasonably hope that it is at least well tested, but there are (almost) always bugs, even in well tested code.
That basically leaves legal BS. But at this point, how much damage would they cause? It cost you almost nothing to implement it, and it'll cost you almost nothing to remove it.
They have a responsibility to the shareholders to perform legal due diligence. That isn't "legal BS", it's doing your job.
What I don't understand is why there is such an insane gap between the prototype and the working product.
For me, this pretty much sums up why OS X is OS X and Linux is Linux. Reasonably people may disagree.
Anyone who says "because it would cost money" is a moron. All of these formats have free implementations -- in fact, as far as I know, all of them have free, patent-free, royalty-free, and MIT license at worst, which means if iTunes is at all pluggable, it should take one engineer maybe two hours to add support for them, if that.
A couple hours to prototype.
A couple weeks to optimize playback so that it doesn't kill a laptop's battery life.*
A couple weeks to optimize for playback on an itty-bitty iPhone / iPod processor.*
A couple weeks to do a complete security audit.
A couple weeks to bring up a rigorous regression suite.
A couple weeks to fix the 100-something crashers that the test suite turned up.
A couple weeks to clear everything with legal and do a search for submarine patents.
(*) I honestly don't know what the performance of open source ogg decoding is like these days, but I would stake a wager that whatever it is, it could be improved on. I suppose it's possible that it's already quite excellent, in which case you might be able to skip these two steps. Still, you're looking at many engineer-weeks to bring to market a feature that almost nobody needs.
http://en.wikipedia.org/wiki/List_of_Jewish_American_sportspeople
Apple sells an upscale urban life-style. Microsoft solid middle class value.
Apple has the boutique in Manhattan. Microsoft the big-box retailer in every township populous enough to rate a single traffic light.
Long term and with the economy in recession, who do you think holds the stronger cards?
Upscale urban buyers are going to be relatively unaffected by a recession. It's the middle class that gets pinched.
Is it still full 754-compliant double precision, or is it round-to-zero-only-and-god-knows-what-other-shortcuts like single?
If it's a fully 754 implementation, this is good news.
Finding Nemo?
Toy Story?
Monsters, Inc?
Cars?
Lack of humans is pretty much the norm for Pixar movies. The Incredibles is the odd one out.
This was true once (before Wilkinson/Kahan/others showed that you could do meaningful error analysis for floating-point all those years ago). It's not really true anymore. The vast bulk of scientific computing is now done in floating-point, except for specialized problems that require more than double precision, or problems that are fundamentally discrete in nature and are best performed in integer.
The performance benefit from using hardware floating-point vs. soft float is simply too huge to be left on the table. Double precision is rarely "perfect", as you say, but it is by far the most used format for scientific computing:
Consider that EVERY computation in MATLAB is done in double, and you've already got one giant slice of the scientific market. On top of that, most of the most heavily used libraries for scientific computing (BLAS, LAPACK, FFTW, for example) provide double and single precision routines (not integer).
Single precision only, non IEEE-754 arithmetic isn't a "real win for scientific computing". It's a win for getting the wrong answers really, really quickly.
Yes, I know that there are problems for which the limitations of the SPEs don't kill the accuracy of the solution, but people (even scientists) rarely do a complete analysis of whether or not their problem is one of those before they set off to use the new faster hotness.
What I disagree with is that implementing transcendental functions requires no mathematical knowledge, and all of the other nonsense that you've posted since then. I'm just trying to refute some obviously misinformed opinions. If that comes across as being an Apple zealot, I'm sorry that you feel that way. Sometimes the world isn't the way you think it is. Darwin's libm is based on Berkeley's, and the last release seems to have been in 2006 Darwin's Libm is almost entirely *not* based on BSD, and is pretty damn easy to find with Google (you may need to register at opensource.apple.com in order to grab the sources from there):
http://www.opensource.apple.com/darwinsource/10.5.3/Libm-292.4/
A quick search didn't find any direct benchmarks comparing Apple's libm to glibc, but does turn up plentiful evidence that the GNU libm is lousy enough that Apple would be very well motivated to write their own:
http://rnc7.loria.fr/astafiev.pdf
Have a look at the performance and accuracy tables comparing the GNU libm to the Intel libm on pages 17 and 18. The GNU library is 3 times slower and orders of magnitude less accurate than the Intel library. You haven't shown any benchmarks, there are no papers, nothing. It's all just a bunch of hot air. Neither have you. I wouldn't get too indignant. If they don't publish, they aren't contributing to science or research, it's that simple. If they make some researcher's climate simulation run 10% faster, or give more accurate results than the scientist can get from the GNU libm, then yes, they're contributing to science and research. Far more so than we are by having this discussion.
The standard Linux ones would be a good start. Heck, Apple might even contribute to them if they actually were doing anything interesting in the area (which they don't seem to be).
Apple makes their libm available under APSL. If you are interested in such things, I suggest you look at it.
Does Apple provide accuracy proofs for their libraries? No.
Does Apple provide evidence that their libraries achieve (near-) optimal performance on Apple's current hardware? No.
Does Apple provide any evidence that their hardware/software combo is higher performance than equivalent Linux machines? No.
They don't have to -- they're not trying to convince you to use their library, whereas you seem to take it as gospel that they should use the Linux library. I'm merely asking you for evidence to support that assertion.
Have Apple employees published any significant papers on mathematics, numerical algorithms, or statistics recently? No.
I am highly doubtful that you know this with any certainty. It may or may not be true, I honestly have no idea. I know of a few relevant patents, and that several Apple employees played important roles in the IEEE 754 revision process, which I would argue is more important than most research papers as it has a direct effect on state of scientific computing. I don't believe that any of the linux libm maintainers chose to participate in the process -- apparently the fundamental standard for machine arithmetic isn't important to them?
Apple is a dead end when it comes to mathematics or computer science; there is little that's interesting happening there. Apple is all about design and marketing fluff, with a little engineering thrown in.
I know a few Math PhDs at Apple who would take pretty severe exception to this claim. It's not academia. They don't publish tons of papers -- they work on real products, and often patent their work. It's a tradeoff; they chose to directly benefit millions of users immediately in exchange for forgoing a chance at someday being remembered as one of the great names of Mathematics via their publications. You may not agree with the choice, but that doesn't make it wrong.
The fact that they don't go out of their way to publicize their work doesn't mean that it isn't happening, or that they aren't rewarded for it internally.
Yes, but only a little, plus a bag of tricks and hacks that don't generalize to anything else.
It is very easy to write an libm that works. It is hard to write a libm that works *fast*, to say nothing of FFT or vector math libraries (both of which Apple ships in the Accelerate.framework). It requires a pretty substantial amount of low-level performance understanding, and that generalizes to other low-level performance problems. Suppose you have two candidate parts for the CPU of an iPod. Part A is 10 cents cheaper than part B, but executes some critical software path 10% too slowly. If said engineer can apply his or her low-level performance knowledge to get a 15% speedup to the critical path while maintaining accuracy (which is an entirely reasonable speedup for a low-level performance specialist to be able to produce), they just saved Apple 5 million dollars a year.
No, I don't think there'd be any demand for that sort of thing either.
Well, you're entitled to your opinions. But whatever your opinion, fact is that knowledge of how to write a double precision log function won't get you a machine learning or statistics job. In fact, I doubt it will get you a job at all if implementation of transcendental functions is your primary skill.
I have a couple published papers on machine learning. Nothing incredible, but one is now well into the hundreds of citations. A good, respectable paper. I have more respect for the guys writing math libraries at Intel, Apple and HP than I have for all but a handful of people in the field of machine learning, and they cer
You don't huh?
Then I don't think you're in any position to call them fools. And, you're right, that requires little mathematical knowledge and even less mathematical understanding. I was at a conference a few months ago for Beresford Parlett's birthday (since you're such an authority on mathematical computation, you surely know who he is), and at the end of his plenary talk, he took a few minutes to bemoan the fact that in a room filled with PhDs in Applied Mathematics and Computer Science, there were probably no more than one or two who could quickly and correctly implement the double-precision log function with good accuracy and performance (in the words of one professor who is a numerical analyst, "I wouldn't even know where to begin"). So, yes, I'd say it requires a little mathematical knowledge and understanding. Certainly more than the elementary statistical analysis necessary to sell Advertisements.
As opposed to writing transcendental function libraries or encryption routines for the OS, which requires no mathematical knowledge at all...
OS engineers do not write "cool apps". We write the kernel and libraries that enable other people to write "cool apps".
All the "features" that you're talking about aren't part of an operating system, and thus have no place in a discussion of how easy or hard it would be for Apple to add significant features to a future OS. They are applications. It's possible that an apps team at Apple might write them and include them for free with the OS, but they aren't part of the OS in any meaningful way.
When an OS vendor says that they're focusing on stability and performance, they mean that the engineers who work on the system libraries and kernel aren't going to spend their time making it do fundamentally new things, they're going to focus instead on making it do the thing it already does faster and more correctly (which may require a complete rewrite of huge sections of code).
This has essentially nothing to do with the sort of "features" that you're talking about. Trivial little toy applications are neither here nor there.
I'd be interested to read your references for the "historical fact that Mohammad dictated the Koran while in what modern people would call a seizer."
Not a lot of historical documents from that time period have survived, so I'm curious about your hidden stash of medical records. I'm also curious about your apparent collection of criminal (or are they professional?) records establishing the prophet as a baby-raper.
The God you worship may not like baby-rapers, but does he know how to spell "seizure"? I don't really care about the answer; I just want to use this opportunity to be a condescending punk and point out that you're not only delusional, but also can't spell properly.
You may also want to review the rules of English capitalization.
I've been at a talk where the lecturer mentioned that we would, of course, recognize 10.99 as being "approximately seven-halves pi".
I don't know what you've done to your terminal preferences, but on mine there's a little button at the bottom of the "Settings" pane that says "Default". If I click that, then new windows will open with the selected style. This has been in place since 10.5.0, at least.
In that case you're not using a laptop anyway, you're using a calibrated external monitor with a hood.