Wolfram Mathematica

@Rojo I log into MSE using my google account, but I'm trying to degoogle. Any advice before I start down the path of creating a SE account and linking it to MSE?

belisarius

@WReach As you can see, @Rojo was killed while trying it

Rojo

@WReach Not really. I made a mess because I didn't have a clue of how OpenID worked, and I thought all SE sites were the same. Funny enough, the MSE doesn't offer you the SE login when you go to "my logins" in your profile and click on "add account". But it works when you paste the openid.stackexchange.com url in the box

WReach

3:16 AM

@Rojo Thanks. I'll give that a whirl some time.

Rojo

@Wre no problem

@belisa Fortunately, I am still ali

¿adónde?

2 hours later…

5:31 AM

Do binary operators always bind equally strongly at both sides?

If so, why?

4 hours later…

Pickett

9:23 AM

Is this behavior documented somewhere?

<|<|"val" -> 1, "val2" -> 2|>, "val" -> 3|> (* Out: <|"val" -> 3, "val2" -> 2|> *)

(I learned about it here)

3 hours later…

rm -rf

12:48 PM

@Pickett I have used it a few times and I don't think it is documented. However, this is a standard behaviour of such a data structure (same with dictionaries, binary search trees, etc.). One could argue that an error/warning should be issued instead (I was confused by it at first as well... also see Leonid's reply a few messages down), but I think this is non-standard.

Pickett

@rm-rf Would you use it in code that you intend to distribute, despite the fact that it isn't documented?

If it is standard behavior for that data structure I mean, it will probably not change?

2 hours later…

belisarius

2:45 PM

"A gentle nudge" deserved:

data.stackexchange.com/mathematica/query/217455/a-gentle-nudge

Murta

3:15 PM

@TaliesinBeynon Nice to know about a more formal structure for "Incremental Language Development".

2 hours later…

rm -rf

5:13 PM

@Pickett I certainly would. I think the confusion comes from the fact that it looks like a collection of rules and this behaviour doesn't happen with a list of rules (at least, this was how I saw it at first anyway).

Pickett

@rm-rf Yes, I think that is where the confusion comes from as well. Thank you.

WReach

5:50 PM

@Pickett I don't know of any explicit mention of this capability in the documentation, but the language lawyer in me thinks that it is strongly implied.

The documentation explicitly states that 1) with repeated keys, the last key wins; 2) key/value pairs can be specified either as loose rules or as lists of rules; and 3) associations act like lists in "typical list operations" and "many operations". I think it is reasonable to expect that Association itself is one of those "many operations", and indeed it is.

The same language lawyer would prefer an explicit statement over such inference :)

Pickett

6:01 PM

@WReach OK, I agree that it is implied by those three. Thanks.

2 hours later…

Rojo

7:50 PM

@WReach Last key wins but in first key's position. That's also something that I think should be in the docs (I mailed that long ago)

2 hours later…

WReach

9:43 PM

@Rojo Yes. My mental model is that it starts with an empty hash trie and then applies each rule from left to right as an update to that trie. So I guess I found that behaviour unsurprising. But I agree that it is worth noting in the documentation.

Rojo

@WReach I didn't know what a hash trie is and that behaviour would have been my last guess

WReach

@Rojo And judging from comments in chat and on postings, I think your reaction is the common one. While this particular issue didn't make me pause for thought, I've been surprised frequently (e.g. most recently, the Listable behaviour for associations). I also vote in favour of a section in the documentation that lays out the execution model for associations (and datasets) in more detail. And the whole business about AtomQ vs. "NormalQ".

Rojo

@WReach I think they themselves don't have a clear idea yet

WReach

@Rojo I share that impression :)

Rojo

There have been some discussions around about atoms, and people don't seem to agree about what an atom is anyway

@WReach They seem to be trying to mix associations into the language as much as possible. And that's nice, but if they don't go all the way, and document it, it's confusing

WReach

9:57 PM

@Rojo Some of the rules seem to be more heuristic rather than hard and fast. Associations are treated like lists in "many functions", but not in all functions. Dataset seems subject to such guesswork as well, probably a consequence of the heuristics used in the new type system:

It's not that Median isn't compatible with associations, its that the type here is recognized as a Struct instead of an Assoc. That's not wrong, per se, but it does mean that the type inference scheme, which is a vast undertaking that can never really be finished, doesn't 'know' that this should be allowed. There is a fairly straightforward fix that may make it into 10.0.1 (and will fix many similar issues), but for now, writing Median[#]& instead of Median should get around this problem. Edit: I'm wrong, Median doesn't work properly on associations of vectors. — Taliesin Beynon 4 hours ago

I logged a similar bug involving arithmetic ascending operators.

Rojo

@WReach I think that's mainly for Datasets. And its probably nice, but hopefully associations can behave in a simpler and docmented way

@WReach Also, we call associations to both the unevaluated expression, and the atom

WReach

@Rojo Yes, I tripped on that one as well. I don't have a clear model about that transition -- or about when exactly association values are subject to evaluation or re-evaluation.

Rojo

@WReach Exactly

@WReach Furthermore, there's this idea behind all mma, that expressions that aren't atoms are like arrays, are evaluated in certain way, etc. And now there's a special head, Association, that does stuff differently, wants to hold arbitrary mma expressions inside, and yet wants to pretend it fits well

WReach

@Rojo Yeah. Earlier I said (or lamented) to Pickett that we have some unlearning to do. Part of me is looking forward to it (the theoretician). Another part dreads it (the coder trying to get work done). :)

Rojo

@WReach I have always liked the fact that mma has simple core evaluation rules that I more or less understood

@WReach Now, we have lived with some big-atoms like sparse array, image, graph, but associations seem like too core. They'll be there in most of the coding.

It spoils the "clarity". I don't know what I am saying really. It's more a feeling

I wonder if it wouldn't be simpler to just change the "core" a little. Make <| |> part of the full form. So Association is a function that evaluates to <| |>. A mma expression can be either a standard mma exp or an assoc. If it is the former, then usual evaluation procedure. If the latter, then perhaps evaluate in order: key1, value1 (if not :>), etc, etc.

And pattern matching should find a way to represent <| stuff

Then Depth can be incremented as 1 for an association "by reasonable definition", and not as an exception, etc etc. But not for an Association that is unevaluated

WReach

10:16 PM

@Rojo I have the same feeling -- almost a sense of dread that where before the exceptional cases were confined to some dusty corners rarely visited, now such exceptions are moving into core usage. I hope that dread will not ultimately be justified.

@Rojo Yes, the rules need to be clear. More than just in "many functions" such-and-such...

Rojo

@WReach Well said.

WReach

@Rojo Gotta run for now. The coder has some work that has got to get done :D

Rojo

@WReach See you aroudn

WReach

bye

« first day (938 days earlier) ← previous day next day → last day (3563 days later) »

all rooms