Leonid Shifrin

38,127 reputation

3102194

bio	website	mathprogramming-intro.org
	location	St. Petersburg, Russia
	age	36
visits	member for	1 year, 4 months
	seen	1 hour ago
stats	profile views	3,098

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

	38,127 reputation	bio	website	mathprogramming-intro.org	visits	member for	1 year, 4 months
3102194 badges		location	St. Petersburg, Russia		seen	1 hour ago

summary answers questions tags badges favorites bounties reputation activity

2,216 Comments

suggestions reviews revisions comments badges posts accepts all

7h	comment	Simple problem about shadow symbols in multi-contexts +1. I think, a lot of people don't realize that this is the main purpose for Private` contexts to exist, since otherwise a lot of "local" symbols generated will conflict with each other. In some sense, the role of private contexts is more important than what can be seen on the surface (which is, only localize private package-scoped variables and functions), because in addition to this main role,partially they make up for imperfections (emulation) of lexical scoping in Mathematica. In truly lexically-scoped environments, all those `Module`-generated and other symbols wouldn't have existed.
7h	comment	Checking from a preemptive evaluation whether a main evaluation is ongoing @AlbertRetey Yes, but IIRC, the question was about how to determine whether or not the main evaluation is ongoing, from the preemptive evaluation, not from the queued one.
12h	comment	Why is there no PositionFunction in Mathematica? @Mr.Wizard Alas, I don't have the time for this at the moment. May be later. But I also think that this makes real sense only for regular structures such as flat lists, may be multi-dimensional arrays too. For symbolic expressions, I think it will be more trouble than it's worth in the majority of cases. And when not, one should make a custom optimization (this case is not likely to be run into by a novice user anyway).
23h	comment	Performance of Dispatch and lists of Rules @JacobAkkerboom Ok, that's an important note (`DownValues`). You are right in that we may want to understand this issue a bit better. Good night!
23h	comment	Performance of Dispatch and lists of Rules @JacobAkkerboom The usual way `HoldPattern` is used is to prevent some patterns from evaluation. When wrapped around symbols, it is occasionally ok, but this is arguably not its main use. But if I understand correctly, your observation only affects the speed of rule application, not the result. When I have something like `HoldPattern[sym]`, I usually don't care about the speed so much. So, while I agree that you made an interesting observation, I fail to see how this would affect e.g. code I personally write in the 99.9 percent of cases. So, for me, it is just a good warning. Of course, YMMV.
1d	comment	Performance of Dispatch and lists of Rules @Spawn1701D In the case of `Update`, I would not bother. It is really a rare and specialist command. Usually, it is used in rather exceptional circumstances and for non-trivial things. Besides, it is tightly connected to mutable changes and their propagation. So, I'd rather try to avoid situations where it may affect things, as I suggested in the previous comments.
1d	comment	Performance of Dispatch and lists of Rules @Spawn1701D I think that overloading `Update` is a horrible idea. It is obscure enough without being overloaded.
1d	comment	Performance of Dispatch and lists of Rules I think that in the context of usual (normal) lists of rules, performance is not the main concern, and `Dispatch` was introduced specifically to improve performance for long lists of rules. So I would not say that the behavior you have observed screws up lists of rules. Correctness comes first, and speed may be not even second. If you have huge lists of rules and want fast application, and also for robust resuts, I think it is in your best interest to make l.h.s. of rules immutable. Actually, in all practical cases I recall for `Dispatch`, this was the case.
1d	comment	Performance of Dispatch and lists of Rules That's a good observation you made on `Update`, but `Update` is a rather special command. In my experience, I had at most a dozen cases where I really needed to use `Update` (i.e. it was crucial). I would think that the general message we should take home from your observation is that it is best to not use l-values (symbols or expressions which can be assigned values) as l.h.s. of rules (also in `Dispatch`), but I more or less follow this practice in any case.
1d	comment	Why is there no PositionFunction in Mathematica? In this answer, I described some implementation techniques which may also be applicable here.
2d	comment	At what point should MLSetMessageHandler() be called? @Szabolcs That was my very first suggestion (function callable from M). I did not know about MLMDEFN macro, but apparently was thinking in the right direction :)
May 19	comment	At what point should MLSetMessageHandler() be called? Actually, the most economical way would be to define the macro as `#define MLSetMessageHandler(link, handler) MLSetMessageHandler(link, (MLMessageHandlerObject) msghandler)`, and then you don't need to set it yourself - as long as this `#define` is included when you compile your files, it will automatically replace the call to `MLSetMessageHandler` that is present in generated `MLMain()`. This should answer both of your concerns at the same time.
May 18	comment	At what point should MLSetMessageHandler() be called? You could also use a hack and define a `MLSetMessageHandler` macro using the C preprocessor, to effectively disable the code generated by `mprep`. Something like `#define MLSetMessageHandler(x,y)` and then `#define MLSetMessageHandler(x,y,flag) MLSetMessageHandler(x,y)` . The point is that you will use the second version with a (spurios) flag - say 0, and since the macro expansion is not recursive, the first version won't be used on the expanded result.
May 18	comment	At what point should MLSetMessageHandler() be called? Why can't you have a custom function to set your message handler and call it as a part of installing your function, after `MlMain` does this?
May 18	comment	Recursion depth exceeded @J.M. In this case, conversion to iterative version is made trivial via memoization, see my answer.
May 18	comment	Recursion depth exceeded @J.M. It also depends on how recursion is used. If one uses it for algorithm which is deeply recursive (high recursion depth), then the right way to do this in Mathematica is to perform some form of tail call optimization. Note that tail call - optimized functions in Mathematica require modifications of `$IterationLimit` rather than `$RecursionLimit`, and the former are safe (it is safe to set `$IterationLimit` to `Infinity`).
May 18	comment	Recursion depth exceeded @J.M. Sure, I just wanted to reinforce your comment. Re- `Block` - this is better, but IMO not enough. Actually, presence of absence of `Block` is irrelevant for my main argument. My point is that even with `Block`, setting `$RecursionLimit = Infinity` can easily overflow the stack which leads to a kernel crash. Happened to me more than once :-).
May 18	comment	Recursion depth exceeded @J.M. Actually, I think that setting `$RecursionLimit = Infinity` is never appropriate. I realize that I may be biased by my software development (rather than problem - solving) perspective, but it is all too easy to lose unsaved data by using this setting.
May 18	comment	Can one identify the design patterns of Mathematica? @rcollyer Yes, that's a good point. Somehow I didn't trust Internal`InheritedBlock for user-defined symbols (don't remember why - I think something went wrong a few times), so in such cases I use the technique which can be sketched as `f[x_]:=With[{dv = DownValues[f]},Block[{f},DownValues[f]=dv; new-defs;code]]`. But whatever the implementation, this version of technique is useful. Since I plan to have a separate post on self-blocking, which wasn't the main topic here, I did not provide all these details.
May 16	comment	Variable scoping problem when mapping over delayed replacement Ok, I see. You want to generate rules programmatically. I think this is going to be tough no matter how you slice it. One thing that comes to mind: `Cases[Hold[y, y^2, y^3], el_ :> RuleDelayed @@ Hold[{x_, y_}, {x, el}]]`, but this is not exactly simple.