MathMorphs: An Environment for Learning and Doing Math
MathMorphs: An Environment for Learning and Doing Math, by Luciano
Notarfrancesco and Leandro Caniglia of UBA.
Current draft: mathmorphs.pdf
Promised Reviewers:
Danny Sharpe (dts)
Bruce O'Neel (beoneel@mindspring.com)
Answers to Danny's comments 2000/3/14
[dts] Shouldn't the authors' e-mail addresses be given on the first page?
[LC] Done
[dts] Many of the illustrations appear to have had rows and columns of pixels removed during resizing. This makes some of them hard to interpret since the text they contain has gotten mangled.
[LC] They look well in the original (Word). May be the problem is introduced when converting to PDF (?)
[dts] In the MorphicWrappers section on page 2, please tell where the user can get MorphicWrappers. Also, for the benefit of those who aren't intimately familiar with the Squeak and Morphic environments, please tell how to install it and start playing with it.
[LC] Done
[dts] At the top of page 4, it mentions "when the morph is in focus". Please tell what events cause a morph to come into focus and how it advertises the fact that it is in focus.
[LC] Done
[dts] Design question: Not all morphs behave the same when in focus. Mathy ones created by typing on air turn color and pop up a balloon saying "I am a Point" or some such, but others created from the "New morph" menu option don't seem to give any visual indication. Was this a design decision? If so, I don't understand the rationale.
[LC] This is a must since we cannot alter the way that normal morphs (those created from "New morph") behave. From the MathMorphs perspective, there are two kind of morphs: (1) normal morphs, and (2) MorphicWrappers. MorphicWrappers dress ordinary objects with Morphc behavior and appearance. Visual indications such as balloons or color changes are part of the suit. Normal morphs are as they are, we cannot change them.
[dts] On page 4, in the Typing History section, it says "There is one expression history for each class of wrapped objects." But, among other things, I managed to get an Ellipse to give me the expression history for some Points I had created earlier. Objects of different classes appear to give me different sections of a global expression history, and the same morph doesn't always give the same history. I don't understand.
[LC] Well, this seems to be a bug report. Thank you! I'll check it out. (Note also that the package is in continuous evolution)
[dts] On page 6, in the Identity section, it suddenly starts talking about CarryingMorph and ShakingMorph. I don't understand what these have to do with Identity. Perhaps an omitted section header?
[LC] Section header and an introductory paragraph added.
[dts] Also, wouldn't this discussion go over better a bit later on, after you've discussed redefining methods? That way, you could give an example of some of the neat things that can be accomplished by redefining the methods of those classes.
[LC] We haven't provided programming examples for the sake of brevity. The chapter tries to expose the main ideas focussing on the consequences more than in the implementation details. As everybody says: "this goes beyond the scope blah, blah..." ;-). Anyway, let me know any suggestion about that.
[dts] Page 6, RequestBoxes section, last sentence: insert the word "by" after "RequestBox". It should read, "... to a RequestBox by typing on air..."
[LC] Done
[dts] But I'm not sure why RequestBoxes are being discussed here. For newbies, this discusson is like the one of CarryingMorph - it brings up the desire to experiment but experimentation requires knowledge that is not obtained until later.
[LC] I've changed those two sections trying to elaborate a bit more. Please, let me know what you think now.
[dts] Page 6, Programming with the MorphicWrappers, section header: Delete the word "the". It should read, "Programming with MorphicWrappers". Same section, first sentence: Change the word "were" to "where". It should read, "... is a framework where more...".
[LC] Done
[dts] Some cosmetics comments -
The practice of emphasizing terms such as MorphicWrapper, CodeBalloon, etc., every time they're used is distracting. I would like to see them emphasized when they are defined, and written normally everywhere else.
The illustrations are pushed all the way to the left page margin. Shouldn't they line up with the text margin, which is one inch in, or even be centered between the text margins if they're not too wide?
The captions for the illustrations stand out a little too well. It took me a couple of double-takes to figure out that they were captions and not section headers. I would like them not to stand out so much, and be more closely associated with their illustrations.
[LC] I'll try to do my best. But, as far as I understand, all these "characteristics" were explicit formatting rules from Mark and Kim (Am I right?)
[dts] Also, some of the captions are wider than the illustrations they go with; in that case, they should be folded.
[LC] It is my fault. I'll fix them.
[dts] It might be a good idea to number the illustrations.
[LC] I'll take this suggestion in consideration. Let me see.
[dts] And that takes us through page 6. More later.
[LC] Many thanks. Your notes are very clear and useful.
Comments:
dts 2000/03/07:
(Note: Since I'm learning MathMorphs while reviewing the chapter, I'm evaluating the chapter from the point of view of a newbie working through a tutorial.)
General impression: It's a good article and I'm enjoying working through it.
Now, on to the picky details...
Shouldn't the authors' e-mail addresses be given on the first page?
Many of the illustrations appear to have had rows and columns of pixels removed during resizing. This makes some of them hard to interpret since the text they contain has gotten mangled.
In the MorphicWrappers section on page 2, please tell where the user can get MorphicWrappers. Also, for the benefit of those who aren't intimately familiar with the Squeak and Morphic environments, please tell how to install it and start playing with it.
At the top of page 4, it mentions "when the morph is in focus". Please tell what events cause a morph to come into focus and how it advertises the fact that it is in focus.
Design question: Not all morphs behave the same when in focus. Mathy ones created by typing on air turn color and pop up a balloon saying "I am a Point" or some such, but others created from the "New morph" menu option don't seem to give any visual indication. Was this a design decision? If so, I don't understand the rationale.
On page 4, in the Typing History section, it says "There is one expression history for each class of wrapped objects." But, among other things, I managed to get an Ellipse to give me the expression history for some Points I had created earlier. Objects of different classes appear to give me different sections of a global expression history, and the same morph doesn't always give the same history. I don't understand.
On page 6, in the Identity section, it suddenly starts talking about CarryingMorph and ShakingMorph. I don't understand what these have to do with Identity. Perhaps an omitted section header? Also, wouldn't this discussion go over better a bit later on, after you've discussed redefining methods? That way, you could give an example of some of the neat things that can be accomplished by redefining the methods of those classes.
Page 6, RequestBoxes section, last sentence: insert the word "by" after "RequestBox". It should read, "... to a RequestBox by typing on air..."
But I'm not sure why RequestBoxes are being discussed here. For newbies, this discusson is like the one of CarryingMorph - it brings up the desire to experiment but experimentation requires knowledge that is not obtained until later.
Page 6, Programming with the MorphicWrappers, section header: Delete the word "the". It should read, "Programming with MorphicWrappers".
Same section, first sentence: Change the word "were" to "where". It should read, "... is a framework where more...".
Some cosmetics comments -
The practice of emphasizing terms such as MorphicWrapper, CodeBalloon, etc., every time they're used is distracting. I would like to see them emphasized when they are defined, and written normally everywhere else.
The illustrations are pushed all the way to the left page margin. Shouldn't they line up with the text margin, which is one inch in, or even be centered between the text margins if they're not too wide?
The captions for the illustrations stand out a little too well. It took me a couple of double-takes to figure out that they were captions and not section headers. I would like them not to stand out so much, and be more closely associated with their illustrations.
Also, some of the captions are wider than the illustrations they go with; in that case, they should be folded.
It might be a good idea to number the illustrations.
And that takes us through page 6. More later.
I get a ghostscript error on ~3 page. I think it is looking for a nimbus font. asb
Acrobat works fine. asb
I didn't see where do download/install the MathMorphs file(s). That could be useful. krc
I cannot open this file with adobe because access is denied
Just some comments from Stephane Ducasse
I found the description really exciting even if I get lost by some
of the concepts. My main remark is the following one:
Everytimes you show a picture please consider that the user should
be able to reproduce it by reading the text. I read but even with MathMorph I was not able to reproduce what you show. ;((((
Hi,
This is Bruce O'Neel
Boy, I found this a hard chapter to read. My Math skills are way too weak. It's possible that a paragraph should be included at the beginning warning folks like me.
It also might be useful to have a section for the non-math folks
who still might get some great use out of MathMorphs. I'm thinking
of some of the matrix manipulations in particular.
It would be very useful to have a pointer to the website with the code, unless the code is included in the squeak image by the time the
book is published. It also might be a really nice addition to have
a change set with an example class with 10s of example methods, one for each one of examples you list (that can easily be put into a method).
Finally, you have two gems hidden at the end of the chapter. The Type inference and Text to Speech bits could be very interesting, even
to folks who didn't understand the previous parts of the chapter.
Possibly you could add something in the intro pointing this out.
Thanks very much!
cheers
bruce
Mark's Review of "MathMorphs: An Environment for Learning and Doing Math"
I've been recommending this chapter to many people, especially math and engineering faculty who are trying to decide if Squeak is interesting. I think it works extremely well as part of the "Community" aspect of the book – that Squeak is used in different ways for different reasons by different users, but Squeak itself offers an infrastructure and core that is worth the entire community supporting. I also find the vision at the beginning of the chapter very compelling: Computer-as-metamedium becomes a new way of doing math. (I have "Wow!" written in the footnote of my printout next to these paragraphs :-)
The chapter gets into a set of mathematics concepts which are going to be far beyond most of the readers of the book. I'm not too worried about that. I see part of the story of this chapter as "Squeak works well for math learning and doing because of the particular structure and feature set of Squeak." The advanced mathematics concepts serve as examples of things that Squeak (with MathMorphs) can support well. As long as the math gets related back to MathMorphs and Squeak, it works well. The math-for-the-sake-of-math doesn't work quite so well, e.g., the "How it works" section on p. 29 seems to be just about math, not about MathMorphs or Squeak.
Issues:
- p. 1: Should you warn the reader that there's some heavy math going ahead, and that the reader will still get a lot out of the chapter even if they don't understand ALL of the math?
- p. 2: Some URLs to where to get the latest MathMorphs (e.g. http://mathmorphs.swiki.net) would be great.
- p. 2: I think that an Acknowledgements section like this works well.
- p. 2: "by usual techniques" – what does this mean? You might want to reference John Maloney's chapter on Morphic in the same volume.
- p. 2: "Richiarte" -> "Richarte", yes?
- p. 3: What does it mean "hand is focused on a MorphicWrapper"? Is it just within bounds?
- p. 3: I love the images! They really work!
- p. 4: What is the scope of names defined through typing-on-air? Just the same project?
- p. 5: The top figure doesn't work so well. On paper, one can't see the boundaries between the three images (two images?) so it's hard to see that it's a transition. Perhaps insert a hairline between or an arrow => to show progression?
- p. 5: How does the MorphicWrapper support identity? Does it do a search across submorphs for an == item before creating a new one?
- p. 6: The explanation of carrying and shaking is very nice, but I was wondering how you handle the disappearance of the ShakingMorph. When does it go away? Is it actually carried by the hand before it disappears?
- p. 6: I've never seen a RequestBox in MorphicWrappers – it's very nice! Can you give an example of when one would come up, and/or, how a programmer might use one?
- p. 9: "Forget arguments" I think that the "or" there should be an "and"?
- p. 9: For adding an instance variable and class variable,the same mechanism is listed in both cases. There must be some differentiation in the action, yes? Else how can the system figure out what you're trying to do?
- p. 12: I can't figure out what's going on in either of the figures. What is the flow of action between the workspace, inspector, and morph in the top one? How'd you get a matrix with a vertical bar in the bottom?
- p. 12: I thought that the discussion of why the MatrixReducer is an object was very nice!
- p. 13: Algebraic Ambients – now the going gets seriously tough for those of us with weaker math backgrounds. Can you repeat your warning here that there is value here even for those who don't know the math? For myself, without such a rich math background, I still found the discussion fascinating as I watched math and Squeak interleave throughout.
- p. 13: "special hypothesis" -> "special hypothesES"? Should it be plural?
- p. 16: The font went odd for TensorAmbient, HomAmbient, etc.
- p. 19 was great – I had been wondering how you got those Polynomials to show up as you had in your screenshots! That helped alot.
- p. 23: The refinement of an AlgebraicNumber was terrific!
- p. 24: I couldn't figure out the image at the top of the page. Are we looking at a BookMorph? A particular SturmMorph? How was it generated?
- p. 25: What's the root? Is it just a little pun, or is this picture really how a RootFinder is conveyed in MathMorphs? If so, how is one created?
- p. 26: The RootOfUnity figure introduces an idea that probably should have been mentioned earlier. (I guess the MatrixMorph includes this idea, too, but it wasn't so clear to me.) This is a VERY different wrapper than the ones used on numbers and polynomials earlier. I know that I've played with different wrappers on the same object (when playing with the TuringMachine graphs). Perhaps you might mention earlier that there are these families of wrappers and some objects can be seen within different wrappers for different representations?
- p. 28: What is the image at the top of the page? Is it really a screenshot, or is it a MorphicWrapper balloon placed on top of a picture of a blackboard?
- p. 29: As I suggested earlier, I don't think "How it works" works here, unless the implications for the Squeak could be made clearer.
- p. 30: QualifiedSentece is missing an $n.
- p. 30: The qualified sentence morph is very cool – how did you generate it? Where did the ForEach and ForAll symbols come from?
- p. 31: The lack of need for "self" is very powerful. I think it deserves mention up front when you're first introducing the power of MathMorphs.
- p. 33: "initial velocity proportional to its own extent" means what? That BIG morphs correspond to BIG velocity, or vice versa, or do you mean something different by "extent" than "boundingBox extent"?
- p. 35: Could you say something about how the image of the KalmanFilter was generated? Is this a FunctionPlot?
- p. 36: The screen shot of the biosphere doesn't really work because it won't be in color. Is there a different one that you can use, or can you explain it differently so that color is less critical?
- I'm torn over the "Related Projects" section. On the one hand, it's fascinating! On the other hand, it has little to do with MathMorphs and the chapter is over-long as it is. My preference is to leave them in, but if you can relate them better to the MathMorphs effort (e.g., does type inferencing help MathMorphs any? Does the text-to-speech work build on any of the MathMorphs ideas?) it would work better.
- p. 41: "from which (TO) get"
- p. 41: Graduate class or undergraduate?
- p. 41: "poor provision of artificial examples" – I don't know what's meant there.
- p. 41: The overall conclusion is very nice!
Link to this Page