12.6.1.2143 REPRESENT FLOATING

( c-addr u -- n flag1 flag2 ) ( F: r -- ) or ( r c-addr u -- n flag1 flag2 )

At c-addr, place the character-string external representation of the significand of the floating-point number r. Return the decimal-base exponent as n, the sign as flag1 and "valid result" as flag2. The character string shall consist of the u most significant digits of the significand represented as a decimal fraction with the implied decimal point to the left of the first digit, and the first digit zero only if all digits are zero. The significand is rounded to u digits following the "round to nearest" rule; n is adjusted, if necessary, to correspond to the rounded magnitude of the significand. If flag2 is true then r was in the implementation-defined range of floating-point numbers. If flag1 is true then r is negative.

An ambiguous condition exists if the value of BASE is not decimal ten.

When flag2 is false, n and flag1 are implementation defined, as are the contents of c-addr. Under these circumstances, the string at c-addr shall consist of graphic characters.

See:

Rationale:

This word provides a primitive for floating-point display. Some floating-point formats, including those specified by IEEE-754, allow representations of numbers outside of an implementation-defined range. These include plus and minus infinities, denormalized numbers, and others. In these cases we expect that REPRESENT will usually be implemented to return appropriate character strings, such as "+infinity" or "nan", possibly truncated.

ContributeContributions

ruvavatar of ruv [347] Behavior of `represent` when buffer length is zeroRequest for clarification2024-06-28 23:47:44

There was a recent discussion in comp.lang.forth about the behavior of represent ( c-addr u -- n flag1 flag2 ) ( F: r -- ) when the parameter at position u is zero (links: 1 , 2 ).

There are two positions regarding this case (u=0):

  1. the behavior is specified:
    • nothing is written into the buffer,
    • the significand (in the specified representation) is rounded to 0 digits after the decimal point — to an integer digit; n is adjusted correspondingly.
  2. the behavior is unclear/unspecified.

Some systems writes to the buffer (despite u is zero). Some throw an exception. Some behave according to (1).

Should we clarify the text description, or specify some other particular behavior (e.g., throw a specific exception), or declare an ambiguous condition?

If represent does not throw an exception, I would expect behavior as follows:

t{ 0.1e pad 1 represent -> 0 0 -1 }t
t{ 0.1e pad 0 represent -> 1 0 -1 }t
t{ 0.1e 0 0 represent -> 1 0 -1 }t  \ to ensure that nothing is written

It can be useful if the field width for a significand is calculated and can be zero in a program, and then only the order of magnitude for the number is shown by the program.

ruvavatar of ruv

Correction. If not exception, it should be:

t{ 0.1e pad 0 represent -> 0 0 -1 }t
t{ 0.4e pad 0 represent -> 0 0 -1 }t
t{ 0.6e pad 0 represent -> 1 0 -1 }t

Concerning 0.5e — it's unclear. Probably, it's system defined.

AntonErtlavatar of AntonErtl

The character string shall consist of the u most significant digits of the significand

So with u=0 zero characters must be written to c-addr. Any implementation that writes something there is buggy. An exception for u=0 is also a bug (and in case of Gforth this bug will be fixed).

There is no basis for any claim that the u=0 case is unclear or unspecified. And unsurprisingly, the person who claimed so presented no argument that would support such a claim. Given that, why do you request clarification? I don't think that the person who makes such claims will be swayed any more by an answer to such a request than by the clear wording cited above.

But given that this has been brought up, we should add at least one test case that tests u=0. These test cases should also check that nothing is written at c-addr in that case. So your test cases are not quite there.

Closing this because it is clearly specified.

Closed
Reply New Version