1. can_add() and linear()
- Posted by CChris <christian.cuvier at agri?ulture.gou?.fr> May 11, 2008
- 686 views
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
2. Re: can_add() and linear()
- Posted by CChris <christian.cuvier at agriculture.go?v.fr> May 13, 2008
- 650 views
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
3. Re: can_add() and linear()
- Posted by CChris <christian.cuvier at ag?iculture.g?uv.fr> May 21, 2008
- 675 views
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
4. Re: can_add() and linear()
- Posted by Jeremy Cowgar <jeremy at cowg?r.?om> May 21, 2008
- 670 views
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()" -- Jeremy Cowgar http://jeremy.cowgar.com