No, an uninitialized variable is by definition uninitialized by the program. In C / C++ and some other languages they are variables in "auto" (on the stack) or in a block allocated (malloced or newed) from the heap without the program explicitly initializing them. That also means the decoration is uninitialized. The whole variable (inf, sup and decoration) contains random garbage. Programming languages are unlikely to treat Interval variables significantly differently than other types, so uninitialized Interval variables will exist.
Many compilers or operating systems have some way of helping programmers with this. IBM's XLC / XLC++ / XLF compilers have had an option for decades to help debug programs by initializing auto (stack) variables to any user-specified pattern, and you can choose one that gives you invalid pointers or extremely negative integers or obviously bad character strings or signaling NaNs or whatever else you need. Similar handling for the heap has been suggested. Some other systems have essentially the same capability. An early one was the original Watfor Fortran compiler, which preinitialized all data memory to have bad parity. A bad parity word isn't a Signaling NaN but has a similar effect. Note that this sort of feature is NOT part of the language, it's a compiler and/or operating system quality of implementation issue, and it's needed by programmers to deal with real life problems in large programs.
For this to also work for 1788 does NOT require that it be part of the 1788 standard. It just requires that 1788 not prohibit it. If 1788 is implemented using 754, it can be automatically available via the compiler or OS option.
VL> The fact that they cannot be the result of an operation is one of the reasons I proposed to disallow them: this won't be a problem for the implementation.
Since they can't be produced by any 754 operation and presumably (the standard is not final yet) not by any 1788 operation, there is no advantage to disallowing them. They could only occur if the programmer is trying to find an uninitialized variable, probably already cursing and certainly cursing us if we make debugging harder by an unnecessary restriction. It WILL be a problem for the implementation if they are forbidden.
How would one implement that anyway with Intervals embedded in C, if the programmer asks the system to preinitialize memory to Signaling NaNs, and no 1788 or other operation has initialized a variable? Forbid using a useful debugging option?
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
Vincent Lefevre ---01/05/2012 04:14:49 AM---On 2012-01-04 12:15:49 -0500, Ian McIntosh wrote: > VL> Should sNaN be excluded from the Empty repre