3 ms·

So, critically, the missing data type is still missing. TFA talks about an input specification, but actually highlights that the lack of a fixed representation

So, critically, the missing data type is still missing. TFA talks about an input specification, but actually highlights that the lack of a fixed representation for graphs is a strength, because the "computer" can optimize the representation and algorithms on the fly using something like query optimization. So it's not that the graph datatype already exists, it's that, just like the referenced article posits, there is no good representation. And rather than lament and gnash teeth, we use a neato programming / query language to turn that into a strength.

joshuamorton 3y ago
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.

joshuamorton 3y ago

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.