Hmmh. is v11.1 coming out soon? Suddenly WRI support has started mailing me of fixed bugs.

@kirma I have never got such e-mail :(

@Kuba I got couple yesterday for some of the most absurd geometric regions bugs I've reported.

I never knew the following would parse correctly and I always thought the Front End's parser had a quirky limitation. In my mind, breaking a line at an infix operator meant the infix operator had to occur before the linebreak. But again the following is allowed, even in MMA 7.

(
 g
   []
  :=
  15)

@JacobAkkerboom you are forcing to read up to ) so I'd say that is expected. Without this it will show an error.

@Kuba yeah, I think that's why I thought this syntax was not ok in general

But putting a semicolons at the start of a line is also "putting the infix operator after the linebreak"

@JacobAkkerboom ?

The semicolon can be seen as the infix operator for CompoundExpression, right?

This is allowed:

(a
;b)

This is not:

a
; b

@JacobAkkerboom but the first one again has (). About the second one, I was really expecting this to be allowed as CompoundExpression[Null, b].

But I can live with this :)

Nevertheless, I don't see connection with the first case :)

I just meant to say that seeing an answer with semicolons at the start of lines made me reconsider this rule of "infix operators cannot occur directly after linebreaks".

Where is this rule from?

The real rule is "at the top level, infix operators cannot occur directly after linebreaks"

@JacobAkkerboom or "infix operators can not occur at the beginning of read line"

Heh I suppose I made up that rule myself :P. It has nagged me a bit, because I didn't really understand why the syntax was not allowed

@Kuba yeah that sounds simpler

@JacobAkkerboom "top level" is tricky in case of ToExpression @ ":=1"

@Kuba ah yeah that's tricky.

@Kuba the semicolon is also an operator that works both as a postfix and as infix. Do you know of more examples of this?

It seems that because semicolon can be seen as postfix, MMA chops up the following into two readlines

a;
b

but it could also be that there is a special exception for CompoundExpression

@JacobAkkerboom but this is one line:

a;
b

EnterExpressionPacket[MakeExpression[BoxData[{RowBox[{"a", ";"}], "b"}], StandardForm]]

@JacobAkkerboom no it is not, sorry ;)

@Kuba ah, I was thinking "is this another rule I made up?" :P

@JacobAkkerboom I think you are right, that it is due to that operator interpretation. Not related to CompundExpression yet.

It is FrontEnd which decides whether to put it in on RowBox or as a separate lines in BoxData.

@Kuba Yeah, i was thinking that is probably the easiest way to see that the front end has made two readlines out of the code

Whether or not it gets chopped up into multiple readlines can matter when dealing with contexts I think

@JacobAkkerboom yep.

Remove[mysymb]
Begin["Test`"];
Print[Context@mysymb];
End[];

vs

Remove[mysymb]; Begin["Test`"]; Print@Context@mysymb; End[];

@JacobAkkerboom yes, I know :) mathematica.stackexchange.com/a/119187/5478

@C.E. Hello!

@Kuba nice answer

@JacobAkkerboom thanks. I'm struggling with wording. E.g. What happens after "the evaluation" is formatting and typesetting. Applying Format rules really works as evaluation. How should we call this process then?

In context of the main loop.

@Kuba hmm more trickyness

@JacobAkkerboom what I mean is that evaluation and formatting perform, among other things, the same process. How to call it.

Not to confuse with typesetting which does this only partially because MakeExpression rules are not applied repetitively.

@Kuba I'm sorry I'm not sure I understand

But my own understanding of this is also not very organized

I think the term typesetting was used a bit ambiguously on this site

@JacobAkkerboom

Format[F[x_]] := Column[{x, x + 1}];
F[1 + 1]

F[1+1] "evaluates" to F[2]

it is the formatted to Column[{2, 3}] using the same process which formed F[2].

At the end MakeExpression rules are applied to create GridBox.

Those three steps, evaluation/formatting/typesetting, use, among other things, the same process to convert expression according to predefined rules

@JacobAkkerboom Does this process have a proper name?

@Kuba ah yeah, nice question, I think I get it

I would previously simply have called that "evaluation" :P, until you showed the quote by John Fultz: "Recall that the rendering of Graphics has nothing to do with evaluation. It is done entirely in typesetting"

@JacobAkkerboom yes, so this is another question, how to call the part of the typesetting which happens in the Kernel. E.g. MakeBoxes happens there while rendering or rewritting DynamicModuleBox happens in the FrontEnd

How is this possible that key elements of the system do not have proper names?

How do they communicate internally? :)

@Kuba haha

I like the concept "evaluation phase"

and then "typesetting phase"

@JacobAkkerboom I'm glad you like it but as I've said, it is not enough :)

@Kuba so maybe: "evaluation, in the sense the kernel is manipulating an expression". So one correct sentence might be: "In the typesetting phase, it is perhaps surprising that evaluation takes place, in the sense the kernel is manipulating an expression"

But I think what would help communication most is not to refer to the "evaluation phase" as "evaluation", or rather, it helps not to say that something is not evaluation because it does not take place in the evaluation phase

Anyway, I have to go now unfortunately

@Kuba See you

@JacobAkkerboom sure, me too :) have a nice day

Dear all: I feel a bit like Martin Luther (e.g. "here I stand and have no choice...") in doing this mathematica.stackexchange.com/a/127320/764 I will bear your judgement given by vote...

I wonder why FileExistsQ @ $Failed isn't just giving False but an error :(

@Kuba But FileExistsQ@"$Failed" does simply give False. I cannot see anything wrong with that behavior. Note the documentation gives (as an example) OddQ[expr] but FileExistsQ["name"]?

@gwr I don't claim it is unexpected. I just find it less handy design choice. Because usually I'm interested if it is a file, otherwise False. Here I have to check, if that is a string and if its string length is <1. Usually I'm interested in quick check.

So even if you are quickly prototyping a function which should abort in "not a file" case then you have to TrueQ @ Quiet @ FileExistsQ @ input. I just don't like it. But that's a matter of taste.

@Kuba Ok, but usually I would have the pattern test in the function call (file_String) so that FileExistsQ will allways work on a string. But, yes, it is a matter of taste.

@gwr it is not about function construction. Let's say I have a procedure where the second step asks user, via dialog, to provide file path, user click Cancel or X, then $Failed or $Canceled is returned. Now the test comes in.

@gwr @Kuba There is an unwritten, but fairly consistently followed convention that all functions ending in *Q return only True or False. That convention is violated here. That's a bit disappointing.

@Szabolcs and in DirectoryQ

Otherwise I do think that the behaviour makes sense for the given functionality. But I would hope it to be consistent with the Q naming too. Or just not use the naming maybe.

@gwr Well, I already voted to close, but I won't downvote. I simply think that this is the wrong place for complaints or debates (maybe Wolfram Community is better). But if people get sufficiently upset, such posts will happen anyway ...

@gwr Otherwise I do share your frustration.

@Szabolcs One could complain on Community, once it is loaded...

I think FileExistsQ@$Failed -> error plus False is better, but I guess you could use TrueQ@*FileExistsQ. But note EvenQ[a] does not return True/False if a = Sequence[1, 2], although I imagine such a case being intentional in practice being extremely rare.

@MichaelE2 Since EvenQ isn't HoldAll / SequenceHold I'd consider this example as a different case.

@Kuba My point was that some other *Q functions don't always return True/False. However you want to subdivide into cases is fine with me. I agree/sympathize with your opinion about FileExistsQ.

@MichaelE2 I don't insist so much :)

@Szabolcs I have a large graph with about 25M nodes and a similar order of edges. Do you have ideas for what tools I could use to visualize the structure of the graph? I don't have a large cluster I can access... Only my laptop w/ 16G RAM. (I'm open to pruning some of the edges and nodes to make this more manageable but it would be good to get a sense of what it looks like before that.)

@R.M. Do you have any ideas about the structure of the graph? Does it have relatively clear communities? Social networks are typically like that. This last.fm musician graph looks like that: sixdegrees.hu/last.fm I never really visualized huge graphs like that, but I thin DrL should do well on them.

@R.M. But in the end all depends on the structure of the graph. There has to be something relatively simple and high level which can be meaningfully mapped onto an image. For example, a few communities. Otherwise it will look like an uninformative tangle.

@R.M. Take a look at this too: lgl.sourceforge.net

What's the average degree in the graph? What's the degree distribution? These may give hints.

25M really sounds like too much to deal with. My (retina) screen has 5M pixels only.

It would be a good idea to try to reduce it somehow, e.g. try community detection.

@Szabolcs Thanks, I'll take a look! I do fear it is going to be a tangle at first... part of wanting to look at it is so that I can get a sense of how to start trimming.

There are well defined communities — in some ways, Stack Exchange is a perfect analogy. The graph, for example, might contain all stack exchange users, but some of them will cluster as users of SO, some as users of Mma.se, etc. and then there are connections within communities (e.g. you are active on Tex, mma, SO, etc.). Except, there could be about 2-3 million such "communities", mostly small, containing 5-10 nodes each.

Looks like I'll have to think more about this and try to work out some trimming strategy first before doing anything with it

ooooh

@blochwave Just in time! I needed a new space heater this winter and now I can use Mathematica to turn my laptop into a new kind of heater ;P

@R.M. :-D

@kirma does this answer your question about 11.1?

@blochwave Heh. 11.0.1 sounds like a "oh, we fecked it up badly" release, instead of a bugfix release. It can of course contain regular maintenance results up to that point.

For some reason, documentation in v11 (on OSX) hasn't worked at all nicely for me. Gray unevaluated/dynamics disabled boxes all around. I haven't really dug deeper into describing it to WRI support than couple mails exchanged; I hope somebody else has also complained and they have fixed it. ;)

er, "instead of a regular maintenance/incremental release" I meant.

Am I the only one who is really satisfied with how 11.0 was released? Compared to Version 10 it has been nearly trouble-free for me.

In my case, everything else is really obscured by the fact documentation pages are more often mangled than not. And I have reinstalled it several times. I have no idea what causes it, but that definitely dominates my current user experience.

So strange that

It might have something to do with the fact I'm running MacOS Sierra, which was well in beta land when I installed v11 the first time.

I was just going to comment on staying away from the new macOS for a while

Heh...

not for any reason in particular but in the past I always upgraded on one of the few .xx updates

I have absolutely no idea if my troubles are related to Sierra, but it wouldn't necessarily surprise that it has just seen zero testing at WRI.

Then WRI is in good company...seems only a minority of larger developers make good use of Apple's beta program

Considering public release of Sierra was couple days ago, these two things might be related.

I might have some empathy for all those developers not testing on beta versions if the OS betas were as bad as they were around OS X 10.7...

Is btw. anyone knowledgeable/interested in Reinforcement Learning?

I implemented some very simple actor/critic algorithm using what is available at this moment in Mathematica 11.0

@Sascha its about the slowest program I've used on Windows 10 so far. Response to typing is really sluggish. Otherwise it's great - all the new features are pretty fun to explore, esp. the neural network stuff

@kirma agreed, tbh!

@blochwave ClearSystemCache[] helped improve some of the typing performance issues I was seeing. Maybe worth a shot.

@MichaelHale Thanks for the tip! Works a treat

Hi