Leonid Shifrin

38,407 reputation

3105197

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

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

	38,407 reputation	bio	website	mathprogramming-intro.org	visits	member for	1 year, 4 months
3105197 badges		location	St. Petersburg, Russia		seen	22 mins ago

summary answers questions tags badges favorites bounties reputation activity

3,359 Actions

suggestions reviews revisions comments badges posts accepts all

May 22	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.
May 22	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).
May 21	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!
May 21	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.
May 21	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.
May 21	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.
May 21	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.
May 21	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.
May 21	comment	Why is there no PositionFunction in Mathematica? In this answer, I described some implementation techniques which may also be applicable here.
May 20	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 19	revised	Can one identify the design patterns of Mathematica? Added a link, fixed some link names
May 19	answered	Can one identify the design patterns of Mathematica?
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	awarded	Enlightened
May 18	awarded	Nice Answer
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	answered	Recursion depth exceeded
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`).