On a somewhat related note, has anyone on here successfully mastered the art of speed reading?
I'm a CS student at Uni right now, and compared to non-Engineer students, I've noticed I tend to read must slower.
Any tips on up-ing my read speed?
I'd focus on understanding rather than reading speed. If reading faster compromises your understanding, back off. One more thing: the best way to see the need to read fast is to be overwhelmed by browser tabs. When you are, try to kill them after reading. With so many tabs, you'll want to end it up quickly.
If you try to read all the words, just faster, you won't get much farther. The trick is to take a more active approach and optimize how you spend your time towards the goal of comprehension.
One thing that worked well for me was shifting from "reading" to "interrogating". Don't just try to read through a text, think carefully (and jot down) what questions you need to answer from the text, and jump around the text as necessary to answer the questions. If you don't have a sense of what questions to ask, do a quick skim of the text and any other relevant material to get the questions first, then dive in. Iterate and refine your questions and answers.
In the presented example, gray Highlights within white phrases negatively affected my reading, but the white highlights within the yellow text helped I guess. Nonetheless, congratulations for experimenting.
I don't know. That was my first reaction too, but I started reading and after a couple of paragraphs I found them to be helpful. The red periods actually let me read faster because they were easier to spot.
This isn't actually mine, just something I stumbled on. Before I go and pull this apart to do it myself, does anyone know of an extension that will do this to arbitrary text in Firefox?
I found this because someone was using it as an argument against syntax highlighting for code, but I actually find that it lets me read significantly faster.
You may be interested in BeeLine Reader [1]. It puts a color gradient on alternating lines to text to hopefully let you read faster. I think it works a little bit. When I really want to read an entire article but don't want to invest too much time, especially if it's somewhat fluffy, I'll use Spritzlet set to 700 wpm [2].
Interestingly, when people see BeeLine Reader for the first time, many of them think (incorrectly) that it's a sentence-based algorithm instead of a line-based algorithm. Their belief often persists even after being told (by me, the creator) that it is in fact line-based. We've thought about doing something that's sentence-based, or syntactically or semantically aware, but as others have pointed out those tasks are much more complex.
Syntax highlighting works great for code, because code itself is highly structured, mostly normalized data (hence BNF being a thing). Even though we call them "languages", they're much closer to spreadsheets than natural languages. That's why it's so useful. Code isn't meant to be read from left to right, top to bottom. There's a lot of back-and-forth skimming to understand what the code is doing. Natural languages are meant to be read from beginning to end. We do skim, but it's almost entirely contextual, and only slightly syntactic. They're just not alike enough for things like this to make sense.
As an armchair linguist, I get frustrated by how computer nerd types keep comparing programming languages with natural languages. The two have very little in common other than some superficial similarities. The way each is acquired, used, and evolved is very different from the other. One of the worst examples of this bad analogy is sigils in Perl, which Larry insists are supposed to be good because they mirror plurals in English.
The analysis itself could be IMMENSELY useful in things like typesetting. There's a whole assortment of stylistic rules based on rather subtle things (e.g. the space between initials is usually slightly smaller) and they're rather hard to automate. If it were possible to parse and tag text like that, it may give way to advanced typesetting algorithms.
By the way, syntax highlighting works for code only as long as you see the same color scheme. If the scheme changes, the benefit is lost.
My startup [1], which also uses color in order to increase text readability, is launching a pilot program with an on-demand textbook publisher. But your point is well-taken — it has been a long slog to find our first couple publishing partners, even with solid independent research showing benefits for students and other readers.
Putting “house” in blue reminds me of House of Leaves, a book that plays with formatting & typography in unusual ways…
very minor spoilers
…as it descends into madness (blank pages, words in spirals, backwards characters, single-character pages, overlaid paragraphs…). The very first unusual formatting in the book, and spit-take surprising to me as I wasn't expecting anything unusual at all, was simply printing the word “house” in blue. A fun read, thanks for reminding me of it!
Let's have different colors for dialog spoken by different characters, such as Holmes and Watson. That way I won't have to reread the text to figure out who said what.
That would be nice. It's often really hard to tell with long conversations in novels who is speaking. There's a tenancy to have the speaker implied rather than implicit for long conversations, and color would be a good solution. I wonder if this is ever used in cinema and / or theater.
I was taught that the protocol is for the speakers to alternate if no other information is given in the lines. In all other cases you need to restart the speech block with something like "Watson continued, "..."".
Sure, but sometimes I get a little lost - my eyes wandered away from the page, I got distracted and started thinking about something else, or there were too many back-and-forths for me to keep it straight.
This is actually one of the big issues with RSVP techniques like Spritz. When you can't see the paragraph structure, it can be very difficult to track who's talking.
"Even when reading a novel myself, it bothers me when I don't learn the speaker until after the I have read the quoted phrase, like in this comment" said WillAbides
To be fair, I've started to feel the same way about syntax highlighting in code. I've slowly moved to only highlighting 2 things: String literals and comments.
I'm nowadays using a theme in Emacs where everything is black on white and keywords and comments are bold, whereas code regular. I'm happier with this than syntax colouring nowadays. I've also removed some colour from Org, namely headlines are bold and black. Again, I guess the less the colours the better here. I use colours with parens, they're pale by default, then highlighted with highlight-parenthesis mode, denoting nesting via tones of red.
I'm even doing some html-css-js-m4 work for a relatives business website nowadays, and I did not miss highlighting even with such complex mess, instead, I'm happier.
I like to have language keywords accented too, since that helps me scan the shape of the code without having to read it closely, but yes - most of the benefit is just in knowing what context you should read the characters in.
I saw it. I could not really tell if it was good - as it was now with the dark text.
I can't help to think that this was done by someone that does not read that much.
Younger people seems to prefer videos instead of READMEs, and I have not really understood why until I saw somewhere that speedreading skills apparently have been falling drastically among young people. I mean why look at a video for 30 minutes to see if a tool or framework is worth trying, when you can scan the equivalent text in 30 seconds.
Syntax highlighting traditionally chooses a different color for each token in this Java statement:
final String id = leader(NAMES_AND_SCORES);
If I try to translate this statement into English:
Given a global list of names and scores, determine the leader's
id. (Ensure that id is a string of characters.) I'll use "id" to
refer to that leader throughout this paragraph.
If our traditional highlighting approach is generally correct for the code, shouldn't I be highlighting each sentence and/or phrase wholly with one color and not highlight per parts-of-speech?
Or in other words, does the analogy being proposed really hold?
Or another take -- speed readers take in whole sentences at a time. Colorizing parts-of-speech this way would only seem to slow them down whereas syntax highlighting code speeds my reading. I'm sure there's an analysis here; final, String, leader() are not parts-of-speech; each is a separate semantic statement.
I think you make a wonderful comment here, but your analogy doesn't hold, I'd say. While I applaud the effort going into this, I don't think this works for me. I read "code" for humans completely differently than I do code meant to describe computation (NLS text versus programs, respectively). IOW, there can be no analogy for me.
I think it stems from the way we read Sherlock Holmes as an experience whereas we read a program as an explanation. You cannot substitute an explanation for an experience.
It's not an analogy, it IS syntax highlighting. You just encode a lot of semantics into syntax in java, so syntax highlighting is more useful for determining the semantics.
I don't think the OP was claiming this is useful for english in the way syntax highlighting is useful for java.
We don't highlight each line of code separately, which would be the analogue to highlighting natural language at the sentence level. We highlight tokens based on their syntactic type. Strings are all colored the same. Operators are colored the same. That's pretty much the same idea as coloring all common parts of speech the same.
Parsing is the act of taking a linear string of tokens and building a tree out of them. That means reading in a string of tokens and applying the parsing rules (which may be encoded as a set of fuzzy correlations when humans learn those rules). When the rules are not solidly codified or slow to apply due to unfamiliarity, it helps to have hints to orient/validate yourself.
You do this parsing routine with your own natural language, too. You're just much more comfortable doing so and do not need hinting on what each word's role is. Just like a lot of old-school unix guys of lore are more comfortable reading code without the spectra of colors we commonly apply today. I could see natural language syntax highlighting being very useful for language learners, though. Color is used in Chinese language learning to indicate tonalities for learners, since most have no native/intuitive way to transcribe the pitch contours. I'm not convinced that the syntax highlighting presented in the article is really what you'd want, but I'm interested in the direction it's headed.
As an aside, speed readers don't take in a whole sentence at a time. An entire sentence simply doesn't fit within your fovea, but they have optimized their eye tracking to boost their speed. I do imagine that having lots of colors would disrupt and distract from the text and harm their speed / comprehension, but it may be possible that a different highlighting scheme could work for them.
The problem is, if you use italics/bold/underline remotely as often as necessary to convey intonation or emphasis, you read like you're a loon or crank. Bolding is the green ink of the Internet.
We generally add points and comma to emphasize parts of the text, slow down, stop the reading... Try reading the text out loud without the syntax highlighting, then try with. See? It doesn't work, you're going to emphasize and stop on higlighted words. What would have worked would have been to highlight everything and split the highlight according to punctuation, not words.
As someone else pointed out, different colors for different protagonist talking would be neat as well. But there is not much you can't do without deforming the original intent of the writer.
Another thing that could be interesting would be to give these tools to the writer instead of highlighting the text automatically, but then as someone else pointed out, these tools already exists and are rarely used because of the noise they add (bold, italic, underlined). There are also quotes, quads, uppercase, ... There are many ways to help the reader follow the text.
It would be interesting to see the major parts of speech (nouns, verbs, adjectives) colored. Instead this is a coloring of fairly random words. A bunch of short words are grey, but they don't belong to any particular part of speech. They include some articles, prepositions, conjunctions and a few verbs...
I think we'd need to solve computational linguistics for a completely accurate parser to be able to tag the words properly. Although, the current state of the science works for something like 80% of cases (which are the "easy" ones).
I think a naive approach would do quite well. We're not looking to comprehend the sentence entirely, rather a fairly good accuracy, so that the reader only needs, usually, focus on the highlighted words. For example, serif'd, bolded verbs and noun would retain most of the information while filler words like "the" and "and" might not be necessary.
The consequent highlighted parts reminds me a lot of Chinese, where essentially every word is "important" and there are few filler words, and hence there is often a lot of contextual information.
Sorry but POS tagging is pretty much solved already. It is already in the 97+% [1]. Current papers are now mostly improving it by less than one percent.
For the record, 97% on canonical test datasets with little recent progress doesn't mean that it's a solved problem. Admittedly, part of the problem is that elementary school POS categories aren't a great model of natural language.
More generally, for true syntax highlighting I think you do need the parse tree, and parsers (as opposed to taggers) definitely aren't at 97%.
They definitely aren't at 97% but they aren't that bad either. For English they are at around 92% (see for example http://arxiv.org/pdf/1603.04351.pdf) in labelled attachment score (right tag+right label).
If you are interested only in the syntactic tag, not in the structure of the tree, the number is somewhat higher.
To be fair, I'm not a computational linguist (some of my friends did their PhDs in the field though). From what I remember, one of the most glaring issues in the field is that the most used corpus is a bunch of issues of the Wall Street Journal (which is a very specific data set).
The 80% figure was quoted from some talk I heard a few years ago, so I concede it's almost certainly improved since then.
It's true that POS tagging works fairly well. But consider that a sentence involves more than one word. Even at 97 % accuracy for one word, the probability of correctly tagging every word in a short sentence of only ten words, is still as low as 0.97^10 = 0.74. And sentences are generally longer than ten words.
And as POS tagging is usually only done as preprocessing for some other task like syntactically parsing a text (which itself is usually preprocessing for yet another task), 97 % accuracy per word is not as good as it sounds. Parsers need to work with wrong data for every second or third sentence.
Yes, you can get 97-98%, but only when evaluating on data from the same corpus as you trained on. If you evaluate on data from a different corpus, you immediately get a pretty big drop in performance. Thus one person in the field I've talked to even went so far as to say that competing in this part of the field (state-of-the-art performance, basically) is fundamentally a question of "who is the best at overfitting".
There's basically no part of NLP that's a solved problem. Even something as superficially simple as segmenting running text into sentences and tokens is decidedly non-trivial.
Those are stop words. You usually remove them from a text before analysing word frequencies because they are so common to all English text that they don't tell you anything specific about the current text.
I don't know what the rational is for greying them out is, but that's the category.
I thought of that article too, and while this highlighter isn't quite as colourful as that example, it still felt more distracting to read than monochrome text.
You can stop spamming that blog now. The author has a wrong understanding of what syntax highlighting tries to achieve and because of that he comes to questionable conclusions.
It's really just a way to get people to visit his blog by making a bold statement.
If it cannot highlight the main part of a sentence for us, it is making things worse. Our reading habit will not change within a very long time. And if this change has not too much benefit, it is not worth the change. Think about it.
This is a very interesting idea! How about syntax highlighting for proper nouns, using a preset cycling color tables to give proper nouns consistent colors?
Sorry, but when we speak of "syntax highlightning" for natural language what is the actual goal?
Are we trying to color differently verbs, nouns, adverbs and prepositions? So that the "goal" is to properly decide if "lie" is a verb or a noun?
Or are we trying to colour subject, verb, object and other elements of the sentence? So that "Rome destroyed Carthago" will have a different color for Rome then the sentence "Hannibal tried to destroy Rome"?
In general, code has "reserved words" and the rest is either a "name" (variables, constants, literals) or a ... Well... "Verb". Like functions, procedures, methods.
In some rare case (function pointers, closures) you have "verbs" that can be used as "nouns" but you completely lack concepts like dative, accusative and so on.
I think that this really breaks down as an analogy when you try to adapt syntax parsing to natural language.
I can tell you right away that it would be of huge help when reading a new language especially in a new script. And who are biggest set of users that might benefit from this? (clue: they haven't said their first words yet).
Which one? Sorting out names, verbs, adjectives etc. Or finding out what "role" each word is playing (sorry, English is not my language so I do not know the proper technical terms for this... In my culture the first is called "Grammatical Analysis" while the latter is called "Logical Analysis")
I actually made a little thing for emacs that does something similar, actually tagging on the parsed parts of speech instead of just tokens. It requires you to select the text first instead of automatically highlighting, though. It uses coreNLP which was pretty lovely to work with.
I actually made a little thing for emacs that does something similar, actually tagging on the parsed parts of speech instead of just tokens. It requires you to select the text first instead of automatically highlighting, though. It uses coreNLP which was pretty lovely to work with.
In German (and other languages) you capitalize every noun. When I was younger I found it confusing that English didn't do that. It seems that this kind of syntax highlighting allows your brain to read text a little bit faster since it instantly knows that this will be a noun. It's also a little annoying if people write German and don't properly capitalize, your brain just doesn't expect the word to be noun if it's not capitalized.
English used to do this. You can still see evidence of it in things like the US Constitution, where the capitalization seems random until you remember English is a Germanic-family language and did this as recently as a couple hundred years ago:
We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America
I.
All legislative Powers herein granted shall be vested in a Congress of the United States, which shall consist of a Senate and House of Representatives.
The House of Representatives shall be composed of Members chosen every second Year by the People of the several States, and the Electors in each State shall have the Qualifications requisite for Electors of the most numerous Branch of the State Legislature.
At least, it is not a typo from ubernostrum, it's spelled "defence" in the original [1].
Moreover that's the British spelling of defense (is there a link with the lack of capital?).
Also note that, instead of "Blessings", it is "Bleſsings" in the original. But they are roughly equivalent if you apply a compatibility decomposition in your unicode normalization (NFKD/NFKC).
So where is the edit button for that constitution? Or do they only accept pull requests?
but at least in my browser, I can't see the actual answer (it says "2 Answers" but I can only see one, which just confirms that the word is not capitalized).
"common defense" is being used as an elision of "common defense of the People". The entire phrase is a noun phrase. But " defense" is a verb within the noun phrase.
But that rule doesn't apply only to nouns: it applies to all words that aren't pronouns, conjunctions and articles. Hence, "To Kill a Mockingbird" ('kill' is a verb), "Malone Dies," etc.
That rule (the one I learned in primary school) does apply only to nouns. I'm not suggesting my primary school teacher's rule is the correct, most popular or best rule :)
Personally, though, I find many US newspapers' headlines jarring due to excessive capitalisation.
Other languages also have more complex inclination and declension rules that add additional structure. (And for writing systems, c.f. the use of hiragana in Japanese for things like particles and verb endings).
110 comments
[ 3.4 ms ] story [ 187 ms ] threadOne thing that worked well for me was shifting from "reading" to "interrogating". Don't just try to read through a text, think carefully (and jot down) what questions you need to answer from the text, and jump around the text as necessary to answer the questions. If you don't have a sense of what questions to ask, do a quick skim of the text and any other relevant material to get the questions first, then dive in. Iterate and refine your questions and answers.
I use it sometimes, it works pretty well but occasionally gets confused.
I found this because someone was using it as an argument against syntax highlighting for code, but I actually find that it lets me read significantly faster.
1: http://www.beelinereader.com/
2: http://www.spritzlet.com/
By the way, syntax highlighting works for code only as long as you see the same color scheme. If the scheme changes, the benefit is lost.
1: http://www.BeeLineReader.com
very minor spoilers
…as it descends into madness (blank pages, words in spirals, backwards characters, single-character pages, overlaid paragraphs…). The very first unusual formatting in the book, and spit-take surprising to me as I wasn't expecting anything unusual at all, was simply printing the word “house” in blue. A fun read, thanks for reminding me of it!
https://en.wikipedia.org/wiki/House_of_Leaves#Colors
I'm even doing some html-css-js-m4 work for a relatives business website nowadays, and I did not miss highlighting even with such complex mess, instead, I'm happier.
Larger blocks of cited text might work.
I can't help to think that this was done by someone that does not read that much.
Younger people seems to prefer videos instead of READMEs, and I have not really understood why until I saw somewhere that speedreading skills apparently have been falling drastically among young people. I mean why look at a video for 30 minutes to see if a tool or framework is worth trying, when you can scan the equivalent text in 30 seconds.
Or in other words, does the analogy being proposed really hold?
Or another take -- speed readers take in whole sentences at a time. Colorizing parts-of-speech this way would only seem to slow them down whereas syntax highlighting code speeds my reading. I'm sure there's an analysis here; final, String, leader() are not parts-of-speech; each is a separate semantic statement.
I think it stems from the way we read Sherlock Holmes as an experience whereas we read a program as an explanation. You cannot substitute an explanation for an experience.
It's not an analogy, it IS syntax highlighting. You just encode a lot of semantics into syntax in java, so syntax highlighting is more useful for determining the semantics.
I don't think the OP was claiming this is useful for english in the way syntax highlighting is useful for java.
Parsing is the act of taking a linear string of tokens and building a tree out of them. That means reading in a string of tokens and applying the parsing rules (which may be encoded as a set of fuzzy correlations when humans learn those rules). When the rules are not solidly codified or slow to apply due to unfamiliarity, it helps to have hints to orient/validate yourself.
You do this parsing routine with your own natural language, too. You're just much more comfortable doing so and do not need hinting on what each word's role is. Just like a lot of old-school unix guys of lore are more comfortable reading code without the spectra of colors we commonly apply today. I could see natural language syntax highlighting being very useful for language learners, though. Color is used in Chinese language learning to indicate tonalities for learners, since most have no native/intuitive way to transcribe the pitch contours. I'm not convinced that the syntax highlighting presented in the article is really what you'd want, but I'm interested in the direction it's headed.
As an aside, speed readers don't take in a whole sentence at a time. An entire sentence simply doesn't fit within your fovea, but they have optimized their eye tracking to boost their speed. I do imagine that having lots of colors would disrupt and distract from the text and harm their speed / comprehension, but it may be possible that a different highlighting scheme could work for them.
As someone else pointed out, different colors for different protagonist talking would be neat as well. But there is not much you can't do without deforming the original intent of the writer.
Another thing that could be interesting would be to give these tools to the writer instead of highlighting the text automatically, but then as someone else pointed out, these tools already exists and are rarely used because of the noise they add (bold, italic, underlined). There are also quotes, quads, uppercase, ... There are many ways to help the reader follow the text.
The consequent highlighted parts reminds me a lot of Chinese, where essentially every word is "important" and there are few filler words, and hence there is often a lot of contextual information.
1. http://nlp.stanford.edu/pubs/CICLing2011-manning-tagging.pdf
More generally, for true syntax highlighting I think you do need the parse tree, and parsers (as opposed to taggers) definitely aren't at 97%.
If you are interested only in the syntactic tag, not in the structure of the tree, the number is somewhat higher.
The 80% figure was quoted from some talk I heard a few years ago, so I concede it's almost certainly improved since then.
Graded as a school exercise, I think 97% wouldn't be that good.
And as POS tagging is usually only done as preprocessing for some other task like syntactically parsing a text (which itself is usually preprocessing for yet another task), 97 % accuracy per word is not as good as it sounds. Parsers need to work with wrong data for every second or third sentence.
(This surprises me. I would expect accuracy for different words in a sentence to be correlated, you either make no errors or several.)
There's basically no part of NLP that's a solved problem. Even something as superficially simple as segmenting running text into sentences and tokens is decidedly non-trivial.
http://hemingwayapp.com/
not quite what you're proposing but useful nonetheless
I don't know what the rational is for greying them out is, but that's the category.
https://en.wikipedia.org/wiki/Stop_words
https://en.wikipedia.org/wiki/Part_of_speech
It's really just a way to get people to visit his blog by making a bold statement.
Are we trying to color differently verbs, nouns, adverbs and prepositions? So that the "goal" is to properly decide if "lie" is a verb or a noun?
Or are we trying to colour subject, verb, object and other elements of the sentence? So that "Rome destroyed Carthago" will have a different color for Rome then the sentence "Hannibal tried to destroy Rome"?
In general, code has "reserved words" and the rest is either a "name" (variables, constants, literals) or a ... Well... "Verb". Like functions, procedures, methods.
In some rare case (function pointers, closures) you have "verbs" that can be used as "nouns" but you completely lack concepts like dative, accusative and so on.
I think that this really breaks down as an analogy when you try to adapt syntax parsing to natural language.
I switched to a gray scale theme (emacs tao theme) two weeks ago and it is so much better.
https://github.com/cosmicexplorer/speech-tagger
https://github.com/cosmicexplorer/speech-tagger
* http://www.ruediger-weingarten.de/Texte/Capitalization.pdf (pg 4ff, last paragraph)
* https://mindmodeling.org/cogsci2013/papers/0462/paper0462.pd...
* http://linguistics.stackexchange.com/questions/699/does-capi...
We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America
I.
All legislative Powers herein granted shall be vested in a Congress of the United States, which shall consist of a Senate and House of Representatives.
The House of Representatives shall be composed of Members chosen every second Year by the People of the several States, and the Electors in each State shall have the Qualifications requisite for Electors of the most numerous Branch of the State Legislature.
etc.
At least, it is not a typo from ubernostrum, it's spelled "defence" in the original [1].
Moreover that's the British spelling of defense (is there a link with the lack of capital?).
Also note that, instead of "Blessings", it is "Bleſsings" in the original. But they are roughly equivalent if you apply a compatibility decomposition in your unicode normalization (NFKD/NFKC).
So where is the edit button for that constitution? Or do they only accept pull requests?
[1] http://www.archives.gov/exhibits/charters/charters_downloads...
https://www.quora.com/Why-is-the-word-defence-the-only-uncap...
but at least in my browser, I can't see the actual answer (it says "2 Answers" but I can only see one, which just confirms that the word is not capitalized).
So, an essay title might be "The Man and his Dog" rather than "The man and his dog".
Personally, though, I find many US newspapers' headlines jarring due to excessive capitalisation.
I'm very curious.