OpenEuphoria

Re: Proposal for 'math.e' (2007-08-23)

• Posted by CChris <christian.cuvier at agriculture.go?v.f?> Aug 23, 2007
• 685 views

Juergen Luethje wrote:
> 
> CChris wrote:
> 
> > Juergen Luethje wrote:
> > 
> > > This is my current (2007-08-23) proposal for a "math.e" standard
> > > include file, according to the discussion here on EUforum.
> > > 
> > > Changes compared to the previous version:
> > > - Changed function sum(), so that it can't only add numbers,
> > >   but also sequences. 
> > > - Fixed a glitch in function rect_to_polar().
> 
> <snip>
> 
> > > type sequence_of_a_xor_s (object x)
> > >    -- A sequence whose top-level elements are either only atoms or only
> > >    -- sequences (or which is empty).
> > >    integer object_type
> > > 
> > >    if atom(x) then
> > >       return 0
> > >    end if
> > > 
> > >    if length(x) = 0 then
> > >       return 1
> > >    end if
> > > 
> > >    object_type = atom(x[1])
> > >    for i = 2 to length(x) do
> > >       if object_type != atom(x[i]) then
> > >          return 0
> > >       end if
> > >    end for
> > >    
> > >    return 1
> > > end type
> > > 
> > 
> > As I had mentioned earlier, this type doesn't
> > check for equal lengths of added items.
> > As a result, sum() may crash in the middle of its operation, and
> > the user has to figure out what happened. See my replacement proposal
> > (search for the "sequence_of_addables" keyword).
> 
> It's not necessary for me to search for it. I had answered to that post,
> but you didn't reply to my answer. And I deliberately have waited a
> rather long time before posting this new proposal.
> 

I thought I had. I'll check.

> BTW: Your type does not do what it should do. Checking the lengths
> of sequences must be done recursively with all sub-sequences. I
> previously _had_ posted such a type here, but you wrote that that type
> works too slow ...

They do indeed. Using a technique that will catch a large majority of problems
while being quite faster looked reasonable. And without type_check, the type is
probably useless anyway.

> 
> > The name of the type is mysterious too.
> 
> a) It is not mysterious (and it's only used internally anyway).
> b) Why didn't you write that earlier? With this kind of chaotic
>    discussion we'll never come to an end.
> 
> > > global function sum (sequence_of_a_xor_s list)
> > >    -- Return the sum of all elements in 'list'.
> > >    -- Note: This does not do a recursive sum of sub-sequences.
> > >    object ret
> > > 
> > >    if length(list) = 0 then
> > >       return 0
> > >    end if
> > > 
> > >    ret = list[1]
> > >    for i = 2 to length(list) do
> > >       ret += list[i]
> > >    end for
> > >    return ret
> > > end function
> 
> <snip>
> 
> > Also suggested, and not rejected AFAIK, were:
> > * a gamma(a) function - standard generalisation of the integer factorial;
> > * an erf(x) function (distribution function at x of the centered reduced
> > Gauss
> > probability density);
> > * an incomplete gamma function, part_gamma(a,x) - integrate the integrand of
> > gamma(a) over [0,x] and normalise by gamma(a).
> 
> Did anyone except of you say he wants these functions in a standard
> include file? Generally speaking, I think we shouldn't add something
> just because 1 person wants it. And if this is statistical stuff, then
> I suggest to put it in a "statistics.e" file, rather than the general
> "math.e" file.
> 

erf() is clearly used mostly in statistics, while gamma() has widespred uses
across analysis, andand part_gamma() is more closely related to physic.

erf() and gamma() would use common helper functions. If you really want to put
them in different files, the helpers will need to be global - this solves the
polynom evaluators issue, in a way.

CChris

> > There is ample supply of free C and Fortran code around to compute them, and
> > porting is not difficult, just tedious when the format of constants is not a
> > little endian sequence of bytes.
> > 
> > By the way, if I port (a small part of) the C library I have in mind, I'll
> > have
> > to port a polynom evaluator (uses Horner's method). Could be nice to make it
> > global, since it would be here anyway.
> > 
> > CChris
> 
> And there are dozens of other interesting math functions.
> So if we like, we can continue to make suggestions for the next five yeras,
> without ever actually releasing a standard "math.e" include file ...
> 
> Regards,
>    Juergen