-
Notifications
You must be signed in to change notification settings - Fork 23
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
Specify units in impact responses #43
Comments
Hi @da-ekchajzer, I prefer your first proposal (adding dedicated units properties) rather than integrating in in the value field. But IMHO we could have
{
"gwp":{"value":"30", "unit":"kgCO2eq"}
"adp":{"value":"10", "unit":"kgSbeq."}
"pe":{"value":"5", "unit":"MJ"}
} Maybe this last model should even be the default (non verbose). From my perspective, not returning units is more a matter of optimization (reduced data exchange) but I think we should maybe rather be explicit by default. Are there other considerations for not returning units ? |
We haven't addressed the unit issue until now because we haven't thought about it. I personally like your proposition, since units are as important as the value itself. Besides, since we have different duration units, it can be inadequate to assess extreme durations. For instance, kgCO2eq is too big to assess the impact of an hour of cloud istances. The only drawback I see is the complexification of the object. The question for me now is : should we send this """complex object""" only in verbose mode ? Or for all impacts objects ? |
I like the way this object is precise and self-explaining. I'm not seeing too much complexity, I feel that it should the response by default. By the way, in the server API, should the response be built to follow the same guideline? ie : {
"gwp": {
"manufacture": 3292.0,
"use": 696.0,
"unit":"kgCO2eq"
},
"pe": {
"manufacture": 41821.0,
"use": "Not Implemented",
"unit":"MJ"
},
"adp": {
"manufacture": 0.234,
"use": "Not Implemented",
"unit":"kgSbeq."
}
} In your opinion will the manufacture and use impacts be expressed always with the same unit? |
I agree with your opinion to put the unit as close to the value as possible
I think we should have the same units :
The client will be able to convert if he need Problem - To Round or not to round ?For instance, if I want the impact of the server for 1 hour : {
"model": {
},
"configuration": {
},
"usage": {
"hours_use_time": 1,
"hour_electrical_consumption": 500
}
} Will return a usage impact of 0 in kgCO2eq, since the value is rounded to the unit "gwp": {
"manufacture": 3292,
"use": 0
} Without rounding many digits, without considering significant figures "gwp": {
"manufacture": 3291.81656474227,
"use": 0.07949550000000001,
"unit":"kgCO2eq"
} Solution
"gwp": {
"manufacture": 3291.81,
"use": 0.079,
"unit":"kgCO2eq"
} 2? Could be an input provided by the user What's your your opinion on this solution ? |
Good point raised on the precision of those rounded values. Generally a result value should not be more precise than the inputs given to calculate it. "usage": {
"hours_use_time": 1,
"hour_electrical_consumption": 500
} In your example, the significant figures are 1 for the hours_use_time, and 3 for the hour_electrical_consumption, it reflects than the 'use' field should be only precise to 1 significant figure. If I'm not mistaken the results should be : "gwp": {
"manufacture": 3291,
"use": 0.08,
"unit":"kgCO2eq"
} In theory, the user should input "hours_use_time": 1.0 to increase precision to 2 significant figures. In your example the "manufacture" is calculated without any user inputs, so we should be able to define its precision based on the internal data used from the calculator (TBD) Solution
Does it make sense to you? Would that be easily understandable by the api consumers? |
I agree with your solution ! To reformulate, we round according to the less precise attribute of the object used to measure the impact. We don't need to distinguish two cases for user and API data. We can directly use the completed objects (completed_server, completed_cpu, completed_ssd, ...) which contains User input + API data. In addition, we could let the user override the default process and specify the number of significant figures wanted in a query parameter : Solution
Same questions ;) |
Correlated issue : Are they guidelines on the precision for internal data? If it is 3 significant digits by default, then we can document it and users can take it into account. I am working on a solution with the 'auto' precision, let's iterate from that |
Problem
Units are not specified in impact responses.
Solution
Add static units object in the verbose
Alternatives
Transform impacts from float to string. Concatenated value and unit.
Example : '30' => "30 kgCO2eq"
Drawback : user need to transform the string back into float if they need to reuse the data
Additional context or elements
Example of units JSON object inside verbose
The text was updated successfully, but these errors were encountered: