Questions regarding the logger

[HeleNoir]

I came across some question/problems with our current logging procedure:

• We do not automatically log the final values. However, I think we should.
• In examples\coco.rs we use log_common_sets and then set another trigger for logging other values. This results in two triggers and a lot of useless lines in the data. While it is not really a problem, it is nevertheless not nice.

I'm not quite sure if and how we want to adress these issues, so I'm asking for some feedback @luleyleo @Saethox .

[Saethox]

We do not automatically log the final values. However, I think we should.

Yeah, we log only every 10 iterations or so, so we may lose the values of the last 9 iterations. Fixes that I can think of include

• using the Change trigger to log the best objective value, so we certainly know that the value has not changed if it's not logged anymore,
• or appending a second Logger at the very end, after the loop, to log final values.

In examples\coco.rs we use log_common_sets and then set another trigger for logging other values. This results in two triggers and a lot of useless lines in the data. While it is not really a problem, it is nevertheless not nice.

You can use Logger::builder().log_set(LogSet::common().with_logger(...)) to append to the same trigger used by the common LogSet's. Is this what you mean? In the special case of coco.rs, you could also use Logger::builder().log_common_single_objective_sets() directly.

[HeleNoir]

Thanks for the tipps! I think I managed to resolve the issue with the final values by adding two new trigger options. They may be not nice, but in contrast to your first idea they provide a value for the last iteration/evaluation. However, your idea to append a second Logger might be better.

Towards log_common_sets: I think if we configure more logging options and trigger for a specific experiment, it is not necessary to use this anyway. It might, as in my case, only add useless entries. But it is still helpful for a general overview of the runs.

[HeleNoir]

And another question (I knew there would be some problems when trying to create the first experiment, but I'm getting a bit tired...): Can we log only the diversity value of the DiversityState? @Saethox @luleyleo

At the moment, the whole state is logged. This makes it more complex to prepare the data for evaluation. I could resolve this in Python by reformatting the data, but this will take forever to run with larger experiments...

[luleyleo]

Can we log only the diversity value of the DiversityState?

Yes, we have two options here:

1. Change the struct definition of diversity state to serialize only the normalized diversity value.
2. Use a custom logging function which logs only the normalized diversity value and ignores the rest.

The latter is certainly the more flexible option, but the prior might be more convenient.

Option 1:

/// State for logging/tracking population diversity.
#[derive(Debug, Serialize)]
#[serde(transparent)]
pub struct DiversityState<I> {
    /// Normalized diversity.
    pub diversity: f64,

    /// Non-normalized maximal diversity.
    #[serde(skip)]
    pub max_diversity: f64,
    
    #[serde(skip)]
    phantom: PhantomData<I>,
}

Option 2:

pub fn normalized_diversity<I>(state: &State) -> Entry {
    Entry {
        name: type_name::<DiversityState<I>>(),
        value: Box::new(state.get::<DiversityState<I>>().diversity)
    }
}

[HeleNoir]

Thanks! I think I prefer and will use Option 2, especially as there might be some similar cases in the future.