3 ms·

And this works great, until some necessary thing isn't supported by the language/library/black-box/datalog implementation you're using. In reality the original

And this works great, until some necessary thing isn't supported by the language/library/black-box/datalog implementation you're using. In reality the original (hillelwayne) article is saying that the "graph" datatype is missing, as a standard type, which is true. Imperative language implementations abstract that away to libraries, which may be graph databases (datalog being one of many), or may be more tightly coupled things like networkx for cases where you need some kind closer knit integration and custom computation. Like, taking a step back, you're saying that no single representation is a panacea. And the original article is taking the same stance, that no single graph representation or library is a panacea, because so much is computation dependent.

jvanderbot 3y ago
Well I'm only saying what the article was saying. And you're repeating what both articles were saying. So I think we're in perfect agreement? > until some necessary thing isn't supported Taking a third side, I dont think the possibility of a missing algorithm should remove the positives of not assuming a graph format apriori. What I mean is, it seems that the approach of "use a data representation and implement your algorithm using something like queries" is meant to be an argument for empowering graph library writers to support a wider array of inputs (e.g., all of them) without specifying different implementations for those inputs. That's cool. Maybe I misunderstood what you said.
- joshuamorton 3y ago
  > What I mean is, it seems that the approach of "use a data representation and implement your algorithm using something like queries" is meant to be an argument for empowering graph library writers to support a wider array of inputs (e.g., all of them) without specifying different implementations for those inputs. I think this gets back to the thing I initially brought up, which is that if you take this as the guidance, features as simple as weighted edges jumps to the realm of SoTA. It's perhaps good research guidance, but that's not useful for me who needs to analyze a graph today.
  - jvanderbot 3y ago
    Well sure, my comment does not apply outside its intended scope. But for your scope, the article implies that this is not an esoteric, half baked thing - that it's real right now. So maybe if I were in your shoes that's where I'd look.

jvanderbot 3y ago

Well I'm only saying what the article was saying. And you're repeating what both articles were saying. So I think we're in perfect agreement? > until some necessary thing isn't supported Taking a third side, I dont think the possibility of a missing algorithm should remove the positives of not assuming a graph format apriori. What I mean is, it seems that the approach of "use a data representation and implement your algorithm using something like queries" is meant to be an argument for empowering graph library writers to support a wider array of inputs (e.g., all of them) without specifying different implementations for those inputs. That's cool. Maybe I misunderstood what you said.

joshuamorton 3y ago
> What I mean is, it seems that the approach of "use a data representation and implement your algorithm using something like queries" is meant to be an argument for empowering graph library writers to support a wider array of inputs (e.g., all of them) without specifying different implementations for those inputs. I think this gets back to the thing I initially brought up, which is that if you take this as the guidance, features as simple as weighted edges jumps to the realm of SoTA. It's perhaps good research guidance, but that's not useful for me who needs to analyze a graph today.
- jvanderbot 3y ago
  Well sure, my comment does not apply outside its intended scope. But for your scope, the article implies that this is not an esoteric, half baked thing - that it's real right now. So maybe if I were in your shoes that's where I'd look.