algolicious

Also, I'd recommend taking a look at Magma: http://en.wikipedia.org/wiki/Magma_computer_algebra_system

There are two sides to this trial. On the one side is the emotional appeal: Samsung copied Apple, and documents detail the extent to which Samsung imitated the iPhone. On the other side are the various technical ways in which Apple claimed that Samsung copied them. But just as Apple engineers slaved for years over the technical details of the iPhone, it is incredibly important for the future of mobile innovation that all of the technical parts of the trial are correctly decided. If the jury finds no infringement but finds that infringement was induced, this indicates that technical mistakes were made. But in particular, I wonder if the jury was so swayed by the emotional appeal that sufficient attention was paid to the substantial prior art demonstrated regarding capacitive touch screen phones and multitouch displays.

http://www.scribd.com/doc/98367038/Galaxy-Tab-Injunction-Rul...

The injunction is being granted based on this patent:

http://www.google.com/patents/USD504889

It's a design patent granted in 2005 for an electronic device shaped like a rounded rectangle. But it cites several other patents for other devices shaped like rectangles. So is it the precise aspect ratio and thickness of their rectangle that makes it unique? But the Galaxy Tab is substantially thinner than the rectangle shown in this patent.

First, Apple has been designing its own "Ax" series of ARM chips with its purchase of PA Semi, currently with the A5/A5X. If Apple switched to an Intel chip, they would no longer have the flexibility of a custom design or marketing claim to a custom chip in their product.

Second, though Apple contracts with Samsung to fabricate their ARM chips, they could presumably go to other companies to do the same thing. There have been rumors of a future partnership with TSMC. If Apple switched iOS to Intel's architecture, Apple would have much less flexibility with fabrication.

Third, switching CPU architectures means that your old software doesn't work immediately (we used to say "out of the box"). When Apple previously switched CPU architectures on the Mac, they had an emulator to allow running old apps, but this has a huge performance penalty that wouldn't fly on iOS: apps wouldn't be silky smooth on the latest product. The situation here is a bit different than with the Mac because developers sell directly through the App Store, but Apple would have to take a temporary hit to their huge app selection while developers recompile their apps, and some developers may not have the resources to do so (because the work was done via contract, for example). Perhaps static recompilation to retarget the architecture could be done by Apple for each app, but reading the EFF's copy of the iPhone Developer Program License Agreement, I don't see where Apple granted themselves the right to do this (correct me if I'm wrong).

To me, it makes more sense that Apple would want Intel to manufacture Ax ARM chips for them. But given that Intel has shown huge resistance to ARM (probably due to the lack of manufacturer lock-in), it's unlikely that they would partner with Apple to do this. The key advantage for Apple would be the use of Intel's cutting edge fabs, which would make their ARM chips the undisputed champions.

I'm not quite sure why Pike wrote this. Was he afraid that the wheelchair concealed a weapon of some sort? But how can you visually verify that a person needs a wheelchair?

I also wonder what Pike thinks now that his employer is being sued over the violations of patents in their open source GUI software. The swipe-to-unlock patent strikes me as about as obvious as backing store.

abstract class BaseSecurity { public string Description { get; set; } public Exchange Exchange { get; set; } }

then modify Security to derive from BaseSecurity:

abstract class Security : BaseSecurity { public string Isin { get; set; } }

Then you are done, except for two issues: first is that any serialized data needs to be regenerated, and second is that you can't trade BaseSecurities. However, this trading functionality can be written separately without disturbing the existing ecosystem of software. This is what your type hierarchy buys you.

On the other hand, if we insist that this is not correct, and Security should have Isin removed, then we can add a new PhysicalSecurity between Security and the various implementations, and Stock/Bond/Trade can inherit from PhysicalSecurity.

In that case, the problem is that a lot of code was written with the incorrect assumption that an Isin exists in every security. Now we have to take a step back and ask how to fix that code on a case by case basis. No matter what language you use, it's always possible to write bad code with incorrect assumptions, and in that case you must pay the price. Hopefully you would be clear with your client on the delays required.

Now we can ask ourselves how a static language treats the situation differently than a dynamic language. The author seems to think a dynamic language would help, providing only praise in his description of them.

With a static language, we can simply remove Isin from the definition of Option. This will cause a lot of compilation failures. However, every place where there is a compilation failure is a place in the code which had an incorrect assumption. Each of these incorrect assumptions must be considered individually. After all, this represents the model for a trading system, and any bugs would likely result in severe financial consequences.

In a dynamic language, the definition could be changed, but there would not be any inherent mechanism to catch the now-incorrect calls. Instead, we would just get the NullPointerExceptions that the author complains about and which jeopardize the viability of the financial trading system. Perhaps the coders would have written beautiful unit tests that would help, but that could be the case in any static language as well. Of course, it's also possible that the coders would have created trivial unit tests or no tests at all.

In any case, I see this situation as a win for static type systems rather than a loss.

While it is true that most garbage collected environments will reserve some memory at startup, a hard minimum of 512 MB is not the norm. Do note that embedded Java has run on cell phones with minimal amounts of RAM for many years.

Employees with low karma can regain their lost points over time by performing well—though some also try to help their odds by bringing Rossi goodies. Booze and cupcakes are Rossi's preferred currency of redemption; the release engineering team has an impressive supply of booze on hand, some of which was supplied by developers looking to restore their tarnished karma.

This sounds like Facebook strongly rewards developers who work on trivial, low-risk features rather than larger, more important features. Also, it sounds like bribery factors into your overall job performance rating.

I must say that the lack of static typing really gets in the way on larger projects. Being able to confidently change datatypes and function signatures, knowing that the compiler will point out most inconsistencies that you introduce, is something that I've really come to appreciate after working with Rust and Haskell. Test coverage helps, of course, but I'm not a very diligent test writer, and tend to feel that type signatures are easier to maintain than an exhaustive test suite.

(Edited to remove link to not affect Google juice)

Most interesting to me: "Geordie presented graphs that showed D-Wave’s quantum annealer solving its Ising spin problem “faster” than classical simulated annealing and tabu search (where “faster” means ignoring the time for cooling the annealer down, which seemed fair to me). Unfortunately, the data didn’t go up to large input sizes, while the data that did go up to large input sizes only compared against complete classical algorithms rather than heuristic ones. (Of course, all this is leaving aside the large blowups that would likely be incurred in practice, from reducing practical optimization problems to D-Wave’s fixed Ising spin problem.) In summary, while the observed speedup is certainly interesting, it remains unclear exactly what to make of it, and especially, whether or not quantum coherence is playing a role."

In this case, they meant power, as in computational power.

http://www.engadget.com/2007/01/09/video-iphone-in-person-be...

One other thing: is there any way to keep the dots from displaying until the map is loaded? It is jarring for me to see them floating out in white space. Yet when the map is cached, the map displays before the dots.