NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/tcl/2232

Text File | 1992-12-22 | 3.9 KB | 77 lines

Newsgroups: comp.lang.tcl
Path: sparky!uunet!news.mtholyoke.edu!jbotz
From: [e-mail] (Jurgen Botz)
Subject: Re: Advice wanted on math functions for Tcl 7.0
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Mount Holyoke College
References: <[e-mail]>
Date: Wed, 23 Dec 1992 01:36:21 GMT
Lines: 65

In article <[e-mail]> [e-mail] (John Ousterhout) writes:
>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.

I vote for the embedded implementation... I had to think about this for a
bit, and I came up with the following reasons:

1) Natural syntax.  Programs that use transcendental functions are usually
   doing failry complex math, and readability can make a _big_ difference
   in debugging and allowing others to understand your code.

2) Speed.  Transcendentals aren't needed very often, but when they are
   speed usually is important.  It's true that where Tcl is used it's
   usually not speed-critical, but a Tcl expression doing some reasonably
   sophisticated math needn't execute significantly slower than equivalent
   C code since most of the time is going to be spent in the math library
   anyway.  If you have such an expression in a loop, why slow it down
   unnecessarily with lots of back-and-forth string-number conversions?

3) Data types.  Tcl has only one data type: strings.  Mathematical
   expressions evaluated by computers on the other hand have many data
   types with different representations and precisions.  What happens
   when you evaluate an expression depends a whole lot on the the
   internal implementation of these types in your evaluator, and as
   such should be encapsulated by the evaluator.  True, strings can be
   viewed as a super-set of all the possible internal data types of
   the expression evaluator, and thus are loss-less as an intermediate
   or external representation, but I think that encapsulating math
   funcations in the expression evaluator keeps the Tcl "typeless"
   paradigm cleaner

   For example, I might want to use Tcl in an application that does
   arbitrary-precision arithmetic... if all things that inherently use
   specific precision intermediate representations are encapsulated in
   the "expr" command I can use arbitrary precision arithmetic with
   higher-precision transcendentals by simply supplying my own
   "apexpr" command.  In other words, the supplied transcendentals
   simply don't make much sense outside of the context of the supplied
   expression evaluator.

   As another example, let me address a point John specifically listed
   as a possible advantage of an external implementation of transcendentals:

>4. In the command approach it's possible to use the individual math
>   functions separately without having to go through expr.  For example,
>   you could say "set a [cos $x]", whereas in the embedded approach
>   you'd have to say "set a [expr cos($x)]"

   But indeed the second form makes more sense because what I'm going to
   get back from the command is a string that represents an "expression
   result", i.e. the external representation of the data type "expr" is
   capable of returning.  It is then sufficient for me to know that "expr"
   will return results with a certain precision and in a certain format,
   whereas in the first form I have to specifically know the format and
   precision of the result for each transcendental command (the fact that
   they are likely to all be the same is incidental, since they needn't
   be as string values... they could even be rational numbers, say in
   format "dddd/dddd".)

--
Jurgen Botz                  |   Internet: [e-mail]
Academic Systems Consultant  |     Bitnet: [e-mail]
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629