Examples: query, "exact match", wildcard*, wild?ard, wild*rd
Fuzzy search: cake~ (finds cakes, bake)
Term boost: "red velvet"^4, chocolate^2
Field grouping: tags:(+work -"fun-stuff")
Escaping: Escape characters +-&|!(){}[]^"~*?:\ with \, e.g. \+
Range search: properties.timestamp:[1587729413488 TO *] (inclusive), properties.title:{A TO Z}(excluding A and Z)
Combinations: chocolate AND vanilla, chocolate OR vanilla, (chocolate OR vanilla) NOT "vanilla pudding"
Field search: properties.title:"The Title" AND text
Answered
I Am Still Going Through All The Docs And Intro Videos … But: Is The Only Way To Create A New Experiment To Run The Script That Contains The Experiment At Least Once? I Wonder About This B.C. Most Of What I Want To Run Are Quite Long Jobs, So Even Running

I am still going through all the docs and intro videos … but: is the only way to create a new experiment to run the script that contains the experiment at least once? I wonder about this b.c. most of what I want to run are quite long jobs, so even running it once locally would be bit of a roadblock.

  
  
Posted one year ago
Votes Newest

Answers 9


Yup if you scroll through the logs in the console, near the top (post config dump), you’ll see a git clone and checkout to the specific hash.

PS You can actually change this parameter in an experiment’s configuration if it is in draft mode.

  
  
Posted one year ago

you can put task.execute_remotely() to create it in draft mode. I've taken to configuring defaults to run things very quickly just in case i forget though (e.g. placeholder string for dataset, bail out early if not changed… or just do one epoch on a small subset of samples, etc).

  
  
Posted one year ago

🤔 could one create empty draft experiment placeholders, finalize all their code, commit it, and then and manually connect the impl as it exists in a file in a commit in a repo to that draft, once I’ve decided that all development is done?

  
  
Posted one year ago

but I’ll try out what you said - parameterize it all, and run a short version locally, then scale up in the UI

  
  
Posted one year ago

For reproducibility, it kind of makes sense though. The existence of the file is contingent on the worker cloning the source code. I'm sure things can be done to maintain state differently but I personally adapted to the git-based workflow for managing files pretty quickly.

though yes I will admit I had the same thought first: why must I run it each time?

Beware: squash merges will ruin the ability to reproduce the experiment at that time since the git commit will be lost (presuming the branch was deleted post-merge)

  
  
Posted one year ago

huh, ok … the need to run stuff locally first is a little odd, ngl… just have to get a sense of what the workflow here is

but it looks like execute_remotely is indeed what I want, and I should just standardize on using that,
either in-situ, or in an outer runner script that just calls that first, then calls down to my actual implementation

  
  
Posted one year ago

local development is fine, but local-running-first I am just unsure about

  
  
Posted one year ago

probably, but the syntax would be in that of a git diff, so it’d be a touch clunky if you asked me
Are you trying to avoid local development?

  
  
Posted one year ago

🤔 does a job/experiment always reproduce from git + commit hash + specific file?
(again, haven’t read through all the docs yet, a lot to take in)

  
  
Posted one year ago
1K Views
9 Answers
one year ago
one year ago
Tags