Specify how many zeroes to display per attribute/method

[wmeyers]

On the converter overview page all attributes and methods are kind of treated the same in terms of how many zeroes are displayed. Some things like MJ's it's nice to see it per million or billion, but for some other things, like costs it would be much easier to just see the real number, or have it rounded in a different way.

A nice new feature would be to be able to specify in the attributes list of a converter how many zeroes to display, or maybe another option, to be able to choose which way to round based on the unit.

@dennisschoenmakers is this possible?

[dennisquintel]

@dennisschoenmakers is this possible?

Everything is possible. Assigned @paozac to have a look at how hard it is to add this as an attribute of the 'attribute'

[pzac]

I think that defining all the method units is better, so we can add a common metric library that handles the scaling consistently and automatically

[dennisquintel]

@wmeyers: I think it will help if you can provide some examples, that demonstrate te necessity.

[wmeyers]

For example: if I'm talking about the electricity bill of a single household I would like to see this formatted like this:

1,556.99 €/year

However, if I'm talking about the electricity bill of an entire country I would like to see it formatted like this:

45 bil €/year

Another example:

Full load hours is now often presented as 2,19 K It's just the amount of hours that a plant is 'On' per year, so cannot be higher than 8760, why not just display the whole number like 2190?

If this is difficult to implement we can also talk about changing the rounding logic. I think numbers that are rounded to K should probably not be rounded, because they are still very easy to read without the rounding. Now some things are rounded to 0.62 M, which would be much easier to read as 617.08 K. That last thing can be generalized more to say that things which go below 1 when rounded should probably be rounded a little bit less rigorously.

@paozac, can you specify how hard it is to implement the rounding per attribute/method. I think this might require a lot of work. How much work would it be to make changes to the rounding logic itself?

[pzac]

Defining the rounding per attribute/method would produce a lot of duplication. It can already be done: check https://github.com/dennisschoenmakers/etengine/blob/master/app/models/api/v3/converter_presenter_data.rb#L38 for an example.

It makes more sense, though, to define a rounding/scaling strategy per unit, that would be used consistently across the /data section, charts and converter details page. Let's go through the units and decide how we want the values to be formatted. I've added a jasmine test for metric.js, I will extend it, so we can first define the desired output and then implement the code.

[hasclass]

Related; https://github.com/dennisschoenmakers/etengine/issues/462

[pzac]

Check this

https://github.com/dennisschoenmakers/etmodel/commit/bea981772ec70220ddf6ad3d453c303fd6edf36b

This is still a javascript file, so we'll need an equivalent library for the ruby side on the engine. We have, unit-wise, three cases:

• format value and unit together (dashboard)
• format value without changing the unit (ie: show/hide a certain number of decimal digits - converter detail page)
• format value changing the unit (ie: transform 3000PJ into 3EJ and similar - chart axis)

I'll clean up Metric.js and the related ruby file. As a general rule do we agree on showing

x > 1000: 0 decimal digits 1 > x > 999: 2 dec dig 0 > x > 1: 3 or 4 dec dig

?

Then we have to decide the to switch unit: when should PJ become EJ, € -> k€, mln € -> bln €? With values > 10000? Let's find a good general rule.

[wmeyers]

@ChaelKruip @markquintel and @AlexanderWirtz please also contribute.

To make matters more complex I think there might be a difference in how rounding should be done in different cases. I mainly see a need for more significance (and thus less rounding) on the engine.

On the engine I would propose to drop the rounding to K for values smaller than 100_000. So you would get:

0.1
1
10
100
1000
10000
100 K

On etmodel I would propose to leave things mostly as they are and I like your suggestion of using 10_000 as a cap, especially for PJ values. For example the energy use in the Netherlands is 3500 PJ per year, and I would prefer showing that in PJ. For Germany the energy use is higher, around 13_000 PJ. Maybe we should show that in EJ, but I'm not super sure. @markquintel what do you think?

So on etmodel you would get:

10 TJ
0.1 PJ
1 PJ
10 PJ
100 PJ
1000 PJ
10 EJ
100 EJ

I'm not sure how easy this is to program and I'm not sure if everyone agrees.

[ChaelKruip]

I like these suggestions but have no strong feelings about the subject as long as it fits on the page and uses units that are generally accepted.

[pzac]

I've modified the engine number formatter following @wmeyers indications. The ETM will take longer since the unit scaling is used in many different places and there is still some legacy code

[wmeyers]

@paozac Wow, that's much, much, much more readable! Two (hopefully) small change requests:

• Format 1_000_000 as 1 M instead of 1000 K.
• Use , as 1000's separator and . for decimal separator, like we do in the rest of the engine and model. So, 1,000.00 instead of 1.000,00

For the rest I'm reallly happy with this change! It makes everything on the converter page a lot more readable!

[ChaelKruip]

Maybe this is nitpicking, or too subjective but I really dislike comma as a separator in numbers such as 1,000.00. To me it reads as two values: '1' and '000.00' (which is an ugly way of saying 0.0). Why not use 1000.0?

[hasclass]

The Swiss solved this problem many years ago: 1'000.0

[wmeyers]

Yes, it's nitpicking. For me 1,000,000.00 reads much easier than

1000000.00.

[dennisquintel]

I agree with Wouter. Lets use those thousand separators!

[pzac]

Closed with https://github.com/quintel/etengine/commit/fbe056c6c281ba0ee20482525fd10c38ec1726a6