Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #43945 > unrolled thread

RfD: D>F and S>F second draft

Back to article view | Back to comp.lang.forth

Contents

  RfD: D>F and S>F second draft C G Montgomery <cgm@physics.utoledo.edu> - 2015-11-29 17:19 -0500
    Re: D>F and S>F second draft "HAA" <someone@microsoft.com> - 2015-12-06 13:02 +1100
      Re: D>F and S>F second draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-06 03:28 +0100
        Re: D>F and S>F second draft "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-12-06 04:01 -0500
      Re: D>F and S>F second draft Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-06 02:27 +0000
        Re: D>F and S>F second draft krishna.myneni@ccreweb.org - 2015-12-06 12:55 -0800
    RfD: D>F and S>F second draft krishna.myneni@ccreweb.org - 2015-12-06 10:18 -0800
      RfD: D>F and S>F second draft krishna.myneni@ccreweb.org - 2015-12-06 10:55 -0800
        Re: RfD: D>F and S>F second draft "Elizabeth D. Rather" <erather@forth.com> - 2015-12-06 09:31 -1000
          Re: RfD: D>F and S>F second draft Paul Rubin <no.email@nospam.invalid> - 2015-12-06 11:48 -0800
            Re: RfD: D>F and S>F second draft krishna.myneni@ccreweb.org - 2015-12-06 12:15 -0800
              Re: RfD: D>F and S>F second draft "Elizabeth D. Rather" <erather@forth.com> - 2015-12-06 14:57 -1000
          Re: RfD: D>F and S>F second draft krishna.myneni@ccreweb.org - 2015-12-06 12:07 -0800
            Re: RfD: D>F and S>F second draft C G Montgomery <cgm@physics.utoledo.edu> - 2015-12-06 20:04 -0500

#43945 — RfD: D>F and S>F second draft

Author:

Charles G. Montgomery <cgm@physics.utoledo.edu>

Changes from first draft:

A few minor rewordings, non-normative.
New Comments on integers outside range of floating-point values.

Problem:

The current Forth Standard specification for D>F states that an ambiguous 
condition
exists if the double number D cannot be precisely represented as a 
floating-point
value.
Similarly, the specification for S>F calls for an ambiguous condition if 
the single
number N can not be precisely represented as a floating-point value.

The purpose of this proposal is to eliminate these ambiguous conditions by 
instead specifying that if no floating-point value is precisely equivalent 
to the provided integer the word provides the floating-point value which 
is closest to the integer.

This is the behavior provided by some Standard Forth systems, and is often 
what is most useful for the programmer.

Preliminary Remarks:

While Forth is largely untyped, it recognizes the distinction between 
integer and floating-point values.  Section 12.3.1.2 says "The internal 
representation of a floating-point number, including the format and 
precision of the significand and the format and range of the exponent, is 
implementation defined."  This seems to presume that the representation of 
a floating-point value is of the form
    (significand) * (base)^(exponent)  
where (significand), (base), and (exponent) are integers.  Since Section 
12.3.2 refers to the "least significant bit" in defining "round to 
nearest", (base) is presumably 2.
I am not aware of any Forth which is not consistent with these 
presumptions.
So the "representable values" of floating-point numbers is a countable 
subset of the uncountable real numbers.

Integers in Forth may be signed or unsigned.  Floating point values are 
almost invariably signed, so (significand) includes a sign.  D in D>F is 
presumably signed.

Proposal:

In 2.6.1.1130 D>F  (d -- )(F: -- r) replace 
"r is the floating point equivalent of d.  An ambiguous condition exists 
if d cannot be precisely represented as a floating-point value"
with
"r is the floating-point value which is nearest to d in the sense of 
'round to nearest' as given in 12.3.2."

In 12.6.2.2175 S>F  (n -- )(F: -- r) replace 
"r is the floating-point equivalent of the single-cell value n.  An 
ambiguous condition exists if n can not be precisely represented as a 
floating-point value."
with
"r is the floating-point value which is nearest to n in the sense of 
'round to nearest' as given in 12.3.2."

Remove the documentation requirements in section 12.4.1.2 for the no 
longer existing ambiguous conditions from D>F and S>F.

Further Remarks:

D>F is in the FLOATING word set; S>F is in the FLOATING EXT word set.

The reverse operations, F>D and F>S, are unchanged.  For each, the 
Standard includes a note pointing out that rounding a floating-point value 
before using them may be desirable.

No change is needed for the possibly relevant words >FLOAT and REPRESENT.

It remains easy to determine whether the conversion between floats and 
integers is exact, by comparing an initial integer value with the result 
of D>F F>D or S>F F>S.

Implementation and Testing:

For any system which provides the FLOATING and FLOATING EXT word sets and 
does not already comply with this proposal it should not be difficult to 
implement.
Whether floating-point support is in hardware or software, if FROUND and 
similar words can be provided it should be no harder to provide the 
proposed behavior of D>F and S>F.

The intentional flexibility of the Standard in specifying floating point 
internal representations makes it difficult to provide tests which have 
universal applicability to all Standard systems.

Comments:

Discussion has called attention to the situation where an integer lies
outside the range of representable floating-point values.
This proposal clearly calls for the valid extreme floating-point value.
A Standard System could not return something like "inf" or "nan".
The Forth Standard does not address the use of things like "nan" or "+-
inf", which can be useful if they are available from a floating-point
implementation.
To comply with this proposal, a system might need to test for the 
condition and provide the required result as the default.  At the cost of 
one more word in the dictionary, another version could be retained as 
available.
A Standard Program should have no problem in testing for the condition and
taking any desired action. 

An alternative, which I like less but could accept, would be to add to 
both D>F and S>F "An ambiguous condition exists if the integer value lies
outside the range of representable floating point values."
The documentation requirement for this could be considered as included
already in 12.4.1.2 under
  "floating point result out of range (e.g.,in 12.6.1.1430 F/)"
or a separate entry could be devised.

(  end of RfD  )

Regards to all   cgm

[toc] | [next] | [standalone]

#44098 — Re: D>F and S>F second draft

C G Montgomery wrote:
> Author:
>
> The purpose of this proposal is to eliminate these ambiguous conditions by
> instead specifying that if no floating-point value is precisely equivalent
> to the provided integer the word provides the floating-point value which
> is closest to the integer.
>
> This is the behavior provided by some Standard Forth systems, and is often
> what is most useful for the programmer.

Your repeat the assertion on which your proposal rests but where is the
evidence?

There will be cases where D>F cannot provide a numerically correct result
due to lack of precision.  Occassionally a programmer won't care at the
loss of precision but I wouldn't call this typical or "most useful".  Nor would
I impose it on systems.

It is true most systems behave the way you describe but I suggest it is
done because it is the easiest - not because it is "useful".  ANS currently
entitles systems to choose their response under exceptional conditions
and I see no reason or advantage in changing it.  Quite the reverse.

Bernd has likened those who disagree with your proposal as trolls who
need clubbing.  On the contrary I provide it because Forth deserves
respect.  If a proposal limits the options available to systems with no
demonstrable advantage, then it should properly be rejected.

[toc] | [prev] | [next] | [standalone]

#44099 — Re: D>F and S>F second draft

HAA wrote:
> Bernd has likened those who disagree with your proposal as trolls who
> need clubbing.

No, that was related to you saying he did not respond to you.  In a 
newsgroup you can chose to ignore people who you think are trolls, and I 
said there's no duty to club them down.  That means: anybody is allowed to 
respond to perceived trolls by ignoring them.

So if you feel being ignored, it's maybe that you raise too many troll 
alerts; that's what I wanted to say.  But given your other argumentation, 
such complicated conversation requiring humor and knowledge of Usenet 
culture wasn't a good idea.

> On the contrary I provide it because Forth deserves
> respect.  If a proposal limits the options available to systems with no
> demonstrable advantage, then it should properly be rejected.

The advantage is for the programmer, who now can depend on a particular 
popular behavior, as opposed to an ambiguous condition, which can do 
anything, and therefore makes all programs that might trigger that condition 
(which depends on the actual precision of floating point use) non-portable.  
When some particular behavior is very popular, it's very difficult to test 
against different implementations (they are rare and hard to come by), and 
the popularity itself tells you that this is "common practice".  A standard 
body should identify common practice, and codify it.  This is of course 
always at the cost of unommon practice, which still may exist - a consensus 
doesn't need to be 100%, 90% is good enough.

And, if your program needs a checking version (you really want it that way), 
you can actually implement that portably with the proposal.  As system 
implementer, you can still provide a performance-optimized checking version, 
e.g. under a different name.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#44101 — Re: D>F and S>F second draft

On Sat, 05 Dec 2015 21:28:22 -0500, Bernd Paysan <bernd.paysan@gmx.de> wrote:

> HAA wrote:

It seems to me HAA asked a serious question.

What do you do with non-portable or imprecise behavior?  Do you define it
in an unlikely attempt to make it portable?  Do you define it and introduce
potential numberical errors on some or all systems?  Do you leave it as
ambiguous so that it causes programs to not always work correctly or fail
when ported?  Do you disadvantage one system versus another by either
defining or not defining?  Do you cause programs to abort unexpectedly
for undefined behavior?  Do you allow programs to continue to function
albeit with errors?

Damned if you do.  Damned if you don't.  Catch-22.

>> Bernd has likened those who disagree with your proposal as trolls
>> who need clubbing.
>
> No, that was related to you saying he did not respond to you.

First, HAA understood that you meant that he and others here are trolls:
"He appears to be leaving that job to you."  I.e., you, Bernd, clubbed
HAA like a poor little baby seal staring up at you with big, innocent,
sad, teary eyes ...

Second, HAA was correct here.  You said, "beat *all* [of] the trolls
to death," not just one of them. (emphasis, correction added)  HAA
is just one guy and can't possibly be "all" of the trolls who are
likely to eventually respond to C.G. Montgomery.  We all know that
you responded, and we suspect Hugh will respond at some point too.

> In a newsgroup you can chose to ignore people who you think are
> trolls, and I said there's no duty to club them down.  That means:
> anybody is allowed to respond to perceived trolls by ignoring them.

Just how does someone distinquish not being responded to because the
person has nothing more to say, has quit in anger, or perhaps died,
 from someone being intentionally ignored or being given the silent
treatment for having opposing viewpoints?  Silence serves no purpose
when being done intentionally because no one knows your true intent.
Is it good, bad, indifferent, angry, hurt, or what?  It's silence.

Unlike at home or work or school, in a usenet group, no one is going
to ask you why you're being quiet because no one will even notice.
Silence is golden, especially in a noisy room.  So, you might as well
be holding a grudge with a tree.  The tree won't know you're angry
with it.  People are scapegoated and attacked behind their backs all
the time because no one bothers to ask them if they were the culprit
or no one tells them when they're being blamed for something.  So,
you're denied the fair chance to defend yourself.  In this sense,
silence is just about as evil as lying.  Lying and silence both
create victims.

How is not responding to someone, by ignoring them, actually a
response to them? (rhetorical)  If you do nothing, where is the
response?  Since when is a lack of a response, a response?  ...
I agree that a lack of a decision is still a decision, because a
decision doesn't require something to actually be done in reality,
unlike a response.

Does *not* responding to supposed trolls *do* anything to actually
*make* them leave?  I think not ...

So, it seems you went off-topic again, into non-Forth territory.
This time on clubbing, (other) trolls, being ignored, lack of
humor, "knowledge" as a euphemism for "ignorance" much like three
letter agencies use "intelligence" as a euphemism for "information,"
etc.  It's clearly not the first time you have, and most likely
not the last.  Every time you do, it offers me opportunities to
show you my take on what reading your anti-American, distorted
world perspective, incorrect history, off-topic posts are like.

Thank you so much!


Rod Pemberton


-- 
How to kill Facebook.  Tell a bunch of fourth graders that
only old people use Facebook.  Wait eight years.

[toc] | [prev] | [next] | [standalone]

#44100 — Re: D>F and S>F second draft

"HAA" <someone@microsoft.com> writes:

>C G Montgomery wrote:
>> Author:
>>
>> The purpose of this proposal is to eliminate these ambiguous conditions by
>> instead specifying that if no floating-point value is precisely equivalent
>> to the provided integer the word provides the floating-point value which
>> is closest to the integer.
>>
>> This is the behavior provided by some Standard Forth systems, and is often
>> what is most useful for the programmer.

>Your repeat the assertion on which your proposal rests but where is the
>evidence?

>There will be cases where D>F cannot provide a numerically correct result
>due to lack of precision.  Occassionally a programmer won't care at the
>loss of precision but I wouldn't call this typical or "most useful".  Nor would
>I impose it on systems.

The very fact that she is willing to store a number in a floating
point presentation means that the programmer is accepting loss of precision.
Can we finally put this item to rest?

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#44115 — Re: D>F and S>F second draft

On Saturday, December 5, 2015 at 8:40:02 PM UTC-6, Albert van der Horst wrote:
> "
> The very fact that she is willing to store a number in a floating
> point presentation means that the programmer is accepting loss of precision.
> Can we finally put this item to rest?
> 
> Groetjes Albert
>

Precisely and to the point!

Cheers,
Krishna

[toc] | [prev] | [next] | [standalone]

#44107

Although the wording,

"that if no floating-point value is precisely equivalent to the provided integer",

still gives me pause, I think the proposal is a useful one.

Krishna

[toc] | [prev] | [next] | [standalone]

#44109

How about a rewording of

"The purpose of this proposal is to eliminate these ambiguous conditions by 
instead specifying that if no floating-point value is precisely equivalent 
to the provided integer the word provides the floating-point value which 
is closest to the integer."

to

"The purpose of this proposal is to eliminate these ambiguous conditions by 
instead specifying that if a signed double integer to floating-point value conversion results in a loss of precision to the provided integer, the word provides the floating-point value which is closest to the integer." ?

[toc] | [prev] | [next] | [standalone]

#44110

On 12/6/15 8:55 AM, krishna.myneni@ccreweb.org wrote:
> How about a rewording of
>
> "The purpose of this proposal is to eliminate these ambiguous conditions by
> instead specifying that if no floating-point value is precisely equivalent
> to the provided integer the word provides the floating-point value which
> is closest to the integer."
>
> to
>
> "The purpose of this proposal is to eliminate these ambiguous conditions by
> instead specifying that if a signed double integer to floating-point value
> conversion results in a loss of precision to the provided integer, the word
> provides the floating-point value which is closest to the integer." ?
>

The second sentence implies that the provided integer has lost 
precision. It hasn't, it's fine. It's the floating-point value that 
doesn't accurately represent the precision of the integer. How about:

"The purpose of this proposal is to eliminate these ambiguous conditions 
by specifying that if a signed double integer to floating-point value 
conversion results in a floating-point value that does not represent the 
provided integer with full precision, the word returns the 
floating-point value which is closest to the integer."

Cheers,
Eizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#44111

"Elizabeth D. Rather" <erather@forth.com> writes:
> "The purpose of this proposal is to eliminate these ambiguous
> conditions by specifying that if a signed double integer

But it should also deal with single integers, which can lose precision
when converted to single (32-bit) floats in the common situation of
32-bit integer cells.  It could also be useful to have unsigned
conversions but I guess that's separate.

[toc] | [prev] | [next] | [standalone]

#44113

Good point, Paul. The word, "double", should be removed. There are no standard words for converting unsigned integers to floating point, so the present proposal need not concern itself with hypothetical words, U>F and UD>F, which I brought up earlier, and which prompted the present discussion.

Krishna

[toc] | [prev] | [next] | [standalone]

#44116

On 12/6/15 10:15 AM, krishna.myneni@ccreweb.org wrote:
> Good point, Paul. The word, "double", should be removed. There
> are no standard words for converting unsigned integers to floating
> point, so the present proposal need not concern itself with
> hypothetical words, U>F and UD>F, which I brought up earlier,
> and which prompted the present discussion.
>
> Krishna
>

Ok, so: "The purpose of this proposal is to eliminate these ambiguous 
conditions by specifying that if a signed integer to floating-point 
conversion results in a floating-point value that does not represent the 
provided integer with full precision, the word returns the 
floating-point value that is closest to the integer."

(A couple more tiny tweaks for conciseness and better grammar)

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#44112

I agree, Elizabeth. That's a better rewording.

Krishna

[toc] | [prev] | [next] | [standalone]

#44117

krishna.myneni@ccreweb.org krishna.myneni@ccreweb.org wrote:

> I agree, Elizabeth. That's a better rewording.
> 
> Krishna

I really don't think the wording here is very important.  It just provides 
the motivation for the proposal; it is present in the RfD and CfV but not 
in the Standard itself if the proposal is adopted.

But if wording worries are called for...

Elizabeth and Krishna prefer
"The purpose of this proposal is to eliminate these ambiguous conditions 
by specifying that if a signed double integer to floating-point value 
conversion results in a floating-point value that does not represent the 
provided integer with full precision, the word returns the 
floating-point value which is closest to the integer."

My intention was to include both single and double integers, since the 
proposal includes both, hence "provided integer".

Under the current Standard, there may be no "integer to floating-point 
value" occurring at all!  Whether there is a floating-point value which is 
precisely equivalent to the provided integer is system-dependent but 
unambiguous.

regards to all   cgm

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web