64,092 reputation
6189283
bio website mathprogramming-intro.org
location St. Petersburg, Russia
age 38
visits member for 3 years, 2 months
seen 1 hour ago

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


Feb
18
comment Context of localised (dynamic) symbols
To correct my statement a bit: fully-qualified names are only converted to fully-qualified strings if the context of the symbol is not on the $ContextPath - otherwise they are still converted as short names (strings). Conversely, if you have a symbol and pass it to the code which converts it to a string in an environment where the symbol's context is not on the $ContextPath, the result would be a fully-qualified string name even if initially you referred to the symbol by its short name (the fact that I exploited in my answer in the linked question).
Feb
18
comment Context of localised (dynamic) symbols
Somewhat related to my last comments.
Feb
18
comment Context of localised (dynamic) symbols
Why the design here is as it is, I can't answer, but I've found this behavior useful on many occasions.
Feb
18
comment Context of localised (dynamic) symbols
I haven't tested this now (although I did before IIRC), but my guess would be that the distinction is not whether the symbol is in Global` or not, but whether the symbol is referenced by its short name or not. And it probably has to do with conversion to boxes. When short names are used, they are converted to short string names when box conversion happend. My guess is that FE code assumes then that those are to be dynamic FE variables, and converts them accordingly. But when fully qualified symbols are converted, they result in long string names, and FE treats them as kernel variables.
Feb
18
comment Context of localised (dynamic) symbols
In a sense, once symbol-generation + symbol renaming is chosen as a mechanism to implement lexical scoping, there aren't many natural choices left for the rest of it. I'd say, the current behavior is rather natural from this point of view.
Feb
18
comment Context of localised (dynamic) symbols
The fact that you use a variable with a long (full context) name does not prevent the variable capture in this case. Which is another good reason to use Private` subcontexts for implementations (where the code with Module will sit). In that case, the generated variables will live in those private sub-contexts, and such annoying variable captures are much less likely.
Feb
18
comment Context of localised (dynamic) symbols
One reason might be that, given the Module approach to lexical scoping (symbol generation), and that these symbols may, under certain conditions, leak (persist after the execution leaves Module), it may be a good idea for them to at least leak into whatever context was there when they were constructed. If we think about it, once we state that Module implements lexical scoping by symbol generation, the currently existing scheme is the simplest possible.
Feb
18
comment How to search Dataset to find all keys share same Value
@WReach Precisely the reason I discarded it too - in exactly the same form. But, also, +1.
Feb
17
comment How to search Dataset to find all keys share same Value
@Mr.Wizard Anyway, FWIW, your suggestion with PositionIndex is perhaps the most idiomatic for Mathematica (IMO). I already voted for it, but after this discussion I started to appreciate it more.
Feb
17
comment How to search Dataset to find all keys share same Value
@Mr.Wizard Sorry, I apparently wasn't paying enough attention. Perhaps, my general hesitation to embrace position-based solutions is that I prefer to think about this problem in terms of data and relations, rather than the structure of expressions used to represent this data in Mathematica. Admittedly, such approach often isn't the right one for Mathematica code (particularly if we need it to be fast), but I decided that I can afford this luxury in this case :)
Feb
17
comment How to search Dataset to find all keys share same Value
@Mr.Wizard Yes, it is slower for any particular single value, but if you need to query this for several (many) different values, then I think it should be faster, since it only does it once. But, as you said, the main value is conceptual. We may in the future get some efficient version of invertManyToMany, which could even be lazy (do only as much as needed to service a particular query). The main point is - my solution stresses the conceptual problem we need to solve, and separates the high-level query from the lower-level implementation details - at least, this is what I like about it.
Feb
16
answered How to search Dataset to find all keys share same Value
Feb
13
comment Most efficient way of splitting a file into length-prefixed blocks
+1. It is interesting that this is so efficient - I did not expect this (don't have the time to test right now, but the 1.65 coefficient isn't bad at all). I guess this would also depend on the average chunk size, and for really small chunks (like 5-10 bytes), the difference will me more, while for larger chunks, it will be less.
Feb
12
comment Why does an inert ReplaceAll modify this Dataset?
@StefanR Thanks, I wasn't aware of that. But that doesn't change the fact that in principle, typesetting for Assoc and Struct is likely to be different. The other question is whether to consider type inferencing not powerful enough to produce the same result as type deduction, as a bug. Personally, I would not, but I didn't discuss that with Tali yet.
Feb
12
answered Why does an inert ReplaceAll modify this Dataset?
Feb
10
comment Most efficient way of splitting a file into length-prefixed blocks
@Mr.Wizard Thanks :) But I am sure you would do it at least just as well, and besides, it uses your code as an ingredient.
Feb
10
comment Most efficient way of splitting a file into length-prefixed blocks
@R.Kazeno Good to know. Was glad to help. Thanks for the accept.
Feb
10
revised Most efficient way of splitting a file into length-prefixed blocks
added 366 characters in body
Feb
10
answered Most efficient way of splitting a file into length-prefixed blocks
Feb
10
comment Most efficient way of splitting a file into length-prefixed blocks
@Mr.Wizard You don't need separators - the lengths instruct you when one block ends and the next starts.