May be referring not to LQCD relying on approximate analytical methods but some of the other non-perturbative methods? Example would be trying to apply homotopy analysis method (HAM) or a related transform to whatever field equations to make some semi-analytical predictions.
"is it more natural read for people familiar with writing functional programs? (am I permanently "broken" due to my familiarity with imperative programing?)"
As just one person who has written a great deal of functional code, it reads well to me. I think because I am used to reading it "inside out"? Reading lisp-likes is probably helpful.
Take 'color' for example. It opens with a 'cond', with three branches. First branch is if the idx-th position in word is the same as letter, return green. Second branch is if the word includes the latter at all, yellow. Otherwise we're grey.
That took me a few seconds to grok. Just one anecdote for you. Don't think you're broken but reading/writing this kind of code even a little bit will change the way you see code IMO.
That's just a myth spread by a few workaholic programmers. Luckily, there are enough 9-5 programmers to clean up the mess created by those 2AM committers.
> I know which one I'd prefer to grok at 2AM with alerts going off.
I hate meaningless statements like this. This means nothing, other maybe that you know Python. 20 years ago people might have said that about Python - I even know many people today who would say that about Python.
I was in a "101" undergrad compsci class the first year the program used Java (1997, I think?) and so this asst prof was showing a simple example of some Java syntax.
I had been programming in C for a while, learning from K&R, to build ray tracing input files and that sort of thing so I was kind of disappointed but whatever, I was a mature student who had rediscovered computers a couple of years before (had a C64 in the 80s) and was just happy to be there.
Anyway, this guy in the back yells out "I could do that in 2 lines of Q-BASIC" or something to that effect (Q-BASIC was definitely part of his pithy one-liner). Little did I know he was representing so many of the people I would encounter over the next decades.
Honestly both read about the same to me, and I'm largely unfamiliar with Clojure. The main difference appears to be the 3 `str` callouts, which appear extraneous as the following version works just the same:
(defn color [word letter idx]
(cond
(= (nth word idx) letter) :green
(str/includes? word letter) :yellow
:else :gray))
Interesting that even with the `str` callouts removed, the function still appears to work on other datatypes such as:
(def s (seq ("test1"))
A lazy sequence, but one Clojure still allows to be indexed over in O(1) time. That's probably what the `str` conversion was trying to speed up.
Python, meanwhile, fails on lazy input as it isn't indexable.
word = (c for c in "test1")
I guess I'll be checking out Clojure this weekend.
I'm guessing that str allow it to work when the inputs are symbols? So that they are compared as strings rather than by identity. There could be more than one symbol named "foo"; if you want those to compare the same, you can't use regular symbol equality.
Or possibly the code even uses non-symbols for some of the arguments. Suppose that letter is sometimes the integer 1.
> It opens with a 'cond', with three branches. First branch is if the idx-th position in word is the same as letter, return green. Second branch is if the word includes the letter at all, yellow.
This is a tangent, but I've been thinking about how I feel when the conditions of an if-else ladder rely on the order they're listed in.
This is an example; if you swapped the order of those branches around, the coloration would become incorrect.
I'm a little happier when the conditions are described completely, such that swapping the order of the checks doesn't change which of them evaluate false or true, but it's also true that that can add quite a bit of complexity over an order-sensitive set of conditions.
Having the order matter and matching the first `true` branch makes for more readable and less-wordy if statements. Otherwise when you have two conditions which have any overlap, such as A and B, for the A branch you need to add `and not B` and for the B branch you need to add `and not A`. This can create very long expressions. Having them evaluate in order and only match the first true one makes this unnecessary.
I mean if the checks are expensive and it's on hot path, then that's wasteful.It might also require then to use more nesting of IFs which isn't necessarily nicer.
Recently came back and hero'd a character for old times sake. The people who still play are a good crew and very welcoming of anyone who wants to play.
It's a different game with fewer players, in that you have the run of desirable zones like Demonforge or Bloodstone but the meta for running them has changed to account for smaller formations. Really fun!
It's interesting since Hinton's approach seems to be more inspired by the computational geometry aspects of vision (reverse computer graphics, invariant representations) and working backwards towards the neural superstructures.
Hawkins' seems to be inspired by the biology itself, working from the "common computational substrate" hypothesis up to the cortical units required.
They both seem to meet in the middle at the need to figure out invariant representations for the intermediate features presented to each level of the hierarchy.
I do wonder what an argument between those two would look like concerning the applicability of back-propagation, which I remember Hawkins' deriding as totally artificial compared to the feedback structure of the actual neocortex.
Anyone more up to date on the state of the argument regarding that?
They both seem to neglect time (internal dynamics). I haven't seen either of them coming up with a model as that from Izhikevich with polychronization: http://www.izhikevich.org/publications/spnet.htm. If we would be able to make one of such ideas computationally useful, things would become really interesting.
I've done your typical ANN 101 training in the past so have a good mental model for back-propagation. Modelling the actual nonlinear dynamics of "realistic" neural networks seems like an obvious path of research but I know how daunting it is. It seems like every tiny bit we can push forward our tools for understanding complex non-linear systems should pay large dividends across so many different computational fields (fluid dynamics, QFT, economics, ..., everything?)
I'll have to read Izhikevich's paper, seems like a unique line of research.
Coincidence detection where delays are playing a functional role is one of the things that I find interesting (as well as the fact that there are more polychronous groups than neurons). The other thing is the emergence of gamma waves. I would be surprised if these do also not have some functional role (although it might be just as well the humming of our biological processor). :-)
I wish I was brave enough to start experimenting with different neural networks. For now I am on the roll "Bayesianfying" everything I encounter. Even the Hough transform that Hinton is so fond of in this talk. :-)
If I'm following this presentation correct it seems like it would be relatively simple to add time into these models by using the previous frame's guesses as priors for this frame.
He offhandedly mentioned something once that may have been this, but there wasn't enough context to be sure this is what he meant. Still, with the general idea of this reliable high-level affine invariance it doesn't seem hard to imagine how to convert this to a temporally-aware approach, at least at a basic level.
At the end of his talk he answers a question about audio. A student of him has worked on it and he expressed admiration for that student. He didn't come across as if he solved that problem as well. :-)
* If you have (human-like) part-based representations you need linear relationships to build up the whole again.
* Routing is key.
With dynamics involved, say movie scenes, or your hand moving in front of your own eyes, we might postulate that we will first discover linear relationships as well. A car disappearing temporarily behind a fence on the right we will expect to appear on the other side at the left.
Routing in the brain that corresponds with dynamic behavior, is probably something else than the time slicing / windowing we are all so familiar with in machine learning. It also goes beyond a simple central pattern generator for locomotion, which is not a routing problem at all (but just a clone of the outside frequency pattern with dynamics between neurons). "Real" dynamics is about being able to put items into slots, to learn a (visual) grammar. The thought that routing is key seems also be shared by Schmidthuber who created LTSM only to be able to route errors in a more sophisticated way through a network.
The problem is that Hawkins hasn't really found a comparable alternative. He's trying to throw away decades of progress in mathematics and reinvent the learning algorithms, which is great, but he hasn't succeeded (yet)
That's what came to mind first for me as well, but I think it's important to note that 'mindfulness' as defined in the paper is a specific type of "thinking harder".
I wonder if there would be similar results if the experiments were performed with new motor skill acquisition. I know that in my own experience it seems that a combination of "mindful" practice (especially at the beginning of the learning process) with "drill" type practice seems to seal the deal most efficiently. Basically the "engram" theory.
I think this is a valid concern, but as JS engines start implementing more and more of the rich web client working drafts like FileAPI (http://www.w3.org/TR/FileAPI/), those same concerns will be valid for your browser too. I can only imagine that developers of desktop platforms like this are aware of these drafts too and are planning to utilize as much as they can of the functionality provided.
As with most security, our best hope lies in open implementations which can be audited for such problems, with consideration being drawn in during design and implementation stages from security experts. Hopefully some lessons were learned from the ActiveX desktop days!
I like the idea of assigning permissions to applications. Then if browser B runs under user U, its effective permissions would be the intersection of what both B and U are allowed to do. I don't see why Firefox should be able to write anything outside ~/.mozilla/firefox and ~/Downloads
These type of restrictions are exactly what Linux's AppArmor (as well as SELinux, etc) do.
I'm not sure what profile Firefox runs under, but what you suggested would be quite reasonable, though maybe not as default -- You probably want to be able to "save as" to an arbitrary directory, and open files for upload from anywhere too. Though since both of those involve a user dialog, that could easily be a secondary application with its own profile that uses IPC/shared memory/something to pass data to the browser. Smaller target attack area.
This post really really resonates with the thoughts bouncing around in my head currently.
In the current environment (at least where I am) of well-funded startups with no shortage of benefits and work/life balance, a lot of people will think you're crazy for not taking advantage of it.
I personally like the closing sentence:
"Interesting indeed. And somehow, I have a feeling that it’s all going to work out in the end. For both of us."
While optimistic, it reminds me that try as we might to codify and generalize all the ways to be successful in business, your own personal heuristic approach is all that's going to matter in the end.
"In the current environment (at least where I am) of well-funded startups with no shortage of benefits and work/life balance, a lot of people will think you're crazy for not taking advantage of it."
The reply to those people is: there's no such thing as a free lunch. All that funding isn't coming out of the goodness of people's hearts, there are strings attached. We all need to make our tradeoffs.
It might be worthwhile to take a look at certain types of game engine architectures.
Since modularity is one of the keypoints of how this editor/game engine work so well together, it's probably a good idea to have some idea of how to structure game components to lessen the 'ball of mud' feeling.
Cool! Since the startup I work for has been acquired I've been working downtown and lamenting the lack of such things. I'd like to check out your spot sometime!
There's also an interesting group of folks over in silverlake at the "silverlake headquarters (SLHQ)", which is also decidedly non west side. :)
