-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade process_results to include plots #951
Comments
There was the idea of trying to use weights and biases for this (and for
the batch execution).
Do you think it would be applicable?
* Miguel Riem de Oliveira Professor Auxiliar *
email: ***@***.*** | ***@***.***
zoom: https://videoconf-colibri.zoom.us/j/7155402102
office: 22.2.18 | ext: 23887
Dep. de Engenharia Mecânica, Universidade de Aveiro
*Campus Universitário de Santiago, 3810-193 Portugal*
…On Thu, May 9, 2024 at 5:21 PM Bruno Silva ***@***.***> wrote:
I find comparing and analyzing the results after a batch very
time-consuming and prone to error.
It would be great if the processing also outputted a plot of the results.
There is a problem with this though. This requires ATOM to know which
experiments are related and which are not.
For example in this tree : ( from my odometry experiments)
├── nig_0.1
├── nig_0.15
├── nig_0.15-ntfv_0.1
├── nig_0.15-ntfv_0.15
├── nig_0.15-ntfv_0.2
├── nig_0.15-ntfv_0.25
├── nig_0.15-ntfv_0.3
├── nig_0.1-ntfv_0.1
├── nig_0.1-ntfv_0.15
├── nig_0.1-ntfv_0.2
├── nig_0.1-ntfv_0.25
├── nig_0.1-ntfv_0.3
├── nig_0.2
├── nig_0.25
├── nig_0.25-ntfv_0.1
├── nig_0.25-ntfv_0.15
├── nig_0.25-ntfv_0.2
├── nig_0.25-ntfv_0.25
├── nig_0.25-ntfv_0.3
├── nig_0.2_no_odom_calib
├── nig_0.2-ntfv_0.1
├── nig_0.2-ntfv_0.15
├── nig_0.2-ntfv_0.2
├── nig_0.2-ntfv_0.25
├── nig_0.2-ntfv_0.2_no_odom_calib
├── nig_0.2-ntfv_0.3
├── nig_0.3
├── nig_0.3-ntfv_0.1
├── nig_0.3-ntfv_0.15
├── nig_0.3-ntfv_0.2
├── nig_0.3-ntfv_0.25
├── nig_0.3-ntfv_0.3
└── perfect_sim
How would you know which experiments were part of the same plot?
My first guess was to compare which experiments had the same alphabetic
characters but this is very easily prone to a lot of error.
These 2 for example should be on the same plot:
├── nig_0.3-ntfv_0.2
├── nig_0.3-ntfv_0.25
But this shouldn't even though they have same alphabetic chars.
├── nig_0.2-ntfv_0.2
There is no way for the code to know which experiments are related.
There is a super easy fix but would break backwards compatibility : Add a
field in data.yml called groups, like so :
experiments:
group_1:
#Varying ntfv with fixed nig = 0.1
- {name: nig_0.1-ntfv_0.1 , nig_value: 0.1, ntfv_value: 0.1, calibrate_odom : true}
- {name: nig_0.1-ntfv_0.15, nig_value: 0.1, ntfv_value: 0.15, calibrate_odom : true}
- {name: nig_0.1-ntfv_0.2 , nig_value: 0.1, ntfv_value: 0.2, calibrate_odom : true}
- {name: nig_0.1-ntfv_0.25, nig_value: 0.1, ntfv_value: 0.25, calibrate_odom : true}
- {name: nig_0.1-ntfv_0.3 , nig_value: 0.1, ntfv_value: 0.3, calibrate_odom : true}
group_2:
#Varying ntfv with fixed nig = 0.2
- {name: nig_0.1-ntfv_0.1 , nig_value: 0.2, ntfv_value: 0.1, calibrate_odom : true}
- {name: nig_0.1-ntfv_0.15, nig_value: 0.2, ntfv_value: 0.15, calibrate_odom : true}
- {name: nig_0.1-ntfv_0.2 , nig_value: 0.2, ntfv_value: 0.2, calibrate_odom : true}
- {name: nig_0.1-ntfv_0.25, nig_value: 0.2, ntfv_value: 0.25, calibrate_odom : true}
- {name: nig_0.1-ntfv_0.3 , nig_value: 0.2, ntfv_value: 0.3, calibrate_odom : true}
I'll work on this even if its just for myself and if it proves useful we
consider making it on to noetic-devel
—
Reply to this email directly, view it on GitHub
<#951>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWTHVWIEV36GVXN5CNUANDZBOPAXAVCNFSM6AAAAABHPDHQYCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI4DQMBTGI4DKMY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
What do you mean weights and biases? I didn't get it. Attribute a "weight" (more like a id the way im thinking) to each related experience and relate them after in processing that way? I don't think thats it is it? |
I'm going back on my previous take. Other than breaking backwards compatibility, the way the plots would be generated would be fixed. After discussing with @manuelgitgomes, I settled on saving a yaml with the experiment settings on the experiment dir and then use it later in processing to plot whichever plots the user wants based on n conditions. |
I meant this: as @lucasrdalcol to show you what it can do. |
necessary plot.yml uploaded in NAS already
I will mention it whenever I seem him next week :) Plot graphs scriptThis is the new fully fledged plot maker in atom. Functionalities :
The script is already fully documented on the yaml with all possible functionalities. It is also full with informativeprints and custom debug prints as well. Example yaml :
Help section :
Example execution : What needs to be improved/enhanced :
@miguelriemoliveira @manuelgitgomes @Kazadhum I would like your opinion on this feature :) |
This looks great! Congrats @brunofavs ! |
and fixed a small bug when legend wasnt provided
Possibly migrate to seaborn. Could move the plotting to a separate function and give the user the option to choose between seaborn/matplotlib. |
I find comparing and analyzing the results after a batch very time-consuming and prone to error.
It would be great if the processing also outputted a plot of the results.
There is a problem with this though. This requires ATOM to know which experiments are related and which are not.
For example in this tree : ( from my odometry experiments)
How would you know which experiments were part of the same plot?
My first guess was to compare which experiments had the same alphabetic characters but this is very easily prone to a lot of error.
These 2 for example should be on the same plot:
But this shouldn't even though they have same alphabetic chars.
├── nig_0.2-ntfv_0.2
There is no way for the code to know which experiments are related.
There is a super easy fix but would break backwards compatibility : Add a field in
data.yml
calledgroups
, like so :I'll work on this even if its just for myself and if it proves useful we consider making it on to
noetic-devel
The text was updated successfully, but these errors were encountered: