Sketch of possible text representations of a getguesstimate.com spreadsheet

gistfile1.txt

Naive thinking of ways to represent @getguesstimate spreadsheets as text....
Using http://www.getguesstimate.com/models/314 as an example

in YML

count_meltdowns:
  label: Number of meltdowns  
  formula: normal(0,2)   # distributions use function notation?

minutes_per_meltdown:
  label: Minutes per meltdown    # if label is skipped, split/capitalize node id to save on typing
  formula: uniform(3,13)
  
total_meltdown_time:
  formula: count_meltdowns * minutes_per_meltdown   # can also force everthing into function notation
  reasoning: |
    some explanation here
    yml allows multiline strings
    and you get parsing of these for free


S expressions or Clojure syntax could be fun too, but not as (general) user-friendly, maybe

(defnode number-meltdowns
  :label "Number of meltdowns"
  (uniform-dist 0 2))

(defnode minutes-per-meltdown
  :label "Minutes per meltdown"
  :formula (uniform-dist 3 13))

(defnode total-meltdown-time
  (* number-meltdowns minutes-per-meltdown))

I like this as a starting point. I'll share some of my thoughts on why this would be difficult to do right now.

First, a lot of names in the graphical app have spaces. This seems like it would work well in raw text form, but not as much in a graphical display. We could also use variable names, which seems like a reasonable alternative.

Second, I'd be curious what to do with cells without names. This is especially true for tables of data. This Guesstimate has an example of a 'table' of data. I think these will just need an alternative notation. They may have to be recognized as tables, then described accordingly (for instance, united_states.population)

@OAGr

re: tables, can think of a couple options.

• If the emphasis is on storing data in the most appropriate and easily parse-able format, then maybe tables could be CSV files referenced from the cell, re-using the function notation (YML example):

    population:
      label: "Population distribution between states"
      formula: csv_table("us-population.csv")

    total_us:
      label: "Total population of US"
      formula: sum(population.state_population)

This obviously means that a "spreadsheet" is no longer one file but a directory, but on the other hand that opens up other interesting possibilities

• On the other hand, if the focus is on keeping it all in one file (can't think of a reason why that would have to be an overriding design principle), I'm guessing JSON works, but not nearly as human-friendly, especially if tabular data is added and files grow to large sizes
• I don't have much experience with YML, but it seems to support extensions, so it's probably possible to store contents of CSV files inside https://en.wikipedia.org/wiki/YAML#Other_specified_data_types

Now that I think about it, why did you originally want this feature? If the goal is to have text files that can be converted into Guesstimate models, that's a lot easier than having ones that are interoperable (can be converted back and forth). There's already a private API and we've had someone else try it; with that we could have a lot more flexibility for anyone to make their own format method and have that convert to a model.

Agreed that it would make sense to have data as part of other files, that could work.

One limitation of this is that it would make dependencies difficult; the longer term vision for Guesstimate is for it to be a bit like a wiki, where some models could reference data from other models or the internet. This makes it much less repo like, but there may be some clever ways to get much of the best of both worlds. Programmers have a lot of ways of dealing with dependencies, but it would definitely be a fair bit of work to do all that dependency management for something like this.