1. Re: math.e and misc.e
CChris wrote:
> Juergen Luethje wrote:
> >
> > CChris wrote:
> >
> > > Juergen Luethje wrote:
> > >
> > > > CChris wrote:
> > > >
> > > > > [large snip]
> > > > >
>
> [yet mre snip]
> > > >
> > > > Issues or not -- a last_error global variable or function would IMHO be
> > > > much
> > > > better than the current situation. My favourite solution would be to
> > > > introduce a special 'object' NIL or NAN or something, that is returned
> > > > by
> > > > functions in order to unambiguously and consistenly signal an error.
> > > > I wrote that already several years ago ...
> > > >
> > >
> > > And I also suggested it would be a good thing. My guess is that it is too
> > > late
> > > for Eu to digest NIL. Too bad.
> >
> > Why is it too late to introduce NIL into Euphoria?
> >
>
> Because you'll have to test whether returned values are NIL or not. Since NIL
> is a no-value entity, you cannot do this using the standard if or while
> statement
> -> need for if_nil, if_not_nil, while_nil, while_not_nil. All logical
> operators
> would have to see their behaviour modified accordingly - actually, if any
> argument
> to anything is NIL, the result should be automatically NIL.
Oh, I see now.
> While I would welcome this as a definite enhancement to reliability of
> software
> written in Euphoria, just look at the reactions on this list about much less
> far reaching changes. Makes me wonder.
>
> > > > I'm ok with whatever people agree upon in this regard.
> > > > >
> > > > > Of course, if we could trap type check failures with resume/retry,
> > > > > things
> would</font></i>
> > > > > be much easier. But this is a wholly different topic.
> > > > >
> > > > > > > True, it should be global. Not hard to fix, is it?
> > > > > > >
> > > > > > > CChris
> > > > > >
> > > > > > Because it was not global, I had assumed that find_bounds() is an
> > > > > > internal function. But it's supposed to be called by the user, yes?
> > > > > > What is it's purpose, and what do the global constants
> > > > > > FB_MIN = 0,
> > > > > > FB_MAX = 8,
> > > > > > FB_INDEX = 1,
> > > > > > FB_VALUE = 2,
> > > > > > FB_PAIR = 4
> > > > > > mean?
> > > > > >
> > > > > > Regards,
> > > > > > Juergen
> > > > >
> > > > > The purpose of this function is to allow dynamic requesting the
> > > > > minimum or
> > maximum</font></i>
> > > > > index or value in a sequence, and allow more ways of returning results
> > > > > than
> > > > > greatest() and friends.
> > > > >
> > > > > The return_mode parameter is the sum of:
> > > > > * one or more of FB_INDEX, FB_VALUE, FB_PAIR
> > > > > * zero or more of FB_MIN and FB_MAX.
> > > > >
> > > > > Using FB_MIN asks to return something related to a minimum, FB_MAX for
> a maximum.</font></i>
> > > > >
> > > > > The allowable combinations of FB_INDEX, FB_VALUE, FB_PAIR are:
> > > > > * FB_VALUE to return the min or max value
> > > > > * FB_INDEX to return the index of the min or max value
> > > > > * FB_PAIR+FB_INDEX to return {index, value}
> > > > > * FB_PAIR+FB_VALUE to return {value, index}
> > > > > as code inspection should show imho.
> > > > > Currently FB_PAIR alone is valid and treated as FB_PAIR+FB_VALUE; this
> > > > > can
> be</font></i>
> > > > > avoided by changing the mask used to test the validity of return_mode
> > > > > to
> > > FB_INDEX+FB_VALUE.
> > > > > Unless it is allowed, which doesn't hurt either.
> > > >
> > > > I can't see a reason for putting such a clumsy function in a standard
> > > > library of a straight-forward and elegant language like Euphoria.
> > > >
> > >
> > > Perhaps could you explain why you are saying this. An elegant language
> > > (ahem,
> > > could be way better in this respect) like Euphoria needs both speed and
> > > flexibility,
> > > which are both part of elegance, even though they tend to contradict each
> > > other.
> > > The library would provide inflexible, fast routines and a slower, more
> > > flexible
> > > routine. Makes sense to me, so I don't get your point.
> >
> > I think it would make more sense the other way round. When we'll have
> > - find_least()
> > - find_greatest()
> > - least()
> > - greatest()
> >
> > maybe then the one who suggested that function can explain why it would
> > be necessary at all. When someone wants to get quickly the index AND the
> > value of say the greatest value in a list, then (s)he can use:
> > }}}
<eucode>
> > i_max = find_greatest(list, start)
> > v_max = list[i]
> > </eucode>
{{{
> > Do you actually want me to explain why I consider it inelegant to provide
> > an extra function with several parameter combinations for that purpose?
> >
> > Regards,
> > Juergen
>
> Do you want me to explain why I consider acquiring a value - and all the
> functions
> above need to eep a copy of the minimum or maximum value, even if they just
> return an index -, discarding it on return and then retrieving it again
> immediately
> inelegant and wasteful?
Curren6tly we do not talk about
- find_least()
- find_greatest()
- least()
- greatest()
since there already has been agreement to implement these functions.
The only remaining question is, whether or not an additional useless
and clumsy function should be added.
Regards,
Juergen
