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
Unanswered
Another Conundrum: I Have A Single Script That Launches Training Jobs For Various Models. It Does This By Accepting A Flag Which Is The Model Name, And Dynamically Loading The Module To Train It. This Didn'T Mesh Well With Trains, Because The Project And


I presume is via the 

project_name

  and 

task_name

 parameters.

You are correct in your assumption, it only happens when you call Task.init but two distinctions:
ArgParser arguments are overridden (with trains-agent) even before Task.init is called Task.init when running under trains-agent will totally ignore the project/task name, it receives a pre-made task id, and uses it. So the project name and experiment are meaningless if you are running the task with trains-agent

A few implementation details to complete the image for you. Task.init creates a new Task when running manually, and puts data into the created task (e.g. ArgParser dictionary params etc)
When called under trains-agent, the Task.init will do the opposite. It will not create a Task but it receives a Task id, from it it will pull all the parameters into the code, including argparser etc.
The exception is ArgParser, since it can be called before Task.init is called. As long as someone imported the trains package, the auto-magic will make sure that in trains-agent mode, the argparser will get the correct arguments before the call for Task.init

  
  
Posted 4 years ago
178 Views
0 Answers
4 years ago
one year ago