From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4893 invoked from network); 15 Sep 1999 07:16:28 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Sep 1999 07:16:28 -0000 Received: (qmail 4851 invoked by alias); 15 Sep 1999 07:16:23 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7832 Received: (qmail 4843 invoked from network); 15 Sep 1999 07:16:20 -0000 Date: Wed, 15 Sep 1999 09:16:19 +0200 (MET DST) Message-Id: <199909150716.JAA30604@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Tue, 14 Sep 1999 17:56:15 +0200 Subject: Re: Floating point support? Peter Stephenson wrote: > I'm thinking about adding some floating point support to zsh; this is just > to canvas opinions. Yes! > My idea is to add a floating point parameter type, > together with support in math evaluations (which would involve stuff like > promoting integers to floats etc.). That's what I was thinking about, too. > ... > > - Is anyone able to summarise what the status is with other shells > (particularly ksh)? I once looked for floating point support in ksh, but don't remember everything, so... http://www.kornshell.com (sorry ;-) Bart Schaefer wrote: > Problems that immediately come to mind: > > For one, suppose I have float-typed parameters x and y and I write > > for i in {$x..$y}; do > or > print *.<$x-$y> > > Another is that array subscripts are math-eval'd, and some pretty strange > things may happen in any code that relies upon multiplication or division > to compute subscripts if floating point gets involved (even if the result > is rounded down). Not that I'm directly aware of any such code ... Hm, but that last one is the same as in every other programming language. So maybe it's OK if we just mention these problems in the docs. Or maybe not? > I'd vote for the module, though it should be in the builtin modules list > for a static compile. Agreed. > } which would require yet more support for hooks > > We could treat it like a Windoze DLL and simply load the module named > "math" (or "float" or something); if users want other special functions > they have add them to a module with that same name. I think we should just allow modules to define functions for math contexts and the possibility to make modules autoloaded on them. Doesn't sound too hard. > Maybe we could put > in support for any module to load another one later in the module path, > for creation of such augmented modules. That may be interesting to have anyway. Although it may be a bit irritating if the loading of such an augmenting module happens accidentally. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de