[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: srfi-58@xxxxxxxxxxxxxxxxx*Subject*: Re: Floating-point formats and standards*From*: "Bradd W. Szonye" <bradd+srfi@xxxxxxxxxx>*Date*: Thu, 6 Jan 2005 02:48:20 -0800*Delivered-to*: srfi-58@xxxxxxxxxxxxxxxxx*In-reply-to*: <20050106060805.D2EEC1B7727@xxxxxxxxxxxxxxxx>*Mail-followup-to*: srfi-58@xxxxxxxxxxxxxxxxx*References*: <Pine.LNX.4.44.0412262207080.10074-100000@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <20041230222337.3D7BD1B7711@xxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0412301550550.3862@xxxxxxxxxxxxxx> <20050105012438.GD6573@xxxxxxxxxxxxxxx> <20050105055413.5FA901B7717@xxxxxxxxxxxxxxxx> <20050105114809.GB9007@xxxxxxxxxxxxxxx> <20050105122227.GC9007@xxxxxxxxxxxxxxx> <20050105170342.348AC1B7719@xxxxxxxxxxxxxxxx> <20050106004956.GB10975@xxxxxxxxxxxxxxx> <20050106060805.D2EEC1B7727@xxxxxxxxxxxxxxxx>*User-agent*: Mutt/1.4.1i

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

**Follow-Ups**:**Re: Floating-point formats and standards***From:*Aubrey Jaffer

**Re: Floating-point formats and standards***From:*bear

**References**:**Re: #\a octothorpe syntax vs SRFI 10***From:*campbell

**Re: #\a octothorpe syntax vs SRFI 10***From:*Aubrey Jaffer

**Re: #\a octothorpe syntax vs SRFI 10***From:*bear

**Re: #\a octothorpe syntax vs SRFI 10***From:*Bradd W. Szonye

**Re: #\a octothorpe syntax vs SRFI 10***From:*Aubrey Jaffer

**Floating-point formats and standards***From:*Bradd W. Szonye

**Re: Floating-point formats and standards***From:*Bradd W. Szonye

**Re: Floating-point formats and standards***From:*Aubrey Jaffer

**Re: Floating-point formats and standards***From:*Bradd W. Szonye

**Re: Floating-point formats and standards***From:*Aubrey Jaffer

- Prev by Date:
**Re: Floating-point formats and standards** - Next by Date:
**Re: Floating-point formats and standards** - Previous by thread:
**Re: Floating-point formats and standards** - Next by thread:
**Re: Floating-point formats and standards** - Index(es):