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

Text File | 1992-12-23 | 3.7 KB | 78 lines

Newsgroups: comp.lang.tcl
Path: sparky!uunet!psinntp!sugar!karl
From: [e-mail] (Karl Lehenbauer)
Subject: Re: Advice wanted on math functions for Tcl 7.0
Organization: NeoSoft Communications Services -- [phone]
Date: Thu, 24 Dec 1992 02:59:25 GMT
Message-ID: <[e-mail]>
References: <[e-mail]>
Lines: 67

My main argument, plain and simple:  What is so special about these math
functions to differentiate them from any other command in Tcl that takes
arguments and returns results?

It complicates the syntax, creates an arbitrary distinction between certain
commands where there need not be one, and -- mark my words -- will not
improve overall program performance one whit.

In article <[e-mail]> [e-mail] (John Ousterhout) writes:
>    expr {$x*sin(2*$theta) + $y*cos(2*$theta)}
>    expr {$x*[sin 2*$theta] + $y*[cos 2*$theta]}

Introduce this new syntax and add all that to expr in order to use parens
instead of brackets and save two characters in the expression?

And then configuring some widget with based on the output of that expression
is going to incur a hundred times more overhead than evaluating the expression
did, anyway.

>Here are the tradeoffs between the two approaches, as I see them:
>1. The embedded approach avoids having to add a lot of commands (10-20)
>   to the command name space and uses the normal functional syntax that
>   people are used to in expressions in other languages like C.

I think it would be unfortunate and naive to look exclusively at the output of
"info commands" as a measure of the complexity of the language.

For one thing, having twelve suboptions to a command, as "string" does,
helps to keep the toplevel namespace small, but doesn't reduce complexity
in any other way (does it?).  The names are still there, and so are the dozen
distinct string functions they invoke.

What we really need are dynamically loadable libraries, IMHO.

>2. By putting the functions into expr, there is less conversion to and
>   from ASCII, which is more efficient (ASCII conversion is pretty slow
>   on most machines).  In the second example above, the results of the
>   sin and cos commands have to be printed in ASCII, then reparsed by
>   expr;  in the first example the only conversion to ASCII is when expr
>   creates its result.

Efficiency has never been an overriding consideration in Tcl, and I am
a bit surprised to see John bringing it up in support of this position.

I'll tell you all, I got burned trying to speed up the early version of
arrays.  Although I was able to make the lookups several times more efficient,
even when creating a test program designed to amplify the performance
increase as much as possible with degenerate cases, I found something like a
1.5% improvement in overall performance.  You must profile if you want to
know where to go to speed up a program.  I have profiled Tcl...

If you live by Tcl_Eval, so shall you die by it.  That's where most of
the overhead is, and that's where it will still be in any Tcl program
regardless of whether floating point function calls (a small part of
any Tcl program for sure) are slightly shortcut.

Come on, Tcl is a pig for any kind of serious floating point.  For sure
you'd go to C, totally for sure, if performance was any kind of issue
at all.  When it isn't, it isn't, and I say if you are using Tcl to do
heavy floating point you have implicitly accepted that you not doing it
the fast way, rather the convenient way.

If you agree, send John a vote for "commands".  If not, "embedded".
I'll live either way.
--
-- Email [e-mail] for info on getting interactive Internet access.
"In a minute, I'll burp up your droid."