@tohecz $\lvert ab\rvert=\lvert a\rvert\lvert b\rvert$, in particular $\lvert-b\rvert|=\lvert b\rvert|$. However this is mathematically incorrect: $\lvert-b\rvert|=\lvert b\rvert|$ by definition.
@percusse Again implication only. I think the original expressions by @tohecz are best, I only don't like the sound of "particularly" (and you need to be completely sober saying it).
@StephanLehmke I think I'm trying to express what egreg has commented. This is not a derivation of |-b| = |b| it's another validation, since abs(.) is well defined.
this also shows that my proposition is also not good :)
@egreg it wouldn't. It depends on what you emphasize at what place. I don't write axioms of norm anywhere and I don't prove that the map I call "norm" is a norm since it is obvious. I just need to some stress that - has "the same" properties as + (in this case, continuity).
This has the same problem of having if and only if in the definitions. If you define it then it's iff anyway, if you derive it you derive a definition which is circular.
@Mohan Minor point: the link you put in your torn paper question is not to JLDiaz's website but to TeXample (which is run by Steffan Kottwitz, or some variant thereof).
@tohecz This way of doing things reminds me of the "proof" of the infinitude of primes via the divergence of the harmonic series and Euler's infinite products. :) If it's obvious that it's a norm, there's no need to stress that ||a||=||-a||.
The Plain TeX
$$ \sum_{i \in S \atop j \in T} i $$
seems to be usually typeset mathematically in LaTeX using the \substack macro from the AMS maths macros (accessed using \usepackage{amsmath})
\[ \sum_{\substack{i \in S\\ j \in T}} i \]
which gives slightly different results, most important...
@egreg algebra is a set with finitely or infinitely many operations. I construct a counterexample to some statement about topological semirings so I want to be really clear in what I define and how.
@PauloCereda When I first started my PhD, my supervisor asked me how I've designed my controller for a particular robot. I've started the sentence by well I've obtained a group of matrices from an experimental setup... and he was already disapproving with his head murmuring matrices are not groups. I should have seen it coming :D
And I was a working mechanical engineer.... Now I need to state field of characteristic not being equal to 2 in any conversation with him. So that was a long way you can imagine. :)
@kan sorry I didn't understand the original problem. If you go \def\Exercise#1{Exercise #1} Then \begin{Exercise}{2.10} will print Excercise 2.10 but somehow I don't think that is what you mean?
@percusse Mathematicians are just hard to talk to for normal people. One careless use of "onto" and they'll stop listening, pondering instead whether you're just presenting a deep insight or are just plain stupid.
@DavidCarlisle You are right about thinking that way... the apparent complication arises from the fact that Exercise is a modified theorem environment, so, I should be passing arguments like: \begin{exer}{2.10} which sounds fishy... but something I have seen implemented certainly.
@AndrewStacey And it's frightening over there (assuming MO) :) Why don't you take @egreg for a trip there, he can surely survive and most probably make it better.
@StephanLehmke Yes, I didn't understand it for a long time. I didn't even know about the difference having for all at the beginning and at the end of the proposition.
I think it's OK if the etiquette is stated more clearly somewhere. This is very typical of student fraternities where you screw up something and you don't even know. There are unwritten rules.
@kan It's not so difficult. \newtheorem{x}{X} just defines some commands that use X as the theorem name. But it's not necessarily a string, it can be any token list. If it contains a macro like \exernumber, the current meaning of \exernumber is used. So I use a "wrapper environment" that absorbs an argument with which it gives a meaning to \exernumber. Et voilà. :)
@kan no, just unexperienced, as all us are are or were. you begin by understanding the tricks, and once you understand a trick, you can try to reuse it or modify it. And then, as time flows, you get to know more and more of them, et voila!
@HenningKlevjer OK then how doesn't it work? Appearing question marks or undefined references? Are you putting your labels inside or outside etc. Can you replicate the issue with a simple example with one figure or algorithm?
@HenningKlevjer well if it's not in the aux file \ref won't find it. But there could be any number of reasons for it not being there. \includeonly for example
@HenningKlevjer That's OK: It will all work fine unless you stop it working:-)
\includeonly speeds up processing during drafting by just re-using aux file from previous run of the skipped files, but that means that it uses stale information, if you add a new \label or new numbered section, or basically anything to a chapter then references to that chapter and all following numbers might be wrong until you next process that chapter. The idea is that that doesn't matter at draft stage if you just want to quickly proof chapter 100 without processing chapters 1-99
@PauloCereda I'll try to attack the bounty then :)
I'm always intrigued by the stability of error reporting mechanism of Windoze. It's working quite stably maybe they should extend it to the rest of Windoze.
@DavidCarlisle I have some close friends from Mathworks and they were discussing the items that are appearing on Abandon Matlab blog. Then this came up :)
Hi all! Reading up on LaTeX3. Just curious about the D argument specifier. Specifically: why is it an argument specifier? You cannot 'not use' one argument. It seems to me like it should have come to the left of the :.
When I'm reading about LaTeX3, I can't help but question some of the design decisions. I'd love to discuss that sometime. (Though I don't really have a lot of time lately.)
Though I guess I'm a bit late, seeing as how the interface is now fixed.
@tohecz The D specifier is a minor example. More importantly: I'd have separated type information (what the callee needs) from expansion handling (what the caller needs). Then I'd generate argument handlers on the fly rather than requiring them to be explicitly declared.
well, this is IMHO close-to-the-best decision in LaTeX3, because as a caller, you need to know, whether your callee is going to fully expand the contents, or pass them as-is etc.
@mhelvens lots of people wonder why the :mmm bit is part of the command name rather than some kind of dynamic function modifier, but it's really hard to make the latter work, so many places really need the function names to be a single token to get anything like reasonable behaviour/speed
@mhelvens Well :D is more of a marker, but it's in some ways the same a :w - it does not mean 'one argument' as much as 'you have to know what you are doing'!
@tohecz My point exactly. :-) Expansion control SHOULD be in control of the caller. Whether the thing that is eventually passed, however, is a token or a tokenlist or... whatever, should be in control of the callee.
@mhelvens Certainly the team have looked before at doing variants on-the-fly, and this did not work in a practical sense (or at least could not be done by the team members at the time)
@JosephWright I realize that. I'd just like to understand how that lead to the current design of LaTeX3. It may very well be that I'm flat wrong. :-) But I want to understand.
@JosephWright Please note that I (stupidly) mention two separate issues in one chat-message there.
@JosephWright One about on-the-fly expansion. The other about separation of concerns.
@mhelvens As @DavidCarlisle says, having things as one token can be important, as is the fact that TeX will complain before we can 'intercept' undefined csnames
@mhelvens I have no formal programming background, so simple examples are handy :-)
@JosephWright Yes, 'one token' can be a valid argument type imposed by the callee. In that case, 'non-expanding tokenlist' would be an invalid expansion strategy on the caller side.
@JosephWright Well, it seems to me that the function itself (the callee) should have control over what kind of information it receives. The caller should have control over how to generate that information (the expansions strategy). Those two 'concerns' are now mixed up in what you call argument specifiers. This means you can not get proper encapsulation.
@mhelvens well that's basically the idea in L3 the "function" has control over the basic functionality (and basically should use n arguments) which is called via a thin wrapper which uses :mox whatever which controls the expansion that happens before the base function is called.
@mhelvens Where the function is used, something like \foo:nno means 'first expand the last argument once, then do \foo:nnn'. Thus it's still down to the base function to do 'stuff'
A good example of that is \int_set:Nn where the n-type argument has to be something that will turn into a numexpr on expansion
@JosephWright Yes, I understand. Ok, example: You offer both N and n as argument specifiers (or: caller decision). But whether the function can handle a single token or a braced set of tokens (or a function, or a csname, or...) should be up to the callee. How to generate it should be up to the caller. Both are now encoded in argument specifiers.
@JosephWright @DavidCarlisle @tohecz It was not my purpose to start a full-blown discussion right now. :-) I don't yet know enough about LaTeX3 to say anything with certainty. My apologies. If I every raise an issue like this again, I'll do it with examples and more well-reasoned arguments.
@mhelvens The reason for having these is that they are both sensible at the 'base function' level. There are many cases where you want different behaviour at the \foo:n and \foo:N level (see for example handling of comma lists, where the n functions strip spaces, but stored lists are already processed and so N does no stripping)
Our next interviewee:
Ulrike Fischer
Interview scheduled to Thursday, December 13th, around 13:00 UTC. Everybody is invited!
Lost with the UTC time? Click here to see the event time in your local timezone. :)
@mhelvens I guess you'd prefer we had just 'pure' expansion in the spec, with the 'different handling' in the name. There is of course an argument for that (see for example \str_if_eq_x:nn), but the n/N base stuff works quite well in concert with how we actually want to process arguments.
@tohecz That's not true. DocScape for instance has a much different "language level". It's just a question how much overhead you are willing to accept.
@JosephWright Indeed, that would have been my suggestion. And indeed, it would have been more verbose at times. What you're doing is overloading on parameter types. But I'm not sure that could be done properly in TeX anyway (i.e. determine whether a given actual parameter is a single token, or a list, etc. and dispatching different implementations based on that).
@JosephWright The main question is: Will people use this to define math symbols or graphic objects other stuff which is evaluated a real lot during document generation. In that case it'll get really critical.
@mhelvens The problem is not only detecting what is given (can be done, but time cost could be too high), but also if you are passed \foo, is it a single token list or a macro used to store a passed list.
@StephanLehmke True, but even then there are other issues. Simply saying that a primitives-only approach is faster is not necessarily true as each loop, etc. is then done by hand and it's easier to mess up.
@mhelvens I see what you are after, but I'm really not sure the effort is worth it, nor am I sure that hiding whether a macro expects a variable or an arbitrary list is really that helpful
@JosephWright That's the tradeoff between speed of development and speed of execution. But indeed it is well-known that while high-level languages (like prolog) execute slower on a benchmark level, it is much easier to express complex algorithmic optimizations or caching techniques in them so the system as a whole may be more efficient.
A question, if I may: How would you draw a border around some content without enclosing it in a TeX scope? It may contain \defs that have to survive past the border.
A very strange question, I agree, mixing visual formatting with definition scope. :-)
I get this error trying to execute my code:
I don't know what has changed that caused this error but going through preference, I don't seem to know what should be done there and what's wrong.
@mhelvens oops sorry connection dropped and lost my edit. in the output routine or uisng \pdfsavepos to get the coordinates or using tikz or pstricks coordinates
@DavidCarlisle \pdfsavepos sounds pdf-only. tikz feels a bit overkill, (though I guess I could get it to work). Could you point me toward an explanation of the output routine solution?
@mhelvens I was thinking about N/n on my cycle ride home. There are actually very few cases where there are two functions with the same name but a variation in this only (some for clists come to mind). So as much as anything the difference here is about keeping us 'honest', as TeX does mind about single tokens quite a bit.
@JosephWright The 'honesty' you describe is what we call type-correctness. Don't give a string to a function that expects an int. Or in this case: don't give a tokenlist to a function that expects a single token. My earlier point was that this should be dictated by the function-definition, not by the one who calls the function.
@JosephWright That being said, I would still allow the caller to give a token list to a function that expects a single token, as long as exhaustive expansion is specified and the caller is sure that it will expand to a single token.
@JosephWright Additionally, I would employ some kind of runtime-typechecking to make sure that the right thing is actually passed, so you can supply the programmer with useful error-messages.
@JosephWright And of course allow the programmer to disable runtime-typechecking when performance is a factor.
The Community Promotion Ads - 2013 question has recently appeared on meta. In a comment there, tohecz points out that the stats for the 2012 ads show that older ads get far fewer clicks than newer ones. This raises the question of how many ads to reuse, and more generally what makes a good ad. Th...
@mhelvens We do have some runtime checks, mainly to deal with the fact that TeX registers have to be defined but macros do not
@mhelvens Other way around. In for example \cs_set:Npn, we are providing a wrapper around \def. That has to have a single token first argument, so braces from an x-type expansion are a disaster.
At one point, we had a whole family of 'one token, no braces' specs. They got dropped in a big refactor.
@JosephWright Exactly in the case I described before: The function needs a single token. The caller can supply a braced token list of which he's sure could expand into a single token.
@JosephWright I suppose you would eventually run out of letters in the alphabet. That's why I would also have made the argument specifiers a bit more flexible and delimited somehow, so you're more future-proof.
@JosephWright Exactly! That's why mixing everything up into a single letter may not have been the best design choice.
@mhelvens We did talk about creating more, but the result of the refactor was to cut them down.
For example, we had d (double expansion), but it was used about half a dozen times in total in places where replacement was tricky. So it made sense long-term to cut down to a sensible minimum.
@JosephWright What I would probably have tried was a scheme where you separate different 'dimensions' of argument modifiers. So: \name:(xt)(xl)(nt)(nl). That's a function taking a token, list, another token and another list. The first two are expanded, the last two are not expanded.
@JosephWright Everything else left the same, yes indeed. But as I said before, I'd do other things differently too. So when defining a function, you only have to give the second modifier (per argument). When calling it, you only give the first.
@JosephWright I understand. But note that this is just an example.
@JosephWright You're asking me how I would implement it in TeXe? I'm not experienced enough to give you a detailed answer there. Still, I'm convinced it would be possible. And elegant.
When I started on expl3, the decision was very much how to tidy up the arg spec, so some of the basics are better asked to @FrankMittelbach or @DavidCarlisle, by the way
@mhelvens Yes
@mhelvens In particular, remember you have to define names before you can use them :-)
Another point to bear in mind is the 'finish stuff' problem. When we did the refactor on arg specs (and in other places), we do have to make a decision at some point. It took 15 years to get a decision on arg specs that was stable!
@JosephWright That means you can no longer 'overload' on argument specifiers. But you can compensate for that in different ways. Changing the name itself is one. But you could also have 'real' overloading, by checking the argument type.
@JosephWright May I ask which part of the pgf you meant in your comment? I'm reading it and indeed there are some instances I am not really sure if that's the best practice on certain things.
@JosephWright Note that with my new scheme, you could use (as the 'expansion part' of an argument) 2, 3, 4, x, whatever to denote specific expansion strategies.
@mhelvens The thing for me is that the scheme we have does work, and I find it reasonably clear. I'm happy for people to make better suggestions, but we could argue for ever about lots of things (for example, the choice of : and _ continues to cause some comment)
One issue which springs to mind using an active : is that there are cases where it's very handy that functions are a single token. If you 'free' the arg spec, life becomes more complex
@percusse The one that comes to mind may no longer apply. When I wrote l3keys, I took the original idea from pgfkeys. That was a mission, as while the interface is good the code was not.
@JosephWright Remember we discussed this some weeks ago. We could do it without looking ahead. You could just pre-define all argument specifiers up to a certain length ahead of time. Probably a better solution would be to use currying. Are you familiar with that concept (see: functional programming; lambda calculus).
@JosephWright Currying would probably be a great solution, both for performance and flexibility of the language. But this does imply that any function 'name' would have a variable number of 'parts' (each argument specifier would need its own token), so even the 'two token' idea I gave before would not save us there.
@JosephWright No, just linguistic curiosity. I think 'sled' vs. 'sledge' is N. American vs. British usage; but the image in the animation for me I would call a 'sleigh', since 'sled(ge)' is more of a small thing than something with a seat.
@JosephWright Sorry for all my babbling. :-) Currying would be nice, but it would be exceedingly difficult to do that while maintaining the current LaTeX3 interface (if not impossible). You would probably want a scheme such as \name:x:y:z. Still, it could work. I'm telling you, I'll create a demo sometime.
@JosephWright I just subscribed to LATEX-L. Pf, as if I needed yet another way to procrastinate. :-p
@JosephWright Passing functions around is actually easier with my scheme. You just pass the name, not the argument specifiers. If you want to call it again 'on the inside' you give the argument specifiers you want right there. Since argument specifiers (in my scheme) are up to the caller.
@JosephWright However, if you are intent on sending the 'whole package', you can always wrap it in another macro and send that.
@JosephWright That reminds me of another useful type of argument you could support: anonymous functions: as in, brace delimited token-lists that can contain #1, #2, etc. On the inside of the function it would be delivered as a cs.
That one you could still add, by the way, in the current LaTeX3 scheme.
@JosephWright Anyway, I gotta go. It's been a nice discussion, but we'll have to continue it another time. Cheers!
@AlanMunn Depende dos mineiro, uai. :) Granted, it's a common expression in the whole country. :) If I turn my caipira mode on, the replacement algorithm is executed. :)
I vaguely seem to recall reading that \newenvironment* gives better spacing than \newenvironment, but I don't recall any details and I can't seem to find a reference by searching. What is the difference between these two, and when should one be used rather than the other?
[Note: I'll be happy f...
I just spotted someone use \newcommand* in an answer and realised that I'd never quite sorted out in my head what the star (asterisk) was there for.
(This one is practically impossible to search for on the internet so this is a good place to record the answer!)
I suspect that \newcommand and \newenvironment are quite different conceptually in people's minds and so having an environment question point to a macro question won't seem so natural.
Also, although the meaning of * in the two cases is the same, having one answer might lead to a more general interpretation of what * means, which of course isn't true across packages.
One thing that came up in the discussion with Vivi last night was that I've noticed that a lot of the fast close votes are coming from users who are 'medium rep'. That's not necessarily a problem but we now have lots more users with close voting privileges who don't necessarily have the institutional memory of the meta discussions that talked about these issues. I wonder if there's a way to remedy that?
@AlanMunn Not really, I suspect. The overall network model is much more skewed toward 'close fast, reopen after edits' than we favour. Getting the tools altered is more-or-less impossible.
@AlanMunn It is important to leave appropriate comments, of course
@AlanMunn Comments are the best plan, but once people have voted they don't see them. As we can't tell who votes until after the questions are closed, it's a bit tricky
For the question at hand, someone could provide the fifth and final closing vote, so that @JosephWright could immediately reopen it (and hereby clear all closing votes).
The Plain TeX
$$ \sum_{i \in S \atop j \in T} i $$
seems to be usually typeset mathematically in LaTeX using the \substack macro from the AMS maths macros (accessed using \usepackage{amsmath})
\[ \sum_{\substack{i \in S\\ j \in T}} i \]
which gives slightly different results, most important...
Our next interviewee:
Ulrike Fischer
Interview scheduled to Thursday, December 13th, around 13:00 UTC. Everybody is invited!
Lost with the UTC time? Click here to see the event time in your local timezone. :)
I get this error trying to execute my code:
I don't know what has changed that caused this error but going through preference, I don't seem to know what should be done there and what's wrong.
I just spotted someone use \newcommand* in an answer and realised that I'd never quite sorted out in my head what the star (asterisk) was there for.
(This one is practically impossible to search for on the internet so this is a good place to record the answer!)
