OpenEuphoria

2. Re: find_from and match_from

• Posted by Robert Craig <rds at RapidEuphoria.com> Apr 13, 2007
• 672 views
• Last edited Apr 14, 2007

Matt Lewis wrote:
> I've committed find_from and match_from to the svn repository (including
> changes to the docs).

Great.
I'll update my svn files and do some testing.
I'll also add an item to relnotes.htx about this.

I should also look at the source file diffs on SourceForge.
There are several places where a small change needs 
to be made when a new built-in is added. 
It's not as automated as it should be.
I'll check if you missed anything.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

4. Re: find_from and match_from

• Posted by Juergen Luethje <j.lue at gmx.de> Apr 14, 2007
• 685 views

Robert Craig wrote:

> Robert Craig wrote:
>> Matt Lewis wrote:
>>> I've committed find_from and match_from to the svn repository (including
>>> changes to the docs).
> 
> OK, I updated my svn files, and found a few minor
> omissions/glitches, corrected them, and checked them in. 
> I also updated the Translator to support find_from and 
> match_from (very similar to find and match). 
> 
> find_from and match_from seem to work now, 
> (interpreter with C-backend or execute.e, and translator) 
> but I haven't had time to test things thoroughly. 
> It didn't look like you got to the point of actually testing, 
> so you should give it a try now.

I'm looking forward to have these functions available in Euphoria.
Many thanks to both of you!

Regards,
   Juergen

6. find_from and match_from

• Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Mar 20, 2007
• 668 views

I've put a feature request on sourceforge for find_from and match_from:
http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785

Text:
"Add two built-in functions, find_from and match_from, which work similar to
find and match, but add a third parameter, which specifies the place in the
sequence to begin looking.

If found or matched, the index of the find or match is returned, or zero,
if not found or matched to the end of the sequence.

This has already been implemented in ooeu (http://sf.net/projects/ooeu), so
this is a matter of determining if we want this in Euphoria, not the
feasibility or requesting resources for development."


Since this is already developed (though not documented)in ooeu, we basically 
need to decide if this should go into euphoria or not.

Matt

8. Re: find_from and match_from

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> Mar 20, 2007
• 682 views

Igor Kachan wrote:
> 
> Matt Lewis wrote:
>  
> > I've put a feature request on sourceforge for find_from and match_from:
> > <a
> > href="http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785">http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785</a>
> > 
> > Text:
> > "Add two built-in functions, find_from and match_from, which work similar to
> > find and match, but add a third parameter, which specifies the place in the
> > sequence to begin looking.
> > 
> > If found or matched, the index of the find or match is returned, or zero,
> > if not found or matched to the end of the sequence.
> > 
> > This has already been implemented in ooeu (<a
> > href="http://sf.net/projects/ooeu">http://sf.net/projects/ooeu</a>),
> so</font></i>
> > this is a matter of determining if we want this in Euphoria, not the
> > feasibility or requesting resources for development."
> > 
> > 
> > Since this is already developed (though not documented)in ooeu, we basically
> > 
> > need to decide if this should go into euphoria or not.
> > 
> > Matt
> 
> Hi Matt,
> 
> It seems to be very simple to implement this feature
> just in some library and do not touch 4 different
> versions of interpreters, translators, binders
> with their docs etc etc :
> 
> }}}
<eucode>
> -- not tested
> global function find_from_to(integer N, integer L, object a, sequence b)
>           L = find(a, b[N..L])
>        if L then return L-1+N
>        else return L
> end function
> 
> global function match_from_to(integer N, integer L, sequence a, sequence b)
>           L = match(a,b[N..L])
>        if L then return L-1+N
>        else return L
> end function 
> </eucode>
{{{

> 
> Any one can redefine the standard find() and match() as these
> above function just now (ok, after testing and correction)
> and use them.
> 
> You do know I'm very and too conservative and lazy guy,
> so just my $0.02   
> 
> Regards,
> Igor Kachan
> kinz at peterlink.ru

Very easy and VERY SLOW, because you create a slice just to specify a start
 and end point, and destroy it on return. Do this a few hundred times in a
 loop...

So the idea is indeed to "touch 4 different
> versions of interpreters, translators, binders
> with their docs etc etc" so that you can more sensibly just change the
 bounds of the for loop used internally to find something in a sequence, 
and set them to N and L, not just 1 and length(s). Hence, find_from() and 
friends will be faster than find() if N is large, instead of being slower as
 your code is.

CChris

10. Re: find_from and match_from

• Posted by Juergen Luethje <j.lue at gmx.de> Mar 20, 2007
• 689 views

Matt Lewis wrote:

> I've put a feature request on sourceforge for find_from and match_from:
> <a
> href="http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785">http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785</a>
> 
> Text:
> "Add two built-in functions, find_from and match_from, which work similar to
> find and match, but add a third parameter, which specifies the place in the
> sequence to begin looking.
> 
> If found or matched, the index of the find or match is returned, or zero,
> if not found or matched to the end of the sequence.
> 
> This has already been implemented in ooeu (<a
> href="http://sf.net/projects/ooeu">http://sf.net/projects/ooeu</a>), so
> this is a matter of determining if we want this in Euphoria, not the
> feasibility or requesting resources for development."
> 
> 
> Since this is already developed (though not documented)in ooeu, we basically
> need to decide if this should go into euphoria or not.
> 
> Matt


Yes, it should.
support += my_vote     -- 

Regards,
   Juergen

12. Re: find_from and match_from

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> Mar 20, 2007
• 702 views

Juergen Luethje wrote:
> 
> Matt Lewis wrote:
> 
> > I've put a feature request on sourceforge for find_from and match_from:
> > <a
> > href="http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785">http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785</a>
> > 
> > Text:
> > "Add two built-in functions, find_from and match_from, which work similar to
> > find and match, but add a third parameter, which specifies the place in the
> > sequence to begin looking.
> > 
> > If found or matched, the index of the find or match is returned, or zero,
> > if not found or matched to the end of the sequence.
> > 
> > This has already been implemented in ooeu (<a
> > href="http://sf.net/projects/ooeu">http://sf.net/projects/ooeu</a>),
> so</font></i>
> > this is a matter of determining if we want this in Euphoria, not the
> > feasibility or requesting resources for development."
> > 
> > 
> > Since this is already developed (though not documented)in ooeu, we basically
> > need to decide if this should go into euphoria or not.
> > 
> > Matt
> 
> 
> Yes, it should.
> support += my_vote     -- 
> 
> Regards,
>    Juergen

I support it too.

CChris

14. Re: find_from and match_from

• Posted by Igor Kachan <kinz at peterlink.ru> Mar 20, 2007
• 714 views

CChris wrote:
> 
> Igor Kachan wrote:
> > 
> > Matt Lewis wrote:
> >  
> > > I've put a feature request on sourceforge for find_from and match_from:
> > > <a
> > > href="http://sourceforge.net/tracker/index.php?func=detail&amp;aid=1684321&amp;group_id=182827&amp;atid=902785">http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785</a>
> > > 
> > > Text:
> > > "Add two built-in functions, find_from and match_from, which work similar
> > > to
> > > find and match, but add a third parameter, which specifies the place in
> > > the
> > > sequence to begin looking.
> > > 
> > > If found or matched, the index of the find or match is returned, or zero,
> > > if not found or matched to the end of the sequence.
> > > 
> > > This has already been implemented in ooeu (<a
> > > href="http://sf.net/projects/ooeu">http://sf.net/projects/ooeu</a>),
> > so</font></i>
> > > this is a matter of determining if we want this in Euphoria, not the
> > > feasibility or requesting resources for development."
> > > 
> > > 
> > > Since this is already developed (though not documented)in ooeu, we
> > > basically
> > > 
> > > need to decide if this should go into euphoria or not.
> > > 
> > > Matt
> > 
> > Hi Matt,
> > 
> > It seems to be very simple to implement this feature
> > just in some library and do not touch 4 different
> > versions of interpreters, translators, binders
> > with their docs etc etc :
> > 
> > }}}
<eucode>
> > -- not tested
> > global function find_from_to(integer N, integer L, object a, sequence b)
> >           L = find(a, b[N..L])
> >        if L then return L-1+N
> >        else return L
> > end function
> > 
> > global function match_from_to(integer N, integer L, sequence a, sequence b)
> >           L = match(a,b[N..L])
> >        if L then return L-1+N
> >        else return L
> > end function 
> > </eucode>
{{{

> > 
> > Any one can redefine the standard find() and match() as these
> > above function just now (ok, after testing and correction)
> > and use them.
> > 
> > You do know I'm very and too conservative and lazy guy,
> > so just my $0.02   
> > 
> > Regards,
> > Igor Kachan
> > kinz at peterlink.ru
> 
> Very easy and VERY SLOW, because you create a slice just to specify a start
> and end point, and destroy it on return. Do this a few hundred times in a
>  loop...
> 
> So the idea is indeed to "touch 4 different
> > versions of interpreters, translators, binders
> > with their docs etc etc"
> so that you can more sensibly just change the
> bounds of the for loop used internally to find something in a sequence, 
> and set them to N and L, not just 1 and length(s). Hence, find_from() and 
> friends will be faster than find() if N is large, instead of being slower as
> your code is.

It all depends on ...

function find_from_to(integer N, integer L, object a, sequence b)
     L=find(a,b[N .. L])
     if L then
       return L-1+N
     else
       return L
     end if
end function

sequence p,q,z
p=repeat(10000,9)
q=repeat({}, 10000)

for i=1 to length(q) do
    q[i] = rand(p)
end for    
 
 z=rand(p)

atom T, ok
T=time()
for i=1 to 3000 do
ok = find(z, q)
end for
T=time()-T
? T

T=time()
for i=1 to 3000 do
ok = find_from_to(1,10000,z,q)
end for
T=time()-T
? T

T=time()
for i=1 to 3000 do
ok = find_from_to(100,1000,z,q)
end for
T=time()-T
? T

On my 1.8GHz box I got, for example:

2.41  --  pure find()     -- full range
12.25 --  find_from_to()  -- full range
0.16  --  find_from_to()  -- some suspicious range

Try and try please to be very sure.

Good Luck!

Regards,
Igor Kachan
kinz at peterlink.ru

16. Re: find_from and match_from

• Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Mar 21, 2007
• 698 views

Derek Parnell wrote:
> 
> Robert Craig wrote:
> > the current match() and find()
> 
> Robert, I vaguely remember someone saying that a slice doesn't create a new
> sequence until such time as the slice is actually written to. Is that true?

Not true.  I disassembled Igor's example:

function find_from_to(integer N, integer L, object a, sequence b)
     L=find(a,b[N .. L])
     if L then
       return L-1+N
     else
       return L
     end if
end function

Notice line 7, where the slice is created an assigned to the temp.
An additional slow down occurs here through the arithmetic to convert
from the slice to the sequence as a whole.

SubProgram [find_from_to:00116]
     1: 096 117                          # INTEGER_CHECK: [N:117]
     3: 096 118                          # INTEGER_CHECK: [L:118]
     5: 097 120                          # SEQUENCE_CHECK: [b:120]
7: 046 120 117 118 121              # RHS_SLICE: [b:120] [N:117]..[L:118]
     => [_temp_:121]
12: 077 119 121 118                  # FIND: [a:119], [_temp_:121] =>
    [L:118]
    16: 020 118 32                       # IF: [L:118] = 0 goto 0032
19: 010 118 122 121                  # MINUS: [L:118], [LIT 1:122] =>
    [_temp_:121]
23: 011 121 117 121                  # PLUS: [_temp_:121], [N:117] =>
    [_temp_:121]
    27: 028 116 121                      # RETURNF: [_temp_:121]
    30: 023 35                           # ELSE goto 0035
    32: 028 116 118                      # RETURNF: [L:118]
    35: 043                              # BADRETURNF:
End SubProgram [find_from_to:00116]

Matt

18. Re: find_from and match_from

• Posted by Derek Parnell <ddparnell at bigpond.com> Mar 21, 2007
• 674 views

Derek Parnell wrote:
> 

> This is not conclusive. Although the IL says to create a slice and assign it
> to the temp, does the opcode RHS_SLICE actually allocate RAM for the
> subsequence
> and copy data to the new RAM, or does it just create a reference to the
> existing
> RAM? As the function never assigns to the slice, a reference is all it really
> needs.

Nevermind. I just looked at the back end source code for RHS_Slice() and it does
actually allocate RAM etc... Pity, it doesn't always have to.

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

20. Re: find_from and match_from

• Posted by Derek Parnell <ddparnell at bigpond.com> Mar 21, 2007
• 677 views
• Last edited Mar 22, 2007

Robert Craig wrote:
nt system.
> 
> However, even today, there are cases where a slice does
> not result in a new sequence being written. e.g.
> 
>    x = x[a..b]
> 
> will usually result in a simple update to the header
> of sequence x, to show that it starts later, or ends
> earlier (or both) in memory.

Ok. So something like this might be a tad faster ...

function find_from_to(integer N, integer L, object a, sequence b)
     b = b[N .. L]
     L=find(a,b)
     if L then
       L += N-1
     end if
     return L
end function

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

22. Re: find_from and match_from

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Mar 22, 2007
• 674 views

My tuppenceworth:
I will vote for this on two independent conditions:

1) Keep one opcode, just make it have 3 params, and put a 1 in there as and when
needed (details aside, see PS).

2) At least consider optional parameters, ie in hll it would be eg:

function find(object x, sequence s, integer i=1)
...
end function

The "=1" makes it possible to code find(x,s) *or* find(x,s,i).

Optional parameters would have to be on the RHS.

There are (at least) two ways to do this:
a) find(x,s) automagically passes the 1 as well.
b) find(x,s) assumes i is already set to 1 (ie less il, see PPPS).
I suspect that option b) is problematical for recursive routines.

Regards,
Pete
PS: OK,OK. I lied. This gets my vote anyway. I just wanted an excuse to prattle
on about optional parameters. If you managed 2) but not 1), I would be stunned.
Obviously a new opcode would share maybe 98% of code so I actually care not about
1), I was just, erm, setting up the field for optional parameters.
PPS: This is the same stuff as http://euwiki.ayo.biz/Find_from_and_match_from ,
yes? Didn't spot a link in this thread yet.
PPPS: One thing I figured out early doors when coding Positive was: if you
cannot do such things with builtins, how in **** you gona do it with user code?
Where it will actually be more useful. 

24. Re: find_from and match_from

• Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Mar 22, 2007
• 681 views

Pete Lomax wrote:
> 
> My tuppenceworth:
> I will vote for this on two independent conditions:
> 
> 1) Keep one opcode, just make it have 3 params, and put a 1 in there as and
> when needed (details aside, see PS).
> 
> 2) At least consider optional parameters, ie in hll it would be eg:

<snip>

Both interesting.  I think you'd have to somehow make the third optional,
or else we've probably broken 90% of the code out there.

> PS: OK,OK. I lied. This gets my vote anyway. I just wanted an excuse to
> prattle
> on about optional parameters. If you managed 2) but not 1), I would be
> stunned.
> Obviously a new opcode would share maybe 98% of code so I actually care not
> about 1), I was just, erm, setting up the field for optional parameters.
> PPS: This is the same stuff as http://euwiki.ayo.biz/Find_from_and_match_from
> , yes? Didn't spot a link in this thread yet.

Yes, forgot I'd put that up.

> PPPS: One thing I figured out early doors when coding Positive was: if you
> cannot
> do such things with builtins, how in **** you gona do it with user code? Where
> it will actually be more useful. 

I have thought about how to do it with a built in.  Specifically, I was
thinking of making a call_func/proc that didn't take a sequence, but the
arguments directly.  Basically, put in a negative number for the number
of arguments, whose absolute value is the minimum required number of 
arguments.  Of course, we'd have to establish a syntax for user code to
access arguments beyond the expected, or else also define the maximum
number of arguments as well.