Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!utrcgw.utc.COM!RAYBRO%UTRC From: RAYBRO%UTRC@utrcgw.utc.COM ("William R Brohinsky", ay) Newsgroups: comp.lang.forth Subject: (none) Message-ID: <8911301526.AA13481@jade.berkeley.edu> Date: 30 Nov 89 13:25:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Forth Interest Group International List Organization: The Internet Lines: 74 John Wavrik, U of C - San Diego, writes: >It would not be considered creative in >mathematics to change the shape of 8 (arguing that a different shape would >allow us to write it more quickly) or to suggest that we change the number >base from 10 to 12. And it would be total disaster to leave such >foundational things "implementation dependent". I find that the mathematicians that I know do not have any objection on portability grounds of the fact that they may write '8' with curves (and an occasional horizontal straight line), but that their hand calculators (yes, even mathematicians use them) writes it thus: -- | | -- | | -- . Nor do I find that the authors of the theoretical papers I have frowned over which describe the butterfly Fast Fourier Transform (no mathematician, I) to have rejected the idea of changing the number base from base 10 to base 2. In both cases, the progenitors of the innovations were careful (at first) to define and document their changes, and only with time and common use has the careful description of the changes been left off. I find the use of character formation and number base as justifying grounds for rejecting the need to be concious of implementation dependent factors to be both misleading and incorrect. As a tech writer, I became all too aware that mathematicians change the shape of numbers just because the "different shape [...] allow[ed] [them] to write it more quickly. On the other hand, familiarity with METAFONT and TeX show me that the shape of numerals and characters is highly fluid, and, as explained by Dr. Knuth in his articals on the Concrete Roman fonts (which became necessary when the new Euler fonts proved to look not-so-good with the Computer Modern Roman fonts which he originally designed), may have their shape changed for both reasons of quicker generation (by hand or by printer) and readability. As for the matter of changing bases, mathematicians who must deal with astronomy or time must deal with mixed bases of 10 and 60 and even 12! The question of a mathematician's suggesting a change of base leads to disaster only when done without reason. I see a parallel between this and implementation dependence as required in FORTH implementations for just the reason that Lee Brotzman originally stated. Until all processor manufacturers (including mini- and main-frame manufacturers) use the identical architecture and addressing schemes in their machines, we will have reason for implementation dependence. (Sorry, all, and especially JJW, I don't mean to flame, but I assume non-forther's occasionally read this forum, and things should remain sensible and logical at least when the major points are being made.) >There are very few computer languages that can support the kind of >development >seen in mathematics. For a language to do so, it must be built on a small >and >commonly agreed upon foundation -- and the foundation must be extensive and >powerful enough to allow users to add features to the language. I have >evidence to believe that such a language could be built with an agreement on >about 100 basic commands, and a rather mild agreement about how the language >should function. I think such a language can be made competitively fast and >would offer, in terms of flexibility, an enormous alternative to most of the >computer languages now in existence. John- do you think this language should be FORTH? A replacement for FORTH? Written in FORTH? Extensive but not Extinsible? Looks like a neat idea. Could you elaborate? > John J Wavrik > jjwavrik@ucsd.edu Dept of Math C-012 > Univ of Calif - San Diego > La Jolla, CA 92093 -raybro RAYBRO%UTRC%utrcgw.utc.com@RELAY.CS.NET (I think...)