Back in 1980 or so, I bought a Heathkit H11 which was a repackaged PDP-11. It had dual 8" floppy drives. I wanted it to implement my Empire game on it, which I did, and distributed a few copies of the binary. When I later got an IBM PC with 5.25" drives, I backed up the Empire source files from the H11 by writing them out to a serial port, and using a program I wrote for the PC that read from the serial port and wrote to a floppy. So far, so good.
Eventually, I put all the PDP-11 version of the source code up on my website http://www.classicempire.com./ This year, a person who had a PDP-11 emulator tried to recompile Empire from those sources, and discovered one of the files was missing! Arggh. I had long ago copied all my 5.25 floppies to CD-ROMs, but the file wasn't there, either. I had obviously overlooked backing that one up when transferring the files to the PC. I had thrown out all my paper listings, and just had some handwritten code on notepaper (I use to write code that way, later typing it in). I gave away my H11 in the 80's, but the person I gave it to had thrown it in the trash (too bad, they are valuable collector's items now).
But I did have the old 8" floppies. If only I could read them, and if only they were even readable after 27 years. I emailed my old friend from college, Shal Farley, who now runs Cheshire Engineering. He said he had an old 11 in the back room, it had an 8" drive and an ftp server on it, but he hadn't fired it up in years. I sent him the floppies, and wouldn't ya know, it worked perfectly and he imaged the floppies (about 8 of them). Every single byte read without error! I was amazed. He was kind enough to email me the contents, and I added it to the web site. I'm grateful to Shal for rescuing my data!
When I backed up my 5.25" floppies to CD about 12 years ago, about 90% copied without errors. The ones before 1985 were nearly all thoroughly unreadable, though, which is why I figured the older 8" ones would be quite useless.
When I started out, nobody was interested in interviewing or hiring me, either. After starting my own business writing software, however, this ceased to be a problem.
Doing that would mean that, for example, all the #defines for constants in the C header file would have to be accessed via a C function. While this would make it much easier to port the D runtime library, it would have a significant deleterious effect on performance, as such could not be constant folded or optimized. This is unacceptable for a high performance systems language.
D does not attempt to use FreeBSD header files on Linux. It does not use C header files at all. The point is, for each system, the C header files have to be translated to D import files. The C header files are different on each system, and so the D import files have to be different to match.
If the D import files are correctly ported, the D user won't see any difference any more than the C user would.
Any D program can use either read/write or stdio, as D has direct access to any C functions. The D I/O functions try to layer on top of stdio functions so that the programmer can mix and match using D and stdio as he pleases, including interfacing with C routines that use C stdio.
D can directly call C functions. It is not necessary to go through thunks or some interface layer or build a DLL for the C calls.
D 2.0 can also directly call global C++ functions and C++ member functions for classes that have single inheritance.
D does have multiple inheritance for interfaces. Given that, template mixins, and the strong aggregation support, it's pretty hard to see what's left that might benefit from MI. But if you really, really must have MI, then C++ is for you.
Although bringing Digital Mars C++ to the Mac and Linux would offer several advantages (such as very fast compilation times) there probably wouldn't be enough customers to justify the expense.
The C header files for stdio on FreeBSD won't work on Linux, either, because implementations are free to innovate on that. Significant parts of implementation specific characteristics are exposed in the standard C header files, and these need to be modified for every platform.
D does not use a text preprocessor. Often what is a standard C interface relies on macros in the standard C header files, which is perfectly standard C conforming. The D interface to the standard library has to look at those macro expansions, and write them as equivalent D declarations.
Since the macro expansion text is not specified by the C standard, these all have to be gone through for each port of the D standard library. And yes, they do differ in sometimes dramatic ways.
The interface to the D standard library needs to be portable, but that doesn't mean the implementation of that library needs to be portable. Some speedups in the D I/O library are possible, for example, by taking advantage of some linux specific api functions.
I doubt that legacy C++ code will ever be rewritten in the D programming language, but D can easily replace C++ for new projects. You can do the same things in D as in C++, it's just a lot easier.
What we need is a language with C++-like performance characteristics and a C-like syntax that will feel familiar to C/C++ programmers but without all the baggage of 30+ years of C history. And we've got it. The D programming language. It's specifically designed to be a reengineering of C++.
Let's say, that Y = X1 + X2 +... + X30, with Xi±0.10.
Even without any rounding in the calculation, the result will have an error of ±0.5477225575...
But I'd represent that number as RRRR.RR±0.55, it's pointless to have any more.
I once had a similar conversation with my lead engineer. He asked me why I specified the length of one part as NN with a tolerance of +.0134 and -.0178, and didn't just round them to two places, +.01 and -.01. I answered that the part cost $10,000 to make, and parts often do come in out of spec. When that happens, they try to save those expensive parts, and bounce them back to engineering to see if they are ok anyway. By giving the widest possible tolerance range, instead of cutting it back for mere notational convenience, more parts would be acceptable, thus saving rework and reengineering costs. Avoiding roundoff increased the tolerance range from.02 to.0312, quite a jump. He accepted that, and signed off on it.
In other words, I always did the calcs to get the widest possible tolerance range, and was able to thereby cut the manufacturing cost substantially.
In the past year, I've lost count of how many performance bugs we've had from our customers. Many of them have unrealistic expectations, but their focus on speed is clear. Can you guess how many of them said our algorithms weren't accurate enough? Hint: 0.
I'm not surprised. Few engineers understand the problems with accumulated roundoff error. I'm not the only one who's noticed this, Chuck Allison runs packed seminars helping engineers understand the problem. Part of your job, as a tools vendor, is not just provide what they say they want, but to provide them with the best results possible, because YOU are supposed to understand the problem better than they do. You'll serve your customers' interests better if you help educate them about the issues and how to deal with them.
So your argument in favour of 80-bit is that incompetents who need high-accuracy calculations benefit from it?
Not everyone who is a competent physicist, scientist, or engineer, is also a top expert in floating point. Not everyone has the time to develop complex algorithms to deal with low precision arithmetic when high precision will get them the needed results with much less effort.
Fortunately, since our code places a great emphasis on portable results and on quantifying errors rather than hoping for the best,
I want to comment on that a bit further. If I ran your code on one machine with high precision, then on another machine with low precision, and the results were comparable, then that's a confidence builder in your software. It means the results are likely not affected by roundoff error. But if your code uses the same precision on all platforms, then getting the same results on different platforms would say nothing about the precision of the results.
1. The recent Intel 64 bit floating point support is all about speed. It doesn't do a thing for greater accuracy. Even in 64 bit CPU mode, the 80 bit FPU instructions are still there and still supported. D uses the x87 FPU even for 64 bit types because the intermediate results are done to 80 bit precision.
2. I'm well aware that greater precision isn't going to help with a 1000*1000 element matrix inversion, that what is needed is a better algorithm. Those better algorithms, however, are non-obvious, and great care and expertise has gone in to developing them. That doesn't help one whit, however, if you're doing a complex calculation that isn't a matrix inversion using a library built by an expert. A lot of calculations are custom algorithms written by people who simply don't have the time or expertise to deal with roundoff error. For those, extended precision helps a great deal in mitigating roundoff error problems.
3. Windows, Linux, and MacOS are on x86 boxes that have the 80 bit FPU available. Once again, if your customer has paid for an FPU with 80 bits, why should his (not your) results be dumbed down to the worst FPU you support?
4. Of course, I never blindly assumed my results weren't corrupted by roundoff error. Sanity checks, reverse calculations, and error analysis were done to check the results. If roundoff error was corrupting my results, that meant more work I had to do to find a way to fix it. More precision means fewer such problems, and more productivity.
Assuming your typical aircraft engine is ~10m across, the resolution our customers use would give a guaranteed accuracy of ~100nm. Tell me, did you design your parts to more precision than that?
Um, there's a lot more to aircraft part design than CAD drawings. Your comment shows you really don't know what's involved. But yeah, I've heard such comments from other engineers, too. Read on for what happened to them.
And actually, since I currently work in CAD, it's quite likely that the people ultimately using our maths do design critical things like aircraft parts. Fortunately, since our code places a great emphasis on portable results and on quantifying errors rather than hoping for the best, the parts they design on one system do tend to fit together with the parts they design on another, the whole lot tends to work as designed, and your chances of falling out of the sky aren't too bad.:-)
Portable wrong answers don't help one's design work. Not a bit. (They can also lead you into a false sense of security - if you're getting different answers on different machines, you know you've got a problem. The same wrong answer would be overlooked.) I've worked with engineers who did not place value on getting the most exact answers practical. I can tell you where they spent their nights and weekends - out on the shop floor, trying to figure out why their parts did not fit together, did not work, broke on the test stand, etc. Remember that 30 step calculation? It was for the stabilizer trim shutoff system. The shop mechanics, veterans of decades of new airplane design, told me it was the first one that fit together and worked dead nuts on right out of the box. All of the stuff I did calcs on fit together and worked as designed, first time. If you haven't guessed, I'm damned proud of it, too.
The round off error doesn't matter if the error introduced by round off is smaller than the error in the value. The rule of thumb I learned is that intermediate results should have one more digit than the significant digits.
That rule of thumb is a pernicous source of error if you are doing repetitive calculations. Why add more error to your results if you don't have to?
If I have two measurements, X and Y with an error of 0.1 and I calculate X+Y, it doesn't really matter that I use a representation with an error of 0.01 or 0.0001. Yes, the result of X+Y will differ but in both cases the true value will be somewhere in (X+Y)±0.2.
Now try doing a 30 step calculation, rounding off after each step. Try it with and without rounding.
The net result is that I haven't seen much demand for >64 bit floats, even though in Linux C's long double does translate to 80 bit on x86 and IPF.
You haven't seen the demand because, as this thread illustrates, few understand the problems they get into with low precision. I've seen plenty of people blindly accept the wrong floating point answers they get because they imagine computer math is perfect. The engineer I worked with simply could not understand how roundoff affected his results. He's not atypical.
As for SSE being targeted at games, the design of x87 has never been much liked because it's complex to deal with, both for the hardware implementations and for the software that uses it, mainly due to the stack based aproach.
True, but that has nothing to do with its support for extended precision.
It's being overall disfavoured by SSE2 which provides a more common flat register file. Both Linux and Windows x86-64 bit ABI rely on SSE2 for 32 and 64 bit floats. Microsoft's documentation even says that, for 64 bit applications, x87/MMX register file isn't saved across context switches, although the observed behaviour is that it does indeed save the register file.
Microsoft hasn't updated their doc, then, because they indeed have deliberately fixed it.
It's very likely that in the near future x87 performance will become a second class issue for x86 designers. Actually, Pentium 4 already did so, since it didn't implement FXCH as a "free" instruction.
Performance is for gamers where wrong answers don't matter. For numerical analysts, getting the correct answer is far, far more important than getting a quick wrong answer.
It's your language but due to all of the above I think requiring 80 bit floats places an uneeded burden on non-x86/IPF implementations and on it's future.
It doesn't require 80 bit floating point on architectures that don't have it. It requires that the greatest precision supported by the architecture must be supported.
Slashdot Mirror
Back in 1980 or so, I bought a Heathkit H11 which was a repackaged PDP-11. It had dual 8" floppy drives. I wanted it to implement my Empire game on it, which I did, and distributed a few copies of the binary. When I later got an IBM PC with 5.25" drives, I backed up the Empire source files from the H11 by writing them out to a serial port, and using a program I wrote for the PC that read from the serial port and wrote to a floppy. So far, so good. Eventually, I put all the PDP-11 version of the source code up on my website http://www.classicempire.com./ This year, a person who had a PDP-11 emulator tried to recompile Empire from those sources, and discovered one of the files was missing! Arggh. I had long ago copied all my 5.25 floppies to CD-ROMs, but the file wasn't there, either. I had obviously overlooked backing that one up when transferring the files to the PC. I had thrown out all my paper listings, and just had some handwritten code on notepaper (I use to write code that way, later typing it in). I gave away my H11 in the 80's, but the person I gave it to had thrown it in the trash (too bad, they are valuable collector's items now). But I did have the old 8" floppies. If only I could read them, and if only they were even readable after 27 years. I emailed my old friend from college, Shal Farley, who now runs Cheshire Engineering. He said he had an old 11 in the back room, it had an 8" drive and an ftp server on it, but he hadn't fired it up in years. I sent him the floppies, and wouldn't ya know, it worked perfectly and he imaged the floppies (about 8 of them). Every single byte read without error! I was amazed. He was kind enough to email me the contents, and I added it to the web site. I'm grateful to Shal for rescuing my data! When I backed up my 5.25" floppies to CD about 12 years ago, about 90% copied without errors. The ones before 1985 were nearly all thoroughly unreadable, though, which is why I figured the older 8" ones would be quite useless.
When I started out, nobody was interested in interviewing or hiring me, either. After starting my own business writing software, however, this ceased to be a problem.
Is C# on the Mac?
Doing that would mean that, for example, all the #defines for constants in the C header file would have to be accessed via a C function. While this would make it much easier to port the D runtime library, it would have a significant deleterious effect on performance, as such could not be constant folded or optimized. This is unacceptable for a high performance systems language.
D does not attempt to use FreeBSD header files on Linux. It does not use C header files at all. The point is, for each system, the C header files have to be translated to D import files. The C header files are different on each system, and so the D import files have to be different to match. If the D import files are correctly ported, the D user won't see any difference any more than the C user would. Any D program can use either read/write or stdio, as D has direct access to any C functions. The D I/O functions try to layer on top of stdio functions so that the programmer can mix and match using D and stdio as he pleases, including interfacing with C routines that use C stdio.
D can directly call C functions. It is not necessary to go through thunks or some interface layer or build a DLL for the C calls. D 2.0 can also directly call global C++ functions and C++ member functions for classes that have single inheritance.
D does have multiple inheritance for interfaces. Given that, template mixins, and the strong aggregation support, it's pretty hard to see what's left that might benefit from MI. But if you really, really must have MI, then C++ is for you.
Although bringing Digital Mars C++ to the Mac and Linux would offer several advantages (such as very fast compilation times) there probably wouldn't be enough customers to justify the expense.
I'm very curious what you think is wrong with D's const correctness and operator overloading. Reference (lvalue) returns were recently added to D 2.0.
D supports mixins which does allow you to aggregate behavior without needing multiple inheritance.
The C header files for stdio on FreeBSD won't work on Linux, either, because implementations are free to innovate on that. Significant parts of implementation specific characteristics are exposed in the standard C header files, and these need to be modified for every platform.
D does not use a text preprocessor. Often what is a standard C interface relies on macros in the standard C header files, which is perfectly standard C conforming. The D interface to the standard library has to look at those macro expansions, and write them as equivalent D declarations. Since the macro expansion text is not specified by the C standard, these all have to be gone through for each port of the D standard library. And yes, they do differ in sometimes dramatic ways. The interface to the D standard library needs to be portable, but that doesn't mean the implementation of that library needs to be portable. Some speedups in the D I/O library are possible, for example, by taking advantage of some linux specific api functions.
So you want to be a programmer? lists several courses and their value for a programming career. Foreign language comes at or near the bottom.
I doubt that legacy C++ code will ever be rewritten in the D programming language, but D can easily replace C++ for new projects. You can do the same things in D as in C++, it's just a lot easier.
D combines C++ like power and Python like productivity in one language.
Is Empire, Wargame of the Century. You can get the original PDP-10 FORTRAN source code from classicempire.com.
It's pretty easy to do Units/Dimensional Analysis in the D programming language:
physical.d
The example is by Oskar Linde.
Empire pretty much invented the strategy type computer game back in 1977, and was selected as Computer Gaming World's 1987 game of the year.
:-)
http://www.classicempire.com/
Yes, I wrote it
I once had a similar conversation with my lead engineer. He asked me why I specified the length of one part as NN with a tolerance of +.0134 and -.0178, and didn't just round them to two places, +.01 and -.01. I answered that the part cost $10,000 to make, and parts often do come in out of spec. When that happens, they try to save those expensive parts, and bounce them back to engineering to see if they are ok anyway. By giving the widest possible tolerance range, instead of cutting it back for mere notational convenience, more parts would be acceptable, thus saving rework and reengineering costs. Avoiding roundoff increased the tolerance range from .02 to .0312, quite a jump. He accepted that, and signed off on it.
In other words, I always did the calcs to get the widest possible tolerance range, and was able to thereby cut the manufacturing cost substantially.
I'm not surprised. Few engineers understand the problems with accumulated roundoff error. I'm not the only one who's noticed this, Chuck Allison runs packed seminars helping engineers understand the problem. Part of your job, as a tools vendor, is not just provide what they say they want, but to provide them with the best results possible, because YOU are supposed to understand the problem better than they do. You'll serve your customers' interests better if you help educate them about the issues and how to deal with them.
So your argument in favour of 80-bit is that incompetents who need high-accuracy calculations benefit from it?
Not everyone who is a competent physicist, scientist, or engineer, is also a top expert in floating point. Not everyone has the time to develop complex algorithms to deal with low precision arithmetic when high precision will get them the needed results with much less effort.
I want to comment on that a bit further. If I ran your code on one machine with high precision, then on another machine with low precision, and the results were comparable, then that's a confidence builder in your software. It means the results are likely not affected by roundoff error. But if your code uses the same precision on all platforms, then getting the same results on different platforms would say nothing about the precision of the results.
2. I'm well aware that greater precision isn't going to help with a 1000*1000 element matrix inversion, that what is needed is a better algorithm. Those better algorithms, however, are non-obvious, and great care and expertise has gone in to developing them. That doesn't help one whit, however, if you're doing a complex calculation that isn't a matrix inversion using a library built by an expert. A lot of calculations are custom algorithms written by people who simply don't have the time or expertise to deal with roundoff error. For those, extended precision helps a great deal in mitigating roundoff error problems.
3. Windows, Linux, and MacOS are on x86 boxes that have the 80 bit FPU available. Once again, if your customer has paid for an FPU with 80 bits, why should his (not your) results be dumbed down to the worst FPU you support?
4. Of course, I never blindly assumed my results weren't corrupted by roundoff error. Sanity checks, reverse calculations, and error analysis were done to check the results. If roundoff error was corrupting my results, that meant more work I had to do to find a way to fix it. More precision means fewer such problems, and more productivity.
Assuming your typical aircraft engine is ~10m across, the resolution our customers use would give a guaranteed accuracy of ~100nm. Tell me, did you design your parts to more precision than that?
Um, there's a lot more to aircraft part design than CAD drawings. Your comment shows you really don't know what's involved. But yeah, I've heard such comments from other engineers, too. Read on for what happened to them.
And actually, since I currently work in CAD, it's quite likely that the people ultimately using our maths do design critical things like aircraft parts. Fortunately, since our code places a great emphasis on portable results and on quantifying errors rather than hoping for the best, the parts they design on one system do tend to fit together with the parts they design on another, the whole lot tends to work as designed, and your chances of falling out of the sky aren't too bad.
Portable wrong answers don't help one's design work. Not a bit. (They can also lead you into a false sense of security - if you're getting different answers on different machines, you know you've got a problem. The same wrong answer would be overlooked.) I've worked with engineers who did not place value on getting the most exact answers practical. I can tell you where they spent their nights and weekends - out on the shop floor, trying to figure out why their parts did not fit together, did not work, broke on the test stand, etc. Remember that 30 step calculation? It was for the stabilizer trim shutoff system. The shop mechanics, veterans of decades of new airplane design, told me it was the first one that fit together and worked dead nuts on right out of the box. All of the stuff I did calcs on fit together and worked as designed, first time. If you haven't guessed, I'm damned proud of it, too.
That rule of thumb is a pernicous source of error if you are doing repetitive calculations. Why add more error to your results if you don't have to?
If I have two measurements, X and Y with an error of 0.1 and I calculate X+Y, it doesn't really matter that I use a representation with an error of 0.01 or 0.0001.
Yes, the result of X+Y will differ but in both cases the true value will be somewhere in (X+Y)±0.2.
Now try doing a 30 step calculation, rounding off after each step. Try it with and without rounding.
The net result is that I haven't seen much demand for >64 bit floats, even though in Linux C's long double does translate to 80 bit on x86 and IPF.
You haven't seen the demand because, as this thread illustrates, few understand the problems they get into with low precision. I've seen plenty of people blindly accept the wrong floating point answers they get because they imagine computer math is perfect. The engineer I worked with simply could not understand how roundoff affected his results. He's not atypical.
As for SSE being targeted at games, the design of x87 has never been much liked because it's complex to deal with, both for the hardware implementations and for the software that uses it, mainly due to the stack based aproach.
True, but that has nothing to do with its support for extended precision.
It's being overall disfavoured by SSE2 which provides a more common flat register file. Both Linux and Windows x86-64 bit ABI rely on SSE2 for 32 and 64 bit floats.
Microsoft's documentation even says that, for 64 bit applications, x87/MMX register file isn't saved across context switches, although the observed behaviour is that it does indeed save the register file.
Microsoft hasn't updated their doc, then, because they indeed have deliberately fixed it.
It's very likely that in the near future x87 performance will become a second class issue for x86 designers. Actually, Pentium 4 already did so, since it didn't implement FXCH as a "free" instruction.
Performance is for gamers where wrong answers don't matter. For numerical analysts, getting the correct answer is far, far more important than getting a quick wrong answer.
It's your language but due to all of the above I think requiring 80 bit floats places an uneeded burden on non-x86/IPF implementations and on it's future.
It doesn't require 80 bit floating point on architectures that don't have it. It requires that the greatest precision supported by the architecture must be supported.