Reputation
76,378
Next tag badge:
283/100 score
18/20 answers
Badges
8 227 319
Newest
 Enlightened
Impact
~511k people reached

Jan
29
comment How to make FlattenAt work with Span?
@Mr.Wizard Interesting. Never thought of that. I do use this sort of code in a number of places, so will at some point check the difference and perhaps adopt this method. Thanks for the info.
Jan
27
comment What Mathematica book to buy?
@H.R. Thanks! This is great to know. Yes, I did write it in .nb. At some point soon, I will publish the nb version.
Jan
24
comment Condition and RuleDelayed
Glad it you found it helpful. This is certainly one of the things that I wish to have better understood myself.
Jan
23
comment Condition and RuleDelayed
[2/2] ... rather, it may be a top-level container, that passes that code to some lower-level functionality that actually does the checks. Some analysis in my answer I linked above seems to suggest that this is indeed the case, and the actual heads used for checks are RuleCondition and $ConditionHold. The evaluations in Condition are induced by the pattern-matcher, and are sub-evaluations from the point of view of the main evaluation process for the original expression. Condition taken standalone may behave completely differently, and that does not violate the evaluation rules.
Jan
23
comment Condition and RuleDelayed
[1/2] Since, as you mentioned, Condition can be viewed as a pattern, or, pattern-buiding block, it does not surprise me that it behaves in the special way in the context of the pattern-matching. But I think that the source of this behavior is not in Condition, but in the pattern-matcher, into which Condition must be wired pretty deeply. When the pattern-matcher sees a rule with Condition, it evaluates and matches that rule in a special way. The fact that Condition does keep the test code unevaluated, does not mean that it is actually the function that eventually evaluates it - ...
Jan
23
comment Condition and RuleDelayed
You may find this discussion relevant.
Jan
20
comment Sort by returning positions
@AlGuy No they don't.
Jan
20
comment Sort by returning positions
@JasonB Speed. The way Mathematica evaluator works, SortBy is often vastly faster. The reason is a bit long to explain, but here is one place to look at, and here is another. It could've been discussed also here on this site, but I can't recall where.
Jan
20
comment Sort by returning positions
@Kuba I guess, rather about OrderingBy (which does not yet exist as built-in).
Jan
20
comment Sort by returning positions
Possible duplicate of Retaining and reusing a one-to-one mapping from a sort
Jan
18
comment ReplaceAll behavior change from 10.2 to 10.3
In fact, given that Association serves as HoldAllComplete container (after the key-value pairs have been added, they are not re-evaluated), the new behavior seems more logical to me than the old one.
Jan
18
comment What are some “real-world” applications of Mathematica?
@R.M. Also curious. I think this question is important. It can always be closed again / blocked / protected later, if things start to get out of hand. Voting for reopening.
Jan
17
awarded  Yearling
Jan
15
comment How can I trace a functional expression's evaluation visually?
@M.R. Thanks for reminding. I certainly do keep this in mind, also because I am interested in this too. But I am currently in the same situation as I was then, and free time is as elusive now as it was then, 2 years ago.
Jan
12
comment Two ways of map a function on the list: Which one is faster?
@AndreasLauschke Well, semantically they do the same thing. The only difference is how they achieve it. I also dislike the situation, but having different names for them would explicitly bring performance into the language semantics, and that is something one wants to avoid as much as possible. The only real solution here is to move both performance scales towards each other, by e.g. developing a more general Compile (which is being worked on), that would compile top-level code, perhaps JIT and type-specialize, and would in many cases remove the effect of the top-level Listable.
Jan
12
comment Two ways of map a function on the list: Which one is faster?
@AndreasLauschke Well, the credit for listableQ goes to Mr.Wizard. As to top-level Listable attribute, it doesn't really break Listability semantically, it just replaces the low-level one with the much slower top-level one (so, it degrades performance). The problem is that when you have a function like f[x_, a_,b_]:=x^a + x^b, then while the r.h.s will automatically thread over x when x is a list (by virtue of Plus and Power being both low-level Listable), it is hard to confirm that robustly and efficiently in general. That's what listableQ helps with, to some extent.
Jan
12
comment Two ways of map a function on the list: Which one is faster?
@AndreasLauschke To answer your direct question, I guess that there isn't a fully robust way of testing for listability in general (given that the language is untyped and combinations of listable functions are also often listable), which would be at the same time fast enough in all cases. So, if you have f[x_]:=some-code-using-x, then the r.h.s. may in fact be able to thread over lists (so that Listable is not needed can can only harm performance), or it may not, and there is no general way to find that out. So, this is left to the user, in the same spirit as packed arrays / unpacking.
Jan
12
comment Two ways of map a function on the list: Which one is faster?
@AndreasLauschke Another possible improvement in this context would be to define and use your own version of Map, so that it actually does not use Map on internally Listable symbols: ClearAll[lMap]; lMap[f_?listableQ, arg_List]:=f[arg]; lMap[args__]:=Map[args];. Of course, this would become useful only if the overhead of listableQ is not greater than the overhead of explicit Map. OTOH, for a function you use many times, you can memoize the result of listableQ.
Jan
12
comment Two ways of map a function on the list: Which one is faster?
@AndreasLauschke However, one can still do a few things. One can for example use the listableQ function from this post, and then write something like ClearAll[setListable]; setListable[s_Symbol /; !listableQ[s]]:=SetAttributes[s, Listable]; setListable[s_Symbol]:=Null; and then use setListable instead. To the extent that listableQ works, this would prevent you from spoiling the listability of already internally-listable symbols, and, more importantly, their combinations.
Jan
12
comment Two ways of map a function on the list: Which one is faster?
@AndreasLauschke IMO, this is just one of the consequence of several performance scales present in the language. All functions which work on packed arrays have efficient type-specialized branches for them, and for those functions (where it makes sense), Listable on the top level is just a confirmation that they indeed are Listable, but the way they achieve Listable behavior has nothing to do with the top-level attribute. OTOH, generically, you need to use Listable on general symbols, to make them behave as such. So, given the performance model of M, there is not much one can do.