thebelal

There is a quarto-webr extension to do this. A bunch of real world examples are at https://quarto-webr.thecoatlessprofessor.com/qwebr-community...

An earlier attempt of this is http://csvy.org/, but AFAIK it has never really caught on.

One of the cancers they mention is pancreatic cancer.

A quick Google search suggests the prevalence of pancreatic cancer in the population is 13 per 100,000.

So if you gave this test with a 0.005 false positive rate and 0.5 true positive rate to 100,000 people it would miss diagnose 500 people and only correctly detect 7 cancers.

So given you had a positive test result there would be a 1-(7/500)=98.6% chance you did _not_ have pancreatic cancer.

Doesn't seem very useful in that light...

I use right assignment in this way all the time, you should try it Joe :)

FWIW `scan()` is going to be much faster if you are just reading doubles from standard input than `as.numeric(readLines())`.

1632[0] is the first in a series of entertaining alternate history novels, where an entire West Virginian town is transported to the middle of the Thirty Years war. It touches on some of these problems in having to translate modern knowledge to people in the past.

0: https://en.wikipedia.org/wiki/1632_(novel)

While it is true that S was originally a macro layer around FORTRAN code R has always been primarily written in C. Very little of R core is in FORTRAN, and essentially none of it is C++.

The language statistics show a good deal of FORTRAN (%24.5) [0], however that is largely skewed by the included LAPACK code [1], which accounts for 221,921 / 259,773 lines of FORTRAN in R.

[0] https://github.com/wch/r-source [1]: https://github.com/wch/r-source/tree/trunk/src/modules/lapac...

While the order of the walls in Super Hexagon is random, each level has a predetermined set of walls. Once you identify which wall pattern is coming you know exactly the maneuver needed to traverse it.

This makes Super Hexagon more a game of quick pattern recognition than reaction time.

When I play it I am generally focused at the edges of the screen to quickly identify the next pattern and only using my peripheral vision to maneuver around the walls in the center.

FWIW I have been using vim with Colemak for quite a few years now, with only movie remains needed to get movement back on the home row [0]

0: https://github.com/jimhester/dotfiles/blob/master/colemak/vi...

Dvorak users in this thread should really give Colemak [1] a try. Dvorak has a number of issues [2] in modern usage and is also harder to learn; many more keys change from their QWERTY equivalents.

I have used QWERTY, Dvorak and Colemak for multiple years and Colemak is the clearly the best of the there for me.

[1] https://colemak.com/

[2] https://colemak.com/FAQ#What.27s_wrong_with_the_Dvorak_layou...

"user:foo" will search an organisation named foo.

Colemak changes relatively few keys from qwerty, especially compared to Dvorak. I use colemak full time and can still touch type qwerty reasonably fast.

Agreed, if there was just a little more editor support and use early on the whole CSV mess could have been avoided.

They actually display fairly well in vim

Looks like you can play with the interactive editor as discussed in the paper at https://ohmlang.github.io/editor

1. There is a log plot at the end of the article

2. The author posted the exact search terms used for all languages in an earlier post [0]

[0] http://r4stats.com/articles/how-to-search-for-data-science-a...

This is even easier to do with awk.

    awk -e '!a[$0]++'

I personally would recommend colemak [1] rather than Dvorak. While both are improvements over QWERTY colemak only moves 17 keys from their QWERTY positions, while Dvorak moves nearly all of them. In particular Ctrl-Z, Ctrl-C, Ctrl-V require two hands in Dvorak which is very inconvenient. In some applications these shortcuts can be rebound, but in many others they cannot. In colemak their positions (and all of the left-bottom row keys) are the same as QWERTY.

I used Dvorak for ~2 years and then switched to using colemak for the last 3+. OS support for both is widespread.

You can get back up close to your QWERTY speed in about a month or so (maybe less if going from QWERTY straight to colemak).

I switched to the alternatives to reduce RSI rather than speed and found it helped me with both.

[1] http://colemak.com/

The rvest implementation was the main thing that seemed like an R port of the python implementation rather than best use of rvest.

An alternate (simpler) implementation of the rvest web scraping example is at https://gist.github.com/jimhester/01087e190618cc91a213

It would be even simpler but basketball-reference designs it's tables for humans rather than for easy scraping.

This is IMHO the real benefit to zsh over bash. You can set zsh to share history between sessions and they are interleaved based on the time the commands were run. No more closing a session in the wrong order and losing half of your history for the day.

Great to hear you find per-directory-history useful! (I wrote it)

On the topic of the article I have per directory history going back to ~2013 when I wrote the script.

For those interested in viewing this code in context is is at (https://github.com/vim/vim/blob/db9bc0b7931d252cf578c1cd298a...)

Also note that RealWaitForChar has been completely removed from neovim since April of 2014 (https://github.com/neovim/neovim/pull/474/files)

The axis are described in the text

The x axis (log scaled) gives the number of speakers (plus one, so as not to make dead languages fall off the scale). The y axis, also log scaled, shows the adjusted wikipedia size.

As is the real ratio

real ratio, defined as the number of ‘real’ pages divided by the total page count

Not sure why they couldn't put the above in the figure legend (or better yet label the plot directly). I agree it is poorly done.

Carmack is one of my role models as well, but 0x5f3759df while neat did not originate from him, as it states multiple times in the Wikipedia article you cite.

Completely agree with this. I actually think vims undo tree might be the most useful feature in vim for me. You can basically use it as version control lite with automatic commits.

R (1976)[1] and Matlab (1984)[2] both predate Python (1991)[3], so I guess the answer is because the 'existing' language didn't exist.

As far as Julia goes it aims to bring strong typing and very fast native performance for numerical operations. Neither of which R, Matlab, or Python provide. Seems perfectly reasonable to me.

[1] http://en.m.wikipedia.org/wiki/S_(programming_language)

[2] http://en.m.wikipedia.org/wiki/MATLAB

[3] http://en.m.wikipedia.org/wiki/Python_(programming_language)

You may want to try https://github.com/Valloric/YouCompleteMe Does exactly what you describe wanting, and very well IMHO.

For this example (1 column data), you get much closer results using R's scan function rather than read.table

  awk 'END{for(i=0;i<1000000;i++){ print int(rand() * 1000000) } }' </dev/null > data.txt
   
  time datamash sstdev 1 < data.txt
  288619.72189328
  0.72s user 0.01s system 99% cpu 0.736 total

  time R --vanilla --slave -e 'sd(scan("data.txt"))'
  Read 1000000 items
  [1] 288619.7
  1.09s user 0.04s system 99% cpu 1.134 total

This seems like a better replacement for awk and bash one-liners to me than tasks I would use R for.

For instance counting unique elements.

  #naive approach
  time (sort data.txt | uniq | wc -l)
  632209
  13.09s user 0.04s system 101% cpu 12.984 total

  #using hashing
  time (awk '!a[$0]++' data.txt | wc -l)
  632209
  1.34s user 0.03s system 100% cpu 1.360 total

  #R
  time R --vanilla --slave -e 'length(unique(scan("data.txt")))'
  Read 1000000 items
  [1] 632209
  1.20s user 0.04s system 99% cpu 1.244 total

  #datamash
  time datamash countunique 1 <data.txt
  632209
  0.83s user 0.01s system 99% cpu 0.840 total

Vim works with colemak quite well with only a few rotated keybindings to get back home row navigation.

I have written a good amount of perl in both Vim and Emacs and can't recall noticing bad syntax highlighting in either. Do you have an example?

Back when I was hacking on DF ~4 years ago I believe it was actually the item tracking that was ruining performance in big forts. The main loop had to touch every item in the game every frame, including things like every rock mined by your dwarves. You can usually get significant speedup in big forts just by destroying all the spare rocks (I think the best way to do this in-game was put them under a bridge and then close it on top of them).

I ended up having more fun hacking on DF than playing it, but it is an interesting game.