algolicious

Wrap your head around this one: http://math.andrej.com/2007/09/28/seemingly-impossible-funct...

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

Has anyone tried Gimp for OS X? http://www.gimp.org/downloads/

But you can't actually simulate a TM on any machine with a fixed amount of memory. And any "special purpose" computing hardware would have at least a little memory. So I don't think that distinction works. Unless it only applies to machines with expandable memory? Technically, if it were hot swappable, the memory would be unbounded. But nowadays, the SD slot on phones is often under the battery, if it exists at all.

The best mirror I could find (nyud.net and Google let me down): http://substancedigital.com/2012/10/21/nokias-price-for-excl...

Could you explain what you mean by "to a lesser extent Android"? Android lets apps add widgets to the home screen, replace the home screen, replace the browser, run arbitrary background tasks, and so forth. You can even sideload apps and create your own app store. None of this is possible on iOS.

I'm a little disappointed that Wirth doesn't mention one of the key reasons that financial institutions use decimal floating point: that binary floating point can't produce exact representations of powers of 10, such as 0.1, and you may want to produce exact results for these situations, because fractions of a cent can really add up over time (see e.g. http://en.wikipedia.org/wiki/Salami_slicing).

You can turn the pages using the volume buttons (enabled from Settings on the home screen). I reallly love that feature.

This is one of the best critiques so far of the decision.

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.

Click on the "More" link at the bottom.

Here's the ruling:

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.

This article is missing a couple of facts:

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 looked twice to verify that she needed the wheelchair.

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.

I'm not quite sure what the issue is here. It turns out that the author modeled the domain incorrectly. At least that incorrect model is completely explicit in the code. If it weren't spelled out explicitly, the coupling that the author speaks of would be insidiously spread throughout the code. In order to make the change that the author wants, it's as easy as introducing a new abstract class. In fact, if all the existing code correctly assumes the existence of an Isin, we can create the following set of classes:

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.

This was fun! (I only did the first two paragraphs.)

You are thinking of "homophone" rather than "homonym." Baseball bat and vampire bat are homonyms.

At runtime init, Go programs attempt to reserve 512mb of RAM. If they can’t do this, they crash. Go needs the space because it is garbage collected - presumably, all GC languages, or any program that takes a similar approach to memory management, will be susceptible to the same problem.

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.

Facebook's testing practices and culture of developer accountability help to prevent serious bugs from being rolled out in production code. When a developer's code disrupts the website and necessitates a post-deployment fix, the incident is tracked and factored into Facebook's assessment of the developer's job performance.

[...]

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 was interested in his response to the question, "What you dislike the most about Lisp?"

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.

Here's the most interesting link I found after a few minutes of clicking (obligatory: I am not a doctor): http://saveourbones.com/calcium-heart-attack/

Google for the following phrase to find the site: "Run unmodified Access applications, right inside a web browser."

(Edited to remove link to not affect Google juice)

Scott Aaronson recently wrote an informative article about his trip to D-Wave: http://www.scottaaronson.com/blog/?p=954

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."

Reference counting does have runtime overhead, though. Incrementing and decrementing references as a reference gets passed around isn't free. If you have many small objects, the reference count itself may become a significant memory overhead. Furthermore, GC means that memory allocation can be done by allocating at the top of the heap instead of a more expensive malloc, and freeing garbage may be literally free depending on the algorithm used. When an object falls out of scope in a reference counted world, it is typically immediately freed - if this is a handle into a large recursive data structure, for example, it can definitely suck up cycles. Counterintuitive as it may seem, GC can be the cheapest solution in some circumstances, unless your program eschews malloc entirely.

Andy Hertzfeld used this same trick on the original Macintosh, in a move he called his "worst blunder": http://folklore.org/StoryView.py?project=Macintosh&story...

The paper tells us that Brzustowski and Burgeil already showed that a loss is forced for alternating S and Z pieces. But it is easy to see that you can get 1 line with S and Z simply by putting the thick part in the middle, and this is all the author wants.

http://www.merriam-webster.com/dictionary/puny "slight or inferior in power, size, or importance"

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

Where did you read that? The linked story states that they were married at the time and that she filed for divorce in response to his snooping.

Nope, Apple had theirs behind glass as well.

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

Doesn't work on my Droid with 2.2 either. I loaded it twice, over twelve hours apart, from different locations. Just shows a gray rectangle where the tickets should be (after showing the loading animated gif for several painful seconds) and a white area where the stadium should be. Works fine on Firefox. I think it is important to support mobile - at work, one may rather not have their employer know that they are spending time looking for tickets. Hopefully it is possible to give a good experience. The chrome takes up most of the display in landscape mode, though when I rotate to portrait, there is much more space.

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.

Actually, as an Ars commenter explains, Ars did kind of a bad job explaining NP. NP is the class of problems with an easily verified proof for existence, not the class of all exponentially solvable problems as they seem to imply (EXPTIME). Example: Is a boolean formula satisfiable? Provided an assignment for its variables, it is easy to check if it is a satisfying assignment.

Gruber ignores the Droid, which has sold far more units than the N1, does not have the Pentile subpixel reduction, and has an 854x480 display. A 960x640 display would rock but given that the LCD is smaller than current iPhones, I think it will be a 1.5x increase which will look fine with antialiasing and font/UI element scaling. So 480x720.