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

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

RfD: D>F and S>F first draft

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

Contents

  RfD: D>F and S>F  first draft C G Montgomery <cgm@physics.utoledo.edu> - 2015-11-21 17:59 -0500
    Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-11-22 18:25 +1100
      Re: D>F and S>F  first draft krishna.myneni@ccreweb.org - 2015-11-22 06:20 -0800
        Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-11-23 10:58 +1100
          Re: D>F and S>F  first draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-23 02:57 +0100
            Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-11-24 13:16 +1100
              Re: D>F and S>F  first draft Paul Rubin <no.email@nospam.invalid> - 2015-11-23 18:49 -0800
                Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-11-25 11:51 +1100
                  Re: D>F and S>F  first draft Paul Rubin <no.email@nospam.invalid> - 2015-11-24 17:26 -0800
              Re: D>F and S>F  first draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-25 02:43 +0100
                Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-11-26 12:16 +1100
                  Re: D>F and S>F  first draft Paul Rubin <no.email@nospam.invalid> - 2015-11-25 17:47 -0800
                    Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-11-26 15:47 +1100
                      Re: D>F and S>F  first draft Paul Rubin <no.email@nospam.invalid> - 2015-11-25 23:07 -0800
                      Re: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-26 07:27 +0000
                        Re: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-26 09:19 +0000
                        Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-11-28 04:26 +1100
                          Re: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-28 11:31 +0000
                            Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-11-29 20:23 +1100
                              Re: D>F and S>F  first draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-29 20:39 +0100
                                Re: D>F and S>F  first draft "HAA" <someone@microsoft.com> - 2015-12-05 17:48 +1100
                                  Re: D>F and S>F  first draft Julian Fondren <julian.fondren@gmail.com> - 2015-12-04 23:58 -0800
                                    Re: D>F and S>F  first draft mhx@iae.nl - 2015-12-05 02:19 -0800
                                      Re: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-05 11:25 +0000
                                        Re: D>F and S>F first draft Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-05 13:11 +0000
                                        Re: D>F and S>F  first draft mhx@iae.nl - 2015-12-05 05:27 -0800
                                          Re: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-05 15:33 +0000
                                            Re: D>F and S>F  first draft mhx@iae.nl - 2015-12-07 10:10 -0800
                                              Re: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-09 16:58 +0000
                                      Re: D>F and S>F  first draft krishna.myneni@ccreweb.org - 2015-12-06 10:23 -0800
                                        Re: D>F and S>F  first draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-06 21:37 +0100
                                  Re: D>F and S>F  first draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-05 19:08 +0100
                              Re: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-30 08:33 +0000
                      Re: D>F and S>F first draft "Elizabeth D. Rather" <erather@forth.com> - 2015-11-25 21:43 -1000
                        Re: D>F and S>F first draft "HAA" <someone@microsoft.com> - 2015-11-28 19:28 +1100
                      Re: D>F and S>F first draft Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-26 11:37 +0000
      Re: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-22 15:10 +0000
      Re: D>F and S>F  first draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-22 20:48 +0100
        Re: D>F and S>F first draft "Elizabeth D. Rather" <erather@forth.com> - 2015-11-22 13:42 -1000
          Re: D>F and S>F first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-23 11:50 +0000
            Re: D>F and S>F first draft "Elizabeth D. Rather" <erather@forth.com> - 2015-11-23 12:46 -1000
              Forth libraries Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-24 08:55 +0100
    Re: RfD: D>F and S>F  first draft krishna.myneni@ccreweb.org - 2015-11-22 06:33 -0800
      Re: RfD: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-22 16:00 +0000
        Re: RfD: D>F and S>F  first draft krishna.myneni@ccreweb.org - 2015-11-22 08:53 -0800
          Re: RfD: D>F and S>F  first draft krishna.myneni@ccreweb.org - 2015-11-22 09:11 -0800
          Re: RfD: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-22 18:24 +0000
        Re: RfD: D>F and S>F  first draft Paul Rubin <no.email@nospam.invalid> - 2015-11-22 09:07 -0800
          Re: RfD: D>F and S>F  first draft stephen@mpeforth.com (Stephen Pelc) - 2015-11-22 18:10 +0000
          Re: RfD: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-22 18:26 +0000
            Re: RfD: D>F and S>F first draft rickman <gnuarm@gmail.com> - 2015-11-22 13:58 -0500
              Re: RfD: D>F and S>F first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-23 12:34 +0000
                Re: RfD: D>F and S>F first draft Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-23 16:39 +0000
                Re: RfD: D>F and S>F first draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-24 03:00 +0100
              Re: RfD: D>F and S>F first draft Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-23 13:48 +0100
                Re: RfD: D>F and S>F first draft mhx@iae.nl - 2015-11-23 05:19 -0800
                  Re: RfD: D>F and S>F first draft mhx@iae.nl - 2015-11-23 16:09 -0800
          Re: RfD: D>F and S>F  first draft Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-22 20:42 +0100
      Re: RfD: D>F and S>F  first draft C G Montgomery <cgm@physics.utoledo.edu> - 2015-11-22 16:43 -0500
        Re: RfD: D>F and S>F  first draft krishna.myneni@ccreweb.org - 2015-11-22 18:40 -0800
          Re: RfD: D>F and S>F  first draft krishna.myneni@ccreweb.org - 2015-11-22 18:51 -0800
          Re: RfD: D>F and S>F  first draft C G Montgomery <cgm@physics.utoledo.edu> - 2015-11-25 15:47 -0500
    Re: RfD: D>F and S>F  first draft anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-22 14:29 +0000
    Re: RfD: D>F and S>F first draft "David N. Williams" <williams@umich.edu> - 2015-11-22 10:41 -0600

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#43688 — Re: D>F and S>F first draft

On 11/23/15 1:50 AM, Anton Ertl wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> On 11/22/15 9:48 AM, Bernd Paysan wrote:
>>> There has been a at least 20 year long complaint about the lack of Forth
>>> libraries, but if we can't make Forth systems sufficiently compatible with
>>> each others by leaving too many things ambiguous, that situation will stay
>>> that way.
>>
>> It's more like 40 years. I do not think the problem is with "ambiguity,"
>> it's because a lot of people would rather write "yet another Forth"
>
> Now why is that?  Why do people like to write yet another system when
> they are dealing with Forth, while they like to write libraries when
> they are dealing with Python?  Maybe it's because the Forth standard
> makes it hard to write portable libraries (in order to make it easier
> to claim that your system is standard), while Python makes it easier.

All I know is what they say when they come here asking questions. They 
don't come saying, "Hey, I just posted my implementation for [xxx], 
which I think is Standard, please try it out and tell me what you 
think!". Nor do they say, "I tried to write a library for [xxx] but it 
was too hard, so I'm going to write my own Forth."

No, they come and say, "Hey, I'm going to try to write a Forth because I 
think it's cool and would be a fun project."

And the reason that it's so "cool" is that it looks easy, whereas 
writing your own Python is too hard to be fun.

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]

#43700 — Forth libraries

Elizabeth D. Rather wrote:
> Anton Ertl wrote:
>> "Elizabeth D. Rather wrote:
>>> Bernd Paysan wrote:
>>>> There has been a at least 20 year long complaint about the lack of
>>>> Forth libraries
>>>
>>> It's more like 40 years. I do not think the problem is with
>>> "ambiguity," it's because a lot of people would rather write "yet
>>> another Forth"
>>
>> Now why is that?
>
> All I know is what they say when they come here asking questions. They
> don't come saying, "Hey, I just posted my implementation for [xxx],
> which I think is Standard, please try it out and tell me what you
> think!". Nor do they say, "I tried to write a library for [xxx] but it
> was too hard, so I'm going to write my own Forth."
>
> No, they come and say, "Hey, I'm going to try to write a Forth because
> I think it's cool and would be a fun project."

I think that's true.  I'm one of those myself.

There are about 400 repositories at GitHub which have a sustantial
amount of Forth code.  Out of those, only 10% are libraries and tools:

https://github.com/orgs/ForthHub/teams/libraries/repositories

(And there are a zillion toy Forths written in other languages.)

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

#43635

On Saturday, November 21, 2015 at 4:59:34 PM UTC-6, C G Montgomery wrote:
> Author:
> 
> Charles G. Montgomery <cgm@physics.utoledo.edu>
> 
> 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

"can not" --> cannot
 
> 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.
>

is closest to the integer, within the floating point representation used by the system. 

An ambiguous condition may still exist if the maximum double length integer exceeds the maximum representable floating point number.

> 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 
> prescision 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.

The above discussion seems irrelevant to the problem at hand.

> 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 can not 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."
>

An ambiguous condition may still exist, per my earlier comment, if the exponent part of the number r cannot span the full range of double length integers. As far as I know, this does not pose a problem for any existing systems.

> 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 from float to integer

Don't you mean, integer to float?
 
> is precise, by comparing the initial integer value with the result of D>F

Change "precise" to exact.

> 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 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.
> 

The above statement, I think, is wrong. As long as the range of double length numbers and the intrinsic floating point numbers is well-defined by the Forth system, tests for correct behavior should be possible.

KM

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

#43638

krishna.myneni@ccreweb.org writes:
>An ambiguous condition may still exist if the maximum double length integer exceeds the maximum representable floating point number.

I doubt there is any Forth system where that happens, nor is there
likely to ever be: in particular, the largest non-infinite value on
32-bit IEEE FP is not quite 2^128, while the largest d on a system
with 64-bit cells is not quite 2^127.  And should there ever be a
system that uses, say, 8-bit FP values, there is still an FP value that
is nearest, so use that!  And better think about whether your choice
of FP representation is appropriate.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43640

This is a good argument for prefacing the Rfd with the expected structure of a floating point number, at least in general terms, as consisting of a sign, a significand, and an exponent. The number of bits allocated to the exponent, not to the significand, is where there may be a problem, potentially. As an extreme example, suppose a double integer is 128 bits wide, while the system's floating point representation reserves only 6 bits for the exponent. Then the largest signed double integer would not be representable as an fp number. Admittedly, this would be a pathological case.

Also, I think there needs to be greater specificity on what is meant by round to nearest in the Rfd. How about:

When the double integer cannot be represented exactly in floating point, the system will round the significand to the nearest number to one unit of least precision (1 ulp).

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

#43642

Aagh. Forget the particular example I gave above. That's not quite right.

KM

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

#43644

krishna.myneni@ccreweb.org writes:
>Also, I think there needs to be greater specificity on what is meant by rou=
>nd to nearest in the Rfd.

I think the RfD does fine by referring to the relevant section on
rounding.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43641

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>An ambiguous condition may still exist if the maximum double length
>> integer exceeds the maximum representable floating point number.
> I doubt there is any Forth system where that happens, nor is there
> likely to ever be: in particular, the largest non-infinite value on
> 32-bit IEEE FP is not quite 2^128,...  And should there ever be a
> system that uses, say, 8-bit FP values, there is still an FP value that
> is nearest, so use that!

You mean use the largest FP value even if it's way too small?  That
seems worse than crashing.

IEEE 754 half-precision (binary16) format has a 5 bit exponent.  I
believe it's supported by some graphics hardware that might be plausible
Forth targets.

https://en.wikipedia.org/wiki/Half-precision_floating-point_format

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

#43643

On Sun, 22 Nov 2015 09:07:21 -0800, Paul Rubin
<no.email@nospam.invalid> wrote:

>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>An ambiguous condition may still exist if the maximum double length
>>> integer exceeds the maximum representable floating point number.
>> I doubt there is any Forth system where that happens, nor is there
>> likely to ever be: in particular, the largest non-infinite value on
>> 32-bit IEEE FP is not quite 2^128,...  And should there ever be a
>> system that uses, say, 8-bit FP values, there is still an FP value that
>> is nearest, so use that!
>
>You mean use the largest FP value even if it's way too small?  That
>seems worse than crashing.
>
>IEEE 754 half-precision (binary16) format has a 5 bit exponent.  I
>believe it's supported by some graphics hardware that might be plausible
>Forth targets.
>
>https://en.wikipedia.org/wiki/Half-precision_floating-point_format

ARM Cortex and many ARMs used for Linux support this format. Even
In my most extreme moments, I would not suggest that binary16 is
the primary FP format, but it certainly may need to be supported
by a Forth system.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#43645

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>An ambiguous condition may still exist if the maximum double length
>>> integer exceeds the maximum representable floating point number.
>> I doubt there is any Forth system where that happens, nor is there
>> likely to ever be: in particular, the largest non-infinite value on
>> 32-bit IEEE FP is not quite 2^128,...  And should there ever be a
>> system that uses, say, 8-bit FP values, there is still an FP value that
>> is nearest, so use that!
>
>You mean use the largest FP value even if it's way too small?

Or use an infinity if the FP format supports that.

>That seems worse than crashing.

Seems pretty appropriate to me for an operation that is allowed to
lose precision.  And it's really a question of how many angels can
dance on the head of a pin, as no systems implementor in his right
mind will use such an FP format for the r type in the standard.

>IEEE 754 half-precision (binary16) format has a 5 bit exponent.  I
>believe it's supported by some graphics hardware that might be plausible
>Forth targets.

I don't think that GPUs are a plausible Forth target, but >
>https://en.wikipedia.org/wiki/Half-precision_floating-point_format
anyway, GPUs also have 32-bit floats.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43646 — Re: RfD: D>F and S>F first draft

On 11/22/2015 1:26 PM, Anton Ertl wrote:
> Paul Rubin <no.email@nospam.invalid> writes:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>> An ambiguous condition may still exist if the maximum double length
>>>> integer exceeds the maximum representable floating point number.
>>> I doubt there is any Forth system where that happens, nor is there
>>> likely to ever be: in particular, the largest non-infinite value on
>>> 32-bit IEEE FP is not quite 2^128,...  And should there ever be a
>>> system that uses, say, 8-bit FP values, there is still an FP value that
>>> is nearest, so use that!
>>
>> You mean use the largest FP value even if it's way too small?
>
> Or use an infinity if the FP format supports that.
>
>> That seems worse than crashing.
>
> Seems pretty appropriate to me for an operation that is allowed to
> lose precision.  And it's really a question of how many angels can
> dance on the head of a pin, as no systems implementor in his right
> mind will use such an FP format for the r type in the standard.
>
>> IEEE 754 half-precision (binary16) format has a 5 bit exponent.  I
>> believe it's supported by some graphics hardware that might be plausible
>> Forth targets.
>
> I don't think that GPUs are a plausible Forth target, but >
>> https://en.wikipedia.org/wiki/Half-precision_floating-point_format
> anyway, GPUs also have 32-bit floats.

GPUs are not entirely unlike the GA144.  What about them make forth 
implausible?

-- 

Rick

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

#43673 — Re: RfD: D>F and S>F first draft

rickman <gnuarm@gmail.com> writes:
>On 11/22/2015 1:26 PM, Anton Ertl wrote:
[paste error corrected:]
>> I don't think that GPUs are a plausible Forth target, but
>> anyway, GPUs also have 32-bit floats.
>
>GPUs are not entirely unlike the GA144.  What about them make forth 
>implausible?

My impression is that they are not well fit for general-purpose
computing (e.g., wrt control flow), while Forth is a general-purpose
programming language.  Sure, one probably can design a Forth for them,
but trying to run standard Forth programs on such a Forth (even if it
is possible), is probably not a good use of the hardware, just like on
the GA144.  Another problem is that the actual instruction set is kept
secret, and you are supposed to write your programs in some
intermediate representation, and some compiler integrated in the
driver translates that into the secret instruction set.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43676 — Re: RfD: D>F and S>F first draft

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

>rickman <gnuarm@gmail.com> writes:
>>On 11/22/2015 1:26 PM, Anton Ertl wrote:
>[paste error corrected:]
>>> I don't think that GPUs are a plausible Forth target, but
>>> anyway, GPUs also have 32-bit floats.
>>
>>GPUs are not entirely unlike the GA144.  What about them make forth
>>implausible?

>My impression is that they are not well fit for general-purpose
>computing (e.g., wrt control flow), while Forth is a general-purpose
>programming language.  Sure, one probably can design a Forth for them,
>but trying to run standard Forth programs on such a Forth (even if it
>is possible), is probably not a good use of the hardware, just like on
>the GA144.  Another problem is that the actual instruction set is kept
>secret, and you are supposed to write your programs in some
>intermediate representation, and some compiler integrated in the
>driver translates that into the secret instruction set.

Which makes it entirely possible that it works nicely in Forth
if one gets through that barrier.


>- anton

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]

#43692 — Re: RfD: D>F and S>F first draft

Anton Ertl wrote:

> rickman <gnuarm@gmail.com> writes:
>>On 11/22/2015 1:26 PM, Anton Ertl wrote:
> [paste error corrected:]
>>> I don't think that GPUs are a plausible Forth target, but
>>> anyway, GPUs also have 32-bit floats.
>>
>>GPUs are not entirely unlike the GA144.  What about them make forth
>>implausible?
> 
> My impression is that they are not well fit for general-purpose
> computing (e.g., wrt control flow), while Forth is a general-purpose
> programming language.  Sure, one probably can design a Forth for them,
> but trying to run standard Forth programs on such a Forth (even if it
> is possible), is probably not a good use of the hardware, just like on
> the GA144.  Another problem is that the actual instruction set is kept
> secret, and you are supposed to write your programs in some
> intermediate representation, and some compiler integrated in the
> driver translates that into the secret instruction set.

With the exception of AMD's GCN, which is good enough for general purpose 
computing (that was one of the design goals), and apparently has an open 
spec for the instruction set.  A few hackers already have written 
assemblers, disassemblers and program loaders, filling some gaps that still 
exist.

Slides of one of these projects:

https://onedrive.live.com/view.aspx?resid=EBE7DEDA70D06DA0!
107&app=PowerPoint&authkey=!AD-O3oq3Ung7pzk

-- 
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]

#43674 — Re: RfD: D>F and S>F first draft

rickman wrote:
> Anton Ertl wrote:
>> I don't think that GPUs are a plausible Forth target
> GPUs are not entirely unlike the GA144.  What about them make forth
> implausible?

Here's a special-purpose Forth that runs on GPUs.

http://forthsalon.appspot.com/haiku-about

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

#43675 — Re: RfD: D>F and S>F first draft

On Monday, November 23, 2015 at 1:48:54 PM UTC+1, Lars Brinkhoff wrote:
> rickman wrote:
> > Anton Ertl wrote:
> >> I don't think that GPUs are a plausible Forth target
> > GPUs are not entirely unlike the GA144.  What about them make forth
> > implausible?
> 
> Here's a special-purpose Forth that runs on GPUs.
> 
> http://forthsalon.appspot.com/haiku-about

Even for Forth,
That is stretching the limit,
a bit too thin, especially for me.

-marcel

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

#43691 — Re: RfD: D>F and S>F first draft

On Monday, November 23, 2015 at 2:19:04 PM UTC+1, m...@iae.nl wrote:
> On Monday, November 23, 2015 at 1:48:54 PM UTC+1, Lars Brinkhoff wrote:
> > rickman wrote:
> > > Anton Ertl wrote:
> > >> I don't think that GPUs are a plausible Forth target
> > > GPUs are not entirely unlike the GA144.  What about them make forth
> > > implausible?
> > 
> > Here's a special-purpose Forth that runs on GPUs.
> > 
> > http://forthsalon.appspot.com/haiku-about

 
Even for a Forth,
That is stretching the limit,
Much too thin for me.
 
-marcel

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

#43650

Paul Rubin wrote:
> IEEE 754 half-precision (binary16) format has a 5 bit exponent.  I
> believe it's supported by some graphics hardware that might be plausible
> Forth targets.

Yes, it's supported, especially for pixel color calculations, but *all* 
these GPUs also support IEEE single for the vertex calculations.

AFAIK, many of the smaller GPUs have too many limitations to be used as 
plausible Forth target, and the larger, like GCN, have no problems to deal 
with IEEE doubles.

For an overview over GCN, see here:

http://developer.amd.com/wordpress/media/2013/06/2620_final.pdf

-- 
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]

#43655

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

> On Saturday, November 21, 2015 at 4:59:34 PM UTC-6, C G Montgomery
> wrote:
>> ...
>> the single number N can not be precisely represented as a
>> floating-point value
> 
> "can not" --> cannot
>  
I think the meaning is the same.  You are probably right that I should 
follow the wording of the Standard, which I was not quoting at this point.
I tend to think of this as two separate concepts: 'can be precisely ...' 
and 'not', a reason to prefer two words.

>> ...
>> which is closest to the integer.
>>
> 
> is closest to the integer, within the floating point representation used
> by the system.
> 
If the Standard doesn't include this verbiage, need I?  ;-)

> An ambiguous condition may still exist if the maximum double length
> integer exceeds the maximum representable floating point number.
> 
A valid point.  See below.

>> 
>> Preliminary Remarks:
>> ...
>> I am not aware of any Forth which is not consistent with these
>> presumptions.
> 
> The above discussion seems irrelevant to the problem at hand.
> 
I am trying to clarify the meaning of "precisely represented" in the 
Standard.
I could imagine definitions of "floating point" which incorporate these 
presumptions, but the current Standard does not specify them.

>> ...
>> 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 can not 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."
>>
> 
> An ambiguous condition may still exist, per my earlier comment, if the
> exponent part of the number r cannot span the full range of double
> length integers. As far as I know, this does not pose a problem for any
> existing systems.
> 
The Standard already includes in the list of ambiguous conditions 
requiring documentation
"floating point result out of range (e.g. in 12.6.1.1430 F/)"
This could include the (possibly non-existent) problem you point out.
Would additional treatment be desirable?

>> ...
>> It remains easy to determine whether the conversion from float to
>> integer
> 
> Don't you mean, integer to float?
>  
Maybe "conversion between floats and integers" would be better.

>> is precise, by comparing the initial integer value with the result of
>> D>F
> 
> Change "precise" to exact.
> 
I don't see the benefit.

>> ...
>> 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
>> 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.
>> 
> 
> The above statement, I think, is wrong. As long as the range of double
> length numbers and the intrinsic floating point numbers is well-defined
> by the Forth system, tests for correct behavior should be possible.
> 
I didn't say "impossible"; I just said "difficult", which is certainly 
subjective.
"universal applicability" would require examination of just how floating-
point support is provided by the system.

Thanks for your comments.

cheers   cgm

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

#43662

On Sunday, November 22, 2015 at 3:43:33 PM UTC-6, C G Montgomery wrote:
> krishna.myneni@ccreweb.org krishna.myneni@ccreweb.org wrote:
> 
...
> > 
> > Change "precise" to exact.
> > 
> I don't see the benefit.
> ...

I want to respond to each of your points after some further thought, but this one deserves some immediate attention, particularly because the word "precision" is being thrown about loosely in this thread.

The floating point representation is finite. There are a finite number of bits in the significand and in the exponent. Except for certain numbers, a floating point number is always "precise" to the number of bits in the significand. The unit of least precision defines the precision of the number. The fp representation may also be considered to give an exact representation of an integer or other real number, despite the finite number of bits, for certain numbers when using more bits in the significand gives no change to the binary number.

A precise representation does not imply an exact representation. The necessity for revising the D>F spec arose from the implication in the existing standard that the floating point number must be an exact representation of the double number, instead of specifying that it must give a precise representation to the least unit of precision.

Krishna

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web