... which works great until you have a hardware failure. Or until you have to add yet more servers to cope with even heavier use and you then have to redistribute the m users that were distributed over n server over the now (n+p) servers.
A distributed approach may well be a good idea, but once you start to distribute, you have to consider what should happen if one of the machines falls down.
I've found that my left hand was being overused and I was getting RSI-type pain. I've remapped things on my PC (Linux) keyboard so that the right Shift key and Cap Lock keys are Ctrl keys (as well as the traditional Ctrl key). That way I can avoid forming a 'granny' hand with my left hand to do key combinations (e.g. I can hit Ctrl with my right hand and press C with my left, balancing things out). I'm probably going to do the same with my Mac.
The other thing that I've done, which I like very much, is to move the (parentheses) from above 9 and 0 and put them in the position of the [brackets] (i.e. unshifted). When you think how common these are in English text and many programming languages, it makes sense not to have to Shift to get at them. ({Curly brackets} go on 9 and 0, which is suboptimal if you do C/C++, Java or LaTeX.)
My reading of the piece led me to believe the writer was arguing that it was the physical position of the Command keys that should change, not their semantics. On a regular PC keyboard, the left Control key (semantically equivalent to the Command key on a Mac) is at the bottom left hand corner of the keyboard. On a Mac keyboard, the Command keys are next to the space bar; on a PC keyboard this position is occupied by the Alt keys.
The point about muscle memory is valid, though. However, I use both types of keyboard regularly and don't experience muscle memory problems (albeit one is a laptop and the other a full size desktop keyboard).
I presume your seat belt analogy refers to type safety, which is a bit of a joke for C and C++ as you can explicitly cast one type to another (i.e. there is no run-time type safety). The small amount of Python coding that I have done suggests that its type system is similar to Matlab's (I'm sure there are differences).
I have tried SciPy. I could not get it to install (SuSE 9 on x86). I can't remember the specific problem, but I spent about an hour messing around with it. If one can't guarantee that the environment will even install, then writing code for that environment is equally wasteful as writing code for a proprietary system. The benefit of using the proprietary system is that paying the money gives you certain guarantees (i.e. the software will at least install). Yes I could have spent days in email conversations with SciPy users, but I had a problem to solve, a limited time to solve it, and getting semi-helpful replies from the community (along with the typical "I can do it, you must be a lamer newbie" replies) over a period of days isn't my idea of being productive.
I remember that SciPy has support from a company, who could have helped if I'd have paid them. I can't remember the company's name (and somewhat ironically, the SciPy website is down at this exact moment, so I can't look them up).
It's a shame that the typical response from the open source advocates when you complain that you had installation problems is to assume that you are at fault. I understand configure; make; make install and I understand dependencies. What commercial vendors understand is that their software must install easily.
As for your assertion that computer vision can only be realistically done in C++, this is absurd. As my username suggests, I do computer vision research and my dept. uses Matlab, C++ and C. Most new members are encouraged to use Matlab as it has proven to be more productive. The C++ development experience is nowhere near as interactive as Matlab. I've never seen a C++ user try to run their code, then error, have it break out into a debugging session, want to visualise some data, write the code to do it and then call it with the data from the breakpoint, then correct the problem and continue running the code. Maybe this is possible now, but I'd be very surprised (you can do something similar using Apple's XCode tool, but it's not as powerful as Matlab).
I think we'll have to agree to differ on this one.
I'm finding your objections and their justifications rather orthogonal. For example you say that "Matlab isn't a better numerical programming language because its string processing is poor", which is a bit like saying that "your car isn't faster because it's green". I could understand if you thought Matlab was poor at numerics because it uses methox X and method Y has been proven to be superior.
Well, you are lucky that your numerical problems are simple enough that you can get by with that kind of separation.
No, I'm doing research where I can make certain assumptions (e.g. I already have my data in a certain format and I don't have to worry about the whole pipeline). That's not to say those problems don't exist, but that they are trivial compared to the research I'm doing. Solving these other problems wouldn't help me publish on my topic any quicker. My numerical problems are hard, but I don't care about things like string processing and networking---these aren't numerical problems.
I also disagree with your assertion that
Matlab is only good because of its toolboxes. I know that some people just string calls to toolboxe functions together, but that isn't how most people I know use it. What they tend to do is to use toolbox functionality for problems they are not actively interested in and write custom code for the things that they are. This allows one to spend more time focussed on the research task at hand and little time doing grunt work.
If I were asked why I use Matlab, I would say because it abstracts the numerical problems to a level that is close enough to the mathematical concepts that one works with, but not so much that you can't tune the algorithms. It provides this abstraction in an environment that allows very rapid development and effective debugging and profiling. It also allows one to interact and experiment with data at the command line, which I find to be an effective way to develop software. It is also trivial to write cross-platform software, so members of a team can use the platform they are most comfortable with. All this combines to let me get results quickly. I'd love to be able to use open source/free software, but the reality is that in the field I work, it would take me much longer to get my work done.
If you can suggest some alternatives, I would be very interested to look into them.
Your reply makes me think that you want Matlab to do something that it is not designed to do. Numerical algorithms have absolutely nothing to do with string processing, I/O or networking. Numerical algorithms relate to numbers.
Now, it is certainly the case that data mining, text mining and bioinformatics will use numerical algorithms, but the database, string processing, I/O and networking tasks you mention are simply tasks that need to occur before or after you run numerical algorithms. A final product may well need to integrate all these tasks into one application.
Matlab's role in this is to allow researchers to experiment and develop the numerical algorithms. Once developed, these algorithms could be recoded in C or, more likely, simply compiled into a library using the Matlab compiler. These can then be linked into the final application.
In your field, it may be the case that doing all these extraneous tasks is the bread and butter of your work and that the numerical algorithms are reasonably simple and/or provided by third party libraries. That being the case, I can see no reason to use Matlab.
In my field, developing the numerical algorithms is the bread and butter of my work. Any I/O etc. can be done in an ad hoc way (because it is a solved problem and is therefore an uninteresting research topic). So for me, Matlab is an excellent choice because it lets me develop those numerical algorithms far quicker than almost any other environment I can think of.
The price of Matlab is inconsequential compared to the cost of a regular (technical) employee's wages and equipment that my dept. uses (e.g. MRI scanners, which cost millions).
As my job depends on getting results as fast as possible, I am always looking for ways of achieving that. So far, I have not found any environment that lets me deliver results as fast as I can in Matlab.
Matlab is actually an excellent programming language. I am currently using Java after using Matlab for a few years, and it is just so frustratingly verbose and inflexible. I could have achieved in Matlab in a few weeks what has taken me a few months in Java. The reason you should hire someone who likes Matlab is that they are used to getting things done and will want a programming environment that lets them get things done. Java, on the other hand, looks a lot like work, and feels a lot like work, and is a lot like work; but it's not very productive work.
One of the reasons that Matlab is so productive is because there are so many toolboxes for it. I could use Python and feel all warm and fuzzy, but I'd have to reinvent the wheel so much.
But I think the message really should be to use the right tool for the job: Matlab is excellent for prototyping numerical algorithms, and when you need to do that properly you (or your client) will be prepared to pay for the right software. When you need to do networking, then Python might be a better choice. But don't knock Matlab for being bad at regular expressions or databases; that's not what it's supposed to do.
I don't agree with you. You have to think about what you were being taught and why a particular tool was used for teaching. It is quite possible that whoever was running your course was a crusty old academic who had no idea about the real world, and still thought that Pascal was a must-have on your CV.
However, if you went to a half-decent college, it's more likely that they were trying to teach you the fundamental ideas of your field. Perhaps Pascal had a particular quality that meant that it was useful for the teaching of ideas, or perhaps the development environment meant that students were able to get going quickly and start tackling interesting problems?
Many CS departments now just teach Java over and above the ideas behind the discipline. That's fine, especially for the department (who can say "95% of our graduates went into employment in CS jobs within 6 months of graduating"), but when Java is supplanted by the next big thing, those who just learned Java (rather than the theory behind their subject) may have trouble adapting.
I'm not trashing Java, I'm trashing the sausage factory mindset.
About 99% of what I learned at undergraduate level was not cutting edge (and wasn't even close). However, I was taught ideas, and that has equipped me to work in both industry (for global companies) and more recently in academia on my PhD research. It's at graduate level and beyond that students work at the cutting edge. It's also true that industry develops some cool stuff, but the emphasis in industry is on cutting-edge research that will yield a profit in a couple of years. Academia has an eye on the long term. Sometimes the two converge (Google wouldn't have been possible without cutting edge academic research, but wouldn't be as well supported today if it had stayed a research project).
The main advantage of dual core over dual processor (where the processors are not in the same CPU package) is that it should be possible to allow the two CPUs to communicate at very high speed.
Inside a single CPU, data is moved around at, or very close to, the clock speed of the CPU (e.g. 2.7GHz). Outside of the chip, the longer distances signals need to travel mean that it is more difficult to run data busses at high speeds. So talking to a hard disk or other peripheral component is slower (e.g. 166Mhz).
If you had two separate CPUs (i.e. not in the same package), then they would be limited to the 166MHz buz (or whatever). However, if you have two CPUs in the same package (and ideally on the same piece of silicon), they can communicate at or close to the clock speed of the 'package' (i.e. 2.7GHz). The CPUs can then work co-operatively more efficiently.
The main drawback to putting one or more CPUs on a single piece of silicon is the cost of doing so. CPUs are etched onto silicon wafers. These CPUs are then physically cut out (e.g. with a diamond circular saw) and then packaged. If the wafer has a local imperfection, any chip that intersects with that imperfection is likely to be faulty, so you have to throw it away. If the cutting process damages a chip, it must be discarded. The smaller the CPUs, the less likely a particular one will be damaged. The larger they are, the higher the probability. As the chips get bigger (e.g. if you bolt two CPUs together into a single chip), the yield goes down, and the cost of an individual chip increases.
One of the main differences between the Apple UI and the Windows UI (and an area in which the Apple UI is vastly superior, IMHO) is the policy taken on screen real estate. The Windows model is clearly incorrect, and the approach has been copied in many free UIs (e.g. GNOME, KDE).
Imagine you have just bought a brand new LCD monitor. It was expensive, and you don't want to have paid for under-utilised pixels:
You use Windows, and open a typical Windows app. Your desktop now looks like this:
At the bottom of the screen is the taskbar, which takes up around 1/20th of the vertical height of the screen.
At the top of the screen you have the title bar for the app, another 1/20th.
Next down is the menu bar for the app, another 1/20th of the screen height.
Next down is the toolbar for the app, another 1/20th of the screen height.
We have now got 16/20ths (80%) of the screen height left to actually display app-specific content. Now let's see what a typical app displays.
The app uses a multiple document interface (MDI), so we have yet another title bar, losing another 1/20th of the screen height.
Below the title bar is a a ruler, or some other kind of widget bar. That's another 1/20th.
At the bottom of the MDI window, there is a status bar. Another 1/20th gone.
Now we actually get to see the document that the user wants to work on. It occupies just 65% of the screen's vertical real estate.
Horizontal real estate is generally not wasted as much, and there's more of it to begin with. Often there will be some kind of vertical shortcut bar to the left.
The problem is obvious. We've spent a few hundred on that new LCD monitor, and Windows has wasted almost half of it in the vertical direction.
The Apple solution is to use a single menu bar at the top of the screen that changes, depending on the currently-active application. Windows-style MDIs are not used, saving space. Status bars at the bottom of the screen are rarely used, saving more space. The Dock is too big by default, at around 2/20th - 3/20th of the screen's vertical height. I make it dissapear (just as one can do with the Window's taskbar).
Windows also has a system tray, that every 3rd party software vendor feels compelled to populate. So the horizontal screen real-estate in the task bar is wasted. XP 'solves' this by making rarely-used items vanish, but this is a bit of a strange solution: the 3rd party vendor is saying "here is something the user should know about" and the OS's UI is saying "this isn't important".
I would like to see future UIs make minimal demands on the screen real estate, leaving as much as possible to the user and their applications.
The single most important part of any SDK is a tutorial that is aimed
at absolute novices. You must assume that your users will have had
absolutely no prior experience with your SDK, with any similar SDK, or
perhaps any programming language. The "Your
First Cup of Java" tutorial is a pretty good example of what I
mean.
Your tutorial should be simple enough that the most stupid person
you can ever imagine using your SDK will find it
straightforward. Perhaps test it on a non-technical user like your
mother or some kind of office clerk.
You should try to minimise the length of time required to complete
the tutorial. Less than an hour is good. The tutorial should let the
user understand what your SDK does, how to start using it (including
installing it), and what sort of things they can do with it.
If a user cannot install your SDK, they will never use it.
If a user does not understand what they must do "first", they will not be able to use your SDK.
If a user cannot see why they would use your SDK (particularly over another, similar product), they will not use your SDK.
If a user cannot afford the time required to learn your SDK, they will not use it.
SDKs are boring. If you can make the user leave your tutorial with
a smile on their face and a good feeling about your SDK, then they will come back for more.
A good tutorial should leave the user feeling confident that they
can go out into this new world on their own and survive. This can
partially be achieved by concluding with a handful of good links that
the user can follow to get more information. For example, give a link
to a walkthrough of a simple---but non-trivial---application developed
using the SDK. Give a link to the automatically generated API
documentation. Give a link to a document that explains the
architecture and overall philosophy of the design of the SDK. Give a
link to some "do"s and "don't"s. Let the user know where they can turn
for help from an actual person.
In Bill Bryson's "Made in America" (IIRC) the author says that Edison actually built an electric chair that was used for executions which used AC power (as promoted by Westinghouse) to demonstrate how dangerous AC power can be. I'm not sure if a DC electric chair was built to illustrate similar problems with Edison's system. However, the problems associated with DC power distribution are why we use AC power distribution today.
Yes, but if you want to do semi-professional movie editing, then you might want a product aimed at the semi-professional market, rather than the home market. Of course, there is a continuum, it just depends upon your needs and depth of pocket. iMovie DV might suit the OP fine.
The recent MacWorld Keynote said that Final Cut Express HD will cope with the widescreen format, and I believe this is true for the new iMovie, too.
Advice: Buy a Mac with a version of Final Cut HD.
...nonvolatile memory becomes the solution to crash-prone software rather than better programming...
I don't see how non-volatile memory will cure crash-prone software. One of the main contributory factors to buggy code is memory leaks. Non-volatile memory would allow the invalid state of memory to be preserved between 'reboots', making defects in code more obvious. If non-volatile memory is adopted, then we'll need higher quality code than we have now.
So, *why* was this a good thing to do? The only reason to overclock would be to improve performance, but the article doesn't give any before and after performance measurements.
Given that so many factors contribute to computer performance (CPU architecture, number of caches, size of caches, bus speed, memory size, disk performance, CPU frequency), often in nontrivial ways, increasing the clock speed by such a small amount is unlikely to offer any significant increase in performance.
Try and find a form of exercise that you enjoy and which also has a sociable element.
I do Taekwondo twice a week. It's easy to keep going regularly because:
The classes are fun, so I look forward to going.
The people are very friendly, and TKD is usually very inclusive (ages, sexes etc.). This social aspect helps you keep going.
There are regular gradings (when you test for a new belt), usually every three months, so there is regular positive reinforcement.
Not only do you learn an effective form of self-defence, lose weight, gain strength, flexibility and self-confidence, but you will get regular opportunities to put your day-to-day worries to one side -- if you have a stressful job, this is very rewarding.
I'm not saying TKD if the way for you, but the above qualities make it a good way to get and stay fit, without dropping out.
From the OED: "Customize, trans. To make to order or to measure; to model or alter according to individual requirements".
Similarly: "Personalize, trans. To render personal; to represent as personal, personify; to embody in a person, impersonate; to make (some impersonal object or thing) more obviously related to, or identifiable as belonging to, a particular individual"
I would consider fancy cases, the airbrushed nude or engraving to be personalisation -- apart from aesthetically, the product is not changed. I would consider customisation to involve altering the specification of the machine for my own needs. No, I wouldn't consider choosing a 30GB iPod over a 40GB iPod to be a customisation, as they aren't building it to your specification, it's a stock model.
But if you ask for a dual 2GHz Apple G5 PowerMac with 8GB RAM, 2x250 HDs, a SuperDrive, Bluetooth, a Radion 9800 Pro, 2 Apple Studio displays, an AirPort Extreme card, no modem, a Fibre Channel card, preinstalled with Keynote and AppleCare, then this definitely meets the definition of "customised".
But this is all academic. The point is that Apple don't want to have to spend a lot of time building and testing systems that are not stock items, only for the person placing the order to say "Oops, I didn't want that after all. Take it back and give me a full refund." I don't blame them -- that's no way to run a business. It might be better for them to charge you for the shipping and a restocking fee (and refuse to take it back if the returned system is damaged or spoiled), but really, if you don't want the thing don't place the order!
How else would you customise a computer that you order online from a computer retailer -- ask them to airbrush a nude on the case? Come on, be realistic.
In my mind, selection from a list of pre-configured options does not constitute "custom".
That's not the mechanism. You customise the system by selecting options for things like "RAM", "Optical Disk", "Extended Warranty" etc. Yes, there are are finite number of possible configurations, but given a finite number of component types, that's true for all computers.
Sorry that you came off worse in this instance, but...
1. If you didn't want the machine, why did you order it?
2. Maybe I'm misunderstanding you, but their definition of a 'custom configured computer built to the customer's specifications' seems perfectly reasonable to me.
3. It seems reasonable for Apple not to want to take back a machine that was built to your specification -- hopefully they made you aware of this at the time of buying, but since you went to court, I guess this isn't so. I assume the machine worked -- I'd be dissapointed if they didn't accept a returned faulty machine.
If one was aiming for readability, one obviously wouldn't write the gibberish in your example:-)
We didn't hit 100%, because there was code that would only be run if hardware-centric exceptional cases were encountered. In such a case, exception code was executed, which we could test via a test harness, but the
if(exceptional_state) do_exception();
code did not get covered. I think we managed above 95%, which were we were pretty happy with. I don't recall the ratio of lines of code to lines of tests.
If you look at the code coverage report for the parent example, you'll see that a common cause of less than 100% code coverage is multiple return points in functions.
Multiple return points usually occur because the algorithm computes the return value 'early' (often via some special condition) or because an error condition is encountered and the return mechanism is used to propagate errors up the call hierarchy.
If you write your function to have only a single return point at the end of the function, you can increase the code coverage, while making the code easier to read. You then have to ensure your function's control structures send control to the end of the function (no gotos, you understand!). If you try to achieve this, your programs become more logically structured, easier to test and maintain.
On one project where we set ourselves a 100% coverage target, and followed the above coding standard (along with others), we produced some excellent code.
Of course, it's really hard to exercise some exceptional states, and 100% coverage doesn't mean you have bullet-proof code, but it's another metric to use to assess your code quality.
They worked out how much it costs to build a top-three supercomputer from commodity parts at very low cost, while simultaneously getting a massive amount of publicity.
Firstly, Iran is not a socialist country! It is commonly regarded as a theocracy. The CIA World Factbook (curiously named, but useful nonetheless), classifies it as a "theocratic republic"; it also points out the government's restrictive social policies.
Secondly, the Californian welfare system is much better than that in Iran. In the event of a catastrophic event (think something of the order of 9/11), capital would be released by the state or the federal government to help those in need. In Iran, this support had to be provided by aid from other countries.
Compare former third-world countries like Chile, Hong Kong, Taiwan, Singapore, and South Korea... against any nation you want to choose in Africa.
OK: the first set of countries received political, military and/or economic support from the west; the second set of countries have been ravaged by numerous civil wars fuelled by arms sales from the west, famine and HIV/AIDS (both of which received little support from the west).
Slashdot Mirror
... which works great until you have a hardware failure. Or until you have to add yet more servers to cope with even heavier use and you then have to redistribute the m users that were distributed over n server over the now (n+p) servers.
A distributed approach may well be a good idea, but once you start to distribute, you have to consider what should happen if one of the machines falls down.
I've found that my left hand was being overused and I was getting RSI-type pain. I've remapped things on my PC (Linux) keyboard so that the right Shift key and Cap Lock keys are Ctrl keys (as well as the traditional Ctrl key). That way I can avoid forming a 'granny' hand with my left hand to do key combinations (e.g. I can hit Ctrl with my right hand and press C with my left, balancing things out). I'm probably going to do the same with my Mac.
The other thing that I've done, which I like very much, is to move the (parentheses) from above 9 and 0 and put them in the position of the [brackets] (i.e. unshifted). When you think how common these are in English text and many programming languages, it makes sense not to have to Shift to get at them. ({Curly brackets} go on 9 and 0, which is suboptimal if you do C/C++, Java or LaTeX.)
My reading of the piece led me to believe the writer was arguing that it was the physical position of the Command keys that should change, not their semantics. On a regular PC keyboard, the left Control key (semantically equivalent to the Command key on a Mac) is at the bottom left hand corner of the keyboard. On a Mac keyboard, the Command keys are next to the space bar; on a PC keyboard this position is occupied by the Alt keys.
The point about muscle memory is valid, though. However, I use both types of keyboard regularly and don't experience muscle memory problems (albeit one is a laptop and the other a full size desktop keyboard).
I presume your seat belt analogy refers to type safety, which is a bit of a joke for C and C++ as you can explicitly cast one type to another (i.e. there is no run-time type safety). The small amount of Python coding that I have done suggests that its type system is similar to Matlab's (I'm sure there are differences).
I have tried SciPy. I could not get it to install (SuSE 9 on x86). I can't remember the specific problem, but I spent about an hour messing around with it. If one can't guarantee that the environment will even install, then writing code for that environment is equally wasteful as writing code for a proprietary system. The benefit of using the proprietary system is that paying the money gives you certain guarantees (i.e. the software will at least install). Yes I could have spent days in email conversations with SciPy users, but I had a problem to solve, a limited time to solve it, and getting semi-helpful replies from the community (along with the typical "I can do it, you must be a lamer newbie" replies) over a period of days isn't my idea of being productive.
I remember that SciPy has support from a company, who could have helped if I'd have paid them. I can't remember the company's name (and somewhat ironically, the SciPy website is down at this exact moment, so I can't look them up).
It's a shame that the typical response from the open source advocates when you complain that you had installation problems is to assume that you are at fault. I understand configure; make; make install and I understand dependencies. What commercial vendors understand is that their software must install easily.
As for your assertion that computer vision can only be realistically done in C++, this is absurd. As my username suggests, I do computer vision research and my dept. uses Matlab, C++ and C. Most new members are encouraged to use Matlab as it has proven to be more productive. The C++ development experience is nowhere near as interactive as Matlab. I've never seen a C++ user try to run their code, then error, have it break out into a debugging session, want to visualise some data, write the code to do it and then call it with the data from the breakpoint, then correct the problem and continue running the code. Maybe this is possible now, but I'd be very surprised (you can do something similar using Apple's XCode tool, but it's not as powerful as Matlab).
I think we'll have to agree to differ on this one.
I'm finding your objections and their justifications rather orthogonal. For example you say that "Matlab isn't a better numerical programming language because its string processing is poor", which is a bit like saying that "your car isn't faster because it's green". I could understand if you thought Matlab was poor at numerics because it uses methox X and method Y has been proven to be superior.
No, I'm doing research where I can make certain assumptions (e.g. I already have my data in a certain format and I don't have to worry about the whole pipeline). That's not to say those problems don't exist, but that they are trivial compared to the research I'm doing. Solving these other problems wouldn't help me publish on my topic any quicker. My numerical problems are hard, but I don't care about things like string processing and networking---these aren't numerical problems.
I also disagree with your assertion that Matlab is only good because of its toolboxes. I know that some people just string calls to toolboxe functions together, but that isn't how most people I know use it. What they tend to do is to use toolbox functionality for problems they are not actively interested in and write custom code for the things that they are. This allows one to spend more time focussed on the research task at hand and little time doing grunt work.
If I were asked why I use Matlab, I would say because it abstracts the numerical problems to a level that is close enough to the mathematical concepts that one works with, but not so much that you can't tune the algorithms. It provides this abstraction in an environment that allows very rapid development and effective debugging and profiling. It also allows one to interact and experiment with data at the command line, which I find to be an effective way to develop software. It is also trivial to write cross-platform software, so members of a team can use the platform they are most comfortable with. All this combines to let me get results quickly. I'd love to be able to use open source/free software, but the reality is that in the field I work, it would take me much longer to get my work done.
If you can suggest some alternatives, I would be very interested to look into them.
Your reply makes me think that you want Matlab to do something that it is not designed to do. Numerical algorithms have absolutely nothing to do with string processing, I/O or networking. Numerical algorithms relate to numbers.
Now, it is certainly the case that data mining, text mining and bioinformatics will use numerical algorithms, but the database, string processing, I/O and networking tasks you mention are simply tasks that need to occur before or after you run numerical algorithms. A final product may well need to integrate all these tasks into one application.
Matlab's role in this is to allow researchers to experiment and develop the numerical algorithms. Once developed, these algorithms could be recoded in C or, more likely, simply compiled into a library using the Matlab compiler. These can then be linked into the final application.
In your field, it may be the case that doing all these extraneous tasks is the bread and butter of your work and that the numerical algorithms are reasonably simple and/or provided by third party libraries. That being the case, I can see no reason to use Matlab.
In my field, developing the numerical algorithms is the bread and butter of my work. Any I/O etc. can be done in an ad hoc way (because it is a solved problem and is therefore an uninteresting research topic). So for me, Matlab is an excellent choice because it lets me develop those numerical algorithms far quicker than almost any other environment I can think of.
The price of Matlab is inconsequential compared to the cost of a regular (technical) employee's wages and equipment that my dept. uses (e.g. MRI scanners, which cost millions).
As my job depends on getting results as fast as possible, I am always looking for ways of achieving that. So far, I have not found any environment that lets me deliver results as fast as I can in Matlab.
Matlab is actually an excellent programming language. I am currently using Java after using Matlab for a few years, and it is just so frustratingly verbose and inflexible. I could have achieved in Matlab in a few weeks what has taken me a few months in Java. The reason you should hire someone who likes Matlab is that they are used to getting things done and will want a programming environment that lets them get things done. Java, on the other hand, looks a lot like work, and feels a lot like work, and is a lot like work; but it's not very productive work.
One of the reasons that Matlab is so productive is because there are so many toolboxes for it. I could use Python and feel all warm and fuzzy, but I'd have to reinvent the wheel so much.
But I think the message really should be to use the right tool for the job: Matlab is excellent for prototyping numerical algorithms, and when you need to do that properly you (or your client) will be prepared to pay for the right software. When you need to do networking, then Python might be a better choice. But don't knock Matlab for being bad at regular expressions or databases; that's not what it's supposed to do.
I don't agree with you. You have to think about what you were being taught and why a particular tool was used for teaching. It is quite possible that whoever was running your course was a crusty old academic who had no idea about the real world, and still thought that Pascal was a must-have on your CV.
However, if you went to a half-decent college, it's more likely that they were trying to teach you the fundamental ideas of your field. Perhaps Pascal had a particular quality that meant that it was useful for the teaching of ideas, or perhaps the development environment meant that students were able to get going quickly and start tackling interesting problems?
Many CS departments now just teach Java over and above the ideas behind the discipline. That's fine, especially for the department (who can say "95% of our graduates went into employment in CS jobs within 6 months of graduating"), but when Java is supplanted by the next big thing, those who just learned Java (rather than the theory behind their subject) may have trouble adapting.
I'm not trashing Java, I'm trashing the sausage factory mindset.
About 99% of what I learned at undergraduate level was not cutting edge (and wasn't even close). However, I was taught ideas, and that has equipped me to work in both industry (for global companies) and more recently in academia on my PhD research. It's at graduate level and beyond that students work at the cutting edge. It's also true that industry develops some cool stuff, but the emphasis in industry is on cutting-edge research that will yield a profit in a couple of years. Academia has an eye on the long term. Sometimes the two converge (Google wouldn't have been possible without cutting edge academic research, but wouldn't be as well supported today if it had stayed a research project).
Not sure if anyone answered this properly yet...
The main advantage of dual core over dual processor (where the processors are not in the same CPU package) is that it should be possible to allow the two CPUs to communicate at very high speed.
Inside a single CPU, data is moved around at, or very close to, the clock speed of the CPU (e.g. 2.7GHz). Outside of the chip, the longer distances signals need to travel mean that it is more difficult to run data busses at high speeds. So talking to a hard disk or other peripheral component is slower (e.g. 166Mhz).
If you had two separate CPUs (i.e. not in the same package), then they would be limited to the 166MHz buz (or whatever). However, if you have two CPUs in the same package (and ideally on the same piece of silicon), they can communicate at or close to the clock speed of the 'package' (i.e. 2.7GHz). The CPUs can then work co-operatively more efficiently.
The main drawback to putting one or more CPUs on a single piece of silicon is the cost of doing so. CPUs are etched onto silicon wafers. These CPUs are then physically cut out (e.g. with a diamond circular saw) and then packaged. If the wafer has a local imperfection, any chip that intersects with that imperfection is likely to be faulty, so you have to throw it away. If the cutting process damages a chip, it must be discarded. The smaller the CPUs, the less likely a particular one will be damaged. The larger they are, the higher the probability. As the chips get bigger (e.g. if you bolt two CPUs together into a single chip), the yield goes down, and the cost of an individual chip increases.
One of the main differences between the Apple UI and the Windows UI (and an area in which the Apple UI is vastly superior, IMHO) is the policy taken on screen real estate. The Windows model is clearly incorrect, and the approach has been copied in many free UIs (e.g. GNOME, KDE).
Imagine you have just bought a brand new LCD monitor. It was expensive, and you don't want to have paid for under-utilised pixels:
You use Windows, and open a typical Windows app. Your desktop now looks like this:
We have now got 16/20ths (80%) of the screen height left to actually display app-specific content. Now let's see what a typical app displays.
Now we actually get to see the document that the user wants to work on. It occupies just 65% of the screen's vertical real estate.
Horizontal real estate is generally not wasted as much, and there's more of it to begin with. Often there will be some kind of vertical shortcut bar to the left.
The problem is obvious. We've spent a few hundred on that new LCD monitor, and Windows has wasted almost half of it in the vertical direction.
The Apple solution is to use a single menu bar at the top of the screen that changes, depending on the currently-active application. Windows-style MDIs are not used, saving space. Status bars at the bottom of the screen are rarely used, saving more space. The Dock is too big by default, at around 2/20th - 3/20th of the screen's vertical height. I make it dissapear (just as one can do with the Window's taskbar).
Windows also has a system tray, that every 3rd party software vendor feels compelled to populate. So the horizontal screen real-estate in the task bar is wasted. XP 'solves' this by making rarely-used items vanish, but this is a bit of a strange solution: the 3rd party vendor is saying "here is something the user should know about" and the OS's UI is saying "this isn't important".
I would like to see future UIs make minimal demands on the screen real estate, leaving as much as possible to the user and their applications.
The single most important part of any SDK is a tutorial that is aimed at absolute novices. You must assume that your users will have had absolutely no prior experience with your SDK, with any similar SDK, or perhaps any programming language. The "Your First Cup of Java" tutorial is a pretty good example of what I mean.
Your tutorial should be simple enough that the most stupid person you can ever imagine using your SDK will find it straightforward. Perhaps test it on a non-technical user like your mother or some kind of office clerk.
You should try to minimise the length of time required to complete the tutorial. Less than an hour is good. The tutorial should let the user understand what your SDK does, how to start using it (including installing it), and what sort of things they can do with it.
SDKs are boring. If you can make the user leave your tutorial with a smile on their face and a good feeling about your SDK, then they will come back for more.
A good tutorial should leave the user feeling confident that they can go out into this new world on their own and survive. This can partially be achieved by concluding with a handful of good links that the user can follow to get more information. For example, give a link to a walkthrough of a simple---but non-trivial---application developed using the SDK. Give a link to the automatically generated API documentation. Give a link to a document that explains the architecture and overall philosophy of the design of the SDK. Give a link to some "do"s and "don't"s. Let the user know where they can turn for help from an actual person.
Yes, it is. Apparently companies other than Apple innovate. I'd heard the rumour, but didn't dare believe it.
In Bill Bryson's "Made in America" (IIRC) the author says that Edison actually built an electric chair that was used for executions which used AC power (as promoted by Westinghouse) to demonstrate how dangerous AC power can be. I'm not sure if a DC electric chair was built to illustrate similar problems with Edison's system. However, the problems associated with DC power distribution are why we use AC power distribution today.
Yes, but if you want to do semi-professional movie editing, then you might want a product aimed at the semi-professional market, rather than the home market. Of course, there is a continuum, it just depends upon your needs and depth of pocket. iMovie DV might suit the OP fine.
The recent MacWorld Keynote said that Final Cut Express HD will cope with the widescreen format, and I believe this is true for the new iMovie, too. Advice: Buy a Mac with a version of Final Cut HD.
I don't see how non-volatile memory will cure crash-prone software. One of the main contributory factors to buggy code is memory leaks. Non-volatile memory would allow the invalid state of memory to be preserved between 'reboots', making defects in code more obvious. If non-volatile memory is adopted, then we'll need higher quality code than we have now.
So, *why* was this a good thing to do? The only reason to overclock would be to improve performance, but the article doesn't give any before and after performance measurements.
Given that so many factors contribute to computer performance (CPU architecture, number of caches, size of caches, bus speed, memory size, disk performance, CPU frequency), often in nontrivial ways, increasing the clock speed by such a small amount is unlikely to offer any significant increase in performance.
Try and find a form of exercise that you enjoy and which also has a sociable element.
I do Taekwondo twice a week. It's easy to keep going regularly because:
I'm not saying TKD if the way for you, but the above qualities make it a good way to get and stay fit, without dropping out.
From the OED: "Customize, trans. To make to order or to measure; to model or alter according to individual requirements".
Similarly: "Personalize, trans. To render personal; to represent as personal, personify; to embody in a person, impersonate; to make (some impersonal object or thing) more obviously related to, or identifiable as belonging to, a particular individual"
I would consider fancy cases, the airbrushed nude or engraving to be personalisation -- apart from aesthetically, the product is not changed. I would consider customisation to involve altering the specification of the machine for my own needs. No, I wouldn't consider choosing a 30GB iPod over a 40GB iPod to be a customisation, as they aren't building it to your specification, it's a stock model.
But if you ask for a dual 2GHz Apple G5 PowerMac with 8GB RAM, 2x250 HDs, a SuperDrive, Bluetooth, a Radion 9800 Pro, 2 Apple Studio displays, an AirPort Extreme card, no modem, a Fibre Channel card, preinstalled with Keynote and AppleCare, then this definitely meets the definition of "customised".
But this is all academic. The point is that Apple don't want to have to spend a lot of time building and testing systems that are not stock items, only for the person placing the order to say "Oops, I didn't want that after all. Take it back and give me a full refund." I don't blame them -- that's no way to run a business. It might be better for them to charge you for the shipping and a restocking fee (and refuse to take it back if the returned system is damaged or spoiled), but really, if you don't want the thing don't place the order!
How else would you customise a computer that you order online from a computer retailer -- ask them to airbrush a nude on the case? Come on, be realistic.
That's not the mechanism. You customise the system by selecting options for things like "RAM", "Optical Disk", "Extended Warranty" etc. Yes, there are are finite number of possible configurations, but given a finite number of component types, that's true for all computers.
I don't see what your objection is.
Sorry that you came off worse in this instance, but...
1. If you didn't want the machine, why did you order it?
2. Maybe I'm misunderstanding you, but their definition of a 'custom configured computer built to the customer's specifications' seems perfectly reasonable to me.
3. It seems reasonable for Apple not to want to take back a machine that was built to your specification -- hopefully they made you aware of this at the time of buying, but since you went to court, I guess this isn't so. I assume the machine worked -- I'd be dissapointed if they didn't accept a returned faulty machine.
If one was aiming for readability, one obviously wouldn't write the gibberish in your example :-)
We didn't hit 100%, because there was code that would only be run if hardware-centric exceptional cases were encountered. In such a case, exception code was executed, which we could test via a test harness, but the
code did not get covered. I think we managed above 95%, which were we were pretty happy with. I don't recall the ratio of lines of code to lines of tests.If you look at the code coverage report for the parent example, you'll see that a common cause of less than 100% code coverage is multiple return points in functions.
Multiple return points usually occur because the algorithm computes the return value 'early' (often via some special condition) or because an error condition is encountered and the return mechanism is used to propagate errors up the call hierarchy.
If you write your function to have only a single return point at the end of the function, you can increase the code coverage, while making the code easier to read. You then have to ensure your function's control structures send control to the end of the function (no gotos, you understand!). If you try to achieve this, your programs become more logically structured, easier to test and maintain.
On one project where we set ourselves a 100% coverage target, and followed the above coding standard (along with others), we produced some excellent code.
Of course, it's really hard to exercise some exceptional states, and 100% coverage doesn't mean you have bullet-proof code, but it's another metric to use to assess your code quality.
They worked out how much it costs to build a top-three supercomputer from commodity parts at very low cost, while simultaneously getting a massive amount of publicity.
Firstly, Iran is not a socialist country! It is commonly regarded as a theocracy. The CIA World Factbook (curiously named, but useful nonetheless), classifies it as a "theocratic republic"; it also points out the government's restrictive social policies.
Secondly, the Californian welfare system is much better than that in Iran. In the event of a catastrophic event (think something of the order of 9/11), capital would be released by the state or the federal government to help those in need. In Iran, this support had to be provided by aid from other countries.
OK: the first set of countries received political, military and/or economic support from the west; the second set of countries have been ravaged by numerous civil wars fuelled by arms sales from the west, famine and HIV/AIDS (both of which received little support from the west).