zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: Floating point support?
Date: Wed, 15 Sep 1999 09:16:19 +0200 (MET DST)	[thread overview]
Message-ID: <199909150716.JAA30604@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Peter Stephenson's message of Tue, 14 Sep 1999 17:56:15 +0200


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


             reply	other threads:[~1999-09-15  7:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-15  7:16 Sven Wischnowsky [this message]
1999-09-15 15:20 ` Bart Schaefer
1999-09-15 17:59 ` Peter Whaite
  -- strict thread matches above, loose matches on Subject: below --
1999-09-14 15:56 Peter Stephenson
1999-09-14 17:06 ` Bart Schaefer
1999-09-15  9:19   ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199909150716.JAA30604@beta.informatik.hu-berlin.de \
    --to=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).