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

23h
awarded  Nice Answer
1d
comment How can one manually change the rule ordering
@Mr.Wizard Looks good to me, and pretty elegant. Personally, I would still prefer direct and local manipulations with DownValues, but your 'nonOrder' seems to cover the majority of problematic cases, so this is probably reasonably safe to use. In any case, this is infinitely better than using global option resetting.
1d
comment How can one manually change the rule ordering
@Mr.Wizard This becomes pretty likely scenario if you use some third-party functions in your code (and, due to the lack of fundamental distinction between built-in and library / package functions, those can also be built-in and implemented on the top-level), and the implementer likes this style of coding where closures are created at run-time as inner functions, such as e.g. myPublicFunction[x_]:=Module[{inner}, inner[y_]:=y; inner[y_?OddQ]:=y^2; inner[x]]; . I personally use this style quite a bit, even though typically I give definitions in the correct order. But I know people who don't.
1d
comment How can one manually change the rule ordering
@Mr.Wizard Sure, I can. In my own code, I frequently have internal functions (say, local to Module), which have several overloaded definitions. So these are created at run-time, and that internal local function becomes a closure. Now, say you use some such function, e.g. as a part of using my package for your purposes, without knowing about this implementation detail, and call it from your function already after you changed this option. Then, that function would break, in a way that would look like a complete mystery to you, unless you dig into the implementation.
1d
comment How can one manually change the rule ordering
@Mr.Wizard "I'll never match your Guru badge count" - never say never :). "but I think we make a good duo" - most certainly.
1d
comment How can one manually change the rule ordering
Actually, using this option in practice is pretty scary, since it changes the ordering policy globally. So if some of the code that runs during the time when this stays changed, relies in automatic reordering, things can break in very subtle ways. And this doesn't even have to be one's own code, it could be in some of the functionality one is using (perhaps without even knowing about it).
1d
comment How can one manually change the rule ordering
Interesting. I forgot about this option, +1. Will still keep my answer, since it describes alternative techniques and gives some extra info.
1d
answered How can one manually change the rule ordering
Feb
8
comment Getting lengths of sublists that sum to more than one
@alancalvitti Look for user21. He quit SE. Then rejoined, under the name user21. His past contributions, however, can't be easily found systematically, since the user was deleted. You can find them here and there, e.g. this one.
Feb
7
comment Attempting to modify parts of a multi-level association in-place
@JJM Glad if that was helpful.
Feb
7
comment Attempting to modify parts of a multi-level association in-place
@m_goldberg In fact, there are even much simpler pieces of evidence here, e.g. how Map and similar functions work on assocs.
Feb
7
comment Attempting to modify parts of a multi-level association in-place
@m_goldberg " but nothing I've read has so far convinced me to discard it." - well, how about in-place modifications? Like the one with Set on the top of this post, which works perfectly. Or many more examples, both in the docs and in my post I linked above. In my view, they are much closer to lists (arrays), than to complex numbers - they have similar mutability properties, and both are indexed containers of elements.
Feb
7
comment Attempting to modify parts of a multi-level association in-place
@m_goldberg AtomQ on a association returns True - which is rather unfortunate, and this was done mostly to forbid pattern-matching inside associations like other expressions, and also to avoid making Association explicitly HoldAllComplete. But I didn't mean this fact, but the other things you stated about mutability and in-place modifications. Associations are clearly not atomic for part extraction and modifications, despite returning True on AtomQ.
Feb
7
comment Attempting to modify parts of a multi-level association in-place
Not sure why the close votes either. Did someone have a bad day today?
Feb
7
comment Attempting to modify parts of a multi-level association in-place
Not sure why the downvotes - this looks like a perfectly legitimate question to me.
Feb
7
comment Attempting to modify parts of a multi-level association in-place
@m_goldberg Your statement is incorrect. Associations are given certain degree of (user-level) mutability, when stored in a symbol, just as lists are. Check out my answer I linked to, in the previous comment, for a longer discussion of this.
Feb
7
comment Attempting to modify parts of a multi-level association in-place
Note that this works: AssociateTo[m2[["M"]], "b" -> 3]; m2. Strongly related discussion can be found here.
Feb
7
comment Testing a package in Mathematica 9
Hi @Santi, glad it helps. Re: parallel - alas, I won't have time to look into that for a while. My guess is that you have to clear things both on the parallel sub-kernels and the master kernel. Shared symbols might be trickier still. I will keep this in mind though. At some point soon, I will put the package on github, so that it will be open for pull requests.
Feb
7
comment Partitioning a list when the cumulative sum exceeds 1
@Mr.Wizard This seems to be a rare case where the question is as much a dupe as it is not, in terms of making this decision. As of now, I think we should probably keep this quuestion, but somehow make a reference to that one very visible, so that whoever comes here, will also see that one.
Feb
7
comment Partitioning a list when the cumulative sum exceeds 1
Seems like a borderline dupe of this one - the only missing step from there to this one in to use Internal`PartitionRagged or Mr. Wizard's dynP on the result. In any case, very strongly related.