Re: [Flightgear-devel] Purpose of the Next Release?
Jonathan Polley wrote: My C training goes back to circa 1985, at which time all floats were passed as doubles. Yes, they were. In fact, the modern C/C++ compilers to which I have access still do this (I don't use gcc, except to rebuild FlightGear). Oh? Which compilers? All floating-point co-processors do their work in extended precision (usually 80-96 bits) and shorten the numbers back to the range desired by the user, Certainly some do. I'm pretty sure that not all do, at least not for functions that can be done significantly faster at lower precision. and the single-precision math libraries I have used just cast the results of the double-precision routines to be single-precision (it saves on duplicated code). At work we use an Intermetrics C compiler (Intertools for NEC V20 series processors) that is supplied with a standard software floating-point library that includes separate single and double-precision versions of most of the routines. There is also an alternate version of the library which uses the same data sizes (4 and 8 bytes) but does not calculate to the full accuracy, and is considerably faster. You can choose the most appropriate library for your application. I must be older than anyone else here, but my collegiate C training drove home the fact that mixing integer and floating-point can give you unpredictable results. Granted, this was pre-ANSI C. Maybe it was unpredictable before standardisation, but I feel that's unlikely; I don't have the original (KR) reference book to check. Another possibility is that the teacher couldn't predict the results because he/she didn't know the language well enough ... that's quite common, unfortunately. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Purpose of the Next Release?
On Wednesday, April 17, 2002, at 07:45 PM, Julian Foad wrote: Jonathan Polley wrote: My C training goes back to circa 1985, at which time all floats were passed as doubles. Yes, they were. In fact, the modern C/C++ compilers to which I have access still do this (I don't use gcc, except to rebuild FlightGear). Oh? Which compilers? We use Rational Ada/C for our embedded development. Their C compiler passes passes floats as doubles for C, but will pass a Float as a single, Long_Float as double, in Ada (nothing like consistency). We get burned by that every so often. This is primarily for Solaris (were our simulation environment runs), so it may be a Sun convention as well. I believe I have also seen this interaction between the Aonix Ada compiler and MSVC. I tend to see these problems due to our mixed language development. [...] Maybe it was unpredictable before standardisation, but I feel that's unlikely; I don't have the original (KR) reference book to check. Another possibility is that the teacher couldn't predict the results because he/she didn't know the language well enough ... that's quite common, unfortunately. My C profs were a couple of C hackers form ATT Bell Labs. Given what their area of research was (data communication), I don't think this was the issue. My main purpose for the single- vs. double-precision question was this: On this program, given its hardware requirements, does it make sense to work with single-precision floating point numbers? In our case, there will be no speed improvement (all platforms need FPUs) and the space savings is negligible. The other issues are just personal whininess. My primary job is supporting avionics software development. Because it is written in Ada, and my work has become mostly C, I get to deal with many strange forms of interaction. Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Purpose of the Next Release?
Jonathan Polley wrote: ... Aside from removing unreferenced variables, the bulk of the changes were in the area of the use of floating-point. Since C does all passing of floats as doubles, and does all math in double, could we have a mandate that all floating-point valued be double? I can see it being a pain for the programmer to always add the 'f' at the end of float constants, just go get around the compiler warnings. No: C (since about 1995) and C++ do not pass all floats as doubles and do not do all (floating) math in double. If the result is going to be converted back to float, the compiler is allowed to to the calculation in float precision. Adding f to constants is a pain, I agree. Some compilers can be told to choose the appropriate type for unsuffixed constants in this situation. While on the subject of floating-point, I will get on one of my soap boxes. Taking 5/2.0 may not always yield the result you intend. I would suggest using 5.0/2.0 or, if you really want the integer result, floor(5.0/ 2.0) and ceil(5.0/2.0). The C/C++ programmer will intend the result to be 2.5. This is defined by the standard arithmetic conversion rules of C/C++. What do you think might happen instead? I highly recommend Stroustrup's book The C++ Programming Language. It explains everything. Another personal nit is the lack of a leading zero on numbers 1.0 (I prefer seeing 0.5 rather than .5). Is there a general preference for FlightGear? I prefer the leading zero too, but I don't think there is a strong reason to persuade everyone to use it. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Purpose of the Next Release?
On Tuesday, April 16, 2002, at 11:54 PM, Julian Foad wrote: Jonathan Polley wrote: ... Aside from removing unreferenced variables, the bulk of the changes were in the area of the use of floating-point. Since C does all passing of floats as doubles, and does all math in double, could we have a mandate that all floating-point valued be double? I can see it being a pain for the programmer to always add the 'f' at the end of float constants, just go get around the compiler warnings. No: C (since about 1995) and C++ do not pass all floats as doubles and do not do all (floating) math in double. If the result is going to be converted back to float, the compiler is allowed to to the calculation in float precision. Adding f to constants is a pain, I agree. Some compilers can be told to choose the appropriate type for unsuffixed constants in this situation. My C training goes back to circa 1985, at which time all floats were passed as doubles. In fact, the modern C/C++ compilers to which I have access still do this (I don't use gcc, except to rebuild FlightGear). All floating-point co-processors do their work in extended precision (usually 80-96 bits) and shorten the numbers back to the range desired by the user, and the single-precision math libraries I have used just cast the results of the double-precision routines to be single-precision (it saves on duplicated code). While on the subject of floating-point, I will get on one of my soap boxes. Taking 5/2.0 may not always yield the result you intend. I would suggest using 5.0/2.0 or, if you really want the integer result, floor(5. 0/ 2.0) and ceil(5.0/2.0). The C/C++ programmer will intend the result to be 2.5. This is defined by the standard arithmetic conversion rules of C/C++. What do you think might happen instead? I must be older than anyone else here, but my collegiate C training drove home the fact that mixing integer and floating-point can give you unpredictable results. Granted, this was pre-ANSI C. Another personal nit is the lack of a leading zero on numbers 1.0 (I prefer seeing 0.5 rather than .5). Is there a general preference for FlightGear? I prefer the leading zero too, but I don't think there is a strong reason to persuade everyone to use it. There is quite a bit to be said about consistency. - Julian Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Purpose of the Next Release?
Jonathan Polley writes: I must be older than anyone else here, but my collegiate C training Nah, If you had 'C' courses in college you are just a 'pup' :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Purpose of the Next Release?
Jonathan Polley wrote: I can easily submit patches for the more obvious errors (eliminating unreferenced local variables, adding some type casts), but I don't feel Well, that can be problemeatic, since it might hide other problems if changed without knowing the code well enough ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Purpose of the Next Release?
On Sunday, April 14, 2002, at 03:42 AM, Erik Hofman wrote: Jonathan Polley wrote: I can easily submit patches for the more obvious errors (eliminating unreferenced local variables, adding some type casts), but I don't feel Well, that can be problemeatic, since it might hide other problems if changed without knowing the code well enough ... That is why I would avoid the FDMs. Most of the others are very easy to fix, as they are returning integers as booleans, converting doubles to floats, etc. There are a few instances, converting floats to boolean or void* to boolean, that I wouldn't touch with a ten foot pole. The biggest problem with having someone, such as myself, making the patches is that it will take just as long, or longer, to incorporate the patch as it would to make the original change. My preference would be to have me keep the list fo MSVC build errors up-to-date and come up with a deadline when certain errors will be fixed (especially the ones in FDM\LaRCsim\ls_model.c). Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Purpose of the Next Release?
I will volunteer for making the MSVC patches for all the areas but panel.cxx and the FDMs. The file panel.cxx has NONE defined as a macro and the chance is too high for me to mess something up in the FDMs (and they are under active development). I will also not touch type mismatches such as: 'class ssgBranch *' : forcing value to bool 'true' or 'false' Should I submit patches to you, files to Curt, or submit the patches to the group? If I am to submit patches, I would like a test run just to make sure I have the process down (I use WinCvs, and its diff output doesn' t look like I am use to seeing from others). If the FDM people think they can trust me, I can give them patches for fixing the type mismatches. There are four cases where not all control paths are covered in a function. I assume that I should not touch these, either. Jonathan Polley On Sunday, April 14, 2002, at 12:35 PM, David Megginson wrote: Jonathan Polley writes: My preference would be to have me keep the list fo MSVC build errors up-to-date and come up with a deadline when certain errors will be fixed (especially the ones in FDM\LaRCsim\ls_model.c). Patches are best (for me; full files if you send to Curt). If you simply tell me about an error message, I cannot be sure that I've fixed it correctly; if you send me a patch that eliminates the error under MSVC, I can test it under GCC as well, and the commit if there are no problems (and then make any fixes Erik sends in for Irix, and then repeat the cycle). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Purpose of the Next Release?
Jonathan Polley writes: The file panel.cxx has NONE defined as a macro Actually, the file explicitly *un*defines NONE as a macro so that it won't interfere with properly-scoped enumerated values from elsewhere. I don't know if that's still necessary -- it's worth a quick test. 'class ssgBranch *' : forcing value to bool 'true' or 'false' Should I submit patches to you, files to Curt, or submit the patches to the group? If I am to submit patches, I would like a test run just to make sure I have the process down (I use WinCvs, and its diff output doesn' t look like I am use to seeing from others). Feel free to submit patches to try to fix anything, even in the FDMs, etc.. We'll look at them first (no blind commits) and will bounce them back at you if we think you're wrong. We have no way to know what does and doesn't work with MSVC, so patches are essential. Please send patches/files to Curt or me for most of the FlightGear and SimGear tree. Send them to Andy Ross for YASim, and to Tony Peden or Jon Berndt for JSBSim. Curt, John Check, and I can handle patches for the base package as well, if necessary. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Purpose of the Next Release?
At 4/14/02, you wrote: I will volunteer for making the MSVC patches for all the areas but panel.cxx and the FDMs. The file panel.cxx has NONE defined as a macro and the chance is too high for me to mess something up in the FDMs (and they are under active development). I will also not touch type mismatches such as: 'class ssgBranch *' : forcing value to bool 'true' or 'false' Should I submit patches to you, files to Curt, or submit the patches to the group? If I am to submit patches, I would like a test run just to make sure I have the process down (I use WinCvs, and its diff output doesn' t look like I am use to seeing from others). If the FDM people think they can trust me, I can give them patches for fixing the type mismatches. There are four cases where not all control paths are covered in a function. I assume that I should not touch these, either. Yes, we'd like that on the LaRCsim/UIUC side. Patches should be sent to Curt because we don't update on a regular basis. Jonathan Polley On Sunday, April 14, 2002, at 12:35 PM, David Megginson wrote: Jonathan Polley writes: My preference would be to have me keep the list fo MSVC build errors up-to-date and come up with a deadline when certain errors will be fixed (especially the ones in FDM\LaRCsim\ls_model.c). Patches are best (for me; full files if you send to Curt). If you simply tell me about an error message, I cannot be sure that I've fixed it correctly; if you send me a patch that eliminates the error under MSVC, I can test it under GCC as well, and the commit if there are no problems (and then make any fixes Erik sends in for Irix, and then repeat the cycle). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Purpose of the Next Release?
I have FlightGear building without warnings under MSVC, with the following exceptions: FDM/ExternalNet.cxx has two byte-order conversion on bool. What size is bool? I know, I could instrument the code, but it is getting late. FDM/UIUCModel/uiuc_menu.cpp: the check_float() function doesn't look right, to me. FDM/LaRCSim/ls_model.c has some symbols that need to be added to a header, somewhere. Cockpit/hud.hxx defines NONE as a macro. Could the #defines in there be made into enumerations? Aside from removing unreferenced variables, the bulk of the changes were in the area of the use of floating-point. Since C does all passing of floats as doubles, and does all math in double, could we have a mandate that all floating-point valued be double? I can see it being a pain for the programmer to always add the 'f' at the end of float constants, just go get around the compiler warnings. While on the subject of floating-point, I will get on one of my soap boxes. Taking 5/2.0 may not always yield the result you intend. I would suggest using 5.0/2.0 or, if you really want the integer result, floor(5.0/ 2.0) and ceil(5.0/2.0). Another personal nit is the lack of a leading zero on numbers 1.0 (I prefer seeing 0.5 rather than .5). Is there a general preference for FlightGear? Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Purpose of the Next Release?
I know that there was some discussion on this topic just after the 0.7.9 release, but I don't remember the outcome (or if there was one). Will the next release be feature adding, or bug squashing, release? The reason that I am asking is because of the warnings that I see begin generated by MSVC (and some in gcc, but MSVC is one of the more pedantic compilers I have seen). Most warnings are rather benign, unreferenced local variables, some are a bit stronger, type mismatches between int and bool or signed and unsigned versions of the same type. A few warnings do concern me and, although they are mainly type conversions to boolean that are not integral, a couple are due to not having all control paths covered in some functions. A list of the warnings can be found at: http://homepage.mac.com/eq_fidget/FlightGearErrors.html Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Purpose of the Next Release?
Jonathan Polley writes: I know that there was some discussion on this topic just after the 0.7.9 release, but I don't remember the outcome (or if there was one). Will the next release be feature adding, or bug squashing, release? The reason that I am asking is because of the warnings that I see begin generated by MSVC (and some in gcc, but MSVC is one of the more pedantic compilers I have seen). Most warnings are rather benign, unreferenced local variables, some are a bit stronger, type mismatches between int and bool or signed and unsigned versions of the same type. A few warnings do concern me and, although they are mainly type conversions to boolean that are not integral, a couple are due to not having all control paths covered in some functions. Melchior recently did an excellent job chasing down problem reports from valgrind and submitting patches to fix them. We need brave volunteers to do the same thing in a couple of other contexts: 1. Build with -wall (preferably using g++ 3.*) and fix every warning; ditto for MSVC on the highest warning level. 2. Enable all FPUs and submit patches to make FlightGear FPU-clean. Both are incremental rather than big-bang jobs. Any takers? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Purpose of the Next Release?
On Saturday, April 13, 2002, at 02:39 PM, David Megginson wrote: Jonathan Polley writes: I know that there was some discussion on this topic just after the 0.7.9 release, but I don't remember the outcome (or if there was one). Will the next release be feature adding, or bug squashing, release? The reason that I am asking is because of the warnings that I see begin generated by MSVC (and some in gcc, but MSVC is one of the more pedantic compilers I have seen). Most warnings are rather benign, unreferenced local variables, some are a bit stronger, type mismatches between int and bool or signed and unsigned versions of the same type. A few warnings do concern me and, although they are mainly type conversions to boolean that are not integral, a couple are due to not having all control paths covered in some functions. Melchior recently did an excellent job chasing down problem reports from valgrind and submitting patches to fix them. We need brave volunteers to do the same thing in a couple of other contexts: 1. Build with -wall (preferably using g++ 3.*) and fix every warning; ditto for MSVC on the highest warning level. I would be glad to do the work for MSVC, but enabling the highest warning level generates warnings that I have no hope of understanding (the default is W3, and the highest level is W4), as it complains about usage that is inside STL, etc. I can easily submit patches for the more obvious errors (eliminating unreferenced local variables, adding some type casts), but I don't feel that I can supply patches for the FDMs. I can, if people would like, keep an up-to-date list of of the MSVC errors available at: http://homepage.mac.com/eq_fidget/FlightGearErrors.html 2. Enable all FPUs and submit patches to make FlightGear FPU-clean. Both are incremental rather than big-bang jobs. Any takers? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
