You use the graph functionality a lot, right? I am just trying my first thing now and having trouble already
For starters, this seems like an ugly bug, right?
Graph[{1 [DirectedEdge] 2}] // ConnectedGraphQ gives False, but if I first show the graph in the front end by running gr = Graph[{1 \[DirectedEdge] 2}] (without suppressing the output) and then do ConnectedGraphQ[gr], then I get True
@Rojo I'm throughly fed up with the graph related functionality of Mathematica. It's broken in so many ways, they know it, and they simply refuse to fix it.
I rarely get any useful feedback from WRI regarding graph-related functions, the developer behind it seems to be very cynical.
Somehow graph display and graph processing are weirdly intertwined, which doesn't sound like such a good design ...
One of my pet peeves is how NeighborhoodGraph is unusably slow unless use with GraphLayout -> None. It's slow because it computes the layout, which is totally irrelevant when all I want to compute is the neighborhood. The developer at WRI insists that NeighborhoodGraphhas to compute the layout and refuses to fix this function.
In the meantime most people have no clue why this function is performing so badly, they have no way of guessing what is going wrong, and likely they just assume that Mathematica is crappy software. Which apparently is true.
OK, it's not a crappy program, I still like Mathematica, and I still use graph functions. igraph has bugs too. But Mathematica clearly has too many. Ever since this functionality was added in v8, it's been the buggies area I use.
It's -17 C outside and our heating started to give up. It's been running constantly yet the temperature is dropping. It's now 18 degrees inside. The heater is blowing about 20-21 degrees air.
Hope it won't drop too low by morning.
These American apartments are not very well built and have almost no insulation ...
I´m a little confused. While Mathematica is running while a lot of minutes, I can see in the administrator (Windows8) that CPU is used in a 0%.
Is that normal?
@halirutan This reminds me of a lecture video on Youtube on quantum gravity, multiverses and whatnot by Arkani-Hamed. One of the top comments to the video was complaining about physicists' wrong attitude towards cats. (Schrödingers' cat was maybe mentioned once.)
Once again I lost my faith on any sensible self-criticism on Youtube comments...
@Kuba I guess the posix conventions is what you are looking for. But again, it isn't that hard really. There are only a few notations which are basically [...], <..> and .... Options have a short form like -a or -a <arg> or a long for --anOption
Look at the git man page. It is a very typical man page and even the one of gcc isn't more complicated.
@Kuba You have to understand that the SYNOPSIS is like the usage in ref-pages in the Documentation Center except that it never tells you what the command does.
It is just a formal description of the syntax. Everything else is described later in the man page.
@Kuba Feels like poaching... I don't think the issue is dealt with elsewhere on the site, at least not directly. (The function does not cross, i.e. not transversely, the contour.)
@halirutan Sounds good. It will have to be after I finish grading, though.
@halirutan I'm running the oven. I can't repair the heating. It's the landlord's responsibility and it's kept under a lock. I'm hoping they'll come soon and fix it.
What's a nice way of generating a list of n colors? I am coloring something with the colors, and it would help if the colors are somehow as different as possible to the human eye
Right now, I'm just getting a list with RandomColor[], and playing around with a RandomSeed[] to get a suitable list...
@Nakilon that's a nice idea, but if n gets even mildly large, I get different shades of say red. It's to difficult to tell the different shades of red apart
Hrmm! I want a StringMatchQ that could say answer to the question of "if the string being matched would have continued, could there have been a match?"
@Rojo Well, you could expect StringMatchQ["x", "xy"] to have a chance to continue matching (but fail matching because not enough characters, but StringMatchQ["y", "xy"] has no chance of "having a match in the future."