Intro to the pure concept of programming-to-stimulate-clear-thinking
G15 PMN: clear thinking via expressing simple programming statements
By Aristo Tacoma
How to get a fast G15 PMN up in no time on ANY computer, try a virtual approach.
G15 PMN app page: norskesites.org/fic3/fic3inf3.htm has installation info, links, and also the Third Foundation G15 PMN which is the standard general-purpose set for advanced programming including FCM, which is a way to implement a bit of mind-like techniques into computing, also to steer robots, without the needless presumptions put into the socalled "artificial intelligence" type of quasi-scientific computer work.
G15 Intraplates Multiversity
Part one is EASY TO READ FOR ALL WHO ARE NEW TO PROGRAMMING.
The completing chapter has a discussion of numbers, infinity, the art concept
relative to numbers, and the degree to which the contribution of the logician
L E J Brouwer is meaningful when it comes to questions of infinity. This involves
using also the G15 PMN programming language to get to formalisms that can take you
beyond such questions as Kurt Goedel and others began to open up, in ways that go
beyond even the premises that Goedel operated with, and that touch on the supermodel
theory of the quantum phenomena. This is relevant for art and art students, but
also for philosophical musings in the future; and yet this is also, in its first
part, an introduction for beginners in programming. For more depth on Goedel
itself, connected to the G15 assembly level, see a text written somewhat earlier
which is found in a section of the 'fic3' page linked to above, which summarises
some important and relevant features of Goedel's work in a fairly readable way.
Next images: How the G15 PMN may look when performing on top of such as Ubuntu
(the <del> key switches between fullscreen mode, which is the usual,
and the in-a-frame mode; this is for the y6.zip verison of G15 PMN;
while in the y6all.zip case, the <del> key produces screencopies and
effects a pause). You also see here a mixture of the start-up of the B9edit
--"the benign editor"--which doesn't mess up your writing process by
hyperactive over-assisting things (for such makes writers dumb)--
with the matrix triangle screensaver program. The B9edit typewriter
editor, which this writer typically uses for all general writing,
short or long texts, is a fantastic tool for all young active people
writing using the English alphabet a..z and A..Z. Also, there's something
of the starting-screen of the G15 PMN GEM image editor here. G15 PMN has the
design focus on clarity and youthful esthetics also as inspired by,
and including, youthful healthy vibrant human anatomy. This is healthily
and positively embraced by the warm greentone, that is as black-and-white
only warmer in tone, and an adviced approach, after psychological studies
of brain activation and such, for working professionally on computers:
Background. To enjoy educating the mind, and keep on educating it, so that you can flourish as an artist, a creative thinker, a dancer, a free person in every sense of the word 'free', you need regularly to exercise the muscle of expressing thoughts in a language that is tailor-made for this purpose: expressing simple patterns, via a formalism that isn't full of stuff decided by industrial interests, but designed for the love of it--for the quality, fun and also meditation of clear thinking. So at least some formal things can be illustrated, some aspects as it were of your thinking, this way. Here is an introduction to G15 PMN, language designed by artist Aristo Tacoma, alias Stein R Weber, for just such purposes. Note that G15 PMN is unique in its being a pure design product--designed regardless, so to say, of which century of computing we're in, to fit the HUMAN PSYCHE and what is natural to express clear thoughts and dealing with meaningfully sized numbers, chiefly whole numbers (but also, by them, suitable elements of trigonometry and so on). Hardware can be designed to run G15 PMN in particular, or G15 PMN can be made to perform on top of computer hardware of other kinds given a layer that emulates the G15 CPU. The most advanced general-purpose set of higher-level functions and predefined (PD) functions for G15 PMN are in an app (a G15 app is easily inserted into the G15 PMN machine, and may contain data and/or programs for G15 PMN) what is called The Third Foundation, or TF. All that is there is compatible entirely with the core G15 PMN as here presented, because of this versionlessness.
The completing part of this intro is a part called "Strings, long strings, and infinitely longer strings". It has philosophical notes of value to those who seek to think more abstractly about infinity and going beyond machines altogether.
G15 PMN says: Hello world!
To start with G15 PMN, get a PC that can run it. Perhaps a PC with some sort of Linux. In Ubuntu 32-bit (or 64-bit, if you must), it is the y6.zip that runs best; in many Debian Linuxes, the y6all.zip is also good. Both are easily fetched from norskesites.org/fic3 which is the main G15 PMN source site. In Ubuntu 32-bit the command would be ./g15.sh once y6.zip is unzipped, after cd y6 into that folder, and the SDL 1.2 library is somehow in place (this is explained in the get-sdl.txt inside the .zip). The Avenuege.com/g15pc is a very long-term project of making a not-quite-micro CPU for G15, using our novel notion of 'intraplates', genuinely open hardware design without relying any too much on microscale predesigned chips.
Then, to get it to run the example, you can either put the text above into a card--which is the chief concept of how to relate to the disk, instead of the idea of 'file'--or you type it in direct.
Either way, you start up the main vehicle for working with G15 PMN, both programming and applications, by typing CAR and pressing lineshift several times. Click CTR-L and you can type i1 to open up card i1. Type in the above. Click CTR-S and type i1 to save it there. By the way, you can use TABulator to space out the stuff that fills up empty cards (socalled nilchars).
Then click HOME key and click CTR-W to switch into Menu mode. Click on the PMN, or you can go via side/utility menues and open up the High-powered PMN Terminal, which has lots of readybuilt programs in it-or the TF, the 3rd Foundation, that has twice that much again. Either way, once you are into it, you can compile what you put on the card, or type it in afresh, as this:
helloworld=
^Hello world!.
Or, to compile it from the i1 card, type
^i1
cc
The program is then compiled to the internal G15 form. This involves a kind of assembler-like language, made only of numbers, also called G15 Yoga6dorg Assembly. It is running as a 'virtual CPU' on top of Linux, but it is capable of being implemented in electronics directly.
To run the program that has been compiled (into something much like how Forth did it, a 'threaded' compilation), type in the name-all this has lots of similarities to how one can relate to languages such as Forth, and vaguely also Perl and Lisp, ec. The name in this case is:
helloworld
The result should be that the computer responds by the text you put into the program (after the ^ which is one way of quoting a short line), namely,
Hello world!
If the program didn't work, you go into the mode called 'program correction'. In the case where the program is on a card, type qu to quit the PMN terminal, and CTR-L to open up the card, and check its syntax, and store it by CTR-S, then repeat and try again, carefully.
The USE of a programming language like G15 PMN
With each decade--since, say, the 1960s--algorithms have been archived, systematized, made into libraries, and, in turn, collections of such libraries have been further systematized and bundled and organized, in higher and higher levels. While this has led to an ease with which computers can be tailor-made to fit with purposes that enable people to do things with them without any much training, it has also led to a certain degree of confusion about what computers really are and what programming, indeed, really is. Surely, if programming merely is handling gigantic libraries of ready-made programs, then the distinction between using a computer and programming a computer is more or less vanishing. And while the general usefulness of computers may have gone up, the lack of contact with the essential algorithms that drive the computer has led many of those who before would have learned 'raw' programming to have to spend time on learning to communicate with ready-made programming instead. And programming languages themselves have been made that reflect this rather second-hand relationship to the essential computing.
The programmer, or the person setting about to learn programming for the first time, or to learn a new programming language, perhaps one that is very different from earlier ones, must therefore think through priorities. Do you want to learn something of enduring value, that helps you to think, and to KNOW computers first-hand, and that leads you to real insights into how to make algorithms? Or is all you want to handle the computers of this year and maybe a couple of years into the future, at most, in terms of being able to steer through and configure the most-used and most-hyped and most-commercialised packages?
The use of G15 PMN, whatever the status of G15 PMN in society, in terms of education, is to learn something about computers in a first-hand way, and to sharpen own brain, own mind, own instincts about how to structure thoughts. In a context where other people are using G15 PMN-enabled PCs, this can also be practical, even commercially practical. But even if others aren't using such PCs, you yourself can continue to apply and extend and deepen your programming competence, and create something that works for you and your friends. This skill will be with you and G15 PMN is a finished product, defined in independence from the present status of computers, and will work in any context where there are computers above a certain minimum level of RAM size, speed, and so on. And, there are activities going on where this involves also the use of robotic extensions to G15 PMN-enabled PCs, so it can be practical in this sense, too {at some point}.
When you know how to make algorithms, how to structure data in terms of arrays and so on, you can employ this essential knowledge as a powerful competence whatever you do with computers afterwards, whether by means of G15 PMN or through some other vehicle of computer programming.
What is the grand unifying feature of all data structures in G15 PMN?
Programming languages may be similar when it comes to the simplest statements, but it is, usually, when data structures are to be defined, that they quickly branch out and become as varied as they can be. People talk in different ways--some are more declarative, others are more questioning and tentative. Some talk to direct how things should be, while others talk more so as to point out how things might be. And some people shift between modes. When it comes to creating a data structure, some programming languages want to be very actively part of your data structures. They have all sorts of predefined words, and sometimes these fit the needs we have, and at other times they are inconvenient, because our thinking have leapt lightyears ahead of what the designers of the programming language were thinking about.
In G15 PMN, the approach we take is that we want to encourage thinking, and we don't want to burden the programmer by knowing too many syntactical rules, too many predefined names. The computer is mostly about throwing numbers about. And so when we make a data structure, this is, whether the programming language conceals it or not, mostly about reserving some place in RAM, in the computer memory, for a bunch of numbers. Once you invite the programming language to participate in how you divide this bunch up, you will find that the programming language imposes itself in dealing with that bunch from that point on. In G15 PMN, your are encouraged to visualize arrays of numbers, and matrices of numbers, and to divide them up the way you like, the way that most fits with the program you are making.
In G15 PMN, the most easy way to reserve place for a bunch of numbers, whether they are thought of as a series of numbers, or as a matrix of numbers somehow, is by means of the quote. Yes, quote! For what is a quote? A quote, like the text Hello world! that a simple first program could print on the screen, is of course just a series of numbers, a number for H, a number for e, a number for l, the same number again for an additional l, then a number for o, and so on, all the way to the number for '!'. These are the socalled ASCII numbers. They constitute the English alphabet and the most usual extra stuff like dots (.) and commas (,) and even space ( ), and space is numbered 32, and it goes all the way to 126, with capital A being 65.
So, any quote is, in that sense, an array. The array may be huge, a million, or more, numbers. And so there is a predefined word, a two-letter word or symbol in the language, called 'SZ', short for size. When this is used, it is used with a number that tells how much RAM should be given to the NEXT quote that we invoke. And the next quote can even be an empty one, ie, one without any characters--assuming, then, that we somehow fill it up with suitable stuff later on in our program. In the case where we want a matrix for it, we can call on some of the simple ready-made algorithms (with longer names than just two letters, they are above the Pre-Defined or PD layer), which are preloaded when you start the PMN High-Powered Terminal by means of the utility menu, or otherwise copy and paste these routines into the start of your program. An even larger set of ready-made routines, the socalled 'Ultra-High-Powered' Terminal is what is in the beginning of the Calendar program on the Home Card of the G15 platform. And this is yet more extended into the full general-purpose set called 3rd Foundation PMN, which is on the App page for G15 PMN--all entirely the same G15 PMN core, just more expanded and documented. So these extra routines do a tiny bit of formatting, some initial structuring, we might say, of all the RAM that you have set aside to some work, and given a name, usually.
What you then do with the data structure is up to your programs. And, as I see it, that's how programming should be: the language is as it were a canvas upon which you paint; you are the one who comes with the structure, and the job of the programming language is to be as receptive as it can to your wishes. In that way, the PC is more a mirror of your thought processes and less something that distracts and interferes with your thought processes. And it is the belief that the long-term result of this is programs that actually are more robust, coherent, good, great and fun!
When you want to program loops in G15 PMN
A simple way to do it is by means of LL:nnn, where nnn is the number of repetitions you want. Then say what you want, and complete the loop with LO.
If you put the stuff into card i:1 as above, then the command ^i1 followed by (on the next line) the command 'cc' to compile it, is enough to start it and get the output as shown above.
In the example above--repeated after the output so it is easy to look at while also reading this text--you see that G15 PMN has two columns in each of its program cards. So the text above first defines the word 'nice'. You see that the full stop is really, really huge, so there is no doubt that it is there. You also see that the characters as displayed there--and they are automatically considered as lowercase in these cards, unless you press SHIFT and get a dot above and to the right of this so-called ROBOTFONT (for it is suitable for low-resolution LED-displays on robotic instruments also)--they are rich in contrast, and that's a GOOD thing for programmers. For instance, the 'i' is as different from 'l' and from the number '1' as it is just about possible to get while still having a resemblance to typical English letters. It is also an optimistic font--it's all pointing up, all over the place (except for the letter 'z', which has been mirrored, to reflect that it is last in the alphabet, and signifies typically a completion of something). Finally, let us also note that the letters of these cards are huge,--in fact, gigantic.
Now all this sums up to what a programmer will want to have when truly complicated programs are made, made out of hundreds or even thousands of cards. Each card must be not just half-way right, or two-thirds right, but totally right--in a way. This exactness can be tiresome. The large font, the conciseness of the PMN expressions, the optimism of the bright green and the upward-pointing features of the funny characters, and the clear-cut contrast between the tools that the programmer works with--namely, first and foremost, text and numbers--all this adds up to elegance and meditative flow of programming and ease of correction, generally speaking. Nevertheless, every complex programming process will have moments of confusion, no matter how the language is structured, and how the routines are displayed.
In any case, to return to description of the above: the first routine is called 'nice', and the second 'lotsnice'. Lotsnice is defined like this:
lotsnice=
ce
ll:23
nice
lo.
The line above is LL:23 in small letters, just so it is clear. Sometimes, in texts talking about G15 PMN, we write uppercase to accomodate the more typical book-print font; but always type programming statements with lowercase on the G15 PMN terminal and into the G15 Cards, when it comes to names of functions. In this text we use lowercase and sometimes uppercase. Since the number 1 look like a small L, l, the natural G15 PMN font, called the ROBOTFONT, or RBOTFNT, is rather different. It is made so as to accentuate differences between the characters, and also to work on small LED-displays on robots with great clarity.
So, the {menu} type of thing at bottom merely reflects what mode the card editor and performer, the CAR, was in when I took this screencopy. It also says that I work in card i:1. The {menu} becomes {edit} when the mouse is right-clicked. The {edit} becomes {menu} when CTR-W is pressed. To an artist, a smooth W looks like the metaphor of a girl's mouse.
The CE is Clear scrEen. If you omit it, the program will still work, but it will say YES! on the upper left to show that the program compiled in well enough. Finally, on the right column, at bottom, there is the zz type of statement. This tells the compiler that when compilation is done, then start the quoted function, in this case, the new function, or word, named lotsnice.
To print out the text in B9FONT, which we made {actually earlier on, when the main language form was called Firth234 then Lisa GJ2 FIC3, the 'fic3' still being the name of the language place, norskesites.org/fic3 with a mirror-site in one of the other sites in our Yoga6dorg search engine set of sites, run in the same language, which in this case is moscowsites.org/fic3), you can use the two-letter (predefined) function B9 instead of the function PP. Of course, there are more such functions to place the characters freely on the screen. And in each case, you have the source of these functions, written in the G15 native assembly-like language, and which it is natural to get to know a bit about as you progress in G15 PMN programming, for it vastly extends what you can do with PMN so that you can do anything which is within the scope of just that type of Personal Computer, the G15 PC, as we have imagined it and realized it.
Note that the 'zz' command is typically the very last line in any program that we compile and run, and that is isn't something used within a program. In other words, when we make a new word, a new function, a new program, by doing something like abcdefgh= then some lines then a dot (.), that's fine, but the 'zz' won't be found between the = and the dot. Rather, the zz stands on a line all by itself, and no dot comes after it.
When you have gone through this little example you have seen a great deal of all the main features of the language: and yet there is no end to how many books we can write about programming in it. But that concerns higher structures, techniques, approaches, methods, and getting used to using the libraries of ready-made functions, and such. Fundamentally, it always looks more or less like this type of stuff, though there are a few more features, such as how to handle long-quotes (quotes over several lines) and comments and such, that can be said to be part of the 'syntax' of the language.
Note that the command
^i1
cc
is enough to start the program when you include a 'zz'. If you leave out the zz, you can start it manually by typing in the name of the program. When you have a large program, with many functions or programs {or sub-programs} within it, and you want to check how a certain part of it works without starting the main part yet, you can leave out the zz on purpose; and perhaps put it in when the program is all polished and wonderful and ready to be published to the world, perhaps as a G15 app.
How to make a variable in G15 PMN
With most programming languages, it is possible to do something in more than one way. And some ways may be appearing to be 'tricks'. However, there is no need to view some ways of doing it as tricks if they work consistently. Whether something works in PMN you can find out (when you have gained some knowledge of the whole of G15) by looking into how PMN is defined. In fact, each time you start up a G15 PMN program by clicking on it at a menu, you start a swift process that JIT, Just In Time, compiles the whole of PMN in terms of its more essential G15 code. In this way, you can both inspect what goes on in PMN, and also extend PMN with new two-letter words, new Pre-Defined -- PD -- words!
Anyway, let's look into how to make a variable--in the most typical way, anyway. A number variable is the simplest and in a way, most essential example. Suppose you have a customer-list. How many customers are in the list? You may want a variable for that, and an initial value. Let us set it to 100. This could be how:
customers=
^.
100
customers
kl
Then let's find out how many customers we have at present:
customers
lk
nn
It will now say '100'.Note that 'lk' can be read as 'LooK'. The 'kl' is the reverse sequence. It could be interpreted as 'kill the earlier value, and put this one instead!'.Also, note that we use 'nn' to print a number while a quote would be shown by 'pp'. This is the way we do it in a PMN Terminal. When running a program using various graphical positions on the screen, we have several other possibilities.
{Note that the quote-mark ^ was used. The number variable is an empty quote, in a way. The number goes into the position of the PMN quote used to store the length of the quote.}
A bit of the philosophy of G15 PMN
Those who have the time may want to look into the description of Kurt Goedel's famous 'incompleteness' work, in particular how it is playfully described at the apps page of G15 PMN, in an essay. The norskesites.org/fic3 links to the apps page, and it has an essay section, where it should be easy to find. Put very simply, a computer is finite, and a program on it is finite, and a finite program will always be incomplete in infinitely many ways, as concern the 'perception' of things. This means that artificial intelligence in a general sense isn't possible: that was very clear to Alan Turing, who invented much of the computer concept exactly while trying to disprove Goedel, but instead of disproving Goedel, he only succeeded in strengthening the original proof.
Programming, if it is to stimulate mind, must have a bit of honesty about it. It mustn't try and convey to the human being who uses the program that it has a mind of its own.
Instead, programming, when consciously made, can stimulate to good use of the mind while also being practical and doing tasks that otherwise would be tiresome to carry out manually.
So, instead of 'simulating' mind, the approach we take in G15 PMN is to stimulate mind.
When it comes to handling tasks that require a bit of pattern matching, and perhaps occasional batch tasks of entraining new patterns, it is possible to do this in a way that honors Goedel's incompleteness work, and that, more importantly perhaps, in no way imply that we are giving the computer a real sense of mind. The concept that we invoke in G15 PMN in such cases is FCM: First-hand computerised mentality. This is not about simulating mind, but doing a bit of handling of fuzzy situations such as for instance robots may encounter, so that they have a context-specific set of tools that can handle this fuzziness. These involve that the programmer or programmers invest something of her own mentality into how the program is set up. It would be childish to call this 'artificial intelligence', of course.
More deeply, there are ways of looking at all the data that has come around since the time of Isaac Newton, including all the gravitation and all the quantum phenomena, and take this into consideration in a worldview that doesn't see life nor mind as machine-like. Mind calls on machines, but machines cannot capture minds. Mind is alive. A good session of programming with a good language like G15 PMN can stimulate our aliveness, and be practical, and/or fun, in terms of the resulting programs, as well.
This philosophy of relating to computers so that they stimulate mind is also called 'first-hand programming'. The reason we invented this concept, a long time ago, was to distinguish between programing of a kind that is merely a rather statistical manipulation of packages or masses of data that aren't clearly visualized, and programming that intensely invokes a sense of the exact algorithms and the exact data. G15 PMN is different in key ways from all programming languages made before it, but it can be seen having more in common with Forth by C Moore than most other languages: and Mr Moore clearly did want a language that stimulates mind, in how he designed Forth. However we go a bit further than Forth in thinking through the wide set of themes connection to doing 'stimulation, not simulation'. One of them means setting aside such as the much-hyped sort routine 'quicksort' because it is tainted with second-handedness and with a needless, time-consuming complexity when confronted with lists that are almost sorted already. 'Quicksort' presumes something about how a large list can be organized. We want to use mind in doing the organization of large list, then, as the large list is suitably ordered, the rest of the sublists are small enough that a much cleaner form of sort, the classical, pure, simple, noble 'bubblesort', can be used.
The use of cards rather than files in G15 PMN is similar to some of the earliest versions of Forth, but also different. What must be realized by programmers used to working with files in such a context as Linux is that these files are organized by means of a very advanced database, and they are nothing anywhere near 'essential' to how a computer works. So if such files are the starting-point, the programing language is already rather second-hand: for it doesn't really invoke a relationship to the computer directly, but presumes a giant indexing system along the lines of B+-trees and a whole set of predone programming. Similarly, any handling of parallelism by means of predefined structures such as found in many class/object/hierarchy languages of the type that also Java belongs to, is another type of second-handed-ness. To revert to assembly is not the best solution, for assembly--and perhaps never more than when we speak of Intel i386-derived assembly languages--distracts from focus on the programming process.
Much of the complexity of underlaying operating systems, while suitable for commercial interests, really takes away the sense of empowerment that a programming language is meant to come with relative to the mind of the young student.
The solution, again shared with original Forth, but also found in approaches taken by some of the more adventurous programming language makers such as the swiss N Wirth with his Pascal and Modula-II and Oberon, is to insist that the proper language goes all the way through to the 'bottom' of the PC, and that here isn't another 'operating system' than it. However if this is going to be meaningful to use, not just meaningful to program, we must find out what we can leave out of the definition of the computer. Here, too, we must ask: what is first-hand, and what stimulates; and what is merely a candy for the entertainment-seeking mind, and not essential for computer science and for essential, and mind-awakening, computer use. Do we really NEED video as part of the the computer definition? Do we NEED millions of colors? Or is this merely part of the consumer hype, and not essential--nor very beneficial to mind? For video is but high-speed shifting of images, perhaps with sound-output, aimed at producing nothing but an illusion. The reality is image. Also, playback of sounds isn't essential to what algorithmic programming is about: it is something that is intensely tied up to a clock-like process, whereas computer science and significant use of computers in general is a more timeless process. Further, the full range of stimulation, for most purposes, also entertainment, requires just one (uplifting) tonality, rather than R+G+B blended. Similarly we can focus on what a computer should have as meaningful limits in terms of speed and RAM and such, rather than being obsessed with moving these limits out of commercial greed or some kind of superstitous belief in 'technological evolution'.
In gathering such insights along the lines of a somewhat ascetically, moderately defined Personal Computer, we can then reach the definition of G15 PMN as the programming language par excellence, I think.
How to make some randomized filled rectangles in G15 PMN
Each time you run the program above, which fits on two cards--in the example, k:1 and k:2 are used--it will give a somewhat different set of rectangles on top of each other. Two graphical examples are shown.
So to start this program--to take that first, before explanation--you can either use the g:15 homepage and click on the arrow under the big PMN letters on upper left, where it says d%65000 (only that the '%' shows more like a flower, or twig, or hand, which is a way for us to indicate that we do not approve too much of the overly statistical notion of talking about percentage all the time, besides it looks much like 0/0 which is meaningless arithmetic in any case; we advice the use of the 'permille' concept of 1/1000 instead of percentage as 1/100 in order to facilitate broader thinking about numbers, and not stay in the habit of statistical thinking of the conventional type). Or, you can use the utility menu d:15. You come to this by clicking on the colon in the MORE>>>d:10 line on the homepage g15. (Remember that any use of the mouse during the viewing of cards should happen in the MENU mode. You switch the menu mode on by CTR-W; this is also to remind ourselves that we do not want to over-rely on graphical features to operate our platform, but consider somehow text more important than graphics, and keyboard more important than mouse, except when it is really, really useful.)
When you find the utility menu,--it is not the first one shown, but about the second one shown, after you click on the colon to right of MORE>>>--you see there that d:22000 has the High-powered PMN Terminal. This you can start by clicking on the symbol between d and 22000. This has a lot of preloaded functions (and, as said, there's still more in Third Foundation G15 PMN). AFTER you have run the program using THIS option, you can type F and then NN as in the screenimage above, and then it will show 123456. This is a way, in that terminal (but not in the PMN when started 'raw' on the homepage g15), to check that your use of the G15 PMN main stack (as it is called) was correct. More about this elsewhere.
In any case, how does it work? I'll give you some brief comments here.
First of all, rndsquare--a randomized square--does a bit of calculation. It is going to call on RT, the predefined word that wants x1, y1, x2, y2 and tone of bright green (from 0=black to 255=bright green) as input. The x1, y1 are the coordinates on the screen of the upper left corner. x1 is horisontal, from 0 to 1023. y1 is vertical, from 0 to 767. The x2, y2 is the bottom right corner. The screen is defined to have this size in G15 PMN as part of the tranquility of learning the art of thinking by means of a good language that works against a well-defined machine, rather than something that is changed. (Though in some robotic cases, the screen might be smaller.)
So you see 50 and then 50 goes to x1 and y1. These are 'put on the desktop', the heap or stack ther of numbers,--if you'd like to imagine it. Then 500 goes to AF--which gives you A Free number up to 500, by means of calculation over the milliseconds clock with some wild formula. It is not true random but then what is? 100 is then ADded to this. So that becomes x2, you follow? Whereas y2 is set to 500 all the time.
So, four numbers are on the stack: x1, y1, x2, y2. It remains, before RT is called to make a filled rectangle, to specify the tone, 0..255. Here, 155 AF is added to 100. That means it is never black, in this case. Then RT is shown. That completes one rectangle. The next card, K:2, just loops through this 500 times.
In the final line, just before the ZZ that tells the PMN what to start doing after compilation, the &..& is used. We could have used a hat ^ just before but this i an alternative, and in some cases, when you want to put a space in a quote, it is exactly the way to do it. We'll look at other ways to quote also, and how to add quotes.
The ^k1 followed by a lineshift, then cc followed by a lineshift, should be enough to start it. Then qu to go back to CAR, CTR-Q to quit CAR, and REB to exit the platform {or reboot the G15 PMN PC}.
On the Ease of Stacks
When you program a Personal Computer, then you are, as it were, installing a little extra machinery into it. And that is exactly what it is made for. The underlaying simplicity of the machine, and its flexibility, its capacity to store fresh impulses in its mechanical memory, its RAM {'random access memory', meaning that you can access any bit of it you'd like}, makes it an ideal framework for encouraging the art of thinking, stimulating to greater clarity, more structure. It can also be useful in practical tasks but it is important to realize that many human practical tasks have a complexity that goes beyond what we should try and put computers to. Driving cars is one example. Unless the driving happens in a closed tunnel with only one file and no other entities but the bus in the tunnel,--a totally well-defined context--then the complexities involved are so as to make it incorrect to apply the computer idea there. People can try it, of course; but it should be pretty obvious to one who applies both rationality and intuition, rational intellect and intuitive intellect, over some time, that computers shouldn't meddle in many human affairs, and they should be kept pretty much out of all decision-making where the conditions are fuzzy and floating and context-dependent.
So the personal computer is SIMPLE. That is part of its definition. If it isn't simple, how it can it be personal? So that is the PC idea as we see it in G15 works.
Part of the simplicity of thinking about how to program is that the PC does ONE THING AT A TIME. It can do some things like adding numbers or putting a pixel to the screen very fast compared to how we'd manually do it; and by shifting quickly between a number of tasks like that, back and forth, it can give a sense of doing things in parallel; but the point of the Personal Computer is that it has a possibility of being programmed to run clear-cut succinct, beautiful programs, also called 'algorithms'. These are step by step instructions; and even if there are some languages for PCs that have been made and that conceal this simple truth in pompeous ideas of 'objects' and 'activities' and such, or worse, with mind-like or human-like notions blended into the ideas, so that it is spoken of 'agents' or 'learning' (and THEY speak of it without quotes!), we must stick to this one-thing-at-a-time idea if we want to be faithful to the pure concept of the computer. It has a core, a heart in a sense, which is called CPU, Central Processing Unit. In the case of the G15 approach, this CPU can be run as it were on top of a broader, perhaps less elegantly defined computer, or as a CPU somehow wired together on its own premises, the G15 CPU. We'll look into how to program the G15 CPU for some advanced PMN programs elsewhere.
But for now, thing of this one-thing-at-time idea. This means that when we have a task that is composed of subtasks, and each has to have its own little numbers to arrange things, and we have a single series of numbers presented to them somehow, then we are led naturally to the beautiful notion of a number stack, a digital stack, The Stack.
So, let us imagine that in our house, there is one big desk. You are the boss. You call in somebody to do one task, and allow this person to use the desk while you watch over it. Then you order somebody else to come in ad use the same desk. You want each to clean up properly; you assume that they will, that they are responsible. But in some cases, the sequences of the tasks matter, for you want one person to build on the results of what another person did. And so, it is an advantage that there is one common desk. For one person's completed subtask will then leave the exact desired result that the next person employed to do the next subtask can pick up.
So, for instance, if you go into a PMN terminal, you can type in something like this to add two numbers, then multiply two different numbers, then add all this again, and print it out. Keep the numbers within the psychologically meaningful size of not exceeding something like 9 digits. That is to say, keep them within about 999,999,999,999. You can go up to plus minus 2 billion if you like, and still be within the definition of a solid good rugged socalled "32-bit" computer. {Longer numbers can be handled by special routines, though.}
So here is what you can type in, to start with, if you are learning about stacks. The overview over the inbuilt PDs, the PreDefined words in PMN is easily accessible within the G15 platform. AD is ADdition, SU is SUbstract, MM is multiply, MO is MOdulus (remainder of a whole number division), DI is whole number division. There are ways of treating numbers that can be understood to be fractional numbers, but again, a pure conceptual Personal Computer mustn't be cluttered with things that aren't clean-cut digital in its core design. Still, we can do trigonometry and so on, to a fair and practical extent, as we see elsewhere. Anyhow! Try this--with or without the extra blank lines; it is a common feature between such typed-in programs, and programs run from cards, that you can have blank lines in between the statements. When you start a program from a card, it will keep compiling cards until it finds a card that starts with its socalled 'nilchar', which is the type of thing you see with cards that you haven't put anything on yet; you can copy such 'nilcard' from anywhere to anywhere by the CTR-commands that work within the CAR editor:
23
230
ad
55
5000
mm
ad
nn
How big is the stack? Big enough! But if you want thousands of things stored in RAM, use other ways--an array, or such. We look into that elsewhere in this tutorial. Another question: do you have to use the stack to communicate numbers or other things between functions? No, you can use such as variables as well. Named things. Also something we look into elsewhere.
Now, if you want to check that a function cleans up neatly after it, it is usualy enough that you start it up in the High-Powered PMN Terminal and type either 'nn' directly, or more normally this:
f
nn
The single-letter function 'f' means 'forge a copy', make the top number on the stack be there twice. So when 'nn' picks it up and shows it on the screen, it will still be there. The High-Powered PMN Terminal puts 123456 into the stack before it loads all its extra stuff. And so it is a convenient way to check that all is well with the PC that you type in the above, after trying out a new function on top of all that. Let us say here that all the functions you make yourself by means of the equal-sign = and completed by a dot (.) must have three letters or more. You can make more two-letter PD words at an advanced stage in your G15 PMN learning. If the word already has been defined, the FIRST definition applies. This is one of the things you must check. Try to type in the word you wish to define e.g. in the High-Powered terminal, and see if you get the typical question-marked message; if so, go ahead and define the word!
History of Programming Language Developments---
Algol, Fortran, Simula, Simula67, C++, Forth, C, etc,
and the idea of "warps" in G15 PMN
In the 1960s, computers the size of houses performed 8-bit and 16-bit tasks slowly, and they consumed electricity enough to power a huge factory. At this time, the most typical input and most typical output involved paper: paper with holes as input, and paper with weak character printed on them, in an extremely noisy process. The languages, insofar as they existed, had to be relatively compact and relatively well-defined. Most, like Fortran, were either very near the assembly-level, the machine code level, where one must think in terms of numbers much all the time; or else they were, like Algol, so fixed in their approach and so narrow that one couldn't get perhaps the full functionality of the computer out of them.
At this time, somebody who wanted to think big and abstractly, like Ole-Johan Dahl and Kristen Nygaard at the Norwegian 'Regnecentralen', an academic computer centre in Oslo, would normally use a narrow language like Algol; but they wanted to go beyond some of the limitations, without going nearer to the assembly level, and without making a Fortran-like language. As Nygaard much later (the late Nygaard was a friend of my father, Stein Braaten) told me, they had the source code for an Algol compiler and took that as a starting-point. Dahl was expert at digital computer thinking, while Nygaard had some grand visions of a language more suitable for thinking about living processes, in such as the behavioural sciences. Out of this grew the notion of 'activities' and 'processes' and an implementation of notions of being focussed on data as 'owners' of functions (rather than the other way around, as was typical with such as Algol, we might very roughly say). This was in 1965. In 1967, two years later, they had added hiearchies to this, that objects--as the processes were now called--could be derived from higher-level or more general objects, now called 'classes'. The first version was called Simula, the second was Simula67. This language didn't become all that dominant outside of Norway, but it found its way into some academic computers and a version of the Simular compiler inspired Bjarne Stroestrup to create C++ as a development of C. The snowball started rolling, we got object orientated programming languages, as they were called, in variations of Lisp, in the new 'purer' language Smalltalk, and so on and so forth, to the varieties in terms of thousands of languages including also such as Java and Python. But astute thinkers on programming, such as Larry Wall with his Perl, recognised that there are other ways of getting the same effects as socalled "object orientation" promises, and some of these ways are better, at least in some circumstances. It is the conscious (and wise) decision of Larry Wall that Perl has objects as option without making it compulsory; obviously, Perl is a much better language than such as Java. Then, G15 PMN has something that Perl and many other languages can't have: pure simplicity in design, artistic joy in the beauty of its syntax: because it is designed to honor pure thinking rather than, as e.g. the case with Perl, to be 'practical'. G15 PMN is also practical but it chooses beauty before praxsis when it has to decide.
Of course, Nygaard and Dahl, who got the socalled Turing Prize for their work around year 2000 (some years before both died, Dahl after longtime illness, and Nygaard of sudden illness) had to be proud over the influence of their work. But Nygaard wasn't entirely convinced it had developed the right way. He had experimented, together with some people in Denmark and elsewhere, with new structures, in a language called Beta; and he also talked of invoking the theatre metaphor for yet new thinking about languages. He also found some interest, it seemed to me, in my suggestion that the notion of hierarchy couldn't really be employed so widely as object oriented languages typically want it to be employed--I described some of my meetings with David Bohm to him, and we discussed some possibilities for a while.
The point I wished to make is that the idea of making something better than Algol, with somewhat more exotic data structures, did make sense IN THE CONTEXT of the 1960s. What I say now, with full strength, but which a natural modesty prevented me from saying that direct face-to-face with Nygaard, is that object oriented languages haven't got any much point anymore: they have become a way to hide the computer structure from the programmer, and there are other, and better ways, of getting the more exotic data structures we want.
Very quietly, alongside Algol with its narrow pathways--which also developed into the much more beautiful Pascal by N Wirth--and the C language, as a structured form of assembly and little more to begin with--was Chuck Moore developing Forth at the same time, to have an easy time both interacting with a computer and programming it, while also doing such as control large telescopes; and all this on generally even smaller computers than those typically set up to have the big compilers. The point about objects--as they are called--is that these are data that own, possess, or point to actions. This couldn't be done in Algol with any ease, nor in early type Pascal. Because these languages didn't allow a function to be pointed to. The function could only be called by means of knowing its name, at the time the program is typed in. In Simula, however, new possibilities opened up--however only such as was approved of by the language designers. In C and Forth--two very different languages--we found the same freedom as assembly programmers have when it comes to referring to a function not by name, but by position in RAM. This might seem to be a technical thing, perhaps: but when handled with proper attention and interest, it is a door-opener to fascinating ways of programming.
This fascination deserves a name. The name in C, as in Forth, is typically 'pointer'. In G15 PMN we have used the name we invoked for the earlier forms of our vaguely, or very vaguely Forth-like languages: a warp. A warp is something a flower does, when it grows a sudden new lovely bud and does so not entirely obviously, but by branching out. In scifi writing, warps, or hyperwarps, or hyperjumps, are of course the jumps across regions which, in Isaac Asimov's terms, in his Foundation, are "neither something nor nothing", and where travel happens "between two neighbouring instances of time", whether it concerns "a million miles, or as many lightyears". Some might say that this is too hot a concept for something like pointer. But we need something big to compete with 'classes' and 'objects' and 'inheritance': that's one point. Another point is that we need to remind ourselves of the great importance of handling these delicate things with care,--for they are dangerous unless done entirely right. A "pointer" doesn't call on attention in the same way as a warp does. A warp can cause the PC to stop if done wrong. But when handled right, warps can be fascinating elements providing fresh energy and new ways of programming--and, yes, by the way--all the things that Nygaard wanted to put into a language can come by means of these structures, except perhaps the pre-defined control of them.
The reason I think we shouldn't have a pre-defined control of how these pointers, or warps, should be handled is that a programming language should be as much as possible a canvas, as I've said before, rather than imposing its own structure. Where things can work without it imposes its structure, then let it not impose its structure. In a way, G15 PMN has been designed with much the type of slogan in mind that J D Salinger one of his girl characters in his "Zoey and Frannie" have: that, when the poem has been made, the poet must "get off the page". Once the programming language works, the programming language designers must "get off the language". Leave it to itself. That even means its dominant libraries, for they are part of the meaning of the language.
And since G15 PMN is designed so as to foster clarity in thinking, and stimulate to the art of thinking, and also be a formal language that can work in all future, not just now, connected to a certain set of devices, it has been designed to work with what seems to be a meaningful ripe but not overgrown somewhat minimalistic Personal Computer idea that in all ages in the future can be realized. In this way, G15 PMN can be useful, indeed will be useful, however long into the future we gaze; while the present other computer languages can be hugely useful to control the technology of this year and maybe a couple of more years and then they must be updated at least in dominant libraries.
A bit of Boolean Logic, and Simplistic Keyboard Input
The nuts and bolts of personal computers are not just the idea of '1' and '0', one and zero, or 'pretty much electricity' (not that much actually, just a couple of volts or so) and 'very little electricity', but also how we combine these 1s and 0s, or 'bits', by means of so-called Boolean AND, and Boolean OR.
We say 'Boolean' (or 'boolean') to distinguish digital computer versions of AND and OR, and some more like NOT, from the far richer, deeper and more nuanced versions we operate with eg in English natural language, in writing, thinking, talking, reading, reasoning.
You might say to some friends--"Are we going to a pool, or to the real wild beach? But the beach will be an expedition!" Notice the word 'or'. It really means something exclusive in this case. The digital computer version of it would be, in this case, more XOR than OR. For the normal, much-used OR in dealing with bits is highly inclusive.
We call these things 'boolean' to honor a philosopher, George Boole, who worked out some of these notions in the middle of the 19th century, in England; although of course people had been musing about these things in various parts of the world ever since the beginning of thought, more or less.
Well, there's a lot more to these themes; but let's get on with our example program. For now, the key point is this: a digital computer offers you a way to check whether one or both bits are 1, by its Boolean OR. In G15 PMN, this is, conveniently enough, a two-letter predefined word, OR (we write it in this text by capital letters, although when you type it in, it's important to avoid using the capital form, although the ROBOTFONT always look rather capital {a bit like russian letters in this sense}.
So the OR fetches the two upmost numbers on stack, assuming that they are either 0 or 1. In other programming languages, it may be other values to represent the 'yes' or 'no', the 'true' or 'false', but this is a simple rugged good classical way of doing it that really works quite well, and which is intuitively entirely easy. So OR produces 1 when both are 1 as input to it, or at least 1. Otherwise, with both 0, it produces 0. These boolean operators, as they are also called, typically presume that you only feed them with 1 or 0. {Elsewhere, we look into N? and YE, which elegantly also handle other numbers than 1 and 0 so that they can be inputted into functions expecting only a zero or a one.}
In contrast, the Boolean AND--we just write "AN" in G15 PMN--is more demanding. It gives a yeah, a 1, only when BOTH are 1.
All this is fine, but what can we do with it? Well, we need to have some sort of action that is dependent on 1s and on 0s,--conditioned, we might say, by these bits. We want gates, in a way, that open given a certain condition. So you can see the meaning of the term 'conditional expression' and also, as used in electronics, 'digital gates' or 'boolean gates'. In terms of electronics, we are speaking of how such as the little components called 'transistors', made of metals that aren't quite electricity-conducting metals but halfway so--semi-conductors, we call them--and germanium and silicium are the two most well-known examples: these transistors can be used pretty much to handle what in programming languages are 'conditional expressions', ie, expressions, or statements, or commands, that perform given a certain boolean input, but not with other types of boolean input. All these long words! But our example is very easy. Let's go straight at it. The word we need, though, to act on the 1s and 0s to get a variation, in this case, is "SE". You can easily think of it as an abbreviation of the word "see". It can be thought of this way: 'Have a look at the input. Is it 1, then do what's on the next line. If not, just skip the next line.'
Turning now to the program, we this time use disk F, cards F1, F2 and so on. An example output is shown first. What I typed isn't shown, because the program doesn't have an instruction to show what's typed. But I typed 1 and 1, then I typed 1 and 0, and finally 0 and 0. The outputs are different in each case. After the two first runs, I typed F and NN also, to check that the stack, the desk you know, has good paper-order! And it does, since 123456 is produced. This result came about by using the High-powered PMN Terminal. If you use the elementary form of G15 PMN without all the extra predefined words and all the extra high-level functions, or subprograms, in the High-Powered programs, just skip the F and NN part, for it doesn't have 123456 lying on the desk, on the stack, as a standard. But both can run these cards, for they are programmed using only elementary G15 PMN words.
Now, if you do a lot of work with putting stuff to cards, you may want to check that the next card after the final card is properly empty: so that the G15 PMN compiler knows where to stop, and when to start your program. So here we have included a screencopy of what a socalled "nilcard" looks like. It has Ascii values 0 all over the place. This you can check, if you like, by going into the {MENU} mode, by CTR-W, and then clicking with the mouse on the folder-like symbols. Still in this mode, you can do PgUp and PgDn or CTR-L to another card, and you can click on various numbers and letters and learn something of their inner values, their ASCII values. You will also see, if you click on the digit 0, that it shows that it has value 48. In addition to the ASCII value, you will also get the 'coordinate' of the character you clicked on, namely what position on the line, and which of the 8 lines, in the large ROBOTFONT cards in the CAR editor in G15 PMN. This is a graphical approach to presenting stuff that evolved naturally together with the G15 CPU concept and the PMN programming approach. Let me also say that CTR-R brings you to the middle of the card, where the second column begins. Pressing CTR-R also allows you to test if you are using slim enough columns. G15 PMN is very strict about this: the words must be short, they must fit within these narrow columns; and then we read the columns vertically; but we have two of them, and so both sides, in a way, of the brain, have some stimulation in this. Also, the slenderness tends to suggest elegant shapes.
Anyway, if the next card after the final card you have filled in with a new program isn't the nilcard, you can just copy the nilcard from somewhere else. For instance, go to K:1000 or L:1 or anywhere where there is a nilcard. Press CTR-C to copy it, and press lineshift or ENTER or what you call it. Then do CTR-L to open the F5 card that you want emptied. Press CTR-T to put it there, and press space to confirm.
In the first card, which in our example is F1, but you can put it anywhere you like--of course, it is somewhat easier to make new programs where you have small-sized cardnumbers, rather than going into card-numbers involving many digits,--for you have to type them in all the time--that's part of the mind-stimulating process of programming in this way--anyway, in the first card, there are comments. These are preceeded by a vertical bar | at the first position in the column. It is a good norm also to have vertical bars right after the naming of a new function to tell what should be given to the function and what comes out of it, except where it is very obvious.
So at F1, we have two simple functions, or programs, or algorithms, or subprograms,--call them what you like--that simply gives some text on the screen.
In F2, we invoke a very simple form of keyboard input, one that has more advanced forms, such as KI, to handle also function-keys and that is part of the High-Powered PMN Terminal. This High-Powered stuff you can incorporate into the beginning of any program. It is the normal thing to do,--either this one, or the even more high-powered part that is at the start of the Calendar program on the home page G:15. The KK gets the ASCII value of what is typed. A space becomes 32, a capital A becomes 65, an 'a' becomes 97, and, what is significant in this case, the digit 1 gets the value 49 (0..9 has ASCII values 48..58). The operator or function, the PD, predefined word EQ, compares for equality, and produces a 1 when the two numbers it fetched from the stack are equal, otherwise a 0. So this function outputs 1 or 0, after having a wait for keyboard input. Anything typed of letters and so on will give a 0 as output, in this case. Typing 1 gives 1.
In F3, we call on this routine, the CHKINPUTFOR1, twice. We store the results in some very useful locations. We use S1 and S2 to store in location I1 and I2. What is beautiful about these so-called local variables, of which you have twenty automatically for each function, is that they don't affect the variables of other functions, as a general rule. They are like private folders or mini-desks for each function. The ease with which this can be done, in with as speedy and computationally effective results as in this case, is rare amongst programming languages; and the way done it here is not something we've seen elsewhere. You can say T1 and T2 instead of S1 and S2 but then the output is by means of using J1 and J2 instead of I1 and I2.
So, in F4, we apply what we know about OR and AN: we get the PMN to say that 'at least one is 1' when the OR outputs a 1, and we get the PMN to say that 'all are 1' when the AN outputs 1. The SE sees to this selection, it reads the output of the OR or AN just before it--it expects a 0 or 1 on the stack. What follows after SE--and there are some others also, but this one is eminently useful--you should have a simple function call, not a quote or number or something like that. The line doesn't have to follow right after SE, by the way--you can have several blank lines after it. It is often a good practise to put a blank line in before and after a SE, when there is otherwise room, because any such conditional action is such a critical point in a program that it deserves maximal attention. Nevertheless, the exception to the rule that proves the rule, in the final column on the right side of F:4 we don't have these extra blank lines. This is because we wanted to fit in the ZZ part, that tells how the program should start up.
When you compile it, by typing ^F1 and, on the next line, CC, in the High-Powered PMN Terminal in the utility menu, then you can type TRYIT again and again until you're satisfied your program works well, then QU to get back to CAR editor, CTR-Q to exit CAR, and REB to reboot the G15 PC. Whenever you have done any changes to cards, this is a way to flush the conctent to the disk, so that, if your program causes the platform to somehow stop, you still have saved your works. Programmers should do REB all the time, to refresh the whole lot. Remember that the CAR editor is written in G15, and so if your program runs into doing lots of funny changes of RAM, it can change the CAR editor temporarily: that's why the use of REB is such a key-thing while we program much. And don't worry if the computer stops when you program. As a rule, the errors with the most drastic effects are the easiest to fix!
Getting Into Working With Warps {Also Called Pointers}, and Arrays
When you want to call a function not by name, but by its position in RAM, you do so by what conventionally was called 'pointer' but which we always call 'warp' or 'warp address' or such. There's a bunch of cards connected to this little text, but most of them are composed of texts, and there is really deliciously little to explain about them.
The first point is that the cards, L1 to L12, this time HAVE to be performed in something like the High-Powered PMN Terminal rather than in the basic, most elementary PMN Terminal. So the utility menu you can come to by clicking at the colons in the Home Page and onwards, called D:15, has this High-Powered stuff, and it lists it as existing at D22000. That means that you can look into the source there when you want to. The source of the high-powered stuff has two parts: the first has all the PDs and such, and then, at the card number that D22000 tells you rather clearly, the PMN code itself begins--that's well over a thousand cards above D22000, by the way. So we're into D23000 something. There, at some point, is defined a very useful little function called ISWITHIN. It tells you 1 if a number is within a range set by two other numbers, and 0 if otherwise. This, as well as some predefined functions that handle warps, come in handedly when we do our little work with this program. By the way, if you want to wrap up a program so that you can start it with just one click, without having to first load in a terminal, you simply copy the cards of the terminal, append your own program, and be sure that you remove any traces of a 'ZZ' at the completion of the part you pasted in just before your program. In that way, you can also set up apps and the like.
If you wish to type in this program, when you see two similar cards after one another, you might as well do a CTR-C and copy it, and then a CTR-T followed by Space after you have done PgDn to next card. You can start by modifying the card just before the homecard, which you come to by clicking button then PgUp, and this is of course the G:14 card. G14, then, you can put in e.g. L:1 and a text, namely that this is a warp-example program. Then, why not also type in D%22000, so you get a pointer to the High-Powered PMN Terminal, and can start it straight from this very easily accessible page. So you save the G14 by CTR-S, then activate the mouse by CTR-W, and you can go to L1 quickly, then back to it, then to the High-Powered PMN Terminal, back and forth, until you get it to work. And do REB each time you have done an important change to disk and are out to set your foot in a new place!
So all cards from L1 to L4 are just very easy text functions, making it easier to write small, neat, compact, beautiful functions further on. You won't need all that many comments inside a function when the names of the functions themselves work as comments. However see that the predefined function FF is used. This locates a function--and produces a number, when the function quoted (three letters or more) is found. The number it produces is, indeed, the much-wanted warp. These warps can be gathered up, put in an array, and later used to perform functions without having to again refer to them by name. The function used to perform these at that time is PF. {You can use a text-search as part of High-Powered PMN Terminal to locate comments inside the programming of these functions, when you are getting really into G15 PMN work. It takes a little bit to get used to how to do it, for instance you would search on "pf:" not just "pf", or use some other trick to enhance exactness of the search; and the comments may be a bit tight and obscure sometimes, and then it is better to search for uses of a function inside a program that is more readable.}
At L5 there is a funny one: goldpath= &12345&. What's all that? It is an example of a very short array. For any longer array than a dozen numbers or so, you do it in different ways. But since the G15 PMN language is dedicated through and through to 32-bit, it means that even though &12345& is a text-quote, it can handle MUCH more than just letters and digits there {although, to be precise, you can also pack stuff to 8-bit format; that's an advanced topic}. In each position of this little quote, you can put a whole big vast number up to a billion and more. And the warp addresses, or warps, are just such numbers. We are going to have a program where we let the human interactor--you, presumably--tell what's supposed to be in that array, from a list of three alternatives, for how to proceed from where one is to get a gold treasure. You type in a sequence of 5 digits, such as 3, 2, 3, 1, 3 and the program will change this array each time. Significantly, it will convert each digit you type to a full-fledged warp. We don't have to look at these warp-numbers, they are usually very huge and may vary between one G15 platform and another, or even within two compilations of the same program on the same computer. We just want them to be right within the context of each run.
Then there's more text stuff, as known--using B9 or PP to put text to the screen, and using the &..& quote style, or the ^-style. Please note that since the dot (.) is such a highly significant symbol in G15 PMN, it should never be used at the completion of a comment, for it would look like a signal that the function is done at that point, and it may lead to funny messages if these dots are put there without attention to them. Also, always stick to the &..& stuff rather than the ^.. stuff when there's a dot in the line you wish to quote; or use the other quote-type, for quotes over several lines {talked about elsewhere}.
At L6, we also find the 'SH'. It comes after the KK. So KK reads anything pressed on the keyboard, but in this case, we just wanted to tell the human user something, then wait for a lineshift or such, and then drop it, shuck it. So SH shucks it, throws the number on top of stack.
At L7, we see how a function can be very nicely commented by a line with In or Input or something, and then a line with Gives or something, to tell what comes out of it. This expects a number from 1..3 but the function tells of itself, in the comments in L7, that 'wild' numbers are okay--that is to say, this one checks that the input is right or not. If not, it has quiet, well-thought ways of handling with the 'wildness'. The number is stored in I1, or we should write i1 for clarity in this text, by means of S1. As output of the function is the warp.
In the next card, L8, we see that ISWITHIN is used to check whether i1 is in 1..3. Then the N? is used. This converts 0 to 1 and 1 to 0. It means, of course, "No?" -- and it is the Boolean NOT.
So, in L8, there is a check as to whether i1 is 1 OR whether it is outside of range: when anyone of these conditions are satisified, the function RIGHTWARP is called. This one produces the warp of the function that talks about 'taking the next path to the right'.
Note how easy it is to divide up thought into modules so that each module, or card, can be given attention to all on its own. This is the type of thing that makes programming more a relaxing, graceful task, and less a thing that leads to stress in mind or body.
At L9, it is just a simple check on whether i1 is 2 or 3, and the other warps are chosen then. Having made simple short functions earlier on makes it easy to implement this type of mechanism. There are other ways of doing this, but here the emphasis is clarity, that it looks easy enough, relatively speaking.
In L10, you see that the comment indicates that SETPATH wants two things as input, not just one: it wants part#, and it also wants--on top of stack, as it says--the path, which is 1-3. The first number is 1-5, and the second is 1-3, but wild numbers okay. Note that this is the usual way of writing about inputs to a function, and outputs also: the last thing mentioned is on top of the stack. That's also why the stack is sometimes called LIFO, Last In, First Out. For that number which is put to it last, is on top of it. It is first taken off it.
And indeed, GETPATHWARP is used at once, without further ado. Assuming, then, that GETPATHWARP has done its work and it is now a proper good warp on the stack, we need to shuffle the stack a bit, so as to get things right. For we going to store things in the little array we defined, named GOLDPATH. For this we use the predefined word YA, and to get things off the array again we can use AY {YA/AY, same letters, opposite sequence, in parallel to KL/LK, which is used to put stuff and get stuff from single variables, rather than arrays, as here}.
So W is a single letter function like F, but whereas F forges a duplicate of what is on top of stack, W sWitches it around. There are three such one--letter predefined functions of vital importance in all essential stack use: F, W and D. F duplicates. W switches. D doubles the second number, copies it over to the top.
The YA function wants the array on top of the stack. Just before that, it wants the position in the stack. Just before that again, it wants the value. So you see that W is needed to put it in right sequence. We could also have put it to i1, i2, i3 or the like first, but this was the shortest way, and understandable enough, in this context.
Note that when we progress in thinking about the program from L1 to L10 we have never anticipated a function very much; rather, we go from one definition to the next, using only PREVIOUS definitions. In addition, we take care not to define things that may already have been defined in the High-Powered PMN Terminal, when that is the context within which we run this PMN program. In the TF, the Third Foundation, there is a new function EXISTS that funnily and quickly checks for the existence of a function, and, in addition, the SCAN program has been made part of the standard set of tools, and a new SHOWCARS function, so that you can quickly both scan and look up source code while not leaving the G15 PMN Terminal.
Having made a suitable number of small essential functions, we wrap it up in L11 and L12 rather elegantly.
In L11, we have a loop--it begins with LL:5 and completes with LO. It gives some text first, and cleanses screen by CE after it. It calls on SETPATH. Note that it has a keyboard-reading word in it, KI {which is a more general word, typically used in the High-Powered PMN Terminal; however note that if you use the keyboard numbers very extensively, there are side-implementions of G15 PMN in which the KI may give a different number for a few keys--notably for the so-called "dos" version of G15 PMN}.
After KI reads a digit from the keyboard, 48 is substracted from the number, the PD 'SU' does this. This is the ASCII thing again. 0 has ASCII value 48, 1 49, 2 50, and so on for the digits. So substracting 48 is done when we access the keyboard in this way. There are other ways of getting numbers from keyboards, especially if we call on the High-Powered PMN Terminal extensions, as we talk about elsewhere.
In L12, we use AY rather than YA to get the warp out. The AY expects the position in the array to be told, then, on top of stack, the array itself should be indicated--in this case, GOLDPATH. {Note that for longer arrays, it is often convenient to store the place of them in a variable, in which case not just the name of variable pointing to the array is given, but also the command LK to fetch that place, --also called warp, even though it's just an array}.
Having got the warp on stack, we finally do a PF on it. This happens five times.
Experiment with the program. You see that in a way, as a human interactor with the program, you are somehow changing the program, not just filling an array with 1, 2, 3, 4, and 5, but filling it with direct commands, where in RAM to warp to. The whole process of working with warps has in it the fullness of fun and responsibility, as well, as assembly programming can sometimes give, at its best; and in addition, it gives you a direct sense of relating to the computer. Finally, it can be intensely useful, you can have variables, arrays, matrices, with a lot of stuff in them, and these can themselves hold the functions that are supposed to go along with these objects, or what we call them. If you like, you can derive some new objects from earlier ones, by this: so warps are the power--features of that which is also called 'objects' in 'object-oriented' proramming, but they are far more flexible, less rigid, less hierarchical, and much more fun.
A Simple Warp-Driven Screensaver
Warps are fun, and they are easy, and powerful tools in the hand of the free-thinking programmer. We're going to see how much variation can be achieved with just a few cards, a few simple functions, using warps.
But first a series of paragraphs with more general comments.
When we program, we are not merely playing a game: we are expressing thoughts, and watching the structure of these thoughts when clothed in the shape of a formal language, and getting feedback from the millions of tiny electronical components as to what this structure really implies; what is within our thoughts--formally speaking--is spelled out. Or it is, at least, a formal illustration of a little part of our thoughts. And so this is a dialogue in the mind, that sharps the mind, and that calls on the machinery for this dialogue to take on ever-new heights.
But in order to have a dialogue with ourselves, engaging a machine, the machine must be well-defined; ie, it must have constraints.
The range of the standard full whole greentone screen as defined for all G15 PCs is 1024 pixels horisontally times 768 pixels vertically.
It is good practise to avoid pushing things all the way to the limits,--the X coordinate being max 1023 or so, is here typically set to 1000 or less. Especially when text is output, as it eats up pixels as it goes to the right.
The sequence, by the way, to give coordinates of the screen is, in an almost universal standard, X first then Y. Horisontal first, then Vertical. X is before Y in the alphabet, and H is before V also. So the position on the line of pixels is first, and then which line of pixels, vertically, is indicated. Good to repeat and memorize this sequence; makes things easier!
Why 1024*768? Because professional psychological stimuli is achieved by a squarish format of that kind. The widescreen is more inviting of distractions on the side of the screen; suitable for commercial ads, but not so much for professional work of many types. If you need all that much info on the computers simultaneously radiated into the room, have several computers beside one another. Better that, than stuffing it all into one computer.
The number 1024 is one that we learn to recognise when we program much: double 2 many times and you come to it.
The number 768 is three-fourths of it. So the 4:3 screen, or 3:4 screen, a bit wider than tall, is 1024 times 768. It was the original design of the IBM PC in the 1980s to have this format, and this was greentone for all professional works with texts: many psychological studies showed that the interaction between black and bright green is particularly conducive to good work. Of course, there wasn't all that much graphics variations at that time, and the PCs were very slow compared to what is the G15 PC assumptions. G15 PC is fast, but sticks to greentone, numbered 0..255, but with, in practise, only 64 greentone-steps assumed within this range, as this is enough to produce extremely beautiful renderings of photos of girls, waves, flowers, anything.
You see also that the G15 platform is full of a focus on the optimistic, the young, and that which gathers the coherence of your mind. It is a youth-oriented approach, and it has preteen, teen, and postteen fashionable beauty faces, and some sections of it has got it going a bit wilder.
In some cases, by the way, you want functions that are found eg in the Triangle Screensaver, in the large G15 GEM application, or somewhere else. You'll learn to find your way to these by using the Scan supplemental program at E99 {started within the G15 PMN High-Powered Terminal} on the beginning of the code in each case.
For instance, to draw a rectangle that is composed of four lines instead of a filled rectangle, you can use the simple routine in G15 GEM called SQUARISH, which calls on the draw-rectangle routine RT four times, but each time so that the filled ractangle is slim as a line.
Or, to draw triangles, you can use, and modify if you like, such as the Triangle screensaver {on top of the first utility menu page}. This uses trigonometric functions in a whole-number way to create filled triangles. Filled triangles, when drawn this way, hints of 3D, and indeed it is a quick pathway from filled triangles to emulating 3D. However we advice that unless it is of vital necessity, stick to things that are more elementary and near the flat square screen with its pixels and its essential elementary altogether clear and natural and obvious drawing algorithms.
Now, for the screensaver, as shown in the few cards starting with i:1, as displayed.
In the first cards, ACTION1 to ACTION7 are defined. These use only very simple, mechanical, squarely simple output routines, like RT, BX, RP and PX, and such. These make filled rectangles, or put text anywhere on the screen--BX in B9font, for instance,--while PX put a single pixel on the screen anywhere. Their input, in many cases, are by means of AF.
So AF picks a relatively free fluctuation generated number, also called a RFFG number, or, in more imprecise speech, a 'random' number.
Then the simplest form of a very short array is defined. It is called WARPARRAY. It can have any (meaningful) name of course.
By FF each of the ACTION1 to ACTION7 are located, in terms of the addresses in RAM, their warps.
Finally, a number between 1 and 7 is created by AF and AY gets the warp out of the array and PF performs it.
It remains to create the SCREENSAVER function: it has just two calls, and the second is RE, which jumps up one line and does the stuff again until any key is pressed on the keyboard.
Introduction to Matrixes in G15 PMN
When we work with arrays of numbers, we are working with something that fits eminently well with how the RAM, the memory of the PC, is laid out--series after series of numbers. A text document, for instance, is typically stored inside the editor in an array. But then, we could structure it so that we store it in some other way: for instance, line by line, as an array of lines, --which is to say, as a matrix. A matrix has both row and columns. That's the simple, rather intuitive idea we employ in programming. When we speak of a '2D' matrix, in contrast to such as a '4D' matrix, we speak of how many coordinates--row and column are two coordinates--that are required to identify a single element in the matrix. So, in a 4D matrix, we need to specify four numbers. Albert Einstein, inspired by his russian math teacher Minkowsky, fancied working with X, Y and Z in space, and T as well (or t), for time. Other physicists have challenged this simplistic way of dealing with time, considering that the whole picture is more entwined and complicated--e.g. David Bohm, with his Implicate Order idea.
In terms of programming, a lot of attempts to make computers and their outputs in various forms get the label '3D'. However, a 2D matrix is often a far more useful concept than any such thing as a 3D simulation. For with each added coordinate, the amount of RAM required increases exponentially. That also means that the consumption of electricity, silicon--and money--increases exponentially, and it also looses touch with the underlaying simplicity that we want in good programming. The art of stimulating to thinking requires that we avoid fancy, glossy additions that are mere tacky things to attract the masses, and rather go for elementary features of that which really work, and does so with a respect for the importance of being somewhat conservative in how many algorithms we have to employ, and how much RAM also, and what speed of the CPU.
In addition, a 2D matrix is as radically different from an array as a triangle is from a line: for by a 2D matrix, you can express spatial relationships, just as a triangle spans a space in 2D that can be filled, and related to, and which can express symbolic relationships. So by a 2D matrix concept, you can in some sense conquer all the dimensions--for instance, by having each node in a 2D matrix potentially linking to another 2D matrix. Still, a 2D matrix can technically be seen as merely a way of relating to an array. And indeed, this is how we typically do it in G15 PMN. So, the first thing to know about, in order to make a real good matrix--for instance to represent pixels or squares on the screen, out of which we can build symbolic representations of robots in a game-like environment (as we in connection to the Third Foundation, the part of it called "FCM", which is a distinctly non-AI approach to robotics, developed and refined further in the FCM apps building on the TF)--we need to know how to make a sizable array, a big array. If you recall, really small arrays we can make like this:
miniarray=
&1234567&.
This we can put values into by YA and get values out of by AY. An array requires just one 'coordinate'--the number of the position. For instance, if we make a calendar, we can store the dates of the month for the next seven days in such a little array. Each of the seven position can admit to numbers up to about 2 billion, which is the 32-bit range. Also signed 2 billion. The 32-bit range is psychologically pleasant to work with for the programmer. They are easy to think with, especially when they don't have much more than some or six or seven digits. Psychologically, many studies have shown that the attention span, in some sense, is "seven plus minus 2 things". These "things" can be more abstract, like groups, with training. In the 32-bit range, numbers can easily go up to 9 digits. When we program in G15 PMN, it may make sense to put cards e.g. at such ranges as allow numbers to be fairly small, say, using disk i or so, at cards from 1 up to some thousands--and these pleasant numbers convey something to you as you work with them. They are not just numbers, but they also have inherent pictures, ideas, features--including the peculiarity of prime numbers--where such as 23 is a prime number, but 22 and 24 are composed of smaller prime numbers. Prime numbers are arrythmic, we might say: for they aren't speedily produced by any simple rote procedure [the word 'rote' is defined to mean 'repetition without understanding', and it summarises, of course, excellently what computers are all about!], at least if we speak in terms of practicalities, when they get really big: the biggest computers wouldn't get through to more than so and so many prime numbers even if they worked on making a list for a hundred years.
Now a larger array we can make in some more steps. First we give it the name. Then we make use of the SZ predefined (PD) word in G15 PMN. This allows us to say: the next quote that we make will have the SiZe capacity as specified--which can go into the millions, if we like. Then we make the quote. This is, for empty quotes, simply done by the statement &&. Finally, we put the pointer, the warp to the quote, into the name we made. This we do by repeating the name and using the KL function. (Remember KL is to put stuff into variables, and LK is to LooK them up.) Let us call this 'bigbig':
bigbig=
^.
1000100
sz
&&
bigbig
kl
So, you see, 'bigbig' has now lots of stuff. A million and a hundred more. We have this array and we can do what we like with it, fill it up with numbers and get them out again, doing varying things--for instance, GEM Image Editor in G15 PMN Homecard has an extra PD that copies a portion of the screen to such an array, pixel by pixel. It uses this to pick up some stuff that may have been drawn to the screen eg by the use of a mouse-reading and pixel-drawing routine in a menu option in GEM.
But we can now put some structure to bigbig. We can call on some of the routines that are part of the High-Powered PMN Terminal, and which are rather universal: they are part of almost every program of some size in G15 PMN, including the Triangles program in the first utility menu. This Triangles program expands drawing lines into drawing filled triangles. It uses the screen so as to suggest a matrix-like appearance. It is also one of the more 'commented' programs--it has eductional comments inside it. So, if you like, you can copy the Triangles program and expand it, if you anticipate you may want to use some of its routines. It is, after all, a relatively short extension of the G15 PMN Terminal. To copy it, you could go to its start position, as shown on the utility menu, and then copy the whole lot--which includes the PMN compilation part first. It is much less than 2000 cards. So you could simply do CTR-C and type in 2000 there, and press ENTER, and go to such as i:1 and paste it in by CTR-T followed by SPACE (if you don't have anything unsaved in that area of the i disk). Before you start the program from i:1 by having a line somewhere--perhaps you work from the card just before the Homecard G15, namely G14--and here you could point to the program by the i%1 type of statement (the % is shown more like an arrow, a flower, or a hand, in G15 PMN, though)--before all this you have got to specify the beginning of the PMN part in card i:1. For some, this will be the first time they do anything with G15 'pure' assembly code. The Triangles program begins at disk e (or E), fifth in the alphabet, whereas disk i (or I) is ninth in the alphabet. So to the left of "disk#" you would modify 5 to 9 in this first card in the program. Also, it wants to know where the G15 code stops and where the G15 PMN program begins. It says 4591, in the case of Triangles. If you look at the numbers, when we move the program from 3500 to 1, it means that 1092 is the new start. So to the left of "progcard" you would write 1092. Then save it! By ctr-s, to i1. And you can now work with the program. If you wish to build on the Triangles program but have a different startup, the first thing you would do is to remove the phrase
&triangles&
zz
which is found at i:1478. Then you add new stuff to i:1479 and so on, and provide new information, a new 'ZZ', which specifies the name of your own program. Do please note that the Third Foundation G15 PMN is an app that has already sorted out such things, and has already included the Triangles elements in itself, and provided extra documentation for much of this stuff. It is good, however, to know how to handle also simpler programs with fewer ready-built program modules in them, like this.
Later on, you can copy the program somewhere else, and perhaps wrap it up as a G15 PMN app, and offer it for the public.
It is of value to know that G15 PMN is a fixed, stable, complete package. Whatever it has of issues inside it, these are very, very few, and we can talk of how to handle these. In that way, it is something that allows us to communicate as human beings by means of learning and getting familiar with it. The knowledge we gain of it, is knowledge that will keep on being relevant. The Triangles programs will keep on being the Triangles program--and so on. And we don't have to talk in abstraction, we can talk of concrete card numbers and so on, in such a text as this.
Anyway, we were going to make bigbig into a matrix. To give it structure. In the beginning of the High-Powered Terminal, and also in the beginning of the Triangles program, and building on extra Predefined words included in the expanded G15 PMN core that is standard in these products, there is a word: WWYYMATRIX. If you have just copied the Triangles program to i:1 it is at i:1103. This word we can use this way:
1000
1000
bigbig
wwyymatrix
And that is to say that we want 1000 as width and 1000 as height of our matrix. Notice that we made the size of the array a hundred more: 1000100. A hundred more is a good rule of thumb (50 is required as extra, for the structure). Good programming doesn't push the boundaries too hard. This reduces the chance of the PC collapsing during big loops when the program is made in a way that is a bit hastily thought through at points.
So WWYYMATRIX actually modifies 'bigbig' to point 50 further ahead, so that just before the place where bigbig now points, the data you gave is put in. (The other spaces are just extra, a header you can use for other things, if you wish.)
In order to get stuff into the matrix, use YY, which is part of the expanded standard set of core Predefined words in the High-Powered Terminal, and in most other big programs. In other to get stuff out of it, use WW. These work exactly like YA and AY, except that whereas YA and AY want just one number (the place in the array) to get to where the number is, the WW and YY want both X and Y position, ie, two coordinates.
While the use of the G15 PMN fonts and programs are okay given suitable acknowledgements, you should read intro-comments or associated texts with any G15 PMN App you fetch before you build on it. We recommend but cannot demand that a generous Open Source statement is given by each programmer, so that there is a contribution of new programs in a way that can benefit other programers as well, and lead to a sense of shared growth of understanding. The language Perl built by Larry Wall was in many ways a pioneer both in orienting itself towards source, and towards the sharing of it: and Wall is a scientist, with education in chemistry as well as linguistics. Programming, at its best, is a scientific activity in the best sense of what science can be all about.
Strings, long strings, and infinitely longer strings
"Here's a lot of cash for you---no strings attached!"
That's one sense of 'string'. As a programmer, you are aware of another sense--the sense of an array, typically of letters or characters, including possibly digits. When you add two strings,--even if they contain numbers--you expect the previous strings to be incorporated into the new one--unlike digit additions, which clearly involves transformation of the digits according to the rules of arithmetics. So these things we'll look into here, in the light of G15 PMN running on a psychologically pleasingly constructed PC, fully capable of dealing with 32-bit numbers in formidable masses. We'll touch on a more powerful way of acting on a condition than SE, which in PMN is called 'D2' (which can be read, 'in the Denial of the aforesaid, do the next 2 things', but which also has other capabilities).
And we'll have a brief but concise look at what would happen if we imagined that the G15 PMN formalism made sense if they computer had infinite capacity.
As a computer programmer, you have an influence on society that, to some extent, may be greater than the influence of many other people. Your own value decisions do matter. Your simple statement, 'That's easy to make', or the denial of it, may affect societal developments, when said in certain circumstances.
In that sense, every course in programming ought to have doses of suitably fitting elements of philosophy, including ethics.
And a key theme in ethics is this: the experience of freedom of your fellow beings is part of what makes human living worth the while; so, before you do something that affects society, look into the freedom aspect.
If you enjoy freedom in front of a personal computer, then consider that this is part of the manifold experience of freedom that is, in a sense, a universal human right, when it makes societal sense to some extent. But so often we have seen that computers can become instruments of authorities to exercise control,--too much control. And part of their control mechanism is called 'digital money'.
"No strings attached!" That's the virtue of having cash, cash that is your own cash, cash that's in your pocket, cash for which you can buy without triggering databases all over the place with a rather permanent record of your every movement. Cash is part of the fun of small-business-friendly capitalism and market economy, which is something we can see as distinct from big-business capitalism.
Cash means to have the elegance, playfulness, and joy in doing things without all the time showing up a name and an id for it. This is part of a humane society: privacy. It is part of what makes a city alive. It cannot be replaced by digital money. Digital money--money that exists by virtue of digital computation--can supplement it but all legal, responsible citizens want to be able to do things in complete freedom from surveillance. A limited James Bond-like surveillance we can accept on the basis of vital, intelligent need in each case: but the ground of the flowering in goodness for a society requires the pulse of existence without the constant measurement of each individual. According to the Heisenberg Principle, or what Niels Bohr called 'Indeterminacy', even electrons and photos resist measurement.
While we're on the theme of ethics: influential people with high status in society and in history do make deep mistakes in their thought processes sometimes. Bertrand Russell, with Alfred North Whitehead--people of intensely high status in philosophical circles in early 20th century--seemed to hope to make a complete mechanical system of thought around logic and numbers, in their PrincipiaMathematica. They had put in measures to prevent a feature called 'self-reference'. But only a few years later, Kurt Goedel was able to show that their system is either not complete, as they had hoped, or, worse, it had inner contradictions (in which its capacity to judge anything becomes zeroed out with inconistencies in every case).
However, what happened here may not have been sorted out correctly by the intelligentia of the prestigous universities and their encyclopedias and professors and much-quoted authors. As a programmer, you must look into what makes sense in terms of it being a clear idea. If the idea is confused, say so: but if it is clear to you, and in contradiction to what is hyped up as a truth in society--then that is what you say. You will get enough chances to check ideas about finite structures on the computers, against your own perceptions. You can build on that self-confidence to sometimes take careful leaps into infinity. But few have applied the right care here, as I see it: the scholar, eminent logician, and dutchman, Mr L E J Brouwer was one who called for more care when it comes to handlings of infinity in mathematics than the mainstream. Like L de Broglie in quantum theory, who went against the mainstream interpretation both early and also in the last decades of his life, Brouwer went against the mainstream attitudes on infinity in logic and called for a wholly rebuilt mathematics. If you read our example here, you may get a clear idea why this is necessary.
To get back to the question of working with personal computers--sometimes, it's like having lots of extra cash, isn't it?
Having a programming language, a computer with lots of free RAM, and some speed to it, combined with spare time for yourself--that's a sense of having a degree of limitlessness to yourself, at least if you have come to the point of mastering that programming language. Let us also add that this experience is stronger when you are used to thinking of, and using at least some of the computers you are using in the sense of 'a dialogue with yourself', rather than merely a sort of node in a perhaps vast network of nodes, of computers. For the experience of clarity, tranquility, and sense-making in our process of programming is perhaps never as strong as when we have perfect stability in the medium in which we are expressing some clear ideas.
So, a computer that is lined up to a network can be said to be in the 'online' mode. When a computer is independent from the network, your own experience of your physical surroundings is to a degree emphasized rather than de-emphasized by some decent work on the computer. The word I prefer to use for this mode of computer work is "realline" (and so I totally prefer to avoid the word 'offline', for it is a word implying a deficiency, whereas an independent, stable computer is indeed an abundance).
We'll next have a look on strings, what we in G15 PMN often call 'quotes'--whether they are short, long, or--as in a thought experiment we'll carry out--indefinitely long, in the sense of arrays. Since G15 PMN is leisurely using large 32-bit numbers in each and every position of even text arrays, we have a relaxed distinction between strings (or quotes) on the one hand, and arrays on the other. And this relaxation is actively pursued further by de-emphasizing distinctions between arrays and matrices--and so forth.
Now, in G15 Yoga6dorg assembly language--the language underlaying PMN, and which you can call on to make really fast-performing extra predefined two-letter words by following the scheme that G15 PMN invites you to follow in creating such little additions--there are quotes where there is no size of the quote as the first element of it. But if you in PMN write
&Hello world!&
PP
then you will have created this little string or quote, the 'Hello world!', quite automatically, simply by typing it in like this, so that its size, 12, is in the first position of the array. So, in array position #0, there is the number 12. In array position #1, there is the number for the letter 'H', which in ASCII code is 72. Then follows the lowercase 'e', which has a different ASCII code, and so on, up until '!', with ASCII code 33; and after all that, just to be sure, there's the code zero, the socalled 'nilchar'. In that way, a routine like PP has two ways of working out how long the quote is--either by looking at its beginning, or by working through it until it encounters a zero (also called the 'basis' character in our vocabulary, and in the same vocabulary, for philosophical reasons, we sometimes call the number 1 of the ASCII or 32-bit type for the 'dance' character). So a socalled "PMN quote" has these two features. There is a routine called SETLENANDNIL -- set length and nil -- that modifies a longer string into a shorter one simply by modifying the first number and inserting a nilchar, a zero, after its new length. This is part of the High-Powered PMN Terminal.
It is part of the Terminal, part of, in other words, the set of PMN words that you typically would have as the beginning of any program of some size you write yourself in G15 PMN, that you create a quote out of a number on the stack. It is called MAKENUMBER. So, for instance, you can get the PC to display '1234' in two ways:
1234
NN
That's one way. To print out the number that's on the stack, onto the screen. The other way is to convert it into a PMN quote, and then print it out as a text:
1234
MAKENUMBER
PP
At the stack instead is the address of the text.
To go the other way again, back to number on the stack, CN is Convert-to-Number.
When we want to have a long quote, going over several of the very slender and elegant PMN columns in our cards, then instead of writing such as &Hello world!& we write e.g.:
LONGTXT*
Textline 1
Textline 2
Textline 3
*TXTCOMPLETE
To store the location of this text to a variable we can then write eg:
SAMPLETXT1=
^.
This makes a new variable called SAMPLETXT1. We then pick the pointer (the warp) to the longquote off the stack:
SAMPLETXT1
KL
And then we can later on use such a routine as BX to show a whole long line in beautiful B9FONT by using LK on this variable. Note that there's a useful routine called CLIPTRAIL that clips away the extra blanks that tend to come with these quotes due to the relaxed syntax they have--they don't have a single character to fix the end of the quote, and in that way, anything can be quoted with ease, but rather a lineshift and this whole word *TXTCOMPLETE has to be used. But then there may be blanks you don't want in it. CLIPTRAIL handles that. Just look into the code of these long words as part of the Hipow stuff at D:23091 and up in the standard G15 platform and they document itself. Or you can use the Hipow to search for the definition of such a word by ^E99 followed by CC.
Note that such a text quote can go over many cards if you like--but the more common approach is to do it in chunks that fits the linewidth of such as the BX or RP character displaying routines. If you quickly need to display a menutext to yourself as a programmer while working in hipow, store it via B9EDIT to some cards and write e.g. ^K1 and MORE to show it. There are also really simple ways of outputting and inputting texts both from keyboard and from the cards, line by line, using robotfont associated with this MORE routine (ie, defined near it, in the PMN High-Powered Terminal: e.g. the calendar program are using these, and also the XCalc extended calculator on the utility menu).
Since you are such a high-powered programmer yourself that you read this stuff in this chapter, why don't you begin to work--as a routine--with the Third Foundation app, or its little sister, the Second Foundation App, or ITS liittle sister again, the 'extra-high powered terminal' that is the first part of the Calendar program? It, too, has a number of sleek additions. The first part of the PMN-part of it is exactly the same as in the High-powered Terminal, so it still applies. But from E:21381 and onwards it has still more! It is however important for pedagogical purposes to divide up and not give all these things at once to the beginner,--so we have elementary PMN to be learned first, then gradually these higher-powered things. If you copy the calendar and, in the final column of it, you insert your own intro-text.
This is fairly easy and it is in any case good practise, for all programs in G15 PMN, all apps, can be handled in much the same way. For completeness, let's say you copy the whole of e.g. 2000 cards from the Calendar program, which the home card of G15 PMN lists as E20000, over to L1, then you go into card L:1612 and put in eg &Our hipow!& and PP there, in the right-hand column of that card. You simply blank out the reference to the calendar-program there, and the ZZ on that page, so that it starts straight at PMN instead of launching the program. Also, at L:1 you write 12 for disk# (instead of 5 for E, it is 12 for L), and 1102 as the new starting-card (now that it has been moved from E20000 to L1). Easy to do when you get used to going back and forth in the G15 platform with CTR-C copy and CTR-T to put in cards, CTR-L to open a card and CTR-S to save after edit. When you use e.g. G14 or H1 as a pad for your own often-started programs and often-opened cards, you bookmark each interesting card--like L:1102--by typing it with a colon. To start the L:1 program, type L%1 with the symbol G15 uses instead of percentage sign, and click on the colons and that flower-like symbol in the menu mode. The menu mode is activated by CTR-W and the edit mode by Right-Click on the mouse, and these two are used all the time, so you get them into your fingers.
It is part of the underlaying philosophy of G15 PMN to honor fairly known boundaries, or ranges, instead of trying to pretend that we have 'handled infinity' and instead of making every boundary so fluctuating that the whole platform becomes a bubble instead of something stable one can learn about and grow with.
The somewhat extra-powered terminal contains the same PD set as the GEM image editor--a small addition to the set of PD in the high-powered terminal. At L:1102, then, when copied to the start of the L-disk, is the start of the PMN part, the ordinary high-powered PMN. At L:1382 this is extended with a variety of useful extra-routines. These connect both to numbers and text, both display and disk, and they are fairly well commented and examples of use for some of them are within the calendar program. And, as said, at L:1612 even the Extra High-Powered PMN Terminal has no more to define. It, too, is complete. The Third Foundation G15 PMN contains ALL this stuff and MUCH more, and a very huge number of applications of all sorts can be made what that as a starting-point--and you can then also build on apps having the TF (as we also call it) as starting-point. You are of course entirely free to make all sorts of G15 PMN apps having other apps as beginning when you are clear about acknowledgements and read through whatever licenses the programmers want that should be enforced. If you can sell it, by all means sell it, but you must make agreements with those who sell a program if you wish to build on this one. The language is free; a language must be.
So, continuing with the expansion of the calendar program, we can find defined at E:21423, but at L:1424 if you copy the EXTRA hipow to the L-disk, we see ADDTEXTS: it makes use of a somewhat more general routine defined in this hipow-form of G15 PMN to put one text beside one another and back into the quote.
If, instead, you use the Third Foundation G15 PMN, you can simply type in 'scan' to find the same routine there. When the TF is loaded, it usually keeps the Third Foundation starting at card F1, and you put your own program at F:2351. That means that the Third Foundation G15 PMN has about 2350 cards premade for you--first a lot of G15 assembly to erect core G15, then a lot of higher-level G15 PMN code, including most of that which is found around in various G15 programs in the G15 PMN core platform. There's a new function there, EXISTS, which you can use to check what is already defined as for high-level functions. Read the TF manual at H33 via the B9edit editor as included in the G15 PMN platform, or manually via the new functions SHOWCARS.
So, if we do AD on 1234 and 1234 we get 2468. If we do the following -- 'string addition' -- we get 12341234:
10
SZ
&1234&
S1
This stores the string 1234 to local variable I1 and the string has extra capacity, its max size is set to be 10.
&1234&
S2
This stores 1234 as another string to local variable I2. (Remember, by the way, that SZ is to be used outside of functions. So the above will work if you type it in. If you need extra size capacity for a quote, put the SZ and the quote outside of a function, then store it to a variable with KL as we did above with the longquote.) (Also remember that although we for clarity and ease of reading we write uppercase for code in our explanations here, when you type in these programs, using Robotfont either directly into a PMN Terminal or on cards, you use lowercase for all function names). Here, we use the extra high-powered PMN terminal, which is the first part of the calendar program.
By it, let's add the strings:
I1
I2
ADDTEXTS
I1
PP
This shows 12341234. Note that S1 and I1 and T1 and J1 and such do work outside of function definitions, even though they are called 'local variables'. This is so that it should be easy to check things without having to define a function to do so.
Let us also bring in a more advanced decision-making function--if that's the phrase I want--than 'SE'. The predefined, or PD, word 'SE' can be used e.g. to quit a loop by a keyboard touch doing something like this:
DOINGIT=
LL:10000
SHOWIT
CK
SE
EX
1
S1
LO.
So this routine DOINGIT, as we define it, will run some kind of routine we have, supposedly, just made, called SHOWIT, and it'll keep on doing it--more than a thousand times, because the number 1 and the next line S1 puts 1 into the counter each time. (If you are into Third Foundation, you can just write Q1 instead, which reduces the value of i1 by 1.) But when Check Keyboard shows a touch on it, then the SE will SEe this and do the next line, which is 'EX'--in other words, exit the function. (The CK, by the way, is a standard part of the expanded core of the High-Powered PMN Terminal. These are explained mainly through examples of use, e.g. in B9edit, GEM and so on, but you can also look at the program comments and the code for it. A comment about CK is at d:23053, some dozens of cards before the PMN part of Hipow begins at d:23091. Other PDs are also commented here. Then, a more elaborate comment, sometimes, is in the code itself, which is further dozens of cards earlier.)
But what if we wanted an extra action? Then D2 is an instrument--and it very often happens that we do need such extra actions. D2 is then fed the opposite of SE: D2 can be read as 'do the next 2 lines in Denial of this'. Here:
DOINGMORE=
LL:10000
SHOWIT
CK
N?
D2
FAREWELL
EX
1
S1
LO.
The routine FAREWELL you must make yourself. If in doubt whether a routine exists or not already as part of the High-Powered or the Extra High-Powered PMN Terminal, just start up the Terminal and type in the function name. A question-mark indicates it doesn't exist. If the computer goes up in smoke, the function does exist, but you gave it the wrong parameters ;)
Note that the N? which, when used just before D2, reads as a unit: N? switches 1 to 0 and 0 to 1, and so D2 with this becomes just as SE only that two lines are to be done, instead of just one.
But there are still more variations here. D2 can get an input that is beyond the 'yes'=1 or 'no'=0. What it then does is to jump twice the quantity of lines given, in the direction given: an input like 3 means jump six lines ahead. The word DE is related, it doesn't do twice, but otherwise is similar. So if you want to have a lot of keyboard handling--a certain action for each key pressed, and then exit--D2 may be what you want to use in this way. As this chapter is being typed into the B9edit editor, stuff like SE and D2 are deciding over the consequences after each keyclick.
Now what we'll look into next is, for those used to large programs, deceptively simple. But because the underlaying assumptions shift here--from the finite to the infinite--it must be understood that it is also enormously more complex than the most complicated program imaginable on any digital computer. So formidable is the complexity of thinking about infinity that I always find it appropriate, when talking even a little bit about it, to remind people interested in it to do it only a little bit at a time--and then do many other things, and think about other, and more finite things, before doing a next session with this type of stuff. For infinities are so hard to think about straight that they may do wierd things to a mind if it's done too much at a time--and it isn't worth it. Forgive me also if I cut short the discussion after showing a point instead of dwelling on it--after all, there are plenty of other texts from my hands dealing with this, which are quite available.
Imagine a structure, then, as an experiment in thought:
1. infinite capacity in RAM etc. Every type of infinity associated with this structure we symbolize by "...", three dots, and this ... can be stored where we normally store 32-bit numbers
2. infinite speed is part of it
3. coherent idea of G15 PMN formalism somehow still applies
Have you imagined it? Good! Next, in this imaginary case, where "..." can be used instead of a number to mean "infinity", let us make use of our understanding of arrays to make an array called GENERATED. This has, as some types of PMN arrays have, the quantity of elements in it in the first position. (That is to say, the first element in it is #1 rather than #0, for #0 is set aside for quantity of elements.)
We make it, in our imaginary structure, in this way:
GENERATED=
^.
...
SZ
GENERATED
KL
The size, that is, is set to be the "..." new type of quantity. This is an infinite array--whatever that means.
Further, we are going to fill it up like this:
GENERATE=
LL:...
I1
GENERATED
LK
KL
I1
F
GENERATED
LK
YA
LO.
That is to say, the array, located by GENERATED and LK, is having the i1 counter in the loop inserted, in each case, into its first position--and then, as soon as this is done, this same number is also YAed into the array itself, so that, for instance, at position #5 we put the number 5. In other words, each time a new number is put into the array, the length-info in the array is updated--with the very same number as we added to the array.
The "..." involves an infinity that is infinite also in speed. It doesn't merely mean here, in our imagined structure, "let it go on for as long as we want". It rather means, "let it complete this infinite task".
In that way, we obviously have all the whole positive numbers as members of the array. Interestingly enough, since it is also complete, and the array is infinite, it has the infinity number in the first position of the array--whatever that means. Whatever type of number this is, it is however clear that exactly the same type of number is inside the array--for that is the way we in fact did GENERATE the array GENERATED. In other words, this is an infinite array, containing all whole numbers, which is self-referential in that it contains its own infinite size in it. But then, when Principia Mathematica tries to use the related idea of 'set' of all finite whole numbers as an infinite set of only finite numbers,--and in this regard leaning heavily on Georg Cantor's works some decades earlier--are they then utilizing a clear idea? It is only possible to formulate an infinite set not containing infinity as part of itself if we restrict the type of meaning we put into the word 'infinity' when it is employed inside the process--we generate as many finite numbers as we want--but not when it is employed outside of the process--for we consider the set completed.
In other words, Russell and Whitehead, whose works were shown by Goedel to contain hidden self-reference, may have incorporated this hidden self-reference by means of the cantorian assumptions--which, implicitly and without talking explicitly about it--divides infinity up when attempting to contruct the set of all natural numbers.
In case you read the above quickly, I will suggest that this theme is highly interesting to look into also SLOWLY! :)
And in the spirit of that slowness--for questions of infinity requires a certain patience, even silence within the mind, to be properly perceived--let us muse for a moment on the three dots, the "..." type of symbol.
So, the "..." has been used, in much of 20th century mathematics, when we wish to say--this variable can go high and still higher and we don't need to put a limit on it. For any given number, one can always go a step higher--say, by adding one. And then one has said: this possibility of always going higher is more or less what we will mean by infinity.
In 20th century mathematics, then, the notion of "the limit"--any limit, an arbitrary limit that always can be superceded, because frightfully important, in order to "solve" all sorts of infinity questions raising in the various branches of mathematics, including that which is called "analytical geometry".
As the 20th century books never tired of pointing out, the collection of numbers 1, 2, 3, ... is infinite but "the series itself doesn't reach any infinite number". Why not? Because it was DEFINED not to. But when we reach for clarity in ideas, a bit like the famous dutch thinker Brouwer sought to do, perhaps, we are at liberty also to question definitions. Also definitions must reflect clear ideas.
For clearly, the collection of numbers 1, 2, 3, ... is entirely dependent on what we mean by "...". If we by "..." mean: go to a particular finite number, then that collection isn't infinite. If we mean, go to some kind of infinite number, then we no longer have the original definition of natural numbers intact, but somehow have got beyond it. Instead, the point of view taken in the 20th century was to say: an "arbitrary" finite number. An indefinite but finite number. It goes up to an indefinite finite number. And does it go higher? "Yes, if we wish it to." That was the discourse in much of 20th century mathematical thinking. "As high as we wish."
Let us now consider that "..." means "as high as we wish"--but still a finite number. Then, if we stick to this definition, 1, 2, 3, ... isn't going to infinity after all. And so this is a bit puzzling: how can we say that the set {1, 2, 3, ...} is infinite, if by "..." we mean any abitrarily high but still finite number?
At first, this may sound like an artificial type of question, that we mess around with semantics, and not do real work. But it is real work. It is hard work to understand finite, indefinite finite, and infinite. And something quite startling happens when we begin to see the beauty of what is going on here--and this can turn into a fountain of insight relevant for all art, all design, all philosophy, etc.
What is the case, as we have already hinted, is that there wasn't just one definition of "..." but two different definitions going on at the same time: and mathematicians have, since Bertrand Russell declared (after months of doubt) that it was good thinking, not offered much official doubt on this question (though they should have done it, according to Brouwer and several others). So what were the two definitions?
The two definitions of "..." that the mathematicians operated with was this: [1] "..." means go up to an indefinite yet finite number, as high as you please. [2] "..." means let [1] go on and on and let us see this in completeness from a distance.
So what Georg Cantor achieved, who preceeded the work of David Hilbert, Bertrand Russell and others by some decades, was to jump without saying it between the two definitions of "..." and in that process convincing people that whole numbers constitute one type of infinity, while decimal numbers--with an indefinite number of decimals, possibly infinitely many,--constitute another type of infinity, a larger type. The details of this proof relies the definition of the set of natural numbers; and the definition of the set of natural numbers, in turn, relies also on this double use of the "..." definition.
The definition, then, underlaying most of the premises of the 20th century mathematics, of natural numbers as N = {1, 2, 3, ...} depends on one definition of "..." when seen inside the brackets { }--inside, it is oriented towards finite, though indefinite, numbers. Outside of the brackets, the other definition of "..." is called on, and it is said that "N is of infinite size".
In other words, two NOT overlapping definitions of "..." are used implicitly when N = {1, 2, 3, ...} as a set of all finite whole positive numbers, the "natural numbers" are made.
The natural numbers, in other words, can only be defined if we allow ourselves to be sufficiently loose in the definition of "..." that it serves two different strands of thought: one in which "..." concerns finite numbers, and another in which we abstractly take a step back and think in terms of an (infinite) completion of the process.
It is then my postulate that this jumping--or incoherence--in the definition of "..." by Cantor and others lead directly to such other complicated incoherencies as Kurt Goedel pointed out. And that we should look again at the "..." definition. And this, indeed, we have done above. And how did we repair the error? How did we "coherenize" the definition, and get away from the incoherence?
The answer lies in the fact that we stuck to seeing "..." at an abstract level, where the infinity is in focus. We didn't do it by means of two different definitions. Rather, we asserted at once that by "..." we mean the second type of definition mostly. In other words, "..." refers coherently to an infinite--and completed--process.
But how does this effect our understanding of such as natural numbers? In what I have pointed out since the ISBN-published text, under one of my several earlier pen names, Stein von Reusch, as found on bibsys.no and nb.no (National Library of Norway), since 2004, a text also launching the "super-model theory" of the quantum and gravitation phenomena, it means that there is no definition of natural numbers that is infinite unless we admit not just one, but a whole new class of somehow infinitely sized numbers into the very same set. We can't close it off: once we begin to define it by an arbitrary growing process it is pr definition self-referential in size--just as we perhaps saw together with the imagined "infinite computer" program above. We can only complete the making of the set N = {1, 2, 3, ...} by admitting that the size of N is itself a member of {1, 2, 3, ...}. This is self-reference. Self-reference is the typical feature of infinity. But it isn't the only feature of infinity.
Now, once we begin to appreciate the self-reference in our dealings with infinite collections of numbers of this sort, we will also have to appreciate that the whole notion of addition, and so on, cannot be considered simple anymore. For while addition is usually easy to speak about connected to finite numbers like 3 and 5, if we by such numbers and such arithmetical operators are making infinite sets, then not only the numbers undergo a kind of 'infinity-transformation' but also the operators. All this means that we are going into an area in which we must call very sharply on the human mind and its capacity to perceive, but what is it it perceives? Surely we cannot look to the senses, to ordinary empirics--sensory experience--out there. And yet there is some kind of empirics of sort that we wish to perceive to clarify our ideas further. If it isn't a "physical empirics", then it must something like a "metaphysical empirics". And this is certainly NOT the path Bertrand Russell took in most of his writings (except for a period in which he concerned himself with mysticism and produced a small book which he later disowned).
I wish here only to sketch the beginnings of how you can meditate on this, not close it in, and I do it with a sense that I wish to also persuade the interested reader to do such explorations gently, and only a little at a time, for not few of the big minds in the 20th century who dedicated themselves to infinity number thinking got too much infinity concepts on their minds. In any case, it is now interesting to turn our attention to how whole numbers interact, using rather simple arithmetical and trigonmetric functions, so as to lead to features that involves 'sudden jumps'. Look, for instance, at how an analog clock--a clock with a long and a short arrow--gets interesting irregularities when laid out on a matrix with low resolution, and visible pixels --such as we have consciously implemented as part of the G15 PMN home card--the 'Good Time' program there. You'll see that the whole numbers, as represented in this case by the pixels, get sudden jumps at certain angles. It is just the whole number feature when combined with something like circular angles that lead to features of "jumps" graphically, by way of analogy with how quantum features are introduced by means of the phenomena discussed under the heading of supermodel theory. When processes are moving according to whole numbers, then, under certain conditions, things do not go from one point to the next by smooth transitions, but involve that which is also popularly called "quantum jumps".
We can then propose the following: when we produce formal thinking elements in which natural numbers play a role, but we also allow the structures to engage something like our (holistic) definition of "..." or "et cetera", in a COMPLETED sense of infinity, then we must be prepared to see that there are structures of irregularity depending on just how the whole setup is made. This irregularity takes place in the interaction, we can say, between the finite numbers and the infinity which we can metaphorically associate with that of a smooth circle.
It seems, then, that when we apply intuition into the "metaphysical empirics" of what goes on when we COHERENTLY push integers into infinity, we may get towards something that has some kind of rough feature of both wave and particle in it. The wave aspect is represented by the smoothness of infinity, symbolised by a circle: the particle aspect is represented by the sharp projections of the finite, and the nonregular behaviour of the finite when put into such a context.
All in all, a fruitful theme for future metaphysics, then, can be to engage in getting propositions connected to this theme: can something such as the nature of the phenomena found in quantum laboratories be connected to the questions facing us when we wish to see the interaction between the finite and the infinite in terms of natural numbers?
Let me here, as in other writings about this, not omit to point out that the questions of infinity were handled not only loosely by Georg Cantor, but by a great many thinkers before him--he was standing on the shoulders, so to speak, of a long and fairly inohcerent tradition. Thus, for instance, Descartes operates with much the same type of implicit number understanding as Cantor made explicit, and the loose talk of infinity as nothing but a simple, mechanical--and, as we point out,--incoherent extension of the finite goes back to the ancient Greek texts of Euclid, and has similar features in other ancient cultures like the Eygptian, Chinese and Indian. But in each of these cultures there have always been other thinkers who have pursued other main lines of thought. So thanks to people like Cantor, Hilbert, Russell, Whitehead, Post, Turing and Goedel, we have a lot of explicit stuff that we can tear to pieces. We can see the incoherencies more clearly if we use their work on making things explicit for this purpose.
Let's have another swing at this. On a bright sunlit day, you gaze towards the sun, briefly, and for a moment you see, or think you see, the perfect circle that is the Sun itself. Pursue this for a moment as metaphor for something that is infinitely smooth.
In this metaphor, in this picture, let us further imagine that we take a digital camera and produce a snapshot of the scene, including the Sun. You put this photo into your computer, and you can there enlarge it, until you see the pixels.
Once you see the pixels that compose the photographic image, including the Sun, you then, obviously, are getting an approach to the scenery that is composed of dots or squares or something. You know that this is an artefact of the digital camera: the pixels aren't out there, but rendered as part of the photographic process. (There may be something like pixels out there, but not at the resolution and light sensitivity that your typical handheld digital camera offers; more about this when we talk of quantum phenomena in other places; let us bear in mind that reality as such can have many levels of such continuities and discontinuities.)
Even so, you can de-zoom the image, and get a pretty good representation, as stimuli to your mind, of the scenery including the Sun. Now these are two perspectives: one, in which we focus on the pixels composing the image; and another, in which we focus on what the pixels point to, or represent, as the perfect, clear idea of the continous circle. The notion of using the Sun as image of the infinite--not just the 8-like symbol, but the circle as such--obviously have roots in all ancient human cultures, including, not in the least, the ancient Egyptian cultures, in which, for example, Cleopatra deemed herself a 'relative of the Sun'.
It is also possible to BOTH view the pixels, as when you have enlarged a small photo much, or are watching an analog clock represented with big pixels, so that the clock-arrows get all jagged and arrythmic--and ALSO to consider the idea of the perfect circle that the pixels point to, or represent, or model, or stimulate in our minds.
Consider now saying: have a look at 3, 5, 8, 13, 21 (and why not produce some more by adding the two most recent, these are the Fibonacci numbers, having the golden ratio between them), and the infinity that we can imagine by continuing the process forever and ever.
Then attend to the difference between what we just said and this series: 3, 5, 7, 11, 13, 17 (and why not produce some more by finding the next number that can't be divided into whole numbers, these are the prime numbers), and the infinity that we can imagine by, again, continuing the process forever and ever.
In some senses, these are two different infinities, a bit like, if you photograph the Sun at two different zooms, you get a different pixel-resolution, and that represents the perfect idea of the circle in different manners, and indeed, the circle feels different when represented differently.
So, and this we can explore more and more as part of a freshly started number theory with awareness of the complexities, often unseen, in dealing with the concept of infinity as in the past of number theories: when we speak of finite numbers and an operation and add 'et cetera', then we are as if operating with a certain RESOLUTION; but when we speak of what this is imagined to represent, as perfect completed process, then we are as if taking a step back and considering what this might REPRESENT, as stimuli to our minds.
You see, there's a lot of art hidden in clear thinking about numbers. There's a lot of esthetics, not just in the prime number sequence, the Fibonacci sequence, the trigonometric numbers showing relationships between angles of a circle and the radius, and so on, but also in the notion of the infinite as represented by something finite.
For instance, when a child, untouched by culture, in radiant innocence, stumbles on her knees, gets a scrub-mark and cries, the instinct is at once, in all healthy normal adults, to help and heal the child: the infinity, as it were, represented by the child, ought to be represented without any scrubs or marks and we at once act correctly, the perception of the overall harmony lends quality to our careful actions in healing the little bit of disharmony, we want the scrub-mark to be quickly healed and it goes away and the child is happy again. The symmetries and the perfection--also in a program that has been made to your esthetical satifaction--speaks and listens more strongly than shapes that are less harmonious. So for example, it is much easier to spot the issue that must be corrected in a program that is beautiful-looking. The program as concept is a certain idea, represented by its content, and there's attention in that process. We might say, in such cases, that the pure idea 'listens' to what represents the pure idea, and that which represents it--the pixels representing the Sun for instance--'speaks to' the idea of the Sun.
Now we have done some metaphorical work. Try, if you wish, to entertain these images, these metaphors in your mind as we again look at some hard numbers.
For when we say, let us start the series of numbers 1, 2, 3, ... so that you can add one the most recent and get one higher, we can look at proofs. Now the dutch thinker Brouwer suggested that we must be careful with proofs of existence of ideas that relies on negation: he went further, and called for an end to some uses of negation altogether. I think he went too far. But still, in some senses, we must be careful when we use the 'negation' idea while attempting to prove something. He was right, I think we can say, when it comes to SOME interpretations of the word 'negation'. Here's an example: suppose your teacher asks, "Is there a highest number in this series 1, 2, 3, ...?" And some pupils say, "a billion billion billion trillion" and others say "ten times that!" and yet others just smile. And the teacher replies, "For any number n that you produce, I can always produce n plus 1, and it, too, is also in the series. Right? So it has no limit. So it is infinite. Proof done." This sounds easy and obvious and right but let us look carefully about this over-smart teacher's words.
When the teacher says, "So it has no limit", the teacher is using the force of NEGATION. Right? "No" is negation. "No limit". Okay. That's fine.
But then the teacher says, "So it is infinite. Proof done." But let us look at this. Is our concept The Infinite nothing but the negation of limit? I admit that in its Latin roots, "in" is negation, and "-finite" is, well, finite, and so it sounds indeed like the same word. In older English, "illimited" was an alternative. We can also say "nonfinite", or "unlimited".
Yet clearly these things are different. "Not limited" is a statement that we can make while standing rather within the number series 1, 2, 3, and gazing and steering at them. It is like steering at the pixels in the enlarged photo of the Sun. Then, as we get the idea that these pixels add up to something circular-like, we are sort of summing them up, we are, as it were, going from the particle-perspective to the wave-perspective, speaking quantum mechanics. But we don't have a proof of the perfect circle thereby. We don't have THE SUN by simply looking at the pixels and noticing that there is some circularity about them. To get to the perfect idea of the Sun, we must deliberately defocus our ideas, stand back a step, abstract the perfect idea and let go of the particles, the pixels, and forge in our perceptive minds the perfect percept, or generative idea, of the Sun, and perhaps alongside this idea also the idea of the perfect circle or sphere somehow (we're not now interested in the physical reality of this or that star, but in how we go from looking at pixels to the whole idea).
So, when your teachers show you the pixels, the 1, 2, and 3, and shows you that we can make more and more, and points out that there is no limit, we are all in agreement. But we haven't entirely got to any proof of infinity as a perfect complete clear idea by that. We have done negation, but we haven't done affirmation, for that requires stepping back, getting abstract, getting a whole gestalt. So in that sense Brouwer had a point--only in that sense--that we must be CAREFUL about negation, not that negation is useless. Negation isn't the same as forming a clear idea, it is a bridge, a pointer, a beginning.
In other words, when a teacher says, "The Natural numbers are defined by N = {1, 2, 3, ...} and, since we can negate the idea that there is any finite number n so that this is the maximum inside N, then N has no limit in size, hence, it is infinite, this is proven, and we have only introduced finite number inside it." --Then you must at once recognise the point where there is negation. The point is this: "N has no limit in size". This is correct. But what follow from this negation? "hence, it is infinite". No. It doesn't follow that this series forms the clear idea of the infinite from the fact that we deny limits to it. There is more to the concept of the infinite than this. In other words, then, the statement, as given in quotes, isn't representing clear ideas. It is only the beginning part that is fairly clear. We do not know what N is: is it, indeed, forming the notion of the infinite? Well, possibly: but that is not known as long as we are focussed on 1, 2, and 3. To actually get a clear percept, a clear concept, of N, we must stand back. And we must then focus on "..." and we must defocus on the entire process, and see what comes up. And N may be entirely different from that which is obvious when focussed on the initial "pixels" of it, which here are 1, 2 and 3. And so we are not at liberty to say anything much about N--including not anything much about what sorts of entities are not inside N--without having stood back and formed this clear idea.
Let us now imagine that the teacher retorts: "By 'infinite' I mean the clear idea that something isn't finite. Or anyhow, that's clear enough idea for me." But this you can challenge. "Infinite" is a positive affirmation of a characteristic. We agree that N is not finite. But to say that it is infinite, that it coheres with the notion of infinity, is something different. The teacher may argue but you can point out that this is ordinary English: a negation isn't the same as a positive characteristic. To see N as a whole and affirm what you see means that we do something other than call on a word that has been defined drily as an empty negation.
Suppose now the teacher (poor teachers! they are not all like that!) says, "Well, I think it is most scientific to stay to these definitions, dry or not, and negation is a clear enough idea, and a definition can call on that." But then we can only say that to honor the process of clear thinking, to honor the process of science, to honor mind, not just formalisms, surely we must be willing to clarify what we mean a little bit better than by such definitions. "Surely, my dear teacher, you must admit that you have an informal sense of what you mean by infinity. And you'd really like to apply this to the set N, don't you?"
The teacher can either go along with these noble interests in pure thinking, in scientific thinking, in philosophical thinking, or the teacher may shut down and think about the money he or she is earning on her petty little job. In the spirit of humanity, of trusting thinking, we believe that the teacher opens up, and admit: "Yes, of course, I do have an informal idea of infinity. But do you mean by this to say that the definition isn't clear enough? Can you really affirm the presence of some kind of infinite members in a series defined as simple as that?"
This is the point of dialogue. The teacher is asking a question, not merely repeating dry definitions. But once we have got the teacher to this point, we can draw up this little symbolic drawing of numbers--as I've done repeatedly (in one form or another; since including a related form of this in a proposed thesis to the University of Oslo in 2003, with some Java code, part of the conglomerate of early texts linked to from yoga4d.org called, I think, MYWEBOOK.TXT.) Here is a form of my proof:
.
.
.
1 2 3 4 5
1 2 3 4
1 2 3
1 2
1
In this drawing, we are showing the process of making the set N. We begin at bottom, with 1. We add one member, and get to the second row from bottom, with 1 and 2. And so on. It goes upwards digonally, as a triangle. This triangle is symmetric in its height and its width, given proper spacing and font. The height is composed of the column of 1s. The width is that of the topmost line. Given that the height--which obviously and clearly represents the quantity of members inside the set N is infinite, so, by this symmetry, is the width also infinite. At no point was a breaking of symmetry introduced. So we have to negate the notion that the set N isn't having its own size as member. At all points in its construction does it have its own size as member. At all points is it self-referential, in that sense.
So, we conclude, in speaking to the teacher: "So, my dear teacher, you see that, if we step back from this process, and not merely trod again and again around the same notion N hasn't limits, but take a step back, and look at it in the light of the whole, positive notion of infinity, we see that we haven't got a possibility to exclude some kind of infinite members having sneaked into N on top, as it were."
"But this is impossible!" the honest teacher may cry out, somewhat shocked. But then we can, as Sherlock Holmes to dr Watson, reply, "My dear Watson, it is merely improbable, given your background thinking. It isn't impossible--surely, we have seen no evidence that this is impossible. We have excluded all other possibilities and this stands out and so it must be the right one." Or something like that.
The teacher should, at this point, admit that all of the essential thinking about infinite sets and natural numbers from Cantor and onwards through all the 20th century, apart from the question-marks raised by Brouwer and a few others, is wrong. And that even Kurt Goedel didn't get the premises right, in this sense. And we can from that see something new and a bit startling, perhaps, for some:
That the process of going from looking at the finite numbers, to the infinity concept as a whole, mimicks the process that Goedel did when he summed up all of Russell and Whitehead's axiomatic system and 'stood back' to take a look on it; and it mimicks the process that Turing realized one has to do when one has a made a computer that 'goedelizes' an axiomatic system: the whole thing is to get into the realization that intuitive leaps are required when one perceives something as a whole, rather than stick to staring at what represents this whole. Going from the pixels of the Sun to the Sun, as it were.
And by this, we can see, far more generally than ever Goedel's incompleteness theorems ever pointed out, that the mind is about such wholeness perceptions in ways that transcend content--the formation of percepts is by means of a nonmechanical 'stepping back', something that by intuitive processes of attention shapes itself by not getting lost in representations. The best computers or machines or manmade devices of ANY kind can do is to throw around, by coincidence systems, some attempts to grab such wholenesses.
The hollander L E J Brouwer challenged parts of the proofs surrounding the socalled "real numbers", but not with the type of succinct clarity shown here. What we have shown here implies, among many other things, that no real number--when by this funny term "real" we mean a number whose series of decimals after the dot is imagined to be infinite--is well-defined. For it relies, by such a series of numbers, on the natural number infinity, and this doesn't contain members according to the initial specification of finite members only.
We can refine these pictures of infinity in many ways. For instance, one can imagine that we are approaching such as a photo of the Sun with gradually more and more refined photos, smaller and smaller pixels. Ad infinitum -- you follow? In each case, we are getting a different 'feel' of the infinity. By letting go of the notion that infinity is something static, and being willing to listen to more poetic and more informal notions of the infinite, we may in fact be nearer to the reality of coherence in our number thinking--and, who knows, maybe this more than anything has to do with understanding reality as a whole, cosmos on many levels. When I first met David Bohm, I proposed to him that just as the Explicte Order (ie, our manifest universe) is 'pixelled' by quanta so may the Implicate Order also be somehow pixelled, at least it looks like that in my metaphor of it when doing programming: he didn't want to hear of that and just replied, at the time, but with a smile, that 'all metaphors are limited'. (In general, however, I found him, during the conversations we had, very willing to go along with many new thoughts.) That was in 1986 and I didn't have the courage to respond fiercely at the time, being very nervous about meeting this famous physicist. In any case, I do think that this is exactly how it must be: reality is 'pixelled' in quanta at deeper and deeper level, and what we can call the "Planch level" (because of the role of socalled Planck's constant in studying quantum phenomena in present laboratories) may be only the first of a whole series of such levels, each capable of holding vast structures. At some point, we touch Mind.
I hope that by these musings you will have plenty, as I do, too!, to work with as for future explorations of all sorts relative to these questions of infinity and such. I hope also that you understand now the depth of my postulate that we mustn't be fooled by the "Artificial Intelligence" notion: it is simply an infinity that isn't captured in the brittle theories that we've seen so far in humanity as for the reality of mind, intelligence, emotion, feeling, perception and so on, speaking of the mainstream science of the 20th century and how it has gotten so far in the 21st century. The real science is, clearly, not anymore in the domain of the present mainstream universities and their books and journals. The G15 Intraplates Multiversity is an alternative, then, fostered--by analogy with how Phytagoras, Platon and Aristoteles shaped their gardens of learning, their early Academies--a fresh approach, that is, in contrast to mainstream 20th century atheist approach, coherent.
We haven't, in these musings, touched on the significance for biology. But let us remember that when the quantum phenomena aren't codified into a reductive scheme, then neither can biology, that operates on a 'larger scale' than the typical Planck-size quanta, be defined so as to 'close off' the quantum level. Biology must be retaught as much as fundamental number thinking and what it means for quantum physics and the theory of mind. These things, fascinatingly, cannot be separated once we get a glimpse of the true greatness of the infinity concept in a positive, informal, nondry sense--as coherently shown, I think, in this little essay--however presumptious it sounds to say it! :-)
The grand encyclopaedias over human knowledge are revised according to trends in thinking, and they diverge in their conclusions about such stuff. Certainly, in the main printed edition of Encyclopaedia Britannica in the 1990s, it was stated that towards the end of his life, Georg Cantor saw that not all was well with his set theory, and that there are issues with the foundations of mathematics that have not still been solved--or that was the gist of it. This sober view isn't always reflected in the somewhat easy-going somewhat more pragmatic views of mathmatics ('since it works, it is fine') that have been seen in some latter-day encyclopedias and indeed in many textbooksused by universities and such connected to logic and mathematics and related themes. But it is of value to remember that a pragmatic view is inherently a finite one (for we can only calculate a finite number of things before putting something calculated to use, and then the use is, in each case, a finite application connected to finite quantities). And so, when we have an earnest quest, as I think we should, for the clearest ideas possible, we are at liberty, I would say, to say that mathematics has got very serious issues indeed connected to the concept of infinity, and these can all be seen to be connected to the type of quick treatment of infinity that Cantor did and that Russell and Whitehead--and with them, many others--adopted.
The easy summary of the above complicated words is this: you have the right to be sceptical when someone offers a point of view about infinity and calculations with an air of cocksure certainty. Neither 'it works, therefore it is fine' is a good argument, nor 'this is what the big and important thinkers in the field says' is good enough. You have the right to ask for a clear idea and to put down a foggy idea to it possibly being an expression of unclear thinking. This also means that the notion of "the limit", in the sense of "we can go as high as we want in a certain direction, as for a number", possibly may hide a confusion when this type of concept is used to reach a conclusion about a process that, when seen from the outside of it, is regarded to have completed itself.
Let us go back, fast, into the pleasant world of thinking about finite processes running, if not slowly, then at least not with infinite speed, doing things where the algorithm no longer has the "..." concept. But what have we, as programmers, learned, from the above?
Well, possibly, that our own minds are partaking in an infinity that is in principle entirely beyond what our machines can touch (and that it is this infinity that is imagining finiteness, rather than the other way around).
Don't be gullible!
Hint for further learning: to learn to program G15 PMN, there's nothing that beats taking a simple program and modifying it freely and see what happens. Maybe the program will look better, maybe it'll behave funnily--but there's always learning in that. Experimentation of this sort is easy with G15 PMN.
* * *
Most of this text was written in 2015 while some extensions provided
early in 2016, completed March 1 2016. Note that since G15 PMN
prides itself in being stable,--or, to be more correct in our English
language usage--we take pride in keeping G15 PMN stable, it is to
be hoped--what with all writing errors and such there are in this
text--that the text will be more or less equally fresh half a century
hence, and just as relevant. And, by implication, from there on,
--and on and on. Clear thinking is ALWAYS new, in the sense of it
being an unending--or, to choose an old but grand word, 'perennial'--
philosophical theme. Clear thinking must build on symbols and
expressions that honor what is distinctly human, rather than being
dependent on passing trends and technologies. Clear thinking surely
cannot rely on formalisms so terse they're incomprehensible. Even
such a mastestro, to some extent, of formalisms as Albert Einstein
very forcefully argued that these must always have a second place,
after visualisation and informal understanding. Only the intro
paragraph as to how to set up G15 PMN and on what computers may
be, occasionally, updated, and then only at a couple of technical
points and perhaps by means of linked added or removed. All other
parts of this text is, I promise, to stand from March 1 2016 and
be unchanged. Clearly, other texts to come, steadily, will elaborate
all that's more or less started here; cfr links to various places in
the yoga6d.org set of sites for this. By the way, the book archived
physically at the National Library of Norway, is, as for its text
part, available inside the Firth platform and from yoga4d.org front
page, named there "a.htm"; confer other texts about all the themes
discussed therein for clarifications and further developments, and
various refinements and some subtle changes; but the main theses
of that book stand firm. (The most important evolution in that
theory after that book was written is by means of giving increased
value to the informal, a reworking of the popperian approach into
a more consistently intuitition-oriented 'neo-popperian' approach;
together with a reformulation of the 'metaphysical status' of the
suggested super-model patterns in terms of a larger mind-oriented
approach that we also call, conveniently, for a 'Berkeleyan'
version of the same. This development is indicated in, amongst
other places, the Archive section of the Yoga6d.org/economy.htm texts.
***********************************************************
The texts and images at Intraplates.com are copyright the G15
Intraplates Multiversity. However you are granted the right
to redistribute the whole unchanged and unextended text and
sample images in a respectful context without asking on
condition that this notice and a working link to this
document location at www.intraplates.com is included.
