Reputation
76,428
Next tag badge:
283/100 score
18/20 answers
Badges
8 227 319
Newest
 Enlightened
Impact
~511k people reached

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).
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 :-).