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

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

RFD: Drop double numbers as input format

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

Contents

  RFD: Drop double numbers as input format Matthias Trute <matthias.trute@gmail.com> - 2017-06-04 01:25 -0700
    Re: RFD: Drop double numbers as input format Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-04 03:45 -0500
    Re: RFD: Drop double numbers as input format mhx@iae.nl - 2017-06-04 02:10 -0700
      Re: RFD: Drop double numbers as input format albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-04 12:12 +0200
        Re: RFD: Drop double numbers as input format Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-05 02:32 -0500
          Re: RFD: Drop double numbers as input format albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-05 10:19 +0200
            Re: RFD: Drop double numbers as input format anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-05 09:14 +0000
              Re: RFD: Drop double numbers as input format Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-05 04:57 -0500
            Re: RFD: Drop double numbers as input format Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-05 04:51 -0500
          Re: RFD: Drop double numbers as input format Cecil Bayona <cbayona@cbayona.com> - 2017-06-05 11:53 -0500
            Re: RFD: Drop double numbers as input format Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-05 12:29 -0500
            Re: RFD: Drop double numbers as input format minforth@arcor.de - 2017-06-05 11:20 -0700
              Re: RFD: Drop double numbers as input format Julian Fondren <julian.fondren@gmail.com> - 2017-06-05 11:25 -0700
                Re: RFD: Drop double numbers as input format minforth@arcor.de - 2017-06-06 00:50 -0700
                  Re: RFD: Drop double numbers as input format stephen@mpeforth.com (Stephen Pelc) - 2017-06-06 10:16 +0000
                    Re: RFD: Drop double numbers as input format minforth@arcor.de - 2017-06-06 05:30 -0700
                Re: RFD: Drop double numbers as input format minforth@arcor.de - 2017-06-06 22:54 -0700
            Re: RFD: Drop double numbers as input format Mark Wills <markwills1970@gmail.com> - 2017-06-06 02:12 -0700
              Re: RFD: Drop double numbers as input format Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-06 04:23 -0500
                Re: RFD: Drop double numbers as input format Cecil Bayona <cbayona@cbayona.com> - 2017-06-06 10:26 -0500
              Re: RFD: Drop double numbers as input format anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-06 09:52 +0000
                Re: RFD: Drop double numbers as input format Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-06 04:57 -0700
                Re: RFD: Drop double numbers as input format Mark Wills <markwills1970@gmail.com> - 2017-06-06 06:01 -0700
                Re: RFD: Drop double numbers as input format Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-06-06 18:07 +0100
              Re: RFD: Drop double numbers as input format Julian Fondren <julian.fondren@gmail.com> - 2017-06-06 08:09 -0700
                Re: RFD: Drop double numbers as input format Mark Wills <markwills1970@gmail.com> - 2017-06-06 11:51 -0700
                  Re: RFD: Drop double numbers as input format Julian Fondren <julian.fondren@gmail.com> - 2017-06-06 12:19 -0700
        Re: RFD: Drop double numbers as input format Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-06-10 23:23 +0100
      Re: RFD: Drop double numbers as input format Paul Rubin <no.email@nospam.invalid> - 2017-06-04 17:05 -0700
        Re: RFD: Drop double numbers as input format rickman <gnuarm@gmail.com> - 2017-06-04 21:38 -0400
        Re: RFD: Drop double numbers as input format Julian Fondren <julian.fondren@gmail.com> - 2017-06-04 20:26 -0700
          Re: RFD: Drop double numbers as input format mhx@iae.nl - 2017-06-05 00:01 -0700
            Re: RFD: Drop double numbers as input format Matthias Trute <matthias.trute@gmail.com> - 2017-06-05 01:18 -0700
        Re: RFD: Drop double numbers as input format mhx@iae.nl - 2017-06-04 23:47 -0700
        Re: RFD: Drop double numbers as input format Ron Aaron <rambamist@gmail.com> - 2017-06-05 09:56 +0300
        Re: RFD: Drop double numbers as input format Mark Wills <markwills1970@gmail.com> - 2017-06-06 01:46 -0700
        Re: RFD: Drop double numbers as input format "HAA" <someone@microsoft.com> - 2017-06-07 21:44 +1000
          Re: RFD: Drop double numbers as input format minforth@arcor.de - 2017-06-07 05:13 -0700
            Re: RFD: Drop double numbers as input format "HAA" <someone@microsoft.com> - 2017-06-08 12:36 +1000
          Re: RFD: Drop double numbers as input format Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-07 07:33 -0700
            Re: RFD: Drop double numbers as input format "HAA" <someone@microsoft.com> - 2017-06-08 12:34 +1000
              Re: RFD: Drop double numbers as input format Alex <alex@rivadpm.com> - 2017-06-08 09:55 +0100
                Re: RFD: Drop double numbers as input format "HAA" <someone@microsoft.com> - 2017-06-11 17:22 +1000
          Re: RFD: Drop double numbers as input format hughaguilar96@gmail.com - 2017-06-08 17:13 -0700
    Re: RFD: Drop double numbers as input format mhx@iae.nl - 2017-06-04 02:18 -0700
    Re: RFD: Drop double numbers as input format "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-04 09:54 +0000
    Re: RFD: Drop double numbers as input format albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-04 12:07 +0200
    Re: RFD: Drop double numbers as input format anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-04 10:18 +0000
      Re: RFD: Drop double numbers as input format mhx@iae.nl - 2017-06-04 05:47 -0700
        Re: RFD: Drop double numbers as input format anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-04 15:44 +0000
      Re: RFD: Drop double numbers as input format Matthias Trute <matthias.trute@gmail.com> - 2017-06-04 09:10 -0700
        Re: RFD: Drop double numbers as input format anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-04 16:21 +0000
        Re: RFD: Drop double numbers as input format Coos Haak <htrofhc@gmail.com> - 2017-06-04 18:33 +0200
      Re: RFD: Drop double numbers as input format Bernd Paysan <bernd@net2o.de> - 2017-06-07 01:21 +0200
        Re: RFD: Drop double numbers as input format minforth@arcor.de - 2017-06-06 22:57 -0700
          Re: RFD: Drop double numbers as input format Julian Fondren <julian.fondren@gmail.com> - 2017-06-06 23:34 -0700
            Re: RFD: Drop double numbers as input format minforth@arcor.de - 2017-06-07 01:12 -0700
    Re: RFD: Drop double numbers as input format The Beez <the.beez.speaks@gmail.com> - 2017-06-07 02:38 -0700
    Re: RFD: Drop double numbers as input format JennyB <jennybrien@googlemail.com> - 2017-06-07 02:45 -0700
      Re: RFD: Drop double numbers as input format foxaudioresearch@gmail.com - 2017-06-08 18:34 -0700
        Re: RFD: Drop double numbers as input format Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-06-10 23:08 +0100
          Re: RFD: Drop double numbers as input format anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-11 12:32 +0000
      Re: RFD: Drop double numbers as input format "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-06-09 18:07 +0000

Page 1 of 4  [1] 2 3 4  Next page →

#60272 — RFD: Drop double numbers as input format

A radical one. I admit.

Problem
=======

Double numbers are specified as integer numbers with
values beyond cell size (e.g. 65535 on a 16-bit system). 
They shall be entered with a trailing dot. Common practice
is that the dot can be at any place within the number 
string which conflicts with floating point number formats.


Solution
========

To avoid the syntax confusion and since double numbers
have a fixed stack order, there is no immediate need
to directly enter double numbers at all. The number 1. 
can be written as the sequence 1 0 with single cell numbers
without portabilities issues.

With the wide spread usage of 32 and 64-bit systems, the
need for double cell numbers as input format is expected
to be less important.

Proposal
========

Remove the trailing dot specification from the standard 
and remove the double number as an input format for
integer numbers. All other occurrences of double numbers
are left unchanged.

Experience
==========

None

Typical Usage
=============

Existing double cell input formats are to be split into
two literals. Existing sequences such as "1." are to be
replaced with " 1 0 ".

[toc] | [next] | [standalone]

#60273

Matthias Trute <matthias.trute@gmail.com> wrote:
> A radical one. I admit.
> 
> Problem
> =======
> 
> Double numbers are specified as integer numbers with
> values beyond cell size (e.g. 65535 on a 16-bit system). 
> They shall be entered with a trailing dot. Common practice
> is that the dot can be at any place within the number 
> string which conflicts with floating point number formats.

I think you need a "Compatibility" section in any proposal for
language change, where you discuss the impact on systems and users.

Andrew.

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

#60274

On Sunday, June 4, 2017 at 10:25:59 AM UTC+2, Matthias Trute wrote:
> A radical one. I admit.
> 
> Problem
> =======
> 
> Double numbers are specified as integer numbers with
> values beyond cell size (e.g. 65535 on a 16-bit system). 
> They shall be entered with a trailing dot. Common practice
> is that the dot can be at any place within the number 
> string which conflicts with floating point number formats.
 
This problem statement is not clear.

A minimal floating-point number consists of a single <digit>
between 0 and 9, followed by 'E'. In addition to this, base
should be decimal. Therefore, confusion with a double
(containing a '.' anywhere) is only possible when this
double also contains 'E' followed by *<digit0>. This
obviously makes no sense (for an unprefixed double) when
base is decimal.

My own practice is to don't care about BASE when entering
floating-point. This is possible by always using a prefix
on single *and* double integers, which I consider good
practice fom a copy/past/include viewpoint anyway.

Do you have an example where, in DECIMAL, a certain string
could be both a double and a float?

I suppose your 'problem' is actually that base should be
decimal when using floats.

-marcel

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

#60280

In article <b6285ba7-f386-44f5-a58a-6a761695d025@googlegroups.com>,
 <mhx@iae.nl> wrote:
 <SNIP>
>A minimal floating-point number consists of a single <digit>
>between 0 and 9, followed by 'E'. In addition to this, base
>should be decimal. Therefore, confusion with a double
>(containing a '.' anywhere) is only possible when this
>double also contains 'E' followed by *<digit0>. This
>obviously makes no sense (for an unprefixed double) when
>base is decimal.

Not using BASE for floating point is a missed opportunity.
Using E for exponent instead of e.g. ~ is a design error.

>
>My own practice is to don't care about BASE when entering
>floating-point. This is possible by always using a prefix
>on single *and* double integers, which I consider good
>practice fom a copy/past/include viewpoint anyway.

I know how you do it. It obviously works.
<SNIP>
>
>I suppose your 'problem' is actually that base should be
>decimal when using floats.

A shame, really.

>
>-marcel

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]

#60323

Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
> In article <b6285ba7-f386-44f5-a58a-6a761695d025@googlegroups.com>,
> <mhx@iae.nl> wrote:
> <SNIP>
>>A minimal floating-point number consists of a single <digit>
>>between 0 and 9, followed by 'E'. In addition to this, base
>>should be decimal. Therefore, confusion with a double
>>(containing a '.' anywhere) is only possible when this
>>double also contains 'E' followed by *<digit0>. This
>>obviously makes no sense (for an unprefixed double) when
>>base is decimal.
> 
> Not using BASE for floating point is a missed opportunity.
> Using E for exponent instead of e.g. ~ is a design error.

I understand that Forth is different from other languages by design.
However, is it important to use a notation for floating-point numbers
that is different from, say, pocket calculators, other programming
languages, and IEEE-754?  I'd welcome hex floating-point I/O but I'd
be a lot less keen for Forth to use a notation that's not standard-
compliant.

Andrew.

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

#60326

In article <y-OdnSNA0raclKjEnZ2dnUU7-WudnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
>> In article <b6285ba7-f386-44f5-a58a-6a761695d025@googlegroups.com>,
>> <mhx@iae.nl> wrote:
>> <SNIP>
>>>A minimal floating-point number consists of a single <digit>
>>>between 0 and 9, followed by 'E'. In addition to this, base
>>>should be decimal. Therefore, confusion with a double
>>>(containing a '.' anywhere) is only possible when this
>>>double also contains 'E' followed by *<digit0>. This
>>>obviously makes no sense (for an unprefixed double) when
>>>base is decimal.
>>
>> Not using BASE for floating point is a missed opportunity.
>> Using E for exponent instead of e.g. ~ is a design error.
>
>I understand that Forth is different from other languages by design.
>However, is it important to use a notation for floating-point numbers
>that is different from, say, pocket calculators, other programming
>languages, and IEEE-754?  I'd welcome hex floating-point I/O but I'd
>be a lot less keen for Forth to use a notation that's not standard-
>compliant.

Having the possibility of hex floats doesn't take away decimal floats.

It opens the possibility between (Forth) programs to communicate
readable numbers without loosing precision. There have been
situation in my carreer where this was a desirable goal
unreachable by FORTRAN.

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

#60330

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>Having the possibility of hex floats doesn't take away decimal floats.
>
>It opens the possibility between (Forth) programs to communicate
>readable numbers without loosing precision.

What's readable about hex floats?  If you mean printable, wouldn't a,
say, hex-dump of the df! result (with a defined byte order) satisfy
that requirement with less effort?

If we also want readable, there has been work on accurate conversion
between binary format and decimal representation that are stable under
repeated conversion between formats, e.g.,
<http://people.csail.mit.edu/jaffer/III/EZFPRW> (and that contains
references to the older work).

These algorithms require bignum arithmetic (with up to 1126-bit
immediates for IEEE DP format), and are not simple.  It still might be
a good idea to use them for FP I/O conversion, rather than the crap we
currently have, which falls over now and then (just in the last year I
saw bug reports for Gforth and VFX, and fixed the one for Gforth).
Does anyone volunteer to convert them to Forth?

- 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 2017: http://www.euroforth.org/ef17/

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

#60335

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>Having the possibility of hex floats doesn't take away decimal floats.
>>
>>It opens the possibility between (Forth) programs to communicate
>>readable numbers without loosing precision.
> 
> What's readable about hex floats?  If you mean printable, wouldn't a,
> say, hex-dump of the df! result (with a defined byte order) satisfy
> that requirement with less effort?

That's an interesting point.  However, it would be almost as easy (and
IMO better) to split the number into a fraction and an exponent and
print both as integers: the base wouldn't matter as long as the reader
and the writer agreed.

> If we also want readable, there has been work on accurate conversion
> between binary format and decimal representation that are stable under
> repeated conversion between formats, e.g.,
> <http://people.csail.mit.edu/jaffer/III/EZFPRW> (and that contains
> references to the older work).

Thanks, I haven't seen that one before.  It's a lot easier to
understand than its predecessors.

> These algorithms require bignum arithmetic (with up to 1126-bit
> immediates for IEEE DP format), and are not simple.  It still might be
> a good idea to use them for FP I/O conversion, rather than the crap we
> currently have, which falls over now and then (just in the last year I
> saw bug reports for Gforth and VFX, and fixed the one for Gforth).

I too have wondered about that, particularly when looking at making
Forth IEEE-compatible, but it seems a bit too heavyweight IMO.

Andrew.

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

#60332

Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
> In article <y-OdnSNA0raclKjEnZ2dnUU7-WudnZ2d@supernews.com>,
> Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>>Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
>>> In article <b6285ba7-f386-44f5-a58a-6a761695d025@googlegroups.com>,
>>> <mhx@iae.nl> wrote:
>>> <SNIP>
>>>>A minimal floating-point number consists of a single <digit>
>>>>between 0 and 9, followed by 'E'. In addition to this, base
>>>>should be decimal. Therefore, confusion with a double
>>>>(containing a '.' anywhere) is only possible when this
>>>>double also contains 'E' followed by *<digit0>. This
>>>>obviously makes no sense (for an unprefixed double) when
>>>>base is decimal.
>>>
>>> Not using BASE for floating point is a missed opportunity.
>>> Using E for exponent instead of e.g. ~ is a design error.
>>
>>I understand that Forth is different from other languages by design.
>>However, is it important to use a notation for floating-point numbers
>>that is different from, say, pocket calculators, other programming
>>languages, and IEEE-754?  I'd welcome hex floating-point I/O but I'd
>>be a lot less keen for Forth to use a notation that's not standard-
>>compliant.
> 
> Having the possibility of hex floats doesn't take away decimal floats.

Indeed not, but I'm quibbling about whether it's actually necessary to
have floating-point string representation that's deliberately
different from many other programming languages.  At the moment 1.23e0
works perfectly well with Forth pretty much everything else.  1.23~0,
not so much.

> It opens the possibility between (Forth) programs to communicate
> readable numbers without loosing precision. There have been
> situation in my carreer where this was a desirable goal
> unreachable by FORTRAN.

Does Fortran still not have hex floating-point?

Andrew.

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

#60348

On 6/5/2017 2:32 AM, Andrew Haley wrote:
> Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
>> In article <b6285ba7-f386-44f5-a58a-6a761695d025@googlegroups.com>,
>> <mhx@iae.nl> wrote:
>> <SNIP>
>>> A minimal floating-point number consists of a single <digit>
>>> between 0 and 9, followed by 'E'. In addition to this, base
>>> should be decimal. Therefore, confusion with a double
>>> (containing a '.' anywhere) is only possible when this
>>> double also contains 'E' followed by *<digit0>. This
>>> obviously makes no sense (for an unprefixed double) when
>>> base is decimal.
>>
>> Not using BASE for floating point is a missed opportunity.
>> Using E for exponent instead of e.g. ~ is a design error.
> 
> I understand that Forth is different from other languages by design.
> However, is it important to use a notation for floating-point numbers
> that is different from, say, pocket calculators, other programming
> languages, and IEEE-754?  I'd welcome hex floating-point I/O but I'd
> be a lot less keen for Forth to use a notation that's not standard-
> compliant.
> 
> Andrew.
> 
It's not just that a few languages use a decimal number but everyone 
that went to school was taught that 10.3 is a decimal number with an 
integer and a fraction part separated by a decimal point.

The use of a decimal notation to indicate a double was a bad idea from 
day one since it went counter to everyone's notion of what a decimal 
number is, I understand that in the early days floating point was hard 
on a CPU but still to indicate a double something else should have been 
used.

This whole use of a decimal point to indicate a double sized number 
makes Forther's look ignorant since they ignore decimal number notation 
that has been taught and used for many centuries.

-- 
Cecil - k5nwa

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

#60352

Cecil Bayona <cbayona@cbayona.com> wrote:
> On 6/5/2017 2:32 AM, Andrew Haley wrote:
>> Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
>>> In article <b6285ba7-f386-44f5-a58a-6a761695d025@googlegroups.com>,
>>> <mhx@iae.nl> wrote:
>>> <SNIP>
>>>> A minimal floating-point number consists of a single <digit>
>>>> between 0 and 9, followed by 'E'. In addition to this, base
>>>> should be decimal. Therefore, confusion with a double
>>>> (containing a '.' anywhere) is only possible when this
>>>> double also contains 'E' followed by *<digit0>. This
>>>> obviously makes no sense (for an unprefixed double) when
>>>> base is decimal.
>>>
>>> Not using BASE for floating point is a missed opportunity.
>>> Using E for exponent instead of e.g. ~ is a design error.
>> 
>> I understand that Forth is different from other languages by design.
>> However, is it important to use a notation for floating-point numbers
>> that is different from, say, pocket calculators, other programming
>> languages, and IEEE-754?  I'd welcome hex floating-point I/O but I'd
>> be a lot less keen for Forth to use a notation that's not standard-
>> compliant.
>
> It's not just that a few languages use a decimal number but everyone 
> that went to school was taught that 10.3 is a decimal number with an 
> integer and a fraction part separated by a decimal point.
> 
> The use of a decimal notation to indicate a double was a bad idea from 
> day one since it went counter to everyone's notion of what a decimal 
> number is, I understand that in the early days floating point was hard 
> on a CPU but still to indicate a double something else should have been 
> used.

But in the early days of Forth several punctuation symbols could be
used: "," "-" "." "/" .  And very useful they were too.  I don't think
there was any floating point in Forth for a long time.  (Interesting
question: when does floating point in Forth date from?  AFAICR Forth
Inc didn't use floating-point until they had hardware.)
   
> This whole use of a decimal point to indicate a double sized number 
> makes Forther's look ignorant since they ignore decimal number notation 
> that has been taught and used for many centuries.

No, you cannot claim historical jutification going back centuries.
Over here, a decimal point always was a different glyph from a full
stop: an interpunct was used, not a full stop.  The French and many
other territories use a comma for a decimal point.  The use of full
stop for a decimal point is something of an American eccentricity, but
the rest of the world is stuck with it because of the 7-bit ASCII
character set.

Andrew.

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

#60354

Am Montag, 5. Juni 2017 18:53:21 UTC+2 schrieb Cecil - k5nwa:
> On 6/5/2017 2:32 AM, Andrew Haley wrote:
> > Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote:
> >> In article <b6285ba7-f386-44f5-a58a-6a761695d025@googlegroups.com>,
> >> <mhx@iae.nl> wrote:
> >> <SNIP>
> >>> A minimal floating-point number consists of a single <digit>
> >>> between 0 and 9, followed by 'E'. In addition to this, base
> >>> should be decimal. Therefore, confusion with a double
> >>> (containing a '.' anywhere) is only possible when this
> >>> double also contains 'E' followed by *<digit0>. This
> >>> obviously makes no sense (for an unprefixed double) when
> >>> base is decimal.
> >>
> >> Not using BASE for floating point is a missed opportunity.
> >> Using E for exponent instead of e.g. ~ is a design error.
> > 
> > I understand that Forth is different from other languages by design.
> > However, is it important to use a notation for floating-point numbers
> > that is different from, say, pocket calculators, other programming
> > languages, and IEEE-754?  I'd welcome hex floating-point I/O but I'd
> > be a lot less keen for Forth to use a notation that's not standard-
> > compliant.
> > 
> > Andrew.
> > 
> It's not just that a few languages use a decimal number but everyone 
> that went to school was taught that 10.3 is a decimal number with an 
> integer and a fraction part separated by a decimal point.
> 
> The use of a decimal notation to indicate a double was a bad idea from 
> day one since it went counter to everyone's notion of what a decimal 
> number is, I understand that in the early days floating point was hard 
> on a CPU but still to indicate a double something else should have been 
> used.
> 
> This whole use of a decimal point to indicate a double sized number 
> makes Forther's look ignorant since they ignore decimal number notation 
> that has been taught and used for many centuries.
> 
> -- 
> Cecil - k5nw

In the early days one could use DPL after numeric conversion for loading / implementing fixed-point number math (often sufficient for simple engineering
tasks, precise for financial tasks) or real floating-point number math
(hand coded before coprocessors like the 8087 appeared).

I always found it strange that DPL never made it into the standard.

By checking DPL and BASE most of the discussed number input format
ambiguities would vanish.

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

#60355

On Monday, June 5, 2017 at 1:20:05 PM UTC-5, minf...@arcor.de wrote:
> In the early days one could use DPL after numeric conversion for loading / implementing fixed-point number math (often sufficient for simple engineering
> tasks, precise for financial tasks) or real floating-point number math
> (hand coded before coprocessors like the 8087 appeared).
> 
> I always found it strange that DPL never made it into the standard.

It's because the standard only has 1234. doubles, with trailing dot.

> By checking DPL and BASE most of the discussed number input format
> ambiguities would vanish.

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

#60365

Am Montag, 5. Juni 2017 20:25:59 UTC+2 schrieb Julian Fondren:
> On Monday, June 5, 2017 at 1:20:05 PM UTC-5, minf...@arcor.de wrote:
> > In the early days one could use DPL after numeric conversion for loading / implementing fixed-point number math (often sufficient for simple engineering
> > tasks, precise for financial tasks) or real floating-point number math
> > (hand coded before coprocessors like the 8087 appeared).
> > 
> > I always found it strange that DPL never made it into the standard.
> 
> It's because the standard only has 1234. doubles, with trailing dot.
> 
> > By checking DPL and BASE most of the discussed number input format
> > ambiguities would vanish.

So to overcome the legacy code issue, which forbids dropping double number input as was suggested, it makes more sense to add DPL to the Standard.

And back it with a reference table of correct Input formats for
CORE alone
CORE + DOUBLE loaded
CORE + FLOAT loaded
CORE * FLOAT + DOUBLE loaded

Perhaps accompanied with a control flag, as VFX does.

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

#60376

On Tue, 6 Jun 2017 00:50:16 -0700 (PDT), minforth@arcor.de wrote:

>Am Montag, 5. Juni 2017 20:25:59 UTC+2 schrieb Julian Fondren:
>> On Monday, June 5, 2017 at 1:20:05 PM UTC-5, minf...@arcor.de wrote:
>> > In the early days one could use DPL after numeric conversion for loading / implementing fixed-point number math (often sufficient for simple engineering
>> > tasks, precise for financial tasks) or real floating-point number math
>> > (hand coded before coprocessors like the 8087 appeared).
>> > 
>> > I always found it strange that DPL never made it into the standard.
>> 
>> It's because the standard only has 1234. doubles, with trailing dot.
>> 
>> > By checking DPL and BASE most of the discussed number input format
>> > ambiguities would vanish.
>
>So to overcome the legacy code issue, which forbids dropping double number input as was suggested, it makes more sense to add DPL to the Standard.
>
>And back it with a reference table of correct Input formats for
>CORE alone
>CORE + DOUBLE loaded
>CORE + FLOAT loaded
>CORE * FLOAT + DOUBLE loaded
>
>Perhaps accompanied with a control flag, as VFX does.

What is this control flag in VFX? Sorry, but I don't understand the
terminology.

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]

#60383

Am Dienstag, 6. Juni 2017 12:15:57 UTC+2 schrieb Stephen Pelc:
> On Tue, 6 Jun 2017 00:50:16 -0700 (PDT), minforth@arcor.de wrote:
> 
> >Am Montag, 5. Juni 2017 20:25:59 UTC+2 schrieb Julian Fondren:
> >> On Monday, June 5, 2017 at 1:20:05 PM UTC-5, minf...@arcor.de wrote:
> >> > In the early days one could use DPL after numeric conversion for loading / implementing fixed-point number math (often sufficient for simple engineering
> >> > tasks, precise for financial tasks) or real floating-point number math
> >> > (hand coded before coprocessors like the 8087 appeared).
> >> > 
> >> > I always found it strange that DPL never made it into the standard.
> >> 
> >> It's because the standard only has 1234. doubles, with trailing dot.
> >> 
> >> > By checking DPL and BASE most of the discussed number input format
> >> > ambiguities would vanish.
> >
> >So to overcome the legacy code issue, which forbids dropping double number input as was suggested, it makes more sense to add DPL to the Standard.
> >
> >And back it with a reference table of correct Input formats for
> >CORE alone
> >CORE + DOUBLE loaded
> >CORE + FLOAT loaded
> >CORE * FLOAT + DOUBLE loaded
> >
> >Perhaps accompanied with a control flag, as VFX does.
> 
> What is this control flag in VFX? Sorry, but I don't understand the
> terminology.
> 
> 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

It says in the doc §14.3:  dp-char and fp-char

But I never used it. To me the whole paragraph is about workarounds
of ambiguous number formats.

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

#60419

Am Montag, 5. Juni 2017 20:25:59 UTC+2 schrieb Julian Fondren:
> On Monday, June 5, 2017 at 1:20:05 PM UTC-5, minf...@arcor.de wrote:

> > I always found it strange that DPL never made it into the standard.
> 
> It's because the standard only has 1234. doubles, with trailing dot.

Still DPL indicates whther it's a single number (DPL=-1)
or a double number with trailing dot (DPL=0)

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

#60368

On Monday, 5 June 2017 17:53:21 UTC+1, Cecil - k5nwa  wrote:
> It's not just that a few languages use a decimal number but everyone 
> that went to school was taught that 10.3 is a decimal number with an 
> integer and a fraction part separated by a decimal point.

In Britain, yes; in Eastern Europe you could use a comma and zero
eyebrows would be raised. But anyway, I'm splitting hairs.

> 
> The use of a decimal notation to indicate a double was a bad idea from 
> day one since it went counter to everyone's notion of what a decimal 
> number is, I understand that in the early days floating point was hard 
> on a CPU but still to indicate a double something else should have been 
> used.

It's actually worse than that! Because, yes, a dot in a number PHYSICALLY
produces a double, we all know that, but we're supposed to PRETEND that 
it's a float for use in a fixed-point arithmetic system. Hence we have
words like DPL which allow us align imaginary decimal points when 
multiplying and dividing fixed points, and displaying a decimal when using
<# et al.

We're probably too far down the road to change it though. And would we want
to? Fixed-point and <# # #> work VERY well in Forth, and removing translation of strings containing a period into doubles would interfere with that whole
paradigm. I wouldn't want to throw that baby out with the bathwater. Best we
could do is use a special character to indicate a float. Most Forth's already
have them for binary, decimal, hex, octal etc.

%1111000
$face
#100

Maybe we could adopt a character for floats?

~123.456

The tilde would be a good candidate, as it can also mean "approximately",
which is what you are talking about when you're dealing with floating-point.

Where no tilde is present, it's a regular 1970 flavour double.

That would have absolutely no impact on legacy code, and could be adopted
going forward to explicitly inform the compiler, programmer and reader that
the number in question is explicitly floating point.

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

#60370

Mark Wills <markwills1970@gmail.com> wrote:
> On Monday, 5 June 2017 17:53:21 UTC+1, Cecil - k5nwa  wrote:
>> It's not just that a few languages use a decimal number but everyone 
>> that went to school was taught that 10.3 is a decimal number with an 
>> integer and a fraction part separated by a decimal point.
> 
> In Britain, yes;

In Britain, no: America, yes.

Andrew.

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

#60398

On 6/6/2017 4:23 AM, Andrew Haley wrote:
> Mark Wills <markwills1970@gmail.com> wrote:
>> On Monday, 5 June 2017 17:53:21 UTC+1, Cecil - k5nwa  wrote:
>>> It's not just that a few languages use a decimal number but everyone
>>> that went to school was taught that 10.3 is a decimal number with an
>>> integer and a fraction part separated by a decimal point.
>>
>> In Britain, yes;
> 
> In Britain, no: America, yes.
> 
> Andrew.
> 
Fine a decimal point or a comma but not to signify a double integer.


-- 
Cecil - k5nwa

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web