pardo@june.cs.washington.edu (David Keppel) (07/20/88)
In article <60391@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >> [ Standardization is a GOOD THING ] >[ Would Machines X & Y become little endian, or V & Z big-endian? ] >[ Or did you mean standard disk file data formats? ] lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: >In article <76700037@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: >>[ Machines using assorted formats that RUN FASTER ] >[ 1 program, 2 machines: One converges, other diverges ] >[ When all use IEEE, always get same answer, saves debugging ] >[ Graphics: too expensive to convert formats ] >[ IEEE may be slower for "gradual underflow" ] The X window system is designed to connect simultaneously to a variety of heterogenous machines may be talking to each other at once. They have an interesting (educational) approach to dealing with some of these issues. + They don't use floating-point numbers. + They have big-endian and little-endian socket connections. This is a win over one common, say little-endian, data format. If you have two big-endian machines talking, then you avoid TWO format conversions. + To my knowledge (probably wrong) they avoid negative numbers wherever possible and insist that 0 is the two's complement 0. Some of the lessons that I read from this: + Speed IS important. + Provide alternate interfaces where possible. + Provide specialized conversion mechanisms where needed. I could immagine a package that knows about various data formats (e.g., 1's complement, various floating-point representations). When you open a connection (file) there is a data description in a standard format. You then call a routine that builds you (on the fly) a data conversion function that maps the structure you read to a structure that you can use on your machine. If the data stream is already in the right format, you don't have to do anything. This does NOT address issues about convergence and "rounding" for various floating formats. ;-D on ( Persian Gulf oil: $140/barrel after U.S. military costs ) Pardo pardo@cs.washington.edu {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo