1. Include file such as 'compare.e' or 'find.e'
- Posted by Juergen Luethje <j.lue at g?x.?e> Aug 06, 2007
- 612 views
Hello all, as Jacques has pointed out (and as we all know anyway ), the functions - find_least() - find_greatest() - least() - greatest() - lesser() - greater() are not special math functions. So I think we better should not put them in 'math.e', but rather in another new standard include file, say 'compare.e' or 'find.e', shouldn't we? This file also could be the home of binary_find(), and other functions that might be created, such as find_all(), find_any(), find_word(), soundex_find(), ... ). What do you all think? Yes or yes? Regards, Juergen
2. Re: Include file such as 'compare.e' or 'find.e'
- Posted by Salix <salix at ?r?email.hu> Aug 06, 2007
- 610 views
Juergen Luethje wrote: > > the functions > - find_least() > - find_greatest() > - least() > - greatest() > - lesser() > - greater() > are not special math functions. I'm sorry that the functions are not - find_min() - find_max() - min() - max() They would look much nicer. As of the original question: I would vote to keep them in math.e That's where I would try to find them first. Instead of a long list of find functions such as find_all(), find_any(), find_word(), soundex_find(), etc. I would recommend something like cutom_find()! (Similarly to custom_sort().) Regards, Salix
3. Re: Include file such as 'compare.e' or 'find.e'
- Posted by Juergen Luethje <j.lue at gm??de> Aug 06, 2007
- 602 views
Salix wrote: > Juergen Luethje wrote: > > > the functions > > - find_least() > > - find_greatest() > > - least() > > - greatest() > > - lesser() > > - greater() > > are not special math functions. > > I'm sorry that the functions are not > - find_min() > - find_max() > - min() > - max() > They would look much nicer. You are not the only one who says so. So what should we do now? And what names do you suggest for the other 2 functions then? > As of the original question: > I would vote to keep them in math.e > That's where I would try to find them first. > > Instead of a long list of find functions such as > find_all(), find_any(), find_word(), soundex_find(), etc. That was just a random thought. Just forget about it. > I would recommend something like cutom_find()! (Similarly > to custom_sort().) > > Regards, > > Salix Regards, Juergen
4. Re: Include file such as 'compare.e' or 'find.e'
- Posted by Salix <salix at freem?il?hu> Aug 06, 2007
- 589 views
> > - find_min() > > - find_max() > > - min() > > - max() > > They would look much nicer. > You are not the only one who says so. So what should we do now? > And what names do you suggest for the other 2 functions then? If lesser is meant to work like I think then it doesn't have much sense. I wouldn't introduce it at all. Practically you replace a 3 line expression for a 2 line expression.
-- old method object x x=pB if compare(pA,pB)<=0 then x=pA end if -- new method object x x=lesser(pA,pB)
It's not like find_max()/find_greatest() where you replace a whole 8-10 line loop for a simple expression. Or an arccos() where you simplify a complicated expression. But if I need to suggest new names for lesser() and greater() then I'd rather suggest a new function:
object a a=compare_ret(object x, object y).
Its return value would *not* be -1, 0, and 1 but x, y, and y. (In this order.) Lesser() and greater() are anyway special type compare functions. Regards, Salix P.S.: But I keep on searching for better names for lesser() and greater() in other languages.
5. Re: Include file such as 'compare.e' or 'find.e'
- Posted by CChris <christian.cuvier at agricultu?e.gouv.?r> Aug 06, 2007
- 581 views
Salix wrote: > > Juergen Luethje wrote: > > > the functions > > - find_least() > > - find_greatest() > > - least() > > - greatest() > > - lesser() > > - greater() > > are not special math functions. > > I'm sorry that the functions are not > - find_min() > - find_max() > - min() > - max() > They would look much nicer. > > As of the original question: > I would vote to keep them in math.e > That's where I would try to find them first. > > Instead of a long list of find functions such as > find_all(), find_any(), find_word(), soundex_find(), etc. > I would recommend something like cutom_find()! (Similarly > to custom_sort().) > > Regards, > > Salix That is exactly what I have tried to do with find_bounds(), but that seems to be a minority view. When I wrote locate.e for the ESL, I started out with special names like find_if(), find_any() and such. Then, as I realised that the number of such functions would grow out of what a standard user would memorise, I started from scratch and have a few functions that handle special, supposedly frequent cases, and a generic_locate() with all kinds of options which don't make it necessary to know all 57 string functions in the std C library (or 73, cant remember). Specialised routines are faster and shorter, but they lead to the problem of being just too many. As for the min/max names, they were seen by some as ambiguous. The current names are more precise; they may be a problem to tose whose mastery of english is minimal. As for the location, I think misc.e is an even more natural place to look for these routines than math.e. Yet the latter is still better than having yet another include file. CChris
6. Re: Include file such as 'compare.e' or 'find.e'
- Posted by Salix <salix at freema?l.?u> Aug 06, 2007
- 596 views
CChris wrote: > > As for the min/max names, they were seen by some as ambiguous. The current > names > are more precise; they may be a problem to tose whose mastery of english is > minimal. I don't get this. Why is it ambiguous? Why is not it precise? Sorry, most probably it is due to my limited English knowledge. I don't think that your comment is in line Fernando Bauer's (excellent) arguments at http://www.openeuphoria.org/EUforum/m15576.html . > As for the location, I think misc.e is an even more natural place to look for > these routines than math.e. Yet the latter is still better than having yet > another > include file. I would hesitate to add anything to misc.e as otherwise I should put everything there. Cheers, Salix
7. Re: Include file such as 'compare.e' or 'find.e'
- Posted by Jason Gade <jaygade at ya?o?.com> Aug 06, 2007
- 574 views
Juergen Luethje wrote: > > Hello all, > > as Jacques has pointed out (and as we all know anyway ), > the functions > - find_least() > - find_greatest() > - least() > - greatest() > - lesser() > - greater() > are not special math functions. > > So I think we better should not put them in 'math.e', but rather in > another new standard include file, say 'compare.e' or 'find.e', > shouldn't we? > > This file also could be the home of binary_find(), and other functions > that might be created, such as find_all(), find_any(), find_word(), > soundex_find(), ... ). > > What do you all think? Yes or yes? > > Regards, > Juergen Someone had suggested a new file named "e_misc.e" or some such... I'm not very good at picking names, though, so I'll leave that to others. -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
8. Re: Include file such as 'compare.e' or 'find.e'
- Posted by CChris <christian.cuvier at agri?ulture?gouv.fr> Aug 06, 2007
- 589 views
Salix wrote: > > CChris wrote: > > > > As for the min/max names, they were seen by some as ambiguous. The current > > names > > are more precise; they may be a problem to tose whose mastery of english is > > minimal. > > I don't get this. Why is it ambiguous? Why is not it precise? Sorry, most > probably it is due to my limited English knowledge. > Read please http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=5&fromYear=C&toMonth=7&toYear=C&postedBy=luethje&keywords=min > I don't think that your comment is in line Fernando Bauer's (excellent) > arguments at <a > href="http://www.openeuphoria.org/EUforum/m15576.html">http://www.openeuphoria.org/EUforum/m15576.html</a> > . > As I said, I don't share the current view, which is why I had given other names to these routines in the first place. Fernando is basically right imho. But there seems to be a majority against it. CChris > > As for the location, I think misc.e is an even more natural place to look > > for > > these routines than math.e. Yet the latter is still better than having yet > > another > > include file. > > I would hesitate to add anything to misc.e as otherwise I should > put everything there. > > Cheers, > > Salix
9. Re: Include file such as 'compare.e' or 'find.e'
- Posted by Derek Parnell <ddparnell at ?igpond.?om> Aug 06, 2007
- 588 views
- Last edited Aug 07, 2007
Salix wrote: > > CChris wrote: > > > > As for the min/max names, they were seen by some as ambiguous. The current > > names > > are more precise; they may be a problem to tose whose mastery of english is > > minimal. > > I don't get this. Why is it ambiguous? Why is not it precise? 'greatest' implies that there might be any number of things to test. 'greater' implies that there are only two things to test. Thus ... function greatest( SEQUENCE ) and function greater (OBJECT, OBJECT) But as you say, it is a subtle distinction that only some English speakers might pick up on. So if we are going to have one signature of 'sequence' and another of 'object, object', how should we name the functions (consistently) to give the reader a mnemonic to tell them apart from each other? I don't have an answer to that one yet. -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
10. Re: Include file such as 'compare.e' or 'find.e'
- Posted by Juergen Luethje <j.lue at gm?.?e> Aug 07, 2007
- 588 views
Derek Parnell wrote: > Salix wrote: > > > > CChris wrote: > > > > > > As for the min/max names, they were seen by some as ambiguous. The current > > > names > > > are more precise; they may be a problem to tose whose mastery of english > > > is > > > minimal. > > > > I don't get this. Why is it ambiguous? Why is not it precise? > > 'greatest' implies that there might be any number of things to test. > 'greater' implies that there are only two things to test. > > Thus ... > > function greatest( SEQUENCE ) > > and > > function greater (OBJECT, OBJECT) > > But as you say, it is a subtle distinction that only some English speakers > might > pick up on. > > So if we are going to have one signature of 'sequence' and another of 'object, > object', how should we name the functions (consistently) to give the reader > a mnemonic to tell them apart from each other? > > I don't have an answer to that one yet. How about - find_min(SEQUENCE) - find_max(SEQUENCE) - min(SEQUENCE) - max(SEQUENCE) - lesser(OBJECT, OBJECT) - greater(OBJECT, OBJECT) I think this wouldn't cause confusion. Regards, Juergen
11. Re: Include file such as 'compare.e' or 'find.e'
- Posted by Salix <salix at freemail.??> Aug 07, 2007
- 568 views
> > I don't have an answer to that one yet. > > How about > - find_min(SEQUENCE) > - find_max(SEQUENCE) > - min(SEQUENCE) > - max(SEQUENCE) > - lesser(OBJECT, OBJECT) > - greater(OBJECT, OBJECT) > > I think this wouldn't cause confusion. > I like it. Cheers, Salix
12. Re: Include file such as 'compare.e' or 'find.e'
- Posted by CChris <christian.cuvier at agricul?ur?.gouv.fr> Aug 07, 2007
- 571 views
Juergen Luethje wrote: > > Derek Parnell wrote: > > > Salix wrote: > > > > > > CChris wrote: > > > > > > > > As for the min/max names, they were seen by some as ambiguous. The > > > > current > names</font></i> > > > > are more precise; they may be a problem to tose whose mastery of english > > > > is > > > > minimal. > > > > > > I don't get this. Why is it ambiguous? Why is not it precise? > > > > 'greatest' implies that there might be any number of things to test. > > 'greater' implies that there are only two things to test. > > > > Thus ... > > > > function greatest( SEQUENCE ) > > > > and > > > > function greater (OBJECT, OBJECT) > > > > But as you say, it is a subtle distinction that only some English speakers > > might > > pick up on. > > > > So if we are going to have one signature of 'sequence' and another of > > 'object, > > object', how should we name the functions (consistently) to give the reader > > a mnemonic to tell them apart from each other? > > > > I don't have an answer to that one yet. > > How about > - find_min(SEQUENCE) > - find_max(SEQUENCE) > - min(SEQUENCE) > - max(SEQUENCE) > - lesser(OBJECT, OBJECT) > - greater(OBJECT, OBJECT) > > I think this wouldn't cause confusion. > > Regards, > Juergen That would be better than the current naming scheme. Note however that compile.e, like any language I know, defines min()/max() as the two object thing. In maths, you can overload min(); in Eu, you unfortunately cannot. And of course adding the bounds() parametrised function as well. CChris
13. Re: Include file such as 'compare.e' or 'find.e'
- Posted by Juergen Luethje <j.lue at g?x?de> Aug 07, 2007
- 588 views
CChris wrote: > Juergen Luethje wrote: > > > > Derek Parnell wrote: > > > > > Salix wrote: > > > > > > > > CChris wrote: > > > > > > > > > > As for the min/max names, they were seen by some as ambiguous. The > > > > > current > > names</font></i> > > > > > are more precise; they may be a problem to tose whose mastery of > > > > > english > is</font></i> > > > > > minimal. > > > > > > > > I don't get this. Why is it ambiguous? Why is not it precise? > > > > > > 'greatest' implies that there might be any number of things to test. > > > 'greater' implies that there are only two things to test. > > > > > > Thus ... > > > > > > function greatest( SEQUENCE ) > > > > > > and > > > > > > function greater (OBJECT, OBJECT) > > > > > > But as you say, it is a subtle distinction that only some English speakers > > > might > > > pick up on. > > > > > > So if we are going to have one signature of 'sequence' and another of > > > 'object, > > > object', how should we name the functions (consistently) to give the > > > reader > > > a mnemonic to tell them apart from each other? > > > > > > I don't have an answer to that one yet. > > > > How about > > - find_min(SEQUENCE) > > - find_max(SEQUENCE) > > - min(SEQUENCE) > > - max(SEQUENCE) > > - lesser(OBJECT, OBJECT) > > - greater(OBJECT, OBJECT) > > > > I think this wouldn't cause confusion. > > > > Regards, > > Juergen > > That would be better than the current naming scheme. > Note however that compile.e, like any language I know, defines min()/max() as > the two object thing. We already have had that discussion ... A function that returns the minimum of 2 objects is not necessary at all, because it's just a special case. The genaral case is a function that returns the minimum of a list of objects. This is -- of course! -- the way 'min' is used e.g. on mathworld.wolfram.com. Also, e.g. statistical sofware packages such as SPSS do not have a function minimum(object1, object2) at all. If such a function should be introduced in Euphoria for convenience, then it certainly should _not_ get the general name. The general name is to be used for the general function. > In maths, you can overload min(); in Eu, you unfortunately > cannot. > And of course adding the bounds() parametrised function as well. You still did not tell why it would be an advantage to have that function. Regards, Juergen
14. Re: Include file such as 'compare.e' or 'find.e'
- Posted by CChris <christian.cuvier at agricult??e.gouv.fr> Aug 07, 2007
- 583 views
Juergen Luethje wrote: > > CChris wrote: > > > Juergen Luethje wrote: > > > > > > Derek Parnell wrote: > > > > > > > Salix wrote: > > > > > > > > > > CChris wrote: > > > > > > > > > > > > As for the min/max names, they were seen by some as ambiguous. The > > > > > > current > > > names</font></i> > > > > > > are more precise; they may be a problem to tose whose mastery of > > > > > > english > > is</font></i> > > > > > > minimal. > > > > > > > > > > I don't get this. Why is it ambiguous? Why is not it precise? > > > > > > > > 'greatest' implies that there might be any number of things to test. > > > > 'greater' implies that there are only two things to test. > > > > > > > > Thus ... > > > > > > > > function greatest( SEQUENCE ) > > > > > > > > and > > > > > > > > function greater (OBJECT, OBJECT) > > > > > > > > But as you say, it is a subtle distinction that only some English > > > > speakers > might</font></i> > > > > pick up on. > > > > > > > > So if we are going to have one signature of 'sequence' and another of > > > > 'object, > > > > object', how should we name the functions (consistently) to give the > > > > reader > > > > a mnemonic to tell them apart from each other? > > > > > > > > I don't have an answer to that one yet. > > > > > > How about > > > - find_min(SEQUENCE) > > > - find_max(SEQUENCE) > > > - min(SEQUENCE) > > > - max(SEQUENCE) > > > - lesser(OBJECT, OBJECT) > > > - greater(OBJECT, OBJECT) > > > > > > I think this wouldn't cause confusion. > > > > > > Regards, > > > Juergen > > > > That would be better than the current naming scheme. > > Note however that compile.e, like any language I know, defines min()/max() > > as > > the two object thing. > > We already have had that discussion ... And that doesn't change how widespread the min(a,b) construction is. You simply cannot change that. > A function that returns the minimum of 2 objects is not necessary at all, > because it's just a special case. The genaral case is a function that > returns the minimum of a list of objects. This is -- of course! -- the way > 'min' is used e.g. on mathworld.wolfram.com. Also, e.g. statistical > sofware packages such as SPSS do not have a function > minimum(object1, object2) at all. While min({a,b}) is obviously equivalent to min(a,b), it is certainly a less efficient implementation, because you must create a useless pair to conform to the signature. Did you ever consider that a for loop was equivalent to a special form of while loop? You must be for the removal of "for" from the language, if you are serious. > If such a function should be introduced > in Euphoria for convenience, then it certainly should _not_ get the general > name. The general name is to be used for the general function. Disagree. The general name should be for the most widely used routine, which I believe is the special case here. This wouldn't hold in every case of course. > > > In maths, you can overload min(); in Eu, you unfortunately > > cannot. > > And of course adding the bounds() parametrised function as well. > > You still did not tell why it would be an advantage to have that function. > > Regards, > Juergen I did: * Because you need the {index, value} or {value,index} pair for "global" use, as an argument to printf() or as a subsequence to concatenate or patch somewhere. Discarding the value on return only to retrieve later is wasteful. * Because according to the context, you may have to dynamically choose whether you need a min or a max, an index or a value, and using routine_id() to make that choice is clumsier and slower - you must look up the routine names - than a parametrised routine. These two are good enough imho. CChris
15. Re: Include file such as 'compare.e' or 'find.e'
- Posted by Juergen Luethje <j.lue at ?mx.?e> Aug 07, 2007
- 613 views
CChris wrote: > Juergen Luethje wrote: > > > > CChris wrote: > > > > > Juergen Luethje wrote: > > > > > > > > Derek Parnell wrote: > > > > > > > > > Salix wrote: > > > > > > > > > > > > CChris wrote: > > > > > > > > > > > > > > As for the min/max names, they were seen by some as ambiguous. The > current</font></i> > > > > names</font></i> > > > > > > > are more precise; they may be a problem to tose whose mastery of > > > > > > > english > > > is</font></i> > > > > > > > minimal. > > > > > > > > > > > > I don't get this. Why is it ambiguous? Why is not it precise? > > > > > > > > > > 'greatest' implies that there might be any number of things to test. > > > > > 'greater' implies that there are only two things to test. > > > > > > > > > > Thus ... > > > > > > > > > > function greatest( SEQUENCE ) > > > > > > > > > > and > > > > > > > > > > function greater (OBJECT, OBJECT) > > > > > > > > > > But as you say, it is a subtle distinction that only some English > > > > > speakers > > might</font></i> > > > > > pick up on. > > > > > > > > > > So if we are going to have one signature of 'sequence' and another of > > > > > 'object, > > > > > object', how should we name the functions (consistently) to give the > > > > > reader > > > > > a mnemonic to tell them apart from each other? > > > > > > > > > > I don't have an answer to that one yet. > > > > > > > > How about > > > > - find_min(SEQUENCE) > > > > - find_max(SEQUENCE) > > > > - min(SEQUENCE) > > > > - max(SEQUENCE) > > > > - lesser(OBJECT, OBJECT) > > > > - greater(OBJECT, OBJECT) > > > > > > > > I think this wouldn't cause confusion. > > > > > > > > Regards, > > > > Juergen > > > > > > That would be better than the current naming scheme. > > > Note however that compile.e, like any language I know, defines min()/max() > > > as > > > the two object thing. > > > > We already have had that discussion ... > > And that doesn't change how widespread the min(a,b) construction is. You > simply > cannot change that. > > > A function that returns the minimum of 2 objects is not necessary at all, > > because it's just a special case. The genaral case is a function that > > returns the minimum of a list of objects. This is -- of course! -- the way > > 'min' is used e.g. on mathworld.wolfram.com. Also, e.g. statistical > > sofware packages such as SPSS do not have a function > > minimum(object1, object2) at all. > > While min({a,b}) is obviously equivalent to min(a,b), it is certainly a less > efficient implementation, because you must create a useless pair to conform > to the signature. Did you ever consider that a for loop was equivalent to a > special form of while loop? You must be for the removal of "for" from the > language, > if you are serious. > > > If such a function should be introduced > > in Euphoria for convenience, then it certainly should _not_ get the general > > name. The general name is to be used for the general function. > > Disagree. The general name should be for the most widely used routine, which > I believe is the special case here. This wouldn't hold in every case of > course. We seem to live on different planets. > > > In maths, you can overload min(); in Eu, you unfortunately > > > cannot. > > > And of course adding the bounds() parametrised function as well. > > > > You still did not tell why it would be an advantage to have that function. > > > > Regards, > > Juergen > > I did: > * Because you need the {index, value} or {value,index} pair for "global" use, > as an argument to printf() or as a subsequence to concatenate or patch > somewhere. > Discarding the value on return only to retrieve later is wasteful. > * Because according to the context, you may have to dynamically choose whether > you need a min or a max, an index or a value, and using routine_id() to make > that choice is clumsier and slower - you must look up the routine names - than > a parametrised routine. > > These two are good enough imho. For 99,9% of the programs it should be clear at "writing time", when a value and when an index to that value is needed. Even if there would be a need to make such a decision dynamically at runtime, this can be done -- like everyhing else -- with the functions that we will have anyway: find_min(), find_max(), min(), max(). Regards, Juergen