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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#60450

Raimond Dragomir wrote:
> ...
> Well, I may be dumbing down my forth... let's see:
> ...
> These are very simple things that a today programmer may expect
> at least to not get a feeling it's using an alien language from Mars.
> And the forth at the heart remains a very good one, really a classical
> one. What's wrong in hiding the >R R@ return stack words from the user?
> Or giving them the possibility to use locals if they are not confortable
> with stack jugling? Or having the C '//' line comment instead of '\'?
>
> Well, my forth is not standard anymore (in fact is far from being
> standard for many other reasons). It was not in the first place,
> and I have more advanced features like quotations or building words
> (a replacement for create.. does>), but I don't expect the regular
> application programmer that will script my controllers in it to use
> these features. Unless s/he is motivated indeed...

As you say, you have gone down your own path and produced a
language that is 'forth-like'.  8th has done the same and I certainly
don't object to these.  OTOH when someone hears about 'Forth'
and Chuck Moore, I think they expect to find a language which uses
that name to embody the principles on which it was founded.
The notion 'if you don't like something in Forth, you can change it'
is not a view I share.

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

#60458

On 6/8/2017 03:34, HAA wrote:
> Raimond Dragomir wrote:
>> ...
>> Well, I may be dumbing down my forth... let's see:
>> ...
>> These are very simple things that a today programmer may expect
>> at least to not get a feeling it's using an alien language from Mars.
>> And the forth at the heart remains a very good one, really a classical
>> one. What's wrong in hiding the >R R@ return stack words from the user?
>> Or giving them the possibility to use locals if they are not confortable
>> with stack jugling? Or having the C '//' line comment instead of '\'?
>>
>> Well, my forth is not standard anymore (in fact is far from being
>> standard for many other reasons). It was not in the first place,
>> and I have more advanced features like quotations or building words
>> (a replacement for create.. does>), but I don't expect the regular
>> application programmer that will script my controllers in it to use
>> these features. Unless s/he is motivated indeed...
> 
> As you say, you have gone down your own path and produced a
> language that is 'forth-like'.  8th has done the same and I certainly
> don't object to these.  OTOH when someone hears about 'Forth'
> and Chuck Moore, I think they expect to find a language which uses
> that name to embody the principles on which it was founded.

What are they?

> The notion 'if you don't like something in Forth, you can change it'
> is not a view I share.
> 

But you don't appear to like standards. And Chuck was forever changing 
his views on Forth; qv colorForth

-- 
Alex

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

#60601

Alex wrote:
> On 6/8/2017 03:34, HAA wrote:
> > Raimond Dragomir wrote:
> >> ...
> >> Well, I may be dumbing down my forth... let's see:
> >> ...
> >> These are very simple things that a today programmer may expect
> >> at least to not get a feeling it's using an alien language from Mars.
> >> And the forth at the heart remains a very good one, really a classical
> >> one. What's wrong in hiding the >R R@ return stack words from the user?
> >> Or giving them the possibility to use locals if they are not confortable
> >> with stack jugling? Or having the C '//' line comment instead of '\'?
> >>
> >> Well, my forth is not standard anymore (in fact is far from being
> >> standard for many other reasons). It was not in the first place,
> >> and I have more advanced features like quotations or building words
> >> (a replacement for create.. does>), but I don't expect the regular
> >> application programmer that will script my controllers in it to use
> >> these features. Unless s/he is motivated indeed...
> >
> > As you say, you have gone down your own path and produced a
> > language that is 'forth-like'.  8th has done the same and I certainly
> > don't object to these.  OTOH when someone hears about 'Forth'
> > and Chuck Moore, I think they expect to find a language which uses
> > that name to embody the principles on which it was founded.
>
> What are they?
>
> > The notion 'if you don't like something in Forth, you can change it'
> > is not a view I share.
> >
>
> But you don't appear to like standards.  And Chuck was forever changing
> his views on Forth; qv colorForth

Chuck was forever changing his implementations in pursuit of his goal
which has never changed - 'Keep it simple'.  If a programmer using Forth,
be it writing apps or implementations, isn't constantly asking the question
'Have I kept it simple?', is he a Forth programmer - or just a user of Forth
words and syntax as dictated by some document.

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

#60474

On Wednesday, June 7, 2017 at 4:44:09 AM UTC-7, HAA wrote:
> Paul Rubin wrote:
> > mhx@iae.nl writes:
> > > Do you have an example where, in DECIMAL, a certain string
> > > could be both a double and a float?
> >
> > Users of other languages might well fall over laughing when they
> > hear that in Forth, "3.14159" denotes a very large integer.
> 
> You mean besides - having to work with a stack instead of variables,
> coping with non-intuitive control structures, using different operators
> for each datatype, and so on.
> 
> Makes you wonder how anyone learns Forth, right?  Yet newbies
> get the hang of it in a few days.  What it tells me is that someone who
> wants to learn, will.  Don't under-estimate the challenge and motivation
> which results from seeing great Forth code producing results.
> Dumbing down or reworking Forth in the hope it will pacify critics or
> attract users would be a miscalculation.  It will simply confirm what
> they already suspected - namely that Forth was broken to begin with.
> Nobody is going to learn a broken language.

Forth was broken to begin with. What was needed was a meaningful standard in the 1980s that fixed all the bugs that got introduced in the 1970s --- most, if not all, of Charles Moore's code was written as part of application programs, and it was written under deadline so it wasn't very clean code --- this was never intended to become part of a standard that everybody is required to follow.

Also, there are no newbies getting the hang of ANS-Forth --- everybody thinks ANS-Forth is stupid --- all that remain are gray-haired fools who have been beating this dead horse for decades, hoping that it will rise again.

It is better to admit this, than to continue white-washing the bugs for decades --- nobody is fooled by the white-wash.

I wrote STR>NUM last year and it will go into Straight Forth for use in the outer-interpreter. This is the documentation:

\ STR>INT converts strings to integers, either singles and doubles.
\ An integer is a string of digits. There may be commas throughout.
\ An integer may have a $ # or % at the front, signifying that it is hexadecimal, decimal or binary. If none of these are present, then BASE is used.
\ An integer may have a + or - at the front (after the base signifier if there is one), signifying non-negative or negative, but otherwise it is non-negative.
\ A comma at the beginning (after the sign signifier if there is one) signifies that the integer is a double, but otherwise it is a single.

\ These are valid integers:
\ $-,123,456        double: -123456 hexadecimal
\ -,123,456         double: -123456
\ ,123,456          double: 123456
\ 123,456           single: 123456

\ STR>FLT converts strings to floats.
\ A float is a string of digits. There may be commas throughout. All floats are in decimal.
\ A comma in the front is legal but should not be used as STR>NUM will interpret this as an invalid double.
\ There must be either a decimal-point or an exponent-signifier (either 'E' or 'e') or both.
\ If there is a decimal-point, there must be digits either before or after or both.
\ The first digits are the integer part. The digits after the decimal-point, if there is a decimal-point, are the fraction part.
\ The digits after the exponent-signifier, if there is an exponent-signifier, are the exponent part (scientific notation).
\ If there is an exponent-signifier, and there are no digits after it, then the exponent is assumed to be 0.
\ An exponent may have a + or - at the front, signifying non-negative or negative, but otherwise it is non-negative.

\ STR>NUM converts strings to either integers or floats.

\ These are valid floats:
\ -123,456.78       float: -123456.78
\ -123,456.78E4     float: -1234567800
\ -123,456.78E-4    float: -12.345678
\ 123E4             float: 1230000
\ 123E              float: 123

0 constant #invalid
1 constant #single
2 constant #double
3 constant #float
\ these are the kinds of numbers

\ STR>FLT differs from >FLOAT in a few ways.
\ 1.) >FLOAT will convert an empty string, or a string of blanks, into a zero.                                          STR>FLT considers this to be invalid.
\ 2.) >FLOAT will convert a string into a number if it has blanks padding either the front or back or both.             STR>FLT considers this to be invalid.
\ 3.) >FLOAT will convert a string of digits with neither a decimal point or a exponent-signifier into a number.        STR>FLT considers this to be invalid.
\ 4.) >FLOAT does not accept commas.                                                                                    STR>FLT considers this to be valid.

: str>num ( adr cnt -- #invalid | n #single | d #double | #float )  \ float: -- f (if we return a #float on the data-stack)
    ...

\ I actually forgot about >FLOAT when I wrote STR>FLT --- I could have used >FLOAT instead.
\ STR>NUM would work because it does STR>INT first so #3 above would get converted into a #SINGLE by STR>INT before >FLOAT got called.
\ I could have just special-cased #1 and #2 above as being invalid before >FLOAT got called. It is unlikely that anybody would care about #4.

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

#60275

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.

The 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 un-prefixed 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 from a copy/paste/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? Or maybe your concern is
>FLOAT and not what the interpreter does?

-marcel 

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

#60278

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.

Is that so? I always thought that the dot should be the last character
of the number.

See 8.3.1 here: https://forth-standard.org/standard/double 

I know that some implementations allow the dot to be anywhere, but then
it is their problem how they differentiate between floating point
values and double cell integers.
 
> 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.

It makes sense to be able to enter a number that is larger than a
single cell-size and to let the number interpreting word split that up
into two cells, if necessary, instead of letting the user do the
calculations. For simple numbers, that may be possible, but for larger
numbers, that gets pretty tedious.

But note that the double wordset is an extension, so if you don't need
it, leave it away.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"The wireless music box has no imaginable commercial value. Who 
 would pay for a message sent to nobody in particular?" 
 -- David Sarnoff's associates in response to his urging for 
    investment in the radio in the 1920s.

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

#60279

In article <a5b211f0-f38f-4188-9cfb-ac80ba0e482f@googlegroups.com>,
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.
>
>
>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.

Maybe but
1.000.000.000.000 in the typical Euler problem becomesus
unwieldy for 32 bits.

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

My proposal is more practical.

1. Like pascal, all numbers must start with a digit, integer or floating
point alike.
So 1E0 and no .9999E0
All numbers with an exponent sign *or* a decimal point are floating
point.
Note that Pascal numbers don't have a sign. + and - are monadic
operators. The - in -12 is the same minus as in -(a+b).
So a prefix + and - are also allowed in Forth.

I do not propose to switch to the very clunky
   1.23E12 FNEGATE
   12 NEGATE
but it show that we need + and - number prefixes.
if those words were shorter and this usage introduced in
ANSI 94 we were used to it by now.

2. Now doubles may be added for the very occasional use.
They must start *and* end with a point like so.

.12.

HEX
.FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF.
DECIMAL

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]

#60285

Matthias Trute <matthias.trute@gmail.com> writes:
>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.

The trailing dot also conflicts with floating point syntax, both the
FP input syntax of other programming languages, and the output syntax
of "F.":

SwiftForth:
12345678e f. \ outputs 12345678.

VFX:
1e f. 1.

Gforth:
1e f. 1.

Interestingly, there is no word for outputting a double in a way that
will be rcognized as double on input.  For FP we at least have "FS.".

1. d. \ outputs "1" on Gforth, SwiftForth, and VFX

>Proposal
>========
>
>Remove the trailing dot specification from the standard 
>and remove the double number as an input format for
>integer numbers.

I think that's a little extreme.  My solution is to remove the
prefixless double syntax, but leave the syntax with a prefix in, e.g.

#100000000.

>Existing sequences such as "1." are to be
>replaced with " 1 0 ".

That would mean that we cannot have portable code with double literals
beyond the range of what fits in single cells.  We may not need that
often, but we should not rule it out.

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

#60288

On Sunday, June 4, 2017 at 1:29:58 PM UTC+2, Anton Ertl wrote:
[..] 
> >Proposal
> >========
> >
> >Remove the trailing dot specification from the standard
> >and remove the double number as an input format for
> >integer numbers.
>
> I think that's a little extreme.  My solution is to remove the
> prefixless double syntax, but leave the syntax with a prefix in, e.g.
>
> #100000000.

Then the requirement of the single trailing dot could
indeed be safely removed (as the requirement to be in 
decimal when entering fp numbers):

[Sorry, I don't have VFX to test anymore]

SwiftForth i386-Win32 3.6.3 29-Jun-2016
#1111.2222.3333  ok
d. 111122223333  ok

Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
#1111.2222.3333  ok
d. 111122223333  ok

( iForth )
FORTH> #1111.2222.3333  ok
[2]FORTH> d. 111122223333  ok

-marcel

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

#60294

mhx@iae.nl writes:
>On Sunday, June 4, 2017 at 1:29:58 PM UTC+2, Anton Ertl wrote:
>[..] 
>> >Proposal
>> >========
>> >
>> >Remove the trailing dot specification from the standard
>> >and remove the double number as an input format for
>> >integer numbers.
>>
>> I think that's a little extreme.  My solution is to remove the
>> prefixless double syntax, but leave the syntax with a prefix in, e.g.
>>
>> #100000000.
>
>Then the requirement of the single trailing dot could
>indeed be safely removed

You mean the requirement of only one dot, and that has to be trailing?  Yes.

>(as the requirement to be in 
>decimal when entering fp numbers):

In Gforth, SwiftForth, and VFX,

  decimal 1e

produces an FP value, while

  hex 1e

produces an integer.

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

#60296

 
> I think that's a little extreme.

Indeed. What I find at least worth discussing is whether
it is really useful and necessary to input double numbers
directly. They have an rather artificial syntax and very
little benefit. Double numbers by itself are highly useful.

>  My solution is to remove the
> prefixless double syntax, but leave the syntax with a prefix in, e.g.
> 
> #100000000.

does it mean that a prefix-less 1. can be considered a floating point
number?

> 
> That would mean that we cannot have portable code with double literals
> beyond the range of what fits in single cells.  We may not need that
> often, but we should not rule it out.

Nope, we can have double number literals, but not in the form 1. but
1 0 (a dot should follow, but looks confusing). A DLITERAL does nothing
else.

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

#60298

Matthias Trute <matthias.trute@gmail.com> writes:
> 
>> I think that's a little extreme.
>
>Indeed. What I find at least worth discussing is whether
>it is really useful and necessary to input double numbers
>directly. They have an rather artificial syntax and very
>little benefit. Double numbers by itself are highly useful.
>
>>  My solution is to remove the
>> prefixless double syntax, but leave the syntax with a prefix in, e.g.
>> 
>> #100000000.
>
>does it mean that a prefix-less 1. can be considered a floating point
>number?

It would be non-standard (at least at first).  Systems could recognize
"1." as FP number.  If common practice in this direction emerges, one
could standardize that.

>> That would mean that we cannot have portable code with double literals
>> beyond the range of what fits in single cells.  We may not need that
>> often, but we should not rule it out.
>
>Nope, we can have double number literals, but not in the form 1. but
>1 0 (a dot should follow, but looks confusing).

How do you write a number larger than 2^15-1, and one larger than
2^31-1 etc.  To illustrate the problem:

[~/gforth:94611] gforth
Gforth 0.7.9_20170601, Copyright (C) 1995-2016 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
12345 150 d. 2767011611056432754745  ok

[~/gforth:94612] vfxlin
VFX Forth for Linux IA32 Version: 4.72 [build 0555]
12345 150 d. 644245106745  ok

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

#60300

Op Sun, 4 Jun 2017 09:10:50 -0700 (PDT) schreef Matthias Trute:

>  
>> I think that's a little extreme.
> 
> Indeed. What I find at least worth discussing is whether
> it is really useful and necessary to input double numbers
> directly. They have an rather artificial syntax and very
> little benefit. Double numbers by itself are highly useful.
> 
>>  My solution is to remove the
>> prefixless double syntax, but leave the syntax with a prefix in, e.g.
>> 
>> #100000000.
> 
> does it mean that a prefix-less 1. can be considered a floating point
> number?
> 
>> 
>> That would mean that we cannot have portable code with double literals
>> beyond the range of what fits in single cells.  We may not need that
>> often, but we should not rule it out.
> 
> Nope, we can have double number literals, but not in the form 1. but
> 1 0 (a dot should follow, but looks confusing). A DLITERAL does nothing
> else.

That would mean that in a 16 bit implemetation to write
  16960 15
for entering one million and
  51712 15258
as one milliard?

Forget it!

P.S. one (European continental) billion (10^12) does not fit in 32 bit.

groet Coos

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

#60413

Am 04.06.2017 um 12:18 schrieb Anton Ertl:
> I think that's a little extreme.  My solution is to remove the
> prefixless double syntax, but leave the syntax with a prefix in, e.g.
> 
> #100000000.

And for that purpose we added a warning message in Gforth (for newbies) 
when you enter

1.

or somesuch.  If you got rid of all those warnings by changing your 
sources to have all doubles with base prefixes, you then can flip around 
the recognizer order

rec:word rec:num rec:float -> rec:word rec:float rec:num

and then

1.

is recognized as floating point.

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

#60420

Am Mittwoch, 7. Juni 2017 01:21:53 UTC+2 schrieb Bernd Paysan:
> Am 04.06.2017 um 12:18 schrieb Anton Ertl:
> > I think that's a little extreme.  My solution is to remove the
> > prefixless double syntax, but leave the syntax with a prefix in, e.g.
> > 
> > #100000000.
> 
> And for that purpose we added a warning message in Gforth (for newbies) 
> when you enter
> 
> 1.
> 
> or somesuch.  If you got rid of all those warnings by changing your 
> sources to have all doubles with base prefixes, you then can flip around 
> the recognizer order
> 
> rec:word rec:num rec:float -> rec:word rec:float rec:num
> 
> and then
> 
> 1.
> 
> is recognized as floating point.

Yes this works. But it's rather unsexy, to hobble with those ugly crutches
around poor basic syntax definitions.

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

#60421

On Wednesday, June 7, 2017 at 12:57:04 AM UTC-5, minf...@arcor.de wrote:
> Yes this works. But it's rather unsexy, to hobble with those ugly crutches
> around poor basic syntax definitions.

I'm not impressed by the creative ways people have in this thread of
saying "it's weird". You may as well use all caps, repetition, and
then screaming, arm-flailing tantrums.

You come to Forth, a rare language with a standard that doesn't rot
your code away every few years based on someone's momentary whim, and
even though this is *also* a language that has so many tools that
should satisfy you -- well, they don't. That stuff "works", but it's
"unsexy".


Time 0:

  ######
  #$   #
  #@$$$#
  #    #
  ######

>there's more gold to the right, get it.

Time 3:

  ######
  #$   #
  #   @#
  #    #
  ######

>what are you an idiot? You should've moved up to get the gold there!
>That's the only gold around--that's only gold here in time 3. From
>the perspective of time 3 and only time 3, you've been wandering in
>random bloody directions! It's going to take you *ages* to get over to
>the top left corner!

>Well fortunately there's an escape. Just throw away any gold you have
>and you can start where you were, and make the CORRECT choice this
>time.

Time 0 (revised):

  ######
  #$   #
  #@   #
  #    #
  ######

>get the one piece of gold available on this map.
>not a lot of treasure here but that's life I guess :(


What makes sense over time doesn't always look like what makes sense
at every later instant in time. Try being creative with Forth programs
instead of ways of complaining about utterly trivial unimportant shit
like "oh this language has some quirky literals LIKE EVERY OTHER
PROGRAMMING LANGUAGE".

Tomorrow:

  RFD: Drop the space after S"
  Yes I could do this with recognizers but that's "unsexy".
  No other language has stupid string syntax.
  Look at Python: u'competely sensible unicode strings'
  Python's popular! Therefore I'm right.
  You just hate pointless sexy change.

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

#60427

Am Mittwoch, 7. Juni 2017 08:34:45 UTC+2 schrieb Julian Fondren:
> On Wednesday, June 7, 2017 at 12:57:04 AM UTC-5, minf...@arcor.de wrote:
> > Yes this works. But it's rather unsexy, to hobble with those ugly crutches
> > around poor basic syntax definitions.
> 
> I'm not impressed by the creative ways people have in this thread of
> saying "it's weird". You may as well use all caps, repetition, and
> then screaming, arm-flailing tantrums.
> 
> You come to Forth, a rare language with a standard that doesn't rot
> your code away every few years based on someone's momentary whim, and
> even though this is *also* a language that has so many tools that
> should satisfy you -- well, they don't. That stuff "works", but it's
> "unsexy".
> 
> 
> Time 0:
> 
>   ######
>   #$   #
>   #@$$$#
>   #    #
>   ######
> 
> >there's more gold to the right, get it.
> 
> Time 3:
> 
>   ######
>   #$   #
>   #   @#
>   #    #
>   ######
> 
> >what are you an idiot? You should've moved up to get the gold there!
> >That's the only gold around--that's only gold here in time 3. From
> >the perspective of time 3 and only time 3, you've been wandering in
> >random bloody directions! It's going to take you *ages* to get over to
> >the top left corner!
> 
> >Well fortunately there's an escape. Just throw away any gold you have
> >and you can start where you were, and make the CORRECT choice this
> >time.
> 
> Time 0 (revised):
> 
>   ######
>   #$   #
>   #@   #
>   #    #
>   ######
> 
> >get the one piece of gold available on this map.
> >not a lot of treasure here but that's life I guess :(
> 
> 
> What makes sense over time doesn't always look like what makes sense
> at every later instant in time. Try being creative with Forth programs
> instead of ways of complaining about utterly trivial unimportant shit
> like "oh this language has some quirky literals LIKE EVERY OTHER
> PROGRAMMING LANGUAGE".
> 
> Tomorrow:
> 
>   RFD: Drop the space after S"
>   Yes I could do this with recognizers but that's "unsexy".
>   No other language has stupid string syntax.
>   Look at Python: u'competely sensible unicode strings'
>   Python's popular! Therefore I'm right.
>   You just hate pointless sexy change.

So you have vented off some overpressure. Good for you.  ;-))

IMO the point is not that recognizers work, but that they are _needed_
at all to overcome handling a weird syntax.

Forth is also about making things simple and straightforward. And in this
case those discussed literal formats are not simple and straightforward.

It would be so much simpler to improve the documents instead of complicating
implementations.

That's the unsexiness of it, basically.

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

#60428

On Sunday, June 4, 2017 at 10:25:59 AM UTC+2, Matthias Trute wrote:
> A radical one. I admit.
I thought so too when I dropped double (and hence mixed and unsigned numbers) completely from (native) 4tH. Yes, even <# # # #> works only with signed cells - hence S>D is a dummy to allow writing portable code.

Nowadays mixed and double words are supported by libraries, which works quite well - given it supports an entire FP library with no ill effects. Since 4tH has no recognizers you need s" 12345" S>DOUBLE or U>D (S>D is taken, remember?) to convert to double numbers, which is kind of awkward, but all in all I never regretted that decision. It made the whole thing much more consistent and IMHO easier to understand.

Hans Bezemer

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

#60429

On Sunday, 4 June 2017 09:25:59 UTC+1, 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.

It may be common practice, but it is not at present an entitlement. Only the single trailing . is universally valid. In which languages is 1. as opposed to 1.0 both a valid floating point number and commonly used as such? And does any language use floating point in a base other than decimal?

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

It can be, but it's only easy for the trivial cases like 1. and 2. not for 'magic numbers'. 

I would suggest keeping the existing strict spec for BASE-dependent double numbers but encouraging the use of based prefixes by allowing any number of non-digit separators. Thus:

  #-1,000,000,000
  %1001/1000/1110/1101
  $dead-beef

should all be valid double numbers.
  
> 

> 
> 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] | [prev] | [next] | [standalone]

#60475

> 
> I would suggest keeping the existing strict spec for BASE-dependent double numbers but encouraging the use of based prefixes by allowing any number of non-digit separators. Thus:
> 
>   #-1,000,000,000
>   %1001/1000/1110/1101
>   $dead-beef
> 
> should all be valid double numbers.
>   
> > 
> 
> > 
> > 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 ".

I like this one.
This would make Forth appear more "normal" "rational" (pick your own word) to 
newbies.

If there was a standard way to add this functionality to a "standard" system 
that would be ideal but I may be dreaming in full colour with that idea. 

B

[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