Reputation
76,538
Next tag badge:
283/100 score
18/20 answers
Badges
8 227 320
Newest
 Nice Answer
Impact
~512k people reached

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.
Jan
12
comment `IntegerPartitions` without duplicates
@ciao Thanks! It's been a while ago.
Jan
12
comment How to make FlattenAt work with Span?
@garej I see. In this case, one can e.g. define a helper function as follows: ClearAll[fl]; fl[arg_] := Sequence @@ arg; fl[args___] := args;, and then flattenAt[expr_, spec_] := MapAt[fl, expr, spec].
Jan
12
answered How to inject unevaluated list of Unique into a RuleDelayed?
Jan
12
comment `IntegerPartitions` without duplicates
@Mr.Wizard Wow, I didn't realize that!
Jan
12
comment `IntegerPartitions` without duplicates
Exactly this question was asked some time ago on SO. If you use getPartitions from my answer there, as getPartitions[85, Range[85]] // Length, you get 121792.
Jan
11
comment Can I make a default for an optional argument the value of another argument?
@EmilioPisanty Thanks!
Jan
11
comment How to make FlattenAt work with Span?
@garej It is not clear to me how it should work for such a level spec.
Jan
7
comment How to make FlattenAt work with Span?
@Sascha Sorry, I am short of time right now. Later, if time permits and no one does that by then.
Jan
7
comment How to make FlattenAt work with Span?
@Sascha Ok, why not. Posted.
Jan
7
answered How to make FlattenAt work with Span?
Jan
7
comment How to make FlattenAt work with Span?
+1. If the list of positions is long, Transpose[{Range@@sp}] will be vastly more efficient than List /@ Range @@ sp.