Class SuggestTrialsRequest.Builder

  • All Implemented Interfaces:
    SuggestTrialsRequestOrBuilder, com.google.protobuf.Message.Builder, com.google.protobuf.MessageLite.Builder, com.google.protobuf.MessageLiteOrBuilder, com.google.protobuf.MessageOrBuilder, Cloneable
    Enclosing class:
    SuggestTrialsRequest

    public static final class SuggestTrialsRequest.Builder
    extends com.google.protobuf.GeneratedMessageV3.Builder<SuggestTrialsRequest.Builder>
    implements SuggestTrialsRequestOrBuilder
     Request message for
     [VizierService.SuggestTrials][google.cloud.aiplatform.v1.VizierService.SuggestTrials].
     
    Protobuf type google.cloud.aiplatform.v1.SuggestTrialsRequest
    • Method Detail

      • getDescriptor

        public static final com.google.protobuf.Descriptors.Descriptor getDescriptor()
      • internalGetFieldAccessorTable

        protected com.google.protobuf.GeneratedMessageV3.FieldAccessorTable internalGetFieldAccessorTable()
        Specified by:
        internalGetFieldAccessorTable in class com.google.protobuf.GeneratedMessageV3.Builder<SuggestTrialsRequest.Builder>
      • clear

        public SuggestTrialsRequest.Builder clear()
        Specified by:
        clear in interface com.google.protobuf.Message.Builder
        Specified by:
        clear in interface com.google.protobuf.MessageLite.Builder
        Overrides:
        clear in class com.google.protobuf.GeneratedMessageV3.Builder<SuggestTrialsRequest.Builder>
      • getDescriptorForType

        public com.google.protobuf.Descriptors.Descriptor getDescriptorForType()
        Specified by:
        getDescriptorForType in interface com.google.protobuf.Message.Builder
        Specified by:
        getDescriptorForType in interface com.google.protobuf.MessageOrBuilder
        Overrides:
        getDescriptorForType in class com.google.protobuf.GeneratedMessageV3.Builder<SuggestTrialsRequest.Builder>
      • getDefaultInstanceForType

        public SuggestTrialsRequest getDefaultInstanceForType()
        Specified by:
        getDefaultInstanceForType in interface com.google.protobuf.MessageLiteOrBuilder
        Specified by:
        getDefaultInstanceForType in interface com.google.protobuf.MessageOrBuilder
      • build

        public SuggestTrialsRequest build()
        Specified by:
        build in interface com.google.protobuf.Message.Builder
        Specified by:
        build in interface com.google.protobuf.MessageLite.Builder
      • buildPartial

        public SuggestTrialsRequest buildPartial()
        Specified by:
        buildPartial in interface com.google.protobuf.Message.Builder
        Specified by:
        buildPartial in interface com.google.protobuf.MessageLite.Builder
      • clone

        public SuggestTrialsRequest.Builder clone()
        Specified by:
        clone in interface com.google.protobuf.Message.Builder
        Specified by:
        clone in interface com.google.protobuf.MessageLite.Builder
        Overrides:
        clone in class com.google.protobuf.GeneratedMessageV3.Builder<SuggestTrialsRequest.Builder>
      • setField

        public SuggestTrialsRequest.Builder setField​(com.google.protobuf.Descriptors.FieldDescriptor field,
                                                     Object value)
        Specified by:
        setField in interface com.google.protobuf.Message.Builder
        Overrides:
        setField in class com.google.protobuf.GeneratedMessageV3.Builder<SuggestTrialsRequest.Builder>
      • clearField

        public SuggestTrialsRequest.Builder clearField​(com.google.protobuf.Descriptors.FieldDescriptor field)
        Specified by:
        clearField in interface com.google.protobuf.Message.Builder
        Overrides:
        clearField in class com.google.protobuf.GeneratedMessageV3.Builder<SuggestTrialsRequest.Builder>
      • clearOneof

        public SuggestTrialsRequest.Builder clearOneof​(com.google.protobuf.Descriptors.OneofDescriptor oneof)
        Specified by:
        clearOneof in interface com.google.protobuf.Message.Builder
        Overrides:
        clearOneof in class com.google.protobuf.GeneratedMessageV3.Builder<SuggestTrialsRequest.Builder>
      • setRepeatedField

        public SuggestTrialsRequest.Builder setRepeatedField​(com.google.protobuf.Descriptors.FieldDescriptor field,
                                                             int index,
                                                             Object value)
        Specified by:
        setRepeatedField in interface com.google.protobuf.Message.Builder
        Overrides:
        setRepeatedField in class com.google.protobuf.GeneratedMessageV3.Builder<SuggestTrialsRequest.Builder>
      • addRepeatedField

        public SuggestTrialsRequest.Builder addRepeatedField​(com.google.protobuf.Descriptors.FieldDescriptor field,
                                                             Object value)
        Specified by:
        addRepeatedField in interface com.google.protobuf.Message.Builder
        Overrides:
        addRepeatedField in class com.google.protobuf.GeneratedMessageV3.Builder<SuggestTrialsRequest.Builder>
      • isInitialized

        public final boolean isInitialized()
        Specified by:
        isInitialized in interface com.google.protobuf.MessageLiteOrBuilder
        Overrides:
        isInitialized in class com.google.protobuf.GeneratedMessageV3.Builder<SuggestTrialsRequest.Builder>
      • mergeFrom

        public SuggestTrialsRequest.Builder mergeFrom​(com.google.protobuf.CodedInputStream input,
                                                      com.google.protobuf.ExtensionRegistryLite extensionRegistry)
                                               throws IOException
        Specified by:
        mergeFrom in interface com.google.protobuf.Message.Builder
        Specified by:
        mergeFrom in interface com.google.protobuf.MessageLite.Builder
        Overrides:
        mergeFrom in class com.google.protobuf.AbstractMessage.Builder<SuggestTrialsRequest.Builder>
        Throws:
        IOException
      • getParent

        public String getParent()
         Required. The project and location that the Study belongs to.
         Format: `projects/{project}/locations/{location}/studies/{study}`
         
        string parent = 1 [(.google.api.field_behavior) = REQUIRED, (.google.api.resource_reference) = { ... }
        Specified by:
        getParent in interface SuggestTrialsRequestOrBuilder
        Returns:
        The parent.
      • getParentBytes

        public com.google.protobuf.ByteString getParentBytes()
         Required. The project and location that the Study belongs to.
         Format: `projects/{project}/locations/{location}/studies/{study}`
         
        string parent = 1 [(.google.api.field_behavior) = REQUIRED, (.google.api.resource_reference) = { ... }
        Specified by:
        getParentBytes in interface SuggestTrialsRequestOrBuilder
        Returns:
        The bytes for parent.
      • setParent

        public SuggestTrialsRequest.Builder setParent​(String value)
         Required. The project and location that the Study belongs to.
         Format: `projects/{project}/locations/{location}/studies/{study}`
         
        string parent = 1 [(.google.api.field_behavior) = REQUIRED, (.google.api.resource_reference) = { ... }
        Parameters:
        value - The parent to set.
        Returns:
        This builder for chaining.
      • clearParent

        public SuggestTrialsRequest.Builder clearParent()
         Required. The project and location that the Study belongs to.
         Format: `projects/{project}/locations/{location}/studies/{study}`
         
        string parent = 1 [(.google.api.field_behavior) = REQUIRED, (.google.api.resource_reference) = { ... }
        Returns:
        This builder for chaining.
      • setParentBytes

        public SuggestTrialsRequest.Builder setParentBytes​(com.google.protobuf.ByteString value)
         Required. The project and location that the Study belongs to.
         Format: `projects/{project}/locations/{location}/studies/{study}`
         
        string parent = 1 [(.google.api.field_behavior) = REQUIRED, (.google.api.resource_reference) = { ... }
        Parameters:
        value - The bytes for parent to set.
        Returns:
        This builder for chaining.
      • getSuggestionCount

        public int getSuggestionCount()
         Required. The number of suggestions requested. It must be positive.
         
        int32 suggestion_count = 2 [(.google.api.field_behavior) = REQUIRED];
        Specified by:
        getSuggestionCount in interface SuggestTrialsRequestOrBuilder
        Returns:
        The suggestionCount.
      • setSuggestionCount

        public SuggestTrialsRequest.Builder setSuggestionCount​(int value)
         Required. The number of suggestions requested. It must be positive.
         
        int32 suggestion_count = 2 [(.google.api.field_behavior) = REQUIRED];
        Parameters:
        value - The suggestionCount to set.
        Returns:
        This builder for chaining.
      • clearSuggestionCount

        public SuggestTrialsRequest.Builder clearSuggestionCount()
         Required. The number of suggestions requested. It must be positive.
         
        int32 suggestion_count = 2 [(.google.api.field_behavior) = REQUIRED];
        Returns:
        This builder for chaining.
      • getClientId

        public String getClientId()
         Required. The identifier of the client that is requesting the suggestion.
        
         If multiple SuggestTrialsRequests have the same `client_id`,
         the service will return the identical suggested Trial if the Trial is
         pending, and provide a new Trial if the last suggested Trial was completed.
         
        string client_id = 3 [(.google.api.field_behavior) = REQUIRED];
        Specified by:
        getClientId in interface SuggestTrialsRequestOrBuilder
        Returns:
        The clientId.
      • getClientIdBytes

        public com.google.protobuf.ByteString getClientIdBytes()
         Required. The identifier of the client that is requesting the suggestion.
        
         If multiple SuggestTrialsRequests have the same `client_id`,
         the service will return the identical suggested Trial if the Trial is
         pending, and provide a new Trial if the last suggested Trial was completed.
         
        string client_id = 3 [(.google.api.field_behavior) = REQUIRED];
        Specified by:
        getClientIdBytes in interface SuggestTrialsRequestOrBuilder
        Returns:
        The bytes for clientId.
      • setClientId

        public SuggestTrialsRequest.Builder setClientId​(String value)
         Required. The identifier of the client that is requesting the suggestion.
        
         If multiple SuggestTrialsRequests have the same `client_id`,
         the service will return the identical suggested Trial if the Trial is
         pending, and provide a new Trial if the last suggested Trial was completed.
         
        string client_id = 3 [(.google.api.field_behavior) = REQUIRED];
        Parameters:
        value - The clientId to set.
        Returns:
        This builder for chaining.
      • clearClientId

        public SuggestTrialsRequest.Builder clearClientId()
         Required. The identifier of the client that is requesting the suggestion.
        
         If multiple SuggestTrialsRequests have the same `client_id`,
         the service will return the identical suggested Trial if the Trial is
         pending, and provide a new Trial if the last suggested Trial was completed.
         
        string client_id = 3 [(.google.api.field_behavior) = REQUIRED];
        Returns:
        This builder for chaining.
      • setClientIdBytes

        public SuggestTrialsRequest.Builder setClientIdBytes​(com.google.protobuf.ByteString value)
         Required. The identifier of the client that is requesting the suggestion.
        
         If multiple SuggestTrialsRequests have the same `client_id`,
         the service will return the identical suggested Trial if the Trial is
         pending, and provide a new Trial if the last suggested Trial was completed.
         
        string client_id = 3 [(.google.api.field_behavior) = REQUIRED];
        Parameters:
        value - The bytes for clientId to set.
        Returns:
        This builder for chaining.
      • getContextsList

        public List<TrialContext> getContextsList()
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
        Specified by:
        getContextsList in interface SuggestTrialsRequestOrBuilder
      • getContextsCount

        public int getContextsCount()
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
        Specified by:
        getContextsCount in interface SuggestTrialsRequestOrBuilder
      • getContexts

        public TrialContext getContexts​(int index)
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
        Specified by:
        getContexts in interface SuggestTrialsRequestOrBuilder
      • setContexts

        public SuggestTrialsRequest.Builder setContexts​(int index,
                                                        TrialContext value)
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
      • setContexts

        public SuggestTrialsRequest.Builder setContexts​(int index,
                                                        TrialContext.Builder builderForValue)
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
      • addContexts

        public SuggestTrialsRequest.Builder addContexts​(TrialContext value)
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
      • addContexts

        public SuggestTrialsRequest.Builder addContexts​(int index,
                                                        TrialContext value)
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
      • addContexts

        public SuggestTrialsRequest.Builder addContexts​(TrialContext.Builder builderForValue)
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
      • addContexts

        public SuggestTrialsRequest.Builder addContexts​(int index,
                                                        TrialContext.Builder builderForValue)
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
      • addAllContexts

        public SuggestTrialsRequest.Builder addAllContexts​(Iterable<? extends TrialContext> values)
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
      • clearContexts

        public SuggestTrialsRequest.Builder clearContexts()
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
      • removeContexts

        public SuggestTrialsRequest.Builder removeContexts​(int index)
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
      • getContextsBuilder

        public TrialContext.Builder getContextsBuilder​(int index)
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
      • getContextsOrBuilder

        public TrialContextOrBuilder getContextsOrBuilder​(int index)
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
        Specified by:
        getContextsOrBuilder in interface SuggestTrialsRequestOrBuilder
      • getContextsOrBuilderList

        public List<? extends TrialContextOrBuilder> getContextsOrBuilderList()
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
        Specified by:
        getContextsOrBuilderList in interface SuggestTrialsRequestOrBuilder
      • addContextsBuilder

        public TrialContext.Builder addContextsBuilder()
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
      • addContextsBuilder

        public TrialContext.Builder addContextsBuilder​(int index)
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
      • getContextsBuilderList

        public List<TrialContext.Builder> getContextsBuilderList()
         Optional. This allows you to specify the "context" for a Trial; a context
         is a slice (a subspace) of the search space.
        
         Typical uses for contexts:
         1) You are using Vizier to tune a server for best performance, but there's
           a strong weekly cycle.  The context specifies the day-of-week.
           This allows Tuesday to generalize from Wednesday without assuming that
           everything is identical.
         2) Imagine you're optimizing some medical treatment for people.
           As they walk in the door, you know certain facts about them
           (e.g. sex, weight, height, blood-pressure).  Put that information in the
           context, and Vizier will adapt its suggestions to the patient.
         3) You want to do a fair A/B test efficiently.  Specify the "A" and "B"
           conditions as contexts, and Vizier will generalize between "A" and "B"
           conditions.  If they are similar, this will allow Vizier to converge
           to the optimum faster than if "A" and "B" were separate Studies.
           NOTE: You can also enter contexts as REQUESTED Trials, e.g. via the
           CreateTrial() RPC; that's the asynchronous option where you don't need a
           close association between contexts and suggestions.
        
         NOTE: All the Parameters you set in a context MUST be defined in the
           Study.
         NOTE: You must supply 0 or $suggestion_count contexts.
           If you don't supply any contexts, Vizier will make suggestions
           from the full search space specified in the StudySpec; if you supply
           a full set of context, each suggestion will match the corresponding
           context.
         NOTE: A Context with no features set matches anything, and allows
           suggestions from the full search space.
         NOTE: Contexts MUST lie within the search space specified in the
           StudySpec.  It's an error if they don't.
         NOTE: Contexts preferentially match ACTIVE then REQUESTED trials before
           new suggestions are generated.
         NOTE: Generation of suggestions involves a match between a Context and
           (optionally) a REQUESTED trial; if that match is not fully specified, a
           suggestion will be geneated in the merged subspace.
         
        repeated .google.cloud.aiplatform.v1.TrialContext contexts = 4 [(.google.api.field_behavior) = OPTIONAL];
      • setUnknownFields

        public final SuggestTrialsRequest.Builder setUnknownFields​(com.google.protobuf.UnknownFieldSet unknownFields)
        Specified by:
        setUnknownFields in interface com.google.protobuf.Message.Builder
        Overrides:
        setUnknownFields in class com.google.protobuf.GeneratedMessageV3.Builder<SuggestTrialsRequest.Builder>
      • mergeUnknownFields

        public final SuggestTrialsRequest.Builder mergeUnknownFields​(com.google.protobuf.UnknownFieldSet unknownFields)
        Specified by:
        mergeUnknownFields in interface com.google.protobuf.Message.Builder
        Overrides:
        mergeUnknownFields in class com.google.protobuf.GeneratedMessageV3.Builder<SuggestTrialsRequest.Builder>