[racket] LC53

Making a cons to two fixnums to represent a double-precision number is horribly inefficient. Are you going to write double-precision addition, subtraction, multiplication and division in Scheme? That isn't even possible without access to the carry flag. This kind of low-level code is normally written in assembly-language as part of the basic implementation of the language. Bignums are also very inefficient --- they are primarily provided for convenience, so the users don't have to worry about precision at all. The users aren't completely saved from worrying about precision though, as it is still possible to screw up (for example, in my LC53 you need to do the multiplication first and then the division, and if you do the division first you will get mush).

I like Scheme --- that is why I'm learning it. I think that Scheme is the best scripting language around --- Scheme is much better than Python and Ruby and all of the other scripting languages available. It is a scripting language though --- that is all that I'm expecting from it. For example, in my novice package I wrote a program in Forth that generates the images of slide-rules' faces in both PostScript and CNC gcode. A program such as that would have been much more easily written in Scheme than in Forth. I'm learning Scheme so that I can crank out simple programs like this quickly (especially when execution speed is not an issue). I wouldn't consider Scheme for writing serious programs though.

For a numerical program it is necessary to have mixed-precision arithmetic. This includes multiplication of two single-precision integers to get a double-precision product, and division of a double-precision integer by a single-precision integer to get a single-precision quotient and remainder. Scheme, Python, Ruby, C/C++, Fortran, Java, etc., don't have this --- Forth is the only language that has this (Factor too, as Slava modified the language at my request to do this, although Factor has only a rudimentary capability compared to Forth).

P.S. That LC53 challenge was a trick question, as I knew from the get-go that Scheme didn't have this capability, and that this was a completely inappropriate application for Scheme. I said above that my slide-rule program would have been much easier in Scheme than in Forth --- this is an appropriate application for Scheme --- perhaps some brave Schemer would like to write a Scheme version of that program. You've got all of the examples that you need, just by running my program and looking at the result. I would definitely be interested in seeing a Scheme version of my program to help me learn Scheme! Of course, it is a big waste of time, as the program has no commercial potential --- but we are all hobbyists anyway, so it is not like our time is real valuable anyway. :-) Maybe one of the teachers will assign this project to his students. My knowledge of Scheme currently is too limited for me to port the slide-rule program myself, and I am still working
 on pretty simple programs, but maybe I will do it sometime in the future --- if nobody else does it first. This isn't a numerical program because there isn't any concern about precision, although it does involve basic arithmetic on floating-point numbers --- the generation of the scales is inherently recursive, you need a simple DSL to describe the scales, and the generation of PostScript and gcode is typical data transformation --- this is the kind of program that Scheme was designed for.

regards --- Hugh



________________________________
 From: Jens Axel Søgaard <jensaxel at soegaard.net>
To: Hugh Aguilar <hughaguilar96 at yahoo.com> 
Sent: Saturday, November 17, 2012 5:32 AM
Subject: Re: [racket] LC53
 
2012/11/17 Hugh Aguilar <hughaguilar96 at yahoo.com>:
> Note that when I invented LC53, the 32-bit x86 was still prevalent and I was
> assuming that the system would be 32-bit. Implementing LC53 on the 64-bit
> x86 using 64-bit registers is too easy --- so for this exercise, please
> assume that you are using a 32-bit processor. As often happens in numerical
> programs, overflow of intermediate values will be an issue.

Since fixnum are 30 bit only on 32 bit systems, this can't use fixnums.
If bignums aren't good enough, one can use a cons to two fixnums to
represent 32 bit numbers.

See
https://github.com/plt/racket/blob/master/collects/file/md5.rkt

-- 
Jens Axel Søgaard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20121119/085b1141/attachment.html>