Charts (was: New Graphing Tools)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Charts (was: New Graphing Tools)

Ricardo Moran
Hi guys, I'm trying again with the graphing tools. It's been a while since I worked on this (sorry about that) but I really want to see them integrated.

So now I'm following Bert's suggestions and I'm trying with a less general approach: I'm not introducing a new scale on top of the existing one, instead I just added a "current object" slot on the number lines, and a "current object position in chart" slot that transforms from squeak's pixel to the number line scale and viceversa.

The implementation is much simpler than before but it's more uncomfortable IMHO. I think it would be best to have two "transform" functions accepting a number as argument and returning it transformed from one scale to the other. Unfortunately, it seems Etoys doesn't support this kind of functions nicely, all the examples I could find (such as #color:sees:) seem to be a little hacked and I wasn't sure if following that path was the right way to proceed.

I think the best would be for you to test it and tell me what you think. I'm attaching a project with the new number lines. 
Thanks!

Richo

P.S. I also renamed the project to Charts as Bert suggested

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Charts.001.pr (46K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [squeakland] Charts (was: New Graphing Tools)

Steve Thomas
Nice work.  I like the idea of adding a number line. Some thoughts comments and questions:

If I understand your implementation, you have a horizontal and vertical scale. Then you for each scale you select the "current object" you wish to operate on, to sets its vertical/horizontal position to the "current object position in chart" for each scale.

I think it would be better if you could somehow set the playfield's "scale" based upon the number line(s).   When you add a scale to a the playfield, the objects in that playfield have their X and Y values set to the scales you added.  Then if you "move forward by | N" it moves forward not by N pixels but by the scale settings.

Another possible approach is to have a collection for each "scale". Then all objects in that collection will have their X, Y values set to and use those scale(s).

It would also be nice to have "set of scales" as one object (an X and Y scale) and one collection to make it simpler to add to both in one step.


Stephen
'Invertalways invert' ('man muss immer umkehren')
                                                        - Carl Gustav Jacob Jacobi 

So instead
  1. I would rather be able to set the "scale(s)" for the whole playfield or perhaps set an object to use the number lines scales as opposed to the world's/(playfield it is embedded in) scale.
On Sun, Oct 16, 2011 at 8:16 PM, Ricardo Moran <[hidden email]> wrote:
Hi guys, I'm trying again with the graphing tools. It's been a while since I worked on this (sorry about that) but I really want to see them integrated.

So now I'm following Bert's suggestions and I'm trying with a less general approach: I'm not introducing a new scale on top of the existing one, instead I just added a "current object" slot on the number lines, and a "current object position in chart" slot that transforms from squeak's pixel to the number line scale and viceversa.

The implementation is much simpler than before but it's more uncomfortable IMHO. I think it would be best to have two "transform" functions accepting a number as argument and returning it transformed from one scale to the other. Unfortunately, it seems Etoys doesn't support this kind of functions nicely, all the examples I could find (such as #color:sees:) seem to be a little hacked and I wasn't sure if following that path was the right way to proceed.

I think the best would be for you to test it and tell me what you think. I'm attaching a project with the new number lines. 
Thanks!

Richo

P.S. I also renamed the project to Charts as Bert suggested

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland



_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: [squeakland] Charts (was: New Graphing Tools)

Steve Thomas
In reply to this post by Ricardo Moran
Some other thoughts/questions:
  • Perhaps have an option to show 0 (or not).  This would be useful for when you have two axis that intersect at 0, as it would look better if we didn't show the 0 labels.
  • When I change the Line's min val it changes the max value (and vica versa).  Hmmm, okay I think I'm beginning to understand why you did this.  I was used to setting the min and max value for the axis and having the scale adjust as opposed to the scale setting the max value (well "Invert always invert" ;)  Have to think about this.
  • The labels seem a little too close to the number lines.
  • It would be nice to have tiles to specify the font and size for the labels. (Or course it would be nice to tiles to specify font, size, centered/left flush|right flush|centered, for all text objects :)
  • How can you set the arrow head for the negative direction?
Stephen

On Sun, Oct 16, 2011 at 8:16 PM, Ricardo Moran <[hidden email]> wrote:
Hi guys, I'm trying again with the graphing tools. It's been a while since I worked on this (sorry about that) but I really want to see them integrated.

So now I'm following Bert's suggestions and I'm trying with a less general approach: I'm not introducing a new scale on top of the existing one, instead I just added a "current object" slot on the number lines, and a "current object position in chart" slot that transforms from squeak's pixel to the number line scale and viceversa.

The implementation is much simpler than before but it's more uncomfortable IMHO. I think it would be best to have two "transform" functions accepting a number as argument and returning it transformed from one scale to the other. Unfortunately, it seems Etoys doesn't support this kind of functions nicely, all the examples I could find (such as #color:sees:) seem to be a little hacked and I wasn't sure if following that path was the right way to proceed.

I think the best would be for you to test it and tell me what you think. I'm attaching a project with the new number lines. 
Thanks!

Richo

P.S. I also renamed the project to Charts as Bert suggested

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland



_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: [squeakland] Charts (was: New Graphing Tools)

Ricardo Moran
Hi Steve, thanks for your feedback :)
 
Nice work.  I like the idea of adding a number line. Some thoughts comments and questions:

If I understand your implementation, you have a horizontal and vertical scale. Then you for each scale you select the "current object" you wish to operate on, to sets its vertical/horizontal position to the "current object position in chart" for each scale.

Yes, that is correct.
 

I think it would be better if you could somehow set the playfield's "scale" based upon the number line(s).   When you add a scale to a the playfield, the objects in that playfield have their X and Y values set to the scales you added.  Then if you "move forward by | N" it moves forward not by N pixels but by the scale settings.

Well, that was my initial implementation, but as I recall Bert argued that it was too complicated to add another scale on top of existing scaling. And I have to agree with him, not only because this way is a lot less work :) but because it is also less error prone, my last implementation required patching a lot of important methods.

Also, I think changing the scale of the playfield based on the number line could cause confusion. If we follow that direction what scale would a playfield use if we add two number lines? The opposite is also true: having a different independent scale for the playfield and for the number lines can cause confusion as well (as Randy pointed out). So I think this is the simplest posible implementation: the only responsible of transforming from one scale to another is the number line.
 
 
Another possible approach is to have a collection for each "scale". Then all objects in that collection will have their X, Y values set to and use those scale(s).

It would also be nice to have "set of scales" as one object (an X and Y scale) and one collection to make it simpler to add to both in one step.

I'm sorry, I couldn't follow you... 
  • Perhaps have an option to show 0 (or not).  This would be useful for when you have two axis that intersect at 0, as it would look better if we didn't show the 0 labels.
Yes, that's something I thought too.
 
  • When I change the Line's min val it changes the max value (and vica versa).  Hmmm, okay I think I'm beginning to understand why you did this.  I was used to setting the min and max value for the axis and having the scale adjust as opposed to the scale setting the max value (well "Invert always invert" ;)  Have to think about this.
Mmm... I don't remember why I did it like that. I guess I thought the scale was more important and it should be fixed, but I can change that if you feel it should be the other way around.
  • The labels seem a little too close to the number lines.
True. I'll fix that.
 
  • It would be nice to have tiles to specify the font and size for the labels. (Or course it would be nice to tiles to specify font, size, centered/left flush|right flush|centered, for all text objects :)
Mmm... I could add those tiles to the text objects but I'm not sure of adding them to the number line. Maybe I could add the "collections" category to the number lines and you could iterate over its submorphs changing whatever property you like. In fact, I think that could be added to all objects because all of them can behave like a collection. What do you think?
  • How can you set the arrow head for the negative direction?
Well, you can't :). But that's easy to fix. I don't remember who did but someone told me that the axis with the two arrow heads was confusing because it is supposed to point to the direction of positive infinity, but I always thought the arrows represent the axis going on forever, so I removed the negative arrow head at the time. I don't really know what is the correct meaning of the arrow heads but I could add a preference to turn the negative on/off.

Cheers,
Richo

 
Stephen

On Sun, Oct 16, 2011 at 8:16 PM, Ricardo Moran <[hidden email]> wrote:
Hi guys, I'm trying again with the graphing tools. It's been a while since I worked on this (sorry about that) but I really want to see them integrated.

So now I'm following Bert's suggestions and I'm trying with a less general approach: I'm not introducing a new scale on top of the existing one, instead I just added a "current object" slot on the number lines, and a "current object position in chart" slot that transforms from squeak's pixel to the number line scale and viceversa.

The implementation is much simpler than before but it's more uncomfortable IMHO. I think it would be best to have two "transform" functions accepting a number as argument and returning it transformed from one scale to the other. Unfortunately, it seems Etoys doesn't support this kind of functions nicely, all the examples I could find (such as #color:sees:) seem to be a little hacked and I wasn't sure if following that path was the right way to proceed.

I think the best would be for you to test it and tell me what you think. I'm attaching a project with the new number lines. 
Thanks!

Richo

P.S. I also renamed the project to Charts as Bert suggested

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland




_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: [squeakland] Charts (was: New Graphing Tools)

Steve Thomas
On Mon, Oct 17, 2011 at 9:48 AM, Ricardo Moran <[hidden email]> wrote:
Hi Steve, thanks for your feedback :)
I would think you have learned by now not to encourage me :)
 
Nice work.  I like the idea of adding a number line. Some thoughts comments and questions:

If I understand your implementation, you have a horizontal and vertical scale. Then you for each scale you select the "current object" you wish to operate on, to sets its vertical/horizontal position to the "current object position in chart" for each scale.

Yes, that is correct.
 

I think it would be better if you could somehow set the playfield's "scale" based upon the number line(s).   When you add a scale to a the playfield, the objects in that playfield have their X and Y values set to the scales you added.  Then if you "move forward by | N" it moves forward not by N pixels but by the scale settings.

Well, that was my initial implementation, but as I recall Bert argued that it was too complicated to add another scale on top of existing scaling. And I have to agree with him, not only because this way is a lot less work :) but because it is also less error prone, my last implementation required patching a lot of important methods.
Understood (well at least at the imagining how things are designed/implemented level).  The only concern I have is if you don't do it this way how can you (or can you) have an objects forward by, move based on scale settings instead of pixels?
Hmmmm...  Perhaps (warning requirement overload potential)  You could have a move item in collection forward by tile (read further and hopefully what I am suggesting will become clear, not necessarily the right thing to do, but clear). 

Also, I think changing the scale of the playfield based on the number line could cause confusion. If we follow that direction what scale would a playfield use if we add two number lines? The opposite is also true: having a different independent scale for the playfield and for the number lines can cause confusion as well (as Randy pointed out). So I think this is the simplest posible implementation: the only responsible of transforming from one scale to another is the number line.
 
 
Another possible approach is to have a collection for each "scale". Then all objects in that collection will have their X, Y values set to and use those scale(s).

It would also be nice to have "set of scales" as one object (an X and Y scale) and one collection to make it simpler to add to both in one step.

I'm sorry, I couldn't follow you... 

Let's say you have a scale (or pair of scales).  My thinking is along these lines...
Each scale could have  reference to a collection of "points/things to graph" 
Then when you either:
  • change a scale, or
  • add a "point" to the referenced collection,
you then:
  • For each object in the collection:
  • change the point(s) X,Y to match the scale
The use case I am thinking of is kids plot a bunch of points, then you change the scale, you would want the points to auto-magically adjust to the new scale setting.
  • Perhaps have an option to show 0 (or not).  This would be useful for when you have two axis that intersect at 0, as it would look better if we didn't show the 0 labels.
Yes, that's something I thought too.
 
  • When I change the Line's min val it changes the max value (and vica versa).  Hmmm, okay I think I'm beginning to understand why you did this.  I was used to setting the min and max value for the axis and having the scale adjust as opposed to the scale setting the max value (well "Invert always invert" ;)  Have to think about this.
Mmm... I don't remember why I did it like that. I guess I thought the scale was more important and it should be fixed, but I can change that if you feel it should be the other way around.
  • The labels seem a little too close to the number lines.
True. I'll fix that.
 
  • It would be nice to have tiles to specify the font and size for the labels. (Or course it would be nice to tiles to specify font, size, centered/left flush|right flush|centered, for all text objects :)
Mmm... I could add those tiles to the text objects but I'm not sure of adding them to the number line. Maybe I could add the "collections" category to the number lines and you could iterate over its submorphs changing whatever property you like. In fact, I think that could be added to all objects because all of them can behave like a collection. What do you think?
  • How can you set the arrow head for the negative direction?
Well, you can't :). But that's easy to fix. I don't remember who did but someone told me that the axis with the two arrow heads was confusing because it is supposed to point to the direction of positive infinity, but I always thought the arrows represent the axis going on forever, so I removed the negative arrow head at the time. I don't really know what is the correct meaning of the arrow heads but I could add a preference to turn the negative on/off.
I like the preference, with the default set to negative off.

Cheers,
Richo

 
Stephen

On Sun, Oct 16, 2011 at 8:16 PM, Ricardo Moran <[hidden email]> wrote:
Hi guys, I'm trying again with the graphing tools. It's been a while since I worked on this (sorry about that) but I really want to see them integrated.

So now I'm following Bert's suggestions and I'm trying with a less general approach: I'm not introducing a new scale on top of the existing one, instead I just added a "current object" slot on the number lines, and a "current object position in chart" slot that transforms from squeak's pixel to the number line scale and viceversa.

The implementation is much simpler than before but it's more uncomfortable IMHO. I think it would be best to have two "transform" functions accepting a number as argument and returning it transformed from one scale to the other. Unfortunately, it seems Etoys doesn't support this kind of functions nicely, all the examples I could find (such as #color:sees:) seem to be a little hacked and I wasn't sure if following that path was the right way to proceed.

I think the best would be for you to test it and tell me what you think. I'm attaching a project with the new number lines. 
Thanks!

Richo

P.S. I also renamed the project to Charts as Bert suggested

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland





_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: [squeakland] Charts (was: New Graphing Tools)

Ricardo Moran


On Mon, Oct 17, 2011 at 11:25 AM, Steve Thomas <[hidden email]> wrote:
On Mon, Oct 17, 2011 at 9:48 AM, Ricardo Moran <[hidden email]> wrote:
Hi Steve, thanks for your feedback :)
I would think you have learned by now not to encourage me :)

:)


Understood (well at least at the imagining how things are designed/implemented level).  The only concern I have is if you don't do it this way how can you (or can you) have an objects forward by, move based on scale settings instead of pixels?

Yes, I know what you're saying. Right now you would have to move it by changing it's x and y. I don't really know how you can make "forward" work with this approach, though.

Hmmmm...  Perhaps (warning requirement overload potential)  You could have a move item in collection forward by tile (read further and hopefully what I am suggesting will become clear, not necessarily the right thing to do, but clear). 

At first glance, it doesn't sound right to me, with that tile the viewer might occupy half the screen! :)
 

Let's say you have a scale (or pair of scales).  My thinking is along these lines...
Each scale could have  reference to a collection of "points/things to graph" 
Then when you either:
  • change a scale, or
  • add a "point" to the referenced collection,
you then:
  • For each object in the collection:
  • change the point(s) X,Y to match the scale
The use case I am thinking of is kids plot a bunch of points, then you change the scale, you would want the points to auto-magically adjust to the new scale setting.

Well, then we go back to the first versions of the graphing tools, remember? Where you had a PointGraph containing its own "coordinate system" and a collection of "points". I feel perfectly fine with that approach but IIRC it was decided that these tools were too specific, and all you really need to build a graph is a pair of number lines.

Richo
 
  • Perhaps have an option to show 0 (or not).  This would be useful for when you have two axis that intersect at 0, as it would look better if we didn't show the 0 labels.
Yes, that's something I thought too.
 
  • When I change the Line's min val it changes the max value (and vica versa).  Hmmm, okay I think I'm beginning to understand why you did this.  I was used to setting the min and max value for the axis and having the scale adjust as opposed to the scale setting the max value (well "Invert always invert" ;)  Have to think about this.
Mmm... I don't remember why I did it like that. I guess I thought the scale was more important and it should be fixed, but I can change that if you feel it should be the other way around.
  • The labels seem a little too close to the number lines.
True. I'll fix that.
 
  • It would be nice to have tiles to specify the font and size for the labels. (Or course it would be nice to tiles to specify font, size, centered/left flush|right flush|centered, for all text objects :)
Mmm... I could add those tiles to the text objects but I'm not sure of adding them to the number line. Maybe I could add the "collections" category to the number lines and you could iterate over its submorphs changing whatever property you like. In fact, I think that could be added to all objects because all of them can behave like a collection. What do you think?
  • How can you set the arrow head for the negative direction?
Well, you can't :). But that's easy to fix. I don't remember who did but someone told me that the axis with the two arrow heads was confusing because it is supposed to point to the direction of positive infinity, but I always thought the arrows represent the axis going on forever, so I removed the negative arrow head at the time. I don't really know what is the correct meaning of the arrow heads but I could add a preference to turn the negative on/off.
I like the preference, with the default set to negative off.

Cheers,
Richo

 
Stephen

On Sun, Oct 16, 2011 at 8:16 PM, Ricardo Moran <[hidden email]> wrote:
Hi guys, I'm trying again with the graphing tools. It's been a while since I worked on this (sorry about that) but I really want to see them integrated.

So now I'm following Bert's suggestions and I'm trying with a less general approach: I'm not introducing a new scale on top of the existing one, instead I just added a "current object" slot on the number lines, and a "current object position in chart" slot that transforms from squeak's pixel to the number line scale and viceversa.

The implementation is much simpler than before but it's more uncomfortable IMHO. I think it would be best to have two "transform" functions accepting a number as argument and returning it transformed from one scale to the other. Unfortunately, it seems Etoys doesn't support this kind of functions nicely, all the examples I could find (such as #color:sees:) seem to be a little hacked and I wasn't sure if following that path was the right way to proceed.

I think the best would be for you to test it and tell me what you think. I'm attaching a project with the new number lines. 
Thanks!

Richo

P.S. I also renamed the project to Charts as Bert suggested

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland






_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: [squeakland] Charts (was: New Graphing Tools)

Ricardo Moran
In reply to this post by Steve Thomas

On Mon, Oct 17, 2011 at 11:25 AM, Steve Thomas <[hidden email]> wrote:
  • How can you set the arrow head for the negative direction?
Well, you can't :). But that's easy to fix. I don't remember who did but someone told me that the axis with the two arrow heads was confusing because it is supposed to point to the direction of positive infinity, but I always thought the arrows represent the axis going on forever, so I removed the negative arrow head at the time. I don't really know what is the correct meaning of the arrow heads but I could add a preference to turn the negative on/off.
I like the preference, with the default set to negative off.

Actually, I just realized you don't need the preference. You can just open the menu of the arrow (by clicking twice on the number line) and there you'll find the option "<->" and other ways to customize your arrow :)

It's quite hidden so if you prefer I'll make the preference anyway.
 
Cheers,
Richo


Cheers,
Richo

 
Stephen

On Sun, Oct 16, 2011 at 8:16 PM, Ricardo Moran <[hidden email]> wrote:
Hi guys, I'm trying again with the graphing tools. It's been a while since I worked on this (sorry about that) but I really want to see them integrated.

So now I'm following Bert's suggestions and I'm trying with a less general approach: I'm not introducing a new scale on top of the existing one, instead I just added a "current object" slot on the number lines, and a "current object position in chart" slot that transforms from squeak's pixel to the number line scale and viceversa.

The implementation is much simpler than before but it's more uncomfortable IMHO. I think it would be best to have two "transform" functions accepting a number as argument and returning it transformed from one scale to the other. Unfortunately, it seems Etoys doesn't support this kind of functions nicely, all the examples I could find (such as #color:sees:) seem to be a little hacked and I wasn't sure if following that path was the right way to proceed.

I think the best would be for you to test it and tell me what you think. I'm attaching a project with the new number lines. 
Thanks!

Richo

P.S. I also renamed the project to Charts as Bert suggested

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland






_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev