(Late) typos in dpANS 5. 
Author Message
 (Late) typos in dpANS 5.

While personal circumstances prevented me from making formal comments
within the official period, I thought I'd post these here in the hopes
that some other reader of the Standard could set me straight, OR, that
some member or other of the Technical Committee might perhaps mention
these points at a judicious moment during the revision process.  These
points, if they are not my misunderstandings, are all, I hope, editting
and not substantive, changes.  I apologize in advance for not getting
these comment in during the formal period, and for any typos I may have
made in this message, esp. if I have mis quoted the Standard.

-Doug

a) What is a "Standard character"?  I can't seem to find a definition
for it.  Section 3.3.1.2 Definition names, paragraph 1, refers to
"non-standard characters."  In section 6.1.1320 EMIT "When passed a
character whose character-defining bits have a value between hex 20 and
7E inclusive, the corresponding Standard character, specified by
3.1.2.1 Graphic Characters, is displayed." In section 6.1.1750 KEY "All
standard characters can be received. ... Any standard character
returned by KEY has the numeric value specified in 3.1.2.1 Graphic
Characters."  That last seems to get close to defining it.  In section
6.1.2310 TYPE "When passed a character in a character string whose
character-defining bits have a value between hex 20 and 7E inclusive, the
corresponding Standard character, specified by 3.1.2.1 Graphic Characters,
is displayed."  I may have missed other references.  Can anyone point out
where "Standard character(s)" is/are defined?
    None of the sections:
            2.1.120 character
            3.1.2 Character Types
            3.1.2.1 Graphic Characters
            3.1.2.2 Control Characters
        defines "Standard character".  Table 3.2 (in section 3.1.2.1) is
        labelled "Standard graphic characters", but that has an additional
        qualifier (graphic).

b) In section 6.1.0690 ABS why is there no caveat for the smallest number
under 2s complement machines?  If there is no such caveat, how could a
2s complement machine fully comply with ABS and thereby the Standard?

c) Neither section 6.1.1250 DOES> nor section 6.1.1710 IMMEDIATE make any
reference to each other.  In section 6.1.1250 DOES> in the Execution:
paragarph, the Standard says: "Replace the execution semantics of the most
recently defined word with the name execution semantics given below."  Can
it be a valid reading of the Standard, for the sequence:
        ... CREATE ... IMMEDIATE ... DOES> ...
    that DOES> renders the word just created non-IMMEDIATE?

d) Section 6.1.2033 POSTPONE seems to be missing a reference to D.6.7
Immediacy.

e) Perhaps I missed it, but how does a Standard program determine the size
of the PAD?  Section 6.2.2000 PAD refers only to section 3.3.3.6 Other
Transient Regions.  Section 3.3.3.6 Other Transient Regions says merely
"The size of the scratch area whose address is returned by PAD shall be at
least 84 characters."  Even if a supplier of a Standard system documents
the size of the PAD, how is a Standard program to determine it?

f) Section 6.2.2148 RESTORE-INPUT refers to A.6.2.2182 SAVE-INPUT but
_not_ to 6.2.2.2182 SAVE-INPUT.

g) Section 6.2.2182 SAVE-INPUT does not refer to RESTORE-INPUT by number,
nor does it refer to A.6.2.2182 SAVE-INPUT

h) Section 9.6.1.2275 THROW in the third paragraph from the end of this
section, minus seems to be spelled "minos".

i) Section 11.3.1 Data Types (for The Optional File-Access Word Set),
why was no type added for a file position (say as used by 11.6.1.1520
FILE-POSITION)?  Surely file positions are as deserving (and as opaque a
type) as fileid?



Tue, 05 Dec 1995 10:23:51 GMT  
 (Late) typos in dpANS 5.

[...]
: b) In section 6.1.0690 ABS why is there no caveat for the smallest number
: under 2s complement machines?  If there is no such caveat, how could a
: 2s complement machine fully comply with ABS and thereby the Standard?
:
The single-cell signed numbers range for portable programs is -32767 to 32767
and *excludes* -32768 . So the overflow problem of ABS is avoided elegantly.

: c) Neither section 6.1.1250 DOES> nor section 6.1.1710 IMMEDIATE make any
: reference to each other.  In section 6.1.1250 DOES> in the Execution:
: paragarph, the Standard says: "Replace the execution semantics of the most
: recently defined word with the name execution semantics given below."  Can
: it be a valid reading of the Standard, for the sequence:
:       ... CREATE ... IMMEDIATE ... DOES> ...
:     that DOES> renders the word just created non-IMMEDIATE?
:
: d) Section 6.1.2033 POSTPONE seems to be missing a reference to D.6.7
: Immediacy.
:
c) and d) were under much discussion in the ansforth mailing list.

: e) Perhaps I missed it, but how does a Standard program determine the size
: of the PAD?  Section 6.2.2000 PAD refers only to section 3.3.3.6 Other
: Transient Regions.  Section 3.3.3.6 Other Transient Regions says merely
: "The size of the scratch area whose address is returned by PAD shall be at
: least 84 characters."  Even if a supplier of a Standard system documents
: the size of the PAD, how is a Standard program to determine it?
:
See 3.2.6 Environmental Queries
simply pass /PAD as a string to ?ENVIRONMENT

[...]
: i) Section 11.3.1 Data Types (for The Optional File-Access Word Set),
: why was no type added for a file position (say as used by 11.6.1.1520
: FILE-POSITION)?  Surely file positions are as deserving (and as opaque a
: type) as fileid?
:
See 11.2.1.390 File Position
I think you don't need an extra type as a double-cell character offset from
beginning-of-file is by nature of type ud for *every* Forth system.
However, fileid has not the same meaning over all different platforms.
It may be a file handle like C/UNIX or MSDOS or a memory address of an
identifying structure or whatever the implementor likes...




Tue, 05 Dec 1995 19:03:26 GMT  
 (Late) typos in dpANS 5.


+: b) In section 6.1.0690 ABS why is there no caveat for the smallest number
+: under 2s complement machines?  If there is no such caveat, how could a
+: 2s complement machine fully comply with ABS and thereby the Standard?

+The single-cell signed numbers range for portable programs is -32767 to 32767
+and *excludes* -32768 . So the overflow problem of ABS is avoided elegantly.

Section 3.1.3.2 Single-Cell Signed Integers reads:
        "The range of signed integers shall include {-32767..+32767}"
Section 2. Terms and Notation, in part, reads:
        "In this Standard, 'shall' states a requirement on a system or
        program; conversely 'shall not' is a prohibition;"

Section 3.1.3.2 Single-Cell Signed Integers does not "prohibit" -32768,
it merely requires -32767..+32767.  If 3.1.3.2 were to read as you
suggest, the Standard would be requiring a 16 bit cell.  But it is only
requiring _at least_ a 16 bit cell.

In addition, section 3.1.2.2 Control Characters, in part, reads:
        "Standard Programs that require the ability to send or receive
        control characters han an environmental dependency."
so why doesn't section 3.1.3.2 Single-Cell Signed Integers, in part, read:
        "Standard Programs that require a Single-Cell Signed Integer to
        contain values outside the range given have an environmental
        dependency."?

Further, it is odd that section 3.2.6 Environmental Queries only allows
one to query the the maximum value of various numeric types.  Given the
way that cell sized and double cell sized numbers are defined, the
negation of the values returned for Environmental Queries MAX-D and MAX-N
can be negated, but that doesn't tell you what the smallest allowable
signed cell sized and double cell sized numbers are.

Thanks for the quick and helpful reply (I didn't quote all the other parts
because I didn't disagree with your response).  I am esp. curious to know
how the IMMEDIATE DOES> issue is going to be resolved.  Personally, I
think those two words should refer to each other and there should be
explicit language, even if it is only to say that the interaction is
implementation-defined or ambiguous.

-Doug
-Doug



Tue, 05 Dec 1995 19:58:24 GMT  
 (Late) typos in dpANS 5.




: +: b) In section 6.1.0690 ABS why is there no caveat for the smallest number
: +: under 2s complement machines?  If there is no such caveat, how could a
: +: 2s complement machine fully comply with ABS and thereby the Standard?
:
: +The single-cell signed numbers range for portable programs is -32767 to 32767
: +and *excludes* -32768 . So the overflow problem of ABS is avoided elegantly.
:
: Section 3.1.3.2 Single-Cell Signed Integers reads:
:       "The range of signed integers shall include {-32767..+32767}"
: Section 2. Terms and Notation, in part, reads:
:       "In this Standard, 'shall' states a requirement on a system or
:       program; conversely 'shall not' is a prohibition;"
:
: Section 3.1.3.2 Single-Cell Signed Integers does not "prohibit" -32768,
: it merely requires -32767..+32767.  If 3.1.3.2 were to read as you
: suggest, the Standard would be requiring a 16 bit cell.  But it is only
: requiring _at least_ a 16 bit cell.
Agreed.
I said a portable *program* (without environmental dependencies, I should have
added) can't use -32768 . But a standard *system* may or may not support it,
especially if cell size is greater than the minimum 16bit.

:
: In addition, section 3.1.2.2 Control Characters, in part, reads:
:       "Standard Programs that require the ability to send or receive
:       control characters han an environmental dependency."
: so why doesn't section 3.1.3.2 Single-Cell Signed Integers, in part, read:
:       "Standard Programs that require a Single-Cell Signed Integer to
:       contain values outside the range given have an environmental
:       dependency."?
:
The manual is at home now, but I think somewhere is something like that.

: Further, it is odd that section 3.2.6 Environmental Queries only allows
: one to query the the maximum value of various numeric types.  Given the
: way that cell sized and double cell sized numbers are defined, the
: negation of the values returned for Environmental Queries MAX-D and MAX-N
: can be negated, but that doesn't tell you what the smallest allowable
: signed cell sized and double cell sized numbers are.
:
The idea is that we can't rely on 2'comp any longer, so limiting the minimum
range to -32767...32767 is reasonable and avoids overflow problems e.g. while
negating, as you noticed. On a 16bit 1'comp or 16bit sign-magnitude system,
which are allowed, there is no -32768 ! (anybody does such a beast? 8-)

[...]




Tue, 05 Dec 1995 22:44:08 GMT  
 (Late) typos in dpANS 5.


+Agreed.
+I said a portable *program* (without environmental dependencies, I should have
+added) can't use -32768 . But a standard *system* may or may not support it,
+especially if cell size is greater than the minimum 16bit.

Ahhh... I see that I wasn't clear, when I said:

+: +: b) In section 6.1.0690 ABS why is there no caveat for the smallest number
+: +: under 2s complement machines?  If there is no such caveat, how could a
+: +: 2s complement machine fully comply with ABS and thereby the Standard?

I was refering to a Standard system, not a Standard program.  Are you
saying that in order for a system to be a Standard system that it must
not allow the smallest number on a 2s complement machine?  If the
Standard *does* allow such a number, then there is no way a 2s
complement machine can comply with the requirement for ABS.  I think
that there was merely an oversight in the description for ABS.  Perhaps
the TC should add:  "An ambiguous condition exists for 2s complement
machines if the argument to ABS is the smallest number." or words to
that effect.  If such a condition isn't added to the description of
ABS, then there should be language added to the standard (in 3.1.3.2
Single-Cell Signed Integers) explicitly mentioning that the smallest
number *on a 2s complement machine* is unavailable.

+: In addition, section 3.1.2.2 Control Characters, in part, reads:
+:      "Standard Programs that require the ability to send or receive
+:      control characters han an environmental dependency."
+: so why doesn't section 3.1.3.2 Single-Cell Signed Integers, in part, read:
+:      "Standard Programs that require a Single-Cell Signed Integer to
+:      contain values outside the range given have an environmental
+:      dependency."?
+The manual is at home now, but I think somewhere is something like that.

It may well be buried somewhere, but I can't find it.  Given the
other mentions of environmental dependencies in 3.1, it should be
mentioned in 3.1.3.2 as well.

+The idea is that we can't rely on 2'comp any longer, so limiting the minimum
+range to -32767...32767 is reasonable and avoids overflow problems e.g. while
+negating, as you noticed. On a 16bit 1'comp or 16bit sign-magnitude system,
+which are allowed, there is no -32768 ! (anybody does such a beast? 8-)

That is my point.  You can't tell from looking at the largest number
what the smallest number is.  The Standard says that you can find the
largest number, which may or may not exceed the guaranteed minimum of
+32767, using an environmental query.  Since section 3.2.2.2 Other
Integer Operations, says:  "In all integer arithmetic operations, both
overflow and underflow shall be ignored.  The value returned when
either overflow or underflow occurs is implementation defined." there is
now way for a Standard program to compute the smallest number.

-Doug



Wed, 06 Dec 1995 00:20:34 GMT  
 (Late) typos in dpANS 5.

: I was refering to a Standard system, not a Standard program.  Are you
: saying that in order for a system to be a Standard system that it must
: not allow the smallest number on a 2s complement machine?  If the

  No.

: Standard *does* allow such a number, then there is no way a 2s
: complement machine can comply with the requirement for ABS.  I think
: that there was merely an oversight in the description for ABS.  Perhaps
: the TC should add:  "An ambiguous condition exists for 2s complement
: machines if the argument to ABS is the smallest number." or words to

Yeah, but that's the trick: Specifying -32767...32767 *avoids* that ambiguous
condition at all! More at bottom.

: that effect.  If such a condition isn't added to the description of
: ABS, then there should be language added to the standard (in 3.1.3.2
: Single-Cell Signed Integers) explicitly mentioning that the smallest
: number *on a 2s complement machine* is unavailable.
:
Whether it's available or not is to be documented by the system implementor,
not by the standard!
[...]
:
: +The idea is that we can't rely on 2'comp any longer, so limiting the minimum
: +range to -32767...32767 is reasonable and avoids overflow problems e.g. while
: +negating, as you noticed. On a 16bit 1'comp or 16bit sign-magnitude system,
: +which are allowed, there is no -32768 ! (anybody does such a beast? 8-)
:
: That is my point.  You can't tell from looking at the largest number
: what the smallest number is.  The Standard says that you can find the
: largest number, which may or may not exceed the guaranteed minimum of
: +32767, using an environmental query.  Since section 3.2.2.2 Other
: Integer Operations, says:  "In all integer arithmetic operations, both
: overflow and underflow shall be ignored.  The value returned when
: either overflow or underflow occurs is implementation defined." there is
: now way for a Standard program to compute the smallest number.
:
Again, the smallest number i.e. the most negative signed number a portable
program (w/o env. dep.) may actually use, is MAX-N or MAX-D negated!
If the program declares an environmental dependency on 2'comp, it can assume
there is also -(MAX-N)-1 ! And that triggers overflow problems...

If a program really needs the smallest number, it declares env. dep. on both
2'comp and requiring the smallest number, and voila, it may do it, and any
ambiguous condition as overflow e.g. in ABS is handled as usual i.e. ignored.
The result on overflow should be specified by the system implementor.
I would implement the standard for the "ordinary" numbers and simply test and
document what happens if used with the smallest number...

What do you expect from your old systems doing -32768 ABS but 16bit nonsense?
It might return -32768 again, it might return always 0, it might return some
random garbage that happens to be in a stack or register!




Wed, 06 Dec 1995 02:43:15 GMT  
 (Late) typos in dpANS 5.


+: Standard *does* allow such a number, then there is no way a 2s
+: complement machine can comply with the requirement for ABS.  I think
+: that there was merely an oversight in the description for ABS.  Perhaps
+: the TC should add:  "An ambiguous condition exists for 2s complement
+: machines if the argument to ABS is the smallest number." or words to
+
+Yeah, but that's the trick: Specifying -32767...32767 *avoids* that ambiguous
+condition at all! More at bottom.

The Standard says that a Single-Cell Signed Integer "shall include the
range {-32767..32767}".  It does _not_ say that -32767 is the smallest
allowable Single-Cell Signed Integer, and it does _not_ say that any
program which needs a smaller number has an environmental dependency.
In order to allow 1s complement and sign-magnitude machines the
Standard could not _require_ -32768.  But the Standard does not say
that a Standard system cannot provide it.  And if a 2s complement, 16 bit,
Standard system does provide -32768, it cannot comply with ABS the way it
is currently written.

+Again, the smallest number i.e. the most negative signed number a portable
+program (w/o env. dep.) may actually use, is MAX-N or MAX-D negated!

The Standard does not say that.  For Single-Cell Signed integer, the smallest
number that a Standard system _has_ to provide is -32767.  But, since that
is not a lower bound, but an upper one, ABS should have a warning.

+If a program really needs the smallest number, it declares env. dep. on both
+2'comp and requiring the smallest number, and voila, it may do it, and any
+ambiguous condition as overflow e.g. in ABS is handled as usual i.e. ignored.

I agree there.  It is just a small matter of having the Standard actually say that,
somewhere, and mention it in the definition of ABS.

+What do you expect from your old systems doing -32768 ABS but 16bit nonsense?
+It might return -32768 again, it might return always 0, it might return some
+random garbage that happens to be in a stack or register!

I don't expect anything in particular.  I am just trying to point out a place where I think
the Standard should be more specific.



Wed, 06 Dec 1995 05:34:46 GMT  
 (Late) typos in dpANS 5.

Quote:
>+If a program really needs the smallest number, it declares env. dep. on both
>+2'comp and requiring the smallest number, and voila, it may do it, and any
>+ambiguous condition as overflow e.g. in ABS is handled as usual i.e. ignored.
>I agree there.  It is just a small matter of having the Standard actually say that,
>somewhere, and mention it in the definition of ABS.

Rather than specifying it in ABS (it seems like it might have
implications elsewhere as well), wouldn't it be sufficient to say that
operations on numbers outside of the range {-MAX-N...MAX-N} are
undefined?
--
Chris Waters    | I think, there- | "Never look a gift horse in the mouth"



Wed, 06 Dec 1995 10:50:44 GMT  
 (Late) typos in dpANS 5.


+Rather than specifying it in ABS (it seems like it might have
+implications elsewhere as well), wouldn't it be sufficient to say that
+operations on numbers outside of the range {-MAX-N...MAX-N} are
+undefined?

Perhaps something somewhere in '3.2 The Implementation Environment' would
be appropriate, but I think there should be explicit language for ABS and
DABS as well.

-Doug



Thu, 07 Dec 1995 06:30:37 GMT  
 (Late) typos in dpANS 5.



[...]
: +Yeah, but that's the trick: Specifying -32767...32767 *avoids* that ambiguous
: +condition at all! More at bottom.
:
: The Standard says that a Single-Cell Signed Integer "shall include the
: range {-32767..32767}".  It does _not_ say that -32767 is the smallest
: allowable Single-Cell Signed Integer, and it does _not_ say that any
: program which needs a smaller number has an environmental dependency.
: In order to allow 1s complement and sign-magnitude machines the
: Standard could not _require_ -32768.  But the Standard does not say
: that a Standard system cannot provide it.  And if a 2s complement, 16 bit,
: Standard system does provide -32768, it cannot comply with ABS the way it
: is currently written.
:
I think it can comply.
If you write programs with environmental dependencies you must know what's
going on. A standard only explains standardized things.

So, assuming 16bit 2'comp, everybody should know that -32768 ABS overflows!
The standard also says that not all things can be repeated everywhere.
If at the very beginning, under general ambiguous conditions an overflow is
to be ignored, I think it's not necessary to state that for ABS explicitely.

Given a simple addition: 32767 1 + also overflows, you don't complain?
Under our assumptions, this results in -32768 .
On 16-bit sign-magn. this would be -0 and this number shouldn't exist according
to ANS Forth. 16-bit 1'comp yields -32767 . All three values aren't much useful.
Continuing the program with an undeterminate value is not a good idea.

In general, wouldn't it be sufficient to say that on overflow/underflow the
low-order bits of the truncated true result are returned?
This is what I've assumed in the above example.

However, the results after overflow still would be meaningless as different but
standard conforming systems have different interpretations!
So to have a truely portable program, over/underflows must be avoided at all,
under the most restrictive conditions. A program under development still
producing them is suspect, which is the reason I prefer hardware traps enabled,
unless it is not some sort of sequence counter which might wrap around.
Silently doing modulo 65536 arithmetik is not portable any longer, at least it
is env. dep..

: +Again, the smallest number i.e. the most negative signed number a portable
: +program (w/o env. dep.) may actually use, is MAX-N or MAX-D negated!
:
: The Standard does not say that.  For Single-Cell Signed integer, the smallest
I'll check what it says to me (at home).

: number that a Standard system _has_ to provide is -32767.  But, since that
: is not a lower bound, but an upper one, ABS should have a warning.
:
: +If a program really needs the smallest number, it declares env. dep. on both
: +2'comp and requiring the smallest number, and voila, it may do it, and any
: +ambiguous condition as overflow e.g. in ABS is handled as usual i.e. ignored.
:
: I agree there.  It is just a small matter of having the Standard actually say that,
: somewhere, and mention it in the definition of ABS.
:
: +What do you expect from your old systems doing -32768 ABS but 16bit nonsense?
: +It might return -32768 again, it might return always 0, it might return some
: +random garbage that happens to be in a stack or register!
:
: I don't expect anything in particular.  I am just trying to point out a place where I think
: the Standard should be more specific.

No. A system having the absolute minimum number range doesn't incur this.
It is therefore up to the implementor of a system allowing you to use the
'smallest number' or other environmentalities to document it's implications.
So says the Standard. Amen.




Fri, 08 Dec 1995 00:20:58 GMT  
 (Late) typos in dpANS 5.

: Rather than specifying it in ABS (it seems like it might have
: implications elsewhere as well), wouldn't it be sufficient to say that
: operations on numbers outside of the range {-MAX-N...MAX-N} are
: undefined?

I think it is indeed undefined, they now call it ambigous, but I'll read again.




Fri, 08 Dec 1995 00:23:01 GMT  
 (Late) typos in dpANS 5.


+I think it can comply.
+If you write programs with environmental dependencies you must know what's
+going on. A standard only explains standardized things.

+So, assuming 16bit 2'comp, everybody should know that -32768 ABS overflows!
+If at the very beginning, under general ambiguous conditions an overflow is
+to be ignored, I think it's not necessary to state that for ABS explicitely.

I don't think it is necessarily obvious that ABS overflows.  Certainly
thatt is the result of the obvious implementation.  But, ABS is not
required to be defined as
    : ABS  ( n -- n ) DUP <0 IF 0 SWAP - THEN ;

+Given a simple addition: 32767 1 + also overflows, you don't complain?

No.  :-)

+In general, wouldn't it be sufficient to say that on overflow/underflow the
+low-order bits of the truncated true result are returned?

In 3.2.2.2 Other Integer Operations the Standard says that "The value
returned when either overflow or underflow occurs is implementation
defined."

+Silently doing modulo 65536 arithmetik is not portable any longer, at least it
+is env. dep..

AGreed.

+: +Again, the smallest number i.e. the most negative signed number a portable
+: +program (w/o env. dep.) may actually use, is MAX-N or MAX-D negated!
+:
+: The Standard does not say that.  For Single-Cell Signed integer, the smallest
+I'll check what it says to me (at home).

Please do and cite the specific place.  I haven't been able to find it.  

+No. A system having the absolute minimum number range doesn't incur this.
+It is therefore up to the implementor of a system allowing you to use the
+'smallest number' or other environmentalities to document it's implications.
+So says the Standard. Amen.

Yes, all the implementor _has_ to do is _document_ the ranges for n, +n,
u, d, +d ud.  (From 4.1.1 Implementation Options).  But there is no way
for a Standard Program to determine the smallest usable signed (double)
integer.  The standard doesn't even require that MAX-N or MAX-D be
negatible.  And given that overflow/underflow cause implementation defined
behaviour, there is no way to compute the opposite number (because the
implementation could exit, ABORT or do anything else that a Standard
Program is not guaranteed to be able to control).

-Doug



Fri, 08 Dec 1995 05:33:40 GMT  
 (Late) typos in dpANS 5.



: +I think it can comply.
: +If you write programs with environmental dependencies you must know what's
: +going on. A standard only explains standardized things.
:
: +So, assuming 16bit 2'comp, everybody should know that -32768 ABS overflows!
: +If at the very beginning, under general ambiguous conditions an overflow is
: +to be ignored, I think it's not necessary to state that for ABS explicitely.
:
: I don't think it is necessarily obvious that ABS overflows.  Certainly
: thatt is the result of the obvious implementation.  But, ABS is not
: required to be defined as
:     : ABS  ( n -- n ) DUP <0 IF 0 SWAP - THEN ;

Also possible is
      : ABS  ( n -- n ) DUP <0 IF NEGATE THEN ;
huh, <0 or 0< ? Anyway, it is common knowledge that NEGATE being an arithmetic
base operation *can* overflow on 2'comp!
:
[...]
:
: +In general, wouldn't it be sufficient to say that on overflow/underflow the
: +low-order bits of the truncated true result are returned?
:
: In 3.2.2.2 Other Integer Operations the Standard says that "The value
: returned when either overflow or underflow occurs is implementation
: defined."
So above may be reasonable in implementation docu.
:
[...]
: +: +Again, the smallest number i.e. the most negative signed number a portable
: +: +program (w/o env. dep.) may actually use, is MAX-N or MAX-D negated!
: +:
: +: The Standard does not say that.  For Single-Cell Signed integer, the
: +I'll check what it says to me (at home).
:
: Please do and cite the specific place.  I haven't been able to find it.  

Neither me. But something like that is in A.3.1.2 Character Types:
  1) The storage unit for the character data type [...]
     must be able to contain unsigned numbers from 0 through 255.
  2) An implementation is not required to restrict character storage
     to that range, but a Standard Program ut environmental dependencies cann
    ot assume the ability to store numbers outside that range in a
     "char" 224 location.

I think a fully portable prog. w/o signed single env. dep. can't use numbers
outside -32767...32767 neither. (The above beeing an Appendix is non-normative
but is is nevertheless reasonable.) You have to check MAX-N and magically
switch to double numbers if single range is insufficient.

:
: +No. A system having the absolute minimum number range doesn't incur this.
: +It is therefore up to the implementor of a system allowing you to use the
: +'smallest number' or other environmentalities to document it's implications.
: +So says the Standard. Amen.
:
: Yes, all the implementor _has_ to do is _document_ the ranges for n, +n,
: u, d, +d ud.  (From 4.1.1 Implementation Options).  But there is no way
: for a Standard Program to determine the smallest usable signed (double)
: integer.  The standard doesn't even require that MAX-N or MAX-D be
: negatible.  And given that overflow/underflow cause implementation defined
: behaviour, there is no way to compute the opposite number (because the
: implementation could exit, ABORT or do anything else that a Standard
: Program is not guaranteed to be able to control).
:
Last first: Standard says explicit that arithmetic under/overflow is to be
ignored so it can't cause one of the general ambigous condition actions
like ABORT or so. I was wrong in my previous posting 8-(

MAX-N/MAX-D *are* always negatible without overflow! See A.3.2.1 Numbers !

And what about
 : ?2'comp ( -- flag) 1 INVERT 1+ -1 = ;
 S" MAX-N" ?ENVIRONMENT  NEGATE ?2'comp  +  CONSTANT MIN-N
 S" MAX-D" ?ENVIRONMENT DNEGATE ?2'comp M+ 2CONSTANT MIN-D
which is always valid independent of cell size and number representation!
This has *no* env. dep.! Or I'm wrong?

Since it is required for + - etc. to work with both signed and unsigned numbers
you can also check
 : ?full-single-range ( -- flag) S" MAX-U"  ?ENVIRONMENT -1   = ?2'comp AND ;
 : ?full-double-range ( -- flag) S" MAX-UD" ?ENVIRONMENT -1. D= ?2'comp AND ;
and use the -32768...32767 16bit-range only if above returns true.

I think that on any 2'comp system -32767 1 - *must* result in -32768 and
 -32768 1+ must result in -32767 regardless wether it is 16bit or wider.
If the ALU/CPU supports e.g. ADDL2 (SP)+,(SP) which is the action of + and
behaves as above, why should any system implementor do something strange with
additional instructions in order to deliver another result?

I might restrict MAX-U to MAX-N and MAX-UD to MAX-D on 32bit 2'comp VAX, which
is permitted by the standard, because the VAX has only signed divide machine
instructions. If somebody has algorithms doing unsigned divides as UM/MOD
given only signed divide with quotient and remainder, please let me know.
For multiplication this is no problem and I know how to correct 8-)

BTW, while trying to followup the first time, I lost my edits because of NEWS
crash/hang so I might not have recovered all of my brain threads confusing you.




Fri, 08 Dec 1995 23:39:35 GMT  
 (Late) typos in dpANS 5.


+: I don't think it is necessarily obvious that ABS overflows.  Certainly
+: thatt is the result of the obvious implementation.  But, ABS is not
+: required to be defined as
+:     : ABS  ( n -- n ) DUP <0 IF 0 SWAP - THEN ;

(Sheepishly):  Someone just told me that I had misread the ABS stack
diagram ( n -- n ) is _wrong_.  The diagram is ( n -- u ).  That means
that ABS might be safe, so long as as the implementors range for u
contains <smallest signed single cell integer> ABS.  Note that section
3.1.1 Data-Type Relationships only requires u to be larger than n+ but
on a 2s complement machine n+ is likely to be one smaller than
<smallest signed single cell integer> ABS.  The minimal standard
requirements in 3.1.3.2 Single-Cell Signed Integers and 3.1.3.4
Single-Cell Unsigned Integers make ABS safe.  But, there is no language
requiring that any extension to the ranges of those integers (an
environmental dependency) will satisfy ABS.  Double-Cell integers seem
to have the same trouble.  

+I think a fully portable prog. w/o signed single env. dep. can't use numbers
+outside -32767...32767 neither. (The above beeing an Appendix is non-normative
+but is is nevertheless reasonable.) You have to check MAX-N and magically
+switch to double numbers if single range is insufficient.

Given that the Standard only guarantees that range, yes.  But why then
does the Standard, which says in section 3.1.2 Character Types: "The
characters provided by a Standard System shall include the graphic
characters {32..126}, which represent graphic forms as shown in Table 3.2"
and then go on to say, in section 3.1.2.2 Control Characters: "Standard
Programs that require the ability to send or receive control characters
have an environmental dependency."  It strikes me as odd that the language
about characters and about integers is not similar.

+MAX-N/MAX-D *are* always negatible without overflow! See A.3.2.1 Numbers !

Thanks for pointing out that section.  You will note, the last
paragraph says: "There is no requirement to implement circular unsigned
arithmetic, nor to set the range of unsigned numbers to the full size of
a cell.  There is historical precedent for limiting the range of u to that
of +n, which is permissible when the cell size is greater than 16 bits."

So, if your cell size is greater than 16 bits, it may just be that ABS
cannot be satisfied if the range for u is as given in the last sentence
quoted above.  So, if the Standard writers intended that last sentence to
be true (and it is _not_ part of the Standard), then their is a conflict
with it and ABS.

-Doug



Sat, 09 Dec 1995 20:12:07 GMT  
 (Late) typos in dpANS 5.

Quote:


>>+If a program really needs the smallest number, it declares env. dep. on both
>>+2'comp and requiring the smallest number, and voila, it may do it, and any
>>+ambiguous condition as overflow e.g. in ABS is handled as usual i.e. ignored.

>>I agree there.  It is just a small matter of having the Standard actually say that,
>>somewhere, and mention it in the definition of ABS.

>Rather than specifying it in ABS (it seems like it might have
>implications elsewhere as well), wouldn't it be sufficient to say that
>operations on numbers outside of the range {-MAX-N...MAX-N} are
>undefined?

The solution is even simpler: ABS' stack effect is ( n -- u ), so

-32768 ABS U.

must result in 32768 on a 2s complement machine (one's complement specifies
unsigned numbers only up to 32767 - but the smallest number of one's
complement is -32767 either).
--
Bernd Paysan
"Late answers are wrong answers!"



Sat, 09 Dec 1995 20:59:07 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Latest 1.6.7 release works, but latest 1.7.2 doesn't

2. Excerpting dpANS - Is it OK?

3. Compliance to dpANS

4. printing dpans

5. What does DPANS stand for?

6. Examples in dpANS document

7. HTML version of DPANS-94 updated

8. New DPANS version available...

9. Citing dpANS in online help?

10. Question on DOES> in dpANS

11. execution token in dpANS-6

12. Where to get dpANS

 

 
Powered by phpBB® Forum Software