1. Re: math.e and misc.e
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.
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
> > > > 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.
> > > >
> > > > 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
> > > > 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?
CChris
