You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 12, 2018. It is now read-only.
This should be done towards the release of the tool, when we've more clearly defined the types of graphs that will be generated:
There's some redundancy in columns in the .db file. The main example I can think of is the use of both a node width and node height column, even though nodes are currently scaled by area (so width should equal height for all nodes). Update: we're looking into scaling differently right now (see #164), so this might be a moot point.
Once we've settled on a final specification for graph types, eliminate redundant stuff like this from the .db file. This will reduce .db size, which will in turn reduce processing time in the viewer.
The text was updated successfully, but these errors were encountered:
Also, the "shape" parameter for nodes is not necessarily needed, or at least is too much data -- we can easily deduce this info from the node id (is there a - prefix?) or have a "reverse_complement" parameter which just is either 0 or 1. No need to have "house" or "invhouse" |V| many times in the database.
Update: yeah, width and height are now officially different due to a new scaling method (#175).
So the only real inefficiency I can think of at present in the .db files' schema is the use of the "shape" parameter, which could just be a simple boolean value for "isPositive"/"isForward" or something.
This should be done towards the release of the tool, when we've more clearly defined the types of graphs that will be generated:
There's some redundancy in columns in the .db file. The main example I can think of is the use of both a node width and node height column, even though nodes are currently scaled by area (so width should equal height for all nodes). Update: we're looking into scaling differently right now (see #164), so this might be a moot point.
Once we've settled on a final specification for graph types, eliminate redundant stuff like this from the .db file. This will reduce .db size, which will in turn reduce processing time in the viewer.
The text was updated successfully, but these errors were encountered: