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


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

Double integer input

Started byRosangela Medeiros da Silva <rosangelamesil@gmail.com>
First post2013-02-13 18:15 -0800
Last post2013-02-24 08:16 -1000
Articles 20 on this page of 56 — 18 participants

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


Contents

  Double integer input Rosangela Medeiros da Silva <rosangelamesil@gmail.com> - 2013-02-13 18:15 -0800
    Re: Double integer input Rosangela Medeiros da Silva <rosangelamesil@gmail.com> - 2013-02-14 02:07 -0800
      Re: Double integer input Coos Haak <chforth@hccnet.nl> - 2013-02-14 16:18 +0100
        Re: Double integer input Coos Haak <chforth@hccnet.nl> - 2013-02-14 16:27 +0100
        Re: Double integer input "A. K." <akk@nospam.org> - 2013-02-14 20:54 +0100
          Re: Double integer input Coos Haak <chforth@hccnet.nl> - 2013-02-14 23:20 +0100
    Re: Double integer input "Ed" <invalid@nospam.com> - 2013-02-22 11:00 +1100
      Re: Double integer input "Elizabeth D. Rather" <erather@forth.com> - 2013-02-21 14:24 -1000
        Re: Double integer input Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 01:50 +0100
          Re: Double integer input anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-22 15:35 +0000
            Re: Double integer input Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 18:15 +0100
              Re: Double integer input stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-22 19:02 +0000
              Re: Double integer input anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-23 17:27 +0000
                Re: Double integer input Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-24 03:42 +0100
            Re: Double integer input "Elizabeth D. Rather" <erather@forth.com> - 2013-02-22 09:08 -1000
              Re: Double integer input anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-23 16:15 +0000
                Re: Double integer input stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-23 17:35 +0000
                  Re: Double integer input anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-25 15:25 +0000
                Re: Double integer input albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-23 19:34 +0000
                  Re: Double integer input "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-23 18:35 -0500
                Re: Double integer input Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-23 14:58 -0600
                  Re: Double integer input Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-23 22:01 +0100
                    Re: Double integer input albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-24 04:03 +0000
                    Re: Double integer input "Elizabeth D. Rather" <erather@forth.com> - 2013-02-23 18:13 -1000
                      Re: Double integer input Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-24 12:01 +0100
                      Re: Double integer input anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-25 18:09 +0000
                  Re: Double integer input rickman <gnuarm@gmail.com> - 2013-02-24 15:01 -0500
                    Re: Double integer input Coos Haak <chforth@hccnet.nl> - 2013-02-25 01:13 +0100
                      Re: Double integer input Mark Wills <markrobertwills@yahoo.co.uk> - 2013-02-24 23:44 -0800
                      Re: Double integer input rickman <gnuarm@gmail.com> - 2013-02-27 07:47 -0500
                    Re: Double integer input Mark Wills <markrobertwills@yahoo.co.uk> - 2013-02-24 23:42 -0800
                      Re: Double integer input Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-25 03:57 -0600
                      Re: Double integer input albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-25 14:09 +0000
                    Re: Double integer input Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 16:45 +0100
                      Re: Double integer input Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-25 18:26 -0600
                        Re: Double integer input Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-26 02:04 +0100
                          Re: Double integer input Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-26 05:10 -0600
                            Re: Double integer input Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-26 15:31 +0100
                              Re: Double integer input Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-26 10:28 -0600
                  Re: Double integer input anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-25 16:38 +0000
                Re: Double integer input rickman <gnuarm@gmail.com> - 2013-02-24 14:54 -0500
                  Re: Double integer input "Elizabeth D. Rather" <erather@forth.com> - 2013-02-24 11:59 -1000
                  Re: Double integer input anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-25 18:11 +0000
                    Re: Double integer input rickman <gnuarm@gmail.com> - 2013-02-27 07:58 -0500
                      Re: Double integer input anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 17:10 +0000
        Re: Double integer input "Ed" <invalid@nospam.com> - 2013-02-22 13:22 +1100
          Re: Double integer input "Elizabeth D. Rather" <erather@forth.com> - 2013-02-21 16:31 -1000
        Re: Double integer input Alex McDonald <blog@rivadpm.com> - 2013-02-22 04:54 -0800
          Re: Double integer input "WJ" <w_a_x_man@yahoo.com> - 2013-02-24 22:05 +0000
            Re: Double integer input Paul Rubin <no.email@nospam.invalid> - 2013-02-24 15:02 -0800
            Re: Double integer input Brad Eckert <hwfwguy@gmail.com> - 2013-02-25 09:22 -0800
              Re: Double integer input Brad Eckert <hwfwguy@gmail.com> - 2013-02-25 10:21 -0800
            Re: Double integer input Alex McDonald <blog@rivadpm.com> - 2013-02-26 07:47 -0800
          Re: Double integer input "WJ" <w_a_x_man@yahoo.com> - 2013-02-28 06:27 +0000
        Re: Double integer input Paul Rubin <no.email@nospam.invalid> - 2013-02-23 21:34 -0800
          Re: Double integer input "Elizabeth D. Rather" <erather@forth.com> - 2013-02-24 08:16 -1000

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


#19720 — Double integer input

FromRosangela Medeiros da Silva <rosangelamesil@gmail.com>
Date2013-02-13 18:15 -0800
SubjectDouble integer input
Message-ID<dddbd9b1-de8c-4e44-ae90-b67572a1bb53@googlegroups.com>
I am not a Forth programmer, therefore be patient with me. I was using a Forth that considered that any string of digits with an internal point represents a double precision integer. Therefore, I could write code like the following snippet:

: dollars <# # # [CHAR] . HOLD #S [CHAR] $ HOLD #> TYPE ;

: % 100 M*/ dollars ;

45.60 50 %
$22.80 Ok

For reasons I cannot fathom, people around me started using sp-forth, that does not accept the internal point. However, I know that sp-forth has many libraries and extensions. I wonder whether one of these extensions could handle an internal point. It is really necessary, because it indicates the scale of the programs I am using.

By the way, VFX forth accepts internal points:

45.67  ok-2 
D. 4567  ok

The same happens to lina:
45.67
 OK
D.
4567  OK



[toc] | [next] | [standalone]


#19725

FromRosangela Medeiros da Silva <rosangelamesil@gmail.com>
Date2013-02-14 02:07 -0800
Message-ID<4db502a4-99db-4829-a4ab-491993e8b46c@googlegroups.com>
In reply to#19720
I received a message privately. The problem is that the message was in Russian, and I couldn't make sense of it. Please, write in English if you want me to understand what you mean.

By the way, I want that numbers with an embedded decimal point be recognized as double precision by the SP-Forth compiler. I need a ready to use definition, since I am a Forth user, not a programmer. 

I also believe that the answer may be of use for many people in this group. Therefore, it would be great if you people post your articles here, instead of writing me.

 

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


#19729

FromCoos Haak <chforth@hccnet.nl>
Date2013-02-14 16:18 +0100
Message-ID<o4a89t6jerk0.hch2hpn59dyb$.dlg@40tude.net>
In reply to#19725
Op Thu, 14 Feb 2013 02:07:16 -0800 (PST) schreef Rosangela Medeiros da
Silva:

> I received a message privately. The problem is that the message was in Russian, and I couldn't make sense of it. Please, write in English if you want me to understand what you mean.
> 
> By the way, I want that numbers with an embedded decimal point be recognized as double precision by the SP-Forth compiler. I need a ready to use definition, since I am a Forth user, not a programmer. 
> 
> I also believe that the answer may be of use for many people in this group. Therefore, it would be great if you people post your articles here, instead of writing me.
>

ANS Forth describes that a number followed with a decimal point is
interpreted as a double number. Some Forths use this to regard numbers with
a decimal point embedded in the numbers as floating point.
So 1234. would be the double number (1234 0) and 1.234 would be the
floating point number 1.234e3
This way, simple f.p. numbers can be written without exponential E and an
exponent.

Earlier Forths like Figforth had no floating point, so the decimal point
was allowed anywhere in a double number.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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


#19730

FromCoos Haak <chforth@hccnet.nl>
Date2013-02-14 16:27 +0100
Message-ID<1o4mtle2f2p27.131gh69tmn4ke$.dlg@40tude.net>
In reply to#19729
Op Thu, 14 Feb 2013 16:18:01 +0100 schreef Coos Haak:

> Op Thu, 14 Feb 2013 02:07:16 -0800 (PST) schreef Rosangela Medeiros da
> Silva:
> 
>> I received a message privately. The problem is that the message was in Russian, and I couldn't make sense of it. Please, write in English if you want me to understand what you mean.
>> 
>> By the way, I want that numbers with an embedded decimal point be recognized as double precision by the SP-Forth compiler. I need a ready to use definition, since I am a Forth user, not a programmer. 
>> 
>> I also believe that the answer may be of use for many people in this group. Therefore, it would be great if you people post your articles here, instead of writing me.
>>
> 
> ANS Forth describes that a number followed with a decimal point is
> interpreted as a double number. Some Forths use this to regard numbers with
> a decimal point embedded in the numbers as floating point.
> So 1234. would be the double number (1234 0) and 1.234 would be the
> floating point number 1.234e3
> This way, simple f.p. numbers can be written without exponential E and an
> exponent.
> 
> Earlier Forths like Figforth had no floating point, so the decimal point
> was allowed anywhere in a double number.

Here is an English info on SP-FORTH: 
http://spf.sourceforge.net/docs/intro.en.html#numbers
http://spf.sourceforge.net/docs/intro.en.html#float

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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


#19733

From"A. K." <akk@nospam.org>
Date2013-02-14 20:54 +0100
Message-ID<511d40f1$0$9504$9b4e6d93@newsspool1.arcor-online.net>
In reply to#19729
On 14.02.2013 16:18, Coos Haak wrote:
> Op Thu, 14 Feb 2013 02:07:16 -0800 (PST) schreef Rosangela Medeiros da
> Silva:
>
>> I received a message privately. The problem is that the message was in Russian, and I couldn't make sense of it. Please, write in English if you want me to understand what you mean.
>>
>> By the way, I want that numbers with an embedded decimal point be recognized as double precision by the SP-Forth compiler. I need a ready to use definition, since I am a Forth user, not a programmer.
>>
>> I also believe that the answer may be of use for many people in this group. Therefore, it would be great if you people post your articles here, instead of writing me.
>>
>
> ANS Forth describes that a number followed with a decimal point is
> interpreted as a double number. Some Forths use this to regard numbers with
> a decimal point embedded in the numbers as floating point.
> So 1234. would be the double number (1234 0) and 1.234 would be the
> floating point number 1.234e3
> This way, simple f.p. numbers can be written without exponential E and an
> exponent.
>
> Earlier Forths like Figforth had no floating point, so the decimal point
> was allowed anywhere in a double number.
>

 From the ANS document:

The Technical Committee has more than once received the suggestion that 
the text interpreter in Standard Forth systems should treat numbers that 
have an embedded decimal point, but no exponent, as floating-point 
numbers rather than double cell numbers. This suggestion, although it 
has merit, has always been voted down because it would break too much 
existing code;

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


#19737

FromCoos Haak <chforth@hccnet.nl>
Date2013-02-14 23:20 +0100
Message-ID<n3zbnaqiixs9.ojcylh3lkgiw$.dlg@40tude.net>
In reply to#19733
Op Thu, 14 Feb 2013 20:54:26 +0100 schreef A. K.:

> On 14.02.2013 16:18, Coos Haak wrote:
>> Op Thu, 14 Feb 2013 02:07:16 -0800 (PST) schreef Rosangela Medeiros da
>> Silva:
>>
>>> I received a message privately. The problem is that the message was in Russian, and I couldn't make sense of it. Please, write in English if you want me to understand what you mean.
>>>
>>> By the way, I want that numbers with an embedded decimal point be recognized as double precision by the SP-Forth compiler. I need a ready to use definition, since I am a Forth user, not a programmer.
>>>
>>> I also believe that the answer may be of use for many people in this group. Therefore, it would be great if you people post your articles here, instead of writing me.
>>>
>>
>> ANS Forth describes that a number followed with a decimal point is
>> interpreted as a double number. Some Forths use this to regard numbers with
>> a decimal point embedded in the numbers as floating point.
>> So 1234. would be the double number (1234 0) and 1.234 would be the
>> floating point number 1.234e3
>> This way, simple f.p. numbers can be written without exponential E and an
>> exponent.
>>
>> Earlier Forths like Figforth had no floating point, so the decimal point
>> was allowed anywhere in a double number.
>>
> 
>  From the ANS document:
> 
> The Technical Committee has more than once received the suggestion that 
> the text interpreter in Standard Forth systems should treat numbers that 
> have an embedded decimal point, but no exponent, as floating-point 
> numbers rather than double cell numbers. This suggestion, although it 
> has merit, has always been voted down because it would break too much 
> existing code;

Agreed, therefore I wrote 'some Forths'.
Regarding my followup, it turns out that SP-Forth allows a trailing dot, 
but f.p. numbers require an exponent.

So 'some Forths' is probably near to zero.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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


#19891

From"Ed" <invalid@nospam.com>
Date2013-02-22 11:00 +1100
Message-ID<kg6cg1$a3b$1@speranza.aioe.org>
In reply to#19720
Rosangela Medeiros da Silva wrote:
> I am not a Forth programmer, therefore be patient with me. I was using a Forth that
> considered that any string of digits with an internal point represents a double precision
> integer. Therefore, I could write code like the following snippet:
>
> : dollars <# # # [CHAR] . HOLD #S [CHAR] $ HOLD #> TYPE ;
>
> : % 100 M*/ dollars ;
>
> 45.60 50 %
> $22.80 Ok
>
> For reasons I cannot fathom, people around me started using sp-forth, that does not accept
> the internal point. However, I know that sp-forth has many libraries and extensions. I
> wonder whether one of these extensions could handle an internal point. It is really
> necessary, because it indicates the scale of the programs I am using.
>
> By the way, VFX forth accepts internal points:
>
> 45.67  ok-2
> D. 4567  ok
>
> The same happens to lina:
> 45.67
>  OK
> D.
> 4567  OK

Confusing and open to user error, isn't it.

45.6  50 %
$2.28 ok

45+60 50 %
$22.80 ok


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


#19893

From"Elizabeth D. Rather" <erather@forth.com>
Date2013-02-21 14:24 -1000
Message-ID<brWdnQmhLoxDJ7vMnZ2dnUVZ_uKdnZ2d@supernews.com>
In reply to#19891
On 2/21/13 2:00 PM, Ed wrote:
> Rosangela Medeiros da Silva wrote:
>> I am not a Forth programmer, therefore be patient with me. I was using a Forth that
>> considered that any string of digits with an internal point represents a double precision
>> integer. Therefore, I could write code like the following snippet:
>>
>> : dollars <# # # [CHAR] . HOLD #S [CHAR] $ HOLD #> TYPE ;
>>
>> : % 100 M*/ dollars ;
>>
>> 45.60 50 %
>> $22.80 Ok
>>
>> For reasons I cannot fathom, people around me started using sp-forth, that does not accept
>> the internal point. However, I know that sp-forth has many libraries and extensions. I
>> wonder whether one of these extensions could handle an internal point. It is really
>> necessary, because it indicates the scale of the programs I am using.
>>
>> By the way, VFX forth accepts internal points:
>>
>> 45.67  ok-2
>> D. 4567  ok
>>
>> The same happens to lina:
>> 45.67
>>   OK
>> D.
>> 4567  OK
>
> Confusing and open to user error, isn't it.
>
> 45.6  50 %
> $2.28 ok
>
> 45+60 50 %
> $22.80 ok

It is very unfortunate that the Forth community hasn't managed to 
standardize the inputting of double integers. Historically, many Forths 
have used an internal decimal point to indicate double precision 
integers, but over the years some used it to indicate FP. Requiring only 
a decimal point at the right with an optional exponent was the best 
compromise the Forth94 TC could reach.

Because FORTH, Inc's heritage was making telescope control systems, we 
have always allowed most internal punctuation to make double precision 
integers: . , - (phone#s, social security #s, etc.), / (dates), even : 
(angles). But almost nobody picked up this practice. Too bad, it's 
extremely convenient!

However, one of the standard class problems in my courses and in Forth 
application techniques is to write a special-purpose number input 
function (most recently, for IP addresses: 4 subsections separated only 
by . to yield 4 octets in an array). It's really quite easy :-)

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]


#19898

FromBernd Paysan <bernd.paysan@gmx.de>
Date2013-02-22 01:50 +0100
Message-ID<kg6fbr$9m5$1@online.de>
In reply to#19893
Elizabeth D. Rather wrote:
> Because FORTH, Inc's heritage was making telescope control systems, we
> have always allowed most internal punctuation to make double precision
> integers: . , - (phone#s, social security #s, etc.), / (dates), even :
> (angles). But almost nobody picked up this practice. Too bad, it's
> extremely convenient!

I once had this in bigForth, too, and this went over to early versions of 
Gforth.  As nobody used it, we dropped that feature.  I had ",-./" as 
allowed separators, because they are in line in ASCII.  The code didn't 
change much when I reduced to . and , as allowed separators in bigForth (in 
Gforth, it's . only), it's now disallowing odd separators.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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


#19910

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2013-02-22 15:35 +0000
Message-ID<2013Feb22.163514@mips.complang.tuwien.ac.at>
In reply to#19898
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Elizabeth D. Rather wrote:
>> Because FORTH, Inc's heritage was making telescope control systems, we
>> have always allowed most internal punctuation to make double precision
>> integers: . , - (phone#s, social security #s, etc.), / (dates), even :
>> (angles). But almost nobody picked up this practice. Too bad, it's
>> extremely convenient!
>
>I once had this in bigForth, too, and this went over to early versions of 
>Gforth.  As nobody used it, we dropped that feature.  I had ",-./" as 
>allowed separators, because they are in line in ASCII.  The code didn't 
>change much when I reduced to . and , as allowed separators in bigForth (in 
>Gforth, it's . only), it's now disallowing odd separators.

And there was a specific occasion that lead to taking out "," in
Gforth: I wrote a priece of code that used "2,", and it compiled fine
but did not work.  Eventually I found that Gforth at the time had no
word "2,", but it had "," as double indicator.  So it saw a double
literal instead of the word "2,".  With Elisabeth's list, "2-" would
be another trap.

- 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 2013: http://www.euroforth.org/ef13/

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


#19915

FromBernd Paysan <bernd.paysan@gmx.de>
Date2013-02-22 18:15 +0100
Message-ID<kg893n$u6q$1@online.de>
In reply to#19910
Anton Ertl wrote:
> And there was a specific occasion that lead to taking out "," in
> Gforth: I wrote a priece of code that used "2,", and it compiled fine
> but did not work.  Eventually I found that Gforth at the time had no
> word "2,", but it had "," as double indicator.  So it saw a double
> literal instead of the word "2,".  With Elisabeth's list, "2-" would
> be another trap.

Yes, but today, 2- is floating point for 2, just like 2+.  We didn't take 
that out, every word that converts to a sensible floating point number with 
>FLOAT is accepted as input.  With our new recognizers, we could implement a 
<number>+ and <number>- recognizer, which would eliminate that trap, and 
just compile the literal + and literal - instead (* and / as well).

Back then, we didn't have a fontlock mode for Emacs (and Emacs didn't have 
fontlock at all, and screens didn't have color, at least the ones I had ;-).  
That would probably have made it easier to debug, if it had correctly 
highlighted 2, as number.

Currently, Gforth has dp-char and fp-char, following MPE, which allows us to 
switch to MPE mode, which is ',' for doubles and '.' for float.  I'm not 
sure if this is all rigth.  My suggestion would be a configuration register 
for dp and fp sepearators, which is a 32 bit mask for the characters between 
$20 and $3F.  But all that has the global state disadvantage - you need to 
say which mode you want to be in, when you aren't in standard mode, and when 
your program is a library, you don't want to disturb the users.

You might also have allowed characters and decimal point characters, so e.g. 
123'456'789.123'456 is valid, and only the decimal point itself is treated 
as such.  Makes numbers more readable.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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


#19924

FromstephenXXX@mpeforth.com (Stephen Pelc)
Date2013-02-22 19:02 +0000
Message-ID<5127c03d.834007100@192.168.0.50>
In reply to#19915
On Fri, 22 Feb 2013 18:15:33 +0100, Bernd Paysan <bernd.paysan@gmx.de>
wrote:

>Currently, Gforth has dp-char and fp-char, following MPE, which allows us to 
>switch to MPE mode, which is ',' for doubles and '.' for float.  I'm not 
>sure if this is all rigth.

In the current version, note that DP-CHAR and FP-CHAR are cells
containing up to four characters. 

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]


#19951

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2013-02-23 17:27 +0000
Message-ID<2013Feb23.182701@mips.complang.tuwien.ac.at>
In reply to#19915
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> And there was a specific occasion that lead to taking out "," in
>> Gforth: I wrote a priece of code that used "2,", and it compiled fine
>> but did not work.  Eventually I found that Gforth at the time had no
>> word "2,", but it had "," as double indicator.  So it saw a double
>> literal instead of the word "2,".  With Elisabeth's list, "2-" would
>> be another trap.
>
>Yes, but today, 2- is floating point for 2, just like 2+.  We didn't take 
>that out, every word that converts to a sensible floating point number with 
>>FLOAT is accepted as input.

Actually until recently, there was a check for the syntax of a number
on the Forth level, and it did not accept "2-" as float, so we did
take that out:

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
2- 
:1: Undefined word
>>>2-<<<

Maybe you eliminated that syntax check in your recent work on
recognizers.  I think it would be a good idea to put it back in.

>With our new recognizers, we could implement a 
><number>+ and <number>- recognizer, which would eliminate that trap, and 
>just compile the literal + and literal - instead (* and / as well).

That would also be a possibility, but I wonder if this is not too much
magic for too little benefit.

>Currently, Gforth has dp-char and fp-char, following MPE, which allows us to 
>switch to MPE mode, which is ',' for doubles and '.' for float.  I'm not 
>sure if this is all rigth.  My suggestion would be a configuration register 
>for dp and fp sepearators, which is a 32 bit mask for the characters between 
>$20 and $3F.  But all that has the global state disadvantage - you need to 
>say which mode you want to be in, when you aren't in standard mode, and when 
>your program is a library, you don't want to disturb the users.

If we have a way to properly scope this kind of feature, it may be ok,
otherwise I consider it too dangerous for general consumption.

- 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 2013: http://www.euroforth.org/ef13/

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


#19978

FromBernd Paysan <bernd.paysan@gmx.de>
Date2013-02-24 03:42 +0100
Message-ID<kgbulp$mtc$1@online.de>
In reply to#19951
Anton Ertl wrote:
> Actually until recently, there was a check for the syntax of a number
> on the Forth level, and it did not accept "2-" as float, so we did
> take that out:
> 
> 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
> 2-
> :1: Undefined word
>>>>2-<<<
> 
> Maybe you eliminated that syntax check in your recent work on
> recognizers.  I think it would be a good idea to put it back in.

That check went out with the MPE compatibility stuff (dp-char and fp-char); 
the idea is that in MPE mode, you can enter just 13.3 and get a floating 
point value (no e needed).

I will add that check back in when fp-char and dp-char are equal, i.e. in 
Gforth mode.  As you have to set MPE-mode explicitely, that's following the 
principle of least surprise.  Gforth is more sloppy than MPE in MPE mode, 
following the Postel principle.

As VFX allows now for more than one separator char, I have to revisit that 
compatibility anyways.

The recognizer changes added a completely unrelated feature, you can now 
have engineering numbers, like "2u2" or "12k8".

BTW MPE mode and ANS mode: Stephen, you have two nice definitions in the 
*documentation* of the floating point library: ans-floats and mpe-floats.  
Take them out of the documentation and put them into the actual source code.  
These words are too useful!

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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


#19925

From"Elizabeth D. Rather" <erather@forth.com>
Date2013-02-22 09:08 -1000
Message-ID<H-qdnbjG_ZCNX7rMnZ2dnUVZ_sidnZ2d@supernews.com>
In reply to#19910
On 2/22/13 5:35 AM, Anton Ertl wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Elizabeth D. Rather wrote:
>>> Because FORTH, Inc's heritage was making telescope control systems, we
>>> have always allowed most internal punctuation to make double precision
>>> integers: . , - (phone#s, social security #s, etc.), / (dates), even :
>>> (angles). But almost nobody picked up this practice. Too bad, it's
>>> extremely convenient!
>>
>> I once had this in bigForth, too, and this went over to early versions of
>> Gforth.  As nobody used it, we dropped that feature.  I had ",-./" as
>> allowed separators, because they are in line in ASCII.  The code didn't
>> change much when I reduced to . and , as allowed separators in bigForth (in
>> Gforth, it's . only), it's now disallowing odd separators.
>
> And there was a specific occasion that lead to taking out "," in
> Gforth: I wrote a priece of code that used "2,", and it compiled fine
> but did not work.  Eventually I found that Gforth at the time had no
> word "2,", but it had "," as double indicator.  So it saw a double
> literal instead of the word "2,".  With Elisabeth's list, "2-" would
> be another trap.

If know that punctuation makes doubles, you don't make names that look 
like punctuated numbers, just as you don't make names that look like 
"-2". It really isn't that hard!

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]


#19949

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2013-02-23 16:15 +0000
Message-ID<2013Feb23.171502@mips.complang.tuwien.ac.at>
In reply to#19925
"Elizabeth D. Rather" <erather@forth.com> writes:
>> And there was a specific occasion that lead to taking out "," in
>> Gforth: I wrote a priece of code that used "2,", and it compiled fine
>> but did not work.  Eventually I found that Gforth at the time had no
>> word "2,", but it had "," as double indicator.  So it saw a double
>> literal instead of the word "2,".  With Elisabeth's list, "2-" would
>> be another trap.
>
>If know that punctuation makes doubles, you don't make names that look 
>like punctuated numbers, just as you don't make names that look like 
>"-2". It really isn't that hard!

Well, the problem was that Gforth did not have a name "2,", but I
expected it to, and it accepted "2," (but as a number).

Now "," is a regular Forth word, and words for dealing with two cells
(or doubles) are commonly formed by prepending 2 (Forth-94 has 2! 2>R
2@ 2CONSTANT 2DROP 2DUP 2LITERAL 2OVER 2R> 2R@ 2ROT 2SWAP 2VARIABLE),
so "2," is a likely word name.

If punctuation in word names was a mistake, the mistake was to have a
word called ",".

However, I believe that having "," in numbers was a mistake.

- 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 2013: http://www.euroforth.org/ef13/

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


#19952

FromstephenXXX@mpeforth.com (Stephen Pelc)
Date2013-02-23 17:35 +0000
Message-ID<5128fc79.914962618@192.168.0.50>
In reply to#19949
On Sat, 23 Feb 2013 16:15:02 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>However, I believe that having "," in numbers was a mistake.

"We are tied down to a language which makes up in obscurity what it
lacks in style" Tom Stoppard

The idea that Forth is cast in stone by standards is not a good one.
We are in danger of making the number input words useless for
application input. It is just a fact that the use of ',' and '.'
varies across several European regions without considering the rest
of the world.

Forth Inc and MPE have different practice for number separators.
The common part is that we want the number input parsing to be
useful for applications as well as the Forth compiler itself.

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]


#20016

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2013-02-25 15:25 +0000
Message-ID<2013Feb25.162531@mips.complang.tuwien.ac.at>
In reply to#19952
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Sat, 23 Feb 2013 16:15:02 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>However, I believe that having "," in numbers was a mistake.
...
>The idea that Forth is cast in stone by standards is not a good one.

Nobody proposed that idea, so why do you beat on it?

>We are in danger of making the number input words useless for
>application input.

Number input words were also not being discussed.

But now that you mention it: For floats the standard has a more
liberal syntax for >FLOAT, and a stricter syntax for the text
interpreter.  That's a good idea, as discussed not too long ago.  By
contrast, >NUMBER (as standardized) only processes digits, whereas a
double in the text interpreter also contains a ".".  Maybe it would be
good if there was common practice for something higher level (and more
liberal) than >NUMBER.

>It is just a fact that the use of ',' and '.'
>varies across several European regions without considering the rest
>of the world.

I live in one of thse regions where decimal mark is ",".  That does
not mean that numbers in Forth source code should be written that way.
In my part of the world we also say "wenn" where the English say "if",
but that does not mean that Forth should be extended to accept WENN,
SI, etc. in addition to IF.

If we want to support more flexible text interpreter number input
(including having a way to support "," as decimal mark) for the
scenario where the end user uses the text interpreter (with
application words on top of Forth), I think that there should be a way
to extend the number input.  Your DP-CHAR is one way, recongizers are
a more flexible way; in both cases I am not (yet?) convinced that this
feature works well with combining independently developed libraries
(the recognizer stack probably helps, but will users use it
appropriately).

- 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 2013: http://www.euroforth.org/ef13/

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


#19957

Fromalbert@spenarnc.xs4all.nl (Albert van der Horst)
Date2013-02-23 19:34 +0000
Message-ID<512919c9$0$585$e4fe514c@dreader34.news.xs4all.nl>
In reply to#19949
In article <2013Feb23.171502@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>"Elizabeth D. Rather" <erather@forth.com> writes:
>>> And there was a specific occasion that lead to taking out "," in
>>> Gforth: I wrote a priece of code that used "2,", and it compiled fine
>>> but did not work.  Eventually I found that Gforth at the time had no
>>> word "2,", but it had "," as double indicator.  So it saw a double
>>> literal instead of the word "2,".  With Elisabeth's list, "2-" would
>>> be another trap.
>>
>>If know that punctuation makes doubles, you don't make names that look
>>like punctuated numbers, just as you don't make names that look like
>>"-2". It really isn't that hard!
>
>Well, the problem was that Gforth did not have a name "2,", but I
>expected it to, and it accepted "2," (but as a number).
>
>Now "," is a regular Forth word, and words for dealing with two cells
>(or doubles) are commonly formed by prepending 2 (Forth-94 has 2! 2>R
>2@ 2CONSTANT 2DROP 2DUP 2LITERAL 2OVER 2R> 2R@ 2ROT 2SWAP 2VARIABLE),
>so "2," is a likely word name.
>
>If punctuation in word names was a mistake, the mistake was to have a
>word called ",".
>
>However, I believe that having "," in numbers was a mistake.

I believe the mistake is in the prefix 2. It should have been P of
"pair" or maybe D.

>
>- anton
>--
>M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html

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]


#19969

From"Rod Pemberton" <do_not_have@notemailnotz.cnm>
Date2013-02-23 18:35 -0500
Message-ID<kgbjlg$3pt$1@speranza.aioe.org>
In reply to#19957
"Albert van der Horst" <albert@spenarnc.xs4all.nl> wrote in
message news:512919c9$0$585$e4fe514c@dreader34.news.xs4all.nl...
> In article <2013Feb23.171502@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

> >If punctuation in word names was a mistake, the mistake was
> >to have a word called ",".
> >
> >However, I believe that having "," in numbers was a mistake.
>
> I believe the mistake is in the prefix 2. It should have been P
> of "pair" or maybe D.
>

Well, that doesn't fix "," ...

Would you suggest "1," or perhaps S of "single" as in "S," ?


Rod Pemberton



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


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

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


csiph-web