I don't think Apple breaks down revenue by product type, but they sold 3.47M macs, 8.4M iPhones, 9.41M iPods during the quarter. My guess is that the macs are their highest margin products, but even if margins were the same across the board the price point of a mac is much higher than the other products. Because of this, it is likely that macs are generating at least a third of Apple's hardware revenue and profits. They aren't about to walk away from a business that is generating billions of dollars per year in profit.
Back when I wrote a book, three different publishers sent me contracts and the one from Apress was the most author-friendly by far. The royalty rates were higher, and the terms limiting the exclusive rights were written with authors in mind. All in all I found it to be an equitable arrangement - they were taking a risk by fronting the production costs and wanted a chance at profit. I was compensated more than fairly for the work I did.
The accounting never confused me. The percentage is paid on revenue (not profit), so there isn't any "hollywood accounting". There are several different kinds of sales, each with their own price, but it all adds up.
The "reserve" is really very simple. Distributors order more books than they might need from the publisher. These count as sales. But the publisher also will allow excess inventory to be returned. If the publisher paid out all royalties in full, then at the tail end of a book's life when returns exceeded sales, they would have to ask for money back from the author. It is also difficult to gauge the ups and downs of sales/returns (lots of sales in Q4 followed by returns in Q1). The reserve is a buffer against that. A sort of minimum balance that the publisher owes you but is escrowed against possible returns. Honestly, I never found it to be a problem.
Yes, code reviews are nominally about finding problems with the code, but they can also be used to...
* Share knowledge. You can learn a lot of new things by looking at someone else's code. Perhaps they use a library class you aren't familiar with, or have used a language feature in an elegant way. Just as an artist will look at other artist's work as part of their growth, programmers shouldn't be working in complete isolation. And even if you are the amazing guru that knows everything, then at least your teammates will be able to benefit from your vast knowledge.
* Ensure that every line of code has been seen by at least two people. Code that has only been worked on and looked at by a single person is a liability. If they leave the company (or project or whatever) you suddenly have this huge morass of code that nobody is familiar with, and you probably only start to realize this when there's a nasty bug that needs to be quickly fixed in that code.
* Tests can help with correctness, but do not necessarily make the code maintainable. Even if your code is correct, if a question comes up in code review, then that's an indication that you need to write clearer code and/or better comments if you expect anyone else to be able to work on the code in your absence.
That being said, a bad code review is probably not worth it. Keep the amount of code being reviewed at a single time relatively small. Don't involve too many people - just one other person looking at the code will provide a lot of value at minimal cost. If you start inviting managers and "process czars", then you're on the wrong track. Review code promptly: one-on-one reviewer led discussion works well (they read your code and ask you questions as they go). Code review tools can help, especially if the programmers are in different time zones. Everyone needs to make reviews a priority - aim for 24 hour max turn-around on a review otherwise you'll find everyone always being blocked. I think letting the author pick the reviewer(s) is important. That way if someone is a complete jerk about code reviews, nobody will ever include them in the reviews and you have minimized the damage that person can cause.
VHDL and Verilog each have their strengths, which is why neither has been able to supplant the other. Perhaps in the long run System Verilog will change this (bringing much of the power of VHDL to the Verilog world), but that day hasn't arrived yet.
Verilog code tends to be very concise, with the language making some implicit conversions and assumptions that turn out to be correct most of the time.
VHDL is bigger, bulkier and more rigid. The rigidity can be annoying, but it also is good at catching errors. The language has features that allow for very elaborate testbench construction, and some powerful means for abstraction (the generate statement, multiple architectures for an entity, etc). But this power comes at a cost. The spec for the language is several times larger than for VHDL. At one point I had a Verilog quick reference that fit nicely on a single page. My equivalent quick reference for VHDL covered four pages.
I've gone through the "choose an HDL" process twice, and both times selected VHDL. But that was within the context of at least half the team already being fluent in VHDL, and working on a large enough (and long lived enough) codebase that we could take advantage of some of VHDL's power. I wish VHDL wasn't so cumbersome and verbose, but it was still a win overall.
You are in a very different situation. I'm assuming you have minimal experience with either language, and it will be new to your students as well. You're going to have plenty of other things to be worrying about (digital design, synthesis, debugging, etc). I think Verilog is a better choice for your situation. It's going to do everything you need, and not really get in your way.
Also, don't worry about which tool is more popular in industry. Tools change many times over a career. University classes should be about providing good theory and foundation, so pick whatever tool enables you teach those concepts most effectively.
According to http://www.taxfoundation.org/taxdata/show/23408.html, the rich do pay a higher percent income tax. This only covers income tax paid vs. AGI, so there can be arguments about other taxes being regressive or sources of income that aren't taxable (or aren't reported). But from the standpoint of income tax this is a reasonable metric. For 2006, the top 1% paid an average of 22.79% of their AGI in tax. The people in the top 5%-2% averaged 17.48%. The top 10%-6% paid 12.60%. One could argue that the rich should pay even more, but claiming that they pay a lower effective rate of income tax than everyone else is just not supported by the facts.
Git and Hg branches are actually quite different. In Git, a branch is just a pointer into the DAG of changesets. If you are "on" a branch and commit, the pointer is moved to the new changeset. But you can manipulate that pointer arbitrarily and point it at any changeset. These pointers are local to a single repository, although I think you can map them so that branch X in repo A corresponds to branch Y in repo B, etc.
In Mercurial, every changeset is marked as belonging to a single branch (the default is a branch named "default"). This marking happens at commit time and cannot be changed afterwards (short of creating a new commit). Typically a changeset inherits the branch name of it first parent, but you can always mark it differently before the commit. So instead of a branch being a pointer to a single changeset, it actually identifies some subset of the DAG, and when you refer to a branch you are asking Hg to figure out the tip of the DAG subset marked with that branchname. Note that since the branch name is recorded internal to the changeset, it remains the same for all clones of the repository.
Personally, I think the git mechanism is more flexible, but the hg mechanism suffices just fine for basic use cases, and leads to fewer surprises among new users.
Assuming an Obama win on Tuesday and a serious shift towards Democrats (what polls largely suggest), are we finally going to see some serious investigations and accountability for this current administration?
Probably not. Obama has been running on a message of unity, and pursuing injustices committed by the current administration would just polarize the country further. Yes, it would be nice to see some justice, but at this point the big question is what to do going forward. There are lots of big problems to deal with, and digging up old dirt is unlikely to fix anything.
It depends on the nature of the programming. Some tasks are tedious, others are challenging. If you have a good job and grow your skills, you should be able to spend plenty of time on interesting projects.
Nothing is perfect, though. Some periods of work have been boring and tedious. Typically, the less challenge I get at work, the more motivated I am at home to spend time on an independent programming project. Then once work turns around and is interesting again, I spend less time on my own projects - not because I stop enjoying programming, but because I manage to get that enjoyment at work and can use my home time to enjoy other things.
Re:I will help YOU get a JOB! (Programming puzzles
on
Programming Puzzles
·
· Score: 2, Informative
ooops - should've previewed. The code didn't paste well into HTML. Here's another try:
#include <stdio.h>
int main() { if (printf("Hello, world\n")) { } }
Re:I will help YOU get a JOB! (Programming puzzles
on
Programming Puzzles
·
· Score: 1
Trigraphs were my first thought on how to solve #1 too, but then I looked them up and it turns out that semicolon is part of the ISO 646 standard 7-bit character set, so there isn't a trigraph for it.
I think the intended solution is to exploit the fact that code blocks after an if or while statement do not need a terminating semicolon:
#include
int main()
{
if (printf("Hello, world\n")) {
}
}
The error comes from the fact that the calculations are being done in floating point, and that some of the quantities involved cannot be represented exactly as a base 2 floating point number.
We run into the same problem using decimal notation in base 10. For example, 1/3 is 0.333... (repeating forever). If you only use a finite number of digits, then whatever number you write down in decimal notation will be a little bit smaller than 1/3. Now multiply that number by 3 and subtract 1:
3 * 1/3 - 1 = 0
But if we use a finite number of decimal digits (say 4) then we get 3 * 0.3333 - 1 = -0.0001.
What throws most people is that although they are used to 1/3 being a repeating decimal, they think 0.1 should be an exact number in floating point. However, computers generally use base 2 instead of base 10, and 1/10 happens to be a repeating fraction in base 2, so all of those decimal numbers become inexact in floating point calculations.
Most of the time this inaccuracy is hidden by performing the calculation with extra digits and rounding the results. Often the errors are rounded away before displaying the result, but they are still lurking in the floating point values. Take your example: 3.083-3.014. In most programs, (Calculator apps, Excel, etc) the result is probably displayed as 0.069. However, if you calculate 3.083-3.014-0.069 you will not get 0. You will see the rounding error.
The bottom line is that floating point calculations are inherently inexact. Most programs (in most situations) do a good job hiding this, but the error is always there.
Re:"Orthogonal Frequency Division Multiplexing"
on
Is 3G Irrelevant?
·
· Score: 1
Conceptually, OFDM isn't too complicated...
If you have 100Mb/s that you want to move wirelessly, one way to do it is to figure out how to modulate 100Mb/s into a single (albeit very wide) channel.
OFDM takes a different approach. You split the big stream of data into many little streams. Let's say you break the 100Mb/s into 500 streams of 200Kb/s each. Each of these streams is then modulated into its own channel. By transmitting/receiving all of these channels simultaneously you can reconstruct the original 100Mb/s stream.
On the surface it may not seem like you have gained much, because now you have to deal with 500 smaller channels (called sub-carriers) instead of just 1 big one, but there are techniques that can make the 500 small channels more effective than a single large one. You also don't have to give all 100Mb/s to the same client...maybe one client gets 200 of the sub-carriers, another uses 10, etc. The allocation can be completely dynamic.
As an analogy, consider taking 20 dial-up lines and spreading IP traffic across all 20 of them to create a broadband connection.
I think Apple was definitely ahead of the curve with Newton. It was a groundbreaking product in many ways, and I feel it was also a fantastic piece of engineering. But from a mass market perspective it just couldn't hold on once Palm introduced the Pilot.
When it was first developed, the Newton's computational power was about on par with typical desktop systems. This translated into higher cost, larger size, and heavier power requirements.
Palm's insight was to simplify what a PDA needed to do. All of the Palm apps were simpler than their Newton counterparts. Even the low level graphics routines were simpler. By relying on hot-sync, Palm offloaded some requirements (i.e. printing) to a desktop computer. Grafitti required considerably less CPU cycles than Newton's handwriting recognition. etc.
By building a simpler system, Palm was able to make their PDA smaller, cheaper, and run for a long time on 2 AAA batteries. IMHO, this was the magic forumla that led to PDAs crossing from early adopters to mainstream.
But I'm skeptical that Palm would have been able to focus their efforts correctly if Newton hadn't already been in the market. It is incredibly difficult to predict what is important and what isn't when creating a new market.
In short, both products deserve a lot of credit for creating the PDA market that we have today.
Slashdot Mirror
You might want to look at Apple's Q3 results: http://www.apple.com/pr/library/2010/07/20results.html
I don't think Apple breaks down revenue by product type, but they sold 3.47M macs, 8.4M iPhones, 9.41M iPods during the quarter. My guess is that the macs are their highest margin products, but even if margins were the same across the board the price point of a mac is much higher than the other products. Because of this, it is likely that macs are generating at least a third of Apple's hardware revenue and profits. They aren't about to walk away from a business that is generating billions of dollars per year in profit.
Back when I wrote a book, three different publishers sent me contracts and the one from Apress was the most author-friendly by far. The royalty rates were higher, and the terms limiting the exclusive rights were written with authors in mind. All in all I found it to be an equitable arrangement - they were taking a risk by fronting the production costs and wanted a chance at profit. I was compensated more than fairly for the work I did.
The accounting never confused me. The percentage is paid on revenue (not profit), so there isn't any "hollywood accounting". There are several different kinds of sales, each with their own price, but it all adds up.
The "reserve" is really very simple. Distributors order more books than they might need from the publisher. These count as sales. But the publisher also will allow excess inventory to be returned. If the publisher paid out all royalties in full, then at the tail end of a book's life when returns exceeded sales, they would have to ask for money back from the author. It is also difficult to gauge the ups and downs of sales/returns (lots of sales in Q4 followed by returns in Q1). The reserve is a buffer against that. A sort of minimum balance that the publisher owes you but is escrowed against possible returns. Honestly, I never found it to be a problem.
Yes, code reviews are nominally about finding problems with the code, but they can also be used to...
* Share knowledge. You can learn a lot of new things by looking at someone else's code. Perhaps they use a library class you aren't familiar with, or have used a language feature in an elegant way. Just as an artist will look at other artist's work as part of their growth, programmers shouldn't be working in complete isolation. And even if you are the amazing guru that knows everything, then at least your teammates will be able to benefit from your vast knowledge.
* Ensure that every line of code has been seen by at least two people. Code that has only been worked on and looked at by a single person is a liability. If they leave the company (or project or whatever) you suddenly have this huge morass of code that nobody is familiar with, and you probably only start to realize this when there's a nasty bug that needs to be quickly fixed in that code.
* Tests can help with correctness, but do not necessarily make the code maintainable. Even if your code is correct, if a question comes up in code review, then that's an indication that you need to write clearer code and/or better comments if you expect anyone else to be able to work on the code in your absence.
That being said, a bad code review is probably not worth it. Keep the amount of code being reviewed at a single time relatively small. Don't involve too many people - just one other person looking at the code will provide a lot of value at minimal cost. If you start inviting managers and "process czars", then you're on the wrong track. Review code promptly: one-on-one reviewer led discussion works well (they read your code and ask you questions as they go). Code review tools can help, especially if the programmers are in different time zones. Everyone needs to make reviews a priority - aim for 24 hour max turn-around on a review otherwise you'll find everyone always being blocked. I think letting the author pick the reviewer(s) is important. That way if someone is a complete jerk about code reviews, nobody will ever include them in the reviews and you have minimized the damage that person can cause.
VHDL and Verilog each have their strengths, which is why neither has been able to supplant the other. Perhaps in the long run System Verilog will change this (bringing much of the power of VHDL to the Verilog world), but that day hasn't arrived yet.
Verilog code tends to be very concise, with the language making some implicit conversions and assumptions that turn out to be correct most of the time.
VHDL is bigger, bulkier and more rigid. The rigidity can be annoying, but it also is good at catching errors. The language has features that allow for very elaborate testbench construction, and some powerful means for abstraction (the generate statement, multiple architectures for an entity, etc). But this power comes at a cost. The spec for the language is several times larger than for VHDL. At one point I had a Verilog quick reference that fit nicely on a single page. My equivalent quick reference for VHDL covered four pages.
I've gone through the "choose an HDL" process twice, and both times selected VHDL. But that was within the context of at least half the team already being fluent in VHDL, and working on a large enough (and long lived enough) codebase that we could take advantage of some of VHDL's power. I wish VHDL wasn't so cumbersome and verbose, but it was still a win overall.
You are in a very different situation. I'm assuming you have minimal experience with either language, and it will be new to your students as well. You're going to have plenty of other things to be worrying about (digital design, synthesis, debugging, etc). I think Verilog is a better choice for your situation. It's going to do everything you need, and not really get in your way.
Also, don't worry about which tool is more popular in industry. Tools change many times over a career. University classes should be about providing good theory and foundation, so pick whatever tool enables you teach those concepts most effectively.
According to http://www.taxfoundation.org/taxdata/show/23408.html, the rich do pay a higher percent income tax. This only covers income tax paid vs. AGI, so there can be arguments about other taxes being regressive or sources of income that aren't taxable (or aren't reported). But from the standpoint of income tax this is a reasonable metric. For 2006, the top 1% paid an average of 22.79% of their AGI in tax. The people in the top 5%-2% averaged 17.48%. The top 10%-6% paid 12.60%. One could argue that the rich should pay even more, but claiming that they pay a lower effective rate of income tax than everyone else is just not supported by the facts.
In Mercurial, every changeset is marked as belonging to a single branch (the default is a branch named "default"). This marking happens at commit time and cannot be changed afterwards (short of creating a new commit). Typically a changeset inherits the branch name of it first parent, but you can always mark it differently before the commit. So instead of a branch being a pointer to a single changeset, it actually identifies some subset of the DAG, and when you refer to a branch you are asking Hg to figure out the tip of the DAG subset marked with that branchname. Note that since the branch name is recorded internal to the changeset, it remains the same for all clones of the repository.
Personally, I think the git mechanism is more flexible, but the hg mechanism suffices just fine for basic use cases, and leads to fewer surprises among new users.
Assuming an Obama win on Tuesday and a serious shift towards Democrats (what polls largely suggest), are we finally going to see some serious investigations and accountability for this current administration?
Probably not. Obama has been running on a message of unity, and pursuing injustices committed by the current administration would just polarize the country further. Yes, it would be nice to see some justice, but at this point the big question is what to do going forward. There are lots of big problems to deal with, and digging up old dirt is unlikely to fix anything.
Nothing is perfect, though. Some periods of work have been boring and tedious. Typically, the less challenge I get at work, the more motivated I am at home to spend time on an independent programming project. Then once work turns around and is interesting again, I spend less time on my own projects - not because I stop enjoying programming, but because I manage to get that enjoyment at work and can use my home time to enjoy other things.
ooops - should've previewed. The code didn't paste well into HTML. Here's another try:
#include <stdio.h>
int main()
{
if (printf("Hello, world\n")) { }
}
Trigraphs were my first thought on how to solve #1 too, but then I looked them up and it turns out that semicolon is part of the ISO 646 standard 7-bit character set, so there isn't a trigraph for it. I think the intended solution is to exploit the fact that code blocks after an if or while statement do not need a terminating semicolon: #include int main() { if (printf("Hello, world\n")) { } }
The error comes from the fact that the calculations are being done in floating point, and that some of the quantities involved cannot be represented exactly as a base 2 floating point number.
We run into the same problem using decimal notation in base 10. For example, 1/3 is 0.333... (repeating forever). If you only use a finite number of digits, then whatever number you write down in decimal notation will be a little bit smaller than 1/3. Now multiply that number by 3 and subtract 1:
3 * 1/3 - 1 = 0
But if we use a finite number of decimal digits (say 4) then we get 3 * 0.3333 - 1 = -0.0001.
What throws most people is that although they are used to 1/3 being a repeating decimal, they think 0.1 should be an exact number in floating point. However, computers generally use base 2 instead of base 10, and 1/10 happens to be a repeating fraction in base 2, so all of those decimal numbers become inexact in floating point calculations.
Most of the time this inaccuracy is hidden by performing the calculation with extra digits and rounding the results. Often the errors are rounded away before displaying the result, but they are still lurking in the floating point values. Take your example: 3.083-3.014. In most programs, (Calculator apps, Excel, etc) the result is probably displayed as 0.069. However, if you calculate 3.083-3.014-0.069 you will not get 0. You will see the rounding error.
The bottom line is that floating point calculations are inherently inexact. Most programs (in most situations) do a good job hiding this, but the error is always there.
Conceptually, OFDM isn't too complicated... If you have 100Mb/s that you want to move wirelessly, one way to do it is to figure out how to modulate 100Mb/s into a single (albeit very wide) channel. OFDM takes a different approach. You split the big stream of data into many little streams. Let's say you break the 100Mb/s into 500 streams of 200Kb/s each. Each of these streams is then modulated into its own channel. By transmitting/receiving all of these channels simultaneously you can reconstruct the original 100Mb/s stream. On the surface it may not seem like you have gained much, because now you have to deal with 500 smaller channels (called sub-carriers) instead of just 1 big one, but there are techniques that can make the 500 small channels more effective than a single large one. You also don't have to give all 100Mb/s to the same client...maybe one client gets 200 of the sub-carriers, another uses 10, etc. The allocation can be completely dynamic. As an analogy, consider taking 20 dial-up lines and spreading IP traffic across all 20 of them to create a broadband connection.
I think Apple was definitely ahead of the curve with Newton. It was a groundbreaking product in many ways, and I feel it was also a fantastic piece of engineering. But from a mass market perspective it just couldn't hold on once Palm introduced the Pilot.
When it was first developed, the Newton's computational power was about on par with typical desktop systems. This translated into higher cost, larger size, and heavier power requirements.
Palm's insight was to simplify what a PDA needed to do. All of the Palm apps were simpler than their Newton counterparts. Even the low level graphics routines were simpler. By relying on hot-sync, Palm offloaded some requirements (i.e. printing) to a desktop computer. Grafitti required considerably less CPU cycles than Newton's handwriting recognition. etc.
By building a simpler system, Palm was able to make their PDA smaller, cheaper, and run for a long time on 2 AAA batteries. IMHO, this was the magic forumla that led to PDAs crossing from early adopters to mainstream.
But I'm skeptical that Palm would have been able to focus their efforts correctly if Newton hadn't already been in the market. It is incredibly difficult to predict what is important and what isn't when creating a new market.
In short, both products deserve a lot of credit for creating the PDA market that we have today.