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

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

Double integer input

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

#19991

On 2/23/2013 11:15 AM, Anton Ertl 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.

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

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

#19994

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.

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]

#20025

rickman <gnuarm@gmail.com> writes:
>On 2/23/2013 11:15 AM, Anton Ertl 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.
>
>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?

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.

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

#20081

On 2/25/2013 1:11 PM, Anton Ertl wrote:
> rickman<gnuarm@gmail.com>  writes:
>> On 2/23/2013 11:15 AM, Anton Ertl 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.
>>
>> 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?
>
> 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.

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

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

#20180

rickman <gnuarm@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

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

#19900

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.

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

#19901

On 2/21/13 4:22 PM, Ed wrote:
> 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.

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.

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]

#19906

On Feb 22, 12:24 am, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> 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 :-)

: 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
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

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

#19995

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

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

#19999

"WJ" <w_a_x_man@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.

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

#20020

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

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

#20026

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 @ ;

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

#20038

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.

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

#20091

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 ;

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

#19984

"Elizabeth D. Rather" <erather@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.  

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

#19990

On 2/23/13 7:34 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@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.
>

Yes, area code has to be separate on a 16-bit 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 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web