1. Include file such as 'compare.e' or 'find.e'
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'
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'
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'
> > - 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'
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'
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'
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'
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
-
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'
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'
> > 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'
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'
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'
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'
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
