Double integer input

[Rosangela Medeiros da Silva]

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

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

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

--
Coos

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

[Coos Haak]

Op Thu, 14 Feb 2013 16:18:01 +0100 schreef Coos Haak:

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

[A. K.]

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;

[Coos Haak]

Op Thu, 14 Feb 2013 20:54:26 +0100 schreef A. K.:

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.

[Ed]

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

45.6 50 %
$2.28 ok

45+60 50 %
$22.80 ok

[Elizabeth D. Rather]

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

[Bernd Paysan]

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/

[Ed]

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!

> ...

Convenient for the programmer. Inconvenient or fatal for the user.

[Elizabeth D. Rather]

Actually, it was mostly user convenience we were going for, and it took
a little extra work (though not much) for the programmers. I mean users
of the application, of course -- scientists and the like. They
appreciated being able to type numbers the way they're represented in
"real world" documents and having them automatically scaled correctly.

[Alex McDonald]

: ip-seg ( addr len -- addr' len' n ) \ IP segment before .
dup >r \ save length
0 0 2swap >number \ convert to number
2swap d>s \ save string & convert to single
over r> <> \ check lengths differ before & after
over 0 256 within \ and range check it
and 0= throw \ flag; true=error
;

: ipv4-number? ( addr len -- d ) \ convert ip address
8 24 do \ 3 dotted segments
ip-seg \ convert up to dot
i lshift \ shift the value,
-rot \ addr string to top
dup 0= throw \ string too short?
over c@ '.' <> throw \ check for a dot, error if not
1 /string \ move past .
-8 +loop \ next shift
ip-seg \ convert what's left
-rot throw \ should be nothing left
drop or or or s>d \ ors to get result, make double
;


Not an array, but a single number in this case. IPv4 can also be 3 or
2 or 1 section, but they are rarely seen. And beware octal;
192.168.0.077 is valid, and the last octet is octal 77 or decimal 63
for 19.168.0.63. 0x is also allowed as a hex prefix. The above code
only works for decimal addresses, but IP-SEG could be enhanced to cope
with octal and hex. What is more commonplace are addresses of the form
192.168.0.0/4 or CIDR notation; an easy extension. IPv6 is a little
trickier, with its :: notation and it requires a double on a 32bit
system..

>
> 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 90045http://www.forth.com

[Anton Ertl]

Bernd Paysan <bernd....@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/

[Bernd Paysan]

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.

[Stephen Pelc]

On Fri, 22 Feb 2013 18:15:33 +0100, Bernd Paysan <bernd....@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, steph...@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

[Elizabeth D. Rather]

On 2/22/13 5:35 AM, Anton Ertl wrote:
> Bernd Paysan <bernd....@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!

[Anton Ertl]

"Elizabeth D. Rather" <era...@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 Ertl]

Bernd Paysan <bernd....@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.

[Stephen Pelc]

On Sat, 23 Feb 2013 16:15:02 GMT, an...@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.

[Albert van der Horst]

In article <2013Feb2...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>"Elizabeth D. Rather" <era...@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

[Andrew Haley]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:

> 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 have noticed that in some parts of Europe , is used as a decimal
point and . used as a thousands separator. But here, , is the
thousands separator and it's really nice to be able to use it in
numbers. It makes reading large numbers much easier. I can't see how
"2," is going to conflict with anything.

Andrew.

[Zbiggy]

In comp.lang.forth, Andrew Haley wrote:

> I have noticed that in some parts of Europe , is used as a decimal
> point and . used as a thousands separator. But here, , is the
> thousands separator and it's really nice to be able to use it in
> numbers. It makes reading large numbers much easier. I can't see how
> "2," is going to conflict with anything.

Actually, the most unambiguous thousands separator is just space.
--
It's us, the scobs.

[Rod Pemberton]

"Albert van der Horst" <alb...@spenarnc.xs4all.nl> wrote in
message news:512919c9$0$585$e4fe...@dreader34.news.xs4all.nl...

> In article <2013Feb2...@mips.complang.tuwien.ac.at>,
> Anton Ertl <an...@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

[Bernd Paysan]

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!

[Albert van der Horst]

In article <slrnkiif5l.7o5.z...@Tichy.myhome.org>,

Another thing Algol68 did right.

>--
>It's us, the scobs.

[Elizabeth D. Rather]

Um, how is the program supposed to know this is one number and not two
(or more)?

Just to provide another data point, Open Firmware accepts (and ignores)
internal '.' and they're commonly used every 4 digits in big hex
addresses for readability.

[Paul Rubin]

"Elizabeth D. Rather" <era...@forth.com> writes:

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

On 16-bit Forths, a NANP phone number (with area code) wouldn't fit in a
double integer.

[Zbiggy]

In comp.lang.forth, Elizabeth D. Rather wrote:

>> Actually, the most unambiguous thousands separator is just space.
>
> Um, how is the program supposed to know this is one number and not two
> (or more)?

Right, I was stating "from human's point of view".

For a program input, there's a need to settle for "convention".

[Elizabeth D. Rather]

Yes, area code has to be separate on a 16-bit system.

[rickman]

On 2/23/2013 11:15 AM, Anton Ertl wrote:
> "Elizabeth D. Rather"<era...@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.

Just so I can understand what you are saying. You didn't know what
characters were interpreted to be numbers or the formatting for the
Forth you were using, you didn't know if 2, was a word in the version of
Forth you were using and when you wrote code based on your assumptions
you didn't like the fact that it didn't provide an error message?

Why does this problem require the modification of a Forth environment?
Can't you just read the docs on the Forth system you want to use? Am I
trivializing the problem? I'm not getting this.

Personally I think having '.' in doubles was a mistake and they should
use ',' instead. Save '.' for floats, more inline with common use.

--

Rick

[rickman]

I have seen this swapped usage and I really don't get it. How did that
come about? Why does it persist? It is confusing to me any time I try
to communicate with someone from one of those regions. It must drive
people nuts when they are in closer contact across these regions.

Next you are going to tell me people drive on the left in these places
too! That would be a hoot, driving on the wrong side of the road... lol

No, really, why does this persist now that global communication is so
common? It is a fairly small minority that uses a comma for decimal and
periods for thousand separators, no?

The whole metric vs. US measurement system nearly drives me nuts. But
this one is just as bad, I just don't see it as often. About 3.576
times less. I'll let you figure out if that period is a thousands
separator or a decimal point.

We can expect an xkcd page on this any day now.

--

Rick

[Elizabeth D. Rather]

On 2/24/13 9:54 AM, rickman wrote:
...

> Personally I think having '.' in doubles was a mistake and they should
> use ',' instead. Save '.' for floats, more inline with common use.

It is on PCs, not so much in embedded systems, where hardware FP is rare
and software FP is costly. Also in embedded systems you have a lot more
16-bit implementations, so double precision is more important.

[WJ]

Alex McDonald wrote:

> : ip-seg ( addr len -- addr' len' n ) \ IP segment before .
> dup >r \ save length
> 0 0 2swap >number \ convert to number
> 2swap d>s \ save string & convert to single
> over r> <> \ check lengths differ before & after
> over 0 256 within \ and range check it
> and 0= throw \ flag; true=error
> ;
>
> : ipv4-number? ( addr len -- d ) \ convert ip address
> 8 24 do \ 3 dotted segments
> ip-seg \ convert up to dot
> i lshift \ shift the value,
> -rot \ addr string to top
> dup 0= throw \ string too short?
> over c@ '.' <> throw \ check for a dot, error if not
> 1 /string \ move past .
> -8 +loop \ next shift
> ip-seg \ convert what's left
> -rot throw \ should be nothing left
> drop or or or s>d \ ors to get result, make double
> ;
>
>
> Not an array, but a single number in this case. IPv4 can also be 3 or
> 2 or 1 section, but they are rarely seen.

Horrible. Simply, inexcusably, criminally horrible.

That looks even more low-level than assembly language.

No rational person would want to code that way.
It's so much easier in other languages.

And the code is not even correct.

s" 1.254.253.252" ipv4-number? ud. 33488380 ok

s" 255.254.253.252" ipv4-number? ud. 18446744073709485564 ok


Ruby:

def ip_to_number str
str.split( "." ).reduce(0){|n,s| n*256 + s.to_i }
end

ip_to_number( "1.254.253.252" )
==>33488380
ip_to_number( "255.254.253.252" )
==>4294901244

[Paul Rubin]

"WJ" <w_a_...@yahoo.com> writes:
> s" 255.254.253.252" ipv4-number? ud. 18446744073709485564 ok

Looks like someone forgot about 64-bit cpu's and didn't AND with
$FFFFFFFF.

[Coos Haak]

Op Sun, 24 Feb 2013 15:01:58 -0500 schreef rickman:

It's like the long and short numbering scheme. We use milliard for
1.000.000.000 and billion for 1.000.000.000.000
(instead of 1,000,000,000 for billion and 1,000,000,000,000 for trillion)

--
Coos

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

[Mark Wills]

> Rick- Hide quoted text -
>
> - Show quoted text -

Meh. The comma is utterly understandable. No problem at all. In the
UK, we use the comma as a thousands separator, and a decimal point for
decimals (i.e. fractions). It works particularly well for currency:

£1,234,568.99

One million, two-hundred and thirty-four thousand, five-hundred and
sixty-eight pounds, and 99 pence.

What's so difficult about that?

'Yall need to get with the British standard, you know it makes sense.

If you want to see confusing, try currency in India and Bangladesh.
They have the Lakh, which, IIRC, is 10 thousands. That ties me up in
knots!

[Mark Wills]

> CHForth, 16 bit DOS applicationshttp://home.hccnet.nl/j.j.haak/forth.html- Hide quoted text -

>
> - Show quoted text -

Agggggh! My heads' going to explode!

[Andrew Haley]

Mark Wills <markrob...@yahoo.co.uk> wrote:
>
> Meh. The comma is utterly understandable. No problem at all. In the
> UK, we use the comma as a thousands separator, and a decimal point for
> decimals (i.e. fractions). It works particularly well for currency:
>
> 1,234,568.99

Umm, a full stop is not a decimal point. :-)

Andrew.

[Albert van der Horst]

In article <de3f6e3a-8a88-4f57...@h11g2000vbf.googlegroups.com>,
Mark Wills <markrob...@yahoo.co.uk> wrote:

>On Feb 24, 8:01�ｿｽpm, rickman <gnu...@gmail.com> wrote:
>> On 2/23/2013 3:58 PM, Andrew Haley wrote:
>>
>>
>>
>>
>>

>> > Anton Ertl<an...@mips.complang.tuwien.ac.at> �ｿｽwrote:

>>
>> >> 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 have noticed that in some parts of Europe , is used as a decimal

>> > point and . used as a thousands separator. �ｿｽBut here, , is the

>> > thousands separator and it's really nice to be able to use it in

>> > numbers. �ｿｽIt makes reading large numbers much easier. �ｿｽI can't see how

>> > "2," is going to conflict with anything.
>>

>> I have seen this swapped usage and I really don't get it. �ｿｽHow did that
>> come about? �ｿｽWhy does it persist? �ｿｽIt is confusing to me any time I try
>> to communicate with someone from one of those regions. �ｿｽIt must drive

>> people nuts when they are in closer contact across these regions.
>>
>> Next you are going to tell me people drive on the left in these places

>> too! �ｿｽThat would be a hoot, driving on the wrong side of the road... lol

>>
>> No, really, why does this persist now that global communication is so

>> common? �ｿｽIt is a fairly small minority that uses a comma for decimal and

>> periods for thousand separators, no?
>>

>> The whole metric vs. US measurement system nearly drives me nuts. �ｿｽBut
>> this one is just as bad, I just don't see it as often. �ｿｽAbout 3.576
>> times less. �ｿｽI'll let you figure out if that period is a thousands

>> separator or a decimal point.
>>
>> We can expect an xkcd page on this any day now.
>>
>> --
>>
>> Rick- Hide quoted text -
>>
>> - Show quoted text -
>
>Meh. The comma is utterly understandable. No problem at all. In the
>UK, we use the comma as a thousands separator, and a decimal point for
>decimals (i.e. fractions). It works particularly well for currency:
>

>�ｿｽ1,234,568.99

The proper way is of course Euro 1.234.568,99

By the way thanks for getting rid of 12 pence in a shilling and 21 shillings
in a guinea. Reading James Joyce Ulysses had me reaching for my
calculator at times.

>
>One million, two-hundred and thirty-four thousand, five-hundred and
>sixty-eight pounds, and 99 pence.
>
>What's so difficult about that?
>
>'Yall need to get with the British standard, you know it makes sense.
>
>If you want to see confusing, try currency in India and Bangladesh.
>They have the Lakh, which, IIRC, is 10 thousands. That ties me up in
>knots!

The French real estate was measured still in millions ( anciens francs)
at a time the francs was reevaluated at 100 old francs.

Groetjes Albert

[Bernd Paysan]

rickman wrote:
> I have seen this swapped usage and I really don't get it. How did that
> come about? Why does it persist?

If I look at the world map of point and comma:

http://commons.wikimedia.org/wiki/File:DecimalSeparator.svg

the answer is easy: It is the british empire which insists on being
different. The only larger non-britisch empire country with point are China
and Mexico; and China is obvious: They have their own numbers and their own
way of fractional notation (subscript), so when they use arabic numbers,
they just use the notation that comes with English, the only foreign
language which is at least taught at school (with moderate success ;-).

> No, really, why does this persist now that global communication is so
> common? It is a fairly small minority that uses a comma for decimal and
> periods for thousand separators, no?

If you look at that map, it's obviously not a small minority. Well, the fact
that Inida and China uses the . (by either forcefully or absent-mindly
following the britisch empire), the .-separators are the majority. If you
look at where this notation came from, i.e. Europe, the dots are the small
minority. And they do drive on the wrong side of the road, hehe.

> The whole metric vs. US measurement system nearly drives me nuts.

This is apparently the same thing. Some snobby brits thought they could
confuse the world by reversing the notation.

[Anton Ertl]

steph...@mpeforth.com (Stephen Pelc) writes:
>On Sat, 23 Feb 2013 16:15:02 GMT, an...@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 Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>I can't see how
>"2," is going to conflict with anything.

Read my earlier posting. If I did not write clearly, please point out
where the lack of clarity is and I will try to improve on it.

[Brad Eckert]

On Sunday, February 24, 2013 3:05:40 PM UTC-7, WJ wrote:
>
> ip_to_number( "1.254.253.252" )
> ==>33488380
> ip_to_number( "255.254.253.252" )
> ==>4294901244

Nice library functions. Can I go into Ruby and type LOCATE ip_to_number to see the source code?

I think Alex didn't consider using SEARCH-STRING. If you don't like the code, post a pretty ipv4-number?.

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:

>Just to provide another data point, Open Firmware accepts (and ignores)
>internal '.' and they're commonly used every 4 digits in big hex
>addresses for readability.

Sure, so does Gforth (in the text interpreter). There have not been
problems with that yet (excrpt people who want "." to indicate FP).

[Anton Ertl]

Correct.

>Why does this problem require the modification of a Forth environment?
>Can't you just read the docs on the Forth system you want to use? Am I
>trivializing the problem? I'm not getting this.

This is a discussion about how things should be designed. Sure, you
can misdesign it and then document the misdesign, and just point users
that have a problem with the misdesign to the docs. But I think it's
better not to produce the misdesign in the first place. Or, in this
case, fix the misdesign when it shows itself.

[Brad Eckert]

On Monday, February 25, 2013 10:22:16 AM UTC-7, Brad Eckert wrote:
>
> Nice library functions. Can I go into Ruby and type LOCATE ip_to_number to see the source code?
>

Derp, it was so short I missed it! Ruby has a very powerful string syntax. Forth string support is bare bones. I guess I'll have to post my version. Octet doesn't have error checking but it's easily added.

variable ipv4
: octet ( a u field# -- a' u' )
>r 0 0 2swap >number 1 /string \ skip .
2swap drop r> 8 * lshift ipv4 +! ;

: ipv4_to_number ( a u -- u1 )
0 ipv4 ! 0 3 do i octet -1 +loop \ 3,2,1,0
2drop ipv4 @ ;

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:

> rickman wrote:
>
>> The whole metric vs. US measurement system nearly drives me nuts.
>
> This is apparently the same thing. Some snobby brits thought they
> could confuse the world by reversing the notation.

Reversing what notation? This comment baffles me.

Andrew.

[Bernd Paysan]

Swapping the meaning of ',' and '.'.

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:
> Andrew Haley wrote:
>
>> Bernd Paysan <bernd....@gmx.de> wrote:
>>> rickman wrote:
>>>
>>>> The whole metric vs. US measurement system nearly drives me nuts.
>>>
>>> This is apparently the same thing. Some snobby brits thought they
>>> could confuse the world by reversing the notation.
>>
>> Reversing what notation? This comment baffles me.
>
> Swapping the meaning of ',' and '.'.

I think you're rather assuming things not in evidence.

Snobby? I really don't understand how "," is any less snobby than "."
AIUI, the original decimal point was a sort of small vertical bar.

The use of a full stop for a decimal point is American, not British.
The British decimal point was a middle dot, not a full stop. The
middle dot isn't in ASCII or on a computer keyboard, though, so it's
losing out.

Andrew.

[Bernd Paysan]

Andrew Haley wrote:

> Bernd Paysan <bernd....@gmx.de> wrote:
>> Swapping the meaning of ',' and '.'.
>
> I think you're rather assuming things not in evidence.
>
> Snobby? I really don't understand how "," is any less snobby than "."
> AIUI, the original decimal point was a sort of small vertical bar.

The original decimal point was subscript for the fractional part, and
invented in China (that's because Chinese at that time had no punctation
whatsoever, but highly advanced math, and a fully functional decimal
system). It changed shape several times:

http://en.wikipedia.org/wiki/Decimal_mark#History
http://de.wikipedia.org/wiki/Dezimaltrennzeichen#Entwicklung

(The German text goes back a bit further, including a hint to the ancient
Chinese notation).

> The use of a full stop for a decimal point is American, not British.
> The British decimal point was a middle dot, not a full stop. The
> middle dot isn't in ASCII or on a computer keyboard, though, so it's
> losing out.

Now that's snobbish: Using a decimal point that's not even on a computer
keyboard ;-).

[Alex McDonald]

On Feb 24, 10:05 pm, "WJ" <w_a_x_...@yahoo.com> wrote:
> Alex McDonald wrote:
> > : ip-seg        ( addr len -- addr' len' n ) \ IP segment before .
> >     dup >r                       \ save length
> >     0 0 2swap >number            \ convert to number
> >     2swap d>s                    \ save string & convert to single
> >     over r> <>                   \ check lengths differ before & after
> >     over 0 256 within            \ and range check it
> >     and 0= throw                 \ flag; true=error
> >     ;
>
> > : ipv4-number?    ( addr len -- d )            \ convert ip address
> >     8 24 do                      \ 3 dotted segments
> >       ip-seg                     \ convert up to dot
> >       i lshift                   \ shift the value,
> >       -rot                       \ addr string to top
> >       dup 0= throw               \ string too short?
> >       over c@ '.' <> throw       \ check for a dot, error if not
> >       1 /string                  \ move past .
> >     -8 +loop                     \ next shift
> >     ip-seg                       \ convert what's left
> >     -rot throw                   \ should be nothing left
> >     drop or or or s>d            \ ors to get result, make double
> >     ;
>
> > Not an array, but a single number in this case. IPv4 can also be 3 or
> > 2 or 1 section, but they are rarely seen.
>
> Horrible.  Simply, inexcusably, criminally horrible.

Thanks!

>
> That looks even more low-level than assembly language.
>
> No rational person would want to code that way.
> It's so much easier in other languages.
>
> And the code is not even correct.
>
> s" 1.254.253.252" ipv4-number? ud. 33488380  ok
>
> s" 255.254.253.252" ipv4-number? ud. 18446744073709485564  ok

Was that a 64bit Forth?

>
> Ruby:
>
> def ip_to_number str
>   str.split( "." ).reduce(0){|n,s| n*256 + s.to_i }
> end

Does this have any error checking?

>
> ip_to_number( "1.254.253.252" )
>     ==>33488380
> ip_to_number( "255.254.253.252" )
>     ==>4294901244

ip_to_number( "1.2546.253 .252" )
=> 183696892

I guess not.

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:
> Andrew Haley wrote:
>
>> Bernd Paysan <bernd....@gmx.de> wrote:
>>> Swapping the meaning of ',' and '.'.
>>
>> I think you're rather assuming things not in evidence.
>>
>> Snobby? I really don't understand how "," is any less snobby than "."
>> AIUI, the original decimal point was a sort of small vertical bar.
>
> The original decimal point was subscript for the fractional part, and
> invented in China (that's because Chinese at that time had no punctation
> whatsoever, but highly advanced math, and a fully functional decimal
> system). It changed shape several times:
>
> http://en.wikipedia.org/wiki/Decimal_mark#History
> http://de.wikipedia.org/wiki/Dezimaltrennzeichen#Entwicklung
>
> (The German text goes back a bit further, including a hint to the ancient
> Chinese notation).

Which isn't in the English text. Never mind, not relevant here.

>> The use of a full stop for a decimal point is American, not British.
>> The British decimal point was a middle dot, not a full stop. The
>> middle dot isn't in ASCII or on a computer keyboard, though, so it's
>> losing out.
>
> Now that's snobbish: Using a decimal point that's not even on a computer
> keyboard ;-).

There weren't any.

Andrew.

[rickman]

I don't care if what you call it in speech since I don't have to hear
it. But you had better write it as Giga and Tera! There is a reason
for SI units. I don't get why people don't seem to be accepting the
binary equivalents Gi and Ti. I guess it is in part because of the
funny sound of gibi and tebi, etc.

BTW, I remember a story about an American in a British bar who was
labeled the biggest liar ever (in the tall tale sense) because he said
three things that were all misinterpreted because of the language. One
of them what that something was "billions" which was interpreted as
1000x what he meant. Rather funny actually.

--

Rick

[rickman]

I have to say I don't understand what the mis-design is. The docs
define how the system operates. If you are ignorant of that, then you
don't have much hope of using the system.

How numbers are input to the system is a basic part of the docs. I am
actually surprised to realize that this is *not* part of the Forth
standard that I can see. I guess they left it as an implementation
feature, but I don't even see where that is discussed. Most important
features of Forth that are implementation defined are listed as such. A
quick scan of the dpans document doesn't show much discussion of number
input at all.

I can see where you might say the standard is deficient, but I don't see
a problem with the system you were using.

--

Rick

[WJ]

Alex McDonald wrote:

> : ip-seg ( addr len -- addr' len' n ) \ IP segment before .
> dup >r \ save length
> 0 0 2swap >number \ convert to number
> 2swap d>s \ save string & convert to single
> over r> <> \ check lengths differ before & after
> over 0 256 within \ and range check it
> and 0= throw \ flag; true=error
> ;
>
> : ipv4-number? ( addr len -- d ) \ convert ip address
> 8 24 do \ 3 dotted segments
> ip-seg \ convert up to dot
> i lshift \ shift the value,
> -rot \ addr string to top
> dup 0= throw \ string too short?
> over c@ '.' <> throw \ check for a dot, error if not
> 1 /string \ move past .
> -8 +loop \ next shift
> ip-seg \ convert what's left
> -rot throw \ should be nothing left
> drop or or or s>d \ ors to get result, make double
> ;
>
>
> Not an array, but a single number in this case.

Factor:


USING: splitting math.parser ;

: ip-to-number ( string -- integer )
"." split
0 [ string>number swap 256 * + ] reduce ;

[Anton Ertl]

rickman <gnu...@gmail.com> writes:
>On 2/25/2013 1:11 PM, Anton Ertl wrote:
>> This is a discussion about how things should be designed. Sure, you
>> can misdesign it and then document the misdesign, and just point users
>> that have a problem with the misdesign to the docs. But I think it's
>> better not to produce the misdesign in the first place. Or, in this
>> case, fix the misdesign when it shows itself.
>
>I have to say I don't understand what the mis-design is. The docs
>define how the system operates. If you are ignorant of that, then you
>don't have much hope of using the system.

Only a badly designed system is useful only to users who know the
documentation by heart. A well-designed system is already useful to
some degree with little or no reading of the documentation.

>How numbers are input to the system is a basic part of the docs. I am
>actually surprised to realize that this is *not* part of the Forth
>standard that I can see.

So much for reading the docs:

http://www.complang.tuwien.ac.at/forth/dpans-html/dpans2.htm#2.2.1
http://www.complang.tuwien.ac.at/forth/dpans-html/dpans3.htm#3.2.1.2
http://www.complang.tuwien.ac.at/forth/dpans-html/dpans8.htm#8.3.2
http://www.complang.tuwien.ac.at/forth/dpans-html/dpans12.htm#12.3.7

[WJ]

Alex McDonald wrote:

> : ip-seg ( addr len -- addr' len' n ) \ IP segment before .
> dup >r \ save length
> 0 0 2swap >number \ convert to number
> 2swap d>s \ save string & convert to single
> over r> <> \ check lengths differ before & after
> over 0 256 within \ and range check it
> and 0= throw \ flag; true=error
> ;
>
> : ipv4-number? ( addr len -- d ) \ convert ip address
> 8 24 do \ 3 dotted segments
> ip-seg \ convert up to dot
> i lshift \ shift the value,
> -rot \ addr string to top
> dup 0= throw \ string too short?
> over c@ '.' <> throw \ check for a dot, error if not
> 1 /string \ move past .
> -8 +loop \ next shift
> ip-seg \ convert what's left
> -rot throw \ should be nothing left
> drop or or or s>d \ ors to get result, make double
> ;

Oforth:

func: ip-to-number
{ wordsWith( '.' ) map( #asInteger )
dup conform( #[ between( 0, 255 ) ] )
ifFalse: [ Exception throw( "bad byte in IP address" ) ]
reduce( #[ swap 256 * + ] )
}

> "0.0.1.20" ip-to-number println
276

> "1.254.253.252" ip-to-number println
33488380

> "127.254.253.252" ip-to-number println
2147417596

> "255.254.253.252" ip-to-number println
4294901244

> "99.254.253.256" ip-to-number println
[1:interpreter] Exception : bad byte in IP address

[WJ]

In OFORTH version V0.9.23.1;

: ip-to-number
wordsWith( '.' ) map( #asInteger )
dup conform( #[ between( 0, 255 ) ] )
ifFalse: [ Exception throw( "bad byte in IP address" ) ]
reduce( #[ swap 256 * + ] ) ;


>
> > "0.0.1.20" ip-to-number println
> 276
>
> > "1.254.253.252" ip-to-number println
> 33488380
>
> > "127.254.253.252" ip-to-number println
> 2147417596
>
> > "255.254.253.252" ip-to-number println
> 4294901244
>
> > "99.254.253.256" ip-to-number println
> [1:interpreter] Exception : bad byte in IP address

--

[François]

3 Years...