Waldek Hebisch wrote:
Frank Heckenbach wrote:
Emil Jerabek wrote:
On Sun, Aug 31, 2003 at 06:49:43AM +0200, Frank Heckenbach wrote:
I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/.
[...]
- `pow' and `**' are EP conformant now (in particular `x pow y = (1 div x) pow (Ây)' if `y' is negative and `x <> 0') (fjf908.pas)
According to the standard, `x pow y' and `x ** y' should be an error if x = 0 and y <= 0 (in fact, there is no sensible value to return in these cases). This (mostly) worked in the old implementation, but it doesn't any more.
Unless I'm missing something, the standard seems to contradict itself:
: 6.8.3.2 : : [...] : : A factor of the form x**y shall be an error if x is zero and y is less than : or equal to zero.
Like you say.
: A factor of the form x**y, where x is of integerÂtype or : realÂtype, shall be an error if x is negative; otherwise, the : value of x**y shall be zero if x is zero, else [...]
Like I implemented it.
I think that the standard really means:
if (x = 0) and (y <= 0) then do_anything (* error *);
if is_integer_or_real(x) then if (x < 0 ) then do_anything (* error *) else if x = 0 then result := 0.0 else if y = 0 then result := 1.0 else result := exp(y*log(x));
if is_complex(x) then if x = 0 then result := 0.0 else if y = 0 then result := 1.0 else result := exp(y*log(x));
Why?
3.2 Error
A violation by a program of the requirements of this International that a processor is permitted to leave undetected.
So statements about errors are obligation on source program,
I don't think so. 3.2, Note 1:
: 1 If it is possible to construct a program in which the violation or : nonÂviolation of this standard requires knowledge of the data read by the : program or the implementation definition of implementationÂdefined features, : then violation of that requirement is classified as either a : dynamicÂviolation or an error.
(And this case certainly belongs to this class, since it depends on the actual values of the operands.)
For obligations on the source code, the standard uses the term "shall", and does not classify them as errors or dynamicÂviolations. The difference between errors and dynamicÂviolations seems to be that an implementation may leave (certain) errors undetected, but not dynamicÂviolations (when they're reached at runtime).
and error in source program (IMHO) effectively voids requrement on implementation to deliver results. So `otherwise' is not needed. The first line about error is clearly intended to apply both to real and to complex case. Putting an `otherwise' between first line and the second statement would limit the scope of first line only to real case.
They'd have to change the formulation somewhat to make it apply to both cases, but that shouldn't be an excuse for ambiguousness.
By the way, the standard is rather careful to specify correct mathematical results, and without first line the result would be incorrect.
The only way I could make sense of it is that a (runtime) error takes precedence of value requirements (though I'm not sure if/where this is actually stated), so an implementation which detects this error wouldn't be concerned about the value requirement.
However, it would also be correct (according to 3.2) to leave this error undetected. Then, AFAICS, the value requirement would become effective, and the value would have to be 0. This is what GPC currently does, though I agree it's not really useful mathematically.
It would also mean that yielding NaN, as Jean-Pierre Vial suggested, would be incorrect in any case.
Frank