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

Re: Floating-point formats and standards

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.

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

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