User talk:Nbarth

From Wikipedia, the free encyclopedia
Jump to: navigation, search
en This user is a native speaker of English.
fr Cet utilisateur a pour langue maternelle le français.
ja-2 この利用者はある程度日本語ができます。
es-2 Este usuario puede contribuir con un nivel intermedio de español.
Search user languages
Symbol question.svg This user has written or expanded 2 articles featured in the Did You Know section on the Main Page.
This editor is a Senior Editor II and is entitled to display this Rhodium Editor Star.
This editor is a Most Pluperfect Labutnum and is entitled to display this Book of Knowledge with Coffee Cup Stain, Cigarette Burn, Chewed Broken Pencil, Sticky Note, and Bookmark.
Following a fortnight’s inactivity, pages are unwatched and threads here below are archived; please start a new thread below if you wish to resume.


You are welcome to email me, add a new comment (by using the + tab above, or click here), or contribute to an existing discussion below.

If I don't reply for a while, I'm probably not logging in much — email me if you want to get in touch.

For reference: Guidelines on using talk pages.

Original Barnstar.png The Original Barnstar
For your recent math improvements (symplectic/almost complex manifold, etc). In the flow of wrong and content free edits I've been seeing lately, yours is appreciated. Orthografer 07:19, 15 November 2007 (UTC)
The Citation Barnstar The Citation Barnstar
For being bald. ;) Paradoctor (talk) 23:40, 18 March 2010 (UTC)
Original Barnstar Hires.png The Original Barnstar
Thank you for your work on the Corecursion article! WillNess (talk) 08:22, 6 October 2013 (UTC)

Dynkin diagram folding[edit]

Hi Nils von Barth,

I noticed you worked on the article/section Dynkin_diagram#Folding. I added some chart examples of these folding, although I can't say I did the "directed graph" aspect correctly. Also I used Coxeter notation, line for 3, labels above 3, rather than double/triple lines. I just added an arrow above the higher order lines. If you know better, please help. I'm surprised there's like a number of C~k versions by arrows >>, <<, and <>, based on foldings of different simply-laced higher graphs! Similarly F~4 can project from E~6 or E~7 with reversed arrows!? I have no confirmation what this means, but for the undirected Coxeter-Dynkin diagrams, it looks correct! Thanks for a look if you can help. Tom Ruen (talk) 05:48, 4 December 2010 (UTC)

p.s. On the directed graphs, Humphreys shows clearly directed arrows on a table on p96. [1] So, either there's something that demands a direct direction, or when it was written (1990), folding wasn't firmly defined, and he didn't recognize alternate forms?! What do you think? Tom Ruen (talk) 06:40, 4 December 2010 (UTC)

p.p.s. I see the main limitation, is the Hn Coxeter group families are excluded from the Dynkin graphs, so if the charts are correct and can stay, they should be replaced in multiline format, and Hn cases removed. Tom Ruen (talk) 07:02, 4 December 2010 (UTC)

Finite folding, Coxeter notation
Finite folding, Dynkins notation
Affine folding, Coxeter notation
Affine folding, Dynkins notation
Hi Tom – thanks for your fabulous diagrams!
I’m not expert in this, so I did some reading – your diagrams look mostly correct, but you’re right, some changes would be in order, specifically:
  • Dynkin-only (eliminate Hn)
  • Affine: change the naming of the affine graphs – the different directions have different names
  • Add 1 more affine graph, and separate out the two ones mapping to “G~2” – I think they go to different graphs.
I elaborate below; the tables at Kac pp. 53–55 are our key reference!
To rephrase, the question you have is
“which way to direct the edges?”
The issue is that, for the affine diagrams, you get different directions (and your reasoning seems correct to me), not all from the first series (see below).
Thoughts follow (unindent for legibility):
  • Firstly, there are several series of affine Dynkin diagrams; see affine Dynkin diagram, and tables on Kac pp. 53–55 (Infinite dimensional Lie algebras, Victor Kac) – I only just learned this.
  • These diagrams need to be labeled with superscripts (1, 2, or 3), as in A_{2l}^{(2)} – the tildes correspond to the first series \tilde A_l = A_l^{(1)} (the “extended” Dynkin diagrams), but there are some from the second series here in folding.
  • Direction isn’t much of a problem for the regular diagrams, but the Hn are not directed, so what exactly these maps mean is a bit unclear.
  • Further, there is a correct direction for the extended Dynkin diagrams; Humphreys is listing the first series:
(for reference, C~n is >-...-<, F~4 is -->-, and G~2 is <-).

The changes we get are:

  • By this reasoning, the 4 foldings A~2k–2 → C~k, D~k+2 → B~k+1, E~6 → F~4, and D~2k+1 → C~k correspond to maps in the second series – the arrows are wrong for the first series; you didn’t comment on the two directions for B…
  • It’s also not clear to me which way the arrow should go on “G~2” in E~7 → G~2, because the vertices on both sides of the multiple side are branch points, but I think the arrow should point to the center (the other way from E~6 → G~2); this maps to the third series.
  • The → H~k maps of (regular) diagrams don’t correspond to Lie algebras, which is a bit confusing or misleading in this context…
  • Also, the I2(8) diagram is an extended Dynkin diagram (A_2^{(2)} – Kac page 55), so you may want to include it. (The other I2(p) are not affine Dynkin diagrams, though of course they are Coxeter ones.)

So, concretely, what I’d suggest is:

  • Use Dynkin diagrams, for consistency with the rest of the article/section and to avoid confusion (discussion and diagrams of Coxeter folding would be interesting, but separate) – I think you’re suggesting this above in regards to the Hn.
    • It’s fine if you want to draw the arrows above the edges (instead of on the edge), but it would be clearer if you use double and triple edges rather than numbers.
    • Also, as you suggest, we should eliminate the Hn from the Dynkin article.
  • Use Kac’s notation (A_{2l}^{(2)} etc.), since some are from the second series.
  • Add the A_{3}^{(1)} \to A_{2}^{(2)} (that’s a square mapping to a quadruple line).
  • I think the “G~2” in E~7 → G~2 (G_{2}^{(1)}) should instead be D_{4}^{(3)}, but this is only a guess – it’s the only remaining diagram we don’t otherwise hit, and note that the branch point (valence 3 vertex) in E~7 maps to the center point in the “G~2”, while the branch point in E~6 maps to an outside point.
    • I’m not completely sure how this works, but I think this is right.

I think this fixes it – all the diagrams are valid, and we get all of Kac’s diagrams. Hope these help, and thanks so much – ガンバテ! (Japanese “bon courage”)

—Nils von Barth (nbarth) (talk) 10:54, 4 December 2010 (UTC)
I'm so glad you're a good careful thinker to can help sort this out. For me, its long past my sleep time. I'd be glad if you want to try your own graphics to replace mine, with corrected notations. Mine can still be helpful as "Coxeter foldings", even if also need some corrections possibly.
  • On E~7--> G~2, I'm convinced it is G~2. Vertically we have a side-ways W zig-zag, which is really a fully folded A5, order 6 symmetry. And the 3 parallel order-3 angles on the right are just 3, so it's [6,3]!

Goodnight. I'm very happy if we can get some sense here! I have emailed some others for advice too.

Tom Ruen (talk) 11:23, 4 December 2010 (UTC)
p.s. It seems like you could fold A7 into D~4 as a 3-4 zig-zag and merging the 3 nodes into one for a 1-4 branching. Does that make any sense? Can you fold a finite group and get an infinite one?! (Well at least that's similar to my relation of E~7 and E~6 in the G2 folding, seeing the left node column merged or not.) Tom Ruen (talk) 01:10, 5 December 2010 (UTC)
The "directed arrow" rule seems to mean to point to the side with less nodes. A perfect zig-zag folding is a folded simplex (An), and will have an odd number of nodes (in Weyl groups), so the arrow is clear. (Hk have 4 nodes, two on each side so no arrow!) The only other cases are like D4-->G2, 3:1, which really is 5 nodes of a 4-simplex foldest as 3:2, with the two nodes merged. So anyway, I think this is clear and my graphs are correct. If I have some time on Sunday evening, maybe I'll try making a chart of Dynkins style graphs (but I don't want to spend too much time on prettiness (like SVG) until its confirmed). Tom Ruen (talk) 02:08, 5 December 2010 (UTC)
I was annoyed at an incompleteness, so I took the time to update the W A5 --> G4 folding, and added A3 --> C2/B2 for good measure. Tom Ruen (talk) 04:37, 5 December 2010 (UTC)
Okay, I made some Dynkin versions. I kept arrows above the edges, more clear on small scales. So they are ugly, but compact. For me tweaking pixels in MSPaint is less frustrating than SVG. Tom Ruen (talk) 07:01, 5 December 2010 (UTC)

Thanks Tom – the newer versions (red vertical lines, Dynkin versions) are very nice!

I’ll leave graphic design choices up to you – I trust your MSPaint skills, and I well remember all the problems that SVG poses.

The other change is to fix the notation – several of the diagrams (the ones with the “wrong way arrows”) are not extended Dynkin diagrams, but rather other affine Dynkin diagrams. Using the notation on Kac p. 55, the maps should be changed as follows:

A~2k–2 → C~k
Firstly, the index on this is wrong – it should be k-1 (remember, extended adds one vertex above the index – this is right in the finite diagram).
Secondly, the target is notated by D_{k+1}^{(2)} (arrows are opposite of C~).
D~k+2 → B~k+1
This maps to A_{2k+1}^{(2)} – arrow is backwards for B~.
E~6 → F~4
This maps E_6^{(2)} – arrow is backwards for F~4.
D~2k+1 → C~k
This maps to A_{2k}^{(2)} – arrows are >>, not the >< you find in C~.

Two other issues:

  • It might also be clearer to replace the ~ by (1), for consistency with the (2)…
  • Also, the bottom right picture in the affine ones isn’t right – you’re taking the quotient of a non-simply laced diagram, which you can’t do (or at least is more delicate) – notice that you’re taking a quotient of a diagram with doubled edges (C~) and the doubled edges disappear in the quotient. Maybe this makes sense, but I’d be very careful.

Thanks again for your continuous improvements!

—Nils von Barth (nbarth) (talk) 06:25, 6 December 2010 (UTC)

Thanks! I'm seeing a bit more "Extended" means "~" format by adding one node to finite groups, and the superscripts (1)/(2) define wider directed-graph variations than the original extended definitions. I'm content to use the superscript notations, but FIRST, I think I need an enumeration of these forms before the folding section in the article, like Coxeter-Dynkin diagram summary tables I list all the groups by symbols. Secondly on indexing, extended or not, agreed there's some confusion, but I can't see exactly until things are properly defined. I just did one update, removed one of the lower-right graphs that didn't match in the folding. I have 2-3 extra busy work days this week, so unsure when I can do more. I'll try to more carely make an enumeration table of the groups and names. (Perhaps I should make some parallel Dynkin symbol codes elements like CD, so they can be more easily built up. Less combinations than CD, since no rings!) Tom Ruen (talk) 11:29, 6 December 2010 (UTC)

Ah, I found Affine Dynkin diagrams. Good! This superscript syntax is defined at least! I wish I had more time, but at negative time now! Tom Ruen (talk) 11:44, 6 December 2010 (UTC)
Cleaned up link formatting. —Nils von Barth (nbarth) (talk) 21:46, 6 December 2010 (UTC)

Agreed, actually listing the affine Dynkin diagrams first (before getting into folding!) makes a lot of sense. No rush – I’m busy myself, and it’s holidays. I won’t close this thread until we’ve finished this, so it shouldn’t slip through the cracks. I’ll see about writing a section on affine Dynkin diagrams (so there’s a good place for the diagrams to go, of course).

—Nils von Barth (nbarth) (talk) 21:46, 6 December 2010 (UTC)
Hi Nils. I created element symbols for Dynkins, and added summary tables by dimension, but I'm sure there's some arrow problems. I tried to follow what was in the book chart. I see the superscript (2) implies a 2-order folding of a higher node family, but the A/D extensions still don't make sense to me, like the folded ~A family should have arrows pointing in opposite directions. Dynkin_diagram#Affine_Dynkin_graphs If you can sort them out and correct, I'd be glad. At least the graphs are all enumerated I think, even if the labels (or arrows) are wrongly connected. I'll try to look more at the book on google and see if I can see anything more clearly. Tom Ruen (talk) 20:29, 9 December 2010 (UTC)

Hi Tom – thanks for the fabulous tables!

Agreed, the naming/numbering and arrows for the higher families are really confusing to me too – I’ll see if I can figure out what’s going on.

—Nils von Barth (nbarth) (talk) 23:53, 9 December 2010 (UTC)

Arrow confusion[edit]

Hi Nils. I've been nervous about the arrow issues, and I found examples of reverse definitions:

  1. [2] Notes on Coxeter transformations and the McKay correspondence, By Rafael Stekolshchik, 2008: Folding examples - Bn arrow directs inwards, Cn, arrow directs outward.
  2. [3] Reflection groups and Coxeter groups, By James E. Humphreys, 1990 - B~n arrow directs outward
  3. [4] Infinite dimensional Lie algebras, Victor G. Kac, 1990 - Bn points outward
  4. [5] Page 7 - finite foldings with arrows and letter names

All but the first seem consistent, and the last defines the arrow directions in relation to foldings, so if I assume that is the correct standard, all my folding arrows are reversed, and B/C relations reversed!

Geometric folding Dynkin graphs.pngGeometric folding Dynkin graphs affine2.png
Geometric folding Dynkin graphs.pngGeometric folding Dynkin graphs affine.png

What do you think? Tom Ruen (talk) 04:27, 16 December 2010 (UTC)

I decided to update, corrections seem solid. Tom Ruen (talk) 03:56, 17 December 2010 (UTC)

p.s. Below is a table from the first book above (by Stekolshchik), page 36 (this page not on googlebooks), showing two naming systems, first is in relation to Quiver_(mathematics) usage. I added these also to the test-new chart above left. Tom Ruen (talk) 23:27, 16 December 2010 (UTC)

Test Affine Dynkin group names.png

Dynkin diagrams[edit]

Hi Nils! At your convenience, I'm interested in your opinion of a table I added to the talk page: Tom Ruen (talk) 08:20, 9 January 2011 (UTC)


Nomination of Inflationism for deletion[edit]

A discussion is taking place as to whether the article Inflationism is suitable for inclusion in Wikipedia according to Wikipedia's policies and guidelines or whether it should be deleted.

The article will be discussed at Wikipedia:Articles for deletion/Inflationism until a consensus is reached, and anyone is welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on good quality evidence, and our policies and guidelines.

Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion template from the top of the article. LK (talk) 13:54, 15 April 2011 (UTC)

DYK nomination of Hōchōdō[edit]

Symbol question.svg Hello! Your submission of Hōchōdō at the Did You Know nominations page has been reviewed, and some issues with it may need to be clarified. Please review the comment(s) underneath your nomination's entry and respond there as soon as possible. Thank you for contributing to Did You Know! — Maile (talk) 01:48, 1 December 2013 (UTC)

DYK for Hōchōdō[edit]

Callanecc (talkcontribslogs) 03:32, 16 December 2013 (UTC)

A barnstar for you![edit]

Writers Barnstar Hires.png The Writer's Barnstar
After spotting Hōchōdō on the Main Page, I took a tour through some of your other article creations - there's some fascinating stuff in there. Thanks for your work improving the encyclopedia, and for broadening my education at the same time! Yunshui  08:37, 16 December 2013 (UTC)

International comparison of bikelanes and shared lanes[edit]

Hi Nbarth, I've written a table showing a selective international comparison of bikelanes and shared lanes only in German and French. Though my capability of English is much better than that of French, I'm too lazy to write an English version, too.

Do you like to translate it and place it in en.wikipedia, and perhaps to add some more information on USA and Canada?

Cheers, Ulamm (talk) 21:03, 8 October 2014 (UTC)

Euler class, Pontryagin class, Vandermonde determinant, Discriminant[edit]

You might be interested in this discussion: Math Overflow. --Kamsa Hapnida (talk) 17:01, 16 October 2014 (UTC)

Problems with PlanetMath attribution template[edit]

Hello Nbarth, I saw you have edited Template:PlanetMath attribution in the past. Unfortunately the template seems to have some bigger problems at the moment, see Template talk:PlanetMath attribution. If you have background knowledge about this template (or know someone else, who has), your help would be greatly appreciated. I know too little about the interface and its connected math website to be of much help myself. GermanJoe (talk) 21:51, 12 November 2014 (UTC)

Re open and closed classes in Japanese[edit]

Do you know of any sources that address this matter? I don't know the language, but it seems to me that if new verbs are sometimes (even if we say "rarely") introduced by adding "-ru", then it can't be said conclusively that verbs are a closed class. Is it really significantly more common for a new pronoun to be introduced than for a "-ru" verb to gain currency? And are pronouns even a word class in Japanese? W. P. Uzer (talk) 08:31, 22 February 2015 (UTC)

Hi W.P.,
Thanks for bringing this up; I’ve added lots of sources and clarified as of this edit.
You’re correct, pronouns are a disputed class in Japanese; added reference for analogous situation in Thai and Lao (open class).
Verbing by adding -ru is a recent and marginal innovation, so their closedness has weakened some, but verbs (and more so, adjectives) as closed class is an accurate description of Japanese word categories for over 1,000 years: Chinese words were imported as nouns, being used as (inflected) verbs or adjectives extremely rarely – at least 1,000:1, probably 10,000:1.
—Nils von Barth (nbarth) (talk) 01:01, 23 February 2015 (UTC)
Great, thanks for the reply and your edits, that's clarified it a lot. W. P. Uzer (talk) 10:47, 23 February 2015 (UTC)


But I do have another objection - ideophones are surely not a part of speech or word class in the way the notion is normally understood? These are words with a certain type of derivation, not with a particular type of grammatical behavior. W. P. Uzer (talk) 10:55, 23 February 2015 (UTC)

(>.<) You have a sharp eye.
You’re right, the classification of ideophones is debatable, and strictly speaking it’s a phonosemantic word class (term used by some), based on derivation. However, even grammatically “in the vast majority of cases” they’re a category of adverbials (Japanese is typical in this respect, and many African languages are likewise). I’ve added a note and refs elaborating and qualifying at this edit, and over at Ideophone in this edit. See especially the Childs ref, which discusses their classification and open status.
Does this improve matters?
Thanks for your (quite constructive) criticism!
—Nils von Barth (nbarth) (talk) 03:55, 24 February 2015 (UTC)
Again, thanks, yes, that certainly clears things up. W. P. Uzer (talk) 07:50, 24 February 2015 (UTC)

Closure (computer programming)[edit]

I'm not too happy with this edit. This discussion really only applies to lexically scoped languages and not to dynamically scoped ones (dynamic scoping is what you get if you try to implement first-class functions without using closures, as early LISPs did), so this would be an important distinction to make. —Ruud 12:33, 26 February 2015 (UTC)

Thanks for bringing this up, and good point.
I was just being picky about the term “scope” (strictly “a region of code where a binding is valid”), but the distinction you point out is gets at the core of what a closure is: it’s about name binding, and accessing variables outside their scope (through a reference). (I avoid the term “dynamic scoping” in favor of “dynamic binding” to emphasize that it’s the binding rule that differs.)
As of this edit I’m rewritten it to emphasize that it’s the static binding that’s at the root of a closure. The result is a bit longer, but seems to front the essence of closures (which are hard enough to explain anyway!).
How is it?
—Nils von Barth (nbarth) (talk) 05:53, 27 February 2015 (UTC)
I had a try at rewriting the introduction myself, I hope it is agreeable with you. As I removed several of the paragraphs you introduced, or otherwise undid some of the changes you made, I think I should explain why:
  • Yes, closure are all about name binding, more specifically an implementation technique for achieving lexically scoped name binding. I made this into the first sentence of the article. (It's at least as important to explain why a closure is, as what a closure is.)
  • What I realized after writing most of the text below is that, when talking about name binding, it is important to distinguish between the static binding structure of a program and the dynamic binding structure (if a recursive function refers to one of its local variables, than it will refer to one particular variable (definition, binder) in its static binding structure, but it will refer to different (substitution) instances of that variable in its dynamic binding structure). As closures only show up in the dynamic semantics of a language, I think they are about dynamic binding structure and what I wrote below should be consistent with that. Our article on Name binding currently does not seem to address this issue at all...
  • Terminology: note that there is a distinction between when name binding is resolved (at compile-time or run-time; let's call this early binding/static dispatch respectively late binding/dynamic dispatch, even though that's not how these terms are exactly used in practice) and where a name gets bound to (the named thing closest to you in the environment of the static semantics of the language, or closest to you in the environment of the dynamic semantics of the language; let's call this lexically scoped respectively dynamically scoped). Now, early binding/static dispatch usually implies lexical scoping and dynamic scoping implies late binding/dynamic dispatch (because resolving dynamic scoping at compile-time in general is an undecidable problem). This means people will refer with the terms static scoping to either early binding, static dispatch or lexical scoping, and with dynamic scoping to either dynamic scoping (in the sense I defined earlier), late binding or dynamic dispatch (programming language theorists are a bit more pedantic and because of this, as well as disregarding early and late binding as uninteresting implementation details, will indeed mean lexical scoping when they talk about static scoping, but most programmers tend to be a bit less precise.) This is quite problematic, as it is perfectly possible to have lexical scoping and late binding; this is exactly what closures do: the scoping is lexical, but binding is resolved at run-time using the environment in the closure. For this reason I think it's best to use the unambiguous term "lexical scoping" over the ambiguous "static scoping", at least in the introduction. (This is also the reason why I removed your footnote "Static binding is usually but not always done at compile time. ..." As explained, this is not correct when using closures. The line between early and late binding is arguably a bit blurry, though: is a binding of a name referring to a function parameter resolved at compile time because the parameter can be found by adding a constant offset to your mark pointer, or is it resolved at run-time because the parameter can only be found by adding a constant offset to your mark pointer?)
  • Regarding the example, as code fragments are the programmer's equivalent of "a picture is worth a thousand words", I think it's important to give it in the lede (it was previously in a separate section and after checking some StackOverflow questions referring to this article, I think it's safe to say that most people don't bother scrolling down past the table of contents). The only reason why I believe programmers find closures difficult to grasp is that they are unfamiliar with nested functions and thus with free variables. An examples should make them understand this aspect more quickly than a theoretical explanation. I also think it's important to give the example in pseudocode, mostly for the reasons given at MOS:PSEUDOCODE. It think the current psuedocode also strikes a good balance between the two languages with first-class functions that readers are most likely familiar with (Python and Javascript). Both languages are not ideal for discussing issues related to scoping: Python because it has implicit variable declaration, occasionally requiring nonlocal annotations, and Javascript because it's scoping rules are a bit odd in general.
  • Some nitpicks: "in some cases (such as ML) it contains the values of each of the names", I think most ML compilers store references to immutable values in closures instead of the values themselves, Java and C++11 are two of the few languages I know that store actual copies of the captured variables. "or passed as arguments to other function calls", closures are used for this in most functional languages, but they are not necessary as access links in the activation frames suffice. "do not support calling nested functions after the enclosing function has exited", Pascal achieves this not by disallowing the call or segfaulting (as GNU C does), but by disallowing functions to return other functions (taking them as arguments is fine) and disallowing functions to be stored in data structures, avoiding them from escaping from the scope of their free variables and thus the upwards funarg problem.
Cheers, —Ruud 12:00, 28 February 2015 (UTC)
Thanks Ruud for your very thoughtful edit and response; I agree it makes the article much clearer!
In particular, thanks for tightening up the intro – agreed that leading with an example is important. (Frankly the practice is simpler than the theory, though implementation…)
I didn’t know about MOS:PSEUDOCODE; it makes sense, much as one might think Python is basically pseudo-code ;) – thanks!
AFAICT the main items you cut were rather wordy discussions of what was binding to what; agreed that these obscure the main point, though perhaps they can usefully be incorporated at name binding or non-local variable.
I slightly tweaked the wording in this edit, and made some minor edits in the body of the article, but otherwise don’t plan to make any further significant changes to the closure article at this time.
I’ll see about working on Name binding, Nested function, Non-local variable, and Funarg problem though, in particular incorporating your notes above. Cheers!
—Nils von Barth (nbarth) (talk) 23:55, 28 February 2015 (UTC)