Plotting time
Locked
 
|
Hi guys,
you will probably hate me after today, but I have one more question. I’m trying to plot some data that is related to time. By default GraphET (and Roassal) do not support Date as value. Of course I can convert timestamp to seconds from epoch but maybe it would be cool to be able to use just Timestamp. For me it seems that evolution of some metric in time should be quite common. Does anybody have intention to implement something like this? Uko _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Uko,
GraphET and Roassal indeed do not support date. Let us know how we can help. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Dec 10, 2013, at 11:19 AM, Yuriy Tymchuk <[hidden email]> wrote: > Hi guys, > > you will probably hate me after today, but I have one more question. > > I’m trying to plot some data that is related to time. By default GraphET (and Roassal) do not support Date as value. Of course I can convert timestamp to seconds from epoch but maybe it would be cool to be able to use just Timestamp. For me it seems that evolution of some metric in time should be quite common. > > Does anybody have intention to implement something like this? > > Uko > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Ok, I’ve made some progress in this direction. For now on I’ve spotted 3 bottlenecks of plotting non-number values.
1) setMaxAndMinXValues self maxXValue: (self xValues max max: 0). self minXValue: (self xValues min min: 0) max: 0 and min: 0 are ruining things a bit. It will be nice to rethink this part. I’m not sure that it’s a good idea to have 0 all the time. Eg. I’d like to plot something in range 10100..10200 and as the result my data will take a very small place. Removing max: 0 and min: 0 solves the problem but they were put there for some reason. 2) getPixelsFromXValue: value ^ value * (self width) / (self maxXValue - self minXValue) We get problem when multiplying Date (value) by number. We can rewrite line in this way ^ (value - self minXValue) * (self width) / (self maxXValue - self minXValue) + minValue this way we operate with durations, which makes more sense. 3) sizeInPixelsOfPositiveXArea: maxSize "return the bar size (width or height) for the corresponding maxSize" (self minValue > 0 and: [ self maxValue > 0 ]) ifTrue: [ ^ maxSize ]. (self minValue <= 0 and: [ self maxValue > 0 ]) ifTrue: [ ^ maxSize * self maxXValue / (self maxXValue + (self minXValue abs)) ]. (self minValue <= 0 and: [ self maxValue <= 0 ]) ifTrue: [ ^ 0 ]. ^ self error: 'should not be here’ I have no idea what this does :). To make things work I just removed everything and made this thing return maxSize… So I’d really appreciate some kind of explanation. It will be good to push this into a working state. Cheers. Uko On 10 Dec 2013, at 18:15, Alexandre Bergel <[hidden email]> wrote: > Hi Uko, > > GraphET and Roassal indeed do not support date. > Let us know how we can help. > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Dec 10, 2013, at 11:19 AM, Yuriy Tymchuk <[hidden email]> wrote: > >> Hi guys, >> >> you will probably hate me after today, but I have one more question. >> >> I’m trying to plot some data that is related to time. By default GraphET (and Roassal) do not support Date as value. Of course I can convert timestamp to seconds from epoch but maybe it would be cool to be able to use just Timestamp. For me it seems that evolution of some metric in time should be quite common. >> >> Does anybody have intention to implement something like this? >> >> Uko >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Yuriy Tymchuk wrote:
> Ok, I’ve made some progress in this direction. For now on I’ve spotted 3 bottlenecks of plotting non-number values. > > 1) setMaxAndMinXValues > > self maxXValue: (self xValues max max: 0). > self minXValue: (self xValues min min: 0) > > max: 0 and min: 0 are ruining things a bit. It will be nice to rethink this part. I’m not sure that it’s a good idea to have 0 all the time. Eg. I’d like to plot something in range 10100..10200 and as the result my data will take a very small place. Removing max: 0 and min: 0 solves the problem but they were put there for some reason. > > Automatic range setting based on the data should be default, so perhaps the following should be considered, so that if a user previously manually force a #maxXValue: that remains set, but otherwise it defaults to range of data. setMaxAndMinXValues self maxXValue ifNil: [ self maxXValue: self xValues max ] self minXValue ifNil: [ self minXValue: self xValues min ] (I am missing some context so probably my comment doesn't properly align with your case. Just sharing my thoughts as they come.) cheers -ben _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
I like your idea, but also we should listen to creators also :)
Uko On 12 Dec 2013, at 14:37, Ben Coman <[hidden email]> wrote: > Yuriy Tymchuk wrote: >> Ok, I’ve made some progress in this direction. For now on I’ve spotted 3 bottlenecks of plotting non-number values. >> >> 1) setMaxAndMinXValues >> >> self maxXValue: (self xValues max max: 0). >> self minXValue: (self xValues min min: 0) >> >> max: 0 and min: 0 are ruining things a bit. It will be nice to rethink this part. I’m not sure that it’s a good idea to have 0 all the time. Eg. I’d like to plot something in range 10100..10200 and as the result my data will take a very small place. Removing max: 0 and min: 0 solves the problem but they were put there for some reason. >> >> > > Automatic range setting based on the data should be default, so perhaps the following should be considered, so that if a user previously manually force a #maxXValue: that remains set, but otherwise it defaults to range of data. > > setMaxAndMinXValues > > self maxXValue ifNil: [ self maxXValue: self xValues max ] > self minXValue ifNil: [ self minXValue: self xValues min ] > > > (I am missing some context so probably my comment doesn't properly align with your case. Just sharing my thoughts as they come.) > > cheers -ben > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Oh wow. It works without changes in GETOrdinaryLineDiagram. As I’ve already told, I have no idea what this classes are meant to represent because they are not commented but GETOrdinaryLineDiagram can plot Date valued data by default.
Uko On 12 Dec 2013, at 14:45, Yuriy Tymchuk <[hidden email]> wrote: > I like your idea, but also we should listen to creators also :) > > Uko > > On 12 Dec 2013, at 14:37, Ben Coman <[hidden email]> wrote: > >> Yuriy Tymchuk wrote: >>> Ok, I’ve made some progress in this direction. For now on I’ve spotted 3 bottlenecks of plotting non-number values. >>> >>> 1) setMaxAndMinXValues >>> >>> self maxXValue: (self xValues max max: 0). >>> self minXValue: (self xValues min min: 0) >>> >>> max: 0 and min: 0 are ruining things a bit. It will be nice to rethink this part. I’m not sure that it’s a good idea to have 0 all the time. Eg. I’d like to plot something in range 10100..10200 and as the result my data will take a very small place. Removing max: 0 and min: 0 solves the problem but they were put there for some reason. >>> >>> >> >> Automatic range setting based on the data should be default, so perhaps the following should be considered, so that if a user previously manually force a #maxXValue: that remains set, but otherwise it defaults to range of data. >> >> setMaxAndMinXValues >> >> self maxXValue ifNil: [ self maxXValue: self xValues max ] >> self minXValue ifNil: [ self minXValue: self xValues min ] >> >> >> (I am missing some context so probably my comment doesn't properly align with your case. Just sharing my thoughts as they come.) >> >> cheers -ben >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Uko2
I will have a look at it ASAP. I am now on my way to Lille...
Alexandre > Le 12-12-2013 à 10:22, Yuriy Tymchuk <[hidden email]> a écrit : > > Ok, I’ve made some progress in this direction. For now on I’ve spotted 3 bottlenecks of plotting non-number values. > > 1) setMaxAndMinXValues > > self maxXValue: (self xValues max max: 0). > self minXValue: (self xValues min min: 0) > > max: 0 and min: 0 are ruining things a bit. It will be nice to rethink this part. I’m not sure that it’s a good idea to have 0 all the time. Eg. I’d like to plot something in range 10100..10200 and as the result my data will take a very small place. Removing max: 0 and min: 0 solves the problem but they were put there for some reason. > > 2) getPixelsFromXValue: value > > ^ value * (self width) / (self maxXValue - self minXValue) > > We get problem when multiplying Date (value) by number. We can rewrite line in this way > > ^ (value - self minXValue) * (self width) / (self maxXValue - self minXValue) + minValue > > this way we operate with durations, which makes more sense. > > 3) sizeInPixelsOfPositiveXArea: maxSize > "return the bar size (width or height) for the corresponding maxSize" > > (self minValue > 0 and: [ self maxValue > 0 ]) ifTrue: [ ^ maxSize ]. > (self minValue <= 0 and: [ self maxValue > 0 ]) ifTrue: [ ^ maxSize * self maxXValue / (self maxXValue + (self minXValue abs)) ]. > (self minValue <= 0 and: [ self maxValue <= 0 ]) ifTrue: [ ^ 0 ]. > > ^ self error: 'should not be here’ > > I have no idea what this does :). To make things work I just removed everything and made this thing return maxSize… So I’d really appreciate some kind of explanation. It will be good to push this into a working state. > > Cheers. > Uko > > > >> On 10 Dec 2013, at 18:15, Alexandre Bergel <[hidden email]> wrote: >> >> Hi Uko, >> >> GraphET and Roassal indeed do not support date. >> Let us know how we can help. >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On Dec 10, 2013, at 11:19 AM, Yuriy Tymchuk <[hidden email]> wrote: >>> >>> Hi guys, >>> >>> you will probably hate me after today, but I have one more question. >>> >>> I’m trying to plot some data that is related to time. By default GraphET (and Roassal) do not support Date as value. Of course I can convert timestamp to seconds from epoch but maybe it would be cool to be able to use just Timestamp. For me it seems that evolution of some metric in time should be quite common. >>> >>> Does anybody have intention to implement something like this? >>> >>> Uko >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Thanks Alex,
see you in a few days! Uko On 12 Dec 2013, at 20:16, Alexandre Bergel <[hidden email]> wrote: > I will have a look at it ASAP. I am now on my way to Lille... > > Alexandre > >> Le 12-12-2013 à 10:22, Yuriy Tymchuk <[hidden email]> a écrit : >> >> Ok, I’ve made some progress in this direction. For now on I’ve spotted 3 bottlenecks of plotting non-number values. >> >> 1) setMaxAndMinXValues >> >> self maxXValue: (self xValues max max: 0). >> self minXValue: (self xValues min min: 0) >> >> max: 0 and min: 0 are ruining things a bit. It will be nice to rethink this part. I’m not sure that it’s a good idea to have 0 all the time. Eg. I’d like to plot something in range 10100..10200 and as the result my data will take a very small place. Removing max: 0 and min: 0 solves the problem but they were put there for some reason. >> >> 2) getPixelsFromXValue: value >> >> ^ value * (self width) / (self maxXValue - self minXValue) >> >> We get problem when multiplying Date (value) by number. We can rewrite line in this way >> >> ^ (value - self minXValue) * (self width) / (self maxXValue - self minXValue) + minValue >> >> this way we operate with durations, which makes more sense. >> >> 3) sizeInPixelsOfPositiveXArea: maxSize >> "return the bar size (width or height) for the corresponding maxSize" >> >> (self minValue > 0 and: [ self maxValue > 0 ]) ifTrue: [ ^ maxSize ]. >> (self minValue <= 0 and: [ self maxValue > 0 ]) ifTrue: [ ^ maxSize * self maxXValue / (self maxXValue + (self minXValue abs)) ]. >> (self minValue <= 0 and: [ self maxValue <= 0 ]) ifTrue: [ ^ 0 ]. >> >> ^ self error: 'should not be here’ >> >> I have no idea what this does :). To make things work I just removed everything and made this thing return maxSize… So I’d really appreciate some kind of explanation. It will be good to push this into a working state. >> >> Cheers. >> Uko >> >> >> >>> On 10 Dec 2013, at 18:15, Alexandre Bergel <[hidden email]> wrote: >>> >>> Hi Uko, >>> >>> GraphET and Roassal indeed do not support date. >>> Let us know how we can help. >>> >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>>> On Dec 10, 2013, at 11:19 AM, Yuriy Tymchuk <[hidden email]> wrote: >>>> >>>> Hi guys, >>>> >>>> you will probably hate me after today, but I have one more question. >>>> >>>> I’m trying to plot some data that is related to time. By default GraphET (and Roassal) do not support Date as value. Of course I can convert timestamp to seconds from epoch but maybe it would be cool to be able to use just Timestamp. For me it seems that evolution of some metric in time should be quite common. >>>> >>>> Does anybody have intention to implement something like this? >>>> >>>> Uko >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi guys! I just finished most of my exams today, I'll take a look at it in a few couple of days.
Daniel > From: [hidden email] > Date: Thu, 12 Dec 2013 20:38:46 +0100 > To: [hidden email] > Subject: [Moose-dev] Re: Plotting time > > Thanks Alex, > > see you in a few days! > > Uko > > On 12 Dec 2013, at 20:16, Alexandre Bergel <[hidden email]> wrote: > > > I will have a look at it ASAP. I am now on my way to Lille... > > > > Alexandre > > > >> Le 12-12-2013 à 10:22, Yuriy Tymchuk <[hidden email]> a écrit : > >> > >> Ok, I’ve made some progress in this direction. For now on I’ve spotted 3 bottlenecks of plotting non-number values. > >> > >> 1) setMaxAndMinXValues > >> > >> self maxXValue: (self xValues max max: 0). > >> self minXValue: (self xValues min min: 0) > >> > >> max: 0 and min: 0 are ruining things a bit. It will be nice to rethink this part. I’m not sure that it’s a good idea to have 0 all the time. Eg. I’d like to plot something in range 10100..10200 and as the result my data will take a very small place. Removing max: 0 and min: 0 solves the problem but they were put there for some reason. > >> > >> 2) getPixelsFromXValue: value > >> > >> ^ value * (self width) / (self maxXValue - self minXValue) > >> > >> We get problem when multiplying Date (value) by number. We can rewrite line in this way > >> > >> ^ (value - self minXValue) * (self width) / (self maxXValue - self minXValue) + minValue > >> > >> this way we operate with durations, which makes more sense. > >> > >> 3) sizeInPixelsOfPositiveXArea: maxSize > >> "return the bar size (width or height) for the corresponding maxSize" > >> > >> (self minValue > 0 and: [ self maxValue > 0 ]) ifTrue: [ ^ maxSize ]. > >> (self minValue <= 0 and: [ self maxValue > 0 ]) ifTrue: [ ^ maxSize * self maxXValue / (self maxXValue + (self minXValue abs)) ]. > >> (self minValue <= 0 and: [ self maxValue <= 0 ]) ifTrue: [ ^ 0 ]. > >> > >> ^ self error: 'should not be here’ > >> > >> I have no idea what this does :). To make things work I just removed everything and made this thing return maxSize… So I’d really appreciate some kind of explanation. It will be good to push this into a working state. > >> > >> Cheers. > >> Uko > >> > >> > >> > >>> On 10 Dec 2013, at 18:15, Alexandre Bergel <[hidden email]> wrote: > >>> > >>> Hi Uko, > >>> > >>> GraphET and Roassal indeed do not support date. > >>> Let us know how we can help. > >>> > >>> Alexandre > >>> -- > >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>> Alexandre Bergel http://www.bergel.eu > >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>> > >>> > >>> > >>>> On Dec 10, 2013, at 11:19 AM, Yuriy Tymchuk <[hidden email]> wrote: > >>>> > >>>> Hi guys, > >>>> > >>>> you will probably hate me after today, but I have one more question. > >>>> > >>>> I’m trying to plot some data that is related to time. By default GraphET (and Roassal) do not support Date as value. Of course I can convert timestamp to seconds from epoch but maybe it would be cool to be able to use just Timestamp. For me it seems that evolution of some metric in time should be quite common. > >>>> > >>>> Does anybody have intention to implement something like this? > >>>> > >>>> Uko > >>>> _______________________________________________ > >>>> Moose-dev mailing list > >>>> [hidden email] > >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>> > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> [hidden email] > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Cool. I’m looking forward for your answers.
Uko On 12 Dec 2013, at 22:35, Daniel Aviv Notario <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |