53,247 reputation
5148243
bio website mathprogramming-intro.org
location St. Petersburg, Russia
age 37
visits member for 2 years, 3 months
seen 9 hours ago

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


Apr
9
comment What is the most efficient way to map a linked list?
@Pillsy Nice! I thought a bit about this, but did not follow this direction. Besides these advantages you named, this should also be a more idiomatic code. Care to add this to my post, or would you leave this to me as an exercise? :)
Apr
8
revised What is the most efficient way to map a linked list?
added 18 characters in body
Apr
8
revised What is the most efficient way to map a linked list?
Added a section on lazy lists
Apr
8
comment What is the most efficient way to map a linked list?
By the way, using untagged exception here does not seem right, since you may be catching an exception thrown by the mapped function, rather than by your mechanism. Generally, I view untagged exceptions as a language defect - they should not be allowed at all.
Apr
8
comment What is the most efficient way to map a linked list?
@Pillsy See my edit for a much faster implementation which goes through flattening - unflattening stage.
Apr
8
revised What is the most efficient way to map a linked list?
Added non - linkedlist implementation
Apr
8
revised What is the most efficient way to map a linked list?
Moved the Replace-based implementation to notes section, since it crashes the kernel
Apr
8
comment What is the most efficient way to map a linked list?
@Pillsy This happened to me too, and I came to the same conclusion. Then I checked on 10000 elements, and it was fine. Now I checked again on 100000 elements, and saw the crash again. Probably, you are right. Will check again and modify my post.
Apr
8
revised What is the most efficient way to map a linked list?
added 13 characters in body
Apr
8
answered What is the most efficient way to map a linked list?
Apr
8
comment Creating a parallelizable DiscretePlot
@bobthechemist Yep, that's the first thing that comes to mind - you probably just forgot :)
Apr
8
answered Creating a parallelizable DiscretePlot
Apr
7
comment Set-generating macro unexpectedly reaches recursion limit
@Akater "This would be the first big disappointment in the core language for me, though." - as far as I know, internal overloading of Set is very infrequent and thought of as a last resort. It is almost just as bad to do that internally as when done by the end user, because any two such modifications done independently can conflict in hard to predict ways, and because it hinders the generality of the language. So, I wouldn't get disappointed just yet - a lot of thought has been put into the design of every (core) feature, and, at least in my view, there are very few inconsistent places.
Apr
7
comment Set-generating macro unexpectedly reaches recursion limit
@Akater " User actually has almost complete control over the core state, and that's why I expected it to be as inert in the absense of user as possible" - well, let me then put it differently. If we think of Mathematica as a rewrite system, then it is well-known that the rules are non-commutative, in the sense that the result depends on the order in which rules are applied. Set can be thought of as a constructor of global rules (which it is). By Block-ing it, you change the sequence in which global rules are constructed, which is equivalent to changing the order in which they are applied
Apr
7
comment Set-generating macro unexpectedly reaches recursion limit
@Akater Another source of confusion may come from comparisons with Lisp etc. Mathematica does not have well-defined read or compile-time. So, in practice, what you call a macro is in fact a dynamic environment, which means that, rather than just expanding code, it changes the state of the system for a (part of) the execution stack, and that's a very unsafe operation. You can also write true macros in Mathematica, but they would involve lexical rather than dynamic scoping constructs, such as With, Function, or replacement rules - as well as tools of evaluation control (Hold and friends).
Apr
7
comment Set-generating macro unexpectedly reaches recursion limit
@Akater Regarding deletion - I don't have a strong opinion on the matter. You raised an important issue, and this has not been discussed here on M SE in any significant detail before. Probably, many other folks do have similar questions. So, it may be a good idea to keep this. Let's see what others think.
Apr
7
comment Set-generating macro unexpectedly reaches recursion limit
@Akater And the fact that most of the functions exposed to the user operate on immutable expressions does not mean that their implementations don't contain mutable state.
Apr
7
comment Set-generating macro unexpectedly reaches recursion limit
@Akater And yes of course, "the environment is modified with it internally on a regular basis". Mathematica is not a pure functional language, mutations are very much allowed (even if not admired). Any function which uses Module, Block, or even CompoundExpression, does that - because it makes no sense to use these functions if you don't have side effects in that code. And of course, a lot of internal functions use those constructs, because Mathematica is largely written in itself. If you had a picture of Mathematica being pure stateless rewrite system, that's a wrong picture.
Apr
7
comment Set-generating macro unexpectedly reaches recursion limit
@Akater ... be an error. In Mathematica, it is not, because it is symbolic, but the problem shows up in a different way. To put in another way, by Block-ing Set you change the evaluation sequence for internal functions (which use Set) in a way they weren't designed to handle. In most languages, you can't even do anything as fundamental as changing the semantics of core operations such as assignments via dynamic scoping, for a part of execution stack rather than a part of the source code. This is a fairly disruptive / intrusive change, it is even much worse than things like AOP.
Apr
7
comment Set-generating macro unexpectedly reaches recursion limit
@Akater The problem is that the system is neither completely side-effect-free (can't be) nor based exclusively on side effects. The real problem is that it is symbolic. What this means is that at certain point, some functions may expect to get arguments with certain heads or, generally, certain structure. By blocking Set, you delay assignments to some variables / L-value-expressions. If those expressions are passed to some functions, those functions are not getting what they would expect to get at that stage. In more traditional languages, calling an undefined function (Set here) would ...