From: gah@att.com (George A. Howlett)
Subject: Re: Advice wanted on math functions for Tcl 7.0
Reply-To: george.howlett@att.com
Organization: AT&T Bell Laboratories
Date: Tue, 22 Dec 1992 19:12:03 GMT
X-Newsreader: TIN [version 1.1 PL8]

John Ousterhout (ouster@sprite.Berkeley.EDU) wrote:

: I'm about to start in earnest on the Tcl 7.0 release (first I'll
: probably put out a Tk 3.1 release to fix all the bugs people are
: finding with 3.0).  Thanks for all the input that many of you
: provided in response to my draft of possible changes for 7.0.
: There's still one issue I haven't been able to resolve, having to
: do with the implementation of math functions like sin and cos.  This
: message explains the issue and then asks for a vote from those of
: you that care.

: There are two possible ways to implement math functions: embedded into
: expr or as separate commands, and I can't make up my mind about which
: way to do it.

: In the embedded implementation, the syntax of expressions gets extended
: with functional notation for all the math functions so that you can say
: things like
:     expr {$x*sin(2*$theta) + $y*cos(2*$theta)}

: In the command implementation, each math function becomes a separate
: command.  These commands would allow not only numbers but arbitrary
: expressions as arguments, and produce floating-point string results,
: so the expr command above would look like this instead:
:     expr {$x*[sin 2*$theta] + $y*[cos 2*$theta]}


I've done both implementations, at first creating new Tcl commands 
and then as an extension to "expr".  I think the extension to expr
is the cleaner, more natural method.

One of the things that makes Tcl a good extension language is that its
syntax is easy to learn.  Command languages need to be simple and the
Tcl command set should not be another hurdle for users. It's hard
enough getting users for a new tool or application, without making
them read a bunch of manual pages.

New users are already bothered by new syntax. And they get confused by
the nested commands in expressions. But for the most part, they're already
comfortable with expressions like a+b*sqrt(c).

It's also natural to think of these functions as extensions of the
"expr" command.  They both take numeric expressions and observe
precedence rules.  Unlike the command implementation, you don't have 
to remember which commands can take expressions and which ones can't.
You generally use these functions in conjunction with "expr" anyways. 

I think it's important that the Tcl command set remain small.
I find it easier to remember hierarchic commands like "string" 
and "file" than their flattened cousins like "lappend" and "llength".
Adding 10-20 extra commands is more to remember.

The command approach muddies the Tcl name space and can provide naming
conflicts.  For example, I may have a journaling command called "log".
And what about the ambiguity between math function "exp" and "expr"?
Save the Tcl name space for application-related commands and procs.

The command approach is less efficient but also can be less accurate.
Rounding errors can be generated, as values are converted back to
ASCII strings.  Given an adjustable floating point conversion (as in
Tcl 7.0), this is admittedly rare.  But it can still very hard to
track down, especially if you are expecting double precision
arithmetic.

And as icing on the cake, the embedded functions automatically work 
with "if", "while", etc.
   
	if { floor(log10($x)) > 2 } { 

as opposed to 

	if { [floor [log10 $x]] > 2 } {
	

--gah



Newsgroups: comp.lang.tcl