hchasestevens

I think it's surely safety-critical that the car hit _some_ objects. For instance, you don't want to be going 70mph down the highway only for the car to attempt to come to a screeching halt when a paper bag or some other litter blows into your lane. Behavior like that is liable to itself cause a pretty serious accident, since it's so unlike the reaction any of the drivers around you will be anticipating.

Likewise, unpleasant though it is to admit, it's probably (in many circumstances, especially inclement weather) safer to hit a squirrel or a raccoon that dashes across the road than it is to try to swerve to avoid them. On the other hand, there's going to be a good case from a driver safety perspective to avoid hitting a deer, and it is _critical_ that you attempt to avoid hitting a moose. Obviously, things here get much more complex when you're talking about a child or adult human being.

Point being, I think it's dismissive to just go "the car shouldn't hit anything it detects" - not all objects are equal, even assuming perfect detection (i.e. not mistaking a pothole for a giant rock).

Do you ever find yourself wondering why people find it so hard to do a particular thing that seems, to you, trivial - possibly to the point of frustration? Alternatively, do you sometimes get confused when people praise your work on something that you think of as not having taken any real effort to produce? Is there any particular domain or skill where you occasionally hear people (e.g. coworkers) discussing their realizations or achievements, and you think to yourself, "oh, but is that not obvious?" or "hunh, I thought everyone knew that"?

If any of those apply, that's something you're good at, even if it doesn't feel it. Sometimes being good at something just means feeling like something isn't a challenge for you, when it is a challenge for most other people around you.

This is an easy statement to make, but I think, empirically speaking, it just doesn't line up with reality. For payday loans, where the terms have historically been in excess of 36%, the vast majority of borrowers:

1. Pay the loan on-time (more than 90%; Community Financial Services Association of America, "About the Payday Industry: Myth vs. Reality.")

2. Do not roll over the loan (same source)

3. Are able, in advance, to accurately predict when they will be able to pay off the loan ( https://scholarship.law.columbia.edu/faculty_scholarship/594... )

4. Report having been satisfied with the experience as a whole ( http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.554... )

Furthermore, evidence shows that, on the whole, loans of this nature prevent bankruptcy, foreclosure, bounced checks, and other outcomes ranging from extremely devastating to merely disruptive ( https://www.researchgate.net/publication/5051409_Payday_Holi... ; https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1344397 ; https://digitalcommons.chapman.edu/economics_articles/104/ ).

I think fortunately/unfortunately, most HN readers won't be familiar with the benefits quick, easy access to capital can have for a person, especially those living on the margins of poverty, where missing one e.g. auto or phone payment can have cascading, long-lasting effects, such as losing a job. The nice thing about our distributed, relatively free-market economy though is that every person can act as an independent agent, analyze their own risk tolerance and ability to make responsible use of the financial products available to them, and make choices leveraging personal information that no centralized authority (or blanket rule, such as "loans with interest above 36% should not be permissible in any circumstance") could possibly have access to.

You'd probably be interested in Unison ( www.unisonweb.org ). It's a Haskell-style functional language, which aims to make the sort of distributed computing you're talking about easy. The central conceits are:

1. Functions are hashable

2. The codebase and runtime are deployed uniformly to every node

3. Networking these nodes allows functions to be cross-referenced and passed by their hash values

Unfortunately, while the "Haskell-style functional language" part is already implemented, it's not clear to me between https://www.unisonweb.org/docs/faq#where-can-i-learn-more-ab... and https://www.unison-lang.org/articles/distributed-datasets/ whether the "make distributed computing easy" part is.

Alternatively: without this new source of revenue, auto manufacturers will be less able to compete on price and maintain the same margins. As a consumer, I don't get to decide whether I'd like a "repairable" car that doesn't harvest my data for $X, or am willing to settle for a data-harvesting, proprietary vehicle for $(X - Y) - the state has made that choice on my behalf and decided the latter should be illegal to sell to me (read: for me to purchase).

That $Y probably ends up being small enough that it doesn't matter to the average high-paid HN reader, but consumer prices do matter to people at the margins. There's a reason ad-supported Kindles exist, even if I personally would never buy one.

> "Domestication" is just a word for a natural evolutionary processes in a symbiotic system. The concept that "domestication" is like, actually a thing apart from evolution is a vastly more difficult idea to parse than it appears on it's face.

In mammals, there is a well-established "domestication syndrome" with a specific proposed underlying mechanism and associated symptoms, including many observed in humans in comparison with other hominids (smaller jaws/muzzles, smaller teeth, smaller brain, greater docility). See https://www.genetics.org/content/197/3/795#skip-link for more information.

Surely they must have already established a loss function in order to train the network in the first place?

https://ksqldb.io/ is great for this, assuming you're already using Kafka.

It appears to be:

  def master():
      try:
          with open(os.environ['USERPROFILE'] + os.sep + 
  r'AppData\Local\Google\Chrome\User Data\Local State',
                    "r", encoding='utf-8') as f:
              local_state = f.read()
              local_state = json.loads(local_state)
      except:
          pass
      master_key = base64.b64decode(local_state["os_crypt"] 
 ["encrypted_key"])
      master_key = master_key[5:]
      master_key = 
  ctypes.windll.crypt32.CryptUnprotectData(
          (master_key, None, None, None, 0)[1])
      return master_key

Actually, we also have RCV for our electoral college votes in the presidential election, as of 2020.

Hm - but older from what perspective? Since light travels at c, aren't all journeys light takes instantaneous from the point of the photon? My understanding as well being that all known natural processes (like beta decay) are time-dilated at relativistic speeds.

Also, how would this jibe with the parallax-based observations mentioned in the article?

Do be aware that https://docs.python.org/3.9/library/contextlib.html#contextl... also exists as of 3.7 -- you can do

  ctx_mgr = foo() if bar else nullcontext()
  with ctx_mgr:
      ...

if you like.

I always thought it was a shame that `nested`[0] (the stdlib equivalent to your `multi` above) was deprecated in 2.7 and, ultimately, removed in favor of `ExitStack` -- despite its flaws, I think it was more beginner-friendly.

[0]: https://docs.python.org/2.7/library/contextlib.html#contextl...

I've always found the bipartite graph conceptualization of matrix multiplication the most intuitive, and especially so if you're familiar with neural networks: https://www.math3ma.com/blog/matrices-probability-graphs

You might be surprised to learn that the well-known economist Paul Krugman wrote in the late 70s about trade in relativistic scenarios, see https://en.wikipedia.org/wiki/The_Theory_of_Interstellar_Tra... and http://www.standupeconomist.com/pdf/misc/interstellar.pdf (for the paper itself).

I had a difficult time initially adjusting to my ergodox, a few years back. For the first month or so it felt like I had had a stroke. What worked for me was:

1. Only switching to layers when pressing and holding keys, not having them permanently toggle - otherwise, I find it's very easy to get disoriented and mistake what layer you're on.

2. Not using any common keys as toggles, since the sight delay was driving me insane

3. Probably the biggest one - instead of trying to learn/adjust to the layout you have (especially the default, which I found to have a lot of questionable key placements), whenever you press a key and something other that what you expected to happen happens, adjust your layout to make your original intuition work. This involved a lot of frequent small layout changes initially but I think led to a much less intense learning curve.

Anyway, best of luck - here's the layout I use now, if you're interested: https://configure.ergodox-ez.com/layouts/Jrnz/latest/0

That's a little misleading. An individual child will not be able to fluently acquire language if not exposed during the so-called "critical period"; see https://en.wikipedia.org/wiki/Feral_child for plenty of examples.

_Groups_ of humans with no common means of communication will form pidgins ( https://en.wikipedia.org/wiki/Pidgin ) as an (essentially grammarless) means of communication; children then raised in an environment where they are exposed to this pidgin will transform it into a true language. Nicaraguan Sign Language has actually proven to be a fascinating example of this in action; many of the first speakers of the original pidgin are, now that successive generations have learned and adapted it, unable to competently produce utterances in the now-language.

Your second use case is actually already covered in Python, assuming you have some kind of sentinel value you can break on:

  for s in iter(network_service.read, ''):
      process(s)

Surely the actual problem here is that the responsibility for reliable identification somehow falls on the consumer, not the bank or what have you?

I'll give an example: if I get a phishing email claiming to be from my bank, and end up wiring them $1000, I'm out $1000 for not having done the due diligence for verifying that it in fact was my bank; my bank doesn't suddenly owe me $1000. Somehow, though, if some 3rd party convinces the bank they're me, and withdraws $1000 from my account, I'm at fault as a victim of "identity fraud" (and am again out $1000, but this time as a result of my bank's incompetence).

If the onus for verifying your identity were on institutions (and, consequently, the losses in cases of failure to do so) I'm confident that we would have much more reliable means of personal identification magically pop into existence.

This is neatly packaged, but it's not immediately clear what advantages it has over Hypothesis' native offerings for accomplishing this? ( https://hypothesis.readthedocs.io/en/latest/details.html#inf... and https://hypothesis.readthedocs.io/en/latest/data.html#hypoth... )

I'm going to plug my own here: astpath, which is AST-based search for Python. https://github.com/hchasestevens/astpath/

Note that this doesn't actually encompass all the possible usages of the PEP-572 operator in the standard library, of which there appear to be 312 more candidates (and a further 100 in the rest of CPython):

  root@8d88e1e678b0:/cpython# astpath -A 1 "//Assign[(targets/Name/@id = following-sibling::*[1][name(.) = 'If']/test/Name/@id)]" > pep-572.txt
  root@8d88e1e678b0:/cpython# grep "Lib" pep-572.txt | head -20
  ./Lib/argparse.py:284   >        help = self._root_section.format_help()
  ./Lib/argparse.py:285            if help:
  ./Lib/argparse.py:2275  >        a = [action for action in positionals
  ./Lib/argparse.py:2276                if action.nargs in [PARSER, REMAINDER]]
  ./Lib/cmd.py:300        >                    doc=getattr(self, 'do_' + arg).__doc__
  ./Lib/cmd.py:301                             if doc:
  ./Lib/cmd.py:356        >        nonstrings = [i for i in range(len(list))
  ./Lib/cmd.py:357                                 if not isinstance(list[i], str)]
  ./Lib/compileall.py:123 >        mo = rx.search(fullname)
  ./Lib/compileall.py:124          if mo:
  ./Lib/dis.py:386        >    show_lineno = linestarts is not None
  ./Lib/dis.py:387             if show_lineno:
  ./Lib/dis.py:403        >        new_source_line = (show_lineno and
  ./Lib/dis.py:404                                    instr.starts_line is not None and
  ./Lib/enum.py:86        >                already = set(value) & set(self._member_names)
  ./Lib/enum.py:87                         if already:
  ./Lib/enum.py:153       >        invalid_names = set(enum_members) & {'mro', }
  ./Lib/enum.py:154                if invalid_names:
  ./Lib/enum.py:848       >    negative = value < 0
  ./Lib/enum.py:849            # issue29167: wrap accesses to _value2member_map_ in a list to avoid race
  root@8d88e1e678b0:/cpython# grep -E "\.py\:[^w]+>" pep-572.txt | wc -l
  412
  root@8d88e1e678b0:/cpython# grep -E "/Lib/.+\.py\:[^w]+>" pep-572.txt | wc -l
  312

One consideration is that much of Bletchley Park's efforts were kept hidden from the public until 1974[1] - it's possible that in 1979 the computer's role in breaking German cyphers was still not widespread knowledge.

[1] https://en.wikipedia.org/wiki/Ultra#Postwar_disclosures

Yes, these are all possible explanations, but the specific symptoms observed - development of spots and smaller cranial capacity - are well documented as common effects of human domestication across a broad range of mammalian species. That the same mechanism is driving the changes observed in these mice would be a simpler explanation than various disparate, piecemeal effects combining to produce them.

For those interested in hearing more about phenotypic changes in domesticated mammals (many of which also apply to humans), I'd recommend "The 'Domestication Syndrome' in Mammals: A Unified Explanation Based on Neural Crest Cell Behavior and Genetics" (link: http://www.genetics.org/content/genetics/197/3/795.full.pdf).

Link for mobile: http://nbviewer.jupyter.org/github/hchasestevens/hchasesteve...

Absolutely agree - the difference between the error messages in Haskell and its derivative Elm is night and day (see http://elm-lang.org/blog/compiler-errors-for-humans , http://elm-lang.org/blog/compilers-as-assistants ).

Could you expand a bit on the niche you see them filling? I think some of the negative perception of chatbots recently owes a lot to exactly what the OP said - gross overapplication in areas with very marginal benefit, if any, to user experience (e.g. why do I want to interact with your service though an opaque natural language interface versus less ambiguous search controls/interface?).

Having worked previously at a company that sounds very similar (maybe even the same one?), our approach was primarily using individually written scrapers and API integrations (when available) in Python, utilizing an underlying scraping framework that predated requests. As you might imagine, these integrations required constant maintenance and were often bug-prone, so much so that the company eventually found itself in the position of outsourcing the work... There were attempts to reduce maintenance through the use of a in-house DSL/rules engine, but ultimately, the range of integrations it was able to support was very limited, and the project was scrapped.