[racket] 80-bit precision in Racket

>OOP surely is not what we chose Racket for.

My understanding of Scheme, including Racket, is that types get converted automatically without explicit casting. This is not an add-on for the language, but is inherent in the language. For example:
(/ 10 6)

5/3           this is what Gambit does
(/ 10 6)
1 2/3        this is what Racket does
(/ 10 6)
1.66667   this is what SICP says will happen (pg 5)

Here we have integer data types as inputs, and either a rational or a float as output. This is what I mean by dynamic-OOP, and what I think is inappropriate for a numerical program such as yours. It is pretty convenient for scripting, in which case the user just thinks "number" without distinction between integers, rationals or floats --- most casual programmers don't consider such distinctions to be important, as high-school algebra class never made any such distinction. These are important distinctions for numerical programmers however.

> Our project is a large program, which has its own DSL

The original purpose of Forth was that it could be made into a DSL (a domain-specific-language, although that term didn't exist in the 1970s when Forth was invented). I wasn't suggesting a dual-language solution, but just to use Forth for both the numerical stuff and the DSL stuff. What primarily distinguishes Forth from C or Fortran or Ada or whatever, is that Forth has macros --- code that runs at compile-time and typically generates code that will run at run-time (see my novice package for examples: http://www.forth.org/novice.html). Traditionally, the only languages that have such macros were Forth and Scheme/Lisp, although some other languages have taken a half-step toward supporting macros nowadays. If you want a DSL, Forth and Scheme/Lisp are pretty much the only choices, and if you want numerical programming, you are better off with Forth than with Scheme/Lisp (although if you want OOP, then you are better off with Scheme/Lisp than with Forth).
 I know C well enough, but I don't really like it because it is not interactive and it doesn't support macros (the two virtues of Forth) --- C has been used for a DSL, such as in Lua which I know a little about, but I don't think that it is a very good language for DSLs --- I think that if a person knows Scheme/Lisp and Forth/assembler, he should be able to tackle pretty much any project, high and low, and forget about C, C++, Java, and all of those other abominations that have arisen. :-)

> (1) Learn how to program in Forth

Well, if you don't know Forth at all, that pretty much concludes this discussion. I'm not going to proselytize Forth on the Racket mailing-list (I don't want to get kicked off). I'm here because I'm learning Scheme nowadays, as I think that Scheme is a far superior scripting language than Forth. I also think that Forth is the best language for micro-controllers (better than C which is widely used on micro-controllers, and better than Scheme which is not used on micro-controllers at all). As for numerical programming, I don't really have enough math background to express strong opinions on the subject --- I only know that some Forthers are into numerical programming and have promoted Forth for this purpose (see especially http://www.taygeta.com/), and that my own meager efforts at numerical programming in the past primarily focused on precision issues, which implied that knowing the precision of my numbers was important. Anyway, good luck on retro-fitting
 Racket to support 80-bit floats!

P.S. for Hugh Myers --- It is true that the first Forth application, written by Chuck Moore, was for the National Radio Astronomy Observatory. That isn't a good comparison to Dmitry's program however. Moore's work was essentially a micro-controller program, as it did the motion-control on the stepper-motors that aimed the telescope at the sky. It didn't use floating-point at all, but only used integers as is typical for motion-control software. It wasn't until much later, with the advent of floating-point coprocessors (especially the 8087), that Forth started to be used for numerical programming --- as championed primarily by Skip Carter --- afaik, Chuck Moore isn't a mathematician at all, but is an electrical engineer and a programmer.

P.S. for Dmitry --- What country are you in? There is a Forth/Lisp user's group in Germany that you might be interested in, if you are there. There is actually more Forth being done in Europe (especially Germany) than in America these days (although Skip Carter and Taygeta are in America). VFX is widely considered to be the best Forth system, and it is made by MPE which is in England.

best regards --- Hugh



________________________________
 From: Dmitry Pavlov <dpavlov at ipa.nw.ru>
To: Erich Rast <erich at snafu.de>; Hugh Aguilar <hughaguilar96 at yahoo.com> 
Cc: users at racket-lang.org 
Sent: Wednesday, November 14, 2012 7:32 AM
Subject: Re: [racket] 80-bit precision in Racket
 
Eric, Hugh,

OOP surely is not what we chose Racket for.
This can lead to a lengthy discussion about the definitions of OOP,
level of support of OOP in Racket according to those definitions,
usefulness of OOP for different kinds of tasks, etc. I think we
better skip the whole OOP topic here.

We are not merely integrating orbits. Our project is a large
program, which has its own DSL, certain procedures for
data manipulation, much logic etc. That is written in Racket,
does not suffer from numerical or performance problems, and
is not going to be rewritten in C/Fortran/Forth/etc.

Integration of orbits is a part of the program, so if we chose
to implement it in another language, we have to connect that
language to Racket. This can be very well done for C; maybe
Fortran, too.

If we chose to rewrite the integrator in Forth, we need to:
(1) Learn how to program in Forth
(2) Learn how to connect Forth to Racket
that seems to be quite a job, and I do not currently see
why Forth is better than C for the purpose. C language
and its preprocessor is good enough for pure numeric tasks.

Anyway, what I am currently trying to achieve is to
avoid the whole "binding to second language" problem.
Yes, worrying about "what type each datum is" is no fun,
but it is better than having two languages instead of one.
Also, we have all the power of Racket's macros to make
"type-aware" code simple and pretty.


Best regards,

Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20121114/4563ad76/attachment-0001.html>