Slashdot Mirror

Ever since my daughter was able to speak, I've been playing games and doing things that help to "feel" math, not just know math facts.

I expect that will advance her mathematics no end. Quite some time ago I wrote about the difference between mathematics and facts about mathematics : the former is important, the latter is largely all that gets taught. It's like teaching history by simply making kids do nothing memorise names and dates -- sure they can regurgitate facts well, but they have no idea what any of it means, and hence have little chance dealing with history as a more advanced subject later (and yes, I know that history is indeed taught this badly in many places). Unfortunately it takes someone who actually has a feel for and deeper understanding of mathematics to do more than mindlessly teach rote facts from a textbook, and the sort of people who have that understanding are not the sort of people who tend to go in for elementary school teaching.

Math is dead mainly because computers are so good at it, and students are usually better with computers than their teachers are, hence it just feels like a huge waste of time with no rewards.

To me this says that you probably don't really know what math is. Don't feel bad, it's most likely not your fault; most school teacers don't seem to have a very solid grasp of what actually constitutes mathematics either, so it's not surprising that tat you don't hve a very good idea -- no one taught you. Real math is a little like art: computers cn provide tools (photoshop and other art and design software in the case of art) that can take some of the grunt work off your hands, but computers can't do it for you; a lot of great work can also be done for which a computer simply cannot help at all. Explaining what mathematics is is hard; I can, at least, point you toward what mathematics is not. Mathemaics is not the facts and computations that you learn and practice in school, at least not ay more than art is a matter of memorising colour theory and rote learning brush technique. Computers should not obsolete maths an more than they obsolete art.

1. I am still glossing over fine technicalities -- at this stage it would confuse rather than inform, and much of it is pendantry that won't be necessary till later... maybe I'll come back and fill the technical holes, but...
2. I am nowhere close to being finished. I'm barely even started. I've been writing pieces as a hobby project for a year, and have only covered a little ground. I expect that I'll be able to explain the basic ideas of my thesis in another 2 or 3 years, by which time the total material will comfortably fill a large book.

There seems to be a great deal of confusion about mathematics, and I think it is easier to point out what mathematics is not than try and explain what it is. The important point, as you suggest, is that math is about structured reasoning; math is not just the endless array of facts and tidbits that they throw at you in high school math. It troubles me that so many people have been taught math so badly that they seem to not really even know what the subject really is.

Philosophy of numbers is, indeed, an interesting problem, something I've discussed at some length. Still, one shouldn't reject the fact that numbers in the purely abstract are important and useful -- the process of abstraction is fundamental to mathematics, and the question you need to ask yourself is "how much detail can I afford to forget for the problem at hand". The more detail you can safely ignore the simpler and more general your work. Being able to remove consideration of units, or indeed any connection to the concrete physical world is important to mathematics, particularly with regard to developing the degree of generality that ultimately makes the subject as powerful and broad reaching as it is. For many problems the complete abstraction to raw number is too much, you've lost detail and information that is important, but then often the full abstraction is vitally important.

Philosophy of numbers is, indeed, an interesting problem, something I've discussed at some length. Still, one shouldn't reject the fact that numbers in the purely abstract are important and useful -- the process of abstraction is fundamental to mathematics, and the question you need to ask yourself is "how much detail can I afford to forget for the problem at hand". The more detail you can safely ignore the simpler and more general your work. Being able to remove consideration of units, or indeed any connection to the concrete physical world is important to mathematics, particularly with regard to developing the degree of generality that ultimately makes the subject as powerful and broad reaching as it is. For many problems the complete abstraction to raw number is too much, you've lost detail and information that is important, but then often the full abstraction is vitally important.

Philosophy of numbers is, indeed, an interesting problem, something I've discussed at some length. Still, one shouldn't reject the fact that numbers in the purely abstract are important and useful -- the process of abstraction is fundamental to mathematics, and the question you need to ask yourself is "how much detail can I afford to forget for the problem at hand". The more detail you can safely ignore the simpler and more general your work. Being able to remove consideration of units, or indeed any connection to the concrete physical world is important to mathematics, particularly with regard to developing the degree of generality that ultimately makes the subject as powerful and broad reaching as it is. For many problems the complete abstraction to raw number is too much, you've lost detail and information that is important, but then often the full abstraction is vitally important.

It seems we have similar views. I wrote an essay on exactly this subject, and if you're interested I keep a blog on math from a broader perspective.

It seems we have similar views. I wrote an essay on exactly this subject, and if you're interested I keep a blog on math from a broader perspective.

The focus on facts and details in math education is deeply worrying to me. I've written on the topic, and I have to say that I find many of the comments here worrying because the continue to perpetuate the confusion. It is as if we were teaching history by simply getting students to memorise names and dates (which, sadly, is all to common in many schools), or assuming that teaching art history is about getting students to be able to tell you what colours are used in famous paintings, or expecting an education in music to result in nothing more than being able to rattle off names of symphonies, who composed them, when, and in what key. High school algebra is not (or at least, should not be) about making you memorise the quadratic formula, it is (or should be) about teaching you how to use formal reasoning, such as algebra, to arrive at complex results (such as the quadratic formula).

For anyone interested in different perspectives on mathematics, I keep a blog on the subject which provides a wider view of the subject which ought to supplement the details and skills that are currently the focus of so much math education.

The focus on facts and details in math education is deeply worrying to me. I've written on the topic, and I have to say that I find many of the comments here worrying because the continue to perpetuate the confusion. It is as if we were teaching history by simply getting students to memorise names and dates (which, sadly, is all to common in many schools), or assuming that teaching art history is about getting students to be able to tell you what colours are used in famous paintings, or expecting an education in music to result in nothing more than being able to rattle off names of symphonies, who composed them, when, and in what key. High school algebra is not (or at least, should not be) about making you memorise the quadratic formula, it is (or should be) about teaching you how to use formal reasoning, such as algebra, to arrive at complex results (such as the quadratic formula).

For anyone interested in different perspectives on mathematics, I keep a blog on the subject which provides a wider view of the subject which ought to supplement the details and skills that are currently the focus of so much math education.

...Which brings us back to the point: as long as math teachers are not qualified they are in no position to teach deep theory and understanding and just follow the book with no understanding themselves. I would claim that much of mathematics is "boring" because the teachers don't have sufficient understanding to actually explain it well so you can understand and think about the subject. History is boring if you have a teacher who doesn't really know history and just recites names, dates, and events from the textbook. History is interesting if you have a teacher who understands history and can actually explain the depth and richness associated with those dates and events and spur studenbts to really think about history. Math is just the same - except that there are far fewer teachers who have enough understanding to teach it well, so most students come away with little or no understanding of the subject, and just a bunch of poorly memorised formulas.

All you then need to use OO.o for is presentation (which can kind of be hacked inelegantly with Inkscape and Evince), which makes it a lot less painful, especially if you rarely need to do a presentation.

The problem with asking why 1+1=2 at the age of 11 is that any decent answer tends to quickly get mired in technicality. It is an insightful question, but it is beyond most school teachers at that level to answer it adequately. I've got Bertrand Russell (always one of the most lucid and readable of mathematical philosophers) description of why 1+1=2 here (scroll down and look for the quote). If you ask any questions about that description you rapidly get yourself into even deeper waters. This, of course, does not excuse the brush off from the school teacher - he should have said that it is actually a deep question and to answer it well you would have a to learn a lot more.

With regard to mathematics involvement in CS - I'm afraid it is fairly integral, though I agree that calculus is of little real help for the most part. Software engineering, on the other hand, will involve somewhat less mathematics. A trade school course in programming, which is the sort of course that is actually interested in equipping you with skills for a career in IT, can skip over almost all the math. To my mind a CS student complaining that there is too much math and it isn't relevant to his programming career is rather like a physics student complaining that there is too much math and it is relevant to his career in architecture and building construction: it mounts to a fundamental misunderstanding of the aim of the subject (which is not trying to teach you a career). That is not to say that I blame the student for the misunderstanding in the case of CS - things have gotten misrepresented and so many schools have CS courses that border on career training that it is not surprising that students are confused. Or, to put it another way, the confusion based on how different schools present CS results in people like you and me talking at somewhat cross purposes because when I say CS I am thinking one thing, but you hear CS and think something completely different, and vice versa.

On the subject of mathematics being taught poorly - I'm afraid I have to agree. For the most part mathematics is taught appallingly. Of coure how to teach math well is a rather trickier proposition. I'm currently (very slowly) working on a project to describe the research I'm currently doing in mathematics to a general audience. The downside is that becauses it requires so much mathematical scaffolding to get to the point where I can explain things that it is going to be a very long journey. So far I've just gotten started, trying to define what math is, and pointing the basic directions we'll be heading as the project progresses. You can find the first part here. Alternatively I've written a rather more "whirlwind tour" approach essay that gets to more interesting material faster, but is a little steeper to climb due to the brevity. Please feel free to add comments - feedback is most welcome.

With regard to mathematics involvement in CS - I'm afraid it is fairly integral, though I agree that calculus is of little real help for the most part. Software engineering, on the other hand, will involve somewhat less mathematics. A trade school course in programming, which is the sort of course that is actually interested in equipping you with skills for a career in IT, can skip over almost all the math. To my mind a CS student complaining that there is too much math and it isn't relevant to his programming career is rather like a physics student complaining that there is too much math and it is relevant to his career in architecture and building construction: it mounts to a fundamental misunderstanding of the aim of the subject (which is not trying to teach you a career). That is not to say that I blame the student for the misunderstanding in the case of CS - things have gotten misrepresented and so many schools have CS courses that border on career training that it is not surprising that students are confused. Or, to put it another way, the confusion based on how different schools present CS results in people like you and me talking at somewhat cross purposes because when I say CS I am thinking one thing, but you hear CS and think something completely different, and vice versa.

On the subject of mathematics being taught poorly - I'm afraid I have to agree. For the most part mathematics is taught appallingly. Of coure how to teach math well is a rather trickier proposition. I'm currently (very slowly) working on a project to describe the research I'm currently doing in mathematics to a general audience. The downside is that becauses it requires so much mathematical scaffolding to get to the point where I can explain things that it is going to be a very long journey. So far I've just gotten started, trying to define what math is, and pointing the basic directions we'll be heading as the project progresses. You can find the first part here. Alternatively I've written a rather more "whirlwind tour" approach essay that gets to more interesting material faster, but is a little steeper to climb due to the brevity. Please feel free to add comments - feedback is most welcome.

May I refer you to this post then, from a poster who gives an elegant description of various ways in which category theory can be effectively applied to computer science in a practical way, and as more than just a model of abstraction. As to what abstraction is I just wrote an essay on that, and my point would be that while abstraction is, indeed, to reduce an idea to the pertinent details, there is the question of which details are pertinent. I would suggest your particular abstraction is leaving out some rather important ones.

Pagemaker is a LOT better than Draw for, say, laying out a newsletter. Yes, yes, LaTeX... but why learn a complicated system when there's an easy one available?

LaTeX doesn't need to be complicated, it's just that few people have bothered to make it simple because it mostly suits their needs already. For an example of making LaTeX easier, consider the problem of laying out and designing a presentation in LaTeX. Hard to do right? Especially for a customised layout. It needn't be: you can draw what you want in inkscape and convert it into a LaTeX presentation layout. I admit that what is on offer there is still not as simple as it could be - but then I'm not really much of a programmer and a simply python script to do the conversion is more than adequate. I'm sure someone appropriately inclined would have no trouble putting a nice GUI with appropriate buttons to click on the whole thing.

Moreover, the simple process involved there can easily enough be converted into a system to design report layouts, newsletter layouts, whatever. If I ever get the time I'll convert it into a more generalised version that handles all of that.

Jedidiah.

If you're doing your presentations in LaTeX then you might want to look at my package that allows you to custom design LaTeX presentation styles in Inkscape. It isn't a replacement for Beamer if you have particularly complex presentation needs, but if you just want something simple to hammer out great looking presentations it may well be worth your time.

Jedidiah.

Because when you switch to PhotoShop or Gimp from another application on a Mac, ALL the pallette windows come with it. In Windows, every toolbar and pallette hangs there by itself and disappear behind your browser or other window, and you have to either bring them all to the front again, or hunt through them until you find the one you want. its a pain in the neck, and made me give up on Gimp on Windows at work.

Yeah, window management of Windows really sucks. Everyone seems to blame GIMP for this, but it works fine on systems withn decent window management, for which it was written. Yes the port over to windows has some issues because Windows lacks a number of basic features that are available for most other windowing systems...

How do other windowing systems handle this? Well, they have several methods. They can do it like the Mac and automatically group application windows by application, they can do it like a lot of X11 WMs and allow multiple/virtual desktops so you can have 1 desktop per task, or you can go with the method taken by some of the fancier X11 WMs and do window groups.

Jedidiah.

I'm really not sure what a correct, elegant solution would be. I loathe the usual Windows container-window MDI, and I do realise that GTK has very little, if any support for writing applications in such a manner, but I do wonder how the situation could be improved for Windows users.

GTK doesn't have support for MDI for a very good reason - it just isn't its responsibility. A widget tollset shouldn't be implementing its own separate window management scheme, which is what MDI as part of GTK would amount to. Handling windows is the Window Managers job. Unfortunately current X Window Managers want to absolve themselves of responsibility and pretend the toolkit should do it. Much silliness and bitching from users ensues. I do agree though, that on Windows, which does provide its own (different!) window management scheme as part of the toolkit, and hence provides no facility in the overall window manager, this presents a problem. But GTK isn't really designed for Windows... perhaps the Windows-GTK people ould add a special patch or soemthing...

A default setup with all the tools and palettes in one tall window on the left of the screen, and some code to grab the 'Maximise' button on image windows so that they expand to fit the space not occupied by the tools window?

Again, I have to blame Window Managers - where oh where is the "maximise to available area" function?! This used to be standard on X WMs, and is still available in things like FVWM and Enlightenment. Windows certainly has no such thing, but then Windows window management is quite sad in so many respects that we shouldn't be surprised.

Likewise, the 'Minimise' button on the tools window could minimise all windows belonging to The GIMP - perhaps a bit of a hack, but it could help.

Ideally I'd like to see a solution that allowed you to finesse that so it does what you want, and you can, for instance, just minimise a single image window, or minimise everything, or maybe just all the tool palettes in an easily controllable manner. It isn't that hard to do.

Jedidiah.

IMO, raising one of them should raise them ALL, and I have yet to find a way to do that. If you know of one (Windows OR Linux), please tell me.

Use a window manager that support window groups and group your GIMP windows. Enlightenment does, I'm not sure about others. I have a proposal for a decent way to do window groups easily here, with advanced features if you want to offer something new for power users. Basically the principle is this: all your GIMP windows belong to a group, and actions applied to a member of the group (like a raise operation) get applied to all members of the group.

The other option, which may e easier to find, is a window manager that supports "send to back", and simply send the other application to the back behind all the various GIMP windows. This used to be a standard feature of X WMs with a toggle key that alternately raised to the top or sent to the back. For some reason a lot of window managers have hidden this feature, or simply not include it at all.

In my opinion a lot of the "issues" with the GIMP interface (in terms of the multiple windows) is more to do with the lack of good window handling from mainstream WMs rather than inherent failings of GIMP. Yes it would be nice to adapt to what's available now, but WMs used to have all these features, so it made sense at the time... and now we're waiting to get our perfectly reasonable and sensible features back damnit!

Jedidiah.

How do you manage 15+ applications that are open?

Well, my suggestion is to combine together multiple desktops with something like this, which allows you to group and control windows elegantly, and potentially in complex and useful ways. If groups could, for instance, hint to the taskbar to group their entries, and applications were capable of hinting to the WM whether to create a new group for its subwindows... well, then you'd have some very useful new window control/management tools available to you.

Jedidiah.

That's no valid as either an excuse or an explanation. The authors of The Gimp knew how X11 WMs worked 10 years ago, and they know they haven't changed too much in the meantime.

Two points:

(1) 10 years ago window managers did actually have such features - witness FVWM, Enlightenment, Blackbox, etc. It has been the recent "new" window managers that have ignored such useful things as "maximise to available area" and window grouping.

(2) I'm not really apologising for GIMP so much as criticising the current mainstream window managers for having fundamentally broken/incomplete behaviour. As I said, such things were available in many window managers for a long time - we should be demanding these features in the mainstream WMs.

So you can't have any windows from other applications onscreen at all. Not a great solution. And what do you do when you'd like to minimize The Gimp and look at something else? Minimize 6 different palettes individually?

I can have several other windows on screen if I want. Check out how Enlightenment handles "maximise to available area": if the window being maximised already overlaps another window, it can maximise beyond it. Besides I can just iconify any other windows out of the way to do the maximise if the smart maximising won't be enough.

What do I do when I want to iconify all the GIMP windows? I just iconify the toolbox. Seeign as all the GIMP windows belong to a window group they automatically iconify as well. You see, the issue is that current mainstream window managers are poor at real window handling. We really ought to be demanding our features back.

Both those problems can be worked-around by assigning a desktop space that's for The Gimp only- but the existence of workarounds doesn't absolve the designer.

You criticise GIMP for knowing what features WMs had but not adjusting to it, and now for knowing what features WMs have, and taking advantage of it. Multiple desktops are one of the few features that has survived unscathed. If proper maximisation and window groups had also managed to survive (and hopefully be improved upon) you wouldn't have anything to complain about. If WMs would just get around to implementing these features a great many people (who apparently never even realised that this was their real problem) will undoubtedly be a lot happier.

Jedidiah.

Is getting the GIMP's UI to standardize on "NOT SUCKING"

I'd be interested to see a good discussion of what exactly it is about GIMP's interface that makes it suck. I've seen lots of complaints that "It sucks!" but less in the way of explanations of what the problems actually are. Certainly there are some minor quirks (discoverability of drawing straight lines for instance), but almost all programs as complex as GIMP have similar quirks. Besides, many of those elements are just that: quirks and minor issues that are being corrected. It doesn't explain the "fundamental suckiness" of the UI.

The most common fundamental complaint about GIMP that I've heard is to do with window handling. This is certainly somewhat of a problem in the Microsoft Windows port, but the port is just that: a port of an application that isn't being developed for that platform. You'll get issues like that in such ports. I have heard that there are patches/plugins that allow GIMP to operate with a root window MDI interface on Windows anyway.

So then we're down to the issue of window handling on X. The complaint seems to be that GIMP doesn't have an MDI interface, and that that is fundamentally bad. Realistically however GIMP is doing things the right way. It delegates window handling to the window manager. The problem with MDIs in applications like GIMP is this: GIMP then has to write its own (usually remarkably inferior) window managing code. This is silly when, on X, we already have a seperate application that is supposed to do all the management of windows. The problem is not, as so many complain, with GIMP, but rather with X window managers. Choose a good window manager that implements window groups and the GIMP interface issues that people describe suddenly vanish. The problem is that few window managers implement window groups, and the ones that do are often lacking in other areas. If you have a problem with window handling for GIMP you should be complaining loud and long to the Metacity and KWin and *box developers that they need to implement a good powerful window group management facility (preferably one that is hintable from applications). That's where the real problem lies.

I've written a description of a particularly power user oriented (extract the greatest power and flexibility out of the concept) window group system. It's still relatively simple to use, and if only a subset of this functionality was implemented it would be entirely possible to have a simple easy to use window group system that would eliminate most of these complaints. The problem is getting such a system implemented by mainstream window managers.

Jedidiah.

The task bar on the KDE Panel automagically groups Gimp windows when the taskbar area becomes crowded...The Gnome (2.6.2) panel's window list area also does grouping. If the area is crowded, gimp windows are automatically grouped. If you want this behavior at all times, pick "Window Grouping: Always group windows" in the preferences dialog.

Nice, but not what he's talking about. Try reading this, which is my proposal for a window grouping interface to get an idea of what is being discussed. I admit that my proposal tends to lean toward power users (I felt it was better to outline all the possibilities), but the basic interface concept for how to group and basic management of the groups is, I think, quite reasonable, and all WMs ought to have something along these lines available.

Jedidiah.

just like The Gimp team is ignoring a large base of potential users by not making the inclusion of a MDI mode a top priority.

That's backward thinking in my view. If you make the application do the MDI, then it has to implement it's own window management scheme - which is always going to be second rate compared to a devoted window manager. On the other had, if you enable the window manager itself to enable MDI like behaviour, you have something far more powerful and flexible in the way of MDI, and at the same time, you get to automatically inherit the window manager's management into the MDI.

Jedidiah

Improvements in GTK should be considered so that screen space is used more efficiently. More intuitive and automatic workspace management would help (such as the Amiga's launching of apps on new workspaces), the option of top-of-screen menus (which aids muscle memory too) would also help.

I've been cntemplating new ways to manage lots of windows. The traditional methods are multiple workspaces, and tabbed windows (like fluxbox or PWM). Enlightenment had a cunning scheme for window groups, but it was clumsy to interact with, and hard to always make it do what you wanted.

With that in mind, I have tried to create a new scheme that manages to make Enlightenment style window groups accessible and simple to use, yet more flexible. I think I have something - you can read my proposal here. Effectively this system is to MDIs what Fluxboxes tabbed windows are to tab interface - only more so. For all those who are busy saying "MDIs suck!", take the time to read what I have in mind. traditionally the problem with MDIs are that they implement their own internal way of managing windows inside the MDI, and that usually sucks. Instead, with this system any MDI would simply use the existing window manager to do everything.

To implement the idea on a basic level is not hard at all (though I am not a coder, so unfrotnately that job doesn't fall to me), but to have it integrated well into the system, in the same way that multiple desktops are heavily integrated into te system, would take a little more work - if anyone wants to code up a version for their favourite window manager, feel free to do so - just let me know so I can try it out.

Jedidiah