This page is part of the web mail archives of SRFI 58 from before July 7th, 2015. The new archives for SRFI 58 contain all messages, not just those from before July 7th, 2015.
| Date: Thu, 6 Jan 2005 02:48:20 -0800 | From: "Bradd W. Szonye" <bradd+srfi@xxxxxxxxxx> | | Aubrey Jaffer wrote: | > This approach combines rank, dimensions, and new floats. | | Initial impression: I love it! Is it stunned silence from the others? I have emailed the editor with version 6. | > I punted rank-0 for now. | | Any particular reason why? It made sense. It was 1:00am. I restored them today. | > The prefix syntax is: | > | > array-prefix :: rank `A' [ dimensions ] [ `:' type-specifier ] | | > `A' dimensions [ `:' type-specifier ] | | Would you mind terribly making the A optional in the second syntax? | | array-prefix :: rank `A' [ dimensions ] [ `:' type-specifier ] | | [`A'] dimensions [ `:' type-specifier ] | | I realize that it complicates parsing a bit, but it also unifies It took several hours to code, but it seems to work. | the dimension syntax with the #n(...) vector syntax of Common Lisp | and PLT Scheme. Can you describe the PLT compatibility? | Don't forget to give semantics and examples for the shaped-array | syntax. I don't particularly care whether you define the | repeat-fill rule; feel free to leave it for a later SRFI if you | don't want to write it up. Do whole rows, planes, etc also repeat? | > dimensions :: dimension | dimensions `*' dimension | | Anybody feel strongly about "*" vs "x" for the bound separator? I | prefer "x" because it makes the digits stand out more in my editor, | but that may be just a personal/old-age/font thing. Here are some | samples: | | A1. #A2*3*4(...) X1. #A2x3x4(...) T1. #A2×3×4(...) | | A2. #A20*30*40(...) X2. #A20x30x40(...) T2. #A20×30×40(...) | | Hm, strange. A2 and X1 are quite readable on my screen, but A1 and | X2 blur together, making it hard to distinguish the numbers at a | glance. T1 and T2 are also good, but they use U+00D7 (the 'times' | symbol) which won't be universally available on Scheme systems. I don't like x because it looks like mistyped hex numbers (#x33) | > prototype type | > procedure exactness element type specifier | > ========= ========= ============ ========= | > vector any | > A:floc128b inexact 128.bit binary flonum complex floc128b | > A:floc64b inexact 64.bit binary flonum complex floc64b | > A:floc32b inexact 32.bit binary flonum complex floc32b | > A:floc16b inexact 16.bit binary flonum complex floc16b | > A:flor128b inexact 128.bit binary flonum real flor128b | > A:flor64b inexact 64.bit binary flonum real flor64b | > A:flor32b inexact 32.bit binary flonum real flor32b | > A:flor16b inexact 16.bit binary flonum real flor16b | > A:flor128d exact 128.bit decimal flonum real flor128d | > A:flor64d exact 64.bit decimal flonum real flor64d | > A:flor32d exact 32.bit decimal flonum real flor32d | > A:fixz64 exact 64.bit binary fixnum fixz64b | > A:fixz32 exact 32.bit binary fixnum fixz32b | > A:fixz16 exact 16.bit binary fixnum fixz16b | > A:fixz8 exact 8.bit binary fixnum fixz8b | > A:fixn64 exact 64.bit nonnegative binary fixnum fixn64b | > A:fixn32 exact 32.bit nonnegative binary fixnum fixn32b | > A:fixn16 exact 16.bit nonnegative binary fixnum fixn16b | > A:fixn8 exact 8.bit nonnegative binary fixnum fixn8b | > A:bool boolean bool | | That covers all of the basic types. Only binaryx is missing, and I | suspect that it'll be a common extension to the SRFI. One problem | with adding x86 binaryx is that I don't know whether you should | call it an 80-bit type or a 96-bit type. I don't mind if you punt | on it. I think you will find that vectorized instructions don't pack non-power-of-2 bit widths. Breaking operands over cache-line boundaries is a huge hassle for hardware. So the 80-bit and 96-bit are likely stored into 128 bits. We might as well call them 128b. This text I added describes how sizes are chosen: Implementations are required to accept all of the type denotations. Uniform types of matching sizes which the platform supports will be used; the others will be represented as the next larger format of the same type implemented. If there is no larger format of the same type and there is a bignum format for that element type, then the array format defaults to vector; otherwise the largest uniform format of that type is used. | No fixq arrays for rational numbers? C'mon, you know you want to! Although the syntax could easily specify arbitrary precisions, the prototype functions would need to take extra arguments. Should the precision be specified as total bits and fractional bits; or integral bits and fractional bits? | Thanks for shortening "boolean" to "bool." All the type name roots are now 4 characters. | What should systems do if they don't provide a 128-bit fixnum? | 16-bit fixnums are OK, because you can fake them with a larger | type, but there's no good way to get 128-bit floats on an | x86. Please don't /drop/ the 128-bit type, but please do specify | what to do about it. The text above does. If you don't have 128-bit flonums, use the largest flonums you have. | Everything else looks good. | | Joke: This draft is even more compatible with Common Lisp than the | original proposal, because it gives you the kitchen sink too! It is the Swiss-army-knife of array syntax. I hope the R6RS editors are okay with that.