436 karma · joined September 1, 2007
CVE-2019-5876
CVE-2019-16230
CVE-2019-16231
CVE-2019-16232
CVE-2019-16233
CVE-2019-16234
CVE-2019-15026
CVE-2019-14192
CVE-2019-14193
CVE-2019-14194
CVE-2019-14195
CVE-2019-14196
CVE-2019-14197
CVE-2019-14198
CVE-2019-14199
CVE-2019-14200
CVE-2019-14201
CVE-2019-14202
CVE-2019-14203
CVE-2019-14204
CVE-2019-14437
CVE-2019-14438
CVE-2019-14438
CVE-2019-14498
CVE-2019-14535
CVE-2019-14534
CVE-2019-14533
CVE-2019-14776
CVE-2019-14778
CVE-2019-14779
CVE-2019-14777
CVE-2019-14970
CVE-2019-15119
CVE-2019-14524
CVE-2019-14523
CVE-2019-7307
CVE-2019-11476
CVE-2019-13115
CVE-2019-3570
CVE-2019-13110
CVE-2019-13112
CVE-2019-13113
CVE-2019-13108
CVE-2019-13109
CVE-2019-13111
CVE-2019-13114
CVE-2019-3560
CVE-2019-9721
CVE-2019-9718
CVE-2019-9717
CVE-2019-9720
CVE-2019-9719
CVE-2018-20222
CVE-2019-3828
CVE-2019-6986
CVE-2019-5414
CVE-2018-4460
CVE-2018-16491
CVE-2018-16489
CVE-2018-16490
CVE-2018-19476
CVE-2018-19477
CVE-2018-19475
CVE-2018-19134
CVE-2018-16472
CVE-2018-18820
CVE-2018-4407
CVE-2018-16487
CVE-2018-4259
CVE-2018-4286
CVE-2018-4287
CVE-2018-4288
CVE-2018-4291
CVE-2019-5413
CVE-2018-16461
CVE-2018-16469
CVE-2018-16486
CVE-2018-16460
CVE-2018-16492
CVE-2018-11776
CVE-2018-8018
CVE-2018-8294
CVE-2018-4249
CVE-2018-8013
CVE-2018-5388
CVE-2018-1295
CVE-2018-4136
CVE-2018-4160
CVE-2018-1000140
CVE-2017-15692
CVE-2017-15693
CVE-2017-13904
CVE-2017-15089
CVE-2018-6834
CVE-2018-6835
CVE-2017-15713
CVE-2017-12634
CVE-2017-13782
CVE-2017-7545
CVE-2017-14949
CVE-2017-14868
CVE-2017-8046
CVE-2017-8045
CVE-2017-9805
CVE-2017-1000207
CVE-2017-1000208
CVE-2017-12612
CVE-2017-0141
So You Want To Learn Type Theory (http://purelytheoretical.com/sywtltt.html)
It felt to me like they had found a way to restrict "symbolic" data to a very narrow domain where issues like hierarchical structure was totally absent, and vectorial representation was therefore quite straight forward, and I wanted to figure out an alternative. Instead of restricting the kinds of symbolic data involved, do the full spectrum. I had the symbolic vector idea in my head for about two years as an answer to the representation problem, but I hadn't seen what the right answer was to the other aspects, at least not clearly. But that paper motivated me to start thinking about it again, and this time I saw the answer. :)
Regarding handling lossiness, it's not clear to what extent it needs to be handled, but the `k` mentioned in the definition of symbolic vectors is a parameter, and the larger `k` is, the less lossy the representation.
Besides, I said "aims", not "succeeds"! :)
I certainly don't think this is The Big Solution, tho. It's far more mundane. Unifying the techniques is nice, but all that means is that we don't have to think about GOFAI and ML as fundamentally distinct. It doesn't mean that any truly deep problems have been solved, just that there's now a reasonably reliable way to use both that isn't just "simultaneous" but rather "fused".
But I would caution against saying this is a Vector Symbolic Architecture; the representations are, as far as I know, quite distinct.
It depends on what you mean by that. It assumes a fixed set of node labels, but not node identities, since we're counting subgraphs. So for instance, multiple distinct nodes labeled `X` or edges labeled `Y` will contribute to the same count, despite having distinct nodes involved.
But if I were to take a staunch SPJian-McBridian position, I would say this attitude arises from really useless type systems.
A good type system is EITHER capable of letting you say as little as necessary, and only telling you when something is messed up (like Haskell or ML, which have type inference and therefore don't require you to write types) OR is capable of letting you say what you mean, and then doing a lot of work for you.
This is the wonderful benefit of dependent types: you can say enough about your intention that you stop fighting the type checker, and actually get the type checker to do work for you.
This is really something that hasn't percolated into the mainstream of programming yet, but is slowing creeping into Haskell with typed holes, but in dependently typed languages like Agda or Epigram, types can be expressive enough that your editor can write half the program for you just because the type you wrote has only one program as its inhabitant.
McBride likes to describe it as, Dependent Types warp code space so that the direction we want to travel is "down", and all we have to do is let ourselves fall.
As an example, here's a demonstration of some simple (but exemplary) interaction with Agda. If we define this type:
data Vec (A : Set) : Nat -> Set where
Nil : Vec A 0
Cons : forall {n} -> A -> Vec A n -> Vec A (1 + n)
where `Nat` is the type of natural numbers and `Vec` is the type of lists indexed by their length, then we might be inclined to write this function: append : forall {A m n} -> Vec A m -> Vec A n -> Vec A (m + n)
append xs ys = {! !}0
where the `{! !}0` is a portion of the program that hasn't yet been defined, called a hole. We can put the cursor in the hole (hole 0) and ask the editor to do a case split on `xs` with `Control-c Control-c x`, and the program will change to be append : forall {A m n} -> Vec A m -> Vec A n -> Vec A (m + n)
append Nil ys = {! !}0
append (Cons x xs) ys = {! !}1
if we put the cursor in hole 0, we can hit `Control-c Control-a` (a for agsy, or auto) and itll fill in the hole with the solution `ys`, and if we do the same in hole 1, itll fill in `Cons x (append xs ys)`.The type of the function we're defining is enough that agda can actually find the definition with almost no help from us.
Not knuckle wrapping here :)
There are also interesting possibilities of cross-pollinating apps, so that as more developers use LE, its out-of-the-box capabilities grow. There's no reason, for instance, that developers should be re-inventing the wheel each time someone builds an app or a robot or whatever. Imagine if every human was born with the cumulative knowledge and skills of all previous humans. Now imagine you can do that with AI.
I don't know about SQL's natural language support, so I won't comment.
As for languages, the technology is independent of particular languages, so you can in principle add modules for, say, core Mandarin vocabulary, and then write your apps for Mandarin. I only speak English, however, so I can only add core vocab for that. :\