Hi,
I discovered a significant problem in RTMetricNormalizer>>normalizeWidth:min:max:using:.
The method is used in the Charter package and it produces an unwanted normalization. I fixed it for this case (see the comment below), but I think we should take the time to review the whole class.
Name: Roassal2-TudorGirba.476 Author: TudorGirba Time: 19 September 2014, 12:14:30.030534 pm UUID: 097886cf-6898-d541-a4a7-21431cfecd67 Ancestors: Roassal2-TudorGirba.475
Patched normalizeWidth. This is used in the Charter package.
The old implementation was like this: tt := min + ((max - min) * ( (t - minValue) / (maxValue - minValue))) asInteger.
The problem with this is that the normalization will return for the lowest value, the specified min value. So, if we had two numbers 10 and 5 to be normalized between 0 and 100, we would get: - 10 => 100 - 5 => 0
This rule works for colors, but for numbers, we want that 5 to be 50.
So, the current implementation looks like: tt := t * (max-min) / maxValue.
Cheers, Doru
Hi Doru,
I still believe that the original implementation of normalizeWidth:min:max:using does its job well. Here is an example of the original implementation:
The width of each element ranges from 5 to 30 pixels. As expected from the script.
With your new implementation, we have:
Width can be less than 5 pixels, which is not what one would expect.
So, if we had two numbers 10 and 5 to be normalized between 0 and 100, we would get:
- 10 => 100
- 5 => 0
This rule works for colors, but for numbers, we want that 5 to be 50.
Actually no, I think that 5 and should be 0, and not 50 since 5 is the minimum value of { 10 . 5 } Maybe we could add #normalizeWidth:minWidth:maxWidth:minValue:using: ? This method would then fit your need. Does it make sense? This is an essential piece of Roassal2, and it has to be well done and flexible.
Cheers, Alexandre
On Sep 19, 2014, at 3:20 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I discovered a significant problem in RTMetricNormalizer>>normalizeWidth:min:max:using:.
The method is used in the Charter package and it produces an unwanted normalization. I fixed it for this case (see the comment below), but I think we should take the time to review the whole class.
Name: Roassal2-TudorGirba.476 Author: TudorGirba Time: 19 September 2014, 12:14:30.030534 pm UUID: 097886cf-6898-d541-a4a7-21431cfecd67 Ancestors: Roassal2-TudorGirba.475
Patched normalizeWidth. This is used in the Charter package.
The old implementation was like this: tt := min + ((max - min) * ( (t - minValue) / (maxValue - minValue))) asInteger.
The problem with this is that the normalization will return for the lowest value, the specified min value. So, if we had two numbers 10 and 5 to be normalized between 0 and 100, we would get:
- 10 => 100
- 5 => 0
This rule works for colors, but for numbers, we want that 5 to be 50.
So, the current implementation looks like: tt := t * (max-min) / maxValue.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Alex,
I agree that it is an essential piece, but the way it was used in the context of Charter was wrong.
Consider this chart:
b := RTDoubleBarBuilder new. b points: #(#(1 5) #(2 10)). b bottomValue: #first. b topValue: #second. b open
The original implementation normalizes in the sense of mapping the minimum value to the minimum allowed size and the maximum value to the maximum allowed size. The result is this:
[image: Inline image 1]
This is not even meeting the expectation of the axis.
The new implementation raises:
[image: Inline image 2]
As I said, in the context of the Charter, the minimum is absolute (basically, 0 should be used at all times), not relative to the input set.
And then, we also have to decouple the normalization algorithm from the aspect that it affects. For example, now we have significant duplication between the width and the height computation. The algorithm is the same, but the application of differs. This should be modeled with composable objects (normalization and application).
Cheers, Doru
On Fri, Sep 19, 2014 at 4:42 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Doru,
I still believe that the original implementation of normalizeWidth:min:max:using does its job well. Here is an example of the original implementation:
The width of each element ranges from 5 to 30 pixels. As expected from the script.
With your new implementation, we have:
Width can be less than 5 pixels, which is not what one would expect.
So, if we had two numbers 10 and 5 to be normalized between 0 and 100, we would get:
- 10 => 100
- 5 => 0
This rule works for colors, but for numbers, we want that 5 to be 50.
Actually no, I think that 5 and should be 0, and not 50 since 5 is the minimum value of { 10 . 5 } Maybe we could add #normalizeWidth:minWidth:maxWidth:minValue:using: ? This method would then fit your need. Does it make sense? This is an essential piece of Roassal2, and it has to be well done and flexible.
Cheers, Alexandre
On Sep 19, 2014, at 3:20 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I discovered a significant problem in RTMetricNormalizer>>normalizeWidth:min:max:using:.
The method is used in the Charter package and it produces an unwanted normalization. I fixed it for this case (see the comment below), but I think we should take the time to review the whole class.
Name: Roassal2-TudorGirba.476 Author: TudorGirba Time: 19 September 2014, 12:14:30.030534 pm UUID: 097886cf-6898-d541-a4a7-21431cfecd67 Ancestors: Roassal2-TudorGirba.475
Patched normalizeWidth. This is used in the Charter package.
The old implementation was like this: tt := min + ((max - min) * ( (t - minValue) / (maxValue - minValue))) asInteger.
The problem with this is that the normalization will return for the lowest value, the specified min value. So, if we had two numbers 10 and 5 to be normalized between 0 and 100, we would get:
- 10 => 100
- 5 => 0
This rule works for colors, but for numbers, we want that 5 to be 50.
So, the current implementation looks like: tt := t * (max-min) / maxValue.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Doru,
I perfectly understand your point. However, I still think we should not force to comprise the 0 value when normalizing x, y, size, height, width. There are some situations where it makes sense to do so, and some other where it is restrictive. For example, if Charter would enforce to have the 0 value when normalizing, then the intersection of the axes will always have to be the 0 @ 0 point, which may not be always the case (Charter is not able to produce such a graph now, but it will be). We can always imagine the axis to be centered on a different value as Excels, Number and R easily allow.
I have improved the RTMetricNormalizer. And factored out the common part. That was indeed necessary.
In the RTDoubleBarBuilder>>metric: aBlock color: aColor height: anHeight I have inserted the following: ... RTMetricNormalizer new elements: boxes; normalizeWidth: aBlock min: 2 max: width minValue: 0. …
This solves the problems without restricting anything or anyone :-)
I have produced Roassal2-AlexandreBergel.478
Cheers, Alexandre
On Sep 19, 2014, at 2:54 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Alex,
I agree that it is an essential piece, but the way it was used in the context of Charter was wrong.
Consider this chart:
b := RTDoubleBarBuilder new. b points: #(#(1 5) #(2 10)). b bottomValue: #first. b topValue: #second. b open
The original implementation normalizes in the sense of mapping the minimum value to the minimum allowed size and the maximum value to the maximum allowed size. The result is this:
<Old.png>
This is not even meeting the expectation of the axis.
The new implementation raises:
<New.png>
As I said, in the context of the Charter, the minimum is absolute (basically, 0 should be used at all times), not relative to the input set.
And then, we also have to decouple the normalization algorithm from the aspect that it affects. For example, now we have significant duplication between the width and the height computation. The algorithm is the same, but the application of differs. This should be modeled with composable objects (normalization and application).
Cheers, Doru
On Fri, Sep 19, 2014 at 4:42 PM, Alexandre Bergel alexandre.bergel@me.com wrote: Hi Doru,
I still believe that the original implementation of normalizeWidth:min:max:using does its job well. Here is an example of the original implementation: <Screen Shot 2014-09-19 at 7.36.54 AM.png>
The width of each element ranges from 5 to 30 pixels. As expected from the script.
With your new implementation, we have: <Screen Shot 2014-09-19 at 7.37.51 AM.png>
Width can be less than 5 pixels, which is not what one would expect.
So, if we had two numbers 10 and 5 to be normalized between 0 and 100, we would get:
- 10 => 100
- 5 => 0
This rule works for colors, but for numbers, we want that 5 to be 50.
Actually no, I think that 5 and should be 0, and not 50 since 5 is the minimum value of { 10 . 5 } Maybe we could add #normalizeWidth:minWidth:maxWidth:minValue:using: ? This method would then fit your need. Does it make sense? This is an essential piece of Roassal2, and it has to be well done and flexible.
Cheers, Alexandre
On Sep 19, 2014, at 3:20 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I discovered a significant problem in RTMetricNormalizer>>normalizeWidth:min:max:using:.
The method is used in the Charter package and it produces an unwanted normalization. I fixed it for this case (see the comment below), but I think we should take the time to review the whole class.
Name: Roassal2-TudorGirba.476 Author: TudorGirba Time: 19 September 2014, 12:14:30.030534 pm UUID: 097886cf-6898-d541-a4a7-21431cfecd67 Ancestors: Roassal2-TudorGirba.475
Patched normalizeWidth. This is used in the Charter package.
The old implementation was like this: tt := min + ((max - min) * ( (t - minValue) / (maxValue - minValue))) asInteger.
The problem with this is that the normalization will return for the lowest value, the specified min value. So, if we had two numbers 10 and 5 to be normalized between 0 and 100, we would get:
- 10 => 100
- 5 => 0
This rule works for colors, but for numbers, we want that 5 to be 50.
So, the current implementation looks like: tt := t * (max-min) / maxValue.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Alex,
Fair enough.
The only point is that Charter should always provide 0@0 as default. Not having 0@0 as the origin in charts typically leads to wrong interpretations (see Tufte and Stephen Few). We should make it easy for people to produce nice and correct graphs and difficult to do otherwise.
Cheers, Tudor
On Sat, Sep 20, 2014 at 10:40 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi Doru,
I perfectly understand your point. However, I still think we should not force to comprise the 0 value when normalizing x, y, size, height, width. There are some situations where it makes sense to do so, and some other where it is restrictive. For example, if Charter would enforce to have the 0 value when normalizing, then the intersection of the axes will always have to be the 0 @ 0 point, which may not be always the case (Charter is not able to produce such a graph now, but it will be). We can always imagine the axis to be centered on a different value as Excels, Number and R easily allow.
I have improved the RTMetricNormalizer. And factored out the common part. That was indeed necessary.
In the RTDoubleBarBuilder>>metric: aBlock color: aColor height: anHeight I have inserted the following: ... RTMetricNormalizer new elements: boxes; normalizeWidth: aBlock min: 2 max: width minValue: 0. …
This solves the problems without restricting anything or anyone :-)
I have produced Roassal2-AlexandreBergel.478
Cheers, Alexandre
On Sep 19, 2014, at 2:54 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Alex,
I agree that it is an essential piece, but the way it was used in the
context of Charter was wrong.
Consider this chart:
b := RTDoubleBarBuilder new. b points: #(#(1 5) #(2 10)). b bottomValue: #first. b topValue: #second. b open
The original implementation normalizes in the sense of mapping the
minimum value to the minimum allowed size and the maximum value to the maximum allowed size. The result is this:
<Old.png>
This is not even meeting the expectation of the axis.
The new implementation raises:
<New.png>
As I said, in the context of the Charter, the minimum is absolute
(basically, 0 should be used at all times), not relative to the input set.
And then, we also have to decouple the normalization algorithm from the
aspect that it affects. For example, now we have significant duplication between the width and the height computation. The algorithm is the same, but the application of differs. This should be modeled with composable objects (normalization and application).
Cheers, Doru
On Fri, Sep 19, 2014 at 4:42 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Hi Doru,
I still believe that the original implementation of
normalizeWidth:min:max:using does its job well.
Here is an example of the original implementation: <Screen Shot 2014-09-19 at 7.36.54 AM.png>
The width of each element ranges from 5 to 30 pixels. As expected from
the script.
With your new implementation, we have: <Screen Shot 2014-09-19 at 7.37.51 AM.png>
Width can be less than 5 pixels, which is not what one would expect.
So, if we had two numbers 10 and 5 to be normalized between 0 and 100,
we would get:
- 10 => 100
- 5 => 0
This rule works for colors, but for numbers, we want that 5 to be 50.
Actually no, I think that 5 and should be 0, and not 50 since 5 is the
minimum value of { 10 . 5 }
Maybe we could add #normalizeWidth:minWidth:maxWidth:minValue:using: ?
This method would then fit your need. Does it make sense?
This is an essential piece of Roassal2, and it has to be well done and
flexible.
Cheers, Alexandre
On Sep 19, 2014, at 3:20 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I discovered a significant problem in
RTMetricNormalizer>>normalizeWidth:min:max:using:.
The method is used in the Charter package and it produces an unwanted
normalization. I fixed it for this case (see the comment below), but I think we should take the time to review the whole class.
Name: Roassal2-TudorGirba.476 Author: TudorGirba Time: 19 September 2014, 12:14:30.030534 pm UUID: 097886cf-6898-d541-a4a7-21431cfecd67 Ancestors: Roassal2-TudorGirba.475
Patched normalizeWidth. This is used in the Charter package.
The old implementation was like this: tt := min + ((max - min) * ( (t - minValue) / (maxValue - minValue)))
asInteger.
The problem with this is that the normalization will return for the
lowest value, the specified min value.
So, if we had two numbers 10 and 5 to be normalized between 0 and 100,
we would get:
- 10 => 100
- 5 => 0
This rule works for colors, but for numbers, we want that 5 to be 50.
So, the current implementation looks like: tt := t * (max-min) / maxValue.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Tudor Girba