This issue is one i think about a fair bit. The usability is some sort of dialog between the user and the program: the user has expectations from entering commands and typing.
I wrote a number of script files a while back. These were programs that did useful work. They ran from the command prompt, so there were no press-button dialog boxes. But the coding was such that i could easily redesign the input sequence on a user-basis, to match the different worksheets. The results were still the same, but the input and output were redesigned to match each section's needs.
The whole idea of user interface design, is that it should be obvious to the user, from standard techniques (eg/? options), exactly what is going to happen.
Some user designs are good, but there is an intrinsic flaw in the design. Consider the desktop. The idea that the screen is a place to start things from is good. But it's more suited for a single-tasking system, since there is no way of recovering the screen once it is overlaid. The problem with this is because the desktop is not listed as a running task.
Suppose, parallel to the desktop, there is also a running task that has the desktop in a window. This would bring on demand, a desktop to the front whenever the user wanted it, and the windowed nature of it would indicate that it was not the only running task.
Using a system menu, such as Microsoft's taskbar, is good, in so much as it is always available to launch and notify. But there is a limit to how much real-estate one can afford for this.
One can go for really tiny windows, like the Office taskbar from Office 4.3. This was a little array of icons, about the size of the title window, that sat in unused space in the title. I use bbar.exe in this way. It takes very little real estate, and coupled with popsel, gives one a multi-menued task-bar.
The idea of running tasks as separate icons is not good: i would rather have a drop-down list, with sublists for sub-windows.
The teletype has been around over 100 years, and is rarely used now. But the idiom of having commands and output is very much alive, because it is something that people can relate to. You don't need a teletype to use a teletype interface.
Likewise, whatever happens to paper in the next 200 years, does not change the effectiveness of creating a form of authority and request. The point was, that instead of storing data in specific formats, one should start considering a global format for forms, etc, and have programs talk in that way.
The effect of this is that forms can be shunted around the electrical office in the same way that paper forms are now: the form would grow as different things are done to it, and then ultimately stored on different media, such as microfiche, or some other durable medium.
One of the side effects is to reduce the interdependence of programs: the payroll forms, for example could be processed on an OS/2 box, and the accounts sent to a Linux box for further processing. Changing the accounting program would then be easy, since it would be a plug-in system.
Consider, for a moment, paper forms. They serve their purpose well. That is one can create a form and use it.
Consider then the model where one makes an XML standard form. Instead of using bits of paper, one has an XML file, suitably filed &c, with part of the crc hidden with the digital signature.
Regardless of the systems in place, the core of the business is not stored in structured program-specific data, but rather forms. One can easily start upgrading the system, or even run several systems, that are none the less capable of using the same forms.
It then would not really matter, for example, if this office used Linux 2060, and that office used OS/4, and some other office is stuck with some legacy operating system such as Longhorn: everyone's talking together in standard defined XML forms, and acting accordingly.
That is, one had basically moved the data to a separate entity to the underlying programs.
The main problem is not so much with "applications" but data format. We talk of the aging db2 formats used of data bases. The reason that these hang around for so long, is that much of the corporate history hangs out in it.
When i design projects, i tend to think more about keeping the data clean, simple and robust over time, rather than the ease which certian applications can reproduce it.
For example, when i designed KML, the idea was that it was meant to be a robust format that could be defined outside the context of any word-processor, and ultimately aimed at HTML, TeX, etc. At the moment, it is Regina REXX's job to render my markup. Nothing stops this from becoming Perl's or CEnvi's job! It's just a matter of writing a new parsing engine.
Because it is not something like HTML or TeX or RTF, i have considerable control over the format, and i can map several internal styles onto the same output, eg like {emphasis} vs {bold} in html.
But the thing can be to the structure of the document.
It is more data standard, rather than program standard that is important. The latter is also important, since we don't want to either run dusty decks or old programs.
But what can you expect from an upgrades-driven market?
In my younger days, i used fdisk as a defragger. Works a treat - and great for downloading lots of empty space.Later on, i converted to OS/2, which had a GUI fdsik!
Mind you, ghost is pretty nifty for fixing machines as well: prolly the unix dd might do it too: just put a new image over the top of the old one!
I suppose now-a-days, i use partition magic. Does the job just swell.
It would only be captain india if he lives in india. It would i suppose, really hurt the americans, if it was Captain America was from and in the employ of the subcontinent.
But hey, a culture of outsourcing leads to an outsourced culture.....
If the intent is to write simple one-off scripts, then something like rexx or cmd or something like that is the go.
On the other hand, if the intent is to develop applications, ie scripts that are typically 40k of source file, then i found Don Knuth's "structured programming" approach useful.
You see, the "problem" is that one can have very large loops, like
begin {many lines of code, with internal nesting} end
What i did was to break the program down to handleable segments, and then assemble the program in the index, like so:
comments about the nature of the files. All file-opening + closing is referenced here.
&c, &c.
The advantage of this is that one can use the same variable across a whole range of files, and one can at a glance see what each segment of code does. The result is then compiled, so that the run-time code is free of comments.
The language can be set up to be simply a text processor, so that one can write the program and INI files in the same source.
You can even do web pages in it, although i prefer to use a home-grown markup language + converter, which i implemented in exactly this way. It is a 40K source file, that breaks down to a 20k rexx script. One can add different bits and pieces without having to digest a 40k file every time: the 40k weave file is structured for easy reading and editing, the resulting 20k output is structured for easy interpretation, since no dead code or comments ever makes it to the list (even where it is in the source tape).
Weave has its limitations also, in that it is not suited for larger programs (as Jon Bentley pointed out in his critisms of Literate Programming), but the approach of "compiled" batch and script files is *ideal* for jobs that rely on 20k-60k files.
My weave-program is itself written in a miniture weave-program, that allows one to intersperse rexx script and comments at any ratio, giving at the end, a rexx script, with no dead code in it. In the example below, one does not see any comments or dead code go through to the program.
Of course, one could look around for Regina REXX, which is cross-platform, and also Patric McPhee's excellent DLLs for REXX.
The real killer is that one has to get something useful going quickly; rather than the language itself. This helps to maintain interest in it.
Unlike BASIC, rexx is fairly easy to learn, while having structured programming, rather than goto's. Also, one does not have to invoke libraries for things.
The registry first appeared in Microsoft Word for Windows. That is, if you install Winword 1.0 under Windows 3.0, it will create both regedit and the registry filr reg.dat.
The MSD program, in both DOS and Windows incarnations, comes from Word. WinWord 1.0 sports MSD vers 1.0, and later versions of WinWord sports a windows version of the same thing.
MSWord is the stomping ground for the crappier ideas we see in Windows, although the dreaded Clippy comes from no other than MS-Bob via Office to Windows XP.
Windows 98 is the last form of Win9x that has a detangable DOS. I mean, people are still flogging MS-DOS 6.22, because this was the last legit stand-alone DOS.
You can detangle the DOS 7.1 from this, and run it as a stand-alone DOS. You can use this DOS to run Windows 3.1 as well as Win95/98.
I mean, the DOS is good enough to run boot-disks that access fat32 &c, and for low-end games-machines, is still the shot.
I installed the patch. It's quite good. It fixes up about 70 bugs, + replaces those awful win98 icons with win2k icons + colour-scheme.
Apart from a few bug fixes, it integrates things like visual-basic runtime files, jet updates + a few other dll-y things.
All versions of OS/2 and Windows NT/2K/XP ships with a copy of qbasic 1.0, while DOS 6, and windoze ME/9x ship with qbasic 1.1.
All of these can be started as an editor, eg QBASIC / EDCOM
On the other hand, only vers 1.1 can read the dos help file HELP.HLP.
Amusingly, Windows understands what a QHELP file is, that if you click on a quickbasic help file, it says 'this is a DOS help file', whereas any other help file (eg 4dos.hlp), it says "unknown format".
In any case, basic shipped with msdos, because in older times, computers had a rom-basic in their bios.
GWBASIC is a standalone emulator for graphical workstations (ie workstations that replaced the rom-basic with video memory).
BASIC in its raw form continues to affect the way that COMMAND.COM and CMD.EXE work. For example, if one does a test, and it is false, the rest of the line is skipped. In the sample below, we see two statements, separated by an &. If one makes the if statement, one gets neither command, while if the statement is true, both work.
if "1"=="1" echo 1 & echo 2
One can implement a die style command by this, or by replacing echo with set, pass a parameter to a subroutine.
msdos 7.1, windows 95, windows 98, os/2 4.5.2, winnt 2000, etc.
4dos, 4os2, or 4nt
regina rexx + mcphee's dll's
most utilities via script-install. Most shell icons and tree layout gets hacked in the script-installs as well. A multiboot makes this useful in any case, so it's not hard to get in the habit.
Once one has a desktop, one can do a clean install of some OS, and then
fix-packs are slipstreamed, or installed first.
internet exploder
unslipstreamed hot-fixes + fixpacks
pdf-viewer
lite2000, (which i doctor the running services and install utilities stuff)
standard utility pack
adaware, firewall, msnmsg 5.1 installed and hacked.
hardware stuff. your mouse has moved, windows must restart for this to take effect
First, there is the matter of command recall. A command line without this is a lot more user hostile than one that is.
There are matters of teletype help, which allows one to select the right switches. Some of the programs that offer lots of options have a very large teletype help, which can not be viewed by screen-fuls.
Whether command and/or file completion is present is another issue.
An important issue is console leakage: that is, whether things like stacks, pipes and command histories leak from console to console.
Another joy i discovered is that multithreading pipe commands might transfer control to the last window, which nicely ends the console after successful completion.
For those who don't understand, trying to say, "there is no 4dos".....
Even there are several command line interfaces.
teletype session, where input and output sessions are to the same session, eg cmd.exe, command.com
command line session, where the command line is for input only, and output goes elsewhere (eg to a different window) eg dbase ii, praxim, IBM DOS E Editor.
Of course, just because the thing looks like a command console, it can be as every bit as hostile as a gui can.
Making command sessions more user friendly
Here are some tips for making a command line more user friendly.
A set of standard commands to indicate what is possible, eg ? to list available commands. 4DOS uses this, and i have seen it a few other places.
A help command to get users started. PTSDOS has a command line help, as did DOS 5.
Some common 'exit' command, that will close the program.
Supporting/? or -? options that gives a page of information.
Commands that do what they say they are, and not do extra things.
Command names that actually suggest what they are going to do.
I have used spreadsheets from the early nineties, even to generate word-processing documents. It took me about 30 minutes to make up a program that generated letters that skipped paragraphs on demand (lotus 123 allowed non-printing lines beginning with a | ).
For an semitechnical person, one finds it cheaper (in time+effort) and easier to use a more limited toolset. So i used, for example, spreadsheet sorting to do time management and 'database views'. It's more about creating sort-friendly handles (eg moving a process through steps a, c, e, g, (with b, d, as block headers). In essence, it is easy to understand, it is easy to work, and easy to correct.
In terms of converting data, one saves data into CSV format, and let Rexx or Perl or Grep loose on it. One can easily get rid of surplus blanks, mixed case et al, simply by this ruse.
On the other hand, the user-hostile way that word was set up, it took me three days even to get the virual basic ide to load. In the end i used a search on a word i knew was in the script!
The spreadsheet has been around long before computers (think of the 8 and 12 column ledgers in the stationers), the magic of spreadsheet is that it basically gives you a clean sheet of active cells to play with.
I suppose before people had phones &c, there were lots of telegrams, designed to get to localised points (eg post office), where it would be dispatched by local services.
Railway crossings are still represented by steam engines, even though these have largely disappeared from the railways, and the old rotary telephone is still the icon for it.
I don't think updating the symbol as icons get updated is a good idea. Icons are symbols that have a meaning, in exactly the same way that keyboard sequences and menu positions are.
These have become standardised (the old q-edit sequence is 'esc,q,q', or some of the IBM programs, which MSD follows, is 'F3'.
I find the algebraic easier to read, but when i evaluate it, it's in RPN order. Note that an
algebraic calculator can have many pending operators, that when one presses a key, one might effect a number of pending operators. Also, one never gets the chance to check the local operators as they fall.
Ten lines of GWBASIC implement the control logic. Exactly what one puts into the stack and what operators and functions are defined elsewhere. One could have 8*8 matricies there:)
On the other hand, writing an RPN code allows one to jimmy together special routines that do one thing, or allow you to write your own functions, and then use an RPN calculator to parse lines. Eg you could produce a document that does calculations like a giant batch file, and produce polished output. Done this often enough.
RPN is actually suffix notation: ie, instead of writing add(a,b), one writes (a,b)add. In fact, the "PN" is a prefix notation, and the R reverses it to a suffix notation.
Because RPN functions expect the same number of functions, ADD will find its arguements already in the stack, and change the stack to a predictable state.
In terms of assembler language, it's pretty much the same, i imagine.
In RPN, the arguements exist before the function occurs, and there is no need for precidence. That is, "+" or "SIN" finds the arguments pre-existing.
Also, in PASCAL, the way the code is loaded, the program *expects* called subroutines to be loaded in the order from deepest to shallowest: that is, the main() is the last loaded routine.
Don Knuth's "literate programming" got around that, but it's a perfectly natural way to think.
In the long run, i settled for a file structure based on some home-grown catalogue.
The base directory describes the block.
Take for example software. There are two possible ways of sorting this: stuff from vendors and stuff by structure. I use both, but the majority of stuff gets stored in the vendor tree, and the minority under the opsys tree. So if i want a non-descript OS/2 utility for file management, i would look under opsys/os2/fileman/
while something from say file commander/2 [which i use a lot] is/vendor/fileman/harvard/os2/.
Personal stuff gets stored under the tdisk tree. These are grouped under broad catergories, eg 'maths', and then a date directory. eg:/tdisk/maths/nbfk/
The whole idea is if ye take a bucket-load of
backup cdroms, ye should get a single tree that is easy to sort through.
This is a line by line translieration of the symbol font in imh0.jpg.
*
* As part of the kernel evolution
towards modular naming, the
* functions malloc and mfree are being
renamed to rmalloc and rmfree
* Compatibility will be maintained by
the folowing assembler code:
* (also see mfree/rmfree below)
*/
Note the parent has "assembly" for "assembler" in the the line "the following assembler code:".
As a host who gets kids who come in to her room, and use symbol font, it's pretty straight forward to read this.
There are people who can see in 4D and higher. I have not fully tested my poweress, but i have had a glimpse of 7D (looking down a hyperbolic vertex figure of a tiling with a 6D euclidian vertex figure derived from the Gosset tiling 2_22).
In three dimensions, we see a 2D cross-section, rather than the true 3D of it. And it's not a
planar cross-section, but an angular one: ie we see whatever is occupying phi/theta than what's at a constant y.
Of course, the visualisation of 4D is the like of watching all bits of a movie projected into solid space or something: that is, ye see the wholeness of the figure, rather than some 3D slice.
The same is true of hyperbolic space. I have little trouble with some figures in 4D hyperbolic space, for example. The most common projections of hyperbolic space are the poincare disk and the klein disk. When i do sketches of what i see, i use either a cylinderical or orthographic projection, depending on whether i am moving or stationary.
Unlike watching a movie, it is more a case of creating the image to watch as ye do it. So while i can watch things in 4D in this manner, the plot of the story needs to be created in the mind, rather than watching someone else's impression of it.
5D and 6D are a bit harder, but can be done.
On the question of the 4D Klien bottle, I have seen pictures of it in 3D, and i can mentally crall over its surface, and i know there is a transformation of its surface into a square-shaped thing, but i am unable to make that topological transformation. But then, i am unable to make the transformation in 3D of turning a torus inside out.
Slashdot Mirror
I wrote a number of script files a while back. These were programs that did useful work. They ran from the command prompt, so there were no press-button dialog boxes. But the coding was such that i could easily redesign the input sequence on a user-basis, to match the different worksheets. The results were still the same, but the input and output were redesigned to match each section's needs.
The whole idea of user interface design, is that it should be obvious to the user, from standard techniques (eg /? options), exactly what is going to happen.
Some user designs are good, but there is an intrinsic flaw in the design. Consider the desktop. The idea that the screen is a place to start things from is good. But it's more suited for a single-tasking system, since there is no way of recovering the screen once it is overlaid. The problem with this is because the desktop is not listed as a running task.
Suppose, parallel to the desktop, there is also a running task that has the desktop in a window. This would bring on demand, a desktop to the front whenever the user wanted it, and the windowed nature of it would indicate that it was not the only running task.
Using a system menu, such as Microsoft's taskbar, is good, in so much as it is always available to launch and notify. But there is a limit to how much real-estate one can afford for this.
One can go for really tiny windows, like the Office taskbar from Office 4.3. This was a little array of icons, about the size of the title window, that sat in unused space in the title. I use bbar.exe in this way. It takes very little real estate, and coupled with popsel, gives one a multi-menued task-bar.
The idea of running tasks as separate icons is not good: i would rather have a drop-down list, with sublists for sub-windows.
Likewise, whatever happens to paper in the next 200 years, does not change the effectiveness of creating a form of authority and request. The point was, that instead of storing data in specific formats, one should start considering a global format for forms, etc, and have programs talk in that way.
The effect of this is that forms can be shunted around the electrical office in the same way that paper forms are now: the form would grow as different things are done to it, and then ultimately stored on different media, such as microfiche, or some other durable medium.
One of the side effects is to reduce the interdependence of programs: the payroll forms, for example could be processed on an OS/2 box, and the accounts sent to a Linux box for further processing. Changing the accounting program would then be easy, since it would be a plug-in system.
Consider then the model where one makes an XML standard form. Instead of using bits of paper, one has an XML file, suitably filed &c, with part of the crc hidden with the digital signature.
Regardless of the systems in place, the core of the business is not stored in structured program-specific data, but rather forms. One can easily start upgrading the system, or even run several systems, that are none the less capable of using the same forms.
It then would not really matter, for example, if this office used Linux 2060, and that office used OS/4, and some other office is stuck with some legacy operating system such as Longhorn: everyone's talking together in standard defined XML forms, and acting accordingly.
That is, one had basically moved the data to a separate entity to the underlying programs.
When i design projects, i tend to think more about keeping the data clean, simple and robust over time, rather than the ease which certian applications can reproduce it.
For example, when i designed KML, the idea was that it was meant to be a robust format that could be defined outside the context of any word-processor, and ultimately aimed at HTML, TeX, etc. At the moment, it is Regina REXX's job to render my markup. Nothing stops this from becoming Perl's or CEnvi's job! It's just a matter of writing a new parsing engine.
Because it is not something like HTML or TeX or RTF, i have considerable control over the format, and i can map several internal styles onto the same output, eg like {emphasis} vs {bold} in html. But the thing can be to the structure of the document.
It is more data standard, rather than program standard that is important. The latter is also important, since we don't want to either run dusty decks or old programs.
But what can you expect from an upgrades-driven market?
Mind you, ghost is pretty nifty for fixing machines as well: prolly the unix dd might do it too: just put a new image over the top of the old one!
I suppose now-a-days, i use partition magic. Does the job just swell.
fwiw, the Windoze NT version:
But hey, a culture of outsourcing leads to an outsourced culture.....
On the other hand, if the intent is to develop applications, ie scripts that are typically 40k of source file, then i found Don Knuth's "structured programming" approach useful.
You see, the "problem" is that one can have very large loops, like
What i did was to break the program down to handleable segments, and then assemble the program in the index, like so:The advantage of this is that one can use the same variable across a whole range of files, and one can at a glance see what each segment of code does. The result is then compiled, so that the run-time code is free of comments.The language can be set up to be simply a text processor, so that one can write the program and INI files in the same source.
You can even do web pages in it, although i prefer to use a home-grown markup language + converter, which i implemented in exactly this way. It is a 40K source file, that breaks down to a 20k rexx script. One can add different bits and pieces without having to digest a 40k file every time: the 40k weave file is structured for easy reading and editing, the resulting 20k output is structured for easy interpretation, since no dead code or comments ever makes it to the list (even where it is in the source tape).
Weave has its limitations also, in that it is not suited for larger programs (as Jon Bentley pointed out in his critisms of Literate Programming), but the approach of "compiled" batch and script files is *ideal* for jobs that rely on 20k-60k files.
My weave-program is itself written in a miniture weave-program, that allows one to intersperse rexx script and comments at any ratio, giving at the end, a rexx script, with no dead code in it. In the example below, one does not see any comments or dead code go through to the program.
The real killer is that one has to get something useful going quickly; rather than the language itself. This helps to maintain interest in it.
Unlike BASIC, rexx is fairly easy to learn, while having structured programming, rather than goto's. Also, one does not have to invoke libraries for things.
If she has a mathematical bent, try also the rexx routines at the Album of Algorithmic Techniques.
All he needs now is a signal to pick up. {laugh - it's funny}
The MSD program, in both DOS and Windows incarnations, comes from Word. WinWord 1.0 sports MSD vers 1.0, and later versions of WinWord sports a windows version of the same thing.
MSWord is the stomping ground for the crappier ideas we see in Windows, although the dreaded Clippy comes from no other than MS-Bob via Office to Windows XP.
You can detangle the DOS 7.1 from this, and run it as a stand-alone DOS. You can use this DOS to run Windows 3.1 as well as Win95/98.
I mean, the DOS is good enough to run boot-disks that access fat32 &c, and for low-end games-machines, is still the shot.
I installed the patch. It's quite good. It fixes up about 70 bugs, + replaces those awful win98 icons with win2k icons + colour-scheme.
Apart from a few bug fixes, it integrates things like visual-basic runtime files, jet updates + a few other dll-y things.
All of these can be started as an editor, eg QBASIC / EDCOM
On the other hand, only vers 1.1 can read the dos help file HELP.HLP.
Amusingly, Windows understands what a QHELP file is, that if you click on a quickbasic help file, it says 'this is a DOS help file', whereas any other help file (eg 4dos.hlp), it says "unknown format".
In any case, basic shipped with msdos, because in older times, computers had a rom-basic in their bios.
GWBASIC is a standalone emulator for graphical workstations (ie workstations that replaced the rom-basic with video memory).
BASIC in its raw form continues to affect the way that COMMAND.COM and CMD.EXE work. For example, if one does a test, and it is false, the rest of the line is skipped. In the sample below, we see two statements, separated by an &. If one makes the if statement, one gets neither command, while if the statement is true, both work.
One can implement a die style command by this, or by replacing echo with set, pass a parameter to a subroutine.In any case, it's dodgy.- some kind of DOS (one or more)
- partition commander
- msdos 7.1, windows 95, windows 98, os/2 4.5.2, winnt 2000, etc.
- 4dos, 4os2, or 4nt
- regina rexx + mcphee's dll's
- most utilities via script-install. Most shell icons and tree layout gets hacked in the script-installs as well. A multiboot makes this useful in any case, so it's not hard to get in the habit.
Once one has a desktop, one can do a clean install of some OS, and thenFirst, there is the matter of command recall. A command line without this is a lot more user hostile than one that is.
There are matters of teletype help, which allows one to select the right switches. Some of the programs that offer lots of options have a very large teletype help, which can not be viewed by screen-fuls.
Whether command and/or file completion is present is another issue.
An important issue is console leakage: that is, whether things like stacks, pipes and command histories leak from console to console.
Another joy i discovered is that multithreading pipe commands might transfer control to the last window, which nicely ends the console after successful completion.
For those who don't understand, trying to say, "there is no 4dos".....
Even there are several command line interfaces.
- teletype session, where input and output sessions are to the same session, eg cmd.exe, command.com
- command line session, where the command line is for input only, and output goes elsewhere (eg to a different window) eg dbase ii, praxim, IBM DOS E Editor.
Of course, just because the thing looks like a command console, it can be as every bit as hostile as a gui can.Making command sessions more user friendly
Here are some tips for making a command line more user friendly.
For an semitechnical person, one finds it cheaper (in time+effort) and easier to use a more limited toolset. So i used, for example, spreadsheet sorting to do time management and 'database views'. It's more about creating sort-friendly handles (eg moving a process through steps a, c, e, g, (with b, d, as block headers). In essence, it is easy to understand, it is easy to work, and easy to correct.
In terms of converting data, one saves data into CSV format, and let Rexx or Perl or Grep loose on it. One can easily get rid of surplus blanks, mixed case et al, simply by this ruse.
On the other hand, the user-hostile way that word was set up, it took me three days even to get the virual basic ide to load. In the end i used a search on a word i knew was in the script!
The spreadsheet has been around long before computers (think of the 8 and 12 column ledgers in the stationers), the magic of spreadsheet is that it basically gives you a clean sheet of active cells to play with.
I suppose that halt+catch fire will take on a whole new meaning!
I suppose before people had phones &c, there were lots of telegrams, designed to get to localised points (eg post office), where it would be dispatched by local services.
Railway crossings are still represented by steam engines, even though these have largely disappeared from the railways, and the old rotary telephone is still the icon for it. I don't think updating the symbol as icons get updated is a good idea. Icons are symbols that have a meaning, in exactly the same way that keyboard sequences and menu positions are. These have become standardised (the old q-edit sequence is 'esc,q,q', or some of the IBM programs, which MSD follows, is 'F3'.
I find the algebraic easier to read, but when i evaluate it, it's in RPN order. Note that an algebraic calculator can have many pending operators, that when one presses a key, one might effect a number of pending operators. Also, one never gets the chance to check the local operators as they fall.
Ten lines of GWBASIC implement the control logic. Exactly what one puts into the stack and what operators and functions are defined elsewhere. One could have 8*8 matricies there :)
On the other hand, writing an RPN code allows one to jimmy together special routines that do one thing, or allow you to write your own functions, and then use an RPN calculator to parse lines. Eg you could produce a document that does calculations like a giant batch file, and produce polished output. Done this often enough.
Because RPN functions expect the same number of functions, ADD will find its arguements already in the stack, and change the stack to a predictable state.
In terms of assembler language, it's pretty much the same, i imagine.
In RPN, the arguements exist before the function occurs, and there is no need for precidence. That is, "+" or "SIN" finds the arguments pre-existing.
Also, in PASCAL, the way the code is loaded, the program *expects* called subroutines to be loaded in the order from deepest to shallowest: that is, the main() is the last loaded routine. Don Knuth's "literate programming" got around that, but it's a perfectly natural way to think.
Here's how i do (A+B-C)*(D+E) in my head.
get number A
get number B
add
get number C
subtract
get number D
get number E
add
multiply
Here's how i do it on an RPN
input A
input B
add
input C
subtract
input D
input E
add
multiply
Hey - a match.
Actually, i have 10 lines of GWBASIC that implement the control logic of an RPN calculator.
I hate the tinny quality on MP3's and prefer real music off a cdrom or vinyl.
The base directory describes the block.
Take for example software. There are two possible ways of sorting this: stuff from vendors and stuff by structure. I use both, but the majority of stuff gets stored in the vendor tree, and the minority under the opsys tree. So if i want a non-descript OS/2 utility for file management, i would look under opsys/os2/fileman/ while something from say file commander/2 [which i use a lot] is /vendor/fileman/harvard/os2/.
Personal stuff gets stored under the tdisk tree. These are grouped under broad catergories, eg 'maths', and then a date directory. eg: /tdisk/maths/nbfk/
The whole idea is if ye take a bucket-load of backup cdroms, ye should get a single tree that is easy to sort through.
*
* As part of the kernel evolution
towards modular naming, the
* functions malloc and mfree are being
renamed to rmalloc and rmfree
* Compatibility will be maintained by
the folowing assembler code:
* (also see mfree/rmfree below)
*/
Note the parent has "assembly" for "assembler" in the the line "the following assembler code:".
As a host who gets kids who come in to her room, and use symbol font, it's pretty straight forward to read this.
In three dimensions, we see a 2D cross-section, rather than the true 3D of it. And it's not a planar cross-section, but an angular one: ie we see whatever is occupying phi/theta than what's at a constant y.
Of course, the visualisation of 4D is the like of watching all bits of a movie projected into solid space or something: that is, ye see the wholeness of the figure, rather than some 3D slice.
The same is true of hyperbolic space. I have little trouble with some figures in 4D hyperbolic space, for example. The most common projections of hyperbolic space are the poincare disk and the klein disk. When i do sketches of what i see, i use either a cylinderical or orthographic projection, depending on whether i am moving or stationary.
Unlike watching a movie, it is more a case of creating the image to watch as ye do it. So while i can watch things in 4D in this manner, the plot of the story needs to be created in the mind, rather than watching someone else's impression of it.
5D and 6D are a bit harder, but can be done.
On the question of the 4D Klien bottle, I have seen pictures of it in 3D, and i can mentally crall over its surface, and i know there is a transformation of its surface into a square-shaped thing, but i am unable to make that topological transformation. But then, i am unable to make the transformation in 3D of turning a torus inside out.