OpenEuphoria

Re: Include file such as 'compare.e' or 'find.e'

• Posted by Juergen Luethje <j.lue at ?mx.?e> Aug 07, 2007
• 612 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