Re: string-stack.4th

Newsgroups	comp.lang.forth
Date	2016-03-10 23:00 -0800
References	(3 earlier) <799b10b1-69a7-47ed-acdb-a791cbd4d248@googlegroups.com> <nbiemr$5kg$1@gioia.aioe.org> <36f34016-ac87-4117-bff3-66bdc6e016d0@googlegroups.com> <b67d0308-b176-4d24-8357-980842c2d6eb@googlegroups.com> <c5b9a927-cc34-4040-80e4-f8a5ad99ef98@googlegroups.com>
Message-ID	<a634ea74-bef2-4fce-abb3-93d5b445ea0e@googlegroups.com> (permalink)
Subject	Re: string-stack.4th
From	hughaguilar96@gmail.com

Show all headers | View raw

On Thursday, March 10, 2016 at 11:42:43 AM UTC-7, franck....@gmail.com wrote:
> Le lundi 7 mars 2016 04:09:14 UTC+1, hughag...@gmail.com a écrit :
>  
> > 1.) JUGGLERS --- These include SWAP$ etc. and they just move items around on the string-stack.
> > 
> > 2.) DUPLICATORS --- These include DUP$ etc. and they make a derivative item.
> > 
> > 3.) CONSUMERS --- These include .$ etc. and they consume an item. If the item is a derivative it is just dropped. If the item is a unique, then FIX-DERIVATIVES is called first (this searches the string-stack for derivatives that are inside of this unique and changes them into uniques) and then it is dropped.
> > 
> > 4.) MUTATORS --- These include UCASE$ etc. and they modify an item. If the item is a derivative it gets changed into a unique first, and if the item is a unique then FIX-DERIVATIVES gets called first, then the item is modified.
> > 
> 
> This is an interesting memory management. I wonder how this compare to 
> a memory management using a garbage collector.
> 
> Did you run some benchmark tests ?
> 
> Franck

Here is some code run using .S$ to show the string-stack throughout:

s" foo:=bar" >$ dup$  ok
.s$ 
STRING STACK:
derivative: |foo:=bar|
unique:     |foo:=bar| ok
s" :=" >$ infix$ . -1  ok
.s$ 
STRING STACK:
derivative: |:=|
derivative: |foo:=bar|
unique:     |foo:=bar| ok
extract$  ok
.s$ 
STRING STACK:
derivative: |bar|
derivative: |foo|
unique:     |foo:=bar| ok
third$ 2@  second$ 2@  first$ 2@  .s 
DATA STACK
     top
             -3 FFFF:FFFD
       67355897 0403:C4F9
             -3 FFFF:FFFD
       67355892 0403:C4F4
              8 0000:0008
       67355892 0403:C4F4
 ok-6 

Notice that only the original string s" foo:=bar" is put on the heap (also the pattern string s" :=" but it is freed by INFIX$). The |:=| string returned by INFIX$ is not the pattern string given to it, but instead is a derivative string inside of the original string. All the way to the very end, nothing is getting put on the heap, but everything that I'm working with are derivative strings.

At the very end I show what the three strings are, and only the original string is a unique, but the other two strings (the prefix and suffix) are derivatives. I expect that this is faster than a system in which every string is put on the heap and then freed later, and significantly faster than a system in which every string is put on the heap and then GC'd later --- I'm just manipulating adr/cnt pairs and not messing with the heap at all --- that has got to be fast!

If I do need to convert a derivative into a unique however, this gets done automatically. Here is some more code:

3drop 3drop  ok
ucase$  ok
.s$ 
STRING STACK:
unique:     |BAR|
derivative: |foo|
unique:     |foo:=bar| ok
third$ 2@  second$ 2@  first$ 2@  .s 
DATA STACK
     top
              3 0000:0003
       67355916 0403:C50C
             -3 FFFF:FFFD
       67355892 0403:C4F4
              8 0000:0008
       67355892 0403:C4F4
 ok-6 

UCASE$ is a mutator, which means that if it is given a derivative (as in this case) it converts it into a unique before mutating it --- if it is given a unique it calls FIX-DERIVATIVES to fix any derivatives of the string that may be on the string-stack before mutating it --- so, I avoid messing with the heap as much as possible, but when it is necessary then it is done automatically.

Anyway --- no --- I haven't run any benchmark tests. For one thing, I'm not familiar enough with oForth to write the oForth code --- also, it depends upon which ANS-Forth compiler is used (VFX generates pretty fast code, but SwiftForth generates abysmally bloated and slow code), so a benchmark against oForth tests the compiler more than the algorithm.

Thread

string-stack.4th hughaguilar96@gmail.com - 2016-03-03 21:42 -0800
  Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-03 21:54 -0800
  Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-04 18:01 -0800
    Re: string-stack.4th Mark Wills <markwills1970@gmail.com> - 2016-03-05 02:52 -0800
      Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-05 15:17 -0800
        Re: string-stack.4th foxaudioresearch@gmail.com - 2016-03-06 08:50 -0800
          Re: string-stack.4th foxaudioresearch@gmail.com - 2016-03-06 10:54 -0800
            Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-06 14:08 -0800
              Re: string-stack.4th "HAA" <someone@microsoft.com> - 2016-03-07 10:30 +1100
                Re: string-stack.4th foxaudioresearch@gmail.com - 2016-03-06 16:45 -0800
                Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-06 19:09 -0800
                Re: string-stack.4th Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-07 12:27 +0000
                Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-07 22:44 -0800
                Re: string-stack.4th JennyB <jennybrien@googlemail.com> - 2016-03-11 03:47 -0800
                Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-09 22:27 -0800
                Re: string-stack.4th Coos Haak <chforth@hccnet.nl> - 2016-03-10 11:05 +0100
                Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-10 09:28 -0800
                Re: string-stack.4th Coos Haak <chforth@hccnet.nl> - 2016-03-11 00:10 +0100
                Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-10 22:42 -0800
                Re: string-stack.4th Coos Haak <chforth@hccnet.nl> - 2016-03-11 12:29 +0100
                Re: string-stack.4th JennyB <jennybrien@googlemail.com> - 2016-03-12 01:33 -0800
                Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-12 16:56 -0800
                Re: string-stack.4th "WJ" <w_a_x_man@yahoo.com> - 2016-04-22 09:55 +0000
                Re: string-stack.4th "WJ" <w_a_x_man@yahoo.com> - 2016-04-22 10:00 +0000
                Re: string-stack.4th "WJ" <w_a_x_man@yahoo.com> - 2016-03-11 06:24 +0000
                Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-21 23:26 -0700
                Re: string-stack.4th franck.bensusan@gmail.com - 2016-03-10 10:42 -0800
                Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-10 23:00 -0800
                Re: string-stack.4th hughaguilar96@gmail.com - 2016-04-10 20:23 -0700
                Re: string-stack.4th stephen@mpeforth.com (Stephen Pelc) - 2016-04-11 09:45 +0000
                Re: string-stack.4th hughaguilar96@gmail.com - 2016-04-11 20:00 -0700
                Re: string-stack.4th Mark Wills <markwills1970@gmail.com> - 2016-04-11 03:16 -0700
                Re: string-stack.4th Mark Wills <markwills1970@gmail.com> - 2016-04-11 03:47 -0700
                Re: string-stack.4th Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-11 05:50 -0500
                Re: string-stack.4th Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-11 04:21 -0700
                Re: string-stack.4th Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-11 06:36 -0500
                Re: string-stack.4th hughaguilar96@gmail.com - 2016-04-11 20:34 -0700
                Re: string-stack.4th hughaguilar96@gmail.com - 2016-04-11 20:20 -0700
                Re: string-stack.4th hughaguilar96@gmail.com - 2016-06-03 05:53 -0700
              Re: string-stack.4th Mark Wills <markwills1970@gmail.com> - 2016-03-08 11:29 -0800

csiph-web