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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

#1528 — Re: Non-constant initializers

(Followups to comp.lang.c only, this has nothing to do with comp.arch.)

On 2011-05-13, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
> Keith Thompson <kst-u@mib.org> writes:
>>     6.23 Non-Constant Initializers
>>     ==============================

> The OP said he wanted non-constant initializers for global variables,
> not for automatic variables.

Yes.  But the question was where in the gcc docs there was anything about
C99 allowing non-constant initializers.  The answer is, there.  Only, as
you note, it doesn't say it about globals.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#1554 — Re: Non-constant initializers

On Thu, May 12, 2011 at 06:01:54PM -0600, Joe Pfeiffer wrote:
> Fred the Freshwater Catfish <usenet.fred@bdtd.invalid> writes:
> >
> > I've been writing some code that I would prefer to be maximally
> > portable.  As I have mostly used Linux, gcc is pretty much the only C
> > compiler I've ever used under UN*X.  I'd like to use non-constant
> > initializers for some global variables.  I'm pretty sure I can get it
> > to work the way I want under gcc, but what of other compilers?  The
> > gcc documentation in info format says that ISO C99 allows this, and so
> > I expect some compilers built in the 90's will support the feature,
> > but to what extent is this true?
> 
> Where does the documentation say this is allowed by C99?  The C99
> standard says
> 
>   All the expressions in an initializer for an object that has static
>   storage duration shall be constant expressions or string literals.
> 
> (Section 6.7.8 paragraph 4)

I figured out my problem.  First, the docs:
	
	File: gcc-4.5.info, Node: Initializers, Next: Compound Literals, Prev:
	Pointer Arith,  Up: C Extensions
	
	6.23 Non-Constant Initializers
	==============================
	
	As in standard C++ and ISO C99, the elements of an aggregate
	initializer for an automatic variable are not required to be constant
	expressions in GNU C.  Here is an example of an initializer with
	run-time varying elements:
	
	     foo (float f, float g)
	     {
	       float beat_freqs[2] = { f-g, f+g };
	       /* ... */
	     }
	


 1 #include <stdio.h>
 2 #include <fcntl.h>
 3 #include <stdlib.h>

 5 int * initialize(void)
 6 {
 7 	int *p;
 8	int fd;
 9
 10	fd = open("/dev/urandom", O_RDONLY);
 11	if(-1 == fd) {
 12		perror("open()");
 13		exit(1);
 14	}
 15
 16	read(fd, p, sizeof(int *));
 17	
 18	return(p);
 19 }
 20
 21 main(int argc, char ** argv)
 22 {
 23 	int * glob = initialize();
 24
 25	fprintf(stdout, "glob = %d\n", glob);
 26
 27	exit(0);
 28 }

So I thought I could move the "glob = initialize()" call out of main()
and have a convenient way to set up global variables.  This is the
problem of designing vaporware when there are a lot of details to
manage.  I'll just have to arrange to load/save my globals with a
little bit more work.  Anyhow, my initial question was related to
efforts to avoid using compilerisms which might lead to portability
issues.  As my project approaches alpha-release material, I'm trying
to plan ahead enough to avoid massive rewrites in stuff that could
limit portability.

Sorry for my misinterpretation of gcc capabilities.



Fred the Freshwater Catfish

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

#1521

On 5/12/2011 1:27 AM, nmm1@cam.ac.uk wrote:
> In article<qmmms6h8met2ha0akir6jb71kasnna7c3f@4ax.com>,

>> 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.

Post your lecture notes?  Slides, if you have them?

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

#1529

Andy \"Krazy\" Glew <andy@SPAM.comp-arch.net> wrote:
>
>>> 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.

No, that's completely wrong.  IEEE NaN has totally the wrong semantics
for missing values, and they are primarily error indicators.  I am a
statistician by training, and have worked with some of the people
who introduced missing values into modern computing.

I have a part-written paper that describes something half a dozen
classes of "Not A Number", and the key factor is that they all have
different and usually incompatible semantics.

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

It was specifically the question of what "IF x > NaN THEN ..." should
do.  IEEE 754 has punted on it, but with an implication that taking
the False path for both that AND "IF x <= NaN THEN ..." is a good
idea.  My assertion is that it is not.

>> 1/0 is undefined in any field, and always has been.  Hence a NaN.
>> Most people would also map the infinity of unknown sign to a NaN,
>> but you could have another value if you preferred.
>>
>> Anyway, my point wasn't that you SHOULD provide all of that, but
>> that the traditional arithmetic model is mathematically consistent,
>> and (bluntly) IEEE 754 isn't.
>
>"Traditional mathematical model"?
>
>I thought this wall all classified as non-standard analysis.  Which was 
>not mathematically formalized until the 20th century.  Is that what you 
>mean by "traditional"?

I am referring to the one developed by numerical analysts and
(later) statisticians for finite-precision calculations in the 19th
and first half of 20th centuries.  It was used to put a fair number
of numerical algorithms into a solid framework in the 1950s to 1970s.

>And then I realized: you are from Cambridge. Home of Isaac Newton and 
>infinitesimals.

True, but not relevant here :-)

>> You will immediately notice that using Cartesian representation
>> with two compactified real numbers does not map well onto what
>> is needed for complex ones.  It's a devil of a problem, technically
>> most easily addressed by using polar coordinates.  However, that
>> is a step too far for most people ....
>
>Sorry the Riemann sphere formulation for complex is equivalent to the 
>affine for reals, with only a single infinity in both cases.

The single infinity compactification of the reals does not preserve
the ordering properties.

>As you may have noticed, I immediately jump to polar coordinates for 
>directed infinities.

Fine.  Good luck in getting programming languages to follow you!

>> 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.
>
>Post your lecture notes?  Slides, if you have them?

See:    http://www-uxsup.csx.cam.ac.uk/courses/Arithmetic/

Note that I am NOT claiming that the statements made there are all
mathematically justifiable - I have not separated out my personal
recommendations from provable statements.


Regards,
Nick Maclaren.

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

#1534

nmm1@cam.ac.uk wrote:
> Andy \"Krazy\" Glew<andy@SPAM.comp-arch.net>  wrote:
>> a) what are the semantics of operations involving missing data, NaNs or
>> nulls, or ... ?
>
> It was specifically the question of what "IF x>  NaN THEN ..." should
> do.  IEEE 754 has punted on it, but with an implication that taking
> the False path for both that AND "IF x<= NaN THEN ..." is a good
> idea.  My assertion is that it is not.

Afair the idiom of "if ((0 < x) || (0 >= x)) {" has been used in a bit 
of code to determine that (x) is a regular number, not a NaN. It does of 
course depend on both comparisons to fail when x is indeed NaN.

>> Post your lecture notes?  Slides, if you have them?
>
> See:    http://www-uxsup.csx.cam.ac.uk/courses/Arithmetic/
>
> Note that I am NOT claiming that the statements made there are all
> mathematically justifiable - I have not separated out my personal
> recommendations from provable statements.

Thanks for posting anyway. :-)

Terje

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

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

#1535

In article <5afv98-e0u2.ln1@ntp6.tmsw.no>,
Terje Mathisen  <"terje.mathisen at tmsw.no"> wrote:
>>
>> It was specifically the question of what "IF x>  NaN THEN ..." should
>> do.  IEEE 754 has punted on it, but with an implication that taking
>> the False path for both that AND "IF x<= NaN THEN ..." is a good
>> idea.  My assertion is that it is not.
>
>Afair the idiom of "if ((0 < x) || (0 >= x)) {" has been used in a bit 
>of code to determine that (x) is a regular number, not a NaN. It does of 
>course depend on both comparisons to fail when x is indeed NaN.

Yes, they have.  That's not the point.  As every competent engineer
(software, hardware or other) knows, the key to RAS and security
is not handling the problems you expect but ensuring that the ones
you don't are (at worst) very rare or caused only by extreme
circumstances.  My point is that writing fail-safe code when doing
the run-of-the-mill comparisons is virtually impossible for mere
mortals.  And at (say) one such comparison every 5-20 lines of
executable code, that is a BIG problem.


Regards,
Nick Maclaren.

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

#1544

On May 13, 5:25 am, n...@cam.ac.uk wrote:
> In article <5afv98-e0u2....@ntp6.tmsw.no>,
> >Afair the idiom of "if ((0 < x) || (0 >= x)) {" has been used in a bit
> >of code to determine that (x) is a regular number, not a NaN. It does of
> >course depend on both comparisons to fail when x is indeed NaN.
>
> Yes, they have.  That's not the point.  

It seems to me that the inherent problem, here, is ::

"What is to be the effect of comparing things that are incomparable"?

Perhaps one should resurect the old FORTRAN IF and add a 4'th lable

100  IF(X.NE.Y) 1,2,3,4

Where the 4'th label is delivered control if the operands are
incomparible.

This seems to be at least as much a language issue as a HW
computational issue.

Mitch

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

#1545

In article <4a613763-70c7-4a66-aa75-7ce3476cddd3@x10g2000yqj.googlegroups.com>,
MitchAlsup  <MitchAlsup@aol.com> wrote:
>
>> >Afair the idiom of "if ((0 < x) || (0 >= x)) {" has been used in a bit
>> >of code to determine that (x) is a regular number, not a NaN. It does of
>> >course depend on both comparisons to fail when x is indeed NaN.
>>
>> Yes, they have.  That's not the point.
>
>It seems to me that the inherent problem, here, is ::
>
>"What is to be the effect of comparing things that are incomparable"?
>
>Perhaps one should resurect the old FORTRAN IF and add a 4'th lable
>
>100  IF(X.NE.Y) 1,2,3,4
>
>Where the 4'th label is delivered control if the operands are
>incomparible.

Do you know SNOBOL? :-)

A modern version of that would be:

    IF (...) THEN
        ...
    ELSE
        ...
    UNORDERED
        ...
    END IF

>This seems to be at least as much a language issue as a HW
>computational issue.

Oh, agreed, but IEEE 754 didn't get it wholly wrong, except for
the equality/inequality operator.  All of the other default ones
raise the invalid exception if one of the operands is a NaN,
which is correct in any environment where that exception always
indicates a serious error and cannot easily get lost.

With that exception, if you got a proper diagnostic on raising
the invalid exception (as in LIA-1), all would be well.  And that
aspect IS a hardware issue, as well as a software one.


Regards,
Nick Maclaren.

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

#1551

On May 13, 10:42 am, n...@cam.ac.uk wrote:
> In article <4a613763-70c7-4a66-aa75-7ce3476cd...@x10g2000yqj.googlegroups.com>,
>
>
>
>
>
> MitchAlsup  <MitchAl...@aol.com> wrote:
>
> >> >Afair the idiom of "if ((0 < x) || (0 >= x)) {" has been used in a bit
> >> >of code to determine that (x) is a regular number, not a NaN. It does of
> >> >course depend on both comparisons to fail when x is indeed NaN.
>
> >> Yes, they have.  That's not the point.
>
> >It seems to me that the inherent problem, here, is ::
>
> >"What is to be the effect of comparing things that are incomparable"?
>
> >Perhaps one should resurect the old FORTRAN IF and add a 4'th lable
>
> >100  IF(X.NE.Y) 1,2,3,4
>
> >Where the 4'th label is delivered control if the operands are
> >incomparible.
>
> Do you know SNOBOL? :-)

A very long time ago--circa 1972

> A modern version of that would be:
>
>     IF (...) THEN
>         ...
>     ELSE
>         ...
>     UNORDERED
>         ...
>     END IF
>
> >This seems to be at least as much a language issue as a HW
> >computational issue.
>
> Oh, agreed, but IEEE 754 didn't get it wholly wrong, except for
> the equality/inequality operator.  All of the other default ones
> raise the invalid exception if one of the operands is a NaN,
> which is correct in any environment where that exception always
> indicates a serious error and cannot easily get lost.

I seem to recall at least one machine of my college era (circa
1971-77) that did equality comparisons on Floats in such a way that if
the numbers were equal to within 3lsb the equality flag was set (?
1108?). Thus: (1.0/3.0)*3.0 was equal to 1.0 even with (but a few)
rounding errors.

Would something like this help or just confuse the issue even more?

Mitch

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

#1553

In article <ea4ee012-3633-4763-8b04-a6aff626e562@p23g2000vbl.googlegroups.com>,
MitchAlsup  <MitchAlsup@aol.com> wrote:
>>
>> >"What is to be the effect of comparing things that are incomparable"?
>>
>> >Perhaps one should resurect the old FORTRAN IF and add a 4'th lable
>>
>> >100 =A0IF(X.NE.Y) 1,2,3,4
>>
>> >Where the 4'th label is delivered control if the operands are
>> >incomparible.
>>
>> Do you know SNOBOL? :-)
>
>A very long time ago--circa 1972

Naturally - it went out of use shortly thereafter.  Then you will
understand my reference :-)

>I seem to recall at least one machine of my college era (circa
>1971-77) that did equality comparisons on Floats in such a way that if
>the numbers were equal to within 3lsb the equality flag was set (?
>1108?). Thus: (1.0/3.0)*3.0 was equal to 1.0 even with (but a few)
>rounding errors.
>
>Would something like this help or just confuse the issue even more?

A very good question.  As far as I know, that approach went out
of fashion without any decent investigation into whether it was
a good or bad idea.  A great pity ....


Regards,
Nick Maclaren.

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

#1559

MitchAlsup wrote:
>> Oh, agreed, but IEEE 754 didn't get it wholly wrong, except for
>> the equality/inequality operator.  All of the other default ones

I agree, the default fp compare should trap on a NaN.

We already have special opcodes that can be used to detect them if their 
occurrence is a normal situation which can/should be handled without 
trapping.

>> raise the invalid exception if one of the operands is a NaN,
>> which is correct in any environment where that exception always
>> indicates a serious error and cannot easily get lost.
>
> I seem to recall at least one machine of my college era (circa
> 1971-77) that did equality comparisons on Floats in such a way that if
> the numbers were equal to within 3lsb the equality flag was set (?
> 1108?). Thus: (1.0/3.0)*3.0 was equal to 1.0 even with (but a few)
> rounding errors.

Wow!

That is a _very_ expensive default: Since the normal epsilon (1.0 -> 
0.99999...) causes an exponent change you would have to handle this as a 
special form of rounding and/or do a fp subtract without 
post-normalization, masking the mantissa instead.
>
> Would something like this help or just confuse the issue even more?

Probably the latter, just like dec fp: Easy cases seem exact, teaching 
students that it is so, then it blows up later.
:-(

It probably helps to have grown up in the slide rule/log table age: All 
(more or less) fp operations had very limited precision, and that was 
very obvioous.

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

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

#1560

Terje Mathisen wrote:

> It probably helps to have grown up in the slide rule/log table age: All
> (more or less) fp operations had very limited precision, and that was
> very obvioous.

Interesting idea. I wonder if anyone has tried to see if it has any validity.

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

#1631

On Sat, 14 May 2011 06:55:51 +0100, Tom Gardner  
<spamjunk@blueyonder.co.uk> wrote:

> Terje Mathisen wrote:
>
>> It probably helps to have grown up in the slide rule/log table age: All
>> (more or less) fp operations had very limited precision, and that was
>> very obvioous.
>
> Interesting idea. I wonder if anyone has tried to see if it has any  
> validity.

I hope not. It sounds like the sort of "study" that ends up in a tabloid  
newspaper.

It probably helps to have twenty years more experience, certainly. A naive  
study of the two groups would fall foul of that. One could try looking for  
youngsters who, despite growing up without them, have learned how to use a  
slide rule, or oldies who never figured out how. But I expect those are  
both even more biased samples.

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

#1632

In article <op.vvmjkrvbjcamrv@khagan.ttx>,
Ken Hagan <k.hagan@thermoteknix.com> wrote:
>On Sat, 14 May 2011 06:55:51 +0100, Tom Gardner  
><spamjunk@blueyonder.co.uk> wrote:
>> Terje Mathisen wrote:
>>
>>> It probably helps to have grown up in the slide rule/log table age: All
>>> (more or less) fp operations had very limited precision, and that was
>>> very obvioous.
>>
>> Interesting idea. I wonder if anyone has tried to see if it has any  
>> validity.
>
>I hope not. It sounds like the sort of "study" that ends up in a tabloid  
>newspaper.

Because you don't think it's likely, it shouldn't be investigated?
Hmm.

>It probably helps to have twenty years more experience, certainly. A naive  
>study of the two groups would fall foul of that. One could try looking for  
>youngsters who, despite growing up without them, have learned how to use a  
>slide rule, or oldies who never figured out how. But I expect those are  
>both even more biased samples.

Well, yes, but that's soluble.  The cost of a serious investigation
probably isn't.

Teaching people to learn principles in an environment where problems
are obvious and critical is an excellent technique.  The modern
approach of shielding the kiddies from such things has meant that
we now have TWO generations that don't understand them, as the
claims of the decimal floating-point brigade shows very clearly.
No, it doesn't solve any problems - it just makes them much less
obvious.

The same thing applies to learning programming.  The best way to
learn C is to start by writing significant, COMPLEX, code in
Assembler.  You either learn self-discipline or will fail.  But
too many people start from the other end and come unstuck the
first time that they hit a problem that the debugger cannot
identify for them.


Regards,
Nick Maclaren.

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

#1635

nmm1@cam.ac.uk wrote:
> Teaching people to learn principles in an environment where problems
> are obvious and critical is an excellent technique.  The modern
> approach of shielding the kiddies from such things has meant that
> we now have TWO generations that don't understand them,

And that principle is valid for much more than mere computing!


> The same thing applies to learning programming.  The best way to
> learn C is to start by writing significant, COMPLEX, code in
> Assembler.  You either learn self-discipline or will fail.

I've no problems with that in the 80s, but has C become
sufficiently complex that it isn't the case any more?
I haven't programmed C recently, but the plethora of
subtle compile and link time switches makes me suspicious
that I wouldn't be able to determine whether or not I'd
missed corner cases.


> But
> too many people start from the other end and come unstuck the
> first time that they hit a problem that the debugger cannot
> identify for them.

Oh yes. Even in the 80s, too many people couldn't
relate very simple C code to the compiler's output.
Bring back In Circuit Emulators for debugging; that'll
learn 'em.

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

#1641

In article <gquAp.5278$5C7.2842@newsfe10.ams2>,
Tom Gardner  <spamjunk@blueyonder.co.uk> wrote:
>
>> The same thing applies to learning programming.  The best way to
>> learn C is to start by writing significant, COMPLEX, code in
>> Assembler.  You either learn self-discipline or will fail.
>
>I've no problems with that in the 80s, but has C become
>sufficiently complex that it isn't the case any more?
>I haven't programmed C recently, but the plethora of
>subtle compile and link time switches makes me suspicious
>that I wouldn't be able to determine whether or not I'd
>missed corner cases.

You wouldn't be - dammit, even I can't and I claim to be a C
expert, for my many and grievous sins :-(  But that wasn't my
point.

It would force the need for self-discipline and being able to
debug without language help, both of which are critical to C
programming.


Regards,
Nick Maclaren.

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

#1636

On Tue, 17 May 2011 12:44:14 +0100, <nmm1@cam.ac.uk> wrote:

> Because you don't think it's likely, it shouldn't be investigated?
> Hmm.

No, what I meant was that I didn't think it was at all likely that anyone  
would be able to compare like with like, or (failing that) compensate for  
the effects. On the other hand, a study that failed to do so would almost  
certainly produce results that implied "things ain't what they used to be"  
and "we're all doomed and it's the fault of the modern education system".  
We get plenty of those in the UK press without adding to the pile.

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

#1562

In article <etd1a8-dn03.ln1@ntp6.tmsw.no>,
Terje Mathisen  <"terje.mathisen at tmsw.no"> wrote:
>MitchAlsup wrote:
>>
>> I seem to recall at least one machine of my college era (circa
>> 1971-77) that did equality comparisons on Floats in such a way that if
>> the numbers were equal to within 3lsb the equality flag was set (?
>> 1108?). Thus: (1.0/3.0)*3.0 was equal to 1.0 even with (but a few)
>> rounding errors.
>
>Wow!
>
>That is a _very_ expensive default: Since the normal epsilon (1.0 -> 
>0.99999...) causes an exponent change you would have to handle this as a 
>special form of rounding and/or do a fp subtract without 
>post-normalization, masking the mantissa instead.

Not really.  All it needs is (essentially) two comparison paths,
one of the case of the same exponent and the other for difference
by one.  If either match as equal, the result is equal.  No real
difference in time, and not really much more logic.


Regards,
Nick Maclaren.

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

#1563

In article <iqlbri$7jr$1@gosset.csi.cam.ac.uk>,  <nmm1@cam.ac.uk> wrote:
>In article <etd1a8-dn03.ln1@ntp6.tmsw.no>,
>Terje Mathisen  <"terje.mathisen at tmsw.no"> wrote:
>>MitchAlsup wrote:
>>>
>>> I seem to recall at least one machine of my college era (circa
>>> 1971-77) that did equality comparisons on Floats in such a way that if
>>> the numbers were equal to within 3lsb the equality flag was set (?
>>> 1108?). Thus: (1.0/3.0)*3.0 was equal to 1.0 even with (but a few)
>>> rounding errors.
>>
>>Wow!
>>
>>That is a _very_ expensive default: Since the normal epsilon (1.0 -> 
>>0.99999...) causes an exponent change you would have to handle this as a 
>>special form of rounding and/or do a fp subtract without 
>>post-normalization, masking the mantissa instead.
>
>Not really.  All it needs is (essentially) two comparison paths,
>one of the case of the same exponent and the other for difference
>by one.  If either match as equal, the result is equal.  No real
>difference in time, and not really much more logic.

Perhaps I should clarify.  The comparison checks the sign as usual.
It then checks the exponents and divides into three paths: the
same, a difference of one, and more than one.  It then checks
the top digit (and the rules differ according to whether the
exponent matches).  If the exponents match, it scans down for
the first mismatch - if none, it matches.

So we now have a situation where the position of the first mismatch
(which may be at the origin) is known.  We then scan down the
numbers, checking for zeroes in the larger and ones in the smaller,
and the first discrepancy gives us the bit count of the relative
accuracy.  A simple calculation shows that it's within a small
constant factor of the true relative accuracy.

On a machine of that era, I doubt that was significantly slower,
though naturally it needed a bit more logic.  Not a lot, even so.


Regards,
Nick Maclaren.

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

#1567

On 5/13/2011 1:17 PM, MitchAlsup wrote:

snip

> I seem to recall at least one machine of my college era (circa
> 1971-77) that did equality comparisons on Floats in such a way that if
> the numbers were equal to within 3lsb the equality flag was set (?
> 1108?). Thus: (1.0/3.0)*3.0 was equal to 1.0 even with (but a few)
> rounding errors.

While there may have been such a machine, it certainly wasn't the 1108. 
  That machine, and its still current descendants, use the same 
registers for both integer and floating point arithmetic.  The "test" 
instructions, which are used for comparison, just work on bit patterns, 
i.e. they don't know whether what they are comparing are integers, 
floating point, or short strings or whatever.  There are no separate 
test instructions for floating point values.  Thus there couldn't be 
such a mechanism as you describe as the hardware wouldn't know when to 
apply it.


-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

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

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

Back to top | Article view | comp.arch

csiph-web