The Land Tenure System of the United States
spatial.maine.edu1 pointsby frig0 comments
--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. 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? 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. [{'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. 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.
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).