Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #1374 > unrolled thread

Re: Computer arithmetic problems worth exploring

Back to article view | Back to comp.arch

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Computer arithmetic problems worth exploring George Neuner <gneuner2@comcast.net> - 2011-05-07 03:06 -0400
    Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-07 09:44 +0100
      Re: Computer arithmetic problems worth exploring Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-07 11:38 +0100
        Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-07 12:21 +0100
          Re: Computer arithmetic problems worth exploring Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-07 13:47 +0100
            Re: Computer arithmetic problems worth exploring Quadibloc <jsavard@ecn.ab.ca> - 2011-05-07 09:55 -0700
              Re: Computer arithmetic problems worth exploring Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-07 19:27 +0100
                Re: Computer arithmetic problems worth exploring Quadibloc <jsavard@ecn.ab.ca> - 2011-05-07 13:54 -0700
                  Re: Computer arithmetic problems worth exploring George Neuner <gneuner2@comcast.net> - 2011-05-09 13:38 -0400
                    Re: Computer arithmetic problems worth exploring Robert A Duff <bobduff@shell01.TheWorld.com> - 2011-05-10 12:40 -0400
                      Re: Computer arithmetic problems worth exploring Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-10 20:32 +0200
              Re: Computer arithmetic problems worth exploring torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-05-09 13:42 +0200
      Re: Computer arithmetic problems worth exploring Quadibloc <jsavard@ecn.ab.ca> - 2011-05-07 04:26 -0700
        Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-07 12:13 +0100
    Re: Computer arithmetic problems worth exploring "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-07 14:59 -0700
      Re: Computer arithmetic problems worth exploring George Neuner <gneuner2@comcast.net> - 2011-05-09 14:14 -0400
        Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-09 20:38 +0100
        Re: Computer arithmetic problems worth exploring "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-09 13:55 -0700
          Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-10 09:05 +0100
            Re: Computer arithmetic problems worth exploring Jason Riedy <jason@lovesgoodfood.com> - 2011-05-10 13:24 -0400
              Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-10 18:41 +0100
              Re: Computer arithmetic problems worth exploring "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-11 13:56 -0700
              Re: Computer arithmetic problems worth exploring "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-11 14:04 -0700
              Re: Computer arithmetic problems worth exploring "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-11 14:06 -0700
            Re: Computer arithmetic problems worth exploring "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-11 13:55 -0700
              Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-11 22:15 +0100
                Re: Computer arithmetic problems worth exploring Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-12 20:52 +0100
                  Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-12 20:20 +0100
                    Re: Computer arithmetic problems worth exploring Quadibloc <jsavard@ecn.ab.ca> - 2011-05-12 14:55 -0700
                  Re: Computer arithmetic problems worth exploring Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-13 12:25 +0200
                    Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-13 11:18 +0100
                      Re: Computer arithmetic problems worth exploring "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-14 13:19 -0700
                        Re: Computer arithmetic problems worth exploring Quadibloc <jsavard@ecn.ab.ca> - 2011-05-14 19:11 -0700
                Re: Computer arithmetic problems worth exploring "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-12 20:08 -0700
              Re: Computer arithmetic problems worth exploring Jason Riedy <jason@lovesgoodfood.com> - 2011-05-12 23:54 -0400
          Re: Computer arithmetic problems worth exploring George Neuner <gneuner2@comcast.net> - 2011-05-12 01:08 -0400
            Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-12 09:27 +0100
              Re: Computer arithmetic problems worth exploring Quadibloc <jsavard@ecn.ab.ca> - 2011-05-12 05:41 -0700
                Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-12 13:22 +0100
                  Re: Computer arithmetic problems worth exploring Quadibloc <jsavard@ecn.ab.ca> - 2011-05-12 07:22 -0700
                    Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-12 14:58 +0100
                      Re: Computer arithmetic problems worth exploring MitchAlsup <MitchAlsup@aol.com> - 2011-05-12 09:23 -0700
                      Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-12 22:59 +0000
                        Re: Non-constant initializers Ian Collins <ian-news@hotmail.com> - 2011-05-13 11:07 +1200
                          Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-12 23:17 +0000
                            Re: Non-constant initializers Ian Collins <ian-news@hotmail.com> - 2011-05-13 11:20 +1200
                              Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-12 23:30 +0000
                                Re: Non-constant initializers Ian Collins <ian-news@hotmail.com> - 2011-05-13 11:34 +1200
                                  Re: Non-constant initializers Keith Thompson <kst-u@mib.org> - 2011-05-12 16:52 -0700
                                    Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-14 00:13 +0000
                                      Re: Non-constant initializers kym@kymhorsell.com - 2011-05-14 01:54 +0000
                                        Re: Non-constant initializers Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-14 01:07 -0700
                                          Re: Non-constant initializers kym@kymhorsell.com - 2011-05-14 09:22 +0000
                                            Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-14 17:14 +0000
                                  Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-14 00:11 +0000
                        Re: Non-constant initializers Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-12 16:15 -0700
                          Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-12 23:28 +0000
                        Re: Non-constant initializers Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-12 18:01 -0600
                          Re: Non-constant initializers Keith Thompson <kst-u@mib.org> - 2011-05-12 18:15 -0700
                            Re: Non-constant initializers Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-12 22:56 -0600
                              Re: Non-constant initializers Seebs <usenet-nospam@seebs.net> - 2011-05-13 05:18 +0000
                          Re: Non-constant initializers Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> - 2011-05-13 23:57 +0000
              Re: Computer arithmetic problems worth exploring "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-12 20:20 -0700
                Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-13 09:48 +0100
                  Re: Computer arithmetic problems worth exploring Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-13 12:55 +0200
                    Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-13 11:25 +0100
                      Re: Computer arithmetic problems worth exploring MitchAlsup <MitchAlsup@aol.com> - 2011-05-13 08:57 -0700
                        Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-13 16:42 +0100
                          Re: Computer arithmetic problems worth exploring MitchAlsup <MitchAlsup@aol.com> - 2011-05-13 13:17 -0700
                            Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-13 21:03 +0100
                            Re: Computer arithmetic problems worth exploring Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-14 06:43 +0200
                              Re: Computer arithmetic problems worth exploring Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-14 06:55 +0100
                                Re: Computer arithmetic problems worth exploring "Ken Hagan" <k.hagan@thermoteknix.com> - 2011-05-17 12:59 +0100
                                  Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-17 12:44 +0100
                                    Re: Computer arithmetic problems worth exploring Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-17 14:07 +0100
                                      Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-17 17:20 +0100
                                    Re: Computer arithmetic problems worth exploring "Ken Hagan" <k.hagan@thermoteknix.com> - 2011-05-17 15:03 +0100
                              Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-14 08:43 +0100
                                Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-14 09:17 +0100
                            Re: Computer arithmetic problems worth exploring Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-05-14 09:04 -0700
                            Re: Computer arithmetic problems worth exploring "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-14 17:00 -0700
                        Re: Computer arithmetic problems worth exploring "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-14 16:58 -0700
                          Re: Computer arithmetic problems worth exploring Quadibloc <jsavard@ecn.ab.ca> - 2011-05-14 19:07 -0700
                            Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-15 09:40 +0100
                            Re: Computer arithmetic problems worth exploring Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-16 11:05 +0200
                              Re: Computer arithmetic problems worth exploring Quadibloc <jsavard@ecn.ab.ca> - 2011-05-16 06:44 -0700
                                Re: Computer arithmetic problems worth exploring mac <acolvin@efunct.com> - 2011-05-19 20:17 +0000
                                  Re: Computer arithmetic problems worth exploring Quadibloc <jsavard@ecn.ab.ca> - 2011-05-19 15:20 -0700
                                    Re: Computer arithmetic problems worth exploring George Neuner <gneuner2@comcast.net> - 2011-05-19 18:51 -0400
                                      Re: Computer arithmetic problems worth exploring Petter Gustad <newsmailcomp6@gustad.com> - 2011-05-20 08:01 +0200
                                        Re: Computer arithmetic problems worth exploring "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-20 15:09 -0700
                                      Re: Computer arithmetic problems worth exploring Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-20 08:54 +0200
                                        Re: Computer arithmetic problems worth exploring "Ken Hagan" <k.hagan@thermoteknix.com> - 2011-05-23 11:11 +0100
                                          Re: Computer arithmetic problems worth exploring George Neuner <gneuner2@comcast.net> - 2011-05-23 18:20 -0400
                                        Re: Computer arithmetic problems worth exploring Morten Reistad <first@last.name> - 2011-06-03 08:21 +0200
                                Re: Computer arithmetic problems worth exploring Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-05-19 13:31 -0700
                              Re: Computer arithmetic problems worth exploring Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-05-16 09:05 -0700
                                Re: Computer arithmetic problems worth exploring Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-16 22:37 +0200
                                  Re: Computer arithmetic problems worth exploring Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-05-18 23:16 -0700
                                Re: Computer arithmetic problems worth exploring ChrisQ <meru@devnull.com> - 2011-05-17 17:10 +0100
                                  Re: Computer arithmetic problems worth exploring Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-17 17:27 +0100
                                    Re: Computer arithmetic problems worth exploring ChrisQ <meru@devnull.com> - 2011-05-17 23:08 +0100
                                    Re: Computer arithmetic problems worth exploring Tom <tggzzz@blueyonder.co.uk> - 2011-05-17 22:37 +0000
                                      Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-18 09:25 +0100
                                        Re: Computer arithmetic problems worth exploring Quadibloc <jsavard@ecn.ab.ca> - 2011-05-18 06:25 -0700
                                          Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-18 14:06 +0100
                                          Re: Computer arithmetic problems worth exploring Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-18 19:23 +0100
                                            Re: Computer arithmetic problems worth exploring Quadibloc <jsavard@ecn.ab.ca> - 2011-05-18 13:48 -0700
                                              Re: Computer arithmetic problems worth exploring Andrew Reilly <areilly---@bigpond.net.au> - 2011-05-19 00:29 +0000
                                                Re: Computer arithmetic problems worth exploring "Ken Hagan" <k.hagan@thermoteknix.com> - 2011-05-19 13:12 +0100
                                  Re: Computer arithmetic problems worth exploring Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-05-18 23:27 -0700
                                    Re: Computer arithmetic problems worth exploring Quadibloc <jsavard@ecn.ab.ca> - 2011-05-19 15:19 -0700
                                      Re: Computer arithmetic problems worth exploring Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-05-20 07:33 -0700
                            Re: Computer arithmetic problems worth exploring Michael S <already5chosen@yahoo.com> - 2011-05-16 03:14 -0700
                              Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-16 10:43 +0100
                                Re: Computer arithmetic problems worth exploring Michael S <already5chosen@yahoo.com> - 2011-05-16 04:58 -0700
                                  Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-16 12:40 +0100
                          Re: Computer arithmetic problems worth exploring MitchAlsup <MitchAlsup@aol.com> - 2011-05-15 10:12 -0700
                  Re: Computer arithmetic problems worth exploring "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-14 13:22 -0700
                    Re: Computer arithmetic problems worth exploring nmm1@cam.ac.uk - 2011-05-15 09:02 +0100
                  Re: Computer arithmetic problems worth exploring "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-14 14:02 -0700
            Re: Computer arithmetic problems worth exploring "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-12 20:18 -0700
        Re: Computer arithmetic problems worth exploring Robert Myers <rbmyersusa@gmail.com> - 2011-05-09 14:32 -0700
          Re: Computer arithmetic problems worth exploring "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-09 16:08 -0700

Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

#1426

In article <8739kmqxhz.fsf@NaN.sparse.dyndns.org>,
Jason Riedy  <jason@lovesgoodfood.com> wrote:
>
>> The thing that IEEE gets spectacularly wrong is its handling of
>> exceptional values (including zero, but that's not visible
>> except via infinities).  And I mean WRONG.
>
>Not everyone agrees with you, and I'm tired of laying out the
>same text again and again.

I am rather bored of correcting your errors, and even
misrepresentations.  I shall attempt to point them out, and stop.

>> It is completely and utterly wrong that x = y does not mean
>> that 1/x = 1/y.
>
>Unless you're tracing either side of an air foil, where that
>matters.  (Or other conformal mapping with a slice.)  Blame the
>standard for supporting users and most architects for insisting
>the mode you want be dropped.  (Yes, projective mode was in the
>original proposal and was removed because it sank the whole
>effort.)

On the contrary.  It is STILL wrong.  And, no, I am not talking
about projective mode.  As I have said before, 90% of arithmetic
is done in the real domain, and the IEEE 754 model conflates
true zero, approximate zero and positive infinitesimals.  That
is mathematically wrong and introduces major gotchas.

Note that I have no objection to signed infinitesimals ('zeroes'),
provided that they are not conflated with true or approximate
zeroes, and it is THAT that causes the trouble - NOT the actual
existence of signed infinitesimals.

>> And, by sick, I mean false positive, false negatives and
>> dubious semantics.
>
>Again, not everyone agrees with you, although I do only for
>allowing a choice on when to signal underflow.  But then
>architects blow a fuse.

Then I suggest that you read the fine print of the standard you
are so enamoured of.  They are all there, and I am talking
mathematical consistency and not matters of judgement.

I suggest that you also find out rather more about the semantic
models of the dominating programming languages.  In particular,
it was and is incompatible with both Fortran and C - though recent
C standards have forbidden existing optimisations and introduced
incompatibilities to improve the fit.

>> And its NaN handling is utterly and completely broken, though
>> it wasn't half as bad when it was designed.  Blame the fanatics
>> who got that into C99, but not only them.
>
>Again, not everyone agrees with you.  I found it quite handy even
>before going to Berkeley and being told the "right" way to use
>NaN propagation.

Yes, doubtless.  I date from an era where we took RAS seriously.

>> 1) There is a mandatory trap-diagnose-and-terminate mode, as
>> on traditional mainframes and in LIA-1.  The objection to this
>> is and was purely dogmatic.
>
>If by "dogmatic" you mean "motivated by vector operations at the
>time and still in use" and "motivated by the mainframe policies
>in operation then".  Nothing in 754 precludes such a mode.

No, I don't.  The dogma was and is to conflate that mode, which
is easy to implement in hardware and compatible with almost all
programming languages, with trap-and-continue, which isn't.
It was pointed out ad nauseam that was known to be false.

And, while it is needed for sane support of parallel operations
(not just vector), it is needed EVEN MORE for support of all
mainstream programming languages.  You simply CAN'T add
trap-and-continue to their semantic models, as 40 years of
attempts to do so have shown.

I have told you about LIA-1 before, but it seems to have little
effect.

>Standardizing such a mode requires standardizing *what* is being
>terminated.  Good luck with that.

It terminates the 'program', and what that means is dependent on
its use.  See LIA-1.  It's been done - and in an ISO standard.

>> 2) Division by zero creates a NaN, not an infinity, thus
>> removing the main gotch caused by the inconsistent
>> interpretation of the sign bit.
>
>Which is a choice that screws a set of users who participated
>with code and text during initial standardization.

And rammed their gotcha-ridden design down everyone else's throats.

See above about signed infinitesimals.

>> 3) ALL numeric operations on NaNs return a NaN or raise a
>> (hard) exception if they can't (including comparison), and the
>> ONLY way to lose a NaN is by an explicit non-numeric test for
>> such a value.
>
>Which is a choice that screws a set of users who participated
>with code and text both during initial standardization and during
>its "re-visioning."

That is exactly why the trapping of integer overflow has been
almost eliminated.  It is SO much better to get wrong answers,
quietly, than a failure that has to be bypassed :-(

I should also point out that the claims about it being needed
for statistics were and are known to be wholly false.

>While I don't like all of the resulting sausage, I know how and
>why it happened.

Regrettably, so do I :-(

The 1984 standard, for all its faults, was better than anything
else around (except perhaps for DEC's alternative, which I did
not see).  But, in the current round, instead of addressing its
design problems, they were simply denied and programming languages
were told that theyhad to abandon their semantic models.  People
don't write much assembler any longer, you know.

Furthermore, one of the main arguments for it in the early 1980s
was efficiency, and that argument was good, then.  Things have
changed, and now its model is a major, but MAJOR obstacle to
efficiency, both at the compiler and hardware level.

I shall not go into its history in the NCEG and WG14, though I
know them far too well.



Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#1461

On 5/10/2011 10:24 AM, Jason Riedy wrote:
> And Nick Maclaren writes:
>> The thing that IEEE gets spectacularly wrong is its handling of
>> exceptional values (including zero, but that's not visible
>> except via infinities).  And I mean WRONG.
>
> Not everyone agrees with you, and I'm tired of laying out the
> same text again and again.
>
>> It is completely and utterly wrong that x = y does not mean
>> that 1/x = 1/y.
>
> Unless you're tracing either side of an air foil, where that
> matters.  (Or other conformal mapping with a slice.)  Blame the
> standard for supporting users and most architects for insisting
> the mode you want be dropped.  (Yes, projective mode was in the
> original proposal and was removed because it sank the whole
> effort.)

Why did it "sink the whole effort"?

[toc] | [prev] | [next] | [standalone]

#1462

On 5/10/2011 10:24 AM, Jason Riedy wrote:
> And Nick Maclaren writes:

>> 1) There is a mandatory trap-diagnose-and-terminate mode, as
>> on traditional mainframes and in LIA-1.  The objection to this
>> is and was purely dogmatic.
>
> If by "dogmatic" you mean "motivated by vector operations at the
> time and still in use" and "motivated by the mainframe policies
> in operation then".  Nothing in 754 precludes such a mode.
> Standardizing such a mode requires standardizing *what* is being
> terminated.  Good luck with that.

Thanks for the insight.  Or at least the reminder.

I worry that there is resistance to traps on scalar machines.

But you point out that there was an even bigger problem with traps on 
vector machines.  Do you terminate with a vector half-done, and a mask 
indicating how far along you got?  Do you require that the mask be of 
the form 111111000000, i.e. everything to the left, or lower, is done, 
nothing above is done?  Precise, or not?

Of course, this point is almost moot.  Classsic vector machines are 
almost dead.  The forms in which they are re-arising, like LRB, solve 
this problem more cleanly.

Except, of course, that just moves the problem of precision out of 
hardware and into software.  If you are running a DO loop on 128 
processors, when you trap, which iterations have completed?

[toc] | [prev] | [next] | [standalone]

#1463

On 5/10/2011 10:24 AM, Jason Riedy wrote:

> While I don't like all of the resulting sausage, I know how and
> why it happened.

While I don't like all of the resulting sausage, I like it better than 
some of the earlier sausage (like IBM HEX FP and CDC FP).

And I know that it happened, i.e. that the sausage got made.

I'd appreciate any pointers to internal discussions, pros and cons, so 
that I can understand the tradeoffs.

[toc] | [prev] | [next] | [standalone]

#1460

On 5/10/2011 1:05 AM, nmm1@cam.ac.uk wrote:
> In article<4DC854BF.8090308@SPAM.comp-arch.net>,
> Andy \"Krazy\" Glew<andy@SPAM.comp-arch.net>  wrote:

>> If we don't go that far, IEEE FP is about as good of a floating point
>> standard as can be achieved. It eliminates most of the FP surprises for
>> unsophisticated programmers that can be eliminated, and still remain FP.
>
> Grrk.  It doesn't do it significantly better than most of the better
> traditional arithmetics do.

Is  IEEE FP better than IBM hex FP?  IMHO yes.

Better than CDC 60 bit FP?  IMHO yes.

But I concede the point:  yes, we can imagine better FP.  I vaguely 
remember reading some of the proposals considered and rejected during 
the IEEE FP standardization effort - or perhaps I saw or read one of 
Kahan's presentations.


Now, the real question:  is it worth fixing?  Is it feasible to fix? 
Could, for example, some SW guy build a "Better FP" library that uses 
some of the things Nick has mentioned, like -0,0,+0, and popularize it? 
  If it was in wide use, then HW might add support?
      Or could some  really brave HW company add  the support, probably 
with an enable that allowed conventional IEEE FP to be supported.
      My guess is that this could not be done in 32 bit - the encodings 
are too tight.  Perhaps in 64 bit. Or in a new, wider, format.


> The thing that IEEE gets spectacularly wrong is its handling of
> exceptional values (including zero, but that's not visible except
> via infinities).  And I mean WRONG.
>
> It is completely and utterly wrong that x = y does not mean that
> 1/x = 1/y.
>
> The argument that it sets a flag would hold water if it were not
> for the fact that the flag handling is seriously sick, as well as
> incompatible with the arithmetic model of all relevant computing
> languages.  And, by sick, I mean false positive, false negatives
> and dubious semantics.

Yes, the idea of setting sticky flags seems to have been a compromise 
that made almost nobody happy.

Personally, I'm all for traps and exceptions as the standard way of 
reporting errors.
    * http://andyglew.blogspot.com/2009/07/error-handling.html
    * http://semipublic.comp-arch.net/wiki/Error_Reporting

But,. it's hard to get traction.

> And its NaN handling is utterly and completely broken, though it
> wasn't half as bad when it was designed.  Blame the fanatics who
> got that into C99, but not only them.
>
> If IEEE 754 had the following modifications, then it would be
> about as good as could be achieved:
>
>      1) There is a mandatory trap-diagnose-and-terminate mode, as
> on traditional mainframes and in LIA-1.  The objection to this
> is and was purely dogmatic.
>
>      2) Division by zero creates a NaN, not an infinity, thus
> removing the main gotch caused by the inconsistent interpretation
> of the sign bit.

Which is better:

-0,0,+0 such that 1/-0=-inf, 1/+0=+inf, 1/0=inf of unknown sign?

Or 1/0 = NaN?



>      3) ALL numeric operations on NaNs return a NaN or raise a
> (hard) exception if they can't (including comparison), and the
> ONLY way to lose a NaN is by an explicit non-numeric test for
> such a value.

Wasn't Kahan conducting a survey about this in CAM a few years ago?

No, actually, it looked like he was  asking leading questions that 
pointed in the direction of getting rid of silent NaNs.

[toc] | [prev] | [next] | [standalone]

#1467

In article <4DCAF7BA.3010700@SPAM.comp-arch.net>,
Andy \"Krazy\" Glew <andy@SPAM.comp-arch.net> wrote:
>
>>> If we don't go that far, IEEE FP is about as good of a floating point
>>> standard as can be achieved. It eliminates most of the FP surprises for
>>> unsophisticated programmers that can be eliminated, and still remain FP.
>>
>> Grrk.  It doesn't do it significantly better than most of the better
>> traditional arithmetics do.
>
>Is  IEEE FP better than IBM hex FP?  IMHO yes.
>
>Better than CDC 60 bit FP?  IMHO yes.

That's why I said "the better traditional arithmetics".  Those
were among the worst!  At least System/360 was consistent, though
being consistently inaccurate is a dubious accolade.

>Now, the real question:  is it worth fixing?  Is it feasible to fix? 
>Could, for example, some SW guy build a "Better FP" library that uses 
>some of the things Nick has mentioned, like -0,0,+0, and popularize it? 

They could, but I doubt that it's worth it.  The active area is
interval arithmetic, where there is an ISO working group.   That's
very comparable.

As I hope that I made clear, my preference is for a simpler, more
consistent and - most of all - more checkable model.

>Yes, the idea of setting sticky flags seems to have been a compromise 
>that made almost nobody happy.

In 1984, it wasn't absolutely clear that it was a catastrophic
idea, though those of us who knew the way compilers were going
knew it.  But, by 1995, it was known to everyone.

>Personally, I'm all for traps and exceptions as the standard way of 
>reporting errors.
>    * http://andyglew.blogspot.com/2009/07/error-handling.html
>    * http://semipublic.comp-arch.net/wiki/Error_Reporting

Yes, but - PROVIDED that you don't also add the ability to continue
transparently!  try/catch is fine - call handler and return is a
disaster area.

>But,. it's hard to get traction.

God help us all, yes :-(

>Which is better:
>
>-0,0,+0 such that 1/-0=-inf, 1/+0=+inf, 1/0=inf of unknown sign?
>
>Or 1/0 = NaN?

If you can distinguish the three cases, it's moot.  What I object
to is 1/-0=-inf, 1/+0=+inf, 1/0=+inf.  That's a foul gotcha.

>>      3) ALL numeric operations on NaNs return a NaN or raise a
>> (hard) exception if they can't (including comparison), and the
>> ONLY way to lose a NaN is by an explicit non-numeric test for
>> such a value.
>
>Wasn't Kahan conducting a survey about this in CAM a few years ago?
>
>No, actually, it looked like he was  asking leading questions that 
>pointed in the direction of getting rid of silent NaNs.

Yes.  There, I agree with him - but every language that I know of
that has supported IEEE 754 NaNs has got rid of signalling ones,
or deprecated them into near uselessness!

I can't tell you whether he lost the argument in 1984 or changed
his views, but quiet NaN comparison was one of the things that
made me splutter when I first read IEEE 754.  I then did a test
on myself, and took considerable care coding - but I had still
got 20% of the tests wrong for correct NaN handling!


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#1499

nmm1@cam.ac.uk wrote:

> The active area is
> interval arithmetic, where there is an ISO working group.   That's
> very comparable.

I'm completely outside the area of my expertise, but hasn't
interval arithmetic been one of the next great things for
the past 25 years?

[toc] | [prev] | [next] | [standalone]

#1500

In article <ZTWyp.1575$yI6.7@newsfe06.ams2>,
Tom Gardner  <spamjunk@blueyonder.co.uk> wrote:
>
>> The active area is
>> interval arithmetic, where there is an ISO working group.   That's
>> very comparable.
>
>I'm completely outside the area of my expertise, but hasn't
>interval arithmetic been one of the next great things for
>the past 25 years?

Longer :-)


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#1501

On May 12, 1:20 pm, n...@cam.ac.uk wrote:
> In article <ZTWyp.1575$yI...@newsfe06.ams2>,
> Tom Gardner  <spamj...@blueyonder.co.uk> wrote:

> >I'm completely outside the area of my expertise, but hasn't
> >interval arithmetic been one of the next great things for
> >the past 25 years?
>
> Longer :-)

Indeed. I was curious to find out exactly how much longer... and it
turns out, not quite as long as I thought.

R. E. Moore published a technical report in 1959, and a Ph.D. thesis
in 1962, but the first paper on the subject appeared in a review
journal, thus being likely to attract widespread attention, in 1965.
(The book Interval Analysis appeared next year in 1966, which is when
Wikipedia says that the modern era of interval arithmetic started.)

And I thought it would have gone back at least as far as 1961, the era
of the STRETCH.

John Savard

[toc] | [prev] | [next] | [standalone]

#1531

Tom Gardner wrote:
> nmm1@cam.ac.uk wrote:
>
>> The active area is
>> interval arithmetic, where there is an ISO working group. That's
>> very comparable.
>
> I'm completely outside the area of my expertise, but hasn't
> interval arithmetic been one of the next great things for
> the past 25 years?

When I looked a little bit into this, it seemed to me that at least when 
using worst-case assumptions, it is very easy for a known stable 
algorithm, like a NR iteration for sqrt/invsqrt, to show horrible loss 
of accuracy according to interval arithmetic?

Do I misremember, or is this a solved problem in IA?

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[toc] | [prev] | [next] | [standalone]

#1533

In article <ihdv98-ntt2.ln1@ntp6.tmsw.no>,
Terje Mathisen  <"terje.mathisen at tmsw.no"> wrote:
>Tom Gardner wrote:
>>
>>> The active area is
>>> interval arithmetic, where there is an ISO working group. That's
>>> very comparable.
>>
>> I'm completely outside the area of my expertise, but hasn't
>> interval arithmetic been one of the next great things for
>> the past 25 years?
>
>When I looked a little bit into this, it seemed to me that at least when 
>using worst-case assumptions, it is very easy for a known stable 
>algorithm, like a NR iteration for sqrt/invsqrt, to show horrible loss 
>of accuracy according to interval arithmetic?
>
>Do I misremember, or is this a solved problem in IA?

I have been told several times that it's a solved problem, but
have never been able to find a useful reference.  Several of
the claimants have said, in essence "It's a solved problem because
all iterative algorithms can be expressed in a direct form."
You can imagine how far I got when I asked for a reference to
that rather interesting development in mathematics!

It's like the dubious claims that all reductions can deliver
deterministic results, efficiently.  Let's ignore ones that
deliver partial results, which clearly can't.  Max/min and
searching obviously can, and addition can by treating the
operands as accurate fixed-point numbers.  Well, that isn't
efficient for 128-bit IEEE 754, for a start.  But, even worse,
what about multiplication?  Or general reductions, using an
arbitrary associative and commutative operator?


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#1574

On 5/13/2011 3:18 AM, nmm1@cam.ac.uk wrote:
> In article<ihdv98-ntt2.ln1@ntp6.tmsw.no>,
> Terje Mathisen<"terje.mathisen at tmsw.no">  wrote:
>> Tom Gardner wrote:
>>>
>>>> The active area is
>>>> interval arithmetic, where there is an ISO working group. That's
>>>> very comparable.
>>>
>>> I'm completely outside the area of my expertise, but hasn't
>>> interval arithmetic been one of the next great things for
>>> the past 25 years?




x = [-1,+1]

1/x = [-inf,-1] union [+1,+inf]

To do anything fancy in advanced arithmetic, you need Mathematica or 
Maple like symbolic analysis, or at least. Something that can represent 
disjoint intervals.

[toc] | [prev] | [next] | [standalone]

#1584

On May 14, 2:19 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
wrote:

> x = [-1,+1]
>
> 1/x = [-inf,-1] union [+1,+inf]
>
> To do anything fancy in advanced arithmetic, you need Mathematica or
> Maple like symbolic analysis, or at least. Something that can represent
> disjoint intervals.

True, but "interval arithmetic" is normally thought of as a way of
doing

x = [2.77999, 2.78001]
1/x = [0.3597109,0.3597136]

and if one happens to do a division by zero which is no longer exactly
precise, of course one will get a NaN as a result. One isn't trying to
do anything "fancy", one just wants error bounds on a conventional
computation that could have proceeded with ordinary numbers.

John Savard

[toc] | [prev] | [next] | [standalone]

#1517

On 5/11/2011 2:15 PM, nmm1@cam.ac.uk wrote:
> In article<4DCAF7BA.3010700@SPAM.comp-arch.net>,
> Andy \"Krazy\" Glew<andy@SPAM.comp-arch.net>  wrote:

>>>       3) ALL numeric operations on NaNs return a NaN or raise a
>>> (hard) exception if they can't (including comparison), and the
>>> ONLY way to lose a NaN is by an explicit non-numeric test for
>>> such a value.
>>
>> Wasn't Kahan conducting a survey about this in CAM a few years ago?
>>
>> No, actually, it looked like he was  asking leading questions that
>> pointed in the direction of getting rid of silent NaNs.
>
> Yes.  There, I agree with him - but every language that I know of
> that has supported IEEE 754 NaNs has got rid of signalling ones,
> or deprecated them into near uselessness!
>
> I can't tell you whether he lost the argument in 1984 or changed
> his views, but quiet NaN comparison was one of the things that
> made me splutter when I first read IEEE 754.  I then did a test
> on myself, and took considerable care coding - but I had still
> got 20% of the tests wrong for correct NaN handling!

I'm not so sure:  quiet NaNs or the equivalent are necessary for things 
like spreadsheets, where you still want to put values into cells even if 
they do calculations like 1/-0(=-inf), or 0/0 or other indeterminate values.

There *must* be a not-number value.  Just like null in databases.  Data 
occasionally is missing.  (And screw papers like 
http://www.dcs.warwick.ac.uk/~hugh/TTM/Missing-info-without-nulls.pdf)

The only questions are

a) what are the semantics of operations involving missing data, NaNs or 
nulls, or ... ?

b) should there be hardware support?  Or should it be entirely a 
software construct.

c) should there be a big performance penalty?

The real problem is that the semantics a) are not, well, understood. 
Different people want different things.

This is usually an indication that hardware support b) is NOT desired. 
If software can't get its act together...

But the problem is c):  nobody wants a spreadsheet reevaluation to take 
1000X more time if there happens to be a NaN propagating everywhere.

I conclude that we need NaN support, both signalling and non-signalling. 
  But with minimal hardware semantics.

Possibly, trap (with expectation of return, as opposed to trap and die), 
and allow a signalling or silent NaN to be inserted by software. 
Possibly with software putting a pointer to some datastructure in the 
silent NaN.

With the simplest possible propagation rules.

Control flow involving NaNs is always problematic.  NaNs are just like 
taint propagation, and taint propagation, DIFT, is divided into three types:
    1) basic DIFT:  propagate through arithemtic, but pointers
       like  (*tainted_pointer)=untained_value does not proapagate
    2) pointer DIFT: (*tainted_pointer)=untained_value propagates
with the third type being control flow DIFT, where the program counter 
itself becomes tainted.  That last may be a Glewism: I'm not aware of 
anyone else being so extreme (or having figured out who to handle it).

I suspect the same may be required for NaN involvement in control flow.

[toc] | [prev] | [next] | [standalone]

#1525

And Andy Glew writes:
> Wasn't Kahan conducting a survey about this in CAM a few years
> ago?
>
> No, actually, it looked like he was asking leading questions
> that pointed in the direction of getting rid of silent NaNs.

No, we were looking for actual users of *signaling* NaNs.  This
was part of the 754 revision effort; it was a committee-wide
query.  IIRC, I posted the open letter here, although likely
under a group address.
-- 
Jason

[toc] | [prev] | [next] | [standalone]

#1482

On Mon, 09 May 2011 13:55:27 -0700, "Andy \"Krazy\" Glew"
<andy@SPAM.comp-arch.net> wrote:

>On 5/9/2011 11:14 AM, George Neuner wrote:
>> On Sat, 07 May 2011 14:59:10 -0700, "Andy \"Krazy\" Glew"
>> <andy@SPAM.comp-arch.net>  wrote:
>>
>>> (2) are less likely to be surprised by things like x-y=0 not being
>>> equivalent to x=y
>>
>> No.  IME unsophisticated programmers are dumbfounded to discover
>> things like x-y=0<>  x=y  and  9(x/9)<>  x.   The simple arithmetic
>> they learned in school fails almost immediately unless they happen to
>> be lucky enough to be using arbitrary precision arithmetic.
>
>It is possible I expressed myself poorly, that you misunderstood what I 
>was trying to say, and that we actually agree:

Possibly.

>Unsophisticated programmers are the ones who need as much help as 
>possible, preserving simple rules lile x-y=0 <=> x=y.  Which, IIRC, IEEE 
>FP provides.
>
>Unfortunately, IEEE FP does not eliminate all of  the gotchas. In 
>particular, y(x/y) <> x.
>
>So it is possible that you are arguing that IEEE FP is not safe enough. 

I try to go by the principle of least surprise.  As it stands, it is
incredibly easy to find simple equalities and/or relations that don't
hold under IEEE FP ... mainly due to inexact representation.

Some of Nick's complaint's: NaN, denormals, underflow, etc. typically
don't rear their heads until the equations become trickier, but
bizarre (to the user) inequalities and relations can strike a newbie
immediately.

And I agree, at least in theory, that programmers should be learning
about floating point before trying to use it ... but FP either isn't
taught or is glossed over in most CS, CE or CIS programs.  Besides
which, now the vast majority of programmers have no formal computer
education anyway (and many no math beyond algebra).  

The computing world has shifted to where the vast majority of
programmers are stunned by results that don't match the basic
arithmetic they learned in school.   And there are precious few
resources to which they can turn for answers.  There are a few good
papers like Goldberg's, but those that attempt to explain the issues
assume some knowledge of calculus from the reader.


>Perhaps you advocate universal default use of rational bignum and 
>bigdecimal arithmetic, possibly with symbolic treatment of irrational 
>numbers like pi and e and ...
>
>There's good arguments for that, but I'm not going to go that far yet. 
>(And, IMHO, just providing bignum rationals  without supporting 
>symbolically exact computations involving pi is just a bandaid.)

I'm not really an advocate of software decimal FP although I do think
it is the only real choice for exacting arithmetic right now.  I'm not
terribly thrilled with decimal FP (754-2008) either - it represents
even fewer numbers exactly than does binary FP.  Wider formats (binary
or decimal) with greater precision help but just push back the issue
of exactness and consume ever larger amounts of chip real estate to do
so.  It would be better if the same number of bits could represent a
larger set of exact numbers.

I want speed as much as the next programmer and that means hardware.
I'd go for the implementation that yields the largest set of numbers
being exactly represented given the bit allowance.  WRT IEEE, that
would mean an incompatible format change.  There are packed series
formats that potentially would squeeze more exactly represented
numbers into the same number of bits, but not being a hardware person
I don't know if any such format could ever be practical to use.


>If we don't go that far, IEEE FP is about as good of a floating point 
>standard as can be achieved. It eliminates most of the FP surprises for 
>unsophisticated programmers that can be eliminated, and still remain FP.
>
>---
>
>Regulars on comp.arch will know that I am a fan of computer hardware 
>instruction set support for "security" like Milo Martin's HardBound. 
>Really, this is support that tries to minimize, catch, prevent, many 
>common programming bugs that lead to security holes.
>
>IEEE FP, with things like denorms and gradual underflow, is to numerical 
>analysis what HardBound is to buffer overflow errors. It's not perfect, 
>but it helps, and  is, IMHO, probably a good use of hardware.
>     Actually, IEEE FP has much better  arguments for it than the 
>"security" support.  It is much less different than existing machines.

George

[toc] | [prev] | [next] | [standalone]

#1489

In article <qmmms6h8met2ha0akir6jb71kasnna7c3f@4ax.com>,
George Neuner  <gneuner2@comcast.net> wrote:
>On Mon, 09 May 2011 13:55:27 -0700, "Andy \"Krazy\" Glew"
><andy@SPAM.comp-arch.net> wrote:
>
>
>>Unsophisticated programmers are the ones who need as much help as 
>>possible, preserving simple rules lile x-y=0 <=> x=y.  Which, IIRC, IEEE 
>>FP provides.
>>
>>Unfortunately, IEEE FP does not eliminate all of  the gotchas. In 
>>particular, y(x/y) <> x.
>>
>>So it is possible that you are arguing that IEEE FP is not safe enough. 
>
>I try to go by the principle of least surprise.  As it stands, it is
>incredibly easy to find simple equalities and/or relations that don't
>hold under IEEE FP ... mainly due to inexact representation.

Well, yes.  But, as I teach in my arithmetic course, ALL of those
gotchas apply to the floating-point that they were (or should have
been) taught at school, by hand using pencil and paper.  I then
ask the rhetorical question were they taught that?  So far, I have
not had ONE who has answered "yes"!

>Some of Nick's complaint's: NaN, denormals, underflow, etc. typically
>don't rear their heads until the equations become trickier, but
>bizarre (to the user) inequalities and relations can strike a newbie
>immediately.

Which is GOOD.  Learning that your assumptions are wrong is far
better than writing a lot of code only to discover that all of
it is based on false premises.  I have seen users hit this one
after having written 10,000 lines.

>And I agree, at least in theory, that programmers should be learning
>about floating point before trying to use it ... but FP either isn't
>taught or is glossed over in most CS, CE or CIS programs.  Besides
>which, now the vast majority of programmers have no formal computer
>education anyway (and many no math beyond algebra).  

Yup.  My course is a one-afternoon summary of all that they need
to know - and, yes, that's moving fast.  It's given to graduates
and staff, and seems popular with those who attend.

>The computing world has shifted to where the vast majority of
>programmers are stunned by results that don't match the basic
>arithmetic they learned in school.   And there are precious few
>resources to which they can turn for answers.  There are a few good
>papers like Goldberg's, but those that attempt to explain the issues
>assume some knowledge of calculus from the reader.

Yes.  It's odd.  If I were writing such a paper, I would use
algebraic terminology (and I mean field and ring properties) :-)

It's had to do more than state the problems without using some
non-trivial mathematics, but they can be stated to be simple for
all but the thickest students.  WARNING:  Here be dragons.
Next foil: how to recognise a dragon.

>I'm not really an advocate of software decimal FP although I do think
>it is the only real choice for exacting arithmetic right now.  I'm not
>terribly thrilled with decimal FP (754-2008) either - it represents
>even fewer numbers exactly than does binary FP.  Wider formats (binary
>or decimal) with greater precision help but just push back the issue
>of exactness and consume ever larger amounts of chip real estate to do
>so.  It would be better if the same number of bits could represent a
>larger set of exact numbers.

Both hardware and software decimal floating-point are a demented
idea, and all of the arguments in favour of them can be turned
round and used against it.  Not that it's particularly harmful,
overall, as those of us who were writing seriously portable
floating-point in the 1970s can witness.

The point is that ALL it does is to remove a few of the most
obvious gotchas, so that programmers are more likely to get
further before hitting trouble.  And it adds one significant
gotcha that binary does not have.

People are forgetting that binary replaced other bases because
it was claimed to be numerically better - yes, I was a heretic
then too, and knew that was a false claim.  But it DOES provide
the most information and accuracy for a fixed number of bits,
and IEEE 754 is close to optimal in its use of bits.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#1491

On May 12, 2:27 am, n...@cam.ac.uk wrote:

> Both hardware and software decimal floating-point are a demented
> idea, and all of the arguments in favour of them can be turned
> round and used against it.  Not that it's particularly harmful,
> overall, as those of us who were writing seriously portable
> floating-point in the 1970s can witness.
>
> The point is that ALL it does is to remove a few of the most
> obvious gotchas, so that programmers are more likely to get
> further before hitting trouble.  And it adds one significant
> gotcha that binary does not have.
>
> People are forgetting that binary replaced other bases because
> it was claimed to be numerically better - yes, I was a heretic
> then too, and knew that was a false claim.  But it DOES provide
> the most information and accuracy for a fixed number of bits,
> and IEEE 754 is close to optimal in its use of bits.

This reminds me of what I discuss on the page

http://www.quadibloc.com/comp/cp020302.htm

on my web site.

Since an argument against decimal floating-point is that the radix, at
10, is larger than 2, the radix of binary floating-point numbers, and
thus the numbers represented in decimal floating-point are *less
evenly distributed* on the real line -

I proposed a scheme where the representable numbers in decimal
floating-point are distributed something like the ticks on a slide
rule. A four-bit code represents the first digit and the last digit of
the significand (mantissa, coefficient) of a DFP number, the
intervening ones perhaps being represented by some version of Chen-Ho
encoding.

0000 .1(...)0
0001 .1(...)2
0010 .1(...)4
0011 .1(...)6
0100 .1(...)8
0101 .2(...)0
0110 .2(...)5
0111 .3(...)0
1000 .3(...)5
1001 .4(...)0
1010 .4(...)5
1011 .5(...)0
1100 .6(...)0
1101 .7(...)0
1110 .8(...)0
1111 .9(...)0

Thus instead of a sudden jump in precision by a factor of 10, the
precision gradually decreases by factors of 2, 2.5, and 2.

One can use a similar scheme of coding so that the precision of binary
floating point numbers gradually decreases by roughly a third of a
bit. I go on to explain how that can be done on the page

http://www.quadibloc.com/comp/cp020303.htm

which you may read if you dare.

John Savard

[toc] | [prev] | [next] | [standalone]

#1492

In article <bea77480-bdf6-458c-8ecd-05ea23d297c7@k3g2000prl.googlegroups.com>,
Quadibloc  <jsavard@ecn.ab.ca> wrote:
>
>This reminds me of what I discuss on the page
>
>http://www.quadibloc.com/comp/cp020302.htm
>
>on my web site.
>
>Since an argument against decimal floating-point is that the radix, at
>10, is larger than 2, the radix of binary floating-point numbers, and
>thus the numbers represented in decimal floating-point are *less
>evenly distributed* on the real line -

Yup.  The 'wobbling accuracy' problem, that was hotly debated in
the argument between bases 2, 8 and 16 - by then, base 10 was
unimportant.

>I proposed a scheme where the representable numbers in decimal
>floating-point are distributed something like the ticks on a slide
>rule. A four-bit code represents the first digit and the last digit of
>the significand (mantissa, coefficient) of a DFP number, the
>intervening ones perhaps being represented by some version of Chen-Ho
>encoding.
>
>One can use a similar scheme of coding so that the precision of binary
>floating point numbers gradually decreases by roughly a third of a
>bit. I go on to explain how that can be done on the page
>
>http://www.quadibloc.com/comp/cp020303.htm
>
>which you may read if you dare.

An interesting variation.  I am afraid that I regard the debate on
this matter as being a storm in a teacup, and would tend to use
base 256 for software floating-point.  The reason is that, to a
first approximation, this problem just loses ln_2(base) bits of
accuracy, irrespective of anything else.

There were a lot of examples in the 1970s of how a hexadecimal
base could cause an error build up of that magnitude per step,
but almost all were bogus as they took truncation as a basic
assumption!  I did some testing, and found that rounded base 16
was only about 3-4 bits worse than base 2, almost irrespective
of amount of calculation!  But it was only a little testing.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#1493

On May 12, 6:22 am, n...@cam.ac.uk wrote:

> There were a lot of examples in the 1970s of how a hexadecimal
> base could cause an error build up of that magnitude per step,
> but almost all were bogus as they took truncation as a basic
> assumption!

Of course, IBM System/360 floating-point *did* truncate instead of
round. That simplified implementation of the low-end machines by
increasing the commonalities between fixed-point arithmetic and
floating-point arithmetic.

I do agree with you, though, that superfluous precision, except for
wasting storage space and computation time, is not intrinsically
harmful, even if that precision is present or absent in a capricious
manner - when the rounding, and the variation in precision are both
unbiased.

John Savard

[toc] | [prev] | [next] | [standalone]

Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

Back to top | Article view | comp.arch

csiph-web