OpenEuphoria

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

• Posted by CChris <christian.cuvier at agricult?re?gouv.fr> Aug 29, 2007
• 666 views

Juergen Luethje wrote:
> 
> Robert Craig wrote:
> 
> > Juergen Luethje wrote:
> > > In the meantime, CChris suggested not to use the name "statistics.e",
> > > but to use "stats.e" instead.
> > > 
> > > Concerning the other points, there was no serious disagreement.
> > > So maybe you can now make the following official decisions:
> > > - There is agreement on the file name "compare.e".
> > > - There is agreement on the file name "math.e".
> > > - There is agreement, that no new global routines, constants or variables
> > >   will be added to the first release of "math.e"
> > >   ( The functions gamma(), part_gamma() and erf() will be contained in
> > >     the next proposal for "math.e" or "stat(istic)s.e". )
> > > 
> > > Making this official decision would allow me to continue, i.e. to post
> > > the most recent proposals for "math.e" and "compare.e".
> > 
> > I don't see any problem with using "statistics.e".
> > So go ahead with that.
> > Even the DOS version of Euphoria can open an existing 
> > non-8.3 filename for read or write. It just can't *create* 
> > a new one (and even that could be fixed if someone took the initiative).
> 
> OK, but "statistics.e" or not "statistics.e" was not my main concern.
> What I actually want to know is, whether there is now "official agreement"
> on the following points:
> - The file name "compare.e".
> - The file name "math.e".
> - No new global routines, constants or variables
>   will be added to the first release of "math.e".
>   ( The functions gamma(), part_gamma() and erf()
>     will be contained in the next proposal for
>     "math.e" or "statistics.e". )
> 

Perhaps there has to.

If gamma() and erf() are in two different files (why should that be?), the
common helper function they use, called polynom(), will have to be global.

Since it is useful in its own sake - it evaluates a polynom in one variable at a
point -, then it would be a good thing to make it public, since it would have to
be global.

One more point, Juergen: I do not understand how you can have a definitive
agreement on anything before all these implementation details are hammered out.
You are overlooking some of them, and I don't think it's a healthy thing to do,
since the interface - ie the set of documented routines - will be affected. It's
a strange game you are playing with us imho.

CChris

> Regards,
>    Juergen