HN user

frig

538 karma
Posts1
Comments268
View on HN

For all the thought you've put into your comment you clearly have a lot of your ego -- probably too much -- invested in being the guy who's not afraid to publicly point out it might be worth making scientific inquiry into racial differences.

Let me point out exactly how you're being stupid here.

The article is about future ramifications of genetic sequencing technology finally becoming economical enough that it's possible to cheaply sequence a person's complete DNA.

You're right that this will allow research to be done of the form: grab a DB with 100k different peoples' sequences; discover strong statistical associations between such-and-such genes and such-and-such amount of alcohol intolerance, and notice that those genes are particularly prevalent amongst people of asian descent.

Where you go awry is your conceptualization of how this information will likely be used; it's a failure to take a premise you've accepted in one part of your scenario -- the premise that DNA sequencing will be cheap-and-thorough enough to allow for research like just sketched -- and failing to apply it to another part of your scenario -- the doctor-patient interaction, and so on.

Given a world in which DNA sequencing is super-cheap and super-affordable, which doctor-patient interaction is likelier:

- doctor says to patient: "you clearly are asian just by looking at you. asians have been shown to have lower alcohol tolerance on average. be careful with how much alcohol you imbibe."

- doctor says to patient: "your DNA sequence contains 7 of the 10 major genes associated with higher levels of alcohol intolerance. this isn't surprising given your family history, but it's nice to know concretely what you've got. be careful with how much alcohol you imbibe."

...which is why you're being stupid: race is a proxy measure for ancestry that's "field-performable" (just look!) and cost-effective and is not an entirely useless proxy measure for ancestry; it is indeed the case that were political bugaboos different than they are that some useful research could be done to characterize racial differences that could be put to general use.

It's also a terribly inaccurate proxy and given the ability to do direct DNA sequencing would be dropped like hotcakes; why use the inaccurate proxy when you can make a direct measurement?

So even in your hypothetical example of looking for a wife: when this research is available, would you not be better served testing for specific genes in a particular individual rather than cutting it off at the level of race? You might still want to move to Ankara if you discovered that "Turks" are likelier than Brits to carry the genes you want your kids to have, but would you really not take it further and check the specific woman's DNA directly (the way that some jews test for tay-sachs at some point in the courtship process)? If you take the research seriously enough to move to Ankara to stack the deck why stop there?

You're essentially making the same kind of mental error you saw in the early dot-com days where people understood that "in the future, you'll buy stuff at home over the internet" -- so were semi-prescient -- but couldn't discard what they already knew about "shopping"; the consequence being that they'd write articles about how you'd sign into some 3d virtual world and then visit an online bookstore and browse the shelves in virtual reality (transporting outdated ideas into a world of new possibilities).

The specific example of 'da Bears' was a weak attempt at humor. I can't easily clarify what I'm getting at and keep this short, and I've got limited time so I'll do the best I can.

I see a lot of people using "informal" bayesian reasoning (meaning a lot of talk about priors and updating and reference to theorems but never any use of actual distributions beyond super-super-cursory examples applied to trivial situations like the boy/girl thing here or stuff like the monty hall problem).

I don't have any problem at all with bayesian analysis applied in a rigorous setting to a rigorously specified problem (like spam detection and so on).

In an informal setting I'm extremely skeptical of the uses I tend to see b/c there's no careful attempt to clearly delineate which informally-statable hypotheses are valid and which are "invalid" "meta-hypotheses" like the optimism thing.

What you've described here is a way in which someone reasonably smart would eliminate the meta hypothesis, which is fine. In general I wouldn't expect it to be feasible to take a full mental inventory, do a topological sort on your beliefs, and then apply the same procedure; most people most of the time will be running around holding partially-inconsistent beliefs (where "hold" means if you were to ask them to give an estimate of, say, what beliefs they had about what # of their beliefs were likely to wind up revealed to be significantly off in the future, or to give an estimate of what they believe about the frequency with which they'd encounter evidence leading to significant revisions of their beliefs, they'd have an answer on offer which would still have "work to do", the way the unexamined belief that "I'm too optimistic about the bears" really has work to be done).

What I'm curious about is if there's either a clearly-specifiable criteria for which types of beliefs or hypotheses are workable and which are "too meta to work", or there's some kind of theorem guaranteeing that starting out with "inconsistent" beliefs -- in the sense of "meta-hypotheses" like with da bears -- you can apply this algorithm to process evidence and over time you'll converge on beliefs that're at least more consistent than you started with.

It's hard to say much more without getting formal and I'm out of time for now; since I'm mainly concerned with informal use of "bayesian" metaphors it's not hugely critical to formalize this stuff but later I could give it a proper whack.

Say a proper Bayesian who's a fan of 'da Bears' just saw the bears lose again, badly. How is he supposed to update these two beliefs:

- this season 'da Bears' will tear shit up every Sunday (fwiw assume prior on this has it as likely)

- I am usually over-optimistic about 'da Bears''s performance (fwiw assume prior on this also has it as likely)

...in light of the new evidence?

(Side note: I'm specifically not talking about bayesian analysis or statistics in a formal setting with a prespecified, finite list of allowed hypotheses (like spam or ham).

If I wrote this out in extreme detail I'd get nothing done today, I think you can charitably fill in the gaps and missing pieces of what I'm getting at; if not I'll fill them out in a few.)

Just something I had a hard time figuring out and seems poorly documented:

    --type-set=scala=.scala # works in .ackrc
    --type-set scala=.scala # doesn't work in .ackrc
...despite the version with one equals being correct command-line sequence. Only seems to matter if you want each flag on a single line in your .ackrc file. Might not be true for everyone.

I like the look of it. Am I correct that the order the statements are in translates into the order things are evaluated in when the code is called?

If eg I edited it to be:

    do { l <- locations;
         w <- widgets;
         guard (l `hasInStock` w);
         s <- sprockets;
         guard (l `hasInStock` s);
         guard (w `isUsableWith` s);
         return (w,s,l); }
Does that force it to go through "location-first" and only check the w and s of (w,s,l) for compatibility if it has already ascertained that w and s are in stock @ l?

You'll be thrilled (lol) to know that the lambda-tuple syntax isn't in python 3 (!); it does make my examples more concise.

The argument in favor of set-notation being higher level is it's less specific (it doesn't explicitly provide a sequence of operations, just an outcome).

List comprehensions look like set notation but have an implicit procedural translation you have to keep in mind to use them well, so it's a toss-up.

I prefer map/filter/reduce when sequencing has large performance implications but for simple filtering or raw-data-shaping comprehensions read more smoothly.

http://books.google.com/books?id=RvY5BM0Xt1wC&lpg=PT367&...

I'm partially defending list comprehensions here and partially challenging you to consider the possibility that there are higher levels of abstraction out there than those employed by functional programming primitives like map and filter.

Level 0: for-loops with an explicit accumulator

Level 1: map + filter (!)

Level 2: ??? arguably an atemporal set-theoretic approach

In practice in python list comprehensions are a superior syntax for computing with multiple source collections.

(!) Really all you need is reduce

    map = lambda f,l: reduce(lambda h,t: h + f(t), l, [])
    filter = lambda f,l: reduce(lambda h,t: h + t if f(t) else h, l, [])
You'd be silly to implement them that way of course but know your tools.

I have a longer comment here that argues the opposite: list-comprehensions are only a syntactic pun or two away from set-builder notation, which is a higher level-of-abstraction (it declaratively states what it is) than map+filter (which specify a procedure to generate it, albeit at higher level of abstraction than a for-loop).

If you can put together a nontrivial usage of map+filter with at least three source collections that's more concise than the equivalent list comprehension I'll (figuratively) eat my hat.

It depends slightly on how you came to functional programming.

You can arguably trace Python's list comprehension syntax all the way back to setl, a "set-theoretic programming language", and the resemblance to mathematical set-builder notation is intentional; compare

- let B = { g(a) s.t. | a \in A and f(a) holds}

- B = [g(a) for a in A if f(a)]

If you're used to thinking in sets having to decompose into "maps" and "filters" is a speedbump; easy to do but nice to avoid.

Where list comprehensions really start to shine is making it comparatively trivial to pull from multiple source collections without a lot of ugly machinery:

    [{'widget':w,'sprocket':s,'location':l} for w in widgets for s in sprockets for l in locations if l.hasInStock(w) and l.hasInStock(s) and w.isUsableWith(s)]
...which is about where explicit map + filter start to become annoying. You can use:
    map(lambda i: {'widget':i[0], 'sprocket':i[1], 'location':i[2]}, filter(lambda i: i[2].hasInStock(i[0]) and i[2].hasInStock(i[1]) and i[0].isUsableWith(i[1]), itertools.product(widgets,sprockets,locations)))
...but to my eyes that is not only very ugly but just going by character count the # of characters given over to keywords (map, lambda, filter) instead of "what i'm doing here" is huge. Additionally use of itertools forces use of tuples for your intermediate values and thus the lambdas are gobbledegook until you get to the tail end of the statement and see that i[0] == widget, i[1] == sprocket, and i[2] == location. I could define some constants (WIDGET = 0, SPROCKET = 1, LOCATION = 2, etc) but now it's even longer.

It gets even worse if you try to be clever with the sequence of operations.

You might look at that definition and say lo! I can pre-filter out stuff not in stock at each location and make things more efficient. Naively you'd wind up with:

  map(lambda d: {'location':d[0], 'widget':d[1], 'sprocket':d[2]}, flatten(map(lambda l: list(filter(lambda p: p[1].isUsableWith(p[2]), itertools.product([l],filter(lambda w: l.hasInStock(w), widgets), filter(lambda s: l.hasInStock(s), sprockets)))), locations))) #nb must-supply-you-own-flatten-method
Under some circumstances that might be substantially faster than the previous approach. But compare the equivalent but you could have instead gone with:
    [{'widget':w,'sprocket':s,'location':l} for l in locations for w in [widget for widget in widgets if l.hasInStock(widget)] for s in [sprocket for sprocket in sprockets if l.hasInStock(sprocket)] if w.isUsableWith(s)]
So you lose a little flexibility in simple cases at in exchange for increasing the scope of what you can get away with as "readable" one-liners.

Yes, you did miscommunicate; even allowing for the miscommunication you're making an extremely poorly-considered analogy.

The kind of peer review that matters for purposes of scientific integrity is review by outsiders; eg, a paper is "peer-reviewed" when experts in the field not involved in writing it or conducting its research give it a going-over and see if it appears to hold up.

The kind of transparency that matters for purposes of scientific integrity is making data available as-is to outsiders, so that they can meaningfully replicate your results ab initio (or, perhaps, not!).

Neither Google nor Amazon conducts meaningful amounts of peer review in the scientific sense nor are they transparent in the scientific sense (nor should they be, the last thing I want is any old anyone seeing the raw data backing someone else's gmail account or search history).

So you're making a useless assertion in the context of the issue at hand: neither Google nor Amazon does much "peer review" (to my knowledge Microsoft in fact does to some limited extent with shared source and hiring 3rd party auditors for some important code chunks); neither is "transparent".

In this thread you'll find multiple people speaking from positions of actual experience working on large-scale endeavors of scientific computation who've commented at length upon their internal practices.

I'm not going to repeat what they've typed but if you read those comments you will see that at least those commenting here were in fact engaging in what you're calling "peer review" and "transparency" wrt their development practices; their reports match my experience concerning scientific computation with large annual budgets but I won't claim any authority for my anecdotal experiences.

I will close out by posting a protip here; you might benefit from it but it's not specifically aimed at you.

If a blog with a name like "chicagoboyz" makes a bold, sweeping, and somewhat shocking assertion about an entire area of human endeavor -- that it itself has no plausible claim to expertise in (it's an ec blog, not a large-scale computation blog, and no claim of direct experience was made that I saw) -- and you find yourself nodding your head and thinking "yeah, that sounds plausible", proceed to do the following:

- slow down, step away from the computer, and count to 20 backwards in greek

- ask yourself: do I have any concrete knowledge, at all, about the area this claim is being made? Any involvement in a project in that area, or business involving that area, etc.? (In this case: do you have any direct experience with large-scale computational efforts in science? do you know anyone who's been involved in such a project? anything beyond the flamebait du jour?)

- if you do have any concrete knowledge: great, you have at least some nonzero evidence base from which your initial "yeah, that's right feeling" may or may not be substantiated. Think carefully about what you already know and see if the "yeah that's right" feeling holds up.

- if you don't have any concrete knowledge: you've given yourself an awesome opportunity for self-discovery and personal growth. Clearly there's something that makes you want to uncritically believe this specific sweeping claim about some area about which you literally know nothing concrete; we generally consider who believe sweeping claims without evidence suckers, and we've found an area where your preexisting biases leave you a sucker, and therefore at the mercy of others. You might still have the right intuition about the sweeping claim, but at least take the opportunity to de-suckerify yourself on this front before drawing your conclusion.

The fit imho is that at least if you stick to numerics you'd have to try pretty hard not to be writing code in a way that could be easily translated into something that'd be runnable on a gpu (or larrabee).

This isn't really a new idea: http://portal.acm.org/citation.cfm?id=579.357248&coll=GU...

...(and gpus / larrabee etc. aren't solely vector processors, but the idea is apparent).

Most of the bulk numeric actions in an array language map pretty nicely to the data-parallel approach you need to use to take advantage of a gpu or larrabee (if it ever shows up); in particular take a look through this:

http://www.ncsa.illinois.edu/~gshi/LRBni_cheatsheet.pdf

...and see how much more straightforward it'd be to take advantage of (compared to SSE and so on). Your interpreter has to be a little more sophisticated (work has to be kept in units of 512 bytes) but seems much more tractable than previously.

Since this isn't a new idea there's history to learn from; it was previously the case that you'd get a speedup from offloading work to the vector units but not really a cost-proportionate one. But now if you look at the performance differential between cpus and gpus and their relative costs it starts making sense again.

Yeah I've not studied that interpreter so if that's your specific interest no luck sadly; rank is an easy idea but wouldn't surprise me if there's some trick to it in an implementation that short.

I think it'd be easier to untangle if you already had a working knowledge of the language but given the line-noisy look of J I can't blame you for trying the shortcut.

The interactive J labs are very good. You might also find the J for C programmers discussion of rank particularly helpful if you are looking at learning by understanding an implementation.

I figure the array languages will make a minor comeback soon what with gpus / larrabee / etc showing up on the horizon and what with more-versatile input devices showing up (making it easier to go back to funky symbols instead of line noise).

Please take this not as an insult but as invitation to offer help.

Rank shouldn't be something to get confused about; if it is you're probably overthinking it.

What did you find confusing about it?

Another point of experience: out of the box it is pretty poor if you work on the macintosh; by default there's nothing mapped to "command" and there're not enough "keys" on it to remap anything to command without giving up something else you probably need (like shift or alt or control).

You can work around this with a footswitch but it's another point to keep in mind.

Mine suffered a similar fate to yours: in a box, awaiting some future period where I have enough downtime to ride out a month or two of reduced typing speed to train myself.

If the article's really about catastrophe theory I'd better-motivate the catastrophe reference; dropping it in at the last second is pretty much a wtf moment for a reader not forewarned.

Motivate it in the abstract as like (but rephrased to match whatever style + diction constraints you're operating under):

Informally, a catastrophe means bad stuff happens all of a sudden; in the area of mathematics known as 'Catastrophe Theory' we have a more formal definition, but the same intuition applies, with a slight caveat we will come to momentarily.

Consider a car driving on an icy road. One minute it's handling smoothly, but then all of a sudden it starts drifting on the ice; the driver attempts to reacquire control but without success. The car spins out of control and lodges into a snowbank (thankfully everyone inside unhurt).

Our intuition says this is a catastrophe (perhaps a small catastrophe, but a catastrophe nonetheless): one minute everything was as normal, but then something terrible happened.

A catastrophe theorist would agree -- a catastrophe did just occur -- but here the caveat comes into play: a mathematician's catastrophe isn't the horrible crash into the snowbank. Instead, the mathematician's catastrophe is the loss-of-control, as in the moment during which the car transitioned from still-steerable to uncontrollably-drifting.

Catastrophe theory is, loosely speaking, the attempt to characterize and understand the fine structure of transitions between different states-of-operation (like the transition from steerable to drifting).

Thankfully not all "catastrophes" are catastrophes in the casual sense of the word. To provide a sense of the flavor of catastrophe I've prepared a much happier example of "catastrophe" involving racing boats (no crashes, I promise!) and as a bonus you'll also learn quite a bit about what makes boats fast or slow.

...then in the conclusion reiterate that the transition between the planing mode and the "normal" mode is the catastrophe (it's the road, not the destination, that matters).

===

Be careful with the use of "we".

It's good b/c it makes it friendly + inclusive but it makes things very jarring when of a sudden you drop to a 3rd person neutral point of view (eg: "Our truck is now a sports car." is more coherent with your overall turn than "The truck is now a sports car.").

===

Then the idea of planing arose. When planing a boat is no longer displacing water, it's skipping over the top. Some of its "lift" comes from the dynamic force of the water hitting the bottom of the hull, and so less water has to be forced out of the way. Less pushing, less bow wave, more speed.

...is clunky. You introduce the concept (planing) before you define it. When in the next sentence you do define "planing" you do so indirectly: does "planing" mean "a planing boat is skipping over the top of the water, instead of sitting amidst the water" or is "planing" some as-yet unspecified thing that has as a side effect the property that when a boat is planing it's skipping over the water?

Not enough time to try rewriting this for you but consider defining-and-motivating planing first -- "If we could get out of the water somehow we could go faster" (but more accurate and better-phrased) -- and then introducing the term "planing" second (We can, and call this "planing", but again better-phrased).

===

But let's ask the reverse (actually "converse") question. For a given amount of drag, how fast are we going?

->

Let's ask the converse:

If we have this much drag, how fast are we going?

I am agnostic on the platonic notion of patents but generally would agree that what we have now is sufficiently far from optimal that the status quo ought not be accorded much deference.

I think generally the little-guy versus big-conglomerate isn't a winnable battle; if you "level the playing field" the elephant stomps the mouse, and if you try and give the mouse a hand grenade you usually wind up giving the elephant a nuke. Thus where I'm coming from there's a background assumption that the little guy will always and everywhere be prone to get screwed, and the only sensible discussion is "how many different ways?" and "what're the systemic effects of such-and-such-policy".

Thus in that light switching to a presumption of invalidity isn't a panacea -- and has its own drawbacks, as any "solution" would have -- and is mainly addressed at mitigating the effect of junk patents, which is what your proposal is also aimed at.

In writing my response to your IBM scenario I found what seems to be one of the ways the 18-wheeler would drive through your proposal so I've put it below, before I get to explaining how the IBM scenario plays out under reduced-presumption-of-validity.

Incidentally, one area where your proposal would fail is that the IBM scenario. So you invent something novel (patentable under your regime). For this to be patentable it has to be a nonobvious combination of existing tech that's been around and commercially viable for some duration of time.

Now IBM looks at it and figures out some other components you need to actually implement it and files junk patents on those in order to force you to cross-license. IBM argues:

- the technology needed has been around for however long your proposal requires (or else your patent wouldn't hold)

- the overall product your invention enabled has been commercially viable for as long as required (or else your patent wouldn't hold)

- their patents are thus "nonobvious" (lol) combinations of preexisting technology that solve problems related to bringing to market a technology that for a long time has been commercially viable if brought to market

In theory you can patch this by tweaking the notion of commercially available or solvable to be sufficiently narrow, but in practice that's very hard language to draft in a loophole-minimized fashion; you'd think it ought to be the case that you can set up criteria that'd make it such that "mechanism for transforming lead to gold" ought to be easily recognizable as "unique" and commercially viable and "mechanism for absorbing shock from spontaneous-change-of-weight during transmutation from base metal to gold" isn't (eg: b/c it is only viable as part of a device that itself is commercially viable only due to your recent patent), but the more you start predicating your notion of "commercial viability" on "independent of any other invention" the more you undercut your likelihood of getting a patent at all.

In some ways your proposed criteria makes this worse: the kinda of stupid patents they'd look for are going to be super generic and useless (like the shock-absorber) and thus not sought after until they're needed to try and screw you out of your invention; thus their uselessness works in their favor (they won't be invented yet b/c they're so dumb) and being generic they have a pretty easy time proving commercial viability (b/c shock absorbers already have a lot of uses, and ours is better than others in some way...).

So you wind up falling back on the same-old pretty-useless nonobvious criteria to defend against IBM if they actively seek to encircle your patent with their junk. In theory they would potentially have a much smaller of junk patents laying around but without patches they'd have a much easier time rounding up junk patents once you got your non-junk patent.

OK. The validity thing plays out like this. In the IBM-threat scenario the threat is that IBM has a bunch of junk patents in technologies around whatever it is you patented, so to actually produce a product using your patent you need to get licenses from them or risk being sued into oblivion; they use the threat of that outcome to compel a cross-licensing agreement, and then run off and make the product you were going to make, leaving you in trouble.

Introducing the presumption of invalidity changes that negotiation slightly.

On the one hand, IBM's threats become a lot more empty; if you go ahead and build your device -- IBM's patents notwithstanding -- then they might well sue you but they'd have to prove their BS patents are not-BS before the trial gets very far, and if they're actually BS then they probably can't get them proven not-BS (judges self-select to take directions about stuff like "presumption" very seriously).

On the other hand say IBM goes and makes a product incorporating your invention, and leaves it up to you to go and sue them. Things here are a little less clear, which is why it's not really a panacea (but what is?). It's easy to say something like "if it's really a good patent it'd hold up in court and you'd be fine", but with any change from the status quo predicting how things actually turn out is a little tricky.

So at the margins the lone-wolf / little-guy inventor has a harder time winning an infringement suit b/c they have to prove their patent is invalid; it's thus a systemic tradeoff between far less "bite" for BS/junk patents in exchange for at the margins having some patents wind up practically unenforceable.

The compare/contrast wrt to your proposal is that your proposal leaves patents harder to get -- thereby cutting back on the BS paten threat -- but doesn't touch the strength of issued patents; the presumption of validity tweak is intended to undermine the utility of issued patents and not have too deleterious an effect on strength.

As far as validating your own patent -- if it held up in court already it's known-good. Some variants of this proposal include a notion of patents-plus (essentially, patents subject to extra scrutiny) available for patents undergoing heavier scrutiny; I'm not a fan of that for a number of reasons, but it's another option (essentially pay extra to get more research done and have your patent enjoy stronger presumed strength).

It basically trades where we are now -- too easy to get junk patents and use them to extort money from productive enterprises -- for a setup where the junk-patent-extortioneering becomes much harder, but at the expense of leaving some lone-wolf holders of valid patents less able to make use of their patents then they are under the current situation.

There are some counterbalances you can throw in -- eg, jacking up the infringement penalties => if you DO win against IBM it'll cost them a ton more money, thereby keeping the expected outcome in the same ballpark despite the reduced likelihood of the little guy winning -- but you can't get around the marginal effect of pushing some patents into the unenforceable range.

I tend to think that's probably an improvement over the current situation, but opinions can differ.

I'd say you're slightly misreading the point of the patent system; I'd argue the underlying "point" is what it says it is in the constitution -- to promote the progress of the useful arts + sciences -- which isn't exactly the same thing as "come up with ideas that people wouldn't otherwise come up with".

EG: one aspect of the patent system is that it promotes invention of work-around, "me-too" inventions to get around patent restrictions (eg: PNG vs. GIF, for a computer example).

I'd argue that's more often a bug than a feature: worthwhile inventions would happen anyways, and engineering-around-a-known-solution is far more often a deadweight loss than a benefit to the economy as a whole; there many others (mainly members of the patent bar) that'd argue that such work-arounds are a feature, as they promote "new invention" that otherwise wouldn't happen (since you'd just use the known-good solution).

I'm sort of assuming you usually see this "my way" on this issue; if you do, then framing it as "think of stuff that wouldn't be invented otherwise" doesn't give you much to stand on (as clearly most workarounds wouldn't be thought of without the patent system...).

Sticking with the promotion-of-progress language gives you a much firmer frame for your arguments.

Your framing also is making you overlook the importance of disclosure in the patent system; it's not an accident that a patent not only describes what it does (separate alumina from bauxite) but also how it works (supposedly in enough detail that someone else could implement the invention by reading the patent, though in practice there's a strong incentive to obfuscate that as much as you can get away with).

The argument here is that this promotes the progress of the useful arts and sciences as it makes the knowledge underlying a particular invention available essentially immediately -- as soon as the filer rushes to the patent office -- allowing work on derivative inventions to start immediately, thereby increasing the rate at which new ideas are come-up-with, etc.

So while on the one hand you're kind-of right -- patents that have lots of simultaneous inventors probably are too obvious to be useful -- you've not addressed the real thrust of the delay issue (which I admittedly could have made clearer):

- for "good" patents in your system there's an incentive to wait as long as possible (as the longer you wait the greater the odds your patent is valid); this'd be especially true for the ones that don't have much to worry about from co-filers b/c they're legit inventions

- this means that the rate of disclosure of the genuinely-novel inventions would be expected to go down, as ceteris paribus there's more incentive to delay filing and therefore delay disclosure of the underlying ideas

- so the calculation what is the effect on the rate of progress of the useful arts + sciences under your proposal is roughly ("increased progress due to lack of bogus patents no longer gumming up the works") - ("reduced rate of disclosure of truly novel inventions"), and imho the latter term would be quite substantial and would need more arguments to justify it

The simpler hack to get what you want is removing the presumption of validity (too lazy to check if I mentioned it already or not); this would change the patent-infringement workflow from:

- file lawsuit; patents assumed valid until (or if) defendant successfully challenges every relevant claim in every relevant patent

to:

- file lawsuit; filer must successfully "validate" each relevant claim in every relevant patent, and only then will proof of infringement imply damages are merited

...and this can be phased in in ways that'd not be crazily disruptive (eg: phased introduction and/or the presumption of (in)validity is on a per-area basis, so pharma is presumed valid but not software).

Too vague to be helpful; only appeal is a seemingly-more-objective test for non-obviousness (nonobvious iff prerequisites developed AND not solved in previous 10 years), but vagueness of relevant terms negates any putative step forward in "objectivity". Also provides incentives to slow down the rate of innovation and has potential to be self-defeating.

I won't harass you about the vagueness as I think that's pretty obvious (do you really want either federal judges or, god forbid, a jury of citizens to be the judge of what is "commercially viable"?).

The incentive to slow down comes from your 10-year rule: if I have a good idea that is economically useful, ceteris paribus the longer I wait to patent it the likelier I am to actually get an enforceable patent (b/c the prerequisites aren't getting any younger). Now obviously in some cases there will be concern that rivals or competitors will jump in front and patent it instead, but in many smallish fields there really aren't that many people working on the same topic at the same time and what competitors there are will all be operating under the same overall incentive (and thus will themselves have some incentive to delay as long as possible).

So the incentive to file for a patent immediately is the same as under the status quo -- make sure you get out ahead of competitors -- but you add in a countervailing incentive to delay that the present system (for all its faults) does not have.

This is particularly egregious wrt brand-new technologies (like, eg, a transistor or the laser): anything making use of a laser or a transistor wouldn't be patentable for ~10 years after the development of that technology. This may help prevent some stupid patents -- land-grab stuff around doing stuff with a laser -- but it also means that any invention that's mostly-done but missing something (like, eg, it'd work if only I had a source of coherent light) now has a 10-year time out on it, also, as it won't have been solvable for 10 years until 10 years have passed from the introduction of the missing piece.

You could try patching your solvability criterion to work around the "missing piece" phenomena but if you put a tiny loophole in next thing you know people will be driving a caravan of 18-wheelers through it.

Your proposal's criteria is also at the margins somewhat self-defeating, especially in the case of a trial in which a patent's validity is called into question.

The person defending it basically has to defend the patent by minimizing its novelty: all the constituents have to be old + well-understood and so on. So the ideal patent is minimally-inventive: it takes solves a known problem using well-known stuff in novel combination...but not too novel, as something too novel runs the risk of exposing you to arguments that the problem you solved wasn't solvable b/c solving it required too many of your own innovations.

The person attacking it has to attack it by maximizing its novelty: claim that the problem wasn't solvable for as long as you're claiming b/c it depended on sub-inventions and so forth; rather than being a minimally-non-obvious recombination of existing technologies you're actually inventing stuff, you see, which works against your patent's validity.

The 10-year period + commercial viability argument cuts both ways: on the one hand if it was solvable for awhile and was commercially viable you can use that as evidence for non-obviousness, but on the other hand your attacker can use the same facts to claim it either wasn't solvable before you went and invented stuff, wasn't actually commercially viable, or some other reason; you're making an overbroad assumption about what seems like reasonable assumptions for other people to hold about the invention process.

So you wind up with inventors forced to downplay the inventiveness of their inventions -- and shy away from overly-novel areas of inquiry -- and attackers overplaying the inventiveness of the inventions for which they hope to invalidate the patents, which scenario is comical but unproductive.

In hindsight the present situation is pretty predictable: as the # of goods produced increases and the amount of specialization increases the value supplied by the intermediary network ("the financial system") increases.

The way the financial system is currently "architected" (a strange term, but I'll use it) it has as a class an inordinate amount of negotiating power vis-a-vis everyone else (!), and thus is able to capture much of what ought to be consumer and producer surplus.

As much of the value it adds is due to network effects just going to a gold standard (which is a popular cure-all on the internet) wouldn't change much, even if you thought that was a good idea; there's still the same tremendous problem of coordinating trade in the same complex, highly-specialized economy and the central switchboard is still ideally placed to extract most of that value.

The easiest-to-envision solution is to forcibly unbundle the basic storage-and-transmission of credits between accounts (full-reserve checking accounts, basically) and run that infrastructure as a public utility (a handful of mainframes in the fort knox). Let the private sector sell value-added services on top of this, but don't leave the basic infrastructure of value-exchange in the hands of the private sector, who will retain the ability to hold the country up for ransom.

It's an easy solution to envision but it's hard to see much happening; it is too radical a shift to go down easily (and all that surplus value captured funds a lot of lobbying) and it too closely resembles socialism and other bugaboos to be an easy sell to the public at large.

(!) Where we are now is pretty analogous to having the local power company -- which provides necessary services to its area of operation -- also involved in speculative ventures that backfired enough that its continual operation is threatened; having the ability to turn the lights off would naturally give the local power company a lot of leverage negotiating for a bailout.

Suppose that the "too big to fail" banks were allowed to fail, and there was temporarily a severe disruption in the banking system. How would you propose that federal, state, and local law enforcement and other "essential services" get paid? With cash -- dangerous and risky? With checks -- while the banking system isn't reliably working? Would you trust them to work without pay for very long?

Generally overconfidence in our present abilities isn't conducive to stimulating new research.

I mean: I give you as much workup on the brain of an unknown individual as you care to have (fMRI, scans, dissection, whatever you want).

Can you detect which languages, if any, the person speaks (or spoke), with any robustness?

Can you detect if the person ever saw an ocelot in person?

Can you detect which sports team, if any, they like or liked to root for, or which instruments, if any, they played?

For most sections of the brain the level-of-detail at which functionality is decoded is still very primitive and coarse-grained. The reason god-of-the-gaps arguments have so much traction is b/c the gaps are still so very large.

Thanks for the response, I do appreciate it. I wasn't aware of how active lojban still is (and it's much more accessible to to get information on thanks to the internet).

I should point out that I'm fairly familiar with the general range of opinion in the linguistics community (as an undergrad I did dual math / linguistics, which made me at that time quite the rara avis, though it's more common now apparently).

Generally I don't give much credence to the idea of semantic primes (at all, not just in some pragmatic sense) but for stuff like spatial relationships + tenses (+ aspect, mood, etc.) it'd seem not an impossible undertaking (do enough reading in linguistic typology and you start seeing enough "repeats" to think such an enumeration might be possible).

After going through a bit of the grammar and the vocab list on wiktionary it seems like you'd have constant problems with synecdoche, which'd bother me (but perhaps only me, and it's not as though natural languages aren't riddled with similar problems).

I've walked away from this with a much stronger sense of the sense in which lojban is attempting to be a logical language, thanks for your time.

It's heartening to see substantial effort put into engineering language; good luck with your efforts.

If dolphins have that much personality there's not much guarantee any two dolphins would act the same way in the same scenario.

Additionally, given that dolphins can apparently teach each other behaviors the entire batch of dolphins they've got in their research tank is contaminated by the first dolphin.

Designing experiments to determine if your test subjects are smart enough to mess with you is hard and it's harder if they all live together and gossip between sessions.

Thanks. I figured grammatical # as such would be discarded as unnecessary but the notion of plurality raises semantic issues that natural language sidesteps by ambiguity.

Disclaimer/Personal Background (trying to be brief): I've often been told I've got an unusual cognitive style (for lack of better term) and I've often felt very much as if there's an impedance mismatch between how my thoughts are structured and how language operates; in essence, at the word-or-sentence level everything I hear or read is very polyvalent and vague, and only take on a concrete meaning to me if I get multiple paraphrases of it...it's putting all the variants into superposition and seeing which parts reinforce or cancel shows me the contour of the actual meaning (which itself is not necessarily ever actually "represented in words" so much as "gets the outline of its semantic boundaries painted").

In the abstract this leaves me with an interest in the idea of something like lojban but very mixed initial reactions: it's possible an artificial language with more-precise meanings would eliminate my need for doing verbal interferometry across multiple paraphrases but on the other hand I have a lifetime's experience feeling very uncomfortable without tons of redundancy and repetition-with-alteration, which seems to be what lojban is trying to eliminate in its use.

Too much info, I'll stop there.

I do have two more questions if you have time.

#1 is historical: what's the process by which the core sets of things like spatial relationships or tenses or shapes or so on came to be enumerated?

EG: if I were doing a language in this form I'd go through all the languages I could get my hands on and try to get good lists of all their fundamental categories (eg: spatial prepositions and "classifiers", like you have in swahili and chinese (+ languages with heavy chinese contact) (cf: http://www.jstor.org/pss/413103 ) and then try to factor them into semantic atoms. I'd consider this approach bottom-up (see what's out there, and then try and simplify and unify them) and contrast it with a more top-down approach (trying to derive a finite set of spatial relations ab initio via pure reasoning); it'd also be a good set of "unit tests" for your final set of core concepts, making sure that none of these words' senses are not really expressible in terms of your base concepts.

How did the lojbanists derive their tenses / spatiotemporal prepositions / etc.? Is there a good "history of the design of lojban" that speaks to this?

Question #2: at a practical level how would you decompose "There are dogs in the kitchen" into lojban?

If I had to break it into predicates it'd probably be the conjunction:

- CONTAINS("containment-type T","kitchen","entity collection E")

- T ~ whatever containment type you have that is ~ "contains within its spatial bounds -- but not structurally -- for an indeterminate time period"

- COUNT(E) > 0

- ENTITY-COLLECTION-TYPE(E,X), where X ~ "collection treated as collection due to spatiotemporal circumstance and descriptive convenience" (EG: E is an entity collection b/c there are label(s) they all share, namely being instance-of dog and contained-in-the-kitchen in the same way; there's no assertion of any other source of entity-identity beyond the circumstances this utterance is describing; contrast to say "baseball team" or "deck of cards", etc., which are entity-collections with a more-persistent and "intentional" identity)

- forall e in E IS-INSTANCE-OF("instance-of-type IoT",e,"dog")

- "instance-of-type" ~ whatever instance-of you have that is ~ "is a concrete instantiation of an abstract type not otherwise specified (eg: an actual 'dog', not 'Pomeranian')

- + some temporal modifier to explain like "the described circumstance started before I made this utterance and I do not think it has ceased, yet"

...but I'd assume some of the intended distinctions are usually left implicit or inferred; what's a good lojban decomposition?

Thanks for the sentence, that's certainly nontrivial enough (I was just trying to dodge 2-3-word-sentences like "jesus wept" or "i like milk", which rarely show anything interesting at the grammatical level).

Not-mocking: there's an apparent lack of number ("thing(s)", "I (or we)"). Is it closer to true that:

- the grammatical root of this apparent lack of # is shared between "thing(s)" and "i (or we)"

...or that:

- "thing(s)" is a gloss of some word that's ~ "specific things not specifically specified"

- "I (or we)" is a gloss of some word that's ~ "who I speak for" (or some other deictic term that's ~ first-person but otherwise underspecified)

...or to some other possibility? Additionally: Given that it's a designed language I'm curious about what underlying intent (whatever it is that explains why the answer is what it is, instead of being something else).

(Disclaimer: wiki's lojban articles have resolved a lot of my other questions, but before I asked you I'd only looked at lojban's wiki's articles, which are mostly unhelpful.)

Overall there's nothing I disagree with in what you wrote.

One thing worth point out though is that affiliate marketing is a huge force-multiplier for the company selling the product, which is why it exists in the first place.

If you have software (or whatever) you're trying to sell and you don't do an affiliate program your advertising budget is basically limited to your cash on hand.

If you run an affiliate program you can potentially get other suckers to spend their resources advertising your product on speculation; you only pay those marketers who successfully make sales, and get the other advertising for free.

A cute corollary is that you have to be tracking what they do tightly enough that you can reverse engineer the successful affiliates' strategies and self-implement them.

So affiliate marketing isn't going anywhere, but outside of the inevitable outliers the economics of it are such that the major profits will be made in scammy products, and thus the bulk of successful affiliate marketers will be marketing scams or worse.

A major change is that good search algorithms or giant server farms could become sufficiently useless that a remote search engine makes no economic sense.

I don't see that happening in the near term but there are sci-fi scenarios in which it might happen; I'll sketch them so the pattern becomes clear.

EG:

- user's local storage and local cpu / throughput goes through a quantum leap and most users most of the time have locally cached copies of any content they might find useful, and the cpu power to search it all efficiently

- some quantum leap in bandwidth and other IT infrastructure means you can scour large chunks of the web directly in a short time period (eg: if everyone had terabit fiber-to-the-home and backend infrastructure were built out enough you could just download entire websites and full-text search them in the time it takes now to search @ google)

- some quantum leap in "software agents" and safely-executing remote code comes to pass and users send out long-lived, virus-like agents that constantly scour-and-index-the-web-for-them (executing at the site of the content host

This is basically a sci-fi "what-if" but as a thought exercise it gets the point across: right now it makes sense to have a centralized spider-and-archive-and-index-and-rank facility b/c the web is so huge and its pipes are so tiny compared to the # of end users and their individual computing capacities; a sufficiently radical shift in end-user capacities would make it moot. All probabilities for the above I'd put at .01% or something similarly lame.

Weaker versions of the scenario include anything that reduces the use of the web and consequently reduces the need for search services:

- next-generation rich-client driven chat + forums + social-networks become the dominant areas of internet activity (with the web relegated to low-grade entertainment, reference material, and shopping); users don't need external search engines for these activities and the service-operators' databanks are deliberately opaque to conventional spiders

- despite all the naysaying the semantic web takes off in some fashion, with enough widely-used, useful-enough ontologies and so forth that user-run agents and user-run spam filters and user-run relevance+credibility assessors can auto-navigate the web to find what the user is looking for without passing through a conventional search engine

...etc., which I'd move up to .1% or so likelihood.