Some comments relating to ICFP contest
Andre van Tonder
(25 Jul 2006 20:25 UTC)
|
Re: Some comments relating to ICFP contest
Alex Shinn
(26 Jul 2006 02:04 UTC)
|
Re: Some comments relating to ICFP contest
Michael Sperber
(26 Jul 2006 05:03 UTC)
|
Re: Some comments relating to ICFP contest
Alan Watson
(26 Jul 2006 08:40 UTC)
|
Re: Some comments relating to ICFP contest
Michael Sperber
(26 Jul 2006 09:02 UTC)
|
Re: Some comments relating to ICFP contest
bear
(04 Sep 2006 17:31 UTC)
|
Re: Some comments relating to ICFP contest Andre van Tonder (26 Jul 2006 15:12 UTC)
|
Re: Some comments relating to ICFP contest
Michael Sperber
(26 Jul 2006 15:35 UTC)
|
Re: Some comments relating to ICFP contest
Andre van Tonder
(26 Jul 2006 16:23 UTC)
|
Re: Some comments relating to ICFP contest
Michael Sperber
(27 Jul 2006 15:51 UTC)
|
Re: Some comments relating to ICFP contest Andre van Tonder 26 Jul 2006 15:12 UTC
On Wed, 26 Jul 2006, Michael Sperber wrote: > For sure, SRFI 77 doesn't have 32-bit or 64-bit integers *as types*. > (And that would cause major pain with the way Scheme's arithmetic is > generally set up.) > However, it does have the necessary operations to > easily implement 32-bit or 64-bit unsigned or two's complement > arithmetic in the form of `div+mod' and `div0+mod0' operations. As > such, it also has bit operations on them. Conceded. But the context of my comment was efficiency. How likely is it that implementations will compile the expression (exact-and (* x y) #xFFFFFFFF) to the single machine instruction available on many architectures? Given that SRFI-74 already mentions ranges u32, s32, ..., operations such as exact-u32*, exact-s32-div, ..., would seem natural and could address the efficiency concern. > SRFI 77 doesn't have, but R6RS will have, support for "unboxed arrays" > of numbers in the form of a variation on SRFI 74. I'm not sure they > qualify as "uniform," but is the uniformity crucial to your > application? Oh, they would probably do the job. Andre