Re: Floating-point formats and standards
Bradd W. Szonye 06 Jan 2005 10:48 UTC
Aubrey Jaffer wrote:
> This approach combines rank, dimensions, and new floats.
Initial impression: I love it!
A few comments below, mostly regarding minor stuff that needs cleaning up.
> I punted rank-0 for now.
Any particular reason why? It made sense.
> I removed mention of IEEE. Whatever implementation of floating point
> one has, use it! The defaulting rules of SRFI-47 need to be
> redesigned.
Good idea. While this syntax should work especially well with IEEE
flonums, there's no need to require them.
> 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 the
dimension syntax with the #n(...) vector syntax of Common Lisp and PLT
Scheme.
By the way, this beautifully solves the rank-0 syntax problem if you
choose to reintroduce it -- just write ('#0A scalar). I wouldn't
recommend allowing ('#A scalar), though, because allowing "no
dimensions" to mean "rank 0" introduces some nasty ambiguity.
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.
> 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.
> dimension :: nonnegative-integer
>
> rank :: positive-integer
>
> type-specifier :: `flo' { `c' | `r' } flowidth `b' |
> `fix' { `z' | `n' } fixwidth `b' |
> `flo' `r' decwidth `d'
>
> flowdith :: `16' | `32' | `64' | `128'
> fixwdith :: `8' | `16' | `32' | `64'
> decwdith :: `32' | `64' | `128'
Typo: "width" is misspelled in the last three rules.
> 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.
No fixq arrays for rational numbers? C'mon, you know you want to!
Thanks for shortening "boolean" to "bool."
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.
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!
--
Bradd W. Szonye
http://www.szonye.com/bradd