53,207 reputation
5147242
bio website mathprogramming-intro.org
location St. Petersburg, Russia
age 37
visits member for 2 years, 3 months
seen 1 hour ago

Ok, an obligatory note: opinions expressed here are mine and not those of my employer.


Apr
7
comment How does Mathematica determine that an evaluation should be terminated?
@luyuwuli You had to follow the discussion more closely. My real statement does not contradict Wagner. The evaluation process first goes down the expression - and during this part, the head is evaluated first indeed (and you can find me stating this in numerous places in my answers here on SE). Then, there is a "going up" stage, in which the arguments has been already evaluated, and then the rules associated with heads are applied. I meant this one. I do agree though, that I used a slightly confusing terminology: I had to say instead that "the rules associated with head ... are applied".
Apr
4
comment “Unflattening” a list
@halirutan Welcome :) Actually, the minimal change would've been just using SetAttributes[f, Listable] in place of Attributes[f]={Listable}, but of course there are many ways, as usual in M.
Apr
3
comment How to fix this memory leak
@Pisto Actually, now that you mentioned this, it is indeed right. The subtle thing here is that such local symbols with DownValues are not collected only if they were referenced by some external symbols / expressions. In this case, they are not, so perhaps all this is an overkill and indeed, SetAttributes alone is sufficient. I have mentioned this also here
Apr
3
comment How to fix this memory leak
@rm-rf Sorry for my stealing your check-mark with an aggressive marketing :)
Apr
3
comment “Unflattening” a list
A memory / symbol leak has been discovered for your code - which is otherwise very neat and elegant, here. Perhaps, it is a good idea to update to one of the alternatives posted there, or some other one?
Apr
3
comment How to fix this memory leak
@Pisto But have a look at my Block-based solution, I think it is a bit more elegant / higher level. It is also robust against exceptions / Aborts inside function's body, which is not an issue here but an issue in general.
Apr
3
comment How to fix this memory leak
@Pisto ... This happens because it explicitly alters all set of attributes, which is one reason why this form is generally not advisable. SetAttributes fixes that, because it only adds Listable to existing ones, so Temporary is retained. Second, we need Clear at the end, to remove the DownValues which accumulated for f during the execution - then we fulfill both conditions and the symbol is garbage-collected.
Apr
3
comment How to fix this memory leak
@Pisto Well, what happens is that the variable is only collected by Module if it has the attribute Temporary and it has no DownValues or SubValues (not sure about UpValues, and OwnValues are fine. There are also a couple of additional more subtle conditions, but they are not important for this case) at the moment when the execution leaves Module (and of course if the return value of Module is not some expression containing this local symbol). Now, originally, there were 2 problems: first, the code Attributes[f] = {Listable} removes the Temporary attribute ...
Apr
3
answered How to fix this memory leak
Apr
3
comment How to fix this memory leak
Ok, the statement Attributes[f]=Listable is the culprit. You also have to use instead SetAttributes[f,Listable], so that the Temporary is preserved.
Apr
3
comment How to fix this memory leak
Actually, in this case, it seems to not work, no matter whether one uses Clear or ClearAll. I am a bit puzzled.
Apr
3
comment How to fix this memory leak
It's not, because then this variable is not garbage -collected - Module only garbage - collects variables with attribute Temporary. You can make a simple experiment to verify that: Module[{f},f[1] = 1; Clear[f]], and then also try ClearAll, and monitor the existing symbols in Global` as you do this.
Apr
3
comment How to fix this memory leak
@DanielLichtblau You beat me to it. Why don't you write this as an answer?
Apr
2
comment Defining conditional Notation rules
@rm-rf Thanks :)
Apr
2
comment Defining conditional Notation rules
@rm-rf Ironically, my initial code was using SubscriptBox, but because I was entering in the FullForm, it did not work for me, and I later changed that to RowBox[...]. And because that was my starting point, it didn't occur to me that that branch should be kept, until the last moment.
Apr
2
comment Defining conditional Notation rules
@DanielMahler By the way, it is exactly this sort of problems which tell me that mixing notation and programming / interactive work is generally a bad idea. I never do it, and neither do most of the experienced users I know. If you need to render things nicely for presentation, it is best done as a separate module and separate step in your workflow (one of the final ones).
Apr
2
comment Defining conditional Notation rules
@DanielMahler I have edited my answer and added another definition to my code, which should be able to catch the case of using the typeset form: makeExpression[SubscriptBox[boxed, arg_], form_] :=MakeExpression[RowBox[{boxed, "[", arg, "]"}], form];. Try the new one and see if it works for you.
Apr
2
comment Defining conditional Notation rules
@rm-rf But thanks a bunch, I appreciate that you took the time to look into this.
Apr
2
revised Defining conditional Notation rules
Added another definition
Apr
2
comment Defining conditional Notation rules
@rm-rf I was 20 secs faster :)