1. can_add() and linear()

I'd suggest two additions to sequence.e, which I hope will appear pretty
natural:

global function can_add(object a,object b)
-- Determines whether a+b would crash the interpreter.
-- Returns 1 if addition possible, else 0.
    if atom(a) or atom(b) then
        return 1
    end if
    if length(a)!=length(b) then
        return 0
    end if
    for i=1 to length(a) do
        if not can_add(a[i],b[i]) then
            return 0
        end if
    end for
    return 1
end function

global funtion linear(object start,object increment,integer count)
-- Returns 0 on failure, or a sequence of count objects.
-- The first one is start, and the whole sequence is a linear progrssion using
increment.
    sequence result

    if count<0 or not can_add(start,increment) then
        return 0
    end if
    result=repeat(start,count)
    for i=2 to count do
        start+=increment
        result[i]=start
    end for
    return result
end function


The latter might go to math.e just as well, but for its dependency on can_add().

CChris

new topic     » topic index » view message » categorize

2. Re: can_add() and linear()

CChris wrote:
> 
> I'd suggest two additions to sequence.e, which I hope will appear pretty
> natural:
> 
> }}}
<eucode>
> global function can_add(object a,object b)
> -- Determines whether a+b would crash the interpreter.
> -- Returns 1 if addition possible, else 0.
>     if atom(a) or atom(b) then
>         return 1
>     end if
>     if length(a)!=length(b) then
>         return 0
>     end if
>     for i=1 to length(a) do
>         if not can_add(a[i],b[i]) then
>             return 0
>         end if
>     end for
>     return 1
> end function
> 
> global funtion linear(object start,object increment,integer count)
> -- Returns 0 on failure, or a sequence of count objects.
> -- The first one is start, and the whole sequence is a linear progrssion using
> increment.
>     sequence result
> 
>     if count<0 or not can_add(start,increment) then
>         return 0
>     end if
>     result=repeat(start,count)
>     for i=2 to count do
>         start+=increment
>         result[i]=start
>     end for
>     return result
> end function
> </eucode>
{{{

> 
> The latter might go to math.e just as well, but for its dependency on
> can_add().
> 
> CChris

More suggestions: 

global function project(sequence vectors,sequence coords) -- currently in sets.e
-- vectors is a rectangular matrix
-- coords is a list of coordinate lists
-- returns a sequence the length of vectors. Each element is a sequence,
-- the length of coords, of sequences. Each inner sequence is made of the 
-- coordinates of the vector for the given coord list.
sequence result,current_vector,coord_set,result_item,projection
integer current_index

result=vectors
for i=1 to length(vectors) do
    result_item=coords
    current_vector=vectors[i] 
    for j=1 to length(coords) do
        coord_set=coords[j]
        projection=coord_set
        for k=1 to length(coords_set) do
            current_index=coords[k]
            if current_index<1 or current_index>length(current_vector) then
crash("Invalid coordinate %d in set %d for vector
                #%d",{coords[k],j,i})
            end if
            projection[k]=current_vector[current_index]
        end for
        result_item[j]=projection
    end for
    result[i]=result_item
end for
return result
end function
</eucode>
{{{


fetch() and store() are useful too - they deal with variable length indexing of
sequences. The implementation is close to J. Babor's:
global function fetch(sequence s,sequence indexes)
    for i=1 to length(indexes)-1 do
        s=s[indexes[i]]
    end for
    return s[indexes[$]] 
end function

function store-(sequence s,sequence indexes,integer index,object x)
integer n

n=indexes[index]
if index=length(indexes) then
    s[n]=x
else
    s[n]=store_(s[n],indexes,index+1,x)
end if
return s
end function

global function store(sequence s,sequence indexes,object x)
return store_(s,indexes,1,x)
end function


For the sake of simplicity, I didn't consider using slices. A complete version
is to be found in http://oedoc.free.fr/Fichiers/ESL/seqops.zip, which agrees with
the OpenEu extended index specification.

CChris

new topic     » goto parent     » topic index » view message » categorize

3. Re: can_add() and linear()

CChris wrote:
> 
> CChris wrote:
> > 
> > I'd suggest two additions to sequence.e, which I hope will appear pretty
> > natural:
> > 
> > }}}
<eucode>
> > global function can_add(object a,object b)
> > -- Determines whether a+b would crash the interpreter.
> > -- Returns 1 if addition possible, else 0.
> >     if atom(a) or atom(b) then
> >         return 1
> >     end if
> >     if length(a)!=length(b) then
> >         return 0
> >     end if
> >     for i=1 to length(a) do
> >         if not can_add(a[i],b[i]) then
> >             return 0
> >         end if
> >     end for
> >     return 1
> > end function
> > 
> > global funtion linear(object start,object increment,integer count)
> > -- Returns 0 on failure, or a sequence of count objects.
> > -- The first one is start, and the whole sequence is a linear progrssion
> > using increment.
> >     sequence result
> > 
> >     if count<0 or not can_add(start,increment) then
> >         return 0
> >     end if
> >     result=repeat(start,count)
> >     for i=2 to count do
> >         start+=increment
> >         result[i]=start
> >     end for
> >     return result
> > end function
> > </eucode>
{{{

> > 
> > The latter might go to math.e just as well, but for its dependency on
> > can_add().
> > 
> > CChris
> 
> More suggestions: 
> 
> global function project(sequence vectors,sequence coords) -- currently in
> sets.e
> -- vectors is a rectangular matrix
> -- coords is a list of coordinate lists
> -- returns a sequence the length of vectors. Each element is a sequence,
> -- the length of coords, of sequences. Each inner sequence is made of the 
> -- coordinates of the vector for the given coord list.
> sequence result,current_vector,coord_set,result_item,projection
> integer current_index
> 
> result=vectors
> for i=1 to length(vectors) do
>     result_item=coords
>     current_vector=vectors[i] 
>     for j=1 to length(coords) do
>         coord_set=coords[j]
>         projection=coord_set
>         for k=1 to length(coords_set) do
>             current_index=coords[k]
>             if current_index<1 or current_index>length(current_vector) then
>                 crash("Invalid coordinate %d in set %d for vector
>                 #%d",{coords[k],j,i})
>             end if
>             projection[k]=current_vector[current_index]
>         end for
>         result_item[j]=projection
>     end for
>     result[i]=result_item
> end for
> return result
> end function
> </eucode>
{{{

> 
> fetch() and store() are useful too - they deal with variable length indexing
> of sequences. The implementation is close to J. Babor's:
> }}}
<eucode>
> global function fetch(sequence s,sequence indexes)
>     for i=1 to length(indexes)-1 do
>         s=s[indexes[i]]
>     end for
>     return s[indexes[$]] 
> end function
> 
> function store-(sequence s,sequence indexes,integer index,object x)
> integer n
> 
> n=indexes[index]
> if index=length(indexes) then
>     s[n]=x
> else
>     s[n]=store_(s[n],indexes,index+1,x)
> end if
> return s
> end function
> 
> global function store(sequence s,sequence indexes,object x)
> return store_(s,indexes,1,x)
> end function
> </eucode>
{{{

> 
> For the sake of simplicity, I didn't consider using slices. A complete version
> is to be found in <a
> href="http://oedoc.free.fr/Fichiers/ESL/seqops.zip,">http://oedoc.free.fr/Fichiers/ESL/seqops.zip,</a>
> which agrees with the OpenEu extended index specification.
> 
> CChris

There hasn't been a single comment regarding this post for the past 8 days. May
I assume that I can go ahead with the additions/moves?

CChris

new topic     » goto parent     » topic index » view message » categorize

4. Re: can_add() and linear()

CChris wrote:
> 
> 
> There hasn't been a single comment regarding this post for the past 8 days.
> May I assume that I can go ahead with the additions/moves?
> 

I am not certain if I would use the can_add and linear, but the fetch and store
seem pretty useful. Now, about can_add and linear.... just because I wouldn't use
them doesn't at all mean that others will not.  I've added many functions to the
standard library that I would not use but was deemed as useful to the general
public.

The rule is simple... will the general public find it useful? If so, you can
added it, document it and create unit tests for it, then commit. When I say
general public, I do not mean 2% of the Euphoria crowd, I mean > 50%. That's an
awfully hard number to judge, but all we can do is use our best judgment.

Once we hit an alpha stage, we are going to expect that most of the developers
are going to go over the docs for the standard library and functions one sees
"largely" questionable will be brought up for discussion. We also hope that when
an alpha is released that those interested in the future development of Euphoria
will also go over the new docs and do the same thing.

So, I would be pretty easy going about what goes into the standard library right
now trusting that each developer has a good head on their shoulders and is not
going to commit something like "days_until_chriss_birthday()" grin

--
Jeremy Cowgar
http://jeremy.cowgar.com

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu