56,452 reputation
5159252
bio website mathprogramming-intro.org
location St. Petersburg, Russia
age 37
visits member for 2 years, 6 months
seen 1 hour ago

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


Jun
24
comment How do I save/export a list so that it can later be easily imported as a list again?
@Szabolcs I disagree however that this is an overkill w.r.t. exporting as Table. The latter involves high-level serialization / parsing, and that always increases chances to not get the same thing back. Serializing to a binary format like .mx is different.
Jun
24
comment How do I save/export a list so that it can later be easily imported as a list again?
@Szabolcs Yep, I do realize. Just when you posted this one, I added a comment under the main question, acknowledging that I learned about Export / Import working on .mx files from you. In this particular case, however, the OP's goal seems to be saving data for later use on the same machine, thus this suggestion.
Jun
24
comment How do I save/export a list so that it can later be easily imported as a list again?
Actually, I recall now that I first learned about the fact that Export / Import working on .mx files from @Szabolcs.
Jun
24
answered How do I save/export a list so that it can later be easily imported as a list again?
Jun
24
comment How do I save/export a list so that it can later be easily imported as a list again?
I'd use .mx files (Export / Import in "MX" format). This is fast, and does not really involve serialization / parsing in the usual sense (via strings). In other words, mx files bypass the high-level parsing, populating internal structures at lower level. In addition, mx files preserve packed arrays.
Jun
23
revised Extract what symbol is set by SetDelayed, Set, TagSet, UpSet, SetAttributes, etc
Added a paragraph explaining definesExt
Jun
23
answered Extract what symbol is set by SetDelayed, Set, TagSet, UpSet, SetAttributes, etc
Jun
21
awarded  Good Answer
Jun
21
awarded  Good Answer
Jun
12
comment Clearing arguments passed to a Module
@eldo Nope, that's not the one I had in mind.
Jun
12
comment Clearing arguments passed to a Module
@Szabolcs Could you find you answer on this matter? I do remember you had a very nice one.
Jun
12
comment Clearing arguments passed to a Module
Your belief isn't correct. You are formally right, in that formally arguments are passed by value. Effectively, however, most arguments are passed by reference, because most arguments are immutable expressions. Even if passed arguments are L-values and can be modified, still the references are passed, and no extra copying is done until you actually modify those expressions. It would be insane for Mathematica to do it differently, given its strong emphasis on immutability.
Jun
12
comment In a Function, how to Ensure Code Runs Prior to an Abort
Have a look here and here. In fact, your question is probably a dupe of the latter.
Jun
12
comment Making a Mathematica package manager?
@jkuczm Thanks!
Jun
12
comment Making a Mathematica package manager?
@jkuczm Since you brought this up, let me just mention that I do have Mathematica package manager under development, but it has to incorporate a number of things to become really useful for Mathematica code. In particular, in my framework, the package manager is only a part of the larger infrastructure aimed to enable people to easily share and reuse Mathematica code. Given this fresh initiative, I will publish my ideas in a separate answer some time soon (currently in the hospital and not fully functional).
Jun
10
comment Understanding performance: graph connected components
The merge function is fast because it is type-specialized on numerical lists, on which it gets compiled. No time to look at your code in detail right now, but any top-level code with some sort of iteration will likely be much slower than the built-in function. You may want to check out my answer here, for a semi-compiled implementation of connected components which might rival a built-in one, and actually the entire thread to which it belongs, for some extra context / ideas.
May
30
comment ReplaceAll performance problem: packed arrays on the LHS are unpacked when the RHS is too long
@Szabolcs In a sense, this just confirms my general view that packed arrays are a language hack, introduced to alleviate the lack of a real compiler. Packed arrays make it possible for us to work as "human compiler" to speed things up, but they also introduce many corner cases, which their users should be aware of. Had Mathematica had the real compiler, you wouldn't even have to know about packing etc, it would just work.
May
30
comment ReplaceAll performance problem: packed arrays on the LHS are unpacked when the RHS is too long
@Szabolcs My guess is that for a large list of rules, optimization needed to decide that there is no need to unpack the packed array is becoming too expensive (because the optimizer has to analyze the list of rules), and so is switched off. Which is why we see unpacking for number of rules >= 10 but not smaller. This can be frustrating, I agree, but I suspect that one can't do much better in general, without significantly extending the current pattern-matcher's implementation. The untyped and very generic nature of pattern-matcher certainly does not help with this sort of problems.
May
30
comment ReplaceAll performance problem: packed arrays on the LHS are unpacked when the RHS is too long
@Szabolcs Thanks for the accept, that was fast :). I didn't give any explanation for the original behavior, though, so answered only a part of your question.
May
30
comment ReplaceAll performance problem: packed arrays on the LHS are unpacked when the RHS is too long
It might even be a dupe of that question, except for your observation about length dependence of unpacking.