I'm fairly well-versed in interactive use of MATLAB and ipython/numpy/scipy. I also have an HP-50g next to my monitor, with the USB cable plugged in so I don't need to keep replacing the batteries every few months.
Generally speaking,
I use ipython if : - the problem has a significant non-mathematical component (string processing or some other general-purpose programming language task), or - I want good looking 3d graphs
I use MATLAB if: - I need to plot a bunch of things (2d), or - the problem is almost entirely linear algebra
I use the 50g if: - the problem is short enough to quickly write on paper, or - the programming only requires a handful or short routines, or - neither of the above programs is running, and the problem won't take more than a minute or two to type in and run on the 50g
There's a strong inverse relationship between the power of a calculating tool and it's usability. For really short stuff with only one or two variables, the ergonomically-ideal 15c is much much quicker than the clumsy notation of numpy. The 50g, with it's math-optimized keyboard and GUI, is often much faster than either desktop option because the bottleneck is the typing process, not the computation process.
So, it doesn't have a physical keyboard, it's slower for all but the most complex operations that a 12c or 15c can do, it gets 1/1000th the battery life, and it has a monthly fee. Sounds great.
It's really a perfect illustration of the downside to device convergence. Your smartphone is jack of all trades, master of none. The 15c, on the other hand, has very little room for improvement: the screen contrast, battery life, and execution speed could be improved, and the price could be lower. The rest of it is basically perfect, and couldn't be improved without seriously compromising another feature. (eg. it could support more functions, but only by compromising the usability significantly.)
Nowadays, you can actually force ICC to emit code that will use up to SSSE3 on AMD CPUs, but only if you don't use runtime code-path selection. (More specifically, you have to tell ICC that the least-common-denominator code path should use SSSE3, which defeats the purpose of runtime code-path selection. ICC will always choose the slowest available code path for an AMD CPU, but you can prevent it from including a non-SSE code path.)
For the hardcore gamers who don't have unlimited budgets, it might be logical to buy the cheapest CPU that won't bottleneck your games, and pair it with the fastest graphics cards you can afford. Particularly if your games can use the GPU for the physics engine, you might not need even AMD's high-end CPUs to keep a pair of NVidia cards busy.
If a company like Intel is still making big mistakes like the Sandy Bridge chipset problem, what reason is there to believe that there will still be a correlation between design flaw frequency and experience if everyone under discussion has at least a few years and more than one product cycle under their belt? Do you really think that anybody who was at Intel during the 1980s is helping them prevent design flaws?
If all they get is a molten pool of radioactive lava, they'll be much better off than Chernobyl: there, the graphite moderator of the reactor caught fire and helped spread fallout far and wide. A pool of radioactive lava is only problematic while it's still too hot to build a new containment building around.
Which nVidia chipsets are you talking about? The only NV chipset problem I remember was the defective packaging of the 8600M, which was eventually recalled.
It's quite possible that sending frivolous takedowns could result in some kind of fraud charges for the copyright holder and FRCP rule 11 sanctions for the law firm, but the DMCA itself does almost nothing to dissuade frivolous notices.
According to the law at issue, the only portion of a DMCA takedown notice that is under penalty of perjury is that the person filing it is authorized to act on behalf of the copyright owner alleging infringement.
For a DMCA takedown counter-notice, the poster needs to assert under penalty of perjury that they have a good faith belief that the takedown was a mistake or misidentification. The lack of a requirement that the party issuing the takedown make a similar statement of belief under penalty of perjury is the real bullshit here, as it violated the principle of equal protection under law.
They don't have any immunity in the first place, as this notice is not about infringement (it's about circumvention devices), so it isn't covered by the DMCA's safe harbor provision.
It's not a real takedown. It's a normal cease-and-desist letter, and even if it were a real takedown notice, it's only perjury if the person submitting it isn't authorized to act on behalf of the person claiming ownership of a work being infringed. Neither the copyright holder or his lawyer are guilty of perjury if the copyright holder lies to his lawyer (or is mistaken) and thus causes a frivolous takedown notice to be sent.
Hit the brakes, and tell the computer in the car behind you to do the same. Also, the car behind you was using radar-assisted cruise control, so it actually wasn't tailgating you.
Obstacles like deer, weather, falling trees, etc. are far less dangerous than the other people on the road. If you can get the rest of them to drive safely and react reliably and quickly, then things like deer are much easier to handle.
The 6900s were originally intended to be build on a 32nm process and be released as the 7x00s, but then TSMC cancelled their 32nm node, so AMD axed half the features of the 7x00s and moved them to the 40nm process that they first used on the 4700s, and used on all the 5000s and 6000s. (The earlier 6000s had also been planned to be 32nm, but ADM switched back to 40nm for cost reasons before the 32nm node got canceled.)
Long story short, the 6900s are being manufactured on a process that is quite mature and that they have a lot of experience with, since it is roughly the 4th generation product on that process. It should be no surprise that yields would be very high out of the gate.
My setup: A regular mouse on the right for gaming and occasional casual use, and a tablet for anything requiring precision or lots of GUI interaction (and for some RTS games). That way, I'm not developing muscle memory that is in any way backwards, but I still get to take advantage of the better dexterity in my left hand.
I do quite like the layout of laptops like the MacBook Pro, with a big touchpad centered under the keyboard, so that you can use it with either hand. Even the multitouch gestures added by jitouch are ambidextrous, so I can switch between hands easily, depending on what side of the keyboard I need to use more.
The only reason to by a TI calculator is because your teacher tells you to.
When you need to get your math on (or your physics or engineering), you use an HP:
My HP-15C is a pocket-sized programmable scientific calculator capable of handling matrices, complex numbers, and numerical root finding and integration. Its battery life is 2-3 years under moderate use.
My graphing calculator is an HP-50g, which has a 200Mhz ARM9 processor (by default underclocked to 75Mhz), an SD card slot that enables you to store all the programs you might want including full source code and documentation, a more powerful computer algebra system than in the TI-89, and it costs less than the TI-89. Also, it can connect to the internet using a modem connected to the serial port or through an IrDA connection to a computer.
Re:That's one heck of a "long goodbye"
on
Goodbye, VGA
·
· Score: 1
Most of Apple's USB stuff runs far beyond spec in terms of the power delivered, so that people won't have the unpleasant surprise on finding out their iPod didn't charge while it was plugged in to the computer.
It seems to me that the number one priority is probably to minimize the risk to actual people, and number two is to get rid of the explosives. Reducing collateral damage is a distant third. Given that, they've decided that the nearest people to the "controlled burn" will be about 5 times further away than their worst-case estimate for how far shrapnel would fly if the stuff starts detonating. It seems, if you presume a reasonable level of competence on the part of the people planning this operation (and with scientists from several national laboratories involved, this assumption is a safe one), that their plan will do a very good job of fulfilling their first two goals.
If they tried to keep people this far away while dismantling the house by robot, the whole process would probably take weeks. The manpower needed to operate and support the robots and keep the area safe, plus the cost of housing the displaced neighbors for an extended period of time probably far outweighs the potential damage the controlled burn could do, particularly given the measures they're taking to protect the adjacent houses.
Individually extracting the bombs requires real, live people to spend a lot of time moving around in and near a house full of explosives. If they start going off, people die. On the other hand, evacuating the neighborhood and setting up remote-controlled fire hoses allows you to get rid of the explosives quickly and without significant risk of people getting hurt. Yes, the risk of property damage beyond the house itself is probably higher this way, but the risk of people getting hurt is much lower, as is the duration of the evacuation of the neighborhood.
Try reading the article again. The 30 minutes is not how long they expect it to take for the house to burn down. 30 minutes is how long they expect it to take before the fire is hot enough to break down toxins before they can escape the house in the plume of smoke.
As for the detonation issue, a lot of explosives will merely burn quickly unless they are very hot and are triggered by a shock wave (such as from a blasting cap) to detonate. It's quite reasonable for them to expect to be able to burn a lot of the explosives without detonation occurring, and even if a lot of the stuff does detonate, they've calculated that debris would only be sent flying 60-70 feet.
From what I recall, all Macs for the past 2 years or so have supported much-higher-than-spec currents over USB so that they can charge iPods and iPhones more quickly.
I was referring more to the fact that there are a great many programmers developing apps for Apple platforms, but Ada and Eiffel programmers are harder to find. CL and Ocaml are probably too abstract to catch on in a market where the average programmer can handle Java and some of C++'s capabilities.
Are any of those good enough compared to obj-c to overcome the advantage obj-c has of being familiar to far more programmers? From what I've heard, CL might be, but I don't know any of those languages enough to judge.
Also, do any of those languages make it as easy to use C and C++ libraries as Obj-C does?
Slashdot Mirror
I'm fairly well-versed in interactive use of MATLAB and ipython/numpy/scipy. I also have an HP-50g next to my monitor, with the USB cable plugged in so I don't need to keep replacing the batteries every few months.
Generally speaking,
I use ipython if :
- the problem has a significant non-mathematical component (string processing or some other general-purpose programming language task), or
- I want good looking 3d graphs
I use MATLAB if:
- I need to plot a bunch of things (2d), or
- the problem is almost entirely linear algebra
I use the 50g if:
- the problem is short enough to quickly write on paper, or
- the programming only requires a handful or short routines, or
- neither of the above programs is running, and the problem won't take more than a minute or two to type in and run on the 50g
There's a strong inverse relationship between the power of a calculating tool and it's usability. For really short stuff with only one or two variables, the ergonomically-ideal 15c is much much quicker than the clumsy notation of numpy. The 50g, with it's math-optimized keyboard and GUI, is often much faster than either desktop option because the bottleneck is the typing process, not the computation process.
So, it doesn't have a physical keyboard, it's slower for all but the most complex operations that a 12c or 15c can do, it gets 1/1000th the battery life, and it has a monthly fee. Sounds great.
It's really a perfect illustration of the downside to device convergence. Your smartphone is jack of all trades, master of none. The 15c, on the other hand, has very little room for improvement: the screen contrast, battery life, and execution speed could be improved, and the price could be lower. The rest of it is basically perfect, and couldn't be improved without seriously compromising another feature. (eg. it could support more functions, but only by compromising the usability significantly.)
Nowadays, you can actually force ICC to emit code that will use up to SSSE3 on AMD CPUs, but only if you don't use runtime code-path selection. (More specifically, you have to tell ICC that the least-common-denominator code path should use SSSE3, which defeats the purpose of runtime code-path selection. ICC will always choose the slowest available code path for an AMD CPU, but you can prevent it from including a non-SSE code path.)
For the hardcore gamers who don't have unlimited budgets, it might be logical to buy the cheapest CPU that won't bottleneck your games, and pair it with the fastest graphics cards you can afford. Particularly if your games can use the GPU for the physics engine, you might not need even AMD's high-end CPUs to keep a pair of NVidia cards busy.
If a company like Intel is still making big mistakes like the Sandy Bridge chipset problem, what reason is there to believe that there will still be a correlation between design flaw frequency and experience if everyone under discussion has at least a few years and more than one product cycle under their belt? Do you really think that anybody who was at Intel during the 1980s is helping them prevent design flaws?
If all they get is a molten pool of radioactive lava, they'll be much better off than Chernobyl: there, the graphite moderator of the reactor caught fire and helped spread fallout far and wide. A pool of radioactive lava is only problematic while it's still too hot to build a new containment building around.
Which nVidia chipsets are you talking about? The only NV chipset problem I remember was the defective packaging of the 8600M, which was eventually recalled.
It's quite possible that sending frivolous takedowns could result in some kind of fraud charges for the copyright holder and FRCP rule 11 sanctions for the law firm, but the DMCA itself does almost nothing to dissuade frivolous notices.
According to the law at issue, the only portion of a DMCA takedown notice that is under penalty of perjury is that the person filing it is authorized to act on behalf of the copyright owner alleging infringement.
For a DMCA takedown counter-notice, the poster needs to assert under penalty of perjury that they have a good faith belief that the takedown was a mistake or misidentification. The lack of a requirement that the party issuing the takedown make a similar statement of belief under penalty of perjury is the real bullshit here, as it violated the principle of equal protection under law.
They don't have any immunity in the first place, as this notice is not about infringement (it's about circumvention devices), so it isn't covered by the DMCA's safe harbor provision.
It's not a real takedown. It's a normal cease-and-desist letter, and even if it were a real takedown notice, it's only perjury if the person submitting it isn't authorized to act on behalf of the person claiming ownership of a work being infringed. Neither the copyright holder or his lawyer are guilty of perjury if the copyright holder lies to his lawyer (or is mistaken) and thus causes a frivolous takedown notice to be sent.
Hit the brakes, and tell the computer in the car behind you to do the same. Also, the car behind you was using radar-assisted cruise control, so it actually wasn't tailgating you.
Obstacles like deer, weather, falling trees, etc. are far less dangerous than the other people on the road. If you can get the rest of them to drive safely and react reliably and quickly, then things like deer are much easier to handle.
The 6900s were originally intended to be build on a 32nm process and be released as the 7x00s, but then TSMC cancelled their 32nm node, so AMD axed half the features of the 7x00s and moved them to the 40nm process that they first used on the 4700s, and used on all the 5000s and 6000s. (The earlier 6000s had also been planned to be 32nm, but ADM switched back to 40nm for cost reasons before the 32nm node got canceled.)
Long story short, the 6900s are being manufactured on a process that is quite mature and that they have a lot of experience with, since it is roughly the 4th generation product on that process. It should be no surprise that yields would be very high out of the gate.
My setup: A regular mouse on the right for gaming and occasional casual use, and a tablet for anything requiring precision or lots of GUI interaction (and for some RTS games). That way, I'm not developing muscle memory that is in any way backwards, but I still get to take advantage of the better dexterity in my left hand.
I do quite like the layout of laptops like the MacBook Pro, with a big touchpad centered under the keyboard, so that you can use it with either hand. Even the multitouch gestures added by jitouch are ambidextrous, so I can switch between hands easily, depending on what side of the keyboard I need to use more.
You may not have to pay money to get the fuel, but it is limited, so efficiency matters.
I would say that it's close enough for the kind of scientific work where using non-metric units is acceptable.
The only reason to by a TI calculator is because your teacher tells you to.
When you need to get your math on (or your physics or engineering), you use an HP:
My HP-15C is a pocket-sized programmable scientific calculator capable of handling matrices, complex numbers, and numerical root finding and integration. Its battery life is 2-3 years under moderate use.
My graphing calculator is an HP-50g, which has a 200Mhz ARM9 processor (by default underclocked to 75Mhz), an SD card slot that enables you to store all the programs you might want including full source code and documentation, a more powerful computer algebra system than in the TI-89, and it costs less than the TI-89. Also, it can connect to the internet using a modem connected to the serial port or through an IrDA connection to a computer.
Most of Apple's USB stuff runs far beyond spec in terms of the power delivered, so that people won't have the unpleasant surprise on finding out their iPod didn't charge while it was plugged in to the computer.
It seems to me that the number one priority is probably to minimize the risk to actual people, and number two is to get rid of the explosives. Reducing collateral damage is a distant third. Given that, they've decided that the nearest people to the "controlled burn" will be about 5 times further away than their worst-case estimate for how far shrapnel would fly if the stuff starts detonating. It seems, if you presume a reasonable level of competence on the part of the people planning this operation (and with scientists from several national laboratories involved, this assumption is a safe one), that their plan will do a very good job of fulfilling their first two goals.
If they tried to keep people this far away while dismantling the house by robot, the whole process would probably take weeks. The manpower needed to operate and support the robots and keep the area safe, plus the cost of housing the displaced neighbors for an extended period of time probably far outweighs the potential damage the controlled burn could do, particularly given the measures they're taking to protect the adjacent houses.
Individually extracting the bombs requires real, live people to spend a lot of time moving around in and near a house full of explosives. If they start going off, people die. On the other hand, evacuating the neighborhood and setting up remote-controlled fire hoses allows you to get rid of the explosives quickly and without significant risk of people getting hurt. Yes, the risk of property damage beyond the house itself is probably higher this way, but the risk of people getting hurt is much lower, as is the duration of the evacuation of the neighborhood.
Try reading the article again. The 30 minutes is not how long they expect it to take for the house to burn down. 30 minutes is how long they expect it to take before the fire is hot enough to break down toxins before they can escape the house in the plume of smoke.
As for the detonation issue, a lot of explosives will merely burn quickly unless they are very hot and are triggered by a shock wave (such as from a blasting cap) to detonate. It's quite reasonable for them to expect to be able to burn a lot of the explosives without detonation occurring, and even if a lot of the stuff does detonate, they've calculated that debris would only be sent flying 60-70 feet.
From what I recall, all Macs for the past 2 years or so have supported much-higher-than-spec currents over USB so that they can charge iPods and iPhones more quickly.
I was referring more to the fact that there are a great many programmers developing apps for Apple platforms, but Ada and Eiffel programmers are harder to find. CL and Ocaml are probably too abstract to catch on in a market where the average programmer can handle Java and some of C++'s capabilities.
Are any of those good enough compared to obj-c to overcome the advantage obj-c has of being familiar to far more programmers? From what I've heard, CL might be, but I don't know any of those languages enough to judge.
Also, do any of those languages make it as easy to use C and C++ libraries as Obj-C does?
If you're not a fan of "gui driven development", why are you commenting on an article about a framework for making GUIs for consumer electronics?