« first day (2176 days earlier)      last day (2298 days later) » 

12:36 AM
Hey everyone, Happy New Year!!!
Is anyone aware of how to properly pass multiple arguments to an executable using Run[~] on Windows? It's straight-forward using RunProcess[~], but there is a bug that causes the Math kernel to hog CPU while just waiting for the extra output produced by RunProcess[~] ...
It's driving me crazy that I can't figure it out.
 
 
10 hours later…
10:10 AM
A syntax highlighter for Rogue. Community post
 
 
2 hours later…
12:33 PM
@Szabolcs Does IGraphM offer any way to write `graph // EdgeList[#, _?(Function[edge,
PropertyValue[{#, edge}, "Selected"]])] &` in a more compact and intuitive way?
This is again something that should be easy but isn't. I don't get why the Patterntest for EdgeList does not get passed a "self reference" i.e. {graph, edge} instead of just edge
 
Not really ... you could do Pick[EdgeList[g], IGEdgeProp["Selected"][g]]
But keep the questions coming. They might give me ideas on how to do this better.
 
I personally find PropertyValue a pain to use in general
 
IGraph/M focuses on treating properties as vectors of the same length as VertexList[g] or EdgeList[g]. I find this more manageable, but it does lose some generality.
@Sascha Everyone does.
 
Despite your philosophy to not duplicate build-in functionality in IGraphM, have you though about a IGPropertyValue function that remedies at least the syntactic issues with PropertyValue?
 
@Sascha Not so far, but it does sound reasonable. I'm not against it. We'd have to figure out what's the best syntax though.
One problem is that properties are not only a pain to work with, the related functionality is also buggy and slow. It is very hard to implement functions that deal with properties (or just don't discard properties).
There's much simpler stuff I haven't gotten around to implementing because of this. For example, when converting a directed graph to an undirected graph, a pair of a->b, b->a edges may get merged into a single a<->b edge. It would be nice to be able to control how to merge properties (e.g. add up, take arithmetic mean, geometric mean, maximum, just put them into a list, etc.)
 
12:43 PM
you mean like Merge does for associations?
 
Kind of.
 
I can imagine that would be usefull
 
I haven't been able to implement even something as simple as this in a general way. I have my own functions for edge weights only, which is all I need. But I didn't include it because a proper function should be able to handle any property.
Of course it's not that hard to implement it if all you need is that it work. But it's very hard to implement it so that it is not terribly slow.
There's the same problem for multigraphs: what to do with proprties when merging multi-edges?
Well, most properties are mishandled with multi-edges. Only a few work, like EdgeWeight or EdgeCapacity.
 
This could all be so easy if WRI would just rewrite Properties to use associations
 
@Sascha Then they'd get into even more trouble with multigraphs.
It seems to me that there is very little development on Graph these days. I wrote a complaint to support last month. Easy to fix bugs are sometimes fixed, I have to admit that. They also added some styling options (PlotTheme). But that's about it. Very severe non-trivial bugs have stayed unchanged since v10.0 or earlier.
There seems to be "bit rot" too. Some stuff that used to work ceases to work. Documentation examples no longer evaluate. E.g. several of the properties of OptimumFlowData no longer extract properly, and this is even show in the documentation! (See e.g. the very last example.)
 
12:51 PM
Not that you mention OptimimFlowData, i also recently encountered an issue with FindMinimumCostFlow
When comparing the result of FindIndependentEdgeSet and equivalent formulation for FindMinimumCostFlow for weighted bipartide graphs at some point FindMinimumCostFlow does give a different result than FindIndependentEdgeSet
(for large graphs)
 
I used to have a notebook where I tracked a few serious bugs (a few were fixed, most still aren't, after multiple reports). Take a look at this:
Every time it is evaluated, it gives a different result.
I imagine the discussion within WRI: "Almost no one uses our graph stuff seriously, so there's no point in spending resources on it." Of course no one uses it if after multiple reports your functions still return wrong results without a warning!! How can anyone trust Mathematica if it's like this?
 
Exactly
I general I'd like to see more work done on anything optimization related be it flow in graphs or better/faster optimizers for NMinimize
@Szabolcs Concerning my issue from before, a Select-like utility function would be a nice replacement for using the second argument of EdgeList (and VertexList).
Or in this case rather a Cases-like function
Syntax could be something like IGEdgeMap e.g. graph // IGEdgeCases[pattern, edgeProperty]
or IGEdgeSelect[function, edgeProperty]
For generality it might be nice if the result of such a function would not be a list of the edges but a graph containing only the selected edges. One would then have to call EdgeList on the Graph to get just the list of course
Similar to the build-in Subgraph
 
 
4 hours later…
4:48 PM
@Sascha I'll think about these things. I really need input like yours to be able to get it right. If you already have a gitter or github account, consider joining the chatroom too: gitter.im/IGraphM/Lobby
The thing is that I generally dislike working with properties because there are so many issues with them. I use them only when some builtin function requires it. Thus I haven't put much effort into trying to make them more usable.
 
 
2 hours later…
7:06 PM
Hi, is there a way to convert very small values like 1e-16 in mathematica to zero?
Found it Chop[] works
 

« first day (2176 days earlier)      last day (2298 days later) »