Re: Interpreters and (math) speed

Adam Granicz <di6adag@cse.hks.se>
7 May 1998 17:03:38 -0400

          From comp.compilers

Related articles
Interpreters and (math) speed stefan.wils@zorro.ruca.ua.ac.be (1998-05-04)
Re: Interpreters and (math) speed marlet@irisa.fr (1998-05-07)
Re: Interpreters and (math) speed di6adag@cse.hks.se (Adam Granicz) (1998-05-07)
Re: Interpreters and (math) speed bernecky@acm.org (Robert Bernecky) (1998-05-12)
| List of all articles for this month |
From: Adam Granicz <di6adag@cse.hks.se>
Newsgroups: comp.compilers
Date: 7 May 1998 17:03:38 -0400
Organization: Chalmers University of Technology
References: 98-05-025
Keywords: performance, interpreter

I Don'T Know What You Mean By "Huge Number" For The Built-In Math And
Graphics Primitives, But I Certainly Like The Idea.


There Are Several Reasons Why An Interpreter Is Better Than A Compiler
In Certain Situations, And I Think Your Idea Could Be A Moderately
Great Success If The System Supported Console-Interaction, Where The
User Could Query For Some Operations, And Immediately See The
Results. And For This, An Interpreter Is Certainly Adjustable. I
Would Certainly Implement A Program That Is Capable Of Distinguishing
Between At Least A Couple Of Real Types That Could Be Used For
Variables Or Expressions. String-Support Would Be Nice Also, In Case
You Come Up With Some 3d Text Rendering Stuff, Which I Think A Lot Of
People Would Like. I Don'T Think That High Math Functions Would
Complicate Your Thing Too Much. For One Thing, As Far As I Could Tell
You Are Wanting To Design A System Where You Specify A Bunch Of
Things, And Then The Computer Draws The Output, Either In The Form Of
A Graph, A Function, An Object, Etc. All The Math Stuff Is Hidden In
Your Implementation, Unless You Let The User Specify His Or Her Own
Math Routines For Some Operations. Either Way, I Think It Would Be A
Nice Program To Work On.


adam granicz.








--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.