User talk:Nbarth

Wikipedia:Babel
 en This user is a native speaker of the English language.
 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
 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 III and is entitled to display this Rhodium Editor Star.
This editor is a Labutnum of the Encyclopedia and is entitled to display this Book of Knowledge with Coffee Cup Stain, Cigarette Burn, Chewed Broken Pencil, Sticky Note, Bookmark, and Note from Jimbo.
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.

Hello!

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.

Awards
 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 For being bald. ;) Paradoctor (talk) 23:40, 18 March 2010 (UTC)
 The Original Barnstar Thank you for your work on the Corecursion article! WillNess (talk) 08:22, 6 October 2013 (UTC)
 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)
 The Good Heart Barnstar For your constructive comments and courtesy while discussing the redirect page ‘no criming’ WPCW (talk) 11:00, 25 May 2018 (UTC)

Dynkin diagram folding

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).
• 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 ${\displaystyle A_{2l}^{(2)}}$ – the tildes correspond to the first series ${\displaystyle {\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 (${\displaystyle 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 (${\displaystyle A_{2l}^{(2)}}$ etc.), since some are from the second series.
• Add the ${\displaystyle 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 (${\displaystyle G_{2}^{(1)}}$) should instead be ${\displaystyle 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 ${\displaystyle k-1}$ (remember, extended adds one vertex above the index – this is right in the finite diagram).
Secondly, the target is notated by ${\displaystyle D_{k+1}^{(2)}}$ (arrows are opposite of C~).
D~k+2 → B~k+1
This maps to ${\displaystyle A_{2k+1}^{(2)}}$ – arrow is backwards for B~.
E~6 → F~4
This maps ${\displaystyle E_{6}^{(2)}}$ – arrow is backwards for F~4.
D~2k+1 → C~k
This maps to ${\displaystyle 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

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!

 Corrected? old

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)

Dynkin diagrams

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)

Talk:Dynkin_diagram#Meaning_of_branches

International comparison of bikelanes and shared lanes

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.

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

Hi Ulamm,
Thanks for the note, and apologies for the reply years later!
I've added added a note to the page in case anyone wants to translate it.
I don't have the time, but an international perspective would be a great addition, and your table is very useful; hopefully someone will get to it, now that it's more visible!
—Nils von Barth (nbarth) (talk) 21:07, 17 June 2018 (UTC)

Euler class, Pontryagin class, Vandermonde determinant, Discriminant

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

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)

Closure (computer programming)

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)

Sytem virtual machine

This article was created by you and the title contains a misspelling. Should it be moved? There is already a page named System virtual machine that redirects to Virtual machine.

Aisteco (talk) 20:19, 16 October 2015 (UTC)

OMG, *embarrassed* (sorry, embarassed [sic] ;)
Thanks so much!
This was from a split that I haven’t gotten around to finishing; see Talk:Virtual machine#Split into separate pages for systems and process.3F.
I’ll split it properly and see about deleting the useless misspelling, then update here – thanks again!
—Nils von Barth (nbarth) (talk) 02:16, 19 October 2015 (UTC)
:) I figured that was the case.
Aisteco (talk) 02:43, 19 October 2015 (UTC)

Server (computing)

Hi.

I'm calling you regarding something that I found very difficult to do: Reverting several (but not all) of your contributions to Server (computing) article on 15 February 2015. Now I am sure you did them in good faith and there was a lot of good ideas in your contributions, but the text was generally problematic: You had used aberrant forms of word and phrases all over the article. Strange word forms hide the meaning completely, rendering the article unreadable. MOS:COMPUTING § Collocation can help.

In addition, the lead should be a summary of the whole article, and devoid of both novel info and complications.

Please preview your own edits more often. I will read what you wrote again and will try to salvage parts of it.

Best regards,
Codename Lisa (talk) 15:49, 15 February 2016 (UTC)

Hi again
I had a small group of college students read your version of the article and they said the problem was complexity, not so much as bad word forms. They said flooding the lead section with unnecessary jargons like "one-to-one", "one-to-many", "many-to-many", "backend", "microservice", "load balancing", "partitioning" and "sharding" was a bad idea. These need to be elaborated.
I tried reducing complexity and adding a picture too. Give it a read and tell me what you think. I could use your opinion. (Sure, I reverted you once but in general, you do good work.)
Best regards,
Codename Lisa (talk) 17:23, 15 February 2016 (UTC)
Hi Lisa,
Thanks for the cleanup, and thanks for the thoughtful note!
Agreed, I put far too much terse detail into the lede. I don't believe that any of my usages were incorrect (I'm extremely careful with word usage, and spend a lot of my editing time on that), but agreed that it was jargon-heavy. Thanks for your cleanup; I'll have a shot at incorporating the content into appropriate sections.
A key concern for me is that the article's lede presented a narrow, 1970s-90s view of what a server is (a massive minicomputer serving many clients), without covering current practice (usually clusters of cheap computers, with very varied system architectures). I'll try to balance without complicating; feel free to edit yourself with our without consulting me, but I'm happy to work together!
—Nils von Barth (nbarth) (talk) 04:57, 16 February 2016 (UTC)
A lot better! It has been a pleasure working with you. I made one or two correction but I don't insist on them.
By the way, if you don't mind, I remove {{citation needed}} above (which a third party has added) because it categorizes your talk page into the category of pages needing citations.
Best regards,
Codename Lisa (talk) 14:22, 16 February 2016 (UTC)

Levy-Ito decomposition and Lebesgue decomposition

Good afternoon!

You made some changes quite some time ago to Lebesgue decomposition and Lévy_process#L.C3.A9vy.E2.80.93It.C5.8D_decomposition discussing the relation between them. Do you have any references for the statements that you added? I have left quite a detailed comment at Talk:Lévy_process#Levy-Ito_decomposition_and_Lebesgue_decomposition explaining why I don't think the relation is precise as stated - perhaps it is an interesting analogy, but I wasn't able to see a way to make it into a one-to-one correspondence. What do you think? Thanks! Alex. 130.88.123.107 (talk) 17:26, 18 January 2017 (UTC)

Sorry about that! You're right, it's just an analogy. I'll make that clearer, and elaborate that they have different continuity properties, with citations, as you indicate. I'm currently traveling, so feel free to go ahead with changes, but I'll clean up and notify you for review. Thanks again! —Nils von Barth (nbarth) (talk) 16:37, 15 February 2017 (UTC)

PDIFF as a category

Hi — in 2009 you added some material regarding PDIFF to piecewise linear manifold. Today I received an email from one of my coauthors complaining that although one can talk about piecewise smooth manifolds on an individual basis, PDIFF is not really a category, or at least the sources do not support it being a category. I have to admit that to me the sourcing to PDIFF looks weak. Do you know more about this? Is there justification for calling it a category despite Google scholar finding almost nothing when one searches for "category of piecewise smooth manifolds" (or differentiable in place of smooth)? If not, should the category-theoretic language surrounding this material be removed? —David Eppstein (talk) 05:00, 1 June 2018 (UTC)

Hi David,
I'm traveling now, so I can get back better in a week or so.
The main reason for the lack of references is that it's a minor technical point, hence no one bothers working it out; it's oral folklore.
There are probably a few subtleties in making it precise; Thurston (p. 194) writes:
Show that [maps from Rn to itself] don't form a group. Thus, piecewise smooth maps serve as bridges between piecewise linear and smooth structures; they don't work well alone.
That said, he calls the self piecewise smooth homeomorphisms a pseudogroup, so I think the category axioms (identity obviously, and composition) are fulfilled, but inverting doesn't work (unlike in PL)?
I assume the only objection to this being a category is that it's not obvious that a composition of piecewise smooth maps is piecewise smooth, because the triangulations don't agree (gives maps from X to Y to Z, the triangulation on Y may not agree with the image of the triangulation on X, or rather not pull back properly). I think this is the same issue for PL, and the answer is to actually have equivalence classes of piecewise linear/smooth structures.
Basically all the "essentially unique" results predate the popularization of category theory, hence they're not stated in that language.
I haven't been working in math since grad school (over 10 years ago), so I'm not the best person to ask.
Probably best would be to ask Curt (Curtis T. McMullen, ctm@math.harvard.edu), whom I'm referencing (Re: PL and DIFF manifolds: a question), or my advisor Shmuel Weinberger (shmuel@math.uchicago.edu); if you mention me they'll recognize it, and might be able to clarify. (They're both quite prominent, and if there's a mistake or gap in the literature, Curt might be inclined to rectify it.)
I can have a shot at rewording it so it's more accurate about what the literature actually states.
—Nils von Barth (nbarth) (talk) 03:18, 2 June 2018 (UTC)
It's the composition my correspondent is worried about. The problem is that unless there's more to the definition than the obvious, the triangulations may not agree, badly enough that you can't piece them together into a common refinement. —David Eppstein (talk) 04:36, 2 June 2018 (UTC)

Haplography?

Just came across your edit of Full stop done 2008 April 13 at 07:25, and I would tend to disagree. As it says in the Haplography entry, it is an erroneous change in copied text, not an intentional change, leaving out a duplicate character.

What do you say? WesT (talk) 22:36, 8 June 2018 (UTC)

You're referring to this change, correct? Thanks, I've fixed it!
—Nils von Barth (nbarth) (talk) 20:10, 17 June 2018 (UTC)
Absolutely! Thanks. WesT (talk) 20:40, 18 June 2018 (UTC)
Hmmm...Just went to look at the page, and I found that only FIVE minutes after your edit, your italics were removed. I really liked the emphasis on the UNintentional as it is exactly that, but apparently SMcCandlish didn't. He quoted Wikipedia:NOT#NEWS, but after reading that section, I don't see how it applies in this case. Not News seems to discuss content, not style, though that is what he says in his edit summary. Just thought you'd like to know. WesT (talk) 20:51, 18 June 2018 (UTC)
Thanks Westley! I won’t bother disputing it, but good to know.
—Nils von Barth (nbarth) (talk) 22:22, 18 June 2018 (UTC)
WP:NOT#NEWS: "Wikipedia is not written in news style." See also MOS:TONE, MOS:ITALICS, and WP:NPOV. We do not go around brow-beating readers with emotive emphasis. See also MOS:ABBR on not doing example the same kind of font tweaking to browbeat readers with the meaning of an acronym (i.e., we do not write "NASA (the National Aeronautics and Space Administration)". In short, please do not treat our readers as if they were both stupid and half-blind. 05:21, 19 June 2018 (UTC)