asterisk_
Joined 8 years ago
Karma
43
Submissions
15
Member since
Jun 2
Recent submissions
Comment · 1 year ago
Comment · 6 years ago
> Il numero medio di patologie osservate in questa popolazione è di 2.7 (mediana 2, Deviazione Standard 1.6)
It seems the above poses another question; is diabetes just confounding other underlying condition(s)?
Further, if most of the patients suffered from type 2 diabetes, it would likely correlate with older age in which case higher fatality rates are to be expected.
I was unable to find this info publicly available, but diabetes being one of the "2+ underlying conditions" seems probable.
Comment · 6 years ago
This doesn't seem too controversial of an opinion, haven't small modules already been at the core of a Unix philosophy? Once usage patterns emerge, these smaller libraries are composed into frameworks which ultimately build end-user applications.
The entirety of engineering is premised upon leveraging powerful abstractions; cf. the reason we're not still coding via electric charge.
Edit: To expand on the analogy: "A two-person startup already uses twenty-eight other tools" [1].
Comment · 6 years ago
Even so, what's the worst-case scenario in biasing towards lower speed and
assisting your vision system with a knowledge base?
You perform the task of vision 100% of the time driving. From a purely probabilistic standpoint, even assuming highly accurate ML, the relatively infrequent database updates still make for a sensible prior.
This is somewhat adjacent to what Gary Marcus has been arguing, and I think it makes a lot of sense; there seems to be no compelling reason to rely exclusively on primitives (i.e. vision) when good priors are easily accessible.
Comment · 6 years ago
Interesting; the article resonates well. Thanks for taking the time to share.
Comment · 6 years ago
I personally didn't encounter any problems whatsoever installing a clean i3, but for anyone searching a batteries-included version of the window manager I've heard a lot of good things about i3-Manjaro (cf. 30-minute review on Youtube [0]).
Comment · 6 years ago
Interesting, I haven't heard of (1) and (2) but as I've mentioned Roam Research also seems a good take on this idea. From my (recent) experience it appears their app is not yet stable enough to use as a daily driver, though. Notion [0] seems like a more mature version based around similar principles.
As for idea rediscovery I'm personally happy with the setup I devised for myself so I can only suggest trying to emulate something similar. If you're interested, some guiding principles I follow:
1. My note-taking app (Vim, but could also be the browser or anything else) is constantly open in the background, and I have a keyboard shortcut to show/hide.
2. I maintain an index document of sorts (with TODOs, recent thoughts, outward links). This is frequently updated and I don't think too much about categorization.
3. Either Markdown `#` headers or `*` are mapped to Vim folds, which allows me to use `zm` and `zr` to quickly expand and collapse document outlines.
4. Treat tags as a "brain-dump". Just quickly come up with some keywords before starting to write the note. If you do that, I find even simple tools such as ctags and grep immensely help with future rediscovery.
5. Backups are on GitHub so I have the double convenience of both tracking document history, as well as being able to access all notes from mobile.
It's served me well thus far; most commercial note-taking apps will handle (4) and (5), while (1) is easy to resolve (e.g. AutoHotkey on Windows) so there's probably no need to make drastic changes to your setup if you wish to try it out.
Comment · 6 years ago
The article seems to be a bit light on details for an "overview" of GNNs.
It's an area I've recently been researching and they do seem to be gaining a significant amount of traction. If anyone is interested in additional reading material, I can suggest the very recent GNNs: Models and Applications (slide deck available on the website) [0].
There is also a fairly comprehensive GitHub repo on [1], though I personally haven't given it a detailed look yet.
[0] http://cse.msu.edu/~mayao4/tutorials/aaai2020/
[1] https://github.com/benedekrozemberczki/awesome-graph-classif...
Comment · 6 years ago
Note-taking seems to have gained popularity on HackerNews over the past few weeks (or my attention has been biased towards these submissions, at least).
I've long been interested in the domain of "personal knowledge engineering" and this clearly seems a common thread within our community. As a brief overview of the "SOTA:"
* Emacs and Vim users skew towards Org-mode or Vim wiki.
* Roam Research is sort of a recent web-based alternative.
* There's a lot of competition in the domain of fully-fledged note taking apps. Evernote has long been viewed as a king of note-taking but lost its edge over time (bad editor, bugs, lack of attention to their users). Memex seems to be gaining popularity even though their software looks somewhat buggy at the moment.
* Otherwise, people naturally develop their own (similar) systems. I myself have independently developed a custom-made Vim wiki before starting research into this topic. It basically consists of a few grepping/Vim aliases to search/create Markdown in a `~/.notes` folder, backed up to GitHub. `mod+-` is bound to an i3 sratchpad where Vim is constantly open to `~/.notes/index.md`. This drastically reduces friction when making new notes.
In any case, seems interesting that a lot of the personal note-taking systems have separately adopted similar principles to what Zettelkasten proposes:
1. Heavy reliance on tagging
2. Some sort of deep linking
3. Preference to making small, independent "knowledge chunks"
Comment · 6 years ago
I find this to be the case with most pop-science books; the author's intention is to leave the reader with a feeling of having learned something rather than providing a full overview of the field, which may be too complex for the situation anyway. I often compare it to my response when non-CS people ask me "what I do."
Do you have some specific examples the people you spoke to frequently criticize regarding Harari?
Comment · 6 years ago
I agree. Random data makes the tests less specific, so I'd wager the authors would probably also argue against it.
Assuming you trust your unit tests, you can claim a passing test suite means: (1) given current understanding, the code is most likely correct and (2) based on the same assumption, other developers agree that the code is most likely correct, for the current version of the program
I personally believe randomness has a place (fuzzing), but should stay semantically distinct from unit testing for the above reasons.
Comment · 6 years ago
How did the detachment manifest, if you don't mind sharing?
Did you try to find an effective way to combat the lack of motivation, or was it just a matter of returning back to the office?
Comment · 6 years ago
> surprised that only 20% of people responded that they struggled with loneliness while working remote. In my experience this number seems to be higher.
Would you agree most lonely remote workers also tend to be younger?
It's somewhat unfortunate that we don't have additional data on the respondents since it may provide interesting insight (e.g. confounders that immediately spring to mind are country of residence and marital status), but there's a natural tendency to drift towards "exploitation" of existing relationships as one gets older as opposed to "exploring" new ones.
For instance, Doist's founder [1] cites being able to spend time with his son every morning as a major advantage.
In any case an even greater push towards remote work seems inevitable, especially as the tech workforce grows older.
Comment · 6 years ago
I don't feel this article brings too much new information to the clean code discussion table. As always, the advice is to strike a balance according to your best judgement.
The summary says it well:
> don’t over-invest (financially and technically) but also don’t try and outrun the liabilities
Comment · 7 years ago
I get where you're coming from with the 'inlined duck debugging' observation, however I'm of the opinion that explicitly commenting out "obvious" code chunks is usually fairly detrimental for a few reasons:
(0. The debugging approach can depend on a person's mental model)
1. Readability - even for a beginner, the method name should give a fair indication of what the code does. If the method name doesn't give a good indication, then the name should be changed. Otherwise, the comment is redundant.
2. Staleness - imagine a commit which changes the behavior of Engine::Compositing::onFrame(Deltatime) to only notify some of the components about the new frame (comment currently states "// Notify all components about the new frame"). Presumably, this commit should only change the internals of the onFrame method. However, because of a redundant comment, the person who changed the onFrame method now also has to find all its invocations and possibly update many comments.
My personal preference is commenting only domain-specific code chunks (example: [1]). These code chunks are usually put as close to the implementation as possible.
This way, whenever someone wishes to change the code, the person (1) immediately notices reasons behind the implementation (and may decide against modifying the code if he/she was unaware of these details) and (2) can modify the comment right away in case domain-specifics have changed in the meantime.
I'm curious to hear your or someone else's opinion against this argument?
[1] https://github.com/tkukurin/lesshint-intellij-plugin/blob/ma...
To get _truly_ self driving UIs you need to read the mind of your users. It's some heavy tailed distribution all the way down. Interesting research problem on its own.
We already have adaptive UIs (profiles in VSC anyone? Vim, Emacs?) they're mostly under-utilized because takes time to setup + most people are not better at designing their own workflow relative to the sane default.