From - Wed Jan 5 11:47:19 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05AlIHj033565 for ; Wed, 5 Jan 2005 11:47:18 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1Cm8h6-0005pl-Ef; Wed, 05 Jan 2005 11:47:13 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j05AlCT0000145519; Wed, 5 Jan 2005 11:47:12 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Newsgroups: comp.text.tex Date: Wed, 5 Jan 2005 11:47:10 +0100 (MET) From: Laurence Finston To: metafont@ens.fr, metapost@tug.org Subject: Re: [metapost] all intersections between two paths In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 11:47:18 +0100 (CET) Hello Antonio, I'm posting this to the mailing lists for the following reasons: 1. I've been a subscriber to the Metafont list for some time, and I don't remember this question coming up. 2. The Metapost list is new and I know this question hasn't come up. The question is about finding all of the intersections of two arbitrary `paths'. On Wed, 5 Jan 2005, Antonio Ramirez wrote: > Laurence Finston wrote: > > > > Plain Metafont does not provide a way of doing this, so if you're trying > > to find the intersections of arbitrary `paths', I think iterating > > through the subpaths would be be your best bet. Someone might have > > written a macro to solve this problem, though, so I suggest you post your > > query to `metafont@ens.fr' and `metapost@tug.org'. > > > > [...] > > Yeah, they are arbitrary paths. I tried my hand at it but apparently I > don't know enough about how subpaths are parameterized. The goal is to > have a macro that computes all the pairs (u,v) such that point u of p > equals point v of q, given paths p and q. > > The problem is this: say p1 is some path and I have > > p2 := subpath (t,infinity) of p1, > > then it is not always the case that (point s of p2) equals (point (s+t) > of p1) as seemed reasonable to me at first; somehow I need to obtain the > parameter time in the original path p1, but this is apparently not the > way to do it. > Off the top of my head, I suspect it has to do with the "speed" of the `paths'. I think you should iterate over subpaths of length 1, but perhaps someone has a more clever suggestion. Laurence > > Meanwhile, thanks for your suggestions about mailing lists; I will > probably post my query there after reading through archives. > > Thanks, > > Antonio > From - Wed Jan 5 15:47:03 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05El1bL071472 for ; Wed, 5 Jan 2005 15:47:01 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CmCQz-0005xE-M2; Wed, 05 Jan 2005 15:46:51 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j05Ekn20000149840; Wed, 5 Jan 2005 15:46:49 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Newsgroups: comp.text.tex Date: Wed, 5 Jan 2005 15:46:47 +0100 (MET) From: Laurence Finston To: metafont@ens.fr, metapost@tug.org Subject: TeX and MF: Fast-loading of core image In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 15:47:01 +0100 (CET) Hello, In _METAFONT: The Program_, section 1203, p. 514, Knuth explains that INIMF (or maybe it's VIRMF, I don't have my copy with me) dumps core "[...] in a form that the operating system can reload speedily". (GNU m4 can also do something similar, or perhaps identical.) He does not, however, explain how this is done, as it is system dependent. I'd really appreciate it if somebody would explain to me how to do this on a GNU/Linux system, or point me in the right direction, so I could find out for myself. Thanks. Laurence Finston http://www.gnu.org/software/3dldf/LDF.html From - Wed Jan 5 15:51:27 2005 Return-Path: Received: from elise.covercraft.com (elise.covercraft.com [216.60.144.98]) by nef2.ens.fr (8.12.11/1.01.28121999) with SMTP id j05EpMCk073924 for ; Wed, 5 Jan 2005 15:51:23 +0100 (CET) Received: from (10.1.1.35) by elise.covercraft.com via smtp id 0173_876fae92_5f29_11d9_9cc3_000d606b36d9; Wed, 05 Jan 2005 08:53:16 -0600 (CST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [metafont] TeX and MF: Fast-loading of core image X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 5 Jan 2005 08:51:12 -0600 Message-ID: <4A8EC263815D4541BB3A5212E451B7812A5C22@EXCHANGE03.covercraft.ind> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [metafont] TeX and MF: Fast-loading of core image Thread-Index: AcTzNb6h6iKh7k3YTGunsY1dVPbFaAAABcwA From: "Driver, David" To: "Laurence Finston" , , X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 15:51:24 +0100 (CET) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nef2.ens.fr id j05EpMCk073924 Where are the administration pages for the metafont and metapost mailing lists? I haven't used Tex in a long time and I need to be removed from the lists. -----Original Message----- From: Laurence Finston [mailto:lfinsto1@gwdg.de] Sent: Wednesday, January 05, 2005 8:47 AM To: metafont@ens.fr; metapost@tug.org Subject: [metafont] TeX and MF: Fast-loading of core image Hello, In _METAFONT: The Program_, section 1203, p. 514, Knuth explains that INIMF (or maybe it's VIRMF, I don't have my copy with me) dumps core "[...] in a form that the operating system can reload speedily". (GNU m4 can also do something similar, or perhaps identical.) He does not, however, explain how this is done, as it is system dependent. I'd really appreciate it if somebody would explain to me how to do this on a GNU/Linux system, or point me in the right direction, so I could find out for myself. Thanks. Laurence Finston http://www.gnu.org/software/3dldf/LDF.html From - Wed Jan 5 16:52:03 2005 Return-Path: Received: from glenfiddich.elvenkind.com (elvenknd.xs4all.nl [213.84.171.68]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05Fpxmk008496 for ; Wed, 5 Jan 2005 16:51:59 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by glenfiddich.elvenkind.com (Postfix) with ESMTP id 6D304390D6; Wed, 5 Jan 2005 16:48:38 +0100 (CET) Received: from glenfiddich.elvenkind.com ([127.0.0.1]) by localhost (glenfiddich.elvenkind.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13872-06; Wed, 5 Jan 2005 16:48:35 +0100 (CET) Received: from [10.10.0.6] (glenlivet.elvenkind.com [10.10.0.6]) by glenfiddich.elvenkind.com (Postfix) with ESMTP id 18E48390D1; Wed, 5 Jan 2005 16:48:35 +0100 (CET) Message-ID: <41DC0D1B.8040105@elvenkind.com> Date: Wed, 05 Jan 2005 16:51:55 +0100 From: Taco Hoekwater User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Laurence Finston Cc: metapost@tug.org, metafont@ens.fr Subject: Re: [metapost] TeX and MF: Fast-loading of core image References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at elvenkind.net X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 16:51:59 +0100 (CET) Hi Laurence, A loooong time ago, there used to be dump/undump binaries in the Linux distro's, but that was in the a.out era; a prehistoric age wherein CPU cycles were more time-expensive then disk I/O. Nowadays, people do not worry that much about cpu cycles burned during initialization, because actually loading extra junk from the harddisk is often slower that alloc()-ing. About the only program that bothers with undumping these days is an ancient relic: GNU Emacs. It has a gazillion subroutines to deal with all the combinations of binary loader/file format, and the Elf/Linux one reportedly works. You may want to look at this file: http://www-ap.fnal.gov/~kriol/source/HotStart.tar.gz The guy who created the tar file (and website) shares your rather morbid interest in the subject ;-) Greetings, Taco Laurence Finston wrote: > Hello, > > In _METAFONT: The Program_, section 1203, p. 514, Knuth explains that > INIMF (or maybe it's VIRMF, I don't have my copy with me) dumps core > "[...] in a form that the operating system can reload speedily". > (GNU m4 can also do something similar, or perhaps identical.) > > He does not, however, explain how this is done, as it is system dependent. > > I'd really appreciate it if somebody would explain to me how to do this on > a GNU/Linux system, or point me in the right direction, so I could find > out for myself. > > Thanks. > > Laurence Finston > http://www.gnu.org/software/3dldf/LDF.html > > _______________________________________________ > metapost mailing list > http://tug.org/mailman/listinfo/metapost From - Wed Jan 5 17:01:03 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05G0xdS013308 for ; Wed, 5 Jan 2005 17:00:59 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CmDaj-0004q7-DB; Wed, 05 Jan 2005 17:00:59 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j05G0up0000150965; Wed, 5 Jan 2005 17:00:56 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Wed, 5 Jan 2005 17:00:56 +0100 (MET) From: Laurence Finston To: Taco Hoekwater cc: metapost@tug.org, metafont@ens.fr Subject: Re: [metapost] TeX and MF: Fast-loading of core image In-Reply-To: <41DC0D1B.8040105@elvenkind.com> Message-ID: References: <41DC0D1B.8040105@elvenkind.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 17:00:59 +0100 (CET) Hi Taco, On Wed, 5 Jan 2005, Taco Hoekwater wrote: > > Nowadays, people do not worry that much about cpu cycles burned > during initialization, because actually loading extra junk from > the harddisk is often slower that alloc()-ing. What about TeX and MF? Do you (or does anybody) happen to know what current distributions do? Thanks for your reply and the link. I do still want to learn how to do it, even if it's not strictly speaking necessary on modern systems. Laurence From - Wed Jan 5 18:10:15 2005 Return-Path: Received: from mta1.cl.cam.ac.uk (mta1.cl.cam.ac.uk [128.232.0.15]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05HAD4X051659 for ; Wed, 5 Jan 2005 18:10:13 +0100 (CET) Received: from mole.cl.cam.ac.uk ([128.232.8.151] helo=cl.cam.ac.uk ident=[3syw2f4sdpOwPUZTweVC68upJP6ioFT3]) by mta1.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 1CmEfd-0004RH-00; Wed, 05 Jan 2005 17:10:05 +0000 To: Laurence Finston cc: metapost@tug.org, metafont@ens.fr Subject: Re: [metafont] Re: [metapost] TeX and MF: Fast-loading of core image In-reply-to: Your message of Wed, 05 Jan 2005 17:00:56 +0100. Date: Wed, 05 Jan 2005 17:09:57 +0000 From: Robin Fairbairns Message-Id: X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 18:10:13 +0100 (CET) > Hi Taco, > > On Wed, 5 Jan 2005, Taco Hoekwater wrote: > > > > > Nowadays, people do not worry that much about cpu cycles burned > > during initialization, because actually loading extra junk from > > the harddisk is often slower that alloc()-ing. > > What about TeX and MF? Do you (or does anybody) happen to know what > current distributions do? the \dump command writes a tex format; dump writes an mf format. that's all that current distributions do. the "dump core and reload it" scheme, where an entire application and its bss and all were written to disc, went out before i started using tex on un*x in 1992. afaik, it never happened under vms, which was what i was using before 1992. > Thanks for your reply and the link. I do still want to learn how to do > it, even if it's not strictly speaking necessary on modern systems. just to provoke you, i'll point out that there are latex macros designed for dumping formats which include the entire headers of documents. From - Wed Jan 5 18:10:31 2005 Return-Path: Received: from post-22.mail.nl.demon.net (post-22.mail.nl.demon.net [194.159.73.192]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05HAJhV051713 for ; Wed, 5 Jan 2005 18:10:19 +0100 (CET) Received: from boo.demon.nl ([82.161.175.147]:48601 helo=[192.168.1.3]) by post-22.mail.nl.demon.net with esmtp (Exim 4.34) id 1CmEfo-000O4T-QC; Wed, 05 Jan 2005 17:10:16 +0000 Message-ID: <41DC1F76.8050300@elvenkind.com> Date: Wed, 05 Jan 2005 18:10:14 +0100 From: Taco Hoekwater User-Agent: Mozilla Thunderbird 0.8 (X11/20040923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Laurence Finston CC: metapost@tug.org, metafont@ens.fr Subject: Re: [metapost] TeX and MF: Fast-loading of core image References: <41DC0D1B.8040105@elvenkind.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 18:10:19 +0100 (CET) Laurence Finston wrote: > What about TeX and MF? Do you (or does anybody) happen to know what > current distributions do? I know what web2c-based distro's do: they convert Knuth's pascal code to the C source output, then allow the C compiler gcc to compile it into the executable. Which is just another way of saying that they do nothing special at all. If you really want to try to implement dumping, look for 'ready_already' in the web source, and combine the code & explanation at those locations with the code & explanation from the README in that archive I gave you the link to. If that doesn't help you figure it out, nothing else will. Greetings, Taco From - Wed Jan 5 18:12:11 2005 Return-Path: Received: from mailrelay01.solcon.nl (maillb.solcon.nl [212.45.32.200]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05HC7I0052686 for ; Wed, 5 Jan 2005 18:12:07 +0100 (CET) Received: from server-1.pragma-net.nl (dsl-212-84-128-085.solcon.nl [212.84.128.85]) by mailrelay01.solcon.nl (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id j05HC3UE008193; Wed, 5 Jan 2005 18:12:03 +0100 Received: by server-1.pragma-net.nl (Postfix, from userid 65534) id 287C31855E; Wed, 5 Jan 2005 18:08:14 +0100 (CET) Received: from [10.100.1.191] (unknown [10.100.1.191]) by server-1.pragma-net.nl (Postfix) with ESMTP id E929217B14; Wed, 5 Jan 2005 17:08:12 +0000 (UTC) Message-ID: <41DC1FE5.1060903@wxs.nl> Date: Wed, 05 Jan 2005 18:12:05 +0100 From: Hans Hagen User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Laurence Finston Cc: Taco Hoekwater , metapost@tug.org, metafont@ens.fr Subject: Re: [metafont] Re: [metapost] TeX and MF: Fast-loading of core image References: <41DC0D1B.8040105@elvenkind.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.5 required=7.5 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Virus-Scanned: ClamAV 0.80/540/Tue Oct 19 14:59:23 2004 clamav-milter version 0.80j on mailrelay01 X-Virus-Status: Clean X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 18:12:08 +0100 (CET) Laurence Finston wrote: > What about TeX and MF? Do you (or does anybody) happen to know what > current distributions do? normally macro packages are dumped (i.e. mem saved to disk with a bit of compression and byte shuffling) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl ----------------------------------------------------------------- From - Wed Jan 5 18:23:13 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05HNBxZ059098 for ; Wed, 5 Jan 2005 18:23:11 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CmEsH-0006zR-V9; Wed, 05 Jan 2005 18:23:11 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j05HN9Q0000152025; Wed, 5 Jan 2005 18:23:09 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Wed, 5 Jan 2005 18:23:08 +0100 (MET) From: Laurence Finston To: Taco Hoekwater cc: metapost@tug.org, metafont@ens.fr Subject: Re: [metapost] TeX and MF: Fast-loading of core image In-Reply-To: <41DC1F76.8050300@elvenkind.com> Message-ID: References: <41DC0D1B.8040105@elvenkind.com> <41DC1F76.8050300@elvenkind.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 18:23:11 +0100 (CET) On Wed, 5 Jan 2005, Taco Hoekwater wrote: > If you really want to try to implement dumping, look for 'ready_already' > in the web source, and combine the code & explanation at those locations > with the code & explanation from the README in that archive I gave you > the link to. If that doesn't help you figure it out, nothing else will. > That sounds like good advice, thanks. The README in the archive didn't explain much, so I'll have to have a look at the code when I get a chance. Thanks to everyone who's responded. I'm still interested, in case anyone else has something to say on the subject. However, the upshot of your responses seems to be that it would be A) difficult and B) unnecessary, so maybe I won't do it after all. Things seem to have been going downhill ever since they invented punch cards. Laurence From - Wed Jan 5 18:48:02 2005 Return-Path: Received: from mailrelay02.solcon.nl (maillb.solcon.nl [212.45.32.200]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05HlxUc071150 for ; Wed, 5 Jan 2005 18:47:59 +0100 (CET) Received: from server-1.pragma-net.nl (dsl-212-84-128-085.solcon.nl [212.84.128.85]) by mailrelay02.solcon.nl (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id j05HltkO015824; Wed, 5 Jan 2005 18:47:55 +0100 Received: by server-1.pragma-net.nl (Postfix, from userid 65534) id E54ED1855D; Wed, 5 Jan 2005 18:44:05 +0100 (CET) Received: from [10.100.1.191] (unknown [10.100.1.191]) by server-1.pragma-net.nl (Postfix) with ESMTP id EE82B17B14; Wed, 5 Jan 2005 17:44:04 +0000 (UTC) Message-ID: <41DC284D.9040901@wxs.nl> Date: Wed, 05 Jan 2005 18:47:57 +0100 From: Hans Hagen User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Laurence Finston Cc: Taco Hoekwater , metapost@tug.org, metafont@ens.fr Subject: Re: [metafont] Re: [metapost] TeX and MF: Fast-loading of core image References: <41DC0D1B.8040105@elvenkind.com> <41DC1F76.8050300@elvenkind.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.1 required=7.5 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Virus-Scanned: ClamAV 0.80/540/Tue Oct 19 14:59:23 2004 clamav-milter version 0.80j on mailrelay02 X-Virus-Status: Clean X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 18:48:00 +0100 (CET) Laurence Finston wrote: > do it after all. Things seem to have been going downhill > ever since they invented punch cards. eh ... downhill? you want to go back to the time that Don K wrote the texbook: 64 K memory and this 1 meg dvi file filling up your whole disk after probably a full night processing time? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl ----------------------------------------------------------------- From - Wed Jan 5 18:56:31 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05HuTm1075534 for ; Wed, 5 Jan 2005 18:56:29 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CmFOX-0001iD-AL; Wed, 05 Jan 2005 18:56:29 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j05HuSa0000152471; Wed, 5 Jan 2005 18:56:28 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Wed, 5 Jan 2005 18:56:28 +0100 (MET) From: Laurence Finston To: Hans Hagen cc: Taco Hoekwater , metapost@tug.org, metafont@ens.fr Subject: Re: [metafont] Re: [metapost] TeX and MF: Fast-loading of core image In-Reply-To: <41DC284D.9040901@wxs.nl> Message-ID: References: <41DC0D1B.8040105@elvenkind.com> <41DC1F76.8050300@elvenkind.com> <41DC284D.9040901@wxs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 18:56:29 +0100 (CET) On Wed, 5 Jan 2005, Hans Hagen wrote: > > eh ... downhill? you want to go back to the time that Don K wrote the texbook: > 64 K memory and this 1 meg dvi file filling up your whole disk after probably a > full night processing time? > Not really. I just have a certain fondness for obsolete technology. Some things are much better, of course, but it seems to me that modern hardware and software sometimes takes some of the fun out of programming. On the other hand, we can do lots of things now that weren't possible in "the good old days", so I guess it's a trade-off, like in so many other areas. Laurence From - Wed Jan 5 19:12:16 2005 Return-Path: Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by nef2.ens.fr (8.12.11/1.01.28121999) with SMTP id j05ICCcp084871 for ; Wed, 5 Jan 2005 19:12:12 +0100 (CET) Received: (qmail invoked by alias); 05 Jan 2005 18:12:12 -0000 Received: from p508BD1C3.dip0.t-ipconnect.de (EHLO hahepc1.hahe) (80.139.209.195) by mail.gmx.net (mp005) with SMTP; 05 Jan 2005 19:12:12 +0100 X-Authenticated: #6218946 Received: from hahe (helo=localhost) by hahepc1.hahe with local-esmtp (Exim 4.41) id 1CmFdi-0000ix-7E; Wed, 05 Jan 2005 19:12:10 +0100 Date: Wed, 5 Jan 2005 19:12:10 +0100 (CET) From: Hartmut Henkel To: Laurence Finston cc: metafont@ens.fr Subject: Re: [metapost] TeX and MF: Fast-loading of core image In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Y-GMX-Trusted: 0 X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 19:12:12 +0100 (CET) On Wed, 5 Jan 2005, Laurence Finston wrote: > In _METAFONT: The Program_, section 1203, p. 514, Knuth explains that > INIMF (or maybe it's VIRMF, I don't have my copy with me) dumps core > "[...] in a form that the operating system can reload speedily". (GNU > m4 can also do something similar, or perhaps identical.) > > He does not, however, explain how this is done, as it is system dependent. > > I'd really appreciate it if somebody would explain to me how to do > this on a GNU/Linux system, or point me in the right direction, so I > could find out for myself. See e. g. http://vx.netlux.org/lib/vsc03.html You can force dump core by sending the process the right signal, e. g. /bin/kill -SIGSEGV . Often core dumps are generated only if ulimit is set to a sufficiently large value, e. g. set: $ ulimit -c 10000000 Then (for Linux) a new ELF binary must be generated from the core file. I tried it (needs a slightly changed kill line here) $ kill -SIGSEGV `ps waux |grep test_harness|grep -v grep|awk '{print $2}'` but program core_reconstruct dumped core itself during conversion of a tex core, same with mf; the example from the webpage worked however. Maybe somewhere on the internet another program is floating around that does the ELF conversion more robustly... Regards, Hartmut From - Wed Jan 5 19:52:11 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05Iq83s005175 for ; Wed, 5 Jan 2005 19:52:08 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CmGG4-0001eN-9h; Wed, 05 Jan 2005 19:52:03 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j05IplU0000153151; Wed, 5 Jan 2005 19:51:47 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Wed, 5 Jan 2005 19:51:47 +0100 (MET) From: Laurence Finston To: antonio@math.stanford.edu cc: metafont@ens.fr, metapost@tug.org Subject: Re: [metapost] all intersections between two paths In-Reply-To: <73903beb05010510255fb69778@mail.gmail.com> Message-ID: References: <73903beb05010510255fb69778@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 19:52:08 +0100 (CET) I'd try something like the following. Please note that it's a sort of pseudo-code, since I don't have time (or the inclination) to work out a real example. This means you'll probably have to fiddle with it. You'll also have to catch the cases that the subpaths don't intersect and eliminate duplicate `pairs' (if it's possible to have them). Unfortunately, I'm not a good enough mathematician to be able to tell you whether `paths' of length 1 can have discontinuities, or whether two of them can have more than one intersection. Laurence **************************************************** path a, b; a = [...] b = [...] length_a = length a; length_b = length b; pair p[]; ctr = 0; for i = 0 upto length_a - 1: for j = 0 upto length_b - 1: p[ctr] = subpath (i, i + 1) of a intersectionpoint subpath (j, j + 1) of b; ctr = incr ctr; endfor; endfor; On Wed, 5 Jan 2005, Antonio Ramirez wrote: > For what it's worth, below is my last attempt at writing the macro, > [...] From - Wed Jan 5 19:54:48 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05IshVE006703 for ; Wed, 5 Jan 2005 19:54:43 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CmGIt-0002b5-BS; Wed, 05 Jan 2005 19:54:43 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j05Isc20000153205; Wed, 5 Jan 2005 19:54:43 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Wed, 5 Jan 2005 19:54:37 +0100 (MET) From: Laurence Finston To: Hartmut Henkel cc: metafont@ens.fr Subject: Re: [metapost] TeX and MF: Fast-loading of core image In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 19:54:43 +0100 (CET) Thanks for the link and the information. I'll need some time to work through it. Laurence From - Wed Jan 5 20:22:31 2005 Return-Path: Received: from sunshine.math.utah.edu (sunshine.math.utah.edu [128.110.198.2]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05JMPF0021466 for ; Wed, 5 Jan 2005 20:22:26 +0100 (CET) Received: from psi.math.utah.edu (IDENT:hO3XBoBMbyjxxIdYYQCtcZ/avmNxw+zw@psi.math.utah.edu [155.101.96.19]) by sunshine.math.utah.edu (8.12.11/8.12.10) with ESMTP id j05JMEJL017987; Wed, 5 Jan 2005 12:22:14 -0700 (MST) Received: from psi.math.utah.edu (IDENT:kAMssCPbfoGMb2WsHwsuf4kBWtnxgv9f@localhost [127.0.0.1]) by psi.math.utah.edu (8.12.11/8.12.10) with ESMTP id j05JMEvl027521; Wed, 5 Jan 2005 12:22:14 -0700 (MST) Received: (from beebe@localhost) by psi.math.utah.edu (8.12.11/8.12.10/Submit) id j05JMEXm027520; Wed, 5 Jan 2005 12:22:14 -0700 (MST) Date: Wed, 5 Jan 2005 12:22:14 -0700 (MST) From: "Nelson H. F. Beebe" To: metafont@ens.fr, metapost@tug.org Cc: beebe@math.utah.edu X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Dumping preloaded executables in the [g]?olden days Message-ID: X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 20:22:26 +0100 (CET) Laurence Finston asks this morning on the metafont/metapost lists about preloading TeX and Metafont with already-compiled/processed macro packages. Below is a demonstration in TOPS-20 on the KLH10 simulator that I ran just now to show how easy it was for Don Knuth to provide for preloading of large macro packages in TeX and Metafont on TOPS-20. The KLH10 simulator, running on a Sun Blade 2500 with dual 1.28GHz CPUs, is about six times faster than our original DEC-20/60 was; that system was retired on 31-Oct-1990. The original system cost was over $250K, and one served the College of Science at Utah for 12 years, and another the Department of Computer Science for about 10 years. Now with either of two PDP-10 simulators, I can relive life on TOPS-20 (for me, 1978--1990). I arrived in Utah a year after Don Knuth began the TeX project at Stanford, and we both had similar machines. At the time, DEC-10s and DEC-20s (different O/S, similar PDP-10 hardware) were the backbone of the Arpanet, of which Utah and Stanford were two of the five founders in 1969 --- the others were UC/Berkeley, UC/Los Angeles, and UC/Santa Barbara. My system ran TOPS-20, Don's ran LOTS (Low-Overhead Timesharing System) at SCORE, and Richard Stallman's ran ITS (Incompatible Timesharing System) at MIT. Code developed on any of these would run with minor mods on the others because of the common PDP-10 hardware. Thus, we all had, used, and loved Richard's Emacs built on top of Dan Murphy's TECO (Text Editor and Corrector). Dan's wife Sarah headed the DEC Fortran team, and I'm writing this message in mm (a C translation from Columbia University of the original DEC-20 assembly-coded mail program) and GNU Emacs (a reimplementation in C and Lisp of the original TECO and assembly-coded PDP-10 emacs) ... see how we're all connected! Although TeX and Metafont started out written in SAIL (Stanford Artificial Intelliengence Language) [Don says that it was because SAIL had a good debugger], the 1981--1982 rewrite in Pascal relied on the availability of Chuck Hedrick's excellent Pascal compiler from Rutgers, bootstrapped in Pascal and PDP-10 assembly code, if I recall correctly. Here is the demonstration (using Fortran, because that is the only compiler that I have at the moment): ;;; The funny mixed case happens when I type ESCape for command and ;;; filename completion. @dayTIME Wednesday, January 5, 2005 11:59:19 @infORMATION (ABOUT) verSION TOPS-20AN Maximum System, TOPS-20AN Monitor 7(21017) TOPS-20 Command processor 7(4143) @type restRT.foR.3 00100 program restart 00200 * Demonstrate TOPS-20 restart 00300 character*40 line1, line2 00400 logical init 00500 data init /.false./ 00600 if (.not. init) then 00700 write (6,'('' ONE: Enter a line of data: '', $)') 00800 read (5,'(a)') line1 00900 write (6,'('' You typed: ['' A '']'')') line1 01000 init = .true. 01100 end if 01200 write (6,'('' TWO: Enter a line of data: '', $)') 01300 read (5,'(a)') line2 01400 write (6,'('' You typed: ['' A '']'')') line2 01500 write (6,'('' You originally typed: ['' A '']'')') line1 01600 call exit 01700 end ;;; Compile and link the program into an executable image in memory @load restrt.for FORTRAN: RESTRT RESTART LINK: Loading ;;; Save the memory image as an executable program @save restrt RESTRT.EXE.1 Saved ;;; Run the program, and interrupt it with Ctl-C after the second prompt @run restrt ONE: Enter a line of data: Initial stuff You typed: [Initial stuff ] TWO: Enter a line of data: ^C ;;; Save the interrupted image as an new program @savE (on file) new-restrt NEW-RESTRT.EXE.1 Saved ;;; Run the interrupted program: notice that it continues from ;;; the point that it left off, because init is now .true. ;;; All of its local variables are still available, because they ;;; are static in C-ese (i.e., not allocated on the stack). @run NEW-RESTRT TWO: Enter a line of data: More stuff You typed: [More stuff ] You originally typed: [Initial stuff ] CPU time 0.01 Elapsed time 3.78 TeX and Metafont use a magic integer constant instead of a Boolean variable: ready_already has the value 314159 after the initial processing. No special hacks or magic system calls were needed to do this, so even user programs on TOPS-20 made use of the feature to eliminate the overhead of reprocessing startup data on every run. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From - Wed Jan 5 22:46:55 2005 Return-Path: Received: from mailhost.uark.edu (mail.uark.edu [130.184.5.66]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05LkpGA090256 for ; Wed, 5 Jan 2005 22:46:51 +0100 (CET) Received: from comp.uark.edu (comp.uark.edu [130.184.5.197]) by mailhost.uark.edu (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPS id <0I9V00G345U27X@mailhost.uark.edu> for metafont@ens.fr; Wed, 05 Jan 2005 15:46:50 -0600 (CST) Date: Wed, 05 Jan 2005 15:46:50 -0600 (CST) From: "Daniel H. Luecking" Subject: Re: [metapost] all intersections between two paths In-reply-to: To: Metafont distribution list Cc: metapost@tug.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 22:46:51 +0100 (CET) On Wed, 5 Jan 2005, Laurence Finston wrote: > Hello Antonio, > > I'm posting this to the mailing lists for the following reasons: > > 1. I've been a subscriber to the Metafont list for some time, and I > don't remember this question coming up. > > 2. The Metapost list is new and I know this question hasn't come up. > > The question is about finding all of the intersections of two arbitrary > `paths'. > > > The problem is this: say p1 is some path and I have > > > > p2 := subpath (t,infinity) of p1, > > > > then it is not always the case that (point s of p2) equals (point (s+t) > > of p1) as seemed reasonable to me at first; somehow I need to obtain the > > parameter time in the original path p1, but this is apparently not the > > way to do it. Use of infinity gives a problem with cyclic paths, one can use (length p1) in its place. However, this has nothing to do with the problem at hand. If p2 = subpath (t, length p1) of p1; suppose that n = floor t; Then the first segment of p2 is subpath (t,n+1) of p1, but reparametrized. For the rest of p2 (s >= 1), point s of p2 = point n+s of p1. The first segment of p2 is reparametrized so that point 0 of p2 = point t of p1; and point 1 of p2 = point n+1 of p1 with linear interpolation in between (0 <= s <= 1): point s of p2 = point (1-s)*t + s of p1. In summary (n = floor t): point s of p2 = point s[t, n + 1] of p1, 0 <= s <= 1, = point s + n of p1, 1 <= s <= length p2. This is laid out in the Metafontbook (look up subpath in the index). -- Dan Luecking Dept. of Mathematical Sciences University of Arkansas Fayetteville, AR 72101 From - Wed Jan 5 23:30:56 2005 Return-Path: Received: from mailhost.uark.edu (mail.uark.edu [130.184.5.66]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05MUs6N010092 for ; Wed, 5 Jan 2005 23:30:54 +0100 (CET) Received: from mathfolk.uark.edu ([130.184.197.23]) by mailhost.uark.edu (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I9V00G2X7VH7X@mailhost.uark.edu> for metafont@ens.fr; Wed, 05 Jan 2005 16:30:54 -0600 (CST) Date: Wed, 05 Jan 2005 16:33:05 -0600 From: Dan Luecking Subject: Re: [metapost] all intersections between two paths In-reply-to: To: metafont@ens.fr Cc: metapost@tug.org Message-id: <6.2.0.14.0.20050105160415.01c30650@mail.uark.edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <73903beb05010510255fb69778@mail.gmail.com> X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 23:30:54 +0100 (CET) At 12:51 PM 1/5/2005, you wrote: >Unfortunately, I'm not a good enough mathematician to be able to >tell you whether `paths' of length 1 can have discontinuities, >or whether two of them can have more than one intersection. Paths can't have discontinuities at all. However, calculations of points on paths *can* be discontinuous because MF's numeric resolution is limited to 2^{-16}. Also, there are cases where an intersection is not detected (by intersectiontimes) if it occurs at a node of one of the paths. Mathematically, paths of length 1 can intersect as many as 9 times. Actually, infinitely many if they happen to be dependent. For example, (0,0)--(1,0) and (1/3,0)--(2/3,0). >path a, b; > >a = [...] >b = [...] > >length_a = length a; >length_b = length b; > >pair p[]; > >ctr = 0; > >for i = 0 upto length_a - 1: > for j = 0 upto length_b - 1: You can save length_a subtraction operations if you set length_b = length b - 1 and use that here. > p[ctr] = subpath (i, i + 1) of a intersectionpoint > subpath (j, j + 1) of b; Just replace this with a routine that computes all intersections and you have it. Reducing to subpaths of length 1 has the advantage of making the time-matching consistent (see my earlier response to Antonio), so the code will be easier. I would do a binary search within such segments. If I have the time (and someone doesn't do it before me) I'll try to produce some actual code. > ctr = incr ctr; Skip this step if they don't intersect. > endfor; >endfor; Dan Daniel H. Luecking Department of Mathematical Sciences University of Arkansas From - Wed Jan 5 23:58:16 2005 Return-Path: Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.191]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05Mw6aq022655 for ; Wed, 5 Jan 2005 23:58:09 +0100 (CET) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CmK6Q-00068r-00 for metafont@ens.fr; Wed, 05 Jan 2005 23:58:06 +0100 Received: from [213.182.136.48] (helo=homer.bertram-scharpf) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1CmK6P-0008JD-00 for metafont@ens.fr; Wed, 05 Jan 2005 23:58:06 +0100 Received: from berti by homer.bertram-scharpf with local (Exim 3.35 #1 (Debian)) id 1CmFxq-00017N-00 for ; Wed, 05 Jan 2005 19:32:58 +0100 Date: Wed, 5 Jan 2005 19:32:57 +0100 From: Bertram Scharpf To: metafont@ens.fr Subject: Re: [metafont] Re: [metapost] TeX and MF: Fast-loading of core image Message-ID: <20050105183257.GA1825@homer.bertram-scharpf> Mail-Followup-To: metafont@ens.fr References: <41DC0D1B.8040105@elvenkind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i Sender: Bertram Scharpf X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:5fac24dba2c774fa1e9ed5da23bde0be X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 05 Jan 2005 23:58:09 +0100 (CET) Hi Laurence, Am Mittwoch, 05. Jan 2005, 17:00:56 +0100 schrieb Laurence Finston: > Thanks for your reply and the link. I do still want to learn how to do > it, even if it's not strictly speaking necessary on modern systems. what's so wrong with _METAFONTbook_, p. 221: execute `inimf' and say `dump' instead of `end'? Maybe I misunderstood your problem. Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de From - Thu Jan 6 00:08:02 2005 Return-Path: Received: from zarquon.dynamic.ip (stu1ir200-101-164.ras.tesion.net [195.226.101.164]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j05N7s7g026498 for ; Thu, 6 Jan 2005 00:07:55 +0100 (CET) Received: from zarquon.dynamic.ip (localhost [127.0.0.1]) by zarquon.dynamic.ip (8.12.3/8.12.3/Debian-7.1) with ESMTP id j05N8r3i001470; Thu, 6 Jan 2005 00:08:53 +0100 Received: (from vieth@localhost) by zarquon.dynamic.ip (8.12.3/8.12.3/Debian-7.1) id j05N8lb8001450; Thu, 6 Jan 2005 00:08:47 +0100 Date: Thu, 6 Jan 2005 00:08:47 +0100 Message-Id: <200501052308.j05N8lb8001450@zarquon.dynamic.ip> To: taco@elvenkind.com CC: lfinsto1@gwdg.de, metapost@tug.org, metafont@ens.fr In-reply-to: <41DC0D1B.8040105@elvenkind.com> (message from Taco Hoekwater on Wed, 05 Jan 2005 16:51:55 +0100) Subject: Re: [metafont] Re: [metapost] TeX and MF: Fast-loading of core image From: Ulrik Vieth Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit References: <41DC0D1B.8040105@elvenkind.com> X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Thu, 06 Jan 2005 00:07:56 +0100 (CET) > A loooong time ago, there used to be dump/undump binaries in the > Linux distro's, but that was in the a.out era; a prehistoric age > wherein CPU cycles were more time-expensive then disk I/O. You can find a complete archive of a TeX 2.95 Unix distribution from around 1988 or 1989 at the following site: ftp://ftp.tug.org/historic/systems/unix/TeX2.95/ You probably would have to look at the file undump.tar.Z to find out how it was down for Unix TeX in the 1980s. If you want to know how it was done at SAIL at Stanford, you might want to look at the SAILDART archive: http://z.baumgart.org/saildart/prog/SYS/TEX_SYS/.browser.html http://z.baumgart.org/saildart/prog/SYS/_MF_SYS/.browser.html I don't know if there is anything useful about dumping/undumping, but it's the best resource there is for the really old stuff. Cheers, Ulrik. From - Thu Jan 6 10:30:36 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j069UZgj013641 for ; Thu, 6 Jan 2005 10:30:35 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CmTyO-00070F-21; Thu, 06 Jan 2005 10:30:30 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j069UK50000164413; Thu, 6 Jan 2005 10:30:20 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Thu, 6 Jan 2005 10:30:20 +0100 (MET) From: Laurence Finston To: Bertram Scharpf cc: metafont@ens.fr, metapost@tug.org Subject: Re: [metafont] Re: [metapost] TeX and MF: Fast-loading of core image In-Reply-To: <20050105183257.GA1825@homer.bertram-scharpf> Message-ID: References: <41DC0D1B.8040105@elvenkind.com> <20050105183257.GA1825@homer.bertram-scharpf> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Thu, 06 Jan 2005 10:30:35 +0100 (CET) On Wed, 5 Jan 2005, Bertram Scharpf wrote: > > what's so wrong with _METAFONTbook_, p. 221: execute `inimf' > and say `dump' instead of `end'? > > Maybe I misunderstood your problem. > There are two issues involved: Dumping to create a fast-loading format file and dumping core in order to avoid costly initialization each time one starts the program. These are two different kinds of dumping. I've never done the first kind with INIMF, but it's no problem with INITEX. I didn't consider the fact that it is possible to load the source for a format before dumping core, although this seems to have been done in the past, if I've understood what people have said correctly. Laurence From - Thu Jan 6 10:36:04 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j069a0C9017133 for ; Thu, 6 Jan 2005 10:36:00 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CmU3C-0000Tg-2q; Thu, 06 Jan 2005 10:35:54 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j069ZJQ0000165118; Thu, 6 Jan 2005 10:35:19 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Thu, 6 Jan 2005 10:35:19 +0100 (MET) From: Laurence Finston To: "Nelson H. F. Beebe" cc: metafont@ens.fr, metapost@tug.org Subject: Re: [metafont] Dumping preloaded executables in the [g]?olden days In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Thu, 06 Jan 2005 10:36:00 +0100 (CET) On Wed, 5 Jan 2005, Nelson H. F. Beebe wrote: > Below is a demonstration in TOPS-20 on the KLH10 simulator that I ran > just now to show how easy it was for Don Knuth to provide for > preloading of large macro packages in TeX and Metafont on TOPS-20. > [...] Thank you very much. I'm going to need some time to work through this, though. I especially enjoyed your "trip down memory lane". I didn't start programming until 1991, so I missed out on that era. Laurence From - Thu Jan 6 11:17:56 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j06AHm8v039758 for ; Thu, 6 Jan 2005 11:17:48 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CmUi7-0008Gu-GY; Thu, 06 Jan 2005 11:17:43 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j06AHgO0000168466; Thu, 6 Jan 2005 11:17:42 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Thu, 6 Jan 2005 11:17:42 +0100 (MET) From: Laurence Finston To: antonio@math.stanford.edu, Dan Luecking cc: metafont@ens.fr, metapost@tug.org Subject: Re: [metafont] Re: [metapost] all intersections between two paths In-Reply-To: <6.2.0.14.0.20050105160415.01c30650@mail.uark.edu> Message-ID: References: <73903beb05010510255fb69778@mail.gmail.com> <6.2.0.14.0.20050105160415.01c30650@mail.uark.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Thu, 06 Jan 2005 11:17:48 +0100 (CET) On Wed, 5 Jan 2005, Dan Luecking wrote: > Paths can't have discontinuities at all. However, calculations of > points on paths *can* be discontinuous because MF's numeric resolution > is limited to 2^{-16}. > Thanks for the information. I'll have to look up the definition of "discontinuity". I found something in the _MFbook_ which expresses something similar to what I was thinking: Knuth gives an example of a `path' of length 1 that forms a "cusp", but indicates that one must specify the control points to achieve this effect. > Also, there are cases where an intersection is not detected (by > intersectiontimes) if it occurs at a node of one of the paths. > > Mathematically, paths of length 1 can intersect as many as 9 times. > Actually, infinitely many if they happen to be dependent. For example, > (0,0)--(1,0) and (1/3,0)--(2/3,0). > Given the manipulations possible with connectors, I think it may be difficult to filter out `paths' with infinitely many intersections. How does one arrive at the value 9 for the maximum number of intersections of other `paths' of length 1? Is there a (relatively) simple proof, or can I look this up somewhere? > Just replace this with a routine that computes all intersections and > you have it. Reducing to subpaths of length 1 has the advantage of > making the time-matching consistent (see my earlier response to Antonio), > so the code will be easier. `intersectiontimes' should be used, because `intersectionpoint' signals an error if none is found. With `intersectiontimes', one can check whether the result is (-1, -1). Reversing the subpaths, finding the intersection point, if any, and checking whether it's the same as the one found for the original subpaths would be an easy way to check whether they have more than one intersection point. [This would just be the first step of the binary search suggested by Dan Luecking.] I think it may not be foolproof, though, because of the way MF finds intersections of paths of length 1, i.e., using a "shuffled binary" representation. In this case, it might be worthwhile to convert the subpaths to paths of length 2, so that MF will find the first intersection point. This may not be worth the effort though. The points will probably have to be compared using an "epsilon" value, since I think they might not be _exactly_ the same. > > > ctr = incr ctr; > `=' should be `:=', of course. Please excuse my carelessness. Laurence From - Thu Jan 6 12:49:16 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j06BnCPG087249 for ; Thu, 6 Jan 2005 12:49:12 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CmW8e-0004G4-F2; Thu, 06 Jan 2005 12:49:12 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j06BnBo0000178267; Thu, 6 Jan 2005 12:49:11 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Thu, 6 Jan 2005 12:49:11 +0100 (MET) From: Laurence Finston To: Marcus Brinkmann cc: metapost@tug.org, metafont@ens.fr Subject: Re: [metafont] Re: [metapost] TeX and MF: Fast-loading of core image In-Reply-To: <87acrmn6g0.wl@ulysses.g10code.de> Message-ID: References: <41DC0D1B.8040105@elvenkind.com> <41DC1F76.8050300@elvenkind.com> <87acrmn6g0.wl@ulysses.g10code.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Thu, 06 Jan 2005 12:49:12 +0100 (CET) On Thu, 6 Jan 2005, Marcus Brinkmann wrote: > > Now, this is getting off-topic, but for what it's worth, I want to > reaffirm what the other people said: You don't really want to do it. > You don't want to do it. Repeat with us :) > Thanks for your response and your convincing arguments. The other people who have responded had already convinced me that it wasn't a good idea, but I'm still interested in knowing how to do it, even though I almost certainly won't actually do it (unless I ever have a lot of time on my hands). I wasn't going to try doing it for TeX or MF---I was considering doing it for GNU 3DLDF. > The reason is that any such approaches are extremely fragile. I know, > because I am working on operating systems, and our own system > (GNU/Hurd) I am very interested in the Hurd. It's actually the only operating system I'm really interested in, except insofar as I have to use GNU/Linux for developing my own software. I hope to have a computer of my own someday so I can try to port GNU 3DLDF to the Hurd. Laurence From - Sat Jan 8 02:29:13 2005 Return-Path: Received: from sunshine.math.utah.edu (sunshine.math.utah.edu [128.110.198.2]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j081T9Gi083488 for ; Sat, 8 Jan 2005 02:29:10 +0100 (CET) Received: from psi.math.utah.edu (IDENT:/v6rAU3SYXjOk7DcXzhPL1q7HVFCOpRi@psi.math.utah.edu [155.101.96.19]) by sunshine.math.utah.edu (8.12.11/8.12.10) with ESMTP id j081T8a0018470; Fri, 7 Jan 2005 18:29:08 -0700 (MST) Received: from psi.math.utah.edu (IDENT:g110Tz2tVFzwaGg6zmWSB24OTcfMfiOZ@localhost [127.0.0.1]) by psi.math.utah.edu (8.12.11/8.12.10) with ESMTP id j081T8uD017775; Fri, 7 Jan 2005 18:29:08 -0700 (MST) Received: (from beebe@localhost) by psi.math.utah.edu (8.12.11/8.12.10/Submit) id j081T3u1017774; Fri, 7 Jan 2005 18:29:03 -0700 (MST) Date: Fri, 7 Jan 2005 18:29:03 -0700 (MST) From: "Nelson H. F. Beebe" To: metafont@ens.fr, metapost@tug.org Cc: beebe@math.utah.edu X-US-Mail: "Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: [metafont] a final note on dumping preloaded executables in the [g]?olden days Message-ID: X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Sat, 08 Jan 2005 02:29:10 +0100 (CET) [I realize this is off topic for metafont and metapost, but I wanted to finish off a thread on this list with a final bit of archaelogical investigation.] I've reloaded some old TOPS-20 disks (for use on the simulator), and dug through them to find out exactly how we used to create dumped versions of TeX and Metafont on TOPS-20 on the DEC-20. My memory no longer retained the details. Here is a fragment of a batch control file (--latex.mic) that shows the procedure: @INITEX'A lplain *\dump @VIRTEX'A &lplain *^C @save tex:latex'a @rename lplain.fmt texformats: @delete lplain.lst The 'A gets substituted by a command-line parameter, normally empty. That was from the days before I wrote a Unix-like make implementation that let us put things in standard Makefiles, instead of the old way of having a gajillion specialized control files. For a bit more history, here is another control-file fragment that shows how TeX was compiled and linked: INITEX:: @enable @TeX:tangle *TeX.web *TeX.tops20-changes'a ! The change file is for INITEX *TeX.pas *TeX.pool @rename TeX.pool TeX: LOAD1:: @enable @set no default compile pas @load %"ERRORLEVEL:10 INITEX/SAVE/RUNAME:INITEX" /language:"'b" TeX.pas @rename iniTeX.exe TeX:iniTeX'a.exe @delete TeX.rel,TeX.pas That shows the original route: Web to Pascal to compiled program in just a few steps. Finally, let's compare a 1984 trip.log report with a more recent TeX typesetting "hello, world". Notice the table size differences: they are up to 400 times bigger nowadays. 1984: This is TeX, Version 1.1 (preloaded format=trip 84.7.8) 8 JUL 1984 21:05 ** &trip trip ... Here is how much of TeX's memory you used: 42 strings out of 1819 225 string characters out of 9287 2195&525 words of memory out of 2300&701 357 multiletter control sequences out of 2100 729 words of font info for 4 fonts, out of 20000 for 75 2 hyphenation exceptions out of 307 5i,7n,9p,113b,38s stack positions out of 200i,40n,60p,500b,600s Output written on trip.dvi (16 pages, 2888 bytes). 2004: Local version: This is TeX, Version 3.1415 (C version 6.1.2) (INITEX) 23 DEC 2004 08:17 Here is how much of TeX's memory you used: 5 strings out of 30802 28 string characters out of 496493 5915 words of memory out of 524286 925 multiletter control sequences out of 27000 14794 words of font info for 50 fonts, out of 400000 for 255 14 hyphenation exceptions out of 2003 8i,4n,0p,25b,22s stack positions out of 300i,40n,60p,3000b,4000s Output written on foo.dvi (1 page, 228 bytes). 2004: TeXlive-2004 version: This is TeXk, Version 3.141592 (Web2C 7.5.2) (format=tex 2004.1.3) 7 JAN 2005 18:10 Here is how much of TeX's memory you used: 5 strings out of 98002 33 string characters out of 1221682 5919 words of memory out of 1500022 926 multiletter control sequences out of 10000+50000 14794 words of font info for 50 fonts, out of 1000000 for 2000 14 hyphenation exceptions out of 1000 8i,4n,0p,25b,22s stack positions out of 5000i,500n,6000p,200000b,40000s Output written on foo.dvi (1 page, 228 bytes). How much did TeX change from 1989 (version 2.991) to 1993 (version 3.1415)? My archives, alas, have no older version of TeX sources. The tex.web file contains: 1989: 24032 lines 1993: 24907 lines A diff report has 4998 lines: 1640 old lines (prefixed with < in the diff output) became 2495 new lines (prefixed with >). In other words, about 7% of the TeX source code was affected by addition of support for 8-bit characters and a few new primitives. The source code logs them like this: % Version 2.991 caught .5\ifdim.6... (June 1989). % Version 2.992 introduced major changes for 8-bit extensions (September 1989). % Version 2.993 fixed a save_stack synchronization bug et alia (December 1989). % Version 3.0 fixed unusual displays; was more \output robust (March 1990). % Version 3.1 fixed nullfont, disabled \write{\the\prevgraf} (September 1990). % Version 3.14 fixed unprintable font names and corrected typos (March 1991). % Version 3.141 more of same; reconstituted ligatures better (March 1992). % Version 3.1415 preserved nonexplicit kerns, tidied up (February 1993). ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- From - Tue Jan 11 06:33:40 2005 Return-Path: Received: from coxeter.math.toronto.edu (coxeter.math.toronto.edu [128.100.68.3]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0B5Xcxu011054 for ; Tue, 11 Jan 2005 06:33:38 +0100 (CET) Received: (from laurent@localhost) by coxeter.math.toronto.edu (AIX5.2/8.11.6p2/8.11.0/UTMath 1.0) id j0B5XMP123972; Tue, 11 Jan 2005 00:33:22 -0500 Date: Tue, 11 Jan 2005 00:33:22 -0500 From: Larry Siebenmann Message-Id: <200501110533.j0B5XMP123972@coxeter.math.toronto.edu> To: hoffmasv@imail.de, laurent@math.toronto.edu, lcs@math.toronto.edu, lfinsto1@gwdg.de, metafont@ens.fr Subject: Re: all intersections between two paths * X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Tue, 11 Jan 2005 06:33:38 +0100 (CET) Hi Laurence, Antonio and all, I got wind of your curve intersection quieries via the Metafont list. If this reply (and others) do not get to the list maybe Laurence F. could relay them. > How does one arrive at the value 9 for the maximum number of intersections > of other `paths' of length 1? Is there a (relatively) simple proof, or > can I look this up somewhere? Given a generic bezier degree n planar path t |--> b(t), there is an "implicitization" process (that goes back to Euler they say) it gives a degree n real valued polynomial B in two variables such that the points on the bezier curve b are one component of the plane locus {(x,y) \in C | B(x,y) = 0} The points where curve b meets a degree m bezier curve t |--> c(t) then genericly lie among the roots of the one-variable degree m*n polynomial B(c(t)). So there are at most m*n such points. A reference for implicitization is Van der Waarden, Modern Algebra, a great classic. A useful informal source of information is the usenet comp.graphics.algorithms group. > Given the manipulations possible with connectors, I think it may be > difficult to filter out `paths' with infinitely many intersections. I am optimistic that it can be done in some practical sense. Have you a specific challenge? I assume you mean by connectors the short paths that metafont seems to insert to link paths that almost but not quite chain together. (?) By pairs of `paths' with infinitely many intersections I imagine you include paths that remain very near to one another for a 'noticeable' stretch? Cheers Laurent S. PS. When I look closely at examples I get the feeling that today's Metapost is a fairly blunt instrument that should be kept under human supervision. To feel confident that metapost will almost always give results free from roundoff artifacts overflows etc. -- without too much human intervention, it would be nice to have a 64 bit implementation of metafont/metapost. Is such a project underway? From - Tue Jan 11 06:34:00 2005 Return-Path: Received: from coxeter.math.toronto.edu (coxeter.math.toronto.edu [128.100.68.3]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0B5Xtqe011248 for ; Tue, 11 Jan 2005 06:33:55 +0100 (CET) Received: (from laurent@localhost) by coxeter.math.toronto.edu (AIX5.2/8.11.6p2/8.11.0/UTMath 1.0) id j0B5Xmn123974; Tue, 11 Jan 2005 00:33:48 -0500 Date: Tue, 11 Jan 2005 00:33:48 -0500 From: Larry Siebenmann Message-Id: <200501110533.j0B5Xmn123974@coxeter.math.toronto.edu> To: hoffmasv@imail.de, laurent@math.toronto.edu, lcs@math.toronto.edu, lfinsto1@gwdg.de, metafont@ens.fr Subject: Re: all intersections between two paths X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Tue, 11 Jan 2005 06:33:56 +0100 (CET) Jacko wrote, > Convincing ;-) I reworked the examples and now the archive has 5.5kB. > > Laurence> Would your algorithm be extensible for use with other forms of > Laurence> spline curve, in particular NURBs? > > No idea. I'm out of math business since long time. I'd ask Larry > Siebenmann... Suppose we are seeking the self-intersections of a map f : X --> Y. Say when Y=R^2, and X is two intervals, while f is b'ezier of degree n on each. The binary search method that Knuth chose to seek intersections is exceedingly general. The key prerequisite to start programming a 'solver' is to have a fast routine giving a small easily prescribed set |S| in Y that contains the image f(S) of a nice small set S. The nice sets S in the case at hand are all the closed subintervals of X. The de Casteljau observation that f(S) then lies in the convex hull of the n+1 control points for f on S is just what we need! This works in all degrees and all dimensions. Who knows of nice implementations in math and graphics environments? Not I. There is considerable distance between theory and practice. The best method really available may be to --- approximate by bezier cubics --- apply the metafont intersection algorithm --- check out candidates solutions There are some simplest rational splines to which the Casteljau observation can be extended. At levels of generality beyond that I know almost nothing of use. Cheers Laurent Siebenmann (Larry) From - Tue Jan 11 10:56:42 2005 Return-Path: Received: from mailrelay01.solcon.nl (maillb.solcon.nl [212.45.32.200]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0B9ub9S052650 for ; Tue, 11 Jan 2005 10:56:37 +0100 (CET) Received: from server-1.pragma-net.nl (dsl-212-84-128-085.solcon.nl [212.84.128.85]) by mailrelay01.solcon.nl (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id j0B9uZCC010394; Tue, 11 Jan 2005 10:56:35 +0100 Received: by server-1.pragma-net.nl (Postfix, from userid 65534) id 5FF6319949; Tue, 11 Jan 2005 10:51:45 +0100 (CET) Received: from [10.100.1.191] (unknown [10.100.1.191]) by server-1.pragma-net.nl (Postfix) with ESMTP id 2D4C217BF1; Tue, 11 Jan 2005 09:51:44 +0000 (UTC) Message-ID: <41E3A2D5.5040105@wxs.nl> Date: Tue, 11 Jan 2005 10:56:37 +0100 From: Hans Hagen User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Larry Siebenmann Cc: hoffmasv@imail.de, lcs@math.toronto.edu, lfinsto1@gwdg.de, metafont@ens.fr Subject: Re: [metafont] Re: all intersections between two paths * References: <200501110533.j0B5XMP123972@coxeter.math.toronto.edu> In-Reply-To: <200501110533.j0B5XMP123972@coxeter.math.toronto.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.5 required=7.5 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Virus-Scanned: ClamAV 0.80/540/Tue Oct 19 14:59:23 2004 clamav-milter version 0.80j on mailrelay01 X-Virus-Status: Clean X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Tue, 11 Jan 2005 10:56:38 +0100 (CET) Larry Siebenmann wrote: > PS. When I look closely at examples I get the feeling that today's > Metapost is a fairly blunt instrument that should be kept under > human supervision. To feel confident that metapost will almost > always give results free from roundoff artifacts overflows etc. -- > without too much human intervention, it would be nice to have a 64 > bit implementation of metafont/metapost. Is such a project > underway? there are indeed plans for that, but after the pending bugfixes also, G. Bilotta may have such a version since he needs it for his phd work Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl ----------------------------------------------------------------- From - Tue Jan 11 12:47:44 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0BBldOH017614 for ; Tue, 11 Jan 2005 12:47:39 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CoKUg-0001ML-RI; Tue, 11 Jan 2005 12:47:27 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0BBlLp0000319485; Tue, 11 Jan 2005 12:47:21 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Tue, 11 Jan 2005 12:47:21 +0100 (MET) From: Laurence Finston To: Larry Siebenmann cc: hoffmasv@imail.de, lcs@math.toronto.edu, metafont@ens.fr, metapost@tug.org, help-3dldf Subject: Re: all intersections between two paths * In-Reply-To: <200501110533.j0B5XMP123972@coxeter.math.toronto.edu> Message-ID: References: <200501110533.j0B5XMP123972@coxeter.math.toronto.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Tue, 11 Jan 2005 12:47:39 +0100 (CET) On Tue, 11 Jan 2005, Larry Siebenmann wrote: > > > How does one arrive at the value 9 for the maximum number of intersections > > of other `paths' of length 1? Is there a (relatively) simple proof, or > > can I look this up somewhere? > > Given a generic bezier degree n planar path t |--> b(t), there > is an "implicitization" process (that goes back to Euler they > say) [...] Thank you for your explanation. > > > Given the manipulations possible with connectors, I think it may be > > difficult to filter out `paths' with infinitely many intersections. > > I am optimistic that it can be done in some practical sense. Have > you a specific challenge? My specific challenge is implementing routines for finding intersections of arbitrary three-dimensional Metafont-like `paths' in GNU 3DLDF. Currently, this is not possible. I plan to reimplement them as NURBs because of the property of projective invariance, which the latter possess. I am not, however, bound by the arithmetical limitations built into MF, since I haven't tried to implement whole number arithmetic and just use `floats' or `doubles', depending on the value of a preprocessor macro. > > I assume you mean by connectors the short paths that metafont seems > to insert to link paths that almost but not quite chain together. > (?) No, that's not what I meant, but I expressed myself poorly. I should have said "given the manipulations possible with control points." What I meant by "connectors" was actually "path joins", e.g., ".. tension a and b .." and "direction specifiers", which, when present, are ultimately used to find control points. > > By pairs of `paths' with infinitely many intersections I imagine > you include paths that remain very near to one another for a > 'noticeable' stretch? Yes. I also think that under certain circustances, the dimensions of the `pens' used for drawing the `paths' should be taken into account, since the drawings of two `paths' might intersect or become tangent although the `paths' themselves do not. This opens another can of worms, though. In discussions about intersections in GNU 3DLDF, Martijn van Manen has pointed out that the case of objects getting very close without actually becoming tangent or intersecting are also problematical. Laurence From - Tue Jan 11 17:45:22 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0BGjKG0011940 for ; Tue, 11 Jan 2005 17:45:20 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CoP8G-00074R-8W; Tue, 11 Jan 2005 17:45:04 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0BGiZg0000332708; Tue, 11 Jan 2005 17:44:35 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Tue, 11 Jan 2005 17:44:35 +0100 (MET) From: Laurence Finston To: help-3dldf , liste metafont , metapost@tug.org Subject: "3D" Metafont fonts with GNU 3DLDF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Tue, 11 Jan 2005 17:45:20 +0100 (CET) Hello, Some months ago I wrote about the possibility of using GNU 3DLDF to generate "3D" Metafont fonts. I have now produced my first sample, so anyone who's interested may have a look at it: http://www.gnu.org/software/3dldf/cdsmpls.html#Globe%20font The code used to generate it is fairly compact, so I include it below. I haven't automated the process of converting the MP code written by 3DLDF to MF, because I plan to make it possible for the former to write MF code directly. Laurence Finston http://www.gnu.org/software/3dldf/LDF.html **************************************************************** %%%% Copyright (C) 2003, 2004, 2005 The Free Software Foundation (GNU General Public License) %% Globe font. `beginfig' needs to be changed to `beginchar', %% and arguments have to be added, e.g., `beginfig(0);' must be changed to %% `beginchar(0, 10pt#,10pt#,10pt#);'. `endfig' must also be changed to %% `endchar'. %% This code appears at the beginning of the Metafont file: %% mag := 10; %% mode=ljfour; %% mode_setup; %% displaying:=-1; circle c[]; division_value := 32; one_quarter_division_value := 1/4division_value; three_quarters_division_value := 3/4division_value; set c0 with_point_count division_value; scale c0 (8pt, 0, 8pt); rotate c0 by 90; point p; path q[]; q[division_value] += get_point 0 c0; pen thick_pen; thick_pen := pencircle scaled (2.5, 2.5, 2.5); pickup thick_pen; step_value := 360 / division_value; j := 1; for i = 0 step step_value until 360 - step_value: rotate c0 (0, step_value); if (is_even j): draw c0; fi; for k = 2 step 2 until one_quarter_division_value - 2: q[k] += get_point (k) c0; q[three_quarters_division_value + k] += get_point (three_quarters_division_value + k) c0; endfor; q[division_value] += get_point 0 c0; j += 1; endfor; q[division_value] += cycle; q[division_value] += ..; draw q[division_value]; for i = 2 step 2 until one_quarter_division_value - 2: q[i] += ..; q[i] += cycle; q[three_quarters_division_value + i] += ..; q[three_quarters_division_value + i] += cycle; draw q[i]; draw q[three_quarters_division_value + i]; endfor; picture p; p := current_picture; n := 0; for i = 0 step 1 until 15: if i > 0: rotate p by 30; fi; for j = 0 step 1 until 15: if j > 0: rotate p (0, 30); fi beginfig(n); output p; endfig; n += 1; endfor; endfor; end; From - Tue Jan 11 21:00:12 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0BK080d033459 for ; Tue, 11 Jan 2005 21:00:08 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CoSBQ-000150-4I; Tue, 11 Jan 2005 21:00:05 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0BK03Q0000340110; Tue, 11 Jan 2005 21:00:03 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Tue, 11 Jan 2005 21:00:03 +0100 (MET) From: Laurence Finston To: help-3dldf , liste metafont , metapost@tug.org Subject: Re: "3D" Metafont fonts with GNU 3DLDF In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Tue, 11 Jan 2005 21:00:08 +0100 (CET) On Tue, 11 Jan 2005, Laurence Finston wrote: > > The code used to generate it is fairly compact, so I include > it below. The following is a better loop for generating the figures. For one thing, it cuts down on the repetition resulting from the symmetry of the sphere. Laurence picture p; picture q; q := p := current_picture; n := 0; for i = 0 step 1 until 4: p := q; if i > 0: rotate p (45i, 0); fi; for j = 0 step 1 until 5: if j > 0: rotate p (0, 30); fi beginfig(n); output p; endfig; n += 1; endfor; endfor; end; From - Sun Jan 16 05:31:31 2005 Return-Path: Received: from coxeter.math.toronto.edu (coxeter.math.toronto.edu [128.100.68.3]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0G4VQtP095613 for ; Sun, 16 Jan 2005 05:31:26 +0100 (CET) Received: (from laurent@localhost) by coxeter.math.toronto.edu (AIX5.2/8.11.6p2/8.11.0/UTMath 1.0) id j0G4VBV265278; Sat, 15 Jan 2005 23:31:11 -0500 Date: Sat, 15 Jan 2005 23:31:11 -0500 From: Larry Siebenmann Message-Id: <200501160431.j0G4VBV265278@coxeter.math.toronto.edu> To: B_Jackowski@GUST.org.pl, antonio.ramirez@gmail.com, elp-3dldf@gnu.org, laurent@math.toronto.edu, lfinsto1@gwdg.de, metafont@ens.fr, pragma@wxs.nl Subject: Re: all intersections between two paths X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Sun, 16 Jan 2005 05:31:27 +0100 (CET) Hi All, This thread (sparked by antonio.ramirez at gmail.com) has been partly on the metapost@tug.org mail list which, for me, is still a "read only" list. That's not a huge problem since its archives are open to the whole world at http://tug.org/pipermail/metapost/. Here I comment on discussion between Laurence Finston (LF here) and Boguslaw Jackowski (BJ here) . The main problem is to find, using metapost or metafont, all the intersection points of two composite bezier cubic paths. A useful near solution was posted by BJ last week. I fear some of you will have to write him for a copy since I don't see it in the archives. The function is called 'intersect_curves' and the macro package is "findoutI.mp" assisted by "qck_sort.mp". BJ> The crucial assumptions for the algorithm to work are: (1) BJ> B\'ezier segments have no selfintersections and (2) two BJ> B\'ezier segments do not intersect at more than two BJ> points. ... BJ> Another argument in favor of the assuption (2) is that BJ> such an algorithm can be implemented in both MF and MP; BJ> otherwise, as rightly pointed out Antonio, the problem BJ> cannot be handled efficiently without arclength and BJ> arctime operations (at least I do not know how to do it BJ> efficiently) and these operations are missing from MF. I seem to manage without arclength and arctime operations. BJ> My question is: which constraints imposed on single BJ> B\'ezier segments you would consider reasonable? I currently favor a technical notion I call 'sparse intersections', that I'll explain in a later post. LF> I don't quite understand why you don't want your macros to LF> process the `paths' until all of the resulting `paths' LF> fulfill your two conditions. BJ> I do want, but I don't know how to do it reliably. As you have BJ> seen, even the question whether two curves touch each other BJ> cannot be reliably answered. In general, I to not know how to BJ> deal efficiently and reliably with infinitezimal artefacts. I BJ> can agree that my knowledge about discrete geometry is BJ> insufficient. Unsolved problem I think -- with condition (2). BJ> Still, I'd bet that: give me a ``universal'' BJ> MP/MF algorithm and I'll find you a counterexample... Well, finally, that is a boast ;-) BJ> Needless to say, if there existed a reliable criterion that BJ> would tell naughty paths from tidy ones, I'd be happy. No idea BJ> whether such a criterion exists. Frankly speaking, I doubt. BJ> But maybe I'm wrong. Therefore I asked the question about such BJ> a criterion. Unsolved I fear. But fragments of solution exist. Good news (?): Two planar b'ezier cubic segments both without inflexions and turning through \leq 180 degrees, have *at most four* intersection points -- unless they intersect infinitely in, which case they just parametrize overlapping segments of the same planar locus of degree \leq 3. (Counterexample?) Bad news: One cannot straightforewardly do better for 90 degrees or even eps degrees. Examples shortly. LF> I just think it's likely that breaking up LF> `paths' that don't fulfill them until all of the resulting LF> `paths' do would be a good way of handling the general LF> case. I think it might be easier than inventing a cleverer LF> algorithm that can handle "naughtier" `paths'. However, LF> maybe someone knows such an algorithm already. On the other LF> hand, if it fails for some cases, then it just fails. I LF> think it would be worthwhile to implement it even if it only LF> handles, say, 90% of the cases. Maybe. But beware of above frustrating fact. BJ> This is one of the possibilities I took into account. BJ> Intuitively, it looked less promising than the other one, BJ> i.e., loosening constraints. Anyway, needs re-thinking. I too feel that loosening constraints is the better option but I may be wrong. LF> My specific challenge is implementing routines for finding LF> intersections of arbitrary three-dimensional Metafont-like LF> `paths' in GNU 3DLDF. Are these generalized paths allowed to have dimension 2, ie to be surface patches? Any degrees >3 badly wanted? Cheers Laurent S. From - Sun Jan 16 05:34:29 2005 Return-Path: Received: from coxeter.math.toronto.edu (coxeter.math.toronto.edu [128.100.68.3]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0G4YNkc097476 for ; Sun, 16 Jan 2005 05:34:23 +0100 (CET) Received: (from laurent@localhost) by coxeter.math.toronto.edu (AIX5.2/8.11.6p2/8.11.0/UTMath 1.0) id j0G4YHZ265280; Sat, 15 Jan 2005 23:34:17 -0500 Date: Sat, 15 Jan 2005 23:34:17 -0500 From: Larry Siebenmann Message-Id: <200501160434.j0G4YHZ265280@coxeter.math.toronto.edu> To: B_Jackowski@GUST.org.pl, antonio.ramirez@gmail.com, elp-3dldf@gnu.org, laurent@math.toronto.edu, lfinsto1@gwdg.de, metafont@ens.fr, pragma@wxs.nl Subject: Re: all intersections between two paths X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Sun, 16 Jan 2005 05:34:24 +0100 (CET) Hi All, I have a test program for intersecting bezier curves having 'sparse intersections'; that may be what Jacko is looking for. At any rate the approach is radically different from that in Jacko's 'intersect_curves' function. The program dates from summer 2003 when Richard Kinch and others discussed the same general problem on the comp.graphics.algorithms news group. It has never been publicly posted. Here it is: http://topo.math.u-psud.fr/~lcs/graphics/ I welcome this opportunity to get it tested; there surely still are bugs to squash. Just post here (or send me) in *simplest* MP language any curve pairs that pose problems and lie in the scope of reasonable requirements. Here is the header: %%%%%% Metapost macro file "Hit.mp" %%%%%% FN_Hit(pp,qq) finds where composite bezier paths pp, qq intersect %%%%%% Examples and testbed included %%%% Limitations: %% -- Needs 'sparse' intersections %% (hence, no lingering grazing contacts, %% nor even extremely sharp angles of transverse intersection). %% -- Needs all intersection points distinct and maybe 1bp apart %% as met by pp when curves at page proof size. %% -- May require configuration for size od detail of your curves. %% -- May fail for over 30 intersection points since recursion used. %% Workaround: break pp and qq into simple bezier paths %% (with 4 control points each) so that 9 is maximum number %% of intersection points that FN_Hit must find. %%%% Possible virtues: %% -- No shape or *self*-intersection restrictions on pp, qq %% (i.e. bezier control trilaterals have arbitrary shapes). %% -- Applies to bezier curves of any degree %% as soon as 'intersectiontimes' is provided for them. %%%% Things to do (maybe): %% -- convenient listing of intersection points %% (on pp, on qq, and in target plane). %% -- some debugging still needed: bug reports please! %% -- a tight production version with enough variable protection %% (but speed seems already adequate) %% -- some refinements to enlarge the 'sweet spot' in param space %% -- apply tricks to use less recursion depth per intersection %% -- optimization for cyclic paths %%%% Contact: %% Laurent Siebenmann, %% Email via http://topo.math.u-psud.fr/~lcs/contact %% Testbed Prototype 0 of January 2005 %% Updates: Read metafont@ens.fr archives or contact author. %% http://www.gutenberg.eu.org/pub/GUTenberg/archives/metafont/ There are a half dozen examples embedded. My first example shows a cubic bezier meeting a quadratic bezier in 4 transverse crossing points. The total turn angle can be made as small as you want by 'yscale'ing. By playing with the control vectors one can group the intersection points more or less at will, thus frustrating naive recipes to split *automatically* into two segments to which Jacko's 'intersect_curves' function directly applies. The other examples resemble ones Jacko presented for his 'intersect_curves' function. Note that I do no preprocessing of paths for any example. The most problematic aspect of the program is the relatively small 'sweet spot' in the parameter space. Meaning the the parameter range that you have to be in to make thing work. It would be *huge* for a 64 bit implementation of MF! The key parameters to adjust are are your drawing size and HitToleranceRatio_. Incidentally, are there compiled versions of MP/MF that allow one to adjust the 'input stack size' limit? That would surely let one deal with far more than 30 intersection points --- without segmenting composite bezier curves before processing. Is 30 intersections already adequate? The idea behind the program is that if you can get one intersection you will somehow get them all by recursion. The main obstacle is that without special tricks the program will give the same intersections again and again. My trick to avoid getting into this rut is removal of a small interval, in (say) the first curve, about any intersection -- after it is found; this is done by drawing a (rather crude) circle of diameter HitTolerance_ about it and excising the part of that first curve within that circle. This costs two extra applications of 'intersectiontimes' per point found; but the cost seems affordable. This trick (in general) breaks a bezier curve into two, and each piece then has to be handled recursively. 'Sparse intersections' just means that this strategy works. I could someday attempt a definition without reference to 'Hit.mp', and try to give useful (and machine verifiable!) sufficient conditions for this sparseness. Finally, apologies for the naive programming style. Maybe I should pretend that it is just to let absolutely anyone understand the code;-) but the truth is that I feel a complete beginner every time I start to program again with MP! Laurent S. PS. Who can offer MF substitutes for the MP functions 'ulcorner' and 'lrcorner' that I use for 'autosizing'. From - Sun Jan 16 17:54:02 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0GGrwH4063844 for ; Sun, 16 Jan 2005 17:53:58 +0100 (CET) Message-Id: <200501161653.j0GGrwH4063844@nef2.ens.fr> Received: from mailbox.gwdg.de ([134.76.10.21] helo=gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CqDew-0005F9-S7; Sun, 16 Jan 2005 17:53:50 +0100 Content-Type: text/plain; charset=us-ascii X-Originating-IP: lfinsto1[134.76.139.103] Date: Sun, 16 Jan 2005 17:53:50 +0100 MIME-Version: 1.0 Subject: Re: all intersections between two paths In-Reply-To: <200501160434.j0G4YHZ265280@coxeter.math.toronto.edu> Content-Transfer-Encoding: 8bit Cc: B_Jackowski@GUST.org.pl, antonio.ramirez@gmail.com, help-3dldf@gnu.org, metafont@ens.fr, pragma@wxs.nl, metapost@tug.org User-Agent: IMHO/0.98.3+G (Webmail for Roxen) From: "Laurence Finston" To: Larry Siebenmann X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Sun, 16 Jan 2005 17:53:58 +0100 (CET) Larry Siebenmann wrote: > PS. Who can offer MF substitutes for the MP functions 'ulcorner' and > 'lrcorner' that I use for 'autosizing'. How about (0, h) and (w, -d)? Laurence From - Sun Jan 16 18:10:54 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0GHAqrA074814 for ; Sun, 16 Jan 2005 18:10:52 +0100 (CET) Message-Id: <200501161710.j0GHAqrA074814@nef2.ens.fr> Received: from mailbox.gwdg.de ([134.76.10.21] helo=gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CqDvM-0001je-3w; Sun, 16 Jan 2005 18:10:48 +0100 Content-Type: text/plain; charset=us-ascii X-Originating-IP: lfinsto1[134.76.139.103] Date: Sun, 16 Jan 2005 18:10:48 +0100 MIME-Version: 1.0 Subject: Re: all intersections between two paths In-Reply-To: <200501160431.j0G4VBV265278@coxeter.math.toronto.edu> Content-Transfer-Encoding: 8bit Cc: B_Jackowski@GUST.org.pl, antonio.ramirez@gmail.com, help-3dldf@gnu.org, metafont@ens.fr, pragma@wxs.nl, metapost@tug.org User-Agent: IMHO/0.98.3+G (Webmail for Roxen) From: "Laurence Finston" To: Larry Siebenmann X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Sun, 16 Jan 2005 18:10:52 +0100 (CET) Larry Siebenmann wrote: > LF> My specific challenge is implementing routines for finding > LF> intersections of arbitrary three-dimensional Metafont-like > LF> `paths' in GNU 3DLDF. > > Are these generalized paths allowed to have dimension 2, ie to > be surface patches? Any degrees >3 badly wanted? > Actually, I just took the opportunity to pose my question because the subject had come up. While I am interested in the answer, my more immediate concern is finding the intersections of non-arbitrary paths, such as straight lines, polygons, ellipses, circles, hyperbolae, etc. I hope for an improvement in performance from implementing NURBs, but they won't bring an improvement in the way curves are rendered. I can get equally good results by just using more points on a given path. The advantage to using NURBs would be that I wouldn't have to project so many points. Therefore I've decided that my next task will be to work on surface hiding with non-arbitrary paths. NURBs are, of course, interesting in their own right. I do eventually want to implement surface patches and n-dimensional geometrical figures for all n. Laurence From - Sun Jan 16 19:05:46 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0GI5fC7010628 for ; Sun, 16 Jan 2005 19:05:41 +0100 (CET) Message-Id: <200501161805.j0GI5fC7010628@nef2.ens.fr> Received: from mailbox.gwdg.de ([134.76.10.21] helo=gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CqEmM-0008Ng-VN; Sun, 16 Jan 2005 19:05:35 +0100 Content-Type: text/plain; charset=us-ascii X-Originating-IP: lfinsto1[134.76.139.103] Date: Sun, 16 Jan 2005 19:05:34 +0100 MIME-Version: 1.0 Subject: Re: all intersections between two paths In-Reply-To: <200501160431.j0G4VBV265278@coxeter.math.toronto.edu> Content-Transfer-Encoding: 8bit Cc: B_Jackowski@GUST.org.pl, antonio.ramirez@gmail.com, help-3dldf@gnu.org, metafont@ens.fr, pragma@wxs.nl, metapost@tug.org User-Agent: IMHO/0.98.3+G (Webmail for Roxen) From: "Laurence Finston" To: Larry Siebenmann X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Sun, 16 Jan 2005 19:05:41 +0100 (CET) Larry Siebenmann wrote: > > I too feel that loosening constraints is the better option > but I may be wrong. I think so too, if you've got a clever algorithm. I didn't have one. > By playing with the control vectors > one can group the intersection points more or less at will, thus > frustrating naive recipes to split *automatically* into two segments > to which Jacko's 'intersect_curves' function directly applies. I confess to the charge of naivete. One nice thing about C++ is that it supports a style of programming that allows one to change the implementation without changing the interface. As I learn or develop less naive algorithms, I can incorporate them into my program without having to rewrite it completely. The point I'd like to make is that one doesn't have to be a computer scientist and a mathematician to write a program that does something useful. These are two wonderful things to be, but it's not _necessary_. If my work has a point, I hope it is to encourage others to say "hey, if he can do it, anyone can", and program something themselves. > May fail for over 30 intersection points since recursion used. I _always_ try to eliminate recursion in my programs wherever possible, and it often is. I haven't read your code, so I don't know whether it is in this case. However, I think it would be worthwhile to consider whether you couldn't just put the subpaths onto an array and loop over the array until some condition is met. > but the truth is that I feel a complete beginner every time I start to > program again with MP! That's a good way to feel. As Shunryu Suzuki Roshi said, "Beginners have many possibilities, experts only a few." (_Zen Spirit, Beginner's Spirit_. This is my translation back into English of the German translation, so it may diverge a little from the original English.) Laurence From - Mon Jan 17 11:09:07 2005 Return-Path: Received: from mailrelay01.solcon.nl (maillb.solcon.nl [212.45.32.200]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0HA93OZ051143 for ; Mon, 17 Jan 2005 11:09:03 +0100 (CET) Received: from server-1.pragma-net.nl (dsl-212-84-128-085.solcon.nl [212.84.128.85]) by mailrelay01.solcon.nl (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id j0HA90LH000584; Mon, 17 Jan 2005 11:09:00 +0100 Received: by server-1.pragma-net.nl (Postfix, from userid 65534) id 3C26C1AB90; Mon, 17 Jan 2005 11:03:08 +0100 (CET) Received: from [10.100.1.191] (unknown [10.100.1.191]) by server-1.pragma-net.nl (Postfix) with ESMTP id EB0D817B14; Mon, 17 Jan 2005 10:03:06 +0000 (UTC) Message-ID: <41EB8EC6.5070607@wxs.nl> Date: Mon, 17 Jan 2005 11:09:10 +0100 From: Hans Hagen User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Laurence Finston Cc: Larry Siebenmann , B_Jackowski@GUST.org.pl, antonio.ramirez@gmail.com, help-3dldf@gnu.org, metafont@ens.fr, metapost@tug.org Subject: Re: all intersections between two paths References: <0IAF00CWP8XHDI@smtp14.wxs.nl> In-Reply-To: <0IAF00CWP8XHDI@smtp14.wxs.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.5 required=7.5 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Virus-Scanned: ClamAV 0.80/540/Tue Oct 19 14:59:23 2004 clamav-milter version 0.80j on mailrelay01 X-Virus-Status: Clean X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 17 Jan 2005 11:09:03 +0100 (CET) Laurence Finston wrote: > I _always_ try to eliminate recursion in my programs wherever possible, and it > often is. I haven't read your code, so I don't know whether it is in this > case. However, I think it would be worthwhile to consider whether you > couldn't just put the subpaths onto an array and loop over the array until > some condition is met. there's nothing wrong with recursion; in tex/mp, try to use tail recursion and then there are no limits Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl ----------------------------------------------------------------- From - Mon Jan 17 11:49:03 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0HAmxRl078683 for ; Mon, 17 Jan 2005 11:48:59 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CqURM-0002Mh-T4; Mon, 17 Jan 2005 11:48:57 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0HAmoL0000026218; Mon, 17 Jan 2005 11:48:51 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Mon, 17 Jan 2005 11:48:50 +0100 (MET) From: Laurence Finston To: Hans Hagen cc: Larry Siebenmann , B_Jackowski@GUST.org.pl, antonio.ramirez@gmail.com, help-3dldf , metafont@ens.fr, metapost@tug.org Subject: Re: all intersections between two paths In-Reply-To: <41EB8EC6.5070607@wxs.nl> Message-ID: References: <0IAF00CWP8XHDI@smtp14.wxs.nl> <41EB8EC6.5070607@wxs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 17 Jan 2005 11:49:00 +0100 (CET) On Mon, 17 Jan 2005, Hans Hagen wrote: > Laurence Finston wrote: > > > I _always_ try to eliminate recursion in my programs wherever possible, > there's nothing wrong with recursion; in tex/mp, try to use > tail recursion and > then there are no limits I don't think there's anything _wrong_ with it. As I understand it, where tail recursion is possible, there is indeed no problem. Roughly speaking, and again as I understand it, in C and C++, the price of a function call is a stack frame, whereas the price of a loop is a handful of machine instructions. The price of an additional, recursive call to a function is another stack frame, whereas the price of an additional iteration is testing a conditional and a jump, i.e., negligible. I don't know whether optimizing compilers (or perhaps the run-time system?) can recognize where tail recursion is possible and eliminate stack frame nesting; nor do I know how a programmer could tell the compiler to do this, where possible, nor whether it would be wise for a programmer to depend on this behavior. If you or anyone else knows about this subject, I'd be very interested in learning more. In GNU 3DLDF, the price of a macro call that of a loop is not too different, since macros and loops are implemented in a similar way. However, each additional call to a macro has the same price as the first one, whereas the price of an additional iteration is negligible. Since macro expansion and looping are similar in MF and GNU 3DLDF, I'm fairly sure the situation is similar in MF, notwithstanding the differences in implementation, unless, of course, MF can use tail recursion. I don't know how it does this, or whether one can depend on it always being done. I believe that in C, tail recursion is possible when the enclosing function exits immediately after the recursive function call, or at least when no local variables are accessed and the values of no static or global variables are changed after the recursive function call. Again, if anyone can "lift the veil of ignorance", this would be much appreciated. Laurence From - Mon Jan 17 12:04:49 2005 Return-Path: Received: from mailrelay02.solcon.nl (maillb.solcon.nl [212.45.32.200]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0HB4ldB090288 for ; Mon, 17 Jan 2005 12:04:47 +0100 (CET) Received: from server-1.pragma-net.nl (dsl-212-84-128-085.solcon.nl [212.84.128.85]) by mailrelay02.solcon.nl (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id j0HB4iek024469; Mon, 17 Jan 2005 12:04:44 +0100 Received: by server-1.pragma-net.nl (Postfix, from userid 65534) id DF35217CBF; Mon, 17 Jan 2005 11:58:51 +0100 (CET) Received: from [10.100.1.191] (unknown [10.100.1.191]) by server-1.pragma-net.nl (Postfix) with ESMTP id 6E86117B14; Mon, 17 Jan 2005 10:58:50 +0000 (UTC) Message-ID: <41EB9BD5.8050008@wxs.nl> Date: Mon, 17 Jan 2005 12:04:53 +0100 From: Hans Hagen User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Laurence Finston Cc: Larry Siebenmann , B_Jackowski@GUST.org.pl, antonio.ramirez@gmail.com, help-3dldf , metafont@ens.fr, metapost@tug.org Subject: Re: all intersections between two paths References: <0IAF00CWP8XHDI@smtp14.wxs.nl> <41EB8EC6.5070607@wxs.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.5 required=7.5 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Virus-Scanned: ClamAV 0.80/540/Tue Oct 19 14:59:23 2004 clamav-milter version 0.80j on mailrelay02 X-Virus-Status: Clean X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 17 Jan 2005 12:04:47 +0100 (CET) Laurence Finston wrote: > I don't think there's anything _wrong_ with it. As I understand it, > where tail recursion is possible, there is indeed no problem. > Roughly speaking, and again as I understand it, > in C and C++, the price of a function call > is a stack frame, whereas the price of a loop is a handful of machine > instructions. most cpu's are optimized for that kind of stack handling, as are compilers, > The price of an additional, recursive call to a function is another stack > frame, whereas the price of an additional iteration is testing a > conditional and a jump, i.e., negligible. in this case, a few hundred stack frames are neglectable to what other threads in your OS may be doing; there are also languages that are build around recursion (functional languages and such) > I don't know whether optimizing compilers (or perhaps the run-time system?) > can recognize where tail recursion is possible and eliminate > stack frame nesting; nor do I know how a programmer could tell the > compiler to do this, where possible, nor whether it would be wise for a > programmer to depend on this behavior. If you or anyone else knows > about this subject, I'd be very interested in learning more. in general, in languages like tex/mp, copying data structures take the most time, so don't worry about speed-up here; (in tex for instance, fully expandable, recursive macros are way faster than loops with counters) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl ----------------------------------------------------------------- From - Mon Jan 17 13:25:24 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0HCPNff042775 for ; Mon, 17 Jan 2005 13:25:23 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CqVwe-0004Uc-EF; Mon, 17 Jan 2005 13:25:20 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0HCPJY0000029330; Mon, 17 Jan 2005 13:25:19 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Mon, 17 Jan 2005 13:25:19 +0100 (MET) From: Laurence Finston To: Hans Hagen cc: Larry Siebenmann , B_Jackowski@GUST.org.pl, antonio.ramirez@gmail.com, help-3dldf , metafont@ens.fr, metapost@tug.org Subject: Re: all intersections between two paths In-Reply-To: <41EB9BD5.8050008@wxs.nl> Message-ID: References: <0IAF00CWP8XHDI@smtp14.wxs.nl> <41EB8EC6.5070607@wxs.nl> <41EB9BD5.8050008@wxs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 17 Jan 2005 13:25:23 +0100 (CET) On Mon, 17 Jan 2005, Hans Hagen wrote: > most cpu's are optimized for that kind of stack handling, as are compilers, Thanks for the information. What happens when a function accesses local variables and/or changes the values of a static variable following a recursive call to the same function? > > in this case, a few hundred stack frames are neglectable to what > other threads > in your OS may be doing; there are also languages that are build around > recursion (functional languages and such) Since GNU 3DLDF uses POSIX threads, and the size of the stacks for threads is generally much smaller than that of the single stack for a process without POSIX threads, I think that it's important to try keep the thread stacks from getting too large. I just tried to check whether this has changed, and whether thread stacks can be extended dynamically, but I don't have my threads book (Butenhof) handy, and I don't know the names of the functions, so I can't find the man pages. > in general, in languages like tex/mp, copying data structures take the most > time, so don't worry about speed-up here; (in tex for instance, fully > expandable, recursive macros are way faster than loops with counters) > With all due respect, I think this is an area where TeX and MF use completely different strategies. If I remember correctly, Knuth had to be talked into including loops in TeX, and in my opinion, they're not the nicest part of TeX. While TeX has loops and MF has macros, if I had to describe TeX and MF in no more than two words each, I would say that TeX is a "macro processor" and MF is an "interpreter". It therefore stands to reason that the implementation of macros, including the handling of recursion, would be especially efficient in TeX, while that of loops would be especially efficient in MF. In GNU 3DLDF, and I suspect in MF, the cost of a macro call is largely the cost of copying the replacement text, replacing placeholders with the arguments, arranging to read input from the copy, and arranging to return to the original input source when it's been read. Laurence From - Mon Jan 17 13:43:51 2005 Return-Path: Received: from mailrelay01.solcon.nl (maillb.solcon.nl [212.45.32.200]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0HCho48054807 for ; Mon, 17 Jan 2005 13:43:50 +0100 (CET) Received: from server-1.pragma-net.nl (dsl-212-84-128-085.solcon.nl [212.84.128.85]) by mailrelay01.solcon.nl (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id j0HChlS2018005; Mon, 17 Jan 2005 13:43:47 +0100 Received: by server-1.pragma-net.nl (Postfix, from userid 65534) id 8D6AB1AB90; Mon, 17 Jan 2005 13:37:54 +0100 (CET) Received: from [10.100.1.191] (unknown [10.100.1.191]) by server-1.pragma-net.nl (Postfix) with ESMTP id 2ECFE17B14; Mon, 17 Jan 2005 12:37:53 +0000 (UTC) Message-ID: <41EBB30D.9040005@wxs.nl> Date: Mon, 17 Jan 2005 13:43:57 +0100 From: Hans Hagen User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Laurence Finston Cc: Larry Siebenmann , B_Jackowski@GUST.org.pl, antonio.ramirez@gmail.com, help-3dldf , metafont@ens.fr, metapost@tug.org Subject: Re: [metafont] Re: all intersections between two paths References: <0IAF00CWP8XHDI@smtp14.wxs.nl> <41EB8EC6.5070607@wxs.nl> <41EB9BD5.8050008@wxs.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.5 required=7.5 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Virus-Scanned: ClamAV 0.80/540/Tue Oct 19 14:59:23 2004 clamav-milter version 0.80j on mailrelay01 X-Virus-Status: Clean X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 17 Jan 2005 13:43:50 +0100 (CET) Laurence Finston wrote: > With all due respect, I think this is an area where TeX and MF > use completely different strategies. If I remember correctly, > Knuth had to be talked into including loops in TeX, and in my there are no loops in tex > opinion, they're not the nicest part of TeX. While TeX has > loops and MF has macros, if I had to describe both tex and mf/mp have macros > TeX and MF in no more than two words each, I would say that TeX > is a "macro processor" and MF is an "interpreter". It therefore hm, both are macro-interpreters -) > stands to reason that the implementation of macros, including the > handling of recursion, would be especially efficient in TeX, while > that of loops would be especially efficient in MF. In GNU 3DLDF, > and I suspect in MF, the cost of a macro call is largely the cost > of copying the replacement text, replacing placeholders with the > arguments, arranging to read input from the copy, and arranging to > return to the original input source when it's been read. a few differences: - in tex output and 'programming' are mixed - mp has functions with return values (vardef etc) which tex unfortunalty lacks - tex and mp have a different concept of grouping for the rest, they serve a different purpose; also, my guess is that knuth made them different (in some language aspects) simply in order to demonstrate different mechanisms; keep in mind that both programs served as examples of documented code for his students Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl ----------------------------------------------------------------- From - Mon Jan 17 14:00:47 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0HD0i6o065215 for ; Mon, 17 Jan 2005 14:00:44 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CqWUr-0008ER-Lk; Mon, 17 Jan 2005 14:00:42 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0HD0fh0000029962; Mon, 17 Jan 2005 14:00:41 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Mon, 17 Jan 2005 14:00:40 +0100 (MET) From: Laurence Finston To: Hans Hagen cc: Larry Siebenmann , B_Jackowski@GUST.org.pl, antonio.ramirez@gmail.com, help-3dldf , metafont@ens.fr, metapost@tug.org Subject: Re: [metafont] Re: all intersections between two paths In-Reply-To: <41EBB30D.9040005@wxs.nl> Message-ID: References: <0IAF00CWP8XHDI@smtp14.wxs.nl> <41EB8EC6.5070607@wxs.nl> <41EB9BD5.8050008@wxs.nl> <41EBB30D.9040005@wxs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 17 Jan 2005 14:00:44 +0100 (CET) On Mon, 17 Jan 2005, Hans Hagen wrote: > there are no loops in tex %% ttest.tex \count255=0 \loop \message{\count255 == \the\count255.} \advance\count255 by 1 \ifnum\count255<3 \repeat \bye --> lfinsto1> tex ttest tex ttest This is TeX, Version 3.14159 (Web2C 7.3.7) (./ttest.tex \count 255 == 0. \count 255 == 1. \count 255 == 2. ) No pages of output. Transcript written on ttest.log. Laurence From - Mon Jan 17 14:04:10 2005 Return-Path: Received: from mta1.cl.cam.ac.uk (mta1.cl.cam.ac.uk [128.232.0.15]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0HD48Ym067414 for ; Mon, 17 Jan 2005 14:04:08 +0100 (CET) Received: from mole.cl.cam.ac.uk ([128.232.8.151] helo=cl.cam.ac.uk ident=[qC6WyrMZwJZpiB15JRuIvBeDkUIep32j]) by mta1.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 1CqWXw-0007Jx-00; Mon, 17 Jan 2005 13:03:52 +0000 To: Laurence Finston cc: Hans Hagen , Larry Siebenmann , B_Jackowski@GUST.org.pl, antonio.ramirez@gmail.com, help-3dldf , metafont@ens.fr, metapost@tug.org Subject: Re: [metafont] Re: all intersections between two paths In-reply-to: Your message of Mon, 17 Jan 2005 14:00:40 +0100. Date: Mon, 17 Jan 2005 13:03:52 +0000 From: Robin Fairbairns Message-Id: X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 17 Jan 2005 14:04:08 +0100 (CET) > On Mon, 17 Jan 2005, Hans Hagen wrote: > > > there are no loops in tex > > %% ttest.tex > > \count255=0 > > \loop i think you confuse the name with the implementation. the macro simulates something approximating the semantics of "loop" using tail-recursion. From - Mon Jan 17 14:06:18 2005 Return-Path: Received: from kerberos2.troja.mff.cuni.cz (kerberos2.troja.mff.cuni.cz [195.113.28.3]) by nef2.ens.fr (8.12.11/1.01.28121999) with SMTP id j0HD6FhN068896 for ; Mon, 17 Jan 2005 14:06:15 +0100 (CET) Received: (qmail 9737 invoked from network); 17 Jan 2005 13:06:17 -0000 Received: from mbox.troja.mff.cuni.cz (195.113.28.2) by kerberos2.troja.mff.cuni.cz with SMTP; 17 Jan 2005 13:06:17 -0000 Received: (qmail 19358 invoked by uid 43797); 17 Jan 2005 13:06:11 -0000 Date: Mon, 17 Jan 2005 14:06:11 +0100 (MET) From: Honza Prachar cc: metapost@tug.org, metafont@ens.fr In-Reply-To: <41DC1F76.8050300@elvenkind.com> Message-ID: <20050117135359.44D6.0@mbox.troja.mff.cuni.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 17 Jan 2005 14:06:15 +0100 (CET) Hello! Do you have any idea how to do a tangent to path p from point z. -- `Honza` Prachar From - Mon Jan 17 14:17:46 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0HDHfDR076449 for ; Mon, 17 Jan 2005 14:17:41 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CqWlG-0007xO-7q; Mon, 17 Jan 2005 14:17:38 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0HDHbG0000030196; Mon, 17 Jan 2005 14:17:38 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Mon, 17 Jan 2005 14:17:37 +0100 (MET) From: Laurence Finston To: Hans Hagen cc: Larry Siebenmann , B_Jackowski@GUST.org.pl, antonio.ramirez@gmail.com, help-3dldf , metafont@ens.fr, metapost@tug.org Subject: Re: [metafont] Re: all intersections between two paths In-Reply-To: <41EBB30D.9040005@wxs.nl> Message-ID: References: <0IAF00CWP8XHDI@smtp14.wxs.nl> <41EB8EC6.5070607@wxs.nl> <41EB9BD5.8050008@wxs.nl> <41EBB30D.9040005@wxs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 17 Jan 2005 14:17:41 +0100 (CET) On Mon, 17 Jan 2005, Hans Hagen wrote: > also, my guess is that knuth made > them different (in some language aspects) simply in order to demonstrate > different mechanisms; keep in mind that both programs served as examples of > documented code for his students I've found that reading the documentation for GNU m4 and GNU Bison, and using the latter to write the parser for GNU 3DLDF has improved my insight into TeX and MF. I now have a better idea of why they are the way they are. It was helpful to read about standard tools for macro processing and compiler generation. Meaning no disrespect to Knuth, I find that his very low-level style of programming (at that time) is an obstacle to learning the internals of TeX and Metafont. I've started both _TeX: The Program_ and _METAFONT: The Program_ several times, but I've never finished them, because it was clear to me that I wasn't going to program that way. If I want to learn about low-level programming, I'd rather read about MIX and MMIX. Laurence From - Mon Jan 17 14:22:07 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0HDM1Ns079572 for ; Mon, 17 Jan 2005 14:22:01 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CqWpS-00013f-8e; Mon, 17 Jan 2005 14:21:58 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0HDLwn0000030240; Mon, 17 Jan 2005 14:21:58 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Mon, 17 Jan 2005 14:21:57 +0100 (MET) From: Laurence Finston To: Robin Fairbairns cc: Hans Hagen , Larry Siebenmann , B_Jackowski@GUST.org.pl, antonio.ramirez@gmail.com, help-3dldf , metafont@ens.fr, metapost@tug.org Subject: Re: [metafont] Re: all intersections between two paths In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 17 Jan 2005 14:22:01 +0100 (CET) On Mon, 17 Jan 2005, Robin Fairbairns wrote: > > \loop > > i think you confuse the name with the implementation. > > the macro simulates something approximating the semantics of "loop" > using tail-recursion. > For me, if it loops, it's a loop. However, I'm willing to concede the point, and thanks for the information. Laurence From - Mon Jan 17 14:39:39 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0HDdbdd091328 for ; Mon, 17 Jan 2005 14:39:37 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CqX6U-0008Fx-Vl; Mon, 17 Jan 2005 14:39:35 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0HDdYn0000031509; Mon, 17 Jan 2005 14:39:34 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Mon, 17 Jan 2005 14:39:34 +0100 (MET) From: Laurence Finston To: Robin Fairbairns cc: Hans Hagen , Larry Siebenmann , B_Jackowski@GUST.org.pl, antonio.ramirez@gmail.com, help-3dldf , metafont@ens.fr, metapost@tug.org Subject: Re: [metafont] Re: all intersections between two paths In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 17 Jan 2005 14:39:37 +0100 (CET) > On Mon, 17 Jan 2005, Robin Fairbairns wrote: > > > > \loop > > > > i think you confuse the name with the implementation. > > > > For me, if it loops, it's a loop. However, I'm willing to concede the > point, and thanks for the information. > How embarassing! I was missing the point that `\loop ... \repeat' is a macro defined in plain TeX and not part of TeX proper. I'm assuming this is true, since I don't have my _TeXbook_ handy, and can't check. Thanks for clearing up my confusion. Laurence From - Mon Jan 17 18:18:07 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0HHI4W3025341 for ; Mon, 17 Jan 2005 18:18:04 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CqaVt-0008Da-On; Mon, 17 Jan 2005 18:18:02 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0HHI1c0000036575; Mon, 17 Jan 2005 18:18:01 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Mon, 17 Jan 2005 18:18:00 +0100 (MET) From: Laurence Finston To: Honza Prachar cc: metafont@ens.fr, metapost@tug.org Subject: Re: [metapost] (no subject) In-Reply-To: <20050117135359.44D6.0@mbox.troja.mff.cuni.cz> Message-ID: References: <20050117135359.44D6.0@mbox.troja.mff.cuni.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 17 Jan 2005 18:18:04 +0100 (CET) On Mon, 17 Jan 2005, Honza Prachar wrote: > > Do you have any idea how to do a tangent to path p from point z. > You'll have to be more specific. For example, a `path' can represent a straight line segment, in which case the problem reduces to determining whether `z' lies on that line. It could also represent an `ellipse', so if `z' is located at one of the corners of the surrounding rectangle, it lies on two tangents to the `path'. I believe you can use `directiontimes' to determine the direction in which a `path' is travelling at a given "time", but I don't have my _METAFONTbook_ handy, so I can't look this up. Since MF's `paths' are Bezier curves, and the latter can approximate a very wide range of curves, you could potentially have a very large number of tangents. This sounds like a job for Larry Siebenmann and Boguslaw Jackowski! Laurence Finston http:/www.gnu.org/software/3dldf/LDF.html From - Mon Jan 17 18:29:22 2005 Return-Path: Received: from kerberos2.troja.mff.cuni.cz (kerberos2.troja.mff.cuni.cz [195.113.28.3]) by nef2.ens.fr (8.12.11/1.01.28121999) with SMTP id j0HHTGFn032159 for ; Mon, 17 Jan 2005 18:29:16 +0100 (CET) Received: (qmail 19671 invoked from network); 17 Jan 2005 17:29:19 -0000 Received: from mbox.troja.mff.cuni.cz (195.113.28.2) by kerberos2.troja.mff.cuni.cz with SMTP; 17 Jan 2005 17:29:19 -0000 Received: (qmail 2522 invoked by uid 43797); 17 Jan 2005 17:29:13 -0000 Date: Mon, 17 Jan 2005 18:29:13 +0100 (MET) From: Honza Prachar To: Laurence Finston cc: metafont@ens.fr, metapost@tug.org Subject: Re: [metapost] tangent In-Reply-To: Message-ID: <20050117182244.44D6.0@mbox.troja.mff.cuni.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 17 Jan 2005 18:29:16 +0100 (CET) On Mon, 17 Jan 2005, Laurence Finston wrote: > You'll have to be more specific. For example, a `path' can represent > a straight line segment, in which case the problem reduces to > determining whether `z' lies on that line. It could also represent an > `ellipse', so if `z' is located at one of the corners of the > surrounding rectangle, it lies on two tangents to the `path'. I meant general curve. I found solution using loop to determine right point, where tangent and curve have same direction. But I do not believe it is the simpliest solution. `Honza` Prachar From - Mon Jan 17 18:36:59 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0HHasVu036819 for ; Mon, 17 Jan 2005 18:36:54 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1Cqao7-0005OO-Ks; Mon, 17 Jan 2005 18:36:52 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0HHapc0000037847; Mon, 17 Jan 2005 18:36:51 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Mon, 17 Jan 2005 18:36:51 +0100 (MET) From: Laurence Finston To: Honza Prachar cc: metafont@ens.fr, metapost@tug.org Subject: Re: [metapost] tangent In-Reply-To: <20050117182244.44D6.0@mbox.troja.mff.cuni.cz> Message-ID: References: <20050117182244.44D6.0@mbox.troja.mff.cuni.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 17 Jan 2005 18:36:54 +0100 (CET) On Mon, 17 Jan 2005, Honza Prachar wrote: > I meant general curve. I found solution using loop to determine right > point, where tangent and curve have same direction. But I do not believe > it is the simpliest solution. > This is another situation where one will have to look for solutions on the basis of individual segments of the curves, i.e., sets of 4 control points where the first and last control points lie on the curve. Metafont "just" chains these segments together. So you're going to have to loop or recurse no matter what. However, I have every faith that one of the good mathematicians on this list can give you some hints, and maybe even a canned solution. Laurence From - Mon Jan 17 21:42:22 2005 Return-Path: Received: from coxeter.math.toronto.edu (coxeter.math.toronto.edu [128.100.68.3]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0HKgGn6043336 for ; Mon, 17 Jan 2005 21:42:16 +0100 (CET) Received: (from laurent@localhost) by coxeter.math.toronto.edu (AIX5.2/8.11.6p2/8.11.0/UTMath 1.0) id j0HKful123698; Mon, 17 Jan 2005 15:41:56 -0500 Date: Mon, 17 Jan 2005 15:41:56 -0500 From: Larry Siebenmann Message-Id: <200501172041.j0HKful123698@coxeter.math.toronto.edu> To: help-3dldf@gnu.org, laurent@math.toronto.edu, lfinsto1@gwdg.de, metafont@ens.fr, pracj3am@mbox.troja.mff.cuni.cz Subject: Honza's puzzler X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 17 Jan 2005 21:42:16 +0100 (CET) On Mon, 17 Jan 2005 14:06:11, on the metapost@tug.org list, Honza Prachar wrote : > Hello! > > Do you have any idea how to do a tangent to path p from point z. > > `Honza` Prachar Hi 'Honza'! That is a cherry-bomb in a tearoom ;-) We like to think that MP/MF does simple things with gracefully! The condition of tangency is that the two vectors in R^2 that are repectively the t-derivative p'(t) and the difference p(t) - z be linearly dependent. But linear dependency occurs if and only if the following determinant condition holds: D(t) := det( p'(t) , p(t) - z ) = 0 This determinant is clearly of degree 5 in t, at most. But inspection shows that the term of degree 5 in t vanishes. So the degree is 4 or less. D(t) is, in fact, generically of degree 4 in t. One can see this geometrically by considering any bezier cubic with a double point. Taking arbitrary z in the region 'just below' the double point there are obviously four distinct lines on point z tangent to path p. xxx xxxx xxxx xxx xxx xx xx xxx xxx xxxx xxxx xxxxx xxxxx Z xxxxx xxxxxx xxxxxx xxxxxx xxxxxxx Now if MP could intersect quartic bezier curves is would be a simple matter to find the roots:- just intersect the line x=0 with the curve q(t)=(t,D(t)). Until then, since quartics are solvable by extraction of square roots, one can squeeze an (excruciatingly boring?) solution out of metafont -- using sqrt. But there may still exist an elegant geometrical solution within MP ... Cheers Laurent S. From - Mon Jan 17 23:09:32 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0HM9UGM096144 for ; Mon, 17 Jan 2005 23:09:30 +0100 (CET) Message-Id: <200501172209.j0HM9UGM096144@nef2.ens.fr> Received: from mailbox.gwdg.de ([134.76.10.21] helo=gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.42) id 1Cqf3w-0004Iq-7I; Mon, 17 Jan 2005 23:09:28 +0100 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 17 Jan 2005 23:09:27 +0100 MIME-Version: 1.0 Subject: recursion in MP/ MF [was: all intersections between two paths] Cc: help-3dldf@gnu.org Content-Transfer-Encoding: 8bit User-Agent: IMHO/0.98.3+G (Webmail for Roxen) X-Originating-IP: lfinsto1[134.76.139.103] From: "Laurence Finston" To: metapost@tug.org, metafont@ens.fr X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 17 Jan 2005 23:09:30 +0100 (CET) Hello, I made the following experiment to test whether GCC (the GNU Compiler Collection) would optimize recursive function calls such that tail recursion would be performed. The results of the experiment indicate that it does not. I have tried to make the program as good a candidate as possible for this, but perhaps I'm missing something. If so, I'd appreciate it if someone would put me straight. Thanks, Laurence ********* The test program. // testrcrs.c++ // Created by Laurence Finston Mo Jan 17 22:18:16 CET 2005 #include #include #include #include using namespace std; void a(int ctr) { cerr << "In `a': `ctr' == " << ctr << endl; if (ctr > 0) a(ctr - 1); return; } int main (int argc, char** argv) { a(3); return 0; } ***** Excerpts from the GCC man page: This indicates that using the `-g' option to `g++' should not cause tail recursion to be disabled. *************************** COPYRIGHT Copyright (c) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc. Unlike most other C compilers, GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce sur- prising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops. -foptimize-sibling-calls Optimize sibling and tail recursive calls. Enabled at levels -O2, -O3, -Os. ********** The compilation command: g++ -g -O3 testrcrs.c++ *********** Excerpts from a gdb (The GNU Debugger) session: run Starting program: /ramdisk/home/knoppix/tmp/a.out Breakpoint 1, a (ctr=1076064912) at testrcrs.c++:16 Breakpoint 1, a (ctr=3) at testrcrs.c++:16 (gdb) bt #0 a (ctr=3) at testrcrs.c++:16 #1 0x08048853 in a (ctr=3) at testrcrs.c++:19 #2 0x08048885 in main (argc=1, argv=0xbffffc74) at testrcrs.c++:30 Breakpoint 1, a (ctr=2) at testrcrs.c++:16 (gdb) bt #0 a (ctr=2) at testrcrs.c++:16 #1 0x08048853 in a (ctr=2) at testrcrs.c++:19 #2 0x08048853 in a (ctr=3) at testrcrs.c++:19 #3 0x08048885 in main (argc=1, argv=0xbffffc74) at testrcrs.c++:30 Breakpoint 1, a (ctr=1) at testrcrs.c++:16 (gdb) bt #0 a (ctr=1) at testrcrs.c++:16 #1 0x08048853 in a (ctr=1) at testrcrs.c++:19 #2 0x08048853 in a (ctr=2) at testrcrs.c++:19 #3 0x08048853 in a (ctr=3) at testrcrs.c++:19 #4 0x08048885 in main (argc=1, argv=0xbffffc74) at testrcrs.c++:30 From - Tue Jan 18 09:31:32 2005 Return-Path: Received: from smatten.engebretsen.se (as2-4-5.cy.s.bonet.se [217.215.4.117]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0I8VRBO018433 for ; Tue, 18 Jan 2005 09:31:27 +0100 (CET) Received: from smatten.engebretsen.se (smatten.engebretsen.se [127.0.0.1]) by smatten.engebretsen.se (8.13.1/8.13.1) with ESMTP id j0I8VQgf015588; Tue, 18 Jan 2005 09:31:26 +0100 Received: (from enge@localhost) by smatten.engebretsen.se (8.13.1/8.13.1/Submit) id j0I8VQCB015587; Tue, 18 Jan 2005 09:31:26 +0100 X-Authentication-Warning: smatten.engebretsen.se: enge set sender to enge@nada.kth.se using -f Subject: Re: [metapost] recursion in MP/ MF [was: all intersections between two paths] From: Lars Engebretsen Reply-To: enge@nada.kth.se To: Laurence Finston Cc: metapost@tug.org, metafont@ens.fr, help-3dldf@gnu.org In-Reply-To: <200501172211.j0HMBVV26184@tug.org> References: <200501172211.j0HMBVV26184@tug.org> Content-Type: text/plain; charset=utf-8 Organization: KTH/NADA Date: Tue, 18 Jan 2005 09:31:26 +0100 Message-Id: <1106037086.15474.8.camel@smatten.engebretsen.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Tue, 18 Jan 2005 09:31:27 +0100 (CET) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nef2.ens.fr id j0I8VRBO018433 mÃ¥n 2005-01-17 klockan 23:09 +0100 skrev Laurence Finston: > Hello, > > I made the following experiment to test whether GCC > (the GNU Compiler Collection) would optimize recursive > function calls such that tail recursion would be performed. > The results of the experiment indicate that it does not. > I have tried to make the program as good a candidate as > possible for this, but perhaps I'm missing something. > If so, I'd appreciate it if someone would put me straight. It could depend on the backend. I'm not an expert in SPARC assembler, but it seems that with that back end, the stack frame for the current recursive call is removed during the delay slot corresponding to the next recursive function call. I generated the assembler code with g++ -S -foptimize-sibling-calls testrcrs.cc using gcc 3.4.2. /Lars From - Tue Jan 18 09:42:43 2005 Return-Path: Received: from mail2.sun.ac.za (mail2.sun.ac.za [146.232.64.14]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0I8gcAj025680 for ; Tue, 18 Jan 2005 09:42:39 +0100 (CET) Received: from gawie.sun.ac.za ([146.232.42.231]) by mail2.sun.ac.za with esmtp (Exim 4.34) id 1Cqowd-0007d6-Lp for metafont@ens.fr; Tue, 18 Jan 2005 10:42:35 +0200 Received: from gawie.sun.ac.za (localhost.localdomain [127.0.0.1]) by gawie.sun.ac.za (8.12.10/8.12.10) with ESMTP id j0I8gZvC019463 for ; Tue, 18 Jan 2005 10:42:35 +0200 Received: (from dirk@localhost) by gawie.sun.ac.za (8.12.10/8.12.10/Submit) id j0I8gP6K019461 for metafont@ens.fr; Tue, 18 Jan 2005 10:42:25 +0200 Date: Tue, 18 Jan 2005 10:42:25 +0200 From: Dirk Laurie To: metafont@ens.fr Subject: Re: [metafont] Honza's puzzler Message-ID: <20050118084225.GA19444@gawie.sun.ac.za> Mail-Followup-To: Dirk Laurie , metafont@ens.fr References: <200501172041.j0HKful123698@coxeter.math.toronto.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501172041.j0HKful123698@coxeter.math.toronto.edu> User-Agent: Mutt/1.4.1i X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Tue, 18 Jan 2005 09:42:39 +0100 (CET) Larry Siebenmann skryf: > > > On Mon, 17 Jan 2005 14:06:11, on the metapost@tug.org list, Honza > Prachar wrote : > > > Hello! > > > > Do you have any idea how to do a tangent to path p from point z. > > > > `Honza` Prachar > > > But there may still exist an elegant geometrical solution > within MP ... > Here is an attempt. The geometrical method is: given an approximate tangent point, connect to point z to give an approximate tangent; the new approximate tangent point is the closest point on the curve where the slope equals that of the approximate tangent. Exercise for the reader: prove that under suitable conditions, this process is quadratically convergent. % Find time near d on path p where line from z is tangent vardef tangenttime(expr z, p, d) = save s,t,iter; numeric t,iter; pair s; t:=d; iter:=0; forever: t0:=t; iter:=iter+1; s:=(p at t)-z; t1:=directiontime s of p; t2:=directiontime -s of p; if abs(t-t1)6) or (abs(t-t0)<0.0001)); endfor if iter>6: errmessage "no convergence in tangentpoint"; fi t enddef; E.g. *path ct; ct:=(0,0)..(1,0)..(1,1)..(0,1)..cycle; *show tangenttime((-2,0),ct,3); >> 2.80913 *show tangenttime((-2,0),ct,1); >> 0.4452 Dirk From - Tue Jan 18 10:09:18 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0I99Fvs042477 for ; Tue, 18 Jan 2005 10:09:15 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CqpMP-0004AQ-0n; Tue, 18 Jan 2005 10:09:13 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0I99Cs0000058851; Tue, 18 Jan 2005 10:09:12 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Tue, 18 Jan 2005 10:09:12 +0100 (MET) From: Laurence Finston To: Lars Engebretsen cc: metapost@tug.org, metafont@ens.fr, help-3dldf@gnu.org Subject: Re: [metafont] Re: [metapost] recursion in MP/ MF [was: all intersections between two paths] In-Reply-To: <1106037086.15474.8.camel@smatten.engebretsen.se> Message-ID: References: <200501172211.j0HMBVV26184@tug.org> <1106037086.15474.8.camel@smatten.engebretsen.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Tue, 18 Jan 2005 10:09:15 +0100 (CET) On Tue, 18 Jan 2005, Lars Engebretsen wrote: > It could depend on the backend. I'm not an expert in SPARC > assembler, but it seems that with that back end, the stack frame > for the current recursive call is removed during the delay slot > corresponding to the next recursive function call. > > I generated the assembler code with > > g++ -S -foptimize-sibling-calls testrcrs.cc > > using gcc 3.4.2. > Thanks for your answer. Please excuse my obtuseness, but I don't understand it. Does this mean that the compiler is causing tail recursion to be performed? If so, is this disabled when you use the `-g' option? Or does the problem lie with GDB? Laurence From - Tue Jan 18 10:22:16 2005 Return-Path: Received: from mailrelay01.solcon.nl (maillb.solcon.nl [212.45.32.200]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0I9MCdp050341 for ; Tue, 18 Jan 2005 10:22:12 +0100 (CET) Received: from server-1.pragma-net.nl (dsl-212-84-128-085.solcon.nl [212.84.128.85]) by mailrelay01.solcon.nl (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id j0I9MA9n010466; Tue, 18 Jan 2005 10:22:10 +0100 Received: by server-1.pragma-net.nl (Postfix, from userid 65534) id ABCBA1A489; Tue, 18 Jan 2005 10:16:07 +0100 (CET) Received: from [127.0.0.1] (unknown [10.100.1.1]) by server-1.pragma-net.nl (Postfix) with ESMTP id 9B65717BF1; Tue, 18 Jan 2005 09:16:06 +0000 (UTC) Message-ID: <41ECD540.5030100@wxs.nl> Date: Tue, 18 Jan 2005 10:22:08 +0100 From: h h extern User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: metafont@ens.fr, metapost@tug.org Subject: Re: [metapost] (no subject) References: <20050117135359.44D6.0@mbox.troja.mff.cuni.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.6 required=7.5 tests=BAYES_00,IN_REP_TO,REFERENCES,USER_AGENT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Virus-Scanned: ClamAV 0.80/540/Tue Oct 19 14:59:23 2004 clamav-milter version 0.80j on mailrelay01 X-Virus-Status: Clean X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Tue, 18 Jan 2005 10:22:12 +0100 (CET) Hi, Can we stop posting to both the mf and mp list, just stick to the metapost one since this is the main metapost users/support list (managed, archived, etc); I don;t want to waste time on organizing duplicate mails -) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl ----------------------------------------------------------------- From - Tue Jan 18 10:36:43 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0I9ade1058608 for ; Tue, 18 Jan 2005 10:36:39 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1Cqpmu-0007TQ-VN; Tue, 18 Jan 2005 10:36:37 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0I9aak0000059361; Tue, 18 Jan 2005 10:36:36 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Tue, 18 Jan 2005 10:36:36 +0100 (MET) From: Laurence Finston To: h h extern cc: metafont@ens.fr, metapost@tug.org Subject: Re: [metafont] Re: [metapost] (no subject) In-Reply-To: <41ECD540.5030100@wxs.nl> Message-ID: References: <20050117135359.44D6.0@mbox.troja.mff.cuni.cz> <41ECD540.5030100@wxs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Tue, 18 Jan 2005 10:36:39 +0100 (CET) On Tue, 18 Jan 2005, h h extern wrote: > > Can we stop posting to both the mf and mp list, just stick to the metapost one > since this is the main metapost users/support list (managed, archived, etc); I > don;t want to waste time on organizing duplicate mails -) > My purpose in posting to both lists was two-fold: 1) I want to support the effort to have a MetaPost mailing list. 2) I want to help keep `metafont@ens.fr' active. I also would like to have postings on some subjects in the `help-3dldf' archive, so I'd appreciate it if people would leave it on the "cc", if it's not too much trouble. I have generally tried to post on purely MP topics to the MP list and on purely MF topics to the MF list, but things are usually not so clear-cut. I sympathize with your desire to not have to cope with duplicate mails. I, too, find it annoying to get multiple copies of postings (even my own), and I know that opinions differ on cross-posting. Perhaps the list administrators would like to make a decision about this. Laurence From - Tue Jan 18 11:55:35 2005 Return-Path: Received: from mailrelay01.solcon.nl (maillb.solcon.nl [212.45.32.200]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0IAtWb2007187 for ; Tue, 18 Jan 2005 11:55:32 +0100 (CET) Received: from server-1.pragma-net.nl (dsl-212-84-128-085.solcon.nl [212.84.128.85]) by mailrelay01.solcon.nl (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id j0IAtTKB008497; Tue, 18 Jan 2005 11:55:29 +0100 Received: by server-1.pragma-net.nl (Postfix, from userid 65534) id C954917CBF; Tue, 18 Jan 2005 11:49:26 +0100 (CET) Received: from [127.0.0.1] (unknown [10.100.1.1]) by server-1.pragma-net.nl (Postfix) with ESMTP id 55A2D17B14; Tue, 18 Jan 2005 10:49:25 +0000 (UTC) Message-ID: <41ECEB20.60204@wxs.nl> Date: Tue, 18 Jan 2005 11:55:28 +0100 From: h h extern User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Laurence Finston Cc: metafont@ens.fr, metapost@tug.org Subject: Re: [metafont] Re: [metapost] (no subject) References: <20050117135359.44D6.0@mbox.troja.mff.cuni.cz> <41ECD540.5030100@wxs.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.5 required=7.5 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Virus-Scanned: ClamAV 0.80/540/Tue Oct 19 14:59:23 2004 clamav-milter version 0.80j on mailrelay01 X-Virus-Status: Clean X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Tue, 18 Jan 2005 11:55:32 +0100 (CET) Laurence Finston wrote: > My purpose in posting to both lists was two-fold: > 1) I want to support the effort to have a MetaPost mailing list. > 2) I want to help keep `metafont@ens.fr' active. imo, in a sense mf is kind of 'dead', i.e. replaced by metapost and/or font editing programs and.or a combination of those Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl ----------------------------------------------------------------- From - Tue Jan 18 14:53:10 2005 Return-Path: Received: from ares.md.kth.se (ares.md.kth.se [130.237.57.10]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0IDr4XL011937 for ; Tue, 18 Jan 2005 14:53:05 +0100 (CET) Received: from localhost (radien.md.kth.se [130.237.57.166]) by localhost.md.kth.se (Postfix) with ESMTP id 9088EA758C; Tue, 18 Jan 2005 14:53:04 +0100 (CET) Received: from ares.md.kth.se ([130.237.57.10]) by localhost (radien.md.kth.se [130.237.57.166]) (amavisd-new, port 10027) with ESMTP id 06438-02; Tue, 18 Jan 2005 14:53:03 +0100 (CET) Received: from ares.md.kth.se (radien.md.kth.se [130.237.57.166]) by localhost.md.kth.se (Postfix) with ESMTP id A754EA758D; Tue, 18 Jan 2005 14:53:03 +0100 (CET) Received: from ludde (ludde.md.kth.se [130.237.57.34]) by ares.md.kth.se (Postfix) with ESMTP id 7370FA758C; Tue, 18 Jan 2005 14:53:03 +0100 (CET) Date: Tue, 18 Jan 2005 14:53:03 +0100 (CET) From: Johan Ingvast To: light Cc: metafont@ens.fr Subject: Re: [metafont] [question about metapost]How to make color text in boxes? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Tue, 18 Jan 2005 14:53:05 +0100 (CET) Hi The pictures that btex ... etex generates can be painted in any color when drawn. I use label(btex $A$ etex withcolor red, origin); and the like alot. I guess you colud do something similar using the image command. circleit.a(image( draw btex $A$ etex withcolor white) ); /johan On Fri, 13 Aug 2004, light wrote: > Hi > > I make a circle box and fill it with black background. The default > text color is black too, so the text and the background mix up and > can't be distinguished from each other. > > Is there any way to specify a different color for the text? for > instance, white, red and so on. > > I have tried to use LaTeX's "color" package as follows: > -------------------------------------------------------------- > verbatimtex > %&latex > \documentclass{article} > \usepackage{color} > \begin{document} > etex > ... > circleit.a(btex \textcolor{white}{$A$} etex); > fill bpath.a withcolor (0,0,0); > drawboxed(a); > ... > verbatimtex > \end{document} > etex > --------------------------------------------------------------- > very disappointed, The text color remains black and the "color" > package seems can't to change the text color. > > Who can help me achieve this goal? > > Thanks for any advise! > > Tang > > > -- Johan Ingvast, PhD student http://www.md.kth.se/~ingvast Department of Machine Design, Royal Institute of Technology, Sweden http://www.md.kth.se, http://www.md.kth.se/~cas <--- Walking robot proj tel +46 (0)8 790 95 36 mob. +46 (0)70 34 34 498 From - Wed Jan 19 05:42:31 2005 Return-Path: Received: from coxeter.math.toronto.edu (coxeter.math.toronto.edu [128.100.68.3]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0J4gR8S090352 for ; Wed, 19 Jan 2005 05:42:28 +0100 (CET) Received: (from laurent@localhost) by coxeter.math.toronto.edu (AIX5.2/8.11.6p2/8.11.0/UTMath 1.0) id j0J4gQf199844; Tue, 18 Jan 2005 23:42:26 -0500 Date: Tue, 18 Jan 2005 23:42:26 -0500 From: Larry Siebenmann Message-Id: <200501190442.j0J4gQf199844@coxeter.math.toronto.edu> To: laurent@math.toronto.edu, metafont@ens.fr, metapost@tug.org Subject: Re: [metafont] Re: [metapost] X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 19 Jan 2005 05:42:28 +0100 (CET) Hans wrote (Tue Jan 18 05:56:10 2005): > imo, in a sense mf is kind of 'dead', i.e. replaced by metapost > and/or font editing programs and.or a combination of those The opposite seems just as plausible. Metapost and metafont will either prosper together or perish together. A parting of these siamese twins could be fatal to both. As for the idea that both will perish, let us recall that, already in the early 90's, the demise of TeX was predicted not just by commercials, but by certain directors of the AMS (bb excluded!). Instead, the plush GUI environments competing with TeX have withered with the OSs and interfaces for which they were built, like autumn leaves before the winter winds. I hope metafont is just as welcome on the metapost list as metapost has been on the metafont list. Simply a *meta* list would be another solution. Cheers Laurent S. PS. With luck this will be the first message that I manage to post on the metapost list (I have had to switch accounts temporarily to do so -- firewall problems etc...). I regret that my inability hitherto to post directly has inconvenienced some. Lets see whether tug.org can equal the @ens.fr setup in reliability so that crossposting will fade! At tug.org, the prospect of a better list interface with quicker and broader archiving is very pleasing. From - Wed Jan 19 06:32:11 2005 Return-Path: Received: from mail3.sun.ac.za (mail3.sun.ac.za [146.232.64.13]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0J5W7Z0020229 for ; Wed, 19 Jan 2005 06:32:07 +0100 (CET) Received: from gawie.sun.ac.za ([146.232.42.231]) by mail3.sun.ac.za with esmtp (Exim 4.34) id 1Cr8Rp-0005jq-8x; Wed, 19 Jan 2005 07:32:05 +0200 Received: from gawie.sun.ac.za (localhost.localdomain [127.0.0.1]) by gawie.sun.ac.za (8.12.10/8.12.10) with ESMTP id j0J5W5vC024427; Wed, 19 Jan 2005 07:32:05 +0200 Received: (from dirk@localhost) by gawie.sun.ac.za (8.12.10/8.12.10/Submit) id j0J5W38Z024425; Wed, 19 Jan 2005 07:32:03 +0200 Date: Wed, 19 Jan 2005 07:32:03 +0200 From: Dirk Laurie To: Larry Siebenmann Cc: metafont@ens.fr, metapost@tug.org Subject: Re: [metafont] Re: [metapost] Message-ID: <20050119053203.GA24410@gawie.sun.ac.za> Mail-Followup-To: Dirk Laurie , Larry Siebenmann , metafont@ens.fr, metapost@tug.org References: <200501190442.j0J4gQf199844@coxeter.math.toronto.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501190442.j0J4gQf199844@coxeter.math.toronto.edu> User-Agent: Mutt/1.4.1i X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 19 Jan 2005 06:32:07 +0100 (CET) Larry Siebenmann skryf: > > I hope metafont is just as welcome on the metapost list as > metapost has been on the metafont list. Simply a *meta* list > would be another solution. > Yes, yes, yes! From - Wed Jan 19 08:37:21 2005 Return-Path: Received: from smtp16.wxs.nl (smtp16.wxs.nl [195.121.6.39]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0J7bHkG094433 for ; Wed, 19 Jan 2005 08:37:17 +0100 (CET) Received: from [62.131.80.185] (ip3e8350b9.speed.planet.nl [62.131.80.185]) by smtp16.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IAJ00KEXZU53I@smtp16.wxs.nl> for metafont@ens.fr; Wed, 19 Jan 2005 08:37:17 +0100 (CET) Received: from 127.0.0.1 (AVG SMTP 7.0.300 [265.7.0]); Wed, 19 Jan 2005 08:37:16 +0100 Date: Wed, 19 Jan 2005 08:37:15 +0100 From: Christophe Grandsire Subject: Re: [metafont] Re: [metapost] In-reply-to: <200501190442.j0J4gQf199844@coxeter.math.toronto.edu> To: Liste Metafont Message-id: <41EE0E2B.9060703@free.fr> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) References: <200501190442.j0J4gQf199844@coxeter.math.toronto.edu> X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 19 Jan 2005 08:37:17 +0100 (CET) En réponse à Larry Siebenmann : > Hans wrote (Tue Jan 18 05:56:10 2005): > > > imo, in a sense mf is kind of 'dead', i.e. replaced by metapost > > and/or font editing programs and.or a combination of those > > The opposite seems just as plausible. Metapost and metafont will > either prosper together or perish together. A parting of these > siamese twins could be fatal to both. > Exactly! Not only that, but there are some people out there trying to keep METAFONT very much alive ;) (I don't usually name people but I can point, at myself in this case ;) ). Check at http://metafont.tutorial.free.fr (/ shameless plug ;) ), which is far from finished, but has already brought people who knew nothing about METAFONT to take an interest in it :) . > As for the idea that both will perish, let us recall that, already in > the early 90's, the demise of TeX was predicted not just by > commercials, but by certain directors of the AMS (bb excluded!). > Instead, the plush GUI environments competing with TeX have withered > with the OSs and interfaces for which they were built, like autumn > leaves before the winter winds. > Hear hear! In 99 when I worked for Philips (yes, Philips! not even a university) it was unthinkable to write your reports in anything else but LaTeX (which is how I got in contact with the wonderful world of TeX/LaTeX :) ). So much for a dead program ;) . And as long as TeX is alive, METAFONT will live. The only thing it needs is a bit of recognition ;) . > I hope metafont is just as welcome on the metapost list as > metapost has been on the metafont list. Simply a *meta* list > would be another solution. > I completely agree. -- Christophe Grandsire. http://rainbow.conlang.free.fr You need a straight mind to invent a twisted conlang. From - Wed Jan 19 08:47:05 2005 Return-Path: Received: from mta1.cl.cam.ac.uk (mta1.cl.cam.ac.uk [128.232.0.15]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0J7l2hR001268 for ; Wed, 19 Jan 2005 08:47:02 +0100 (CET) Received: from mole.cl.cam.ac.uk ([128.232.8.151] helo=cl.cam.ac.uk ident=[+giWfjHT85xqGCd+4hGCRUc6XeWDm32o]) by mta1.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 1CrAYQ-00011p-00 for metafont@ens.fr; Wed, 19 Jan 2005 07:47:02 +0000 To: Liste Metafont Subject: Re: [metafont] Re: [metapost] In-reply-to: Your message of Wed, 19 Jan 2005 08:37:15 +0100. <41EE0E2B.9060703@free.fr> Date: Wed, 19 Jan 2005 07:47:02 +0000 From: Robin Fairbairns Message-Id: X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 19 Jan 2005 08:47:02 +0100 (CET) Christophe Grandsire writes: > [....] Not only that, but there are some people out there trying to > keep METAFONT very much alive ;) (I don't usually name people but I can > point, at myself in this case ;) ). Check at > http://metafont.tutorial.free.fr (/ shameless plug ;) ), which is far > from finished, but has already brought people who knew nothing about > METAFONT to take an interest in it :) . i am a great fan of your tutorial, and i advertise it in the uk faq. (i don't use metafont much, so hadn't spotted the "holes".) i don't know where i first heard of yours, but everyone please note that i am eager to learn of other tutorials for both -font and -post -- it's easy enough to find tutorials for latex, but the meta- community seems less eager to document and inform. christophe excepted, of course... :-) robin From - Wed Jan 19 08:55:54 2005 Return-Path: Received: from smtp16.wxs.nl (smtp16.wxs.nl [195.121.6.39]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0J7toWo007697 for ; Wed, 19 Jan 2005 08:55:50 +0100 (CET) Received: from [62.131.80.185] (ip3e8350b9.speed.planet.nl [62.131.80.185]) by smtp16.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IAK00K9B0P121@smtp16.wxs.nl> for metafont@ens.fr; Wed, 19 Jan 2005 08:55:49 +0100 (CET) Received: from 127.0.0.1 (AVG SMTP 7.0.300 [265.7.0]); Wed, 19 Jan 2005 08:55:49 +0100 Date: Wed, 19 Jan 2005 08:55:49 +0100 From: Christophe Grandsire Subject: Re: [metafont] Re: [metapost] In-reply-to: To: Liste Metafont Message-id: <41EE1285.2050506@free.fr> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) References: X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 19 Jan 2005 08:55:50 +0100 (CET) En réponse à Robin Fairbairns : > > i am a great fan of your tutorial, and i advertise it in the uk faq. > (i don't use metafont much, so hadn't spotted the "holes".) > Thanks! > i don't know where i first heard of yours, but everyone please note > that i am eager to learn of other tutorials for both -font and -post > -- it's easy enough to find tutorials for latex, but the meta- > community seems less eager to document and inform. > I know of a girl who is busy making a very short HOWTO make a simple font in METAFONT. I will host it on my tutorial site when it's ready. Otherwise, I agree with your comment. It's the main reason why I started writing that tutorial, feeling that it was the lack of documentation rather than any defect in the program that slowed down its recognition ;) . > christophe excepted, of course... :-) > Hehe... -- Christophe Grandsire. http://rainbow.conlang.free.fr You need a straight mind to invent a twisted conlang. From - Wed Jan 19 09:12:05 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0J8C3LX018627 for ; Wed, 19 Jan 2005 09:12:03 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CrAwc-00073H-Ph; Wed, 19 Jan 2005 09:12:03 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0J8C2L0000094629; Wed, 19 Jan 2005 09:12:02 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Wed, 19 Jan 2005 09:12:01 +0100 (MET) From: Laurence Finston To: Christophe Grandsire cc: metapost@tug.org, Liste Metafont Subject: Re: [metafont] Re: [metapost] In-Reply-To: <41EE0E2B.9060703@free.fr> Message-ID: References: <200501190442.j0J4gQf199844@coxeter.math.toronto.edu> <41EE0E2B.9060703@free.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 19 Jan 2005 09:12:03 +0100 (CET) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nef2.ens.fr id j0J8C3LX018627 On Wed, 19 Jan 2005, Christophe Grandsire wrote: > En réponse à Larry Siebenmann : > > Hans wrote (Tue Jan 18 05:56:10 2005): > > > > > imo, in a sense mf is kind of 'dead', i.e. replaced by metapost > > > and/or font editing programs and.or a combination of those > > I think it's nice that it's possible to use MP for making fonts, but if I specifically want a font, i.e., run-length encoded bit-maps, I think this would be a rather roundabout way of doing it. I also believe that the digitization routines of MF are interesting in their own right. In my field, linguistics, people often talk about "dead" languages, often implying a value judgement, as though "survival of the fittest" applied to languages. It's not so. Languages can't die, because they were never alive. My work with fonts involved making a font that imitates as closely as possible the writing used in a particular medieval manuscript. I also made a couple of fonts with modified characters from the cm and ec fonts to represent characters from that manuscript. Since the first font will probably only be used in a single work, it doesn't really matter to me how many other people are using MF. I suppose it would be possible to use PostScript to write the palaeographic font. I don't know PostScript, but from what I've seen of it, it doesn't look like it would be as much fun to program in as MF. That, for me, is really the main point. At the time I started learning MF, I was using Autocad (and Autolisp) a lot. LISP is one of my favorite languages, but it was still much more fun to write MF than Autolisp. That's why I chose to use the MF language as the basis of the GNU 3DLDF language. There are people interested in MF, so I think it's worthwhile to maintain the list. I think a single list would be a good idea, too, but it shouldn't be called `metapost@tug.org'. I apologize for the cross posting, and I'll be glad to stop when a solution is found. Laurence From - Wed Jan 19 09:49:58 2005 Return-Path: Received: from mailrelay01.solcon.nl (maillb.solcon.nl [212.45.32.200]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0J8fQ0o039499 for ; Wed, 19 Jan 2005 09:41:26 +0100 (CET) Received: from server-1.pragma-net.nl (dsl-212-84-128-085.solcon.nl [212.84.128.85]) by mailrelay01.solcon.nl (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id j0J8fO76006122; Wed, 19 Jan 2005 09:41:24 +0100 Received: by server-1.pragma-net.nl (Postfix, from userid 65534) id 8DEF61A0DB; Wed, 19 Jan 2005 09:35:11 +0100 (CET) Received: from [10.100.1.191] (unknown [10.100.1.191]) by server-1.pragma-net.nl (Postfix) with ESMTP id F36A018255; Wed, 19 Jan 2005 08:35:09 +0000 (UTC) Message-ID: <41EE1D33.5090409@wxs.nl> Date: Wed, 19 Jan 2005 09:41:23 +0100 From: Hans Hagen User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christophe Grandsire Cc: Liste Metafont , metapost@tug.org Subject: Re: [metafont] Re: [metapost] References: <200501190442.j0J4gQf199844@coxeter.math.toronto.edu> <41EE0E2B.9060703@free.fr> In-Reply-To: <41EE0E2B.9060703@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-6.7 required=7.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Virus-Scanned: ClamAV 0.80/540/Tue Oct 19 14:59:23 2004 clamav-milter version 0.80j on mailrelay01 X-Virus-Status: Clean X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 19 Jan 2005 09:41:26 +0100 (CET) Christophe Grandsire wrote: > En réponse à Larry Siebenmann : > >> Hans wrote (Tue Jan 18 05:56:10 2005): >> >> > imo, in a sense mf is kind of 'dead', i.e. replaced by metapost > >> and/or font editing programs and.or a combination of those >> The opposite seems just as plausible. Metapost and metafont will >> either prosper together or perish together. A parting of these >> siamese twins could be fatal to both. >> > > Exactly! Not only that, but there are some people out there trying to > keep METAFONT very much alive ;) (I don't usually name people but I can > point, at myself in this case ;) ). Check at > http://metafont.tutorial.free.fr (/ shameless plug ;) ), which is far > from finished, but has already brought people who knew nothing about > METAFONT to take an interest in it :) . get me right, i have no problem with metafont, but let's look at its possible usage: - font design: too complex for most font designers, also, bitmaps and not outlines - general symbolic graphic design: bitmaps and therefore not that handy but luckily, metapost offers: - at least a way to create outlines (using jacko's toolkit) - some very basic extension mechanisms so that we can do more advanced graphic tricks The syntax/features of both metavariants are more or less the same (it would be nice of mp has something simular to this picture addition stuff) If I look at our applications / users, i cannot find reasons for them to use metafont over metapost. Of course there are things missing in metapost (and those things are then also missing in metafont), but there are some efforts to extend metapost, so in the end mp may be a richer system than mf in terms of functionality; so, mp is kicking and alive -) >> As for the idea that both will perish, let us recall that, already in >> the early 90's, the demise of TeX was predicted not just by >> commercials, but by certain directors of the AMS (bb excluded!). >> Instead, the plush GUI environments competing with TeX have withered >> with the OSs and interfaces for which they were built, like autumn >> leaves before the winter winds. sure, but it's not per definition all good what tex does; ok, 95% of the docs produced by tex is simple in terms of layout, design (if any), and demands, but the remaining 5% can give one a pretty hard headache (esp when one has to compete with professional dtp) i think that for quite some time tex will stick around, if only because the problems related to typesetting will not change and if better solutions were known, they would already have been implemented 15 years ago; > Hear hear! In 99 when I worked for Philips (yes, Philips! not even a > university) it was unthinkable to write your reports in anything else > but LaTeX (which is how I got in contact with the wonderful world of > TeX/LaTeX :) ). So much for a dead program ;) . And as long as TeX is > alive, METAFONT will live. The only thing it needs is a bit of > recognition ;) . eh ... i never said that tex was dead, actually, i spent most of my time dealign with tex [and mp]; >> I hope metafont is just as welcome on the metapost list as metapost >> has been on the metafont list. Simply a *meta* list would be another >> solution. >> i think that simply the 'font' part in a name will make users thing that it has to do with fonts, so better not mention that one -) Hans a big fan of metapost -) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl ----------------------------------------------------------------- From - Wed Jan 19 10:00:32 2005 Return-Path: Received: from mailrelay02.solcon.nl (maillb.solcon.nl [212.45.32.200]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0J90S9E054889 for ; Wed, 19 Jan 2005 10:00:28 +0100 (CET) Received: from server-1.pragma-net.nl (dsl-212-84-128-085.solcon.nl [212.84.128.85]) by mailrelay02.solcon.nl (8.12.11/SQL-8.12.11-5/8.12.11) with ESMTP id j0J90ReI002423; Wed, 19 Jan 2005 10:00:27 +0100 Received: by server-1.pragma-net.nl (Postfix, from userid 65534) id E3B9B18255; Wed, 19 Jan 2005 09:54:13 +0100 (CET) Received: from [10.100.1.191] (unknown [10.100.1.191]) by server-1.pragma-net.nl (Postfix) with ESMTP id 4D83F1817B; Wed, 19 Jan 2005 08:54:12 +0000 (UTC) Message-ID: <41EE21A9.6030002@wxs.nl> Date: Wed, 19 Jan 2005 10:00:25 +0100 From: Hans Hagen User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Laurence Finston Cc: Christophe Grandsire , Liste Metafont , metapost@tug.org Subject: Re: [metafont] Re: [metapost] References: <200501190442.j0J4gQf199844@coxeter.math.toronto.edu> <41EE0E2B.9060703@free.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-6.7 required=7.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Virus-Scanned: ClamAV 0.80/540/Tue Oct 19 14:59:23 2004 clamav-milter version 0.80j on mailrelay02 X-Virus-Status: Clean X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 19 Jan 2005 10:00:29 +0100 (CET) Laurence Finston wrote: > On Wed, 19 Jan 2005, Christophe Grandsire wrote: > > >>En r�ponse � Larry Siebenmann : >> >>>Hans wrote (Tue Jan 18 05:56:10 2005): >>> >>> > imo, in a sense mf is kind of 'dead', i.e. replaced by metapost >>> > and/or font editing programs and.or a combination of those >>> > > > I think it's nice that it's possible to use MP for making fonts, but if I > specifically want a font, i.e., run-length encoded bit-maps, I think this i'd say: "i.e. a proper outline" > would be a rather roundabout way of doing it. I also believe that the > digitization routines of MF are interesting in their own right. sure > In my field, linguistics, people often talk about "dead" languages, > often implying a value judgement, as though "survival of the > fittest" applied to languages. It's not so. Languages can't die, > because they were never alive. i know, but i'm talking from the perspective of a user community: in order to keep tex and friends around we need a substantial number users (most users are not aware of the enourmous efforts that take place to keep tex and friends running on all platforms, keep the textrees and archives up to date); so, if there are say 100 metapost users fo reach metafont users, then there is a push to keep metapost in the distros, and since metafont is related (but no longer developed) it can piggy back. It's the same with some fonts/tools that are seldom/never used but take not much additional effort to be kept on board. so, replace 'die' by 'loose interest' and 'live' by 'gain interest' > My work with fonts involved making a font that imitates as closely as > possible the writing used in a particular medieval manuscript. I also > made a couple of fonts with modified characters from the cm and ec fonts > to represent characters from that manuscript. Since the first font > will probably only be used in a single work, it doesn't really matter > to me how many other people are using MF. I suppose it would be > possible to use PostScript to write the palaeographic font. I don't > know PostScript, but from what I've seen of it, it doesn't look like it > would be as much fun to program in as MF. That, for me, is really the > main point. At the time I started learning MF, I was using Autocad (and > Autolisp) a lot. LISP is one of my favorite languages, but it was still > much more fun to write MF than Autolisp. That's why I chose to use the MF > language as the basis of the GNU 3DLDF language. the font part of metafont consiste of the ability to make tfm files (which mp can also do) and for the rest it's macros (most of which can be used in mp as well) just like tex is a basic typesetting engine, mf/mp are basic graphic production engines, and for all of them it's the macros that do the magic; my remarks about mf being dead do not concern the language; it's always tricky to talk about languages here: tex as system and language, mf/mp as system and as language. The meta-language is ok, the meta-compiler/interpreters can evolve and be replaced. > There are people interested in MF, so I think it's worthwhile to maintain > the list. I think a single list would be a good idea, too, but it > shouldn't be called `metapost@tug.org'. metafont@....... -> font development in metafont metapost@tug.org -> usage of metapost for whatever application Being involved in user group activities, i also tend to think of marketing: if you visit user group meetings you will notice that metapost is kicking and alive and used for all kind of things; the occasional talk about metafont is (indeed) about fonts, and that's a different topic. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl ----------------------------------------------------------------- From - Wed Jan 19 10:05:29 2005 Return-Path: Received: from avs3.arnes.si (avs3.arnes.si [193.2.1.68]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0J95NFC058727 for ; Wed, 19 Jan 2005 10:05:23 +0100 (CET) Received: from localhost (avs3.arnes.si [193.2.1.68]) by avs3.arnes.si (Postfix) with ESMTP id EFFDD1D7A51; Wed, 19 Jan 2005 10:05:22 +0100 (CET) Received: from avs3.arnes.si ([193.2.1.68]) by localhost (avs3.arnes.si [193.2.1.68]) (amavisd-new, port 10024) with ESMTP id 93962-01; Wed, 19 Jan 2005 10:05:22 +0100 (CET) Received: from [141.84.28.136] (a136.lmu.vpn.lrz-muenchen.de [141.84.28.136]) by avs3.arnes.si (Postfix) with ESMTP id 58C861D7A34; Wed, 19 Jan 2005 10:05:16 +0100 (CET) Message-ID: <41EE22BF.4030309@email.si> Date: Wed, 19 Jan 2005 10:05:03 +0100 From: Mojca Miklavec Reply-To: mojca.miklavec@guest.arnes.si User-Agent: Mozilla/4.5-4.75 (Windows; U; Windows NT 5.1; sl-SI; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: sl, en, en-us, de MIME-Version: 1.0 To: metafont@ens.fr, metapost@tug.org Subject: Re: [metafont][metapost] References: <200501190442.j0J4gQf199844@coxeter.math.toronto.edu> In-Reply-To: <200501190442.j0J4gQf199844@coxeter.math.toronto.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at arnes.si X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 19 Jan 2005 10:05:23 +0100 (CET) Larry Siebenmann wrote: > I hope metafont is just as welcome on the metapost list as > metapost has been on the metafont list. Simply a *meta* list > would be another solution. Laurence Finston wrote: > There are people interested in MF, so I think it's worthwhile to > maintain the list. I think a single list would be a good idea, too, > but it shouldn't be called `metapost@tug.org'. I don't think metafont is dead, it's just the fact that almost everyone needs some images every now and then and there are extremely rare people who really *need to* and *know how* to design nice-looking or any other exotic fonts. (Comparing the number of (La)TeX/ConTeXt -> metapost users -> metafont users is just like comparing the number of Office users -> Photoshop/CorelDraw users -> TrueType font designers ) But I agree that there were a couple of years between when I started to use LaTeX and when I first heard about meta[whatever]. There were mostly ConTeXt manuals that gave me a hint about that. People to which I show the manuals are mostly impressed (plenty of LaTeX enthusiasts who never have heard about Meta, but gave up using \begin{picture} ... \end{picture}, thinking that pictures in LaTeX are something to be afraid of ... just as I did at the very beginning). Metafont is not dead, but its mailing list seems to be. So I still don't see any reason for not making a meta@tug.org mailing list and simply transferring the users from both lists there (metafonters won't complain about the name, metaposters won't become afraid and even metafunners will find some place here -). It will lead to some confusion at the beginning, but if that can satisfy the majority of users it's maybe worth it. Mojca From - Wed Jan 19 11:39:41 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0JAdax5020738 for ; Wed, 19 Jan 2005 11:39:36 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CrDFN-0002WJ-3s; Wed, 19 Jan 2005 11:39:33 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0JAdW10000098462; Wed, 19 Jan 2005 11:39:32 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Wed, 19 Jan 2005 11:39:32 +0100 (MET) From: Laurence Finston To: MASCHLER@vms.HUJI.AC.IL cc: liste metafont , metapost@tug.org Subject: Re: [metafont] Re: [metapost] recursion in MP/ MF [was: all intersections betwee In-Reply-To: <19012005114540@HUJIVMS> Message-ID: References: <19012005114540@HUJIVMS> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: ++++ X-Spam-Report: Content analysis: 4.1 points, 6.0 required 4.1 SUBJ_HAS_SPACES Subject contains lots of white space X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 19 Jan 2005 11:39:36 +0100 (CET) I'm taking the liberty of posting this to the mailing lists (might as well use them while they're still around), because you're probably not the only person who doesn't know this. I'm also not the person on this list who knows the most about this subject, so corrections are welcome. On Wed, 19 Jan 2005 MASCHLER@vms.HUJI.AC.IL wrote: > Sorry for this naive question. I don't think that's something anyone has to apologize for. > > Can you explain to me in plain language what is the difference between > recursion and tail-recursion? This example uses C, but I believe the situation is identical with other compiled languages, such as Fortran and Pascal. When a function invokes itself, that's called recursion. For example, int a(int b) { if (b > 0) return a(b - 1); else return -1; } The call `a(b- 1)' is a recursive call to `a()'. A popular example for teaching recursion in textbooks is the factorial function. When a function is called, the run-time system creates something called a "stack frame" which includes the arguments passed to the function and information such as the address where execution should resume after the function returns. A stack frame is really just data that's pushed onto the stack of the process or the thread. One can examine these stack frames by using a debugger, such as GDB. If you call a function recursively, it creates a new stack frame, so if a function recurses a lot, this can cause many stack frames to be created. For example, calling this version of `a()' will eventually cause your process to run out of space on the stack: void a(int b) { a(b); } If a function doesn't "do anything" after the call to itself, it is possible for the compiler (and/or run-time system?) to remove the stack frame representing that call, so that the stack frames don't pile up. This is called "tail recursion". Knuth mentions this somewhere in the _TeXbook_. That's how I found out about it. Laurence From - Wed Jan 19 12:17:39 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0JBHYMP042716 for ; Wed, 19 Jan 2005 12:17:34 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CrDq6-00010p-IJ; Wed, 19 Jan 2005 12:17:31 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0JBHPG0000099524; Wed, 19 Jan 2005 12:17:30 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Wed, 19 Jan 2005 12:17:24 +0100 (MET) From: Laurence Finston To: Hans Hagen cc: Christophe Grandsire , Liste Metafont , metapost@tug.org Subject: Re: [metafont] Re: [metapost] In-Reply-To: <41EE21A9.6030002@wxs.nl> Message-ID: References: <200501190442.j0J4gQf199844@coxeter.math.toronto.edu> <41EE0E2B.9060703@free.fr> <41EE21A9.6030002@wxs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 19 Jan 2005 12:17:34 +0100 (CET) On Wed, 19 Jan 2005, Hans Hagen wrote: > i know, but i'm talking from the perspective of a user community: in order to > keep tex and friends around we need a substantial number users (most users are > not aware of the enourmous efforts that take place to keep tex and friends > running on all platforms, keep the textrees and archives up to date); There is a range of views on this topic. Some people are satisfied with fewer packages, GUIs, IDEs, etc. Making anything run on "all platforms" is a programmer's nightmare. > > the font part of metafont consiste of the ability to make tfm files (which mp > can also do) and for the rest it's macros (most of which can be used in mp as well) > Macros don't have quite the same importance in MF as in TeX. > just like tex is a basic typesetting engine, mf/mp are basic graphic production > engines, and for all of them it's the macros that do the magic; Sorry, I must disagree with you here: It's the primitives that do the magic. However, you may define "magic" differently from me. > > my remarks about mf being dead do not concern the language; it's always tricky > to talk about languages here: tex as system and language, mf/mp as system and as > language. The meta-language is ok, the meta-compiler/interpreters can evolve and > be replaced. I just used natural languages as an example. Personally, I wouldn't be so quick to discard the compilers. I haven't used any code from MF or MP, but that's not because I'm a better programmer than Knuth. In fact, I'm no match for him and I know it. > > metafont@....... -> font development in metafont > metapost@tug.org -> usage of metapost for whatever application > I think a lot of discussion involves language features common to MF and MP. That's why I cross post. > Being involved in user group activities, i also tend to think of marketing: I respect your point of view, but mine is quite different. What I'm thinking about is Free Software and the Art of Computer Programming (the idea, not the books). I'd like to think that these points of view (and others) can coexist. Laurence From - Wed Jan 19 19:56:18 2005 Return-Path: Received: from coxeter.math.toronto.edu (coxeter.math.toronto.edu [128.100.68.3]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0JIuFpR048650 for ; Wed, 19 Jan 2005 19:56:15 +0100 (CET) Received: (from laurent@localhost) by coxeter.math.toronto.edu (AIX5.2/8.11.6p2/8.11.0/UTMath 1.0) id j0JIuFj305678; Wed, 19 Jan 2005 13:56:15 -0500 Date: Wed, 19 Jan 2005 13:56:15 -0500 From: Larry Siebenmann Message-Id: <200501191856.j0JIuFj305678@coxeter.math.toronto.edu> To: laurent@math.toronto.edu, metafont@ens.fr, metapost@tug.org Subject: Re: recursion in MP/MF X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 19 Jan 2005 19:56:16 +0100 (CET) Hi all, Laurence Finston formulated the following caveat in reaction to my program "Hit.mp" at http://topo.math.u-psud.fr/~lcs/graphics/ "Hit.mp" was designed to find all intersection points of (almost) arbitrary composite bezier paths -- without the preprocessing that B. Jackowski's program still required. > However, I think it would be worthwhile to consider whether you > couldn't just put the subpaths onto an array and loop > over the array until some condition is met. Excellent suggestion; I am still mulling it over. The ensuing discussion of "fullfledged recursion", versus "tail recursion" (as in loops) --- by Laurence Finston Lars Engebretsen, Taco Hoekwater, Hans Hagen, B_Jackowski, and others was particularly helpful to me. I loath having to use syntax without its elucidation in terms of physical or at least virtual machines. Initially, I did not make any attempt to use 'tail recursion' because that sort of code is considerably harder for ME to write AND for YOU to understand. If full fledged recursive reasoning were purged from geometry and combinatorics, only charred treestumps would remain! But yes, given that MF/MP arrays are dynamic, 'tail recursion' seems a workable engineering solution to what B.Jackowski considers to be a nasty bind in MP/MF: > The ``true'' recursion, however, is still > discriminated in MP/MF -- the parameter stack is too > small to use recursive techniques in practice. In > 1994, during the (mentioned in one of my previous > letters) conference in Sobieszewo, Poland, Marek > Ry\'cko and I complained about it; then, a few years > later, I resumed the problem on the > list, giving the following example: [...] Now is much > better: the program breaks for much larger n, i.e., > n=31 [rather than n=29] ... Taco, commented: > I also like recursion. It is unfortunate that precisely > this part of MP/MF cannot easily be changed. Knuth uses > the (compile-time) size of the param stack to > differentiate between the three parameter types, making > it hard to manage the stack dynamically. This suggests two questions: (1) Could one not use just the insignificant byte of the param stack sizes to differentiate between the three parameter types and thus make dynamic stack admin possible? Failing that I ask (2) Why have precompiled stack sizes not kept abreast of available RAM in newer computers? Taco> This is much more of a problem in MP than in TeX > because graphics often relate themselves well to > recursive algorithms. Indeed! How can one expect geometers to adopt MP, as an intimate professional tool if their favorite mode of reasoning is hobbled? Cheers Laurent S %%%%%%%%%%%%%%%%%%%%%% TEXHNICAL PS. While it is hazardous to predict a tail recursion solution before it is posted, I point out that the quantity of extra 'array' data necessary seems acceptable:- If we have to find 100 intersection points, then the parameter interval of the first path pp is going to be broken into about 100 time intervals. Think of these as leaves on a binary tree. Unfortunately, we perhaps also want/need to store the interior nodes. But we can naturally associate to each intersection point the interior node that is the interval in which it is first discovered, and this counts all interior nodes. Hence an array of about 200 time intervals is (more than?) adequate. At any rate, RAM storage for the 100 intersection points, their times on both curves and their correspondence will be of the same order of magnitude. Laurence Finston suggested use of an array. It seems to me that the use of a home-made stack (housed in an array for lack of alternatives?) might be a slightly better solution. Mostly on the hope that the program could remain 'almost' unchanged (unmutilated!?) -- each recursive intersection function call being replaced by a by a 'push' of a time interval onto the stack. The intersection function would 'pop' its time interval as it launches. Incidentally, in this scheme the maximum stack depth might be far less than 100. QUESTIONS. What is the RAM cost of an 'array' element of type pair? Is there some way of recycling useless array elements -- maybe similar to TeX's \let \macroxxx=\undefined? Is there a good example of the use of a stack in MF/MP programming. From - Wed Jan 19 23:00:04 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0JLxxg1053894 for ; Wed, 19 Jan 2005 22:59:59 +0100 (CET) Message-Id: <200501192159.j0JLxxg1053894@nef2.ens.fr> Received: from mailbox.gwdg.de ([134.76.10.21] helo=gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CrNrq-0002gr-8T; Wed, 19 Jan 2005 22:59:58 +0100 X-Originating-IP: lfinsto1[134.76.139.103] Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Jan 2005 22:59:57 +0100 Cc: metafont@ens.fr, metapost@tug.org, help-3dldf@gnu.org In-Reply-To: <200501191856.j0JIuFj305678@coxeter.math.toronto.edu> MIME-Version: 1.0 Subject: Re: [metafont] Re: recursion in MP/MF Content-Transfer-Encoding: 8bit User-Agent: IMHO/0.98.3+G (Webmail for Roxen) From: "Laurence Finston" To: Larry Siebenmann X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 19 Jan 2005 22:59:59 +0100 (CET) Larry Siebenmann wrote: > > > However, I think it would be worthwhile to consider whether you > > couldn't just put the subpaths onto an array and loop > > over the array until some condition is met. > > Excellent suggestion; I am still mulling it over. > Thanks. One does one's best. > > Indeed! How can one expect geometers to adopt MP, as an > intimate professional tool if their favorite mode of > reasoning is hobbled? > Do you think this is a reasonable expectation? I think TeX, MF, and MP perform a limited range of functions very well. I apply something I call "the three `\expandafters' rule": If anything needs more than three `\expandafters', I write a preprocessor instead. This is a bit of an exaggeration, especially since TeX is very interesting viewed simply as a macro processor, apart from its typesetting functionality, but you get the idea. I've found that it works very well to write programs that write TeX code, TeX macros that write LISP code, C programs that preprocess TeX code, etc. Put in a somewhat oversimplified way, I think MF was designed to draw curves and it does that very well. I wish the curves it drew were projectively invariant, but Knuth was apparently not thinking about the third dimension. So it gives me something to do. MF wasn't designed to express recurrence relations, if that's what you mean (and the correct term). I think it could be a powerful tool for a geometer, but one would have to learn what it does well and what it doesn't. > > It seems to > me that the use of a home-made stack (housed in an array > for lack of alternatives?) might be a slightly better > solution. > > QUESTIONS. What is the RAM cost of an 'array' element of > type pair? Is there some way of recycling useless > array elements -- maybe similar to TeX's \let > \macroxxx=\undefined? Is there a good example of > the use of a stack in MF/MP programming. This is just my opinion, but if you're thinking this way, I'm not sure working within MP is the best way to go about solving the problem. Instead, you could write a program to do the calculations and have it write MP code as its output. Then you wouldn't be so restricted by MP's limitations. You could implement tail recursion, implement high-precision arithmetic, do garbage collection, and whatever else you want. Laurence From - Wed Jan 19 23:28:59 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0JMSsg3067975 for ; Wed, 19 Jan 2005 23:28:54 +0100 (CET) Message-Id: <200501192228.j0JMSsg3067975@nef2.ens.fr> Received: from mailbox.gwdg.de ([134.76.10.21] helo=gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CrOJp-0002bG-7d; Wed, 19 Jan 2005 23:28:53 +0100 X-Originating-IP: lfinsto1[134.76.139.103] Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Jan 2005 23:28:53 +0100 Cc: metafont@ens.fr, metapost@tug.org In-Reply-To: <200501191856.j0JIuFj305678@coxeter.math.toronto.edu> MIME-Version: 1.0 Subject: Re: [metafont] Re: recursion in MP/MF Content-Transfer-Encoding: 8bit User-Agent: IMHO/0.98.3+G (Webmail for Roxen) From: "Laurence Finston" To: Larry Siebenmann X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Wed, 19 Jan 2005 23:28:54 +0100 (CET) > > However, I think it would be worthwhile to consider whether you > > couldn't just put the subpaths onto an array and loop > > over the array until some condition is met. > I looked up "tail recursion" in the indices of several of my computer books. It only occurs once in the _TeXbook_ and not at all in the _MFbook_. It does not occur in the index to any of the volumes of Knuth's _The Art of Computer Programming_ although it might be mentioned in one of the many places where "recursion" is discussed. Nor is it mentioned in _Concrete Mathematics_ (Graham, Knuth, and Patashnik). I'm pretty sure it's not mentioned in my other books. The impression I get is that "the compiler is supposed to take care of it". Uwe Schoening, in his book _Algorithmik_, says that recursion can always be replaced by a WHILE loop and a stack. I wrote down the reference, but forgot to take it with me. I believe it is p. 19 and the date of publication was 2001. The publisher is Spektrum Akademischer Verlag. He likes recursion, too, though, for much the same reasons advanced by Taco and Jacko. He points out that accessing the function arguments after the recursive call would make tail recursion impossible, but doesn't say anything about static variables. Laurence From - Fri Jan 28 12:49:27 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0SBnLcH076096 for ; Fri, 28 Jan 2005 12:49:24 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CuUci-00021e-Gy; Fri, 28 Jan 2005 12:49:13 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0SBnB20000366388; Fri, 28 Jan 2005 12:49:11 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Fri, 28 Jan 2005 12:49:11 +0100 (MET) From: Laurence Finston To: liste metafont cc: metapost@tug.org, help-3dldf Subject: Intersections of NURBs In-Reply-To: Message-ID: References: <200501230242.j0N2gk7288726@coxeter.math.toronto.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Fri, 28 Jan 2005 12:49:24 +0100 (CET) Hello, I hope nobody considers this question off-topic on the MF and MP lists. I'm trying to implement surface hiding in GNU 3DLDF in such a way that it will work when using MetaPost output (currently the only form). All of the forms of surface hiding I'm familiar with use raster data, which won't work in this case. Therefore, I've decided to try to do it by "decomposing" objects until (ideally) none intersect, and none of their projections intersect. For non-arbitrary objects, such as circles, ellipses, cuboids, etc., the problem is straightforward, albeit non-trivial. Shapes defined by arbitrary curves are a bigger problem. I've decided to use NURBs (non-uniform rational B-splines) instead of the B{\'e}zier curves used in MF/MP because the former are projectively invariant, i.e., the results of 1) projecting all of the points on the curve and 2) projecting the control points and generating a curve from the projections, are equivalent. B{\'e}zier curves only have the property of affine invariance, i.e., they are only invariant under affine transformations such as rotation, scaling, shifting, and shearing, but not under the perspective transformation. NURBs are similar to B{\'e}zier curves but more complicated. In addition to control points, they use two sequences of real values: "knots" and "weights". "Decomposing" requires finding the intersections of a given pair of objects. None of the texts on NURBs I own or have referred to goes into this topic. In fact, in my experience, computer graphics books tend to ignore the important and fascinating topic of intersections. With respect to a similar, and possibly related problem, Piegl and Tiller, in _The NURBs Book_, mention that determining whether a point lies on a curve is difficult when using a parametric representation (as one does with B{\'e}zier curves and NURBs), but do not elaborate. I've taken a look at Knuth's method of finding intersections, but it appears to depend on the limited precision whole-number arithmetic he uses, and is thus not applicable to my more conventional approach using `floats' or `doubles'. I'm not expecting this to be easy, but any hints would be much appreciated. Laurence Finston From - Fri Jan 28 21:01:27 2005 Return-Path: Received: from coxeter.math.toronto.edu (coxeter.math.toronto.edu [128.100.68.3]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0SK1NX2074767 for ; Fri, 28 Jan 2005 21:01:25 +0100 (CET) Received: (from laurent@localhost) by coxeter.math.toronto.edu (AIX5.2/8.11.6p2/8.11.0/UTMath 1.0) id j0SK1Nn232828; Fri, 28 Jan 2005 15:01:23 -0500 Date: Fri, 28 Jan 2005 15:01:23 -0500 From: Larry Siebenmann Message-Id: <200501282001.j0SK1Nn232828@coxeter.math.toronto.edu> To: metafont@ens.fr, metapost@tug.org Subject: Intersections of NURBs X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Fri, 28 Jan 2005 21:01:25 +0100 (CET) > I'm trying to implement surface hiding in GNU 3DLDF > ... > Therefore, I've decided to try to do it by "decomposing" > objects until (ideally) none intersect, and none of their > projections intersect. Nonintersection is what Knuth-Hobby intersection algorithm is about. It *rigorously* establishes non intersection. > Shapes defined by arbitrary curves are > a bigger problem. Are you defining surfaces in terms of nets of curves? > With respect to a similar, and possibly related problem, > Piegl and Tiller, in _The NURBs Book_, mention that > determining whether a point lies on a curve is difficult > when using a parametric representation (as one does with > B{\'e}zier curves and NURBs), but do not elaborate. Not if you use Knuth-Hobby binary search approach and b'eziers (of any degree). That could make preferring NURBs to bezier an expensive luxury if replacements for the de Castaljau convex hull property are still lacking in the NURBs world. More reasonable might be to use only bezier objects in 3D and project to 2D for display. Why would that be insufficient for 3DLDF? Incidentally how does/will 3DLDF get PS output? > I've taken a look at Knuth's method of finding > intersections, but it appears to depend on the limited > precision whole-number arithmetic he uses, and is thus not > applicable to my more conventional approach using `floats' > or `doubles'. That may make Knuth's code useless. But the concepts work in floating point too. Laurent S. From - Sat Jan 29 11:01:39 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0TA1XPK095682 for ; Sat, 29 Jan 2005 11:01:33 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CupQ2-0005Q4-Er; Sat, 29 Jan 2005 11:01:31 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0TA1Q90000386589; Sat, 29 Jan 2005 11:01:26 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Sat, 29 Jan 2005 11:01:25 +0100 (MET) From: Laurence Finston To: "L. Nobre G." cc: metapost@tug.org, liste metafont , help-3dldf Subject: Re: [help-3dldf] Intersections of NURBs In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Sat, 29 Jan 2005 11:01:34 +0100 (CET) On Fri, 28 Jan 2005, L. Nobre G. wrote: > On Fri, 28 Jan 2005, Laurence Finston wrote: > > > I hope nobody considers this question off-topic on the MF > > and MP lists. > > I don't but I leave to you the posting of this reply on the MF and MP > lists. I'll risk it. If the consensus is that it doesn't belong, I'll stop posting to them. > > > Shapes defined by arbitrary curves are > > a bigger problem. > > Do you mean "arbitrary surfaces"? > If the awswer is "no", stop reading. Yes, surfaces and solids, too. However, I will also allow objects such as curves and polylines. I haven't decided yet how to handle `pens', i.e., whether the dimensions of the `pen' are added to those of the objects. Currently, `pens' can be transformed in three dimensions, but the transformations are converted to two-dimensional ones upon output. `pens' thus only "exist" in the x-y plane of projection. I would like to implement 3D pens, i.e., `pen_sphere' and `pen_cuboid' (which will be transformable), but it will be awhile before I'm able to work on this. > > > "Decomposing" requires finding the intersections of > > a given pair of objects. > > Supposing one has found one point where two arbitrary parametric surfaces > of degree greater then 2 intersect I'd go for a "continuation method" to > run over the intersection curve. It is somewhat similar to > numerically solving a differential equation (or finding a contour line). Thanks for the hint. > > > I've taken a look at Knuth's method of finding > > intersections, but it appears to depend on the limited > > precision whole-number arithmetic he uses, and is thus not > > applicable to my more conventional approach using `floats' > > or `doubles'. > > One can cast floats and doubles into limited precision... They already are. It's the whole number part that makes it difficult to adapt Knuth's algorithms. At a later date, I'd like to use a library for higher-precision arithmetic, as Nelson Beebe suggested. I've also been considering using the GNU Scientific Library, but I haven't had a chance to work on this yet. > > > I'm not expecting this to be easy, but any hints would be > > much appreciated. > > I don't know NURBS but, maybe, there is a standard way to > calculate the polyhedric control surface of surface-NURBS. > If this polyhedric control surface exists, calculating the intersection of > two arbitrary surfaces reduces to finding the piece-wise linear > intersection of two polyhedric surfaces and then `converting' this > polyline to a line-NURBS. Maybe, this convertion is possible and maybe, it > produces the correct intersection. Well, maybe, maybe... > Thanks again. I'm currently reading up on NURBs curves. I've read a little bit about surfaces, but I'm taking it one step at a time. I think a reasonable first step would be to find the intersection of two NURBs of power 3 with four control points and that have a single intersection. Laurence From - Sat Jan 29 11:20:09 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0TAK5Fp004358 for ; Sat, 29 Jan 2005 11:20:05 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1Cuphw-0000LU-R9; Sat, 29 Jan 2005 11:20:01 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0TAK000000386806; Sat, 29 Jan 2005 11:20:00 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Sat, 29 Jan 2005 11:20:00 +0100 (MET) From: Laurence Finston To: Larry Siebenmann cc: metafont@ens.fr, metapost@tug.org, help-3dldf Subject: Re: [metapost] Intersections of NURBs In-Reply-To: <200501282001.j0SK1Nn232828@coxeter.math.toronto.edu> Message-ID: References: <200501282001.j0SK1Nn232828@coxeter.math.toronto.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Sat, 29 Jan 2005 11:20:05 +0100 (CET) On Fri, 28 Jan 2005, Larry Siebenmann wrote: > > Nonintersection is what Knuth-Hobby intersection algorithm > is about. It *rigorously* establishes non intersection. > I'll have to look at it more carefully. It's always a bit difficult trying to understand Knuth's code out of context, and I've never found the time to read _METAFONT: The Program_ cover-to-cover. > > Shapes defined by arbitrary curves are > > a bigger problem. > > Are you defining surfaces in terms of nets of curves? > Not yet. Currently, all of the internal data types (C++ classes) that correspond to data types defined in the 3DLDF language that could be said to be surfaces, i.e., `Rectangle', `Reg_Polygon', `Ellipse', and `Circle', are derived from `Path', with extra data members where appropriate, e.g., `Points' for the center and the foci. > > With respect to a similar, and possibly related problem, > > Piegl and Tiller, in _The NURBs Book_, mention that > > determining whether a point lies on a curve is difficult > > when using a parametric representation (as one does with > > B{\'e}zier curves and NURBs), but do not elaborate. > > Not if you use Knuth-Hobby binary search approach and > b'eziers (of any degree). That could make preferring NURBs to > bezier an expensive luxury if replacements for the de > Castaljau convex hull property are still lacking in the NURBs > world. Please correct me if I'm wrong, but I think NURBs have the convex hull property. I believe that a NURB with all weights equal to 1 and the knot sequence chosen appropriately is equivalent to the B{\'e}zier curve with the same control points. > > More reasonable might be to use only bezier objects in 3D > and project to 2D for display. Why would that be > insufficient for 3DLDF? > Because in that case I'd have to project "all" the points on the curve instead of just the control points. This is, in effect, how 3DLDF works now. > Incidentally how does/will 3DLDF get PS output? 3DLDF writes moderately low-level MP code. I say "moderately", because it writes `draw', `fill', etc., rather than `addto ... also'. Currently, I don't see any reason to write PS code directly. I've never learned PostScript, although I'm sure it would be useful to know it. For the kinds of things I can't do with MP, such as raster-based processing, I plan to have 3DLDF write PNG (Portable Network Graphics), either directly, or by using the GNU Plotutils. > > > I've taken a look at Knuth's method of finding > > intersections, but it appears to depend on the limited > > precision whole-number arithmetic he uses, and is thus not > > applicable to my more conventional approach using `floats' > > or `doubles'. > > That may make Knuth's code useless. But the concepts work in > floating point too. > I'll have to gird my loins and read through it. I got the impression that upon each iteration, an additional bit is set in a segment of memory, interpreted as a whole number value. But perhaps I just didn't understand what he meant. Thank you for your help. Laurence From - Sun Jan 30 03:26:12 2005 Return-Path: Received: from coxeter.math.toronto.edu (coxeter.math.toronto.edu [128.100.68.3]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0U2Q8cY020863 for ; Sun, 30 Jan 2005 03:26:08 +0100 (CET) Received: (from laurent@localhost) by coxeter.math.toronto.edu (AIX5.2/8.11.6p2/8.11.0/UTMath 1.0) id j0U2Q7F236858; Sat, 29 Jan 2005 21:26:07 -0500 Date: Sat, 29 Jan 2005 21:26:07 -0500 From: Larry Siebenmann Message-Id: <200501300226.j0U2Q7F236858@coxeter.math.toronto.edu> To: laurent@math.toronto.edu, metafont@ens.fr, metapost@tug.org Subject: Re: Intersections of NURBs X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Sun, 30 Jan 2005 03:26:08 +0100 (CET) Hi Laurence F., > Currently, all of the internal data types (C++ classes) > that correspond to data types defined in the 3DLDF language > that could be said to be surfaces, i.e., `Rectangle', > `Reg_Polygon', `Ellipse', and `Circle', are derived from > `Path', with extra data members where appropriate, e.g., > `Points' for the center and the foci. If urged, I can agree to identify an ellipse with the planar Jordan region it bounds, thus viewing an ellipse as a planar surface. But I am still sorely confused. What about 2-dimensensional surfaces in R^3? -- Spheres in R^3 rather than circles; or ellipsoids in R^3 rather than ellipses; etc. ??? > Please correct me if I'm wrong, but I think NURBs have the > convex hull property. I believe that a NURB with all weights > equal to 1 and the knot sequence chosen appropriately is > equivalent to the B{\'e}zier curve with the same control > points. There are difficulties in general with extending the convex hull property to NURBS. Maybe they can be overcome. They arise roughly because a projective transformation T of "the plane" is not a well defined self-mapping if the plane but rather of the projectively extended plane RP^2 = R^2 \cup {projective line at infinity} Indeed T respects R^2 and the line at infinity presisely if T is affine! Here is a simplest example where a difficulty arises. I stand before an (infinite) blackboard and project bezier curves on the blackboard from my eye onto the (infinite) floor. Consider in particular the bezier cubic bb with its controll trilateral A--B--C--D on the blackboard thus: B o-------------o C / \ - - - -/ - - - - - -\ - - - H horizon of floor / x \ projected to blackboard / x x \ / \ / x x \ / \ (paper = blackboard) /x x\ / \ / \ A o o D Notice that here the bezier cubic curve does *not* protrude above the horizon H cut out on the blackboard by the horizontal plane through my eye, whereas the control polygon does so protrude. Now let me project from my eye onto the infinite floor both the bezier cubic and the the four control points. Note that the 2 control points B and C slightly above the horizon project to two points B' and C' on the floor that lie far behind my back. Thus the convex hull of A',B',C',D' does NOT contain the projection of the bezier curve. The two intersect just in the two points A' and D'. In other words, the de Casteljau convex hull property fails in general for projections as it is usually stated -- at least if any bezier is, as I seem to recall a special case of NURBS. It is true that something useful can be said. The projection of the *full* convex hull of Cvx(A,B,C,D) does clearly contain the projection of the bezier cubic bb. In the present example this tells us that bb lies in the projection of the filled quadrangle A, BB, CC, D where BB is the intersection of A--B with the horizon line H on the blackboard and CC is defined similarly. This is useful information. But there are several possible positions with respect to the horizon line H that have to to be considered to make this discussion usefully general -- positions with respect to H of the control points and of the bezier curve. Thus I have been making optimistic noises about making a single simple projection manageable for Knuth's non-intersection machinery. But there is worse news:- a general projective transformation is not an elementary eyeball projection as considered here, but rather a composition of several. If someone has seen a well-develloped system of estimates for NURBS suitable to replace the de Casteljau convex hull property, please speak up! >> More reasonable might be to use only bezier objects in 3D >> and project to 2D for display. Why would that be >> insufficient for 3DLDF? > > Because in that case I'd have to project "all" the points on > the curve instead of just the control points. This is, in > effect, how 3DLDF works now. I was implicitly suggesting that objects be left in some to-be-develloped affine 3DMP format and the 2D display tasks be farmed out to some cross-platform 3D==>2D display application with a role analogous to that of a DVI-viewer or of Distiller + Acrobat Reader. The viewer application would only have to deal with simple projections with center an eyeball in R^3. But it would indeed have have to deal with "surface hiding" and hence a modicum of intersection theory. 3 dimensional reality is more affine than projective; thus it is useful to study dimension 3 by affine (and even orthogonal) methods; that's the basic reason for my suggestion. Cheers Laurent S. From - Sun Jan 30 03:26:35 2005 Return-Path: Received: from coxeter.math.toronto.edu (coxeter.math.toronto.edu [128.100.68.3]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0U2QUMT021121 for ; Sun, 30 Jan 2005 03:26:30 +0100 (CET) Received: (from laurent@localhost) by coxeter.math.toronto.edu (AIX5.2/8.11.6p2/8.11.0/UTMath 1.0) id j0U2QUM236860; Sat, 29 Jan 2005 21:26:30 -0500 Date: Sat, 29 Jan 2005 21:26:30 -0500 From: Larry Siebenmann Message-Id: <200501300226.j0U2QUM236860@coxeter.math.toronto.edu> To: laurent@math.toronto.edu, metafont@ens.fr, metapost@tug.org, wl@gnu.org Subject: Re: workaround for turningnumber bug X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Sun, 30 Jan 2005 03:26:31 +0100 (CET) Taco writes: > It looks like the inaccuracies introduced by calculating > envelopes are the real culprits. That is to say: JDH hints > in his explanations that "turningnumber" is actaully using the > envelope routines instead of the path itself. Mysterious. The winding number of the envellope of a penstroke along a cycle may in general differ from the winding number of the cycle, and may depend on pencircle diameter. Maybe for finite but small diameter a useful winding number results??? L. Nobre writes: > Is that the reason for having a strange result from the > buildcycle macro in the program below? Chaining together pieces of curves that do not abut precisely makes winding number of the built cycle undefined without some hidden conventions. Several possible conventions: -- force the components of the built cycle to abut exactly --- see B.Jackowsky's && operation in his recent posting. -- ignore subpaths of short length in a bootstrappong turning number calculation say as suggested by Werner LEMBERG. (Incidentally his program aught to first break up paths that turn >= 180 degrees). -- do with more care something JDH already does??? I have always felt that MF/MP should never have used or even mentioned turning number. Winding numbers (used in PS) are more reliable. Cheers Laurent S. From - Sun Jan 30 14:56:45 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0UDufLw091853 for ; Sun, 30 Jan 2005 14:56:41 +0100 (CET) Message-Id: <200501301356.j0UDufLw091853@nef2.ens.fr> Received: from mailbox.gwdg.de ([134.76.10.21] helo=gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CvFZ9-0008NB-L8; Sun, 30 Jan 2005 14:56:39 +0100 Content-Type: text/plain; charset=us-ascii Date: Sun, 30 Jan 2005 14:56:29 +0100 MIME-Version: 1.0 Subject: Re: [metafont] Re: Intersections of NURBs Content-Transfer-Encoding: 8bit X-Originating-IP: lfinsto1[134.76.139.103] User-Agent: IMHO/0.98.3+G (Webmail for Roxen) From: "Laurence Finston" To: Larry Siebenmann In-Reply-To: <200501300226.j0U2Q7F236858@coxeter.math.toronto.edu> Cc: metafont@ens.fr, metapost@tug.org, help-3dldf@gnu.org X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Sun, 30 Jan 2005 14:56:42 +0100 (CET) Larry Siebenmann wrote: > > If urged, I can agree to identify an ellipse with the planar > Jordan region it bounds, thus viewing an ellipse as a planar > surface. I see what you mean. Please pardon my imprecision. Clearly, an ellipse is a curve. For purposes of filling and surface hiding, I consider the planar region it encloses as part of the `ellipse' object, where `ellipse' is a data type defined in the GNU 3DLDF language which references an object of type `class Ellipse', which is defined internally in the C++ code that implements the 3DLDF interpreter. > But I am still sorely confused. What about > 2-dimensensional surfaces in R^3? -- Spheres in R^3 rather than > circles; or ellipsoids in R^3 rather than ellipses; etc. ??? I have defined two classes `Line' and `Plane' which are only used internally for vector operations. There are no corresponding data types `line' and `plane' defined in the 3DLDF language. A `Plane' comprises a `Point' that represents a point on the plane, a `Point' that represents a normal to the plane, and a `real' value that represents the distance of the plane from the origin. `real' is defined as a synonym either for `float' or `double' by means of a `typedef' declaration, depending on the value of a preprocessor macro. The value of the macro is meant to be set by an option to the `configure' script distributed with GNU 3DLDF, but I don't remember off-hand whether I've implemented this already or not. In my sources, `real' is a synonym for `double'. Points in 3DLDF are represented by objects of `class Point', and their coordinates are represented by a `valarray' of four `reals', i.e., I'm using homogeneous coordinates. Each `Point' also contains an object of type `class Transform', which contains a 4 X 4 matrix of `real' values. `Paths' contain a `vector'. The classes `Triangle' (which I forgot to mention in my last posting), `Reg_Polygon', `Rectangle', `Ellipse', and `Circle' are all derived from `Path'. The 3DLDF language defines a corresponding type for each of these classes, and `Transform' and `Point', i.e., `point', `transform', `path', `triangle', etc. `paths' and the types derived from it may be planar or not. If I declare a `circle' in 3DLDF code, and assign to it as follows: circle c; c := unit_circle; `c' will lie in the x-z plane. I don't know whether it's possible to make a `circle' non-planar by means of a transformation represented by a 4 x 4 matrix, but if it is, it's allowed in 3DLDF. In particular, since each `Point' has its own `Transform', it will be possible to apply different transformations to each one, although I have not yet implemented a means of doing this interactively. I currently define the following types of solid objects: `cuboid', `tetrahedron', `octahedron', `dodecahedron', `icosahedron', and `trunc_octahedron' ("trunc" stands for "truncated"). Each one is represented internally by a class, i.e., `Cuboid', `Tetrahedron', etc. There are other classes in the hierarchy that do not have corresponding types in the 3DLDF language, i.e., `Solid', `Solid_Faced', and `Polyhedron'. I have not yet implemented spheres or ellipsoids, and I plan to make big changes in the way solids are implemented. I'm particularly interested in polyhedra. > > There are difficulties in general with extending the convex hull > property to NURBS. Maybe they can be overcome. [...] Thank you very much for your explanations. I will need some time before I'm able to understand them. I'm currently working on learning linear algebra and analytic geometry, as well as reading Piegl and Tiller. Given the difficulties with NURBs, I may concentrate on the former for now. > > I was implicitly suggesting that objects be left in some > to-be-develloped affine 3DMP format and the 2D display tasks be > farmed out to some cross-platform 3D==>2D display application with a > role analogous to that of a DVI-viewer or of Distiller + Acrobat > Reader. The viewer application would only have to deal with simple > projections with center an eyeball in R^3. But it would indeed have > have to deal with "surface hiding" and hence a modicum of > intersection theory. 3 dimensional reality is more affine than > projective; thus it is useful to study dimension 3 by affine (and > even orthogonal) methods; that's the basic reason for my suggestion. > This is an interesting suggestion. It's quite different from what 3DLDF does now. It's very important to me that 3DLDF always be able to write MetaPost code, although I believe I will have to use PNG format for advanced rendering. Any software I use for displaying and/or preparing printable output will have to be Free Software, and preferably GNU packages. The GNU Plotutils and libpng look promising, but it's time-consuming learning other people's software, and they can't usually just be "plugged in". I also strongly prefer programming myself to reading other people's code. However, eventually, I'll have to "bite the bullet". As far as platforms are concerned, I am fortunate in that the GNU Coding Standards only require maintainers to ensure that their packages run on GNU systems, i.e., GNU/Linux and the Hurd. In practice, not many people have the Hurd yet, and I don't myself, unfortunately, so I'm just concerned with Linux. I would, of course, be very happy if anyone wanted to port 3DLDF to other systems, but I'm even happier that I don't have to do it myself. Thanks again. Laurence From - Sun Jan 30 16:51:07 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0UFp5pE053671 for ; Sun, 30 Jan 2005 16:51:05 +0100 (CET) Message-Id: <200501301551.j0UFp5pE053671@nef2.ens.fr> Received: from mailbox.gwdg.de ([134.76.10.21] helo=gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CvHLs-0003lw-8X; Sun, 30 Jan 2005 16:51:04 +0100 Content-Type: text/plain; charset=us-ascii Date: Sun, 30 Jan 2005 16:51:04 +0100 MIME-Version: 1.0 Subject: Re: [metafont] Re: Intersections of NURBs Content-Transfer-Encoding: 8bit X-Originating-IP: lfinsto1[134.76.139.103] User-Agent: IMHO/0.98.3+G (Webmail for Roxen) From: "Laurence Finston" To: Larry Siebenmann In-Reply-To: <200501300226.j0U2Q7F236858@coxeter.math.toronto.edu> Cc: metafont@ens.fr, metapost@tug.org, help-3dldf@gnu.org X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Sun, 30 Jan 2005 16:51:05 +0100 (CET) Larry Siebenmann wrote: > Here is a simplest example where a difficulty arises. I stand > before an (infinite) blackboard and project bezier curves on the > blackboard from my eye onto the (infinite) floor. Consider in > particular the bezier cubic bb with its controll trilateral > A--B--C--D on the blackboard thus: > > > B o-------------o C > / \ > - - - -/ - - - - - -\ - - - H horizon of floor > / x \ projected to blackboard > / x x \ > / \ > / x x \ > / \ (paper = blackboard) > /x x\ > / \ > / \ > A o o D > I've taken another look at this, and there are a couple of things I don't understand. When I perform the perspective transformation in 3DLDF, I have a `Focus' with `Points' representing the position and the direction of view, and a `real' value representing the distance of the position from the plane of projection. In order to simplify things, the `Focus' is transformed such that `position' and `position + direction' come to lie on the negative z-axis, (in a left-handed Cartesian coordinate system), and this transformation is applied to all of the objects on the `Picture' prior to applying the perspective transformation. Any objects whose z-coordinates are less than or equal to that of `Focus.position' are not projected. According to my understanding, there is no concept of a "horizon" when using this method. In your example, it's not clear to me how the points are projected onto the plane of the floor. If they are at focus level or above, a line through the focus and a given point will not intersect the floor. Nor does this method of projection correspond to traditional linear perspective, in which the direction of view is constant. In traditional linear perspective, when the direction of view is parallel to the ground plane, the horizon is always at the height of the focus---a fact one can easily confirm by looking out at a large body of water from ground level and then from the top of a tall building (I did this with Lake Michigan). If the direction of view is not parallel to the ground plane, then the floor is no longer the ground plane of the perspective construction, i.e., if the direction of view is inclined upward, the floor seems to tilt downward, slanting away from the focus, and vice versa. I believe a ground plane is not a necessary condition for a perspective construction. If my understanding is at fault, please correct me. I'm sorry if my objections are naive---my interest in math has developed rather late. Thanks, Laurence From - Mon Jan 31 04:02:37 2005 Return-Path: Received: from coxeter.math.toronto.edu (coxeter.math.toronto.edu [128.100.68.3]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0V32VmP006744 for ; Mon, 31 Jan 2005 04:02:31 +0100 (CET) Received: (from laurent@localhost) by coxeter.math.toronto.edu (AIX5.2/8.11.6p2/8.11.0/UTMath 1.0) id j0V32Rb87436; Sun, 30 Jan 2005 22:02:27 -0500 Date: Sun, 30 Jan 2005 22:02:27 -0500 From: Larry Siebenmann Message-Id: <200501310302.j0V32Rb87436@coxeter.math.toronto.edu> To: lfinsto1@gwdg.de, metafont@ens.fr, metapost@tug.org Subject: Re: Intersections of NURBs X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 31 Jan 2005 04:02:32 +0100 (CET) L. Finston writes: > I've taken another look at this, and there are a couple of things I > don't understand. The decomposition of projective linear transformations of the plane into perspectivities in R^3 is discussed in most texts on synthetic projective geometry. The upshot is that an artists' perspectivity in dimension 3 gives rise to projective a transformation between planes in R^2 that depends only on the choice of an 'eye point' that lies in R^3 not on neither plane. The transformation is affine as well as projective iff and only if the planes are parallel. Conversely, every projective transformation can be achieved by a perspectivity (modulo affine transformation). > In your example, it's not clear to me how the points are > projected onto the plane of the floor. Along straight lines. > If they are at focus level or above, a line through the > focus and a given point will not intersect the floor. It will intersect behind you!! Recall that LS> a projective transformation T of "the plane" is not a > well defined self-mapping of the plane but rather of the > projectively extended plane > > RP^2 = R^2 \cup {projective line at infinity} LF> Nor does this method of projection correspond to > traditional linear perspective, in which the direction > of view is constant. Direction of view is never constant inless the eye is at infinite distance from the scene. You are confusing directions of objects as seen by the eye with the one direction of the point that goes to the center of paper under the perspectivity. The math does not bother with the center of paper concept but your programming does. Cheers Laurent S. PS. Chatting about de Castaljau for NURBS has convinced me that the de Casteljau convex hull property carries over reasonably well to at least those NURBS that are projective transforms of bezier paths. The key fact is (with notations from yesterday): << The projection of the *full* convex hull Cvx(A,B,C,D) does clearly contain the projection of the bezier cubic bb with control trilateral A--B--C--D >> I cannot recall whether that is all NURBS. But I do think it is enough NURBS to make a good application! Circles, ellipses, and hyperbolae are all exactly represented. And all dims and degrees can be treated. The notion of convex hull in RP^n seems well defined for objects that miss some hyperplane. But small objects such as suitably subdivided control polylaterals easily satisfy this condition. Lets hope I am not being too optimistic... From - Mon Jan 31 10:55:50 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0V9tmrH049848 for ; Mon, 31 Jan 2005 10:55:49 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CvYHV-00067q-3M; Mon, 31 Jan 2005 10:55:41 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0V9te80000427758; Mon, 31 Jan 2005 10:55:40 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Mon, 31 Jan 2005 10:55:40 +0100 (MET) From: Laurence Finston To: Larry Siebenmann cc: metafont@ens.fr, metapost@tug.org, help-3dldf Subject: Re: Intersections of NURBs In-Reply-To: <200501310302.j0V32Rb87436@coxeter.math.toronto.edu> Message-ID: References: <200501310302.j0V32Rb87436@coxeter.math.toronto.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 31 Jan 2005 10:55:49 +0100 (CET) On Sun, 30 Jan 2005, Larry Siebenmann wrote: > The decomposition of projective linear transformations of the plane > into perspectivities in R^3 is discussed in most texts on synthetic > projective geometry. > Thanks. As usual, I'll have to keep studying in order to understand your answer. > PS. Chatting about de Castaljau for NURBS has > convinced me that the de Casteljau convex hull property > carries over reasonably well to at least those NURBS > that are projective transforms of bezier paths. > The key fact is (with notations from yesterday): > > Lets hope I am not being too optimistic... > At any rate, my sources on 3D graphics all indicate that NURBs are the de facto standard for 3D applications. So far, I've had to take this on faith. Thanks again for all your help. Laurence From - Mon Jan 31 11:16:01 2005 Return-Path: Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by nef2.ens.fr (8.12.11/1.01.28121999) with ESMTP id j0VAFt9G064493 for ; Mon, 31 Jan 2005 11:15:56 +0100 (CET) Received: from gwdu71.gwdg.de ([134.76.8.21]) by mailer.gwdg.de with esmtp (Exim 4.42) id 1CvYb1-0004bB-Hd; Mon, 31 Jan 2005 11:15:51 +0100 Received: from localhost by gwdu71.gwdg.de (8.11.1/1.1.29.3/16Jun03-0924AM) id j0VAFoQ0000428246; Mon, 31 Jan 2005 11:15:50 +0100 (MET) X-Authentication-Warning: gwdu71.gwdg.de: lfinsto1 owned process doing -bs Date: Mon, 31 Jan 2005 11:15:50 +0100 (MET) From: Laurence Finston To: "L. Nobre G." cc: metafont@ens.fr, metapost@tug.org, help-3dldf Subject: Re: [help-3dldf] Re: [metapost] Re: [metafont] Re: Intersections of NURBs In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie X-Greylist: Recipient e-mail whitelisted, not delayed by milter-greylist-1.5.10 (nef2.ens.fr [129.199.96.32]); Mon, 31 Jan 2005 11:15:56 +0100 (CET) On Sun, 30 Jan 2005, L. Nobre G. wrote: > I think the following "visualization" agrees with both Laurence and Larry > views: > Accordingly to Laurence you don't see the control points B and C > (they are on the southern hemisphere, z-coordinates are less than or > equal to that of `Focus.position') but you should see the bezier curve on > your left. If control points B and C were projected as Larry explained they > would show up on your right. Right? Thanks. I'll have to leave it to Larry (or someone else) to answer, since I don't know. In case anyone's wondering, the reason why points with the same z-coordinate as Focus::position can't be projected is because this would involve division by 0. Objects consisting of points whose z-coordinates are greater than 0 could be projected, but are generally culled, because people don't see that way. Incidentally, I'd be quite interested to know how you do surface hiding in FEATPOST, if you'd care to explain. Laurence