1. Proposal for 'math.e' (2007-08-23)
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().
global constant
E = 2.7182818284590452,
PI = 3.1415926535897932,
EULER_GAMMA = 0.57721566490153286, -- Euler-Mascheroni constant
LN2 = log(2),
LN10 = log(10),
SQRT2 = sqrt(2),
HALF_SQRT2 = SQRT2/2.0,
HALF_PI = PI/2.0,
QUARTER_PI = PI/4.0,
TWO_PI = PI*2.0,
EULER_NORMAL = 1/sqrt(TWO_PI)
global function log2 (object x)
-- logarithm base 2
-- in : (sequence of) real number(s) > 0
-- out: (sequence of) real number(s)
-- Note: This function returns _exact_ results for all integral
-- powers of 2 in the half-closed interval ]0,#FFFFFFFF]
if atom(x) then
if x = #20000000 then
return 29 -- log(x)/LN2 is imprecise in this case
elsif x = #80000000 then
return 31 -- log(x)/LN2 is imprecise in this case
else
return log(x)/LN2
end if
end if
for i = 1 to length(x) do
x[i] = log2(x[i])
end for
return x
end function
global function log10 (object x)
-- logarithm base 10
-- in : (sequence of) real number(s) > 0
-- out: (sequence of) real number(s)
return log(x)/LN10
end function
type positive_not_1 (object x)
if atom(x) and x > 0 then
return x != 1
end if
return 0
end type
global function logx (object x, positive_not_1 base)
-- general logarithm function
-- in : x : (sequence of) atom(s) > 0
-- base: atom > 0 and != 1
-- out : (sequence of) atom(s)
-- Note: If x = 1 then the function returns 0 for any possible base.
return log(x)/log(base)
end function
global function exp (object x)
return power(E, x)
end function
global function sinh (object x)
return (exp(x) - exp(-x)) / 2
end function
global function cosh (object x)
return (exp(x) + exp(-x)) / 2
end function
global function tanh (object x)
return sinh(x) / cosh(x)
end function
global function arcsinh (object x)
return log(x + sqrt(x*x+1))
end function
type not_below_1 (object x)
if atom(x) then
return x >= 1.0
end if
for i = 1 to length(x) do
if not not_below_1(x[i]) then
return 0
end if
end for
return 1
end type
global function arccosh (not_below_1 x)
return log(x + sqrt(x*x-1))
end function
type abs_below_1 (object x)
if atom(x) then
return x > -1.0 and x < 1.0
end if
for i = 1 to length(x) do
if not abs_below_1(x[i]) then
return 0
end if
end for
return 1
end type
global function arctanh (abs_below_1 x)
return log((1+x)/(1-x)) / 2
end function
global function abs (object x)
-- return the absolute value of (all elements of) x
if atom(x) then
if x < 0 then
return -x
else
return x
end if
end if
for i = 1 to length(x) do
x[i] = abs(x[i])
end for
return x
end function
global function sign (object x)
-- x < 0 ==> -1
-- x = 0 ==> 0
-- x > 0 ==> +1
if atom(x) then
return compare(x, 0)
end if
for i = 1 to length(x) do
x[i] = sign(x[i])
end for
return x
end function
global function ceil (object x)
-- the opposite of floor()
-- Examples: ? ceil(3.2) --> 4
-- ? ceil({-3.2,7,1.6}) --> {-3,7,2}
return -floor(-x)
end function
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
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
constant RADIANS_TO_DEGREES = 180.0/PI
global function radians_to_degrees (object x)
-- in : (sequence of) angle(s) in radians
-- out: (sequence of) angle(s) in degrees
return x * RADIANS_TO_DEGREES
end function
constant DEGREES_TO_RADIANS = PI/180.0
global function degrees_to_radians (object x)
-- in : (sequence of) angle(s) in degrees
-- out: (sequence of) angle(s) in radians
return x * DEGREES_TO_RADIANS
end function
type trig_range (object x)
-- values passed to arccos and arcsin must be [-1,+1]
if atom(x) then
return x >= -1 and x <= 1
end if
for i = 1 to length(x) do
if not trig_range(x[i]) then
return 0
end if
end for
return 1
end type
global function arcsin (trig_range x)
-- returns angle in radians
return 2 * arctan(x / (1.0 + sqrt(1.0 - x * x)))
end function
global function arccos (trig_range x)
-- returns angle in radians
return HALF_PI - 2 * arctan(x / (1.0 + sqrt(1.0 - x * x)))
end function
type point_pol (object x)
if sequence(x) and (length(x) = 2)
and atom(x[1]) and (x[1] >= 0)
and atom(x[2]) then
return 1
end if
return 0
end type
global function polar_to_rect (point_pol p)
-- convert polar coordinates to rectangular coordinates
-- in : sequence of two atoms: {distance, angle};
-- 'distance' must be >= 0, 'angle' is in radians
-- out: sequence of two atoms: {x, y}
atom distance, angle, x, y
distance = p[1]
angle = p[2]
x = distance*cos(angle)
y = distance*sin(angle)
return {x, y}
end function
type point_xy (object x)
if sequence(x) and (length(x) = 2)
and atom(x[1])
and atom(x[2]) then
return 1
end if
return 0
end type
global function rect_to_polar (point_xy p)
-- convert rectangular coordinates to polar coordinates
-- in : sequence of two atoms: {x, y}
-- out: sequence of two atoms: {distance, angle}
-- - 'distance' is always >= 0
-- - 'angle' is an atom that expresses radians,
-- and is in the half-closed interval ]-PI,+PI].
-- If 'distance' equals 0, then 'angle' is undefined.
object angle
atom distance, x, y
x = p[1]
y = p[2]
distance = sqrt(x*x + y*y)
if x > 0 then
angle = arctan(y/x)
elsif x < 0 then
if y < 0 then
angle = arctan(y/x) - PI
else
angle = arctan(y/x) + PI
end if
else
if y < 0 then
angle = -HALF_PI
elsif y > 0 then
angle = HALF_PI
else
angle = 0 -- The angle is undefined in this case.
end if
end if
return {distance, angle}
end function
global function find_min (sequence list, integer start)
-- Search for the minimum value in 'list', beginning at index 'start'.
-- Return the index of that element.
-- Notes: This does not do a recursive compare on sub-sequences.
-- An empty sequence will cause a runtime error.
object temp
integer ret
temp = list[start]
ret = start
for i = start+1 to length(list) do
if compare(temp, list[i]) = 1 then
temp = list[i]
ret = i
end if
end for
return ret
end function
global function find_max (sequence list, integer start)
-- Search for the maximum value in 'list', beginning at index 'start'.
-- Return the index of that element.
-- Notes: This does not do a recursive compare on sub-sequences.
-- An empty sequence will cause a runtime error.
object temp
integer ret
temp = list[start]
ret = start
for i = start+1 to length(list) do
if compare(temp, list[i]) = -1 then
temp = list[i]
ret = i
end if
end for
return ret
end function
global function min (sequence list, integer start)
-- Search for the minimum value in 'list', beginning at index 'start'.
-- Return the value of that element.
-- Notes: This does not do a recursive compare on sub-sequences.
-- An empty sequence will cause a runtime error.
object ret
ret = list[start]
for i = start+1 to length(list) do
if compare(ret, list[i]) = 1 then
ret = list[i]
end if
end for
return ret
end function
global function max (sequence list, integer start)
-- Search for the maximum value in 'list', beginning at index 'start'.
-- Return the value of that element.
-- Notes: This does not do a recursive compare on sub-sequences.
-- An empty sequence will cause a runtime error.
object ret
ret = list[start]
for i = start+1 to length(list) do
if compare(ret, list[i]) = -1 then
ret = list[i]
end if
end for
return ret
end function
global function lesser (object x1, object x2)
-- Return the argument with the lesser value.
-- Note: This does not do a recursive compare on sub-sequences.
if compare(x1, x2) <= 0 then
return x1
else
return x2
end if
end function
global function greater (object x1, object x2)
-- Return the argument with the greater value.
-- Note: This does not do a recursive compare on sub-sequences.
if compare(x1, x2) >= 0 then
return x1
else
return x2
end if
end function
Regards,
Juergen
2. Re: Proposal for 'math.e' (2007-08-23)
I'm not sure if it is relevant here at all
but thinking of the recently fixed bug in
find_from() I would probably check the value
of start integer in some of the routines.
-- just one line
if start<1 then start=1 end if
Tisztelettel:
Salix
Juergen Luethje wrote:
> }}}
<eucode>
> global function min (sequence list, integer start)
> -- Search for the minimum value in 'list', beginning at index 'start'.
> -- Return the value of that element.
> -- Notes: This does not do a recursive compare on sub-sequences.
> -- An empty sequence will cause a runtime error.
> object ret
>
> ret = list[start]
> for i = start+1 to length(list) do
> if compare(ret, list[i]) = 1 then
> ret = list[i]
> end if
> end for
> return ret
> end function
>
> </eucode>
{{{
3. Re: Proposal for 'math.e' (2007-08-23)
Salix wrote:
> I'm not sure if it is relevant here at all
> but thinking of the recently fixed bug in
> find_from() I would probably check the value
> of start integer in some of the routines.
>
> }}}
<eucode>
> -- just one line
> if start<1 then start=1 end if
> </eucode>
{{{
Silently accepting false parameter values like this, was the way
find_from() had worked previously. Rob changed that for the current
3.1.1 release, so that find_from() does not accept wrong parameter
values any more.
E.g. functions min() and max() do behave the same way in this regard,
as find_from() is working now.
Regards,
Juergen
> Tisztelettel:
>
> Salix
>
> Juergen Luethje wrote:
> > }}}
<eucode>
> > global function min (sequence list, integer start)
> > -- Search for the minimum value in 'list', beginning at index 'start'.
> > -- Return the value of that element.
> > -- Notes: This does not do a recursive compare on sub-sequences.
> > -- An empty sequence will cause a runtime error.
> > object ret
> >
> > ret = list[start]
> > for i = start+1 to length(list) do
> > if compare(ret, list[i]) = 1 then
> > ret = list[i]
> > end if
> > end for
> > return ret
> > end function
> >
> > </eucode>
{{{
4. Re: Proposal for 'math.e' (2007-08-23)
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().
>
> }}}
<eucode>
> global constant
> E = 2.7182818284590452,
> PI = 3.1415926535897932,
> EULER_GAMMA = 0.57721566490153286, -- Euler-Mascheroni constant
> LN2 = log(2),
> LN10 = log(10),
> SQRT2 = sqrt(2),
> HALF_SQRT2 = SQRT2/2.0,
> HALF_PI = PI/2.0,
> QUARTER_PI = PI/4.0,
> TWO_PI = PI*2.0,
> EULER_NORMAL = 1/sqrt(TWO_PI)
>
>
> global function log2 (object x)
> -- logarithm base 2
> -- in : (sequence of) real number(s) > 0
> -- out: (sequence of) real number(s)
> -- Note: This function returns _exact_ results for all integral
> -- powers of 2 in the half-closed interval ]0,#FFFFFFFF]
>
> if atom(x) then
> if x = #20000000 then
> return 29 -- log(x)/LN2 is imprecise in this case
> elsif x = #80000000 then
> return 31 -- log(x)/LN2 is imprecise in this case
> else
> return log(x)/LN2
> end if
> end if
>
> for i = 1 to length(x) do
> x[i] = log2(x[i])
> end for
> return x
> end function
>
> global function log10 (object x)
> -- logarithm base 10
> -- in : (sequence of) real number(s) > 0
> -- out: (sequence of) real number(s)
>
> return log(x)/LN10
> end function
>
> type positive_not_1 (object x)
> if atom(x) and x > 0 then
> return x != 1
> end if
> return 0
> end type
>
> global function logx (object x, positive_not_1 base)
> -- general logarithm function
> -- in : x : (sequence of) atom(s) > 0
> -- base: atom > 0 and != 1
> -- out : (sequence of) atom(s)
> -- Note: If x = 1 then the function returns 0 for any possible base.
>
> return log(x)/log(base)
> end function
>
> global function exp (object x)
> return power(E, x)
> end function
>
> global function sinh (object x)
> return (exp(x) - exp(-x)) / 2
> end function
>
> global function cosh (object x)
> return (exp(x) + exp(-x)) / 2
> end function
>
> global function tanh (object x)
> return sinh(x) / cosh(x)
> end function
>
> global function arcsinh (object x)
> return log(x + sqrt(x*x+1))
> end function
>
> type not_below_1 (object x)
> if atom(x) then
> return x >= 1.0
> end if
>
> for i = 1 to length(x) do
> if not not_below_1(x[i]) then
> return 0
> end if
> end for
> return 1
> end type
>
> global function arccosh (not_below_1 x)
> return log(x + sqrt(x*x-1))
> end function
>
> type abs_below_1 (object x)
> if atom(x) then
> return x > -1.0 and x < 1.0
> end if
>
> for i = 1 to length(x) do
> if not abs_below_1(x[i]) then
> return 0
> end if
> end for
> return 1
> end type
>
> global function arctanh (abs_below_1 x)
> return log((1+x)/(1-x)) / 2
> end function
>
> global function abs (object x)
> -- return the absolute value of (all elements of) x
>
> if atom(x) then
> if x < 0 then
> return -x
> else
> return x
> end if
> end if
>
> for i = 1 to length(x) do
> x[i] = abs(x[i])
> end for
> return x
> end function
>
> global function sign (object x)
> -- x < 0 ==> -1
> -- x = 0 ==> 0
> -- x > 0 ==> +1
>
> if atom(x) then
> return compare(x, 0)
> end if
>
> for i = 1 to length(x) do
> x[i] = sign(x[i])
> end for
> return x
> end function
>
> global function ceil (object x)
> -- the opposite of floor()
> -- Examples: ? ceil(3.2) --> 4
> -- ? ceil({-3.2,7,1.6}) --> {-3,7,2}
>
> return -floor(-x)
> end function
>
> 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). The name of the type is mysterious too.
> 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
>
> constant RADIANS_TO_DEGREES = 180.0/PI
>
> global function radians_to_degrees (object x)
> -- in : (sequence of) angle(s) in radians
> -- out: (sequence of) angle(s) in degrees
>
> return x * RADIANS_TO_DEGREES
> end function
>
> constant DEGREES_TO_RADIANS = PI/180.0
>
> global function degrees_to_radians (object x)
> -- in : (sequence of) angle(s) in degrees
> -- out: (sequence of) angle(s) in radians
>
> return x * DEGREES_TO_RADIANS
> end function
>
> type trig_range (object x)
> -- values passed to arccos and arcsin must be [-1,+1]
> if atom(x) then
> return x >= -1 and x <= 1
> end if
>
> for i = 1 to length(x) do
> if not trig_range(x[i]) then
> return 0
> end if
> end for
> return 1
> end type
>
> global function arcsin (trig_range x)
> -- returns angle in radians
> return 2 * arctan(x / (1.0 + sqrt(1.0 - x * x)))
> end function
>
> global function arccos (trig_range x)
> -- returns angle in radians
> return HALF_PI - 2 * arctan(x / (1.0 + sqrt(1.0 - x * x)))
> end function
>
> type point_pol (object x)
> if sequence(x) and (length(x) = 2)
> and atom(x[1]) and (x[1] >= 0)
> and atom(x[2]) then
> return 1
> end if
> return 0
> end type
>
> global function polar_to_rect (point_pol p)
> -- convert polar coordinates to rectangular coordinates
> -- in : sequence of two atoms: {distance, angle};
> -- 'distance' must be >= 0, 'angle' is in radians
> -- out: sequence of two atoms: {x, y}
> atom distance, angle, x, y
>
> distance = p[1]
> angle = p[2]
> x = distance*cos(angle)
> y = distance*sin(angle)
> return {x, y}
> end function
>
> type point_xy (object x)
> if sequence(x) and (length(x) = 2)
> and atom(x[1])
> and atom(x[2]) then
> return 1
> end if
> return 0
> end type
>
> global function rect_to_polar (point_xy p)
> -- convert rectangular coordinates to polar coordinates
> -- in : sequence of two atoms: {x, y}
> -- out: sequence of two atoms: {distance, angle}
> -- - 'distance' is always >= 0
> -- - 'angle' is an atom that expresses radians,
> -- and is in the half-closed interval ]-PI,+PI].
> -- If 'distance' equals 0, then 'angle' is undefined.
> object angle
> atom distance, x, y
>
> x = p[1]
> y = p[2]
> distance = sqrt(x*x + y*y)
> if x > 0 then
> angle = arctan(y/x)
> elsif x < 0 then
> if y < 0 then
> angle = arctan(y/x) - PI
> else
> angle = arctan(y/x) + PI
> end if
> else
> if y < 0 then
> angle = -HALF_PI
> elsif y > 0 then
> angle = HALF_PI
> else
> angle = 0 -- The angle is undefined in this case.
> end if
> end if
> return {distance, angle}
> end function
>
> global function find_min (sequence list, integer start)
> -- Search for the minimum value in 'list', beginning at index 'start'.
> -- Return the index of that element.
> -- Notes: This does not do a recursive compare on sub-sequences.
> -- An empty sequence will cause a runtime error.
> object temp
> integer ret
>
> temp = list[start]
> ret = start
> for i = start+1 to length(list) do
> if compare(temp, list[i]) = 1 then
> temp = list[i]
> ret = i
> end if
> end for
> return ret
> end function
>
> global function find_max (sequence list, integer start)
> -- Search for the maximum value in 'list', beginning at index 'start'.
> -- Return the index of that element.
> -- Notes: This does not do a recursive compare on sub-sequences.
> -- An empty sequence will cause a runtime error.
> object temp
> integer ret
>
> temp = list[start]
> ret = start
> for i = start+1 to length(list) do
> if compare(temp, list[i]) = -1 then
> temp = list[i]
> ret = i
> end if
> end for
> return ret
> end function
>
> global function min (sequence list, integer start)
> -- Search for the minimum value in 'list', beginning at index 'start'.
> -- Return the value of that element.
> -- Notes: This does not do a recursive compare on sub-sequences.
> -- An empty sequence will cause a runtime error.
> object ret
>
> ret = list[start]
> for i = start+1 to length(list) do
> if compare(ret, list[i]) = 1 then
> ret = list[i]
> end if
> end for
> return ret
> end function
>
> global function max (sequence list, integer start)
> -- Search for the maximum value in 'list', beginning at index 'start'.
> -- Return the value of that element.
> -- Notes: This does not do a recursive compare on sub-sequences.
> -- An empty sequence will cause a runtime error.
> object ret
>
> ret = list[start]
> for i = start+1 to length(list) do
> if compare(ret, list[i]) = -1 then
> ret = list[i]
> end if
> end for
> return ret
> end function
>
> global function lesser (object x1, object x2)
> -- Return the argument with the lesser value.
> -- Note: This does not do a recursive compare on sub-sequences.
>
> if compare(x1, x2) <= 0 then
> return x1
<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).
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
5. Re: Proposal for 'math.e' (2007-08-23)
looks good to me, and gets my vote.
6. Re: Proposal for 'math.e' (2007-08-23)
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().
> >
> > }}}
<eucode>
> > global constant
> > E = 2.7182818284590452,
> > PI = 3.1415926535897932,
> > EULER_GAMMA = 0.57721566490153286, -- Euler-Mascheroni constant
> > LN2 = log(2),
> > LN10 = log(10),
> > SQRT2 = sqrt(2),
> > HALF_SQRT2 = SQRT2/2.0,
> > HALF_PI = PI/2.0,
> > QUARTER_PI = PI/4.0,
> > TWO_PI = PI*2.0,
> > EULER_NORMAL = 1/sqrt(TWO_PI)
> >
> >
> > global function log2 (object x)
> > -- logarithm base 2
> > -- in : (sequence of) real number(s) > 0
> > -- out: (sequence of) real number(s)
> > -- Note: This function returns _exact_ results for all integral
> > -- powers of 2 in the half-closed interval ]0,#FFFFFFFF]
> >
> > if atom(x) then
> > if x = #20000000 then
> > return 29 -- log(x)/LN2 is imprecise in this case
> > elsif x = #80000000 then
> > return 31 -- log(x)/LN2 is imprecise in this case
> > else
> > return log(x)/LN2
> > end if
> > end if
> >
> > for i = 1 to length(x) do
> > x[i] = log2(x[i])
> > end for
> > return x
> > end function
> >
> > global function log10 (object x)
> > -- logarithm base 10
> > -- in : (sequence of) real number(s) > 0
> > -- out: (sequence of) real number(s)
> >
> > return log(x)/LN10
> > end function
> >
> > type positive_not_1 (object x)
> > if atom(x) and x > 0 then
> > return x != 1
> > end if
> > return 0
> > end type
> >
> > global function logx (object x, positive_not_1 base)
> > -- general logarithm function
> > -- in : x : (sequence of) atom(s) > 0
> > -- base: atom > 0 and != 1
> > -- out : (sequence of) atom(s)
> > -- Note: If x = 1 then the function returns 0 for any possible base.
> >
> > return log(x)/log(base)
> > end function
> >
> > global function exp (object x)
> > return power(E, x)
> > end function
> >
> > global function sinh (object x)
> > return (exp(x) - exp(-x)) / 2
> > end function
> >
> > global function cosh (object x)
> > return (exp(x) + exp(-x)) / 2
> > end function
> >
> > global function tanh (object x)
> > return sinh(x) / cosh(x)
> > end function
> >
> > global function arcsinh (object x)
> > return log(x + sqrt(x*x+1))
> > end function
> >
> > type not_below_1 (object x)
> > if atom(x) then
> > return x >= 1.0
> > end if
> >
> > for i = 1 to length(x) do
> > if not not_below_1(x[i]) then
> > return 0
> > end if
> > end for
> > return 1
> > end type
> >
> > global function arccosh (not_below_1 x)
> > return log(x + sqrt(x*x-1))
> > end function
> >
> > type abs_below_1 (object x)
> > if atom(x) then
> > return x > -1.0 and x < 1.0
> > end if
> >
> > for i = 1 to length(x) do
> > if not abs_below_1(x[i]) then
> > return 0
> > end if
> > end for
> > return 1
> > end type
> >
> > global function arctanh (abs_below_1 x)
> > return log((1+x)/(1-x)) / 2
> > end function
> >
> > global function abs (object x)
> > -- return the absolute value of (all elements of) x
> >
> > if atom(x) then
> > if x < 0 then
> > return -x
> > else
> > return x
> > end if
> > end if
> >
> > for i = 1 to length(x) do
> > x[i] = abs(x[i])
> > end for
> > return x
> > end function
> >
> > global function sign (object x)
> > -- x < 0 ==> -1
> > -- x = 0 ==> 0
> > -- x > 0 ==> +1
> >
> > if atom(x) then
> > return compare(x, 0)
> > end if
> >
> > for i = 1 to length(x) do
> > x[i] = sign(x[i])
> > end for
> > return x
> > end function
> >
> > global function ceil (object x)
> > -- the opposite of floor()
> > -- Examples: ? ceil(3.2) --> 4
> > -- ? ceil({-3.2,7,1.6}) --> {-3,7,2}
> >
> > return -floor(-x)
> > end function
> >
> > 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). The name of the type is mysterious too.
>
> > 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.
<snip>
do you not think Gamma and erf are too specialized and advanced for a basic math
library?...
what about incorporating the routines from Rod Jackson's sets library (union,
intersection, etc), and possibly some simple stats functions like mean(),
median() std_dev(), or would these be better in a 'statistics.e'?
7. Re: Proposal for 'math.e' (2007-08-23)
sorry, the first part of my last post was a reply to CChris.
8. Re: Proposal for 'math.e' (2007-08-23)
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.
>
> }}}
<eucode>
> global function find_min (sequence list, integer start)
> global function find_max (sequence list, integer start)
> global function min (sequence list, integer start)
> global function max (sequence list, integer start)
> global function lesser (object x1, object x2)
> global function greater (object x1, object x2)
> </eucode>
{{{
I thought we had agreed these should be in a separate file, minmax.e. I do not
remember and I cannot find anyone specifically objecting to that, other than
CChris once saying he was "not sure" and "not against this split", and in the
next post reinventing your "allinc" idea seemed to sway him.
I also thought the final outcome of that long discussion was a general agreement
that no-one gets to use "min" and "max" to avoid ambiguity.
I shall restate my exact position on this:
I would not be too miffed if someone nicked the "min" name for a
single-parameter function min(sequence list), but once it has two parameters,
that is just asking for trouble.
I also cannot imagine any, let alone many, cases where the functions min() and
max() as posted would be useful, since they return a value not an index and I
question what you would do once you've processed that item and how/why would you
setup a suitable "start" value??
Regards,
Pete
9. Re: Proposal for 'math.e' (2007-08-23)
Jules wrote:
> do you not think Gamma and erf are too specialized and advanced for
> a basic math library?...
I would vote for three separate include files:
math.e (basic math)
statistics.e (statistics)
compare.e (min/max)
10. Re: Proposal for 'math.e' (2007-08-23)
c.k.lester wrote:
> Jules wrote:
>
> > do you not think Gamma and erf are too specialized and advanced for
> > a basic math library?...
>
> I would vote for three separate include files:
>
> math.e (basic math)
> statistics.e (statistics)
> compare.e (min/max)
I'd vote exactly for the same.
I actually had suggested "compare.e" about 2 weeks ago, and the only one
who replied was Salix, writing that he dodn't like it. Now you come up
with the same suggestion ...
Sorry, but with this chaotic way of discussing, we'll never come to an
end.
Regards,
Juergen
11. Re: Proposal for 'math.e' (2007-08-23)
Pete Lomax 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.
> >
> > }}}
<eucode>
> > global function find_min (sequence list, integer start)
> > global function find_max (sequence list, integer start)
> > global function min (sequence list, integer start)
> > global function max (sequence list, integer start)
> > global function lesser (object x1, object x2)
> > global function greater (object x1, object x2)
> > </eucode>
{{{
> I thought we had agreed these should be in a separate file, minmax.e. I do not
> remember and I cannot find anyone specifically objecting to that, other than
> CChris once saying he was "not sure" and "not against this split", and in the
> next post reinventing your "allinc" idea seemed to sway him.
>
More accurately:
If there is an umbrella include file that allows one, while developing at least,
not to care whether min() is in math.e, misc.e, compare.e, minmax.e or whatever
fancy place, then I can live with the proposed split. I still consider it to
increase confusion. The more you split, the more border cases as to where to
stick a given routine will arise. On the plus side, I can't see any benefit in
the split.
See, with the proposed math.e, which requires arcsin() to be moved from misc.e,
we'll have to deal with code that might break - that's why I suggested that
misc.e should include math.e at the end, so that code that includes misc.e keeps
working unaffected. Leaving arcsin() in misc.e, on the other hand, would be
nonsensical if there's a math.e besides.
> I also thought the final outcome of that long discussion was a general
> agreement
> that no-one gets to use "min" and "max" to avoid ambiguity.
>
The discussion died indeed, but I am not aware that an agreement was reached.
Unless you call "agreement" the situation where people simply stop posting their
position because they had done so repeatedly. 8 days later the posts go out of
EuForum's visible scope, and that's all folks.
> I shall restate my exact position on this:
> I would not be too miffed if someone nicked the "min" name for a
> single-parameter
> function min(sequence list), but once it has two parameters, that is just
> asking
> for trouble.
> I also cannot imagine any, let alone many, cases where the functions min() and
> max() as posted would be useful, since they return a value not an index and
> I question what you would do once you've processed that item and how/why would
> you setup a suitable "start" value??
That's how I use extreme values in 70% of cases, I'd say. In the other 30% it's
the index I'm after. As I have already stated, discarding the value for the sake
of retrieving it right after that is inelegant and wasteful, so why should it be
recommended?
CChris
> Regards,
> Pete
12. Re: Proposal for 'math.e' (2007-08-23)
Juergen Luethje wrote:
>
> c.k.lester wrote:
>
> > Jules wrote:
> >
> > > do you not think Gamma and erf are too specialized and advanced for
> > > a basic math library?...
> >
> > I would vote for three separate include files:
> >
> > math.e (basic math)
> > statistics.e (statistics)
> > compare.e (min/max)
>
> I'd vote exactly for the same.
Me too.
Unless someone disagrees strongly in the next few days,
maybe we can at least agree to break it down into
those three file names.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
13. Re: Proposal for 'math.e' (2007-08-23)
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.
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 ...
> 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.
> 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
14. Re: Proposal for 'math.e' (2007-08-23)
Juergen Luethje wrote:
> Sorry, but with this chaotic way of discussing, we'll never come to an
> end.
I guess the way things are going to have to work
for now, is that, when necessary, I will make the official decision
Yes/No, based on discussion and democratic voting.
I only want to have one vote, no veto, just like everyone else,
but someone has to ultimately and officially say Yes/No based
on the results of a democratic process. I can't stay
up-to-date and on top of all discussions though.
The person who is pushing for some new thing should try to
be sensitive to which parts of his/her proposal
seem to be generally accepted and which are controversial,
and not proceed with something that is controversial
without getting a clear vote and official approval on it.
Of course, we can't possibly vote on and officially approve
every detail. Developers need some freedom, once they know
they are doing something that is generally supported
If someone does something that people hate, it can
always be removed, especially if it's new and hasn't been used
by many people.
In many cases I'm just going to say Yes or No,
and if anyone doesn't like it, he can always
call for a vote.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
15. Re: Proposal for 'math.e' (2007-08-23)
CChris wrote:
> 8 days later the posts go out of EuForum's visible scope,
> and that's all folks.
Don't worry about that.
Junko has started working on this issue.
It will be fixed within a few days.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
16. Re: Proposal for 'math.e' (2007-08-23)
Robert Craig wrote:
> Juergen Luethje wrote:
>> Sorry, but with this chaotic way of discussing, we'll never come to an
>> end.
>
> I guess the way things are going to have to work
> for now, is that, when necessary, I will make the official decision
> Yes/No, based on discussion and democratic voting.
> I only want to have one vote, no veto, just like everyone else,
> but someone has to ultimately and officially say Yes/No based
> on the results of a democratic process.
I absolutely agree. And thank you! I think it's good when you will be
the one who'll do as described. Even if you only want to have one normal
vote, you are of course the "most official" person here.
[snipped in agreement]
Regards,
Juergen
17. Re: Proposal for 'math.e' (2007-08-23)
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
18. Re: Proposal for 'math.e' (2007-08-23)
CChris wrote:
>
> Pete Lomax wrote:
> > I question how/why would you setup a suitable "start" value??
>
> That's how I use extreme values in 70% of cases, I'd say.
Can you give me an example where you would use max(list,start) where start is
not 1?
Regards,
Pete
19. Re: Proposal for 'math.e' (2007-08-23)
Robert Craig wrote:
>
> Juergen Luethje wrote:
> >
> > c.k.lester wrote:
> >
> > > I would vote for three separate include files:
> > >
> > > math.e (basic math)
> > > statistics.e (statistics)
> > > compare.e (min/max)
> >
> > I'd vote exactly for the same.
>
> Me too.
Me too.
Regards,
Pete
20. Re: Proposal for 'math.e' (2007-08-23)
Juergen Luethje wrote:
>
> Silently accepting false parameter values like this, was the way
> find_from() had worked previously. Rob changed that for the current
> 3.1.1 release, so that find_from() does not accept wrong parameter
> values any more.
> E.g. functions min() and max() do behave the same way in this regard,
> as find_from() is working now.
>
Oh, you are right. I got confused by the different versions. :-]
Regards,
Salix
21. Re: Proposal for 'math.e' (2007-08-23)
CChris wrote:
> 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.
_I_ neither want to put them in different files, nor to put them in the
same file. Please discuss this with Matt or someone else who knows about
the meaning of these functions.
Regards,
Juergen
22. Re: Proposal for 'math.e' (2007-08-23)
Robert Craig wrote:
> Juergen Luethje wrote:
> >
> > c.k.lester wrote:
> >
> > > Jules wrote:
> > >
> > > > do you not think Gamma and erf are too specialized and advanced for
> > > > a basic math library?...
> > >
> > > I would vote for three separate include files:
> > >
> > > math.e (basic math)
> > > statistics.e (statistics)
> > > compare.e (min/max)
> >
> > I'd vote exactly for the same.
>
> Me too.
> Unless someone disagrees strongly in the next few days,
> maybe we can at least agree to break it down into
> those three file names.
And also, unless someone disagrees strongly in the next few days,
hopefully we can agree to stop suggesting new functions (or constants
or whatever) for the first release of "math.e" (*). Otherwise there will
never be a release of it.
Regards,
Juergen
(*) This does of course not apply to erf() and friends, which already
_have been_ suggested.
23. Re: Proposal for 'math.e' (2007-08-23)
- Posted by Bernie Ryan <xotron at ?luefrog.?om>
Aug 23, 2007
-
Last edited Aug 24, 2007
I think the problem is this:
CChris is uses math. on a regular basis in the performance of his job.
99.9% of the users on this list only use basic math in their projects.
The common users of Euphoria do not want broken code just to make it
easy for giant math. projects.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
24. Re: Proposal for 'math.e' (2007-08-23)
- Posted by Juergen Luethje <j.lue at ?mx.de>
Aug 23, 2007
-
Last edited Aug 24, 2007
Sorry for the rather late reply.
There was no discussion about "math.e" for a week or more. So I thought
I'd just post the new version with two little changes that have been
discussed seperately before, but then ... 
Pete Lomax 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.
>>
>>
>> global function find_min (sequence list, integer start)
>> global function find_max (sequence list, integer start)
>> global function min (sequence list, integer start)
>> global function max (sequence list, integer start)
>> global function lesser (object x1, object x2)
>> global function greater (object x1, object x2)
>>
> I thought we had agreed these should be in a separate file, minmax.e.
My impression was that some people didn't like to have that in a
separate file. And I have to admit that I can't remember having read
about the name "minmax.e". However, the current favourite name obviously
is "compare.e". I think this name is actually better, since that file
will also be a good place e.g. for a find_binary() function and more.
> I do not
> remember and I cannot find anyone specifically objecting to that, other than
> CChris once saying he was "not sure" and "not against this split", and in the
> next post reinventing your "allinc" idea seemed to sway him.
>
> I also thought the final outcome of that long discussion was a general
> agreement
> that no-one gets to use "min" and "max" to avoid ambiguity.
I wonder whether there will ever be a final outcome of that discussion.
Seriously:
Up to a certain point in time, there was (or seemed to be) such an
agreement. At that time we had (IIRC):
global function least (sequence list, integer start)
global function greatest (sequence list, integer start)
global function lesser (object x1, object x2)
global function greater (object x1, object x2)
Then came this post by Fernando Bauer:
<http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=6&fromYear=C&toMonth=8&toYear=C&postedBy=Fernando+Bauer&keywords=min2>
This post was the begin of a new round of the discussion.
Fernando actually suggested to use "min" and "min2" as initially
proposed by me. But I had the impression that some people especially
didn't like "min2". And then it also occured to me that probably the
_least confusion_ will be caused by using two completely different words.
So neither use min/min2 nor least/lesser, but min/lesser instead.
Up to now, no one has objected aginst that.
> I shall restate my exact position on this:
> I would not be too miffed if someone nicked the "min" name for a
> single-parameter
> function min(sequence list), but once it has two parameters, that is just
> asking
> for trouble.
> I also cannot imagine any, let alone many, cases where the functions min() and
> max() as posted would be useful, since they return a value not an index and
> I question what you would do once you've processed that item
Hu? Are you asking why statisticians want to get the minimum and maximum
values of a data collection?
> and how/why would you setup a suitable "start" value??
IIRC that was my idea. I was thinking of the fact, that it was necessary
to introduce a separate function find_from(), because find() was created
without a "start" parameter.
So I thought if we now create a min() function, then some time later we'd
introduce a function min_from().
But maybe a "start" parameter actually doesn't make much sense in this
context.
Regards,
Juergen
25. Re: Proposal for 'math.e' (2007-08-23)
- Posted by Juergen Luethje <j.lue at g??.de>
Aug 23, 2007
-
Last edited Aug 24, 2007
Me wrote:
> So I thought if we now create a min() function,
Ooops. That should have been:
"So I thought if we now create a min() function without
a 'start' parameter,"
> then some time later we'd
> introduce a function min_from().
> But maybe a "start" parameter actually doesn't make much sense in this
> context.
Regards,
Juergen
26. Re: Proposal for 'math.e' (2007-08-23)
- Posted by Derek Parnell <ddparnell at bigp?nd.co?>
Aug 23, 2007
-
Last edited Aug 24, 2007
c.k.lester wrote:
>
> Jules wrote:
>
> > do you not think Gamma and erf are too specialized and advanced for
> > a basic math library?...
>
> I would vote for three separate include files:
>
> math.e (basic math)
> statistics.e (statistics)
> compare.e (min/max)
A good idea.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
27. Re: Proposal for 'math.e' (2007-08-23)
- Posted by Derek Parnell <ddparnell at bi?po?d.com>
Aug 23, 2007
-
Last edited Aug 24, 2007
Juergen Luethje wrote:
>
> > 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.
There is nothing stopping the creation of a mathadv.e file to include advanced
maths routines.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
28. Re: Proposal for 'math.e' (2007-08-23)
- Posted by Jules <jdavy at d?l.pipex?com>
Aug 23, 2007
-
Last edited Aug 24, 2007
Derek Parnell wrote:
>
> c.k.lester wrote:
> >
> > Jules wrote:
> >
> > > do you not think Gamma and erf are too specialized and advanced for
> > > a basic math library?...
> >
> > I would vote for three separate include files:
> >
> > math.e (basic math)
> > statistics.e (statistics)
> > compare.e (min/max)
>
> A good idea.
>
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
Agreed. I'd like to see sets included in math.e though. They're basic, a
cornerstone of mathematics, and most importantly, very useful.
-- SETS.E
--
-- An include file to facilitate the declaration and manipulation
-- of mathematical sets constructed from Euphoria sequences.
--
-- Copyright November 2001 by Rod Jackson. All rights reserved.
--
-- This file is made freely available for all public, private,
-- and commercial uses. Please do not publicly distribute
-- modifications without the author's permission.
--
-- For additional information, please contact the author at:
-- rodjackson at bigfoot.com
--
--------------------------------------------------------------------
--
-- AVAILABLE CONSTANTS:
--
-- EMPTY_SET ==> an empty mathematical set; i.e., {}
--
-- AVAILABLE TYPES:
--
-- set ==> ensures that the variable is a sequence wherein
-- each of its members only occurs once in the sequence
--
-- AVAILABLE FUNCTIONS:
--
-- add_member ==> s = add_member (s, x)
-- adds a new member to a set, if it's not already a member
--
-- remove_member ==> s = remove_member (s, x)
-- removes the specified member from the set
--
-- union ==> s = union (s, s)
-- returns the union of two given sets
--
-- intersection ==> s = intersection (s, s)
-- returns the intersection of two given sets
--
-- diff ==> s = diff (s, s)
-- returns the difference of the two given sets; i.e.,
-- the inverse of the union (with the intersection removed)
--
-- is_subset ==> i = is_subset (s, s)
-- returns T (1) if the first set is a subset of the second
--
-- is_superset ==> i = is_superset (s, s)
-- returns T (1) if the first set is a superset of the 2nd
--
-------------------------------------------------------------------
---------------------
-- local constants --
---------------------
constant F = 0,
T = 1
global constant EMPTY_SET = {}
---------------------
-- local variables --
---------------------
integer p, L3, is_set
sequence s3, intersect, d
object o
------------------
-- global types --
------------------
global type set (object s)
if (atom (s)) then
is_set = F
else
is_set = T
for i = 2 to length (s) do
p = find (s[i], s[1..i-1])
if (p > 0) then
is_set = F
exit
end if
end for
end if
return is_set
end type -- set()
----------------------
-- global functions --
----------------------
global function add_member (object x, set s)
p = find (x, s)
if (p < 1) then
s = append (s, x)
end if
return s
end function -- add_member()
----------
global function remove_member (object x, set s)
p = find (x, s)
if (p > 0) then
s = s[1..p-1] & s[p+1..length(s)]
end if
return s
end function -- remove_member()
----------
global function union (set s1, set s2)
L3 = length (s1)
s3 = s1 & s2
for i = 1 to length (s2) do
o = s2[i]
p = find (o, s1)
if (p < 1) then
L3 = L3 + 1
s3[L3] = o
end if
end for
s3 = s3[1..L3]
return s3
end function -- union()
----------
global function intersection (set s1, set s2)
L3 = 0
s3 = repeat (0, length (s1))
for i = 1 to length (s2) do
o = s2[i]
p = find (o, s1)
if (p > 0) then
L3 = L3 + 1
s3[L3] = o
end if
end for
s3 = s3[1..L3]
return s3
end function -- intersection()
----------
global function diff (set s1, set s2)
s3 = EMPTY_SET
for i = 1 to length (s1) do
o = s1[i]
p = find (o, s2)
if (p < 1) then
s3 = append (s3, o)
end if
end for
for i = 1 to length (s2) do
o = s2[i]
p = find (o, s1)
if (p < 1) then
s3 = append (s3, o)
end if
end for
return s3
end function -- diff()
----------
global function is_subset (set sub, set super)
intersect = intersection (sub, super)
d = diff (intersect, sub)
if (length (d) > 0) then
return F
else
return T
end if
end function -- is_subset()
----------
global function is_superset (set super, set sub)
return is_subset (sub, super)
end function -- is_superset()
29. Re: Proposal for 'math.e' (2007-08-23)
- Posted by Juergen Luethje <j.lue at g?x.d?>
Aug 23, 2007
-
Last edited Aug 24, 2007
Derek Parnell wrote:
>
> Juergen Luethje wrote:
> >
>
> > > 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.
>
> There is nothing stopping the creation of a mathadv.e file to include advanced
> maths routines.
What does that mean in the given context? Are you suggesting that we
should create and release a "mathadv.e" standard include file along
with the "math.e" standard include file? Additionally to a "statistics.e"
file or instead of a "statistics.e" file?
Regards,
Juergen
30. Re: Proposal for 'math.e' (2007-08-23)
- Posted by Juergen Luethje <j.lue at gmx?d?>
Aug 23, 2007
-
Last edited Aug 24, 2007
Jules wrote:
> Derek Parnell wrote:
> >
> > c.k.lester wrote:
> > >
> > > Jules wrote:
> > >
> > > > do you not think Gamma and erf are too specialized and advanced for
> > > > a basic math library?...
> > >
> > > I would vote for three separate include files:
> > >
> > > math.e (basic math)
> > > statistics.e (statistics)
> > > compare.e (min/max)
> >
> > A good idea.
> >
> > --
> > Derek Parnell
> > Melbourne, Australia
> > Skype name: derek.j.parnell
>
> Agreed. I'd like to see sets included in math.e though. They're basic, a
> cornerstone
> of mathematics, and most importantly, very useful.
Routines for sets should be in a separate include file, not in "math.e".
Regards,
Juergen
31. Re: Proposal for 'math.e' (2007-08-23)
Juergen Luethje wrote:
> But maybe a "start" parameter actually doesn't make much sense in this
> context.
That is what I was trying to say.
Regards,
Pete
32. Re: Proposal for 'math.e' (2007-08-23)
Pete Lomax wrote:
>
> CChris wrote:
> >
> > Pete Lomax wrote:
> > > I question how/why would you setup a suitable "start" value??
> >
> > That's how I use extreme values in 70% of cases, I'd say.
>
> Can you give me an example where you would use max(list,start) where start is
> not 1?
>
> Regards,
> Pete
I have a data series which decreases, then increases, then decreases even more,
then increases less than before and so on. Think of global winter and summer
rainfall over the long run, for instance.
Then I'm interested not only in the absolute maximum (which start=1 will
return), but also the local maxima further down the road, for which I must filter
the first points in the series.
CChris
33. Re: Proposal for 'math.e' (2007-08-23)
> Jules wrote:
>> I'd like to see sets included in math.e though. They're basic,
>> a cornerstone of mathematics, and most importantly, very useful.
Juergen Luethje wrote:
> Routines for sets should be in a separate include file, not in "math.e".
Agreed. A separate file for "set" functionality.
> Derek wrote:
>> There is nothing stopping the creation of a mathadv.e file to
>> include advanced maths routines.
Juergen Luethje wrote:
> What does that mean in the given context? Are you suggesting
> that we should create and release a "mathadv.e" standard include
> file along with the "math.e" standard include file? Additionally
> to a "statistics.e" file or instead of a "statistics.e" file?
I suggest ...
math.e -- Commonly used mathematical functionality.
mathadv.e -- Not-so commonly used and advanced stuff.
eg. Calculus, Matrix, Vector, etc...
statistics.e -- functions just dealing with stats.
sets.e -- Set operations.
(Though separate files for each distinct area of advanced maths might be good
too).
I can also imagine some one creating a set of Financial maths functions, 2D and
3D geometrical functions, Volume functions, etc ...
By having them in separate files, people can mix'n'match as required.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
34. Re: Proposal for 'math.e' (2007-08-23)
CChris wrote:
> I have a data series which decreases, then increases, then decreases even
> more,
> then increases less than before and so on. Think of global winter and summer
> rainfall over the long run, for instance.
> Then I'm interested not only in the absolute maximum (which start=1 will
> return),
> but also the local maxima further down the road, for which I must filter the
> first points in the series.
Got it. You have a set of data which contains various intersecting and
non-intersecting subsets. Such as annual rainfall which has various subsets for
months, seasons, and ad hoc so one can ask questions such as ...
highest rainfall for the year, for March, for Summer, since "that dust storm
back on July 17th", etc ...
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
35. Re: Proposal for 'math.e' (2007-08-23)
CChris wrote:
>
> Pete Lomax wrote:
> >
> > CChris wrote:
> > >
> > > Pete Lomax wrote:
> > > > I question how/why would you setup a suitable "start" value??
> > >
> > > That's how I use extreme values in 70% of cases, I'd say.
> >
> > Can you give me an example where you would use max(list,start) where start
> > is
> > not 1?
> >
> > Regards,
> > Pete
>
> I have a data series which decreases, then increases, then decreases even
> more,
> then increases less than before and so on. Think of global winter and summer
> rainfall over the long run, for instance.
> Then I'm interested not only in the absolute maximum (which start=1 will
> return),
> but also the local maxima further down the road, for which I must filter the
> first points in the series.
So you can write a report which says:
The maxmimum rainfall between 1823 (when records began) and 2007 was 22.75 but
I'm not telling you when.
The maxmimum rainfall between 1938 and 2007 was 22.75 but no idea when.
The maxmimum rainfall between 1961 and 2007 was 18.75 but no idea when.
The maxmimum rainfall between 1979 and 2007 was 18.75 but no idea when.
The maxmimum rainfall between 2001 and 2007 was 18.75 but no idea when.
Clearly I am not convinced. What possible use are those numbers other than the
first? Do you have a better example?
Do you have some actual code that actually works?
Regards,
Pete
36. Re: Proposal for 'math.e' (2007-08-23)
Derek Parnell wrote:
>
> CChris wrote:
> > I have a data series which decreases, then increases, then decreases even
> > more,
> > then increases less than before and so on. Think of global winter and summer
> > rainfall over the long run, for instance.
> > Then I'm interested not only in the absolute maximum (which start=1 will
> > return),
> > but also the local maxima further down the road, for which I must filter the
> > first points in the series.
>
> Got it. You have a set of data which contains various intersecting and
> non-intersecting
> subsets. Such as annual rainfall which has various subsets for months,
> seasons,
> and ad hoc so one can ask questions such as ...
>
> highest rainfall for the year, for March, for Summer, since "that dust
> storm
> back on July 17th", etc ...
But how can you get the highest rainfall for 2006, or March, or Summer, via a
max(list,start) function?
With max(list[i..j],1), that's how.
So it should be either max(list) or max(list,start,end).
Obviously this is a "whee I can write some code" moment, and no real thought has
yet been put towards anybody actually finding the [] thing useful.
Regards,
Pete
37. Re: Proposal for 'math.e' (2007-08-23)
Pete Lomax wrote:
> But how can you get the highest rainfall for 2006, or March, or Summer, via
> a max(list,start) function?
>
> With max(list[i..j],1), that's how.
Yep. You've convinced me that the max(list,start) is too rare an event to be
required as standard functionality.
I guess
max(list[start..$])
should suffice.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
38. Re: Proposal for 'math.e' (2007-08-23)
I would prefer the simplier (see: max(list)) version.
If I need to specify for my (hobby) projects I'm ready
to write a separate routine and/or use max(list[start..end])
even if it is less efficent. (Although I can hardly imagine
any sigificant difference if length(list)<10000.)
Yours,
Salix
Pete Lomax wrote:
>
>
> But how can you get the highest rainfall for 2006, or March, or Summer, via
> a max(list,start) function?
>
> With max(list[i..j],1), that's how.
>
> So it should be either max(list) or max(list,start,end).
>
> Obviously this is a "whee I can write some code" moment, and no real thought
> has yet been put towards anybody actually finding the [] thing useful.
>
> Regards,
> Pete
39. Re: Proposal for 'math.e' (2007-08-23)
Pete Lomax wrote:
> Derek Parnell wrote:
> >
> > CChris wrote:
> > > I have a data series which decreases, then increases, then decreases even
> > > more,
> > > then increases less than before and so on. Think of global winter and
> > > summer
> > > rainfall over the long run, for instance.
> > > Then I'm interested not only in the absolute maximum (which start=1 will
> > > return),
> > > but also the local maxima further down the road, for which I must filter
> > > the
> > > first points in the series.
> >
> > Got it. You have a set of data which contains various intersecting and
> > non-intersecting
> > subsets. Such as annual rainfall which has various subsets for months,
> > seasons,
> > and ad hoc so one can ask questions such as ...
> >
> > highest rainfall for the year, for March, for Summer, since "that dust
> > storm
> > back on July 17th", etc ...
>
> But how can you get the highest rainfall for 2006, or March, or Summer, via
> a max(list,start) function?
>
> With max(list[i..j],1), that's how.
>
> So it should be either max(list) or max(list,start,end).
>
> Obviously this is a "whee I can write some code" moment, and no real thought
> has yet been put towards anybody actually finding the [] thing useful.
So do you think the 'start' parameter does make sense in the function
find_max(sequence list, integer start) ?
Regards,
Juergen
40. Re: Proposal for 'math.e' (2007-08-23)
> Routines for sets should be in a separate include file, not in "math.e".
>
> Regards,
> Juergen
I'm not going to make a big fuss about it, but why? sets are the foundation of
all mathematical systems, underlying all functions, relations, and logic. Any
decent maths text book will start with sets, then go on to basic functions etc.
IMO relegating them to a separate include file will give the them the status of
a 'specialist' topic, (like matrices, statistics, etc) whereas in fact they are
the basis from which all other disciplines are derived.
If I had my way I'd build them into the interpreter, but maybe that's pushing it
too far.
41. Re: Proposal for 'math.e' (2007-08-23)
Jules wrote:
>
> > Routines for sets should be in a separate include file, not in "math.e".
> >
> > Regards,
> > Juergen
>
> I'm not going to make a big fuss about it, but why? sets are the foundation
> of all mathematical systems, underlying all functions, relations, and logic.
That they may be, but the file will contain set OPERATIONS, and they are not
commonly used. In other words, just because sets are the basis of mathematically
systems it doesn't follow that therefore set operations are used all the time.
> Any decent maths text book will start with sets, then go on to basic functions
> etc.
> IMO relegating them to a separate include file will give the them the status
> of a 'specialist' topic, (like matrices, statistics, etc) whereas in fact they
> are the basis from which all other disciplines are derived.
In the same way that petrol (gas) is the basis of my car's internal combustion
engine but it doesn't mean that I do 'petrol' operations when selecting a
different radio station.
If I need to find the cube root of something I don't use set theory or practice;
I call the power() function. In fact, I can't recall the last time I needed a set
function for any maths in my programs.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
42. Re: Proposal for 'math.e' (2007-08-23)
Derek Parnell wrote:
> Jules wrote:
> >
> > > Routines for sets should be in a separate include file, not in "math.e".
> > >
> > > Regards,
> > > Juergen
> >
> > I'm not going to make a big fuss about it, but why? sets are the foundation
> > of all mathematical systems, underlying all functions, relations, and logic.
>
> That they may be, but the file will contain set OPERATIONS, and they are not
> commonly used. In other words, just because sets are the basis of
> mathematically
> systems it doesn't follow that therefore set operations are used all the time.
>
>
> > Any decent maths text book will start with sets, then go on to basic
> > functions
> > etc.
> > IMO relegating them to a separate include file will give the them the status
> > of a 'specialist' topic, (like matrices, statistics, etc) whereas in fact
> > they
> > are the basis from which all other disciplines are derived.
>
> In the same way that petrol (gas) is the basis of my car's internal combustion
> engine but it doesn't mean that I do 'petrol' operations when selecting a
> different
> radio station.
And although an apple consists of atoms, fortunately I don't have to study
nuclear physics before I can eat it.
> If I need to find the cube root of something I don't use set theory or
> practice;
> I call the power() function. In fact, I can't recall the last time I needed
> a set function for any maths in my programs.
I fully agree. Just a short additional note:
Like in real life, it doesn't make sense to put too many things of
different kinds into one big box (file). That's why the include
statement was invented. From the point of view of a programming
language, operatons on sets (and data types for sets) are an entity
of their own. So it's a matter of course that they should be in their
own separate include file. This will also reduce maintainance costs.
Regards,
Juergen
43. Re: Proposal for 'math.e' (2007-08-23)
Derek Parnell wrote:
>
> Jules wrote:
> >
> > > Routines for sets should be in a separate include file, not in "math.e".
> > >
> > > Regards,
> > > Juergen
> >
> > I'm not going to make a big fuss about it, but why? sets are the foundation
> > of all mathematical systems, underlying all functions, relations, and logic.
>
> That they may be, but the file will contain set OPERATIONS, and they are not
> commonly used. In other words, just because sets are the basis of
> mathematically
> systems it doesn't follow that therefore set operations are used all the time.
they are, but you just don't realise it. :)
In fact, you mentioned set operations in a recent post in this thread, replying
to CChris:
--------------------------------------------------------------------------
"CChris wrote:
> I have a data series which decreases, then increases, then decreases even
> more,
> then increases less than before and so on. Think of global winter and summer
> rainfall over the long run, for instance.
> Then I'm interested not only in the absolute maximum (which start=1 will
> return),
> but also the local maxima further down the road, for which I must filter the
> first points in the series.
Got it. You have a set of data which contains various intersecting and
non-intersecting
subsets. Such as annual rainfall which has various subsets for months, seasons,
and ad hoc so one can ask questions such as ...
highest rainfall for the year, for March, for Summer, since "that dust storm
back on July 17th", etc ..."
---------------------------------------------------------------------------
I think you're taking too narrow and limited a view of set operations.
Euphoria's power and flexibility comes from sequences, which can be regarded as
sets (collections of objects). If you look at the descriptions of the set
operations in sets.e and mentally replace each occurrence of 'set' with
'sequence' you'll get a better idea of how useful they can be, and not just in
computational applications. In fact maybe that's their 'weakness', they're so
generic we take them for granted.
Take 'Intersection' and 'Union' for example. These are closely related to 'and'
and 'or' respectively, but are more powerful in the sense that they return the
actual sequence elements, not just 1's and 0's.
44. Re: Proposal for 'math.e' (2007-08-23)
Jules wrote:
>
> Derek Parnell wrote:
> >
> > Jules wrote:
> > >
> > > > Routines for sets should be in a separate include file, not in "math.e".
> > > >
> > > > Regards,
> > > > Juergen
> > >
> > > I'm not going to make a big fuss about it, but why? sets are the
> > > foundation
> > > of all mathematical systems, underlying all functions, relations, and
> > > logic.
> >
> > That they may be, but the file will contain set OPERATIONS, and they are not
> > commonly used. In other words, just because sets are the basis of
> > mathematically
> > systems it doesn't follow that therefore set operations are used all the
> > time.
>
> they are, but you just don't realise it. :)
Remember the context we are talking in : putting set operations inside a MATH.E
file.
I know sets. I use sets all the time both in programming and real life. But in
the context of maths operations, I rarely if ever, use raw set operations. If
they are used, it is in the background and not explicitly.
> Take 'Intersection' and 'Union' for example. These are closely related to
> 'and'
> and 'or' respectively, but are more powerful in the sense that they return the
> actual sequence elements, not just 1's and 0's.
Yes that is true. But it ain't maths and it is specialized (uncommon)
functionality, so therefore put these useful functions in their own include file
and not in amongst all the commonly used math operations.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
45. Re: Proposal for 'math.e' (2007-08-23)
Pete Lomax wrote:
>
> CChris wrote:
> >
> > Pete Lomax wrote:
> > >
> > > CChris wrote:
> > > >
> > > > Pete Lomax wrote:
> > > > > I question how/why would you setup a suitable "start" value??
> > > >
> > > > That's how I use extreme values in 70% of cases, I'd say.
> > >
> > > Can you give me an example where you would use max(list,start) where start
> > > is
> > > not 1?
> > >
> > > Regards,
> > > Pete
> >
> > I have a data series which decreases, then increases, then decreases even
> > more,
> > then increases less than before and so on. Think of global winter and summer
> > rainfall over the long run, for instance.
> > Then I'm interested not only in the absolute maximum (which start=1 will
> > return),
> > but also the local maxima further down the road, for which I must filter the
> > first points in the series.
>
> So you can write a report which says:
> The maxmimum rainfall between 1823 (when records began) and 2007 was 22.75 but
> I'm not telling you when.
> The maxmimum rainfall between 1938 and 2007 was 22.75 but no idea when.
> The maxmimum rainfall between 1961 and 2007 was 18.75 but no idea when.
> The maxmimum rainfall between 1979 and 2007 was 18.75 but no idea when.
> The maxmimum rainfall between 2001 and 2007 was 18.75 but no idea when.
>
> Clearly I am not convinced. What possible use are those numbers other than the
> first? Do you have a better example?
> Do you have some actual code that actually works?
>
> Regards,
> Pete
I don't usually monitor pointwise dated events, but try to see trends in a
sequence of such data. So I'm not using individual maxima, but the series of such
maxima itself. However, I may have to point out some outlier, in which case I
need the "how much" and the "when", but this is definitely not the biggest part
of the picture.
CChris
46. Re: Proposal for 'math.e' (2007-08-23)
Derek Parnell wrote:
>
> Jules wrote:
> >
> > Derek Parnell wrote:
> > >
> > > Jules wrote:
> > > >
> > > > > Routines for sets should be in a separate include file, not in
> > > > > "math.e".
> > > > >
> > > > > Regards,
> > > > > Juergen
> > > >
> > > > I'm not going to make a big fuss about it, but why? sets are the
> > > > foundation
> > > > of all mathematical systems, underlying all functions, relations, and
> > > > logic.
> > >
> > > That they may be, but the file will contain set OPERATIONS, and they are
> > > not
> > > commonly used. In other words, just because sets are the basis of
> > > mathematically
> > > systems it doesn't follow that therefore set operations are used all the
> > > time.
> >
> > they are, but you just don't realise it. :)
>
>
> Remember the context we are talking in : putting set operations inside a
> MATH.E
> file.
>
> I know sets. I use sets all the time both in programming and real life. But
> in the context of maths operations, I rarely if ever, use raw set operations.
> If they are used, it is in the background and not explicitly.
>
>
> > Take 'Intersection' and 'Union' for example. These are closely related to
> > 'and'
> > and 'or' respectively, but are more powerful in the sense that they return
> > the
> > actual sequence elements, not just 1's and 0's.
>
> Yes that is true. But it ain't maths and it is specialized (uncommon)
> functionality,
> so therefore put these useful functions in their own include file and not in
> amongst all the commonly used math operations.
>
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
Could you consider that the word "commonly" means sometimes opposed things for
different people?
I suggest spinning the DOS graphic functions off to a separate include file,
which does not need to be standard. They are specialised - much more than set
operations -, and in 6 or 7 years I never used any of them a single time. This
will make Euphoria simpler.
CChris
47. Re: Proposal for 'math.e' (2007-08-23)
CChris wrote:
> Could you consider that the word "commonly" means sometimes opposed things for
> different people?
Yep.
> I suggest spinning the DOS graphic functions off to a separate include file,
> which does not need to be standard. They are specialised - much more than set
> operations -, and in 6 or 7 years I never used any of them a single time. This
> will make Euphoria simpler.
Sounds good to me too.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
48. Re: Proposal for 'math.e' (2007-08-23)
Juergen Luethje wrote:
>
> So do you think the 'start' parameter does make sense in the function
> find_max(sequence list, integer start) ?
>
Yes, you can do something useful / lots more with an index, eg:
for i=1 to length(s) do
k=find_max(s,i)
?s[k]
s[k]=s[i]
end for
Regards,
Pete
49. Re: Proposal for 'math.e' (2007-08-23)
CChris wrote:
> Derek Parnell wrote:
> >
> > Jules wrote:
> > >
> > > Derek Parnell wrote:
> > > >
> > > > Jules wrote:
> > > > >
> > > > > > Routines for sets should be in a separate include file, not in
> > > > > > "math.e".
> > > > > >
> > > > > > Regards,
> > > > > > Juergen
> > > > >
> > > > > I'm not going to make a big fuss about it, but why? sets are the
> > > > > foundation
> > > > > of all mathematical systems, underlying all functions, relations, and
> > > > > logic.
> > > >
> > > > That they may be, but the file will contain set OPERATIONS, and they are
> > > > not
> > > > commonly used. In other words, just because sets are the basis of
> > > > mathematically
> > > > systems it doesn't follow that therefore set operations are used all the
> > > > time.
> > >
> > > they are, but you just don't realise it. :)
> >
> >
> > Remember the context we are talking in : putting set operations inside a
> > MATH.E
> > file.
> >
> > I know sets. I use sets all the time both in programming and real life. But
> > in the context of maths operations, I rarely if ever, use raw set
> > operations.
> > If they are used, it is in the background and not explicitly.
> >
> >
> > > Take 'Intersection' and 'Union' for example. These are closely related to
> > > 'and'
> > > and 'or' respectively, but are more powerful in the sense that they return
> > > the
> > > actual sequence elements, not just 1's and 0's.
> >
> > Yes that is true. But it ain't maths and it is specialized (uncommon)
> > functionality,
> > so therefore put these useful functions in their own include file and not in
> > amongst all the commonly used math operations.
> >
> > --
> > Derek Parnell
> > Melbourne, Australia
> > Skype name: derek.j.parnell
>
> Could you consider that the word "commonly" means sometimes opposed things for
> different people?
>
> I suggest spinning the DOS graphic functions off to a separate include file,
> which does not need to be standard. They are specialised - much more than set
> operations -, and in 6 or 7 years I never used any of them a single time. This
> will make Euphoria simpler.
>
> CChris
This has nothing got to do with "math.e". Please try to stay on topic.
Things are chaotic enough currently anyway. There is no need to
deliberately make them even more chaotic.
Sometimes believing I'm in a kindergarten here,
Juergen
50. Re: Proposal for 'math.e' (2007-08-23)
Derek Parnell wrote:
>
> CChris wrote:
> > Could you consider that the word "commonly" means sometimes opposed things
> > for
> > different people?
>
>
> Yep.
>
>
> > I suggest spinning the DOS graphic functions off to a separate include file,
> > which does not need to be standard. They are specialised - much more than
> > set
> > operations -, and in 6 or 7 years I never used any of them a single time.
> > This
> > will make Euphoria simpler.
>
> Sounds good to me too.
>
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
and me.
51. Re: Proposal for 'math.e' (2007-08-23)
CChris wrote:
>
> I suggest spinning the DOS graphic functions off to a separate include file,
> which does not need to be standard. They are specialised - much more than set
> operations -, and in 6 or 7 years I never used any of them a single time. This
> will make Euphoria simpler.
That seems reasonable. Will it make the interpreter more streamlined?
52. Re: Proposal for 'math.e' (2007-08-23)
Juergen Luethje wrote:
>
> CChris wrote:
>
> > Derek Parnell wrote:
> > >
> > > Jules wrote:
> > > >
> > > > Derek Parnell wrote:
> > > > >
> > > > > Jules wrote:
> > > > > >
> > > > > > > Routines for sets should be in a separate include file, not in
> > > > > > > "math.e".
> > > > > > >
> > > > > > > Regards,
> > > > > > > Juergen
> > > > > >
> > > > > > I'm not going to make a big fuss about it, but why? sets are the
> > > > > > foundation
> > > > > > of all mathematical systems, underlying all functions, relations,
> > > > > > and
> logic.</font></i>
> > > > >
> > > > > That they may be, but the file will contain set OPERATIONS, and they
> > > > > are
> not</font></i>
> > > > > commonly used. In other words, just because sets are the basis of
> > > > > mathematically
> > > > > systems it doesn't follow that therefore set operations are used all
> > > > > the
> time.</font></i>
> > > >
> > > > they are, but you just don't realise it. :)
> > >
> > >
> > > Remember the context we are talking in : putting set operations inside a
> > > MATH.E
> > > file.
> > >
> > > I know sets. I use sets all the time both in programming and real life.
> > > But
> > > in the context of maths operations, I rarely if ever, use raw set
> > > operations.
> > > If they are used, it is in the background and not explicitly.
> > >
> > >
> > > > Take 'Intersection' and 'Union' for example. These are closely related
> > > > to 'and'
> > > > and 'or' respectively, but are more powerful in the sense that they
> > > > return
> the</font></i>
> > > > actual sequence elements, not just 1's and 0's.
> > >
> > > Yes that is true. But it ain't maths and it is specialized (uncommon)
> > > functionality,
> > > so therefore put these useful functions in their own include file and not
> > > in
> > > amongst all the commonly used math operations.
> > >
> > > --
> > > Derek Parnell
> > > Melbourne, Australia
> > > Skype name: derek.j.parnell
> >
> > Could you consider that the word "commonly" means sometimes opposed things
> > for
> > different people?
> >
> > I suggest spinning the DOS graphic functions off to a separate include file,
> > which does not need to be standard. They are specialised - much more than
> > set
> > operations -, and in 6 or 7 years I never used any of them a single time.
> > This
> > will make Euphoria simpler.
> >
> > CChris
>
> This has nothing got to do with "math.e". Please try to stay on topic.
> Things are chaotic enough currently anyway. There is no need to
> deliberately make them even more chaotic.
>
> Sometimes believing I'm in a kindergarten here,
> Juergen
I was just pointing out the consequences of the "if it is not commonly used, it
should not be standard" logic which I have seen now and then here.
CChris
53. Re: Proposal for 'math.e' (2007-08-23)
c.k.lester wrote:
>
> CChris wrote:
> >
> > I suggest spinning the DOS graphic functions off to a separate include file,
> > which does not need to be standard. They are specialised - much more than
> > set
> > operations -, and in 6 or 7 years I never used any of them a single time.
> > This
> > will make Euphoria simpler.
>
> That seems reasonable. Will it make the interpreter more streamlined?
At the very least, it will free some opcodes -> some entries in SymTab at parse
time. The big switch C statement that executes IL will have less many branches;
this may speed up translated code, depending on the C compiler you use. The
official Windows interpreter, compiled using Watcom, won't be affected by the
latter. Not sure on other platforms.
The docs will get leaner by a whole section too.
CChris
54. Re: Proposal for 'math.e' (2007-08-23)
- Posted by Juergen Luethje <j.lue at ?mx.d?>
Aug 24, 2007
-
Last edited Aug 25, 2007
Derek Parnell wrote:
<snip>
> > Derek wrote:
> >> There is nothing stopping the creation of a mathadv.e file to
> >> include advanced maths routines.
>
> Juergen Luethje wrote:
> > What does that mean in the given context? Are you suggesting
> > that we should create and release a "mathadv.e" standard include
> > file along with the "math.e" standard include file? Additionally
> > to a "statistics.e" file or instead of a "statistics.e" file?
>
> I suggest ...
> math.e -- Commonly used mathematical functionality.
> mathadv.e -- Not-so commonly used and advanced stuff.
> eg. Calculus, Matrix, Vector, etc...
> statistics.e -- functions just dealing with stats.
> sets.e -- Set operations.
> (Though separate files for each distinct area of advanced maths might be good
> too).
>
> I can also imagine some one creating a set of Financial maths functions, 2D
> and 3D geometrical functions, Volume functions, etc ...
>
> By having them in separate files, people can mix'n'match as required.
Yes, IMHO it's better to have separate files for each distinct area of
advanced maths.
Regards,
Juergen
55. Re: Proposal for 'math.e' (2007-08-23)
Rob wrote on 2007-08-23:
> Juergen Luethje wrote:
>
>> c.k.lester wrote:
>>
>>> Jules wrote:
>>>
>>>> do you not think Gamma and erf are too specialized and advanced for
>>>> a basic math library?...
>>>
>>> I would vote for three separate include files:
>>>
>>> math.e (basic math)
>>> statistics.e (statistics)
>>> compare.e (min/max)
>>
>> I'd vote exactly for the same.
>
> Me too.
> Unless someone disagrees strongly in the next few days,
> maybe we can at least agree to break it down into
> those three file names.
CChris wrote on 2007-08-28 in a different thread:
> [...] could be in stats.e (must obey the 8.3 pattern).
So there still seems to be no agreement on the names for these three
files.
Regards,
Juergen
56. Re: Proposal for 'math.e' (2007-08-23)
Juergen Luethje wrote:
> Robert Craig wrote:
>
> > Juergen Luethje wrote:
> > >
> > > c.k.lester wrote:
> > >
> > > > Jules wrote:
> > > >
> > > > > do you not think Gamma and erf are too specialized and advanced for
> > > > > a basic math library?...
> > > >
> > > > I would vote for three separate include files:
> > > >
> > > > math.e (basic math)
> > > > statistics.e (statistics)
> > > > compare.e (min/max)
> > >
> > > I'd vote exactly for the same.
> >
> > Me too.
> > Unless someone disagrees strongly in the next few days,
> > maybe we can at least agree to break it down into
> > those three file names.
>
> And also, unless someone disagrees strongly in the next few days,
> hopefully we can agree to stop suggesting new functions (or constants
> or whatever) for the first release of "math.e" (*). Otherwise there will
> never be a release of it.
>
> Regards,
> Juergen
>
> (*) This does of course not apply to erf() and friends, which already
> _have been_ suggested.
Hello Rob!
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".
Regards,
Juergen
57. Re: Proposal for 'math.e' (2007-08-23)
You forgot to mention the inaccuracy problem for power(E,x). There is a decision
to make on whether we keep it and allow some inexact values, or remove exp() from
math.e and make it a builtin - which I'd favor.
CChris
58. Re: Proposal for 'math.e' (2007-08-23)
CChris wrote:
> You forgot to mention the inaccuracy problem for power(E,x). There is a
> decision
> to make on whether we keep it and allow some inexact values, or remove exp()
> from math.e and make it a builtin - which I'd favor.
>
> CChris
Whom do you mean by "you"? Me? If so, which of my posts are you refering to?
Please get some information from here:
<http://www.netmeister.org/news/learn2quote.html>
In case you are referring to the message that I had posted previously today,
then I deliberately did not mention the inaccuracy problem for power(E,x).
The post was not about anything and everything concerning "math.e", so I
also did not mention some other issues regarding "math.e". The post had a
special purpose. Everyone who carefully reads that post can understand it.
HTH,
Juergen
59. Re: Proposal for 'math.e' (2007-08-23)
I'm reading late this discussion about math.e
My opinion, in the official euphoria release
must to be included basic math definitions.
Will be great to have specialized library for
advanced math and statistic, complex numbers,
matrix, etc. Is important for student, academics
engineers.
But 99% of the programs will never need this
kind of advanced maths.
If I only need to use in one program power()
or sin() function, why must I to overload the
compile time with a lot of advanced complex
maths.
My suggest is keep a very simple math.e
Including basic math of any kind, power,
root, sin, log, abs
Anyway I thing is good to have specialiced
advanced functions as:
- Advanced trigonometrics.
- Advanced statistics, ANOVA, Correlations, experimental test
- Complex numbers
- Matrix and equation systems
- Electronics
- Structures engineering
- Hidraulic engineer
But as complementary libraries and not as part of the
official release.
+-+-+-+-+-+-+-+
Marco A. Achury
Caracas, Venezuela
+58-414-3142282
60. Re: Proposal for 'math.e' (2007-08-23)
Marco Achury wrote:
> I'm reading late this discussion about math.e
>
> My opinion, in the official euphoria release
> must to be included basic math definitions.
>
> Will be great to have specialized library for
> advanced math and statistic, complex numbers,
> matrix, etc. Is important for student, academics
> engineers.
>
> But 99% of the programs will never need this
> kind of advanced maths.
>
> If I only need to use in one program power()
> or sin() function, why must I to overload the
> compile time with a lot of advanced complex
> maths.
>
> My suggest is keep a very simple math.e
> Including basic math of any kind, power,
> root, sin, log, abs
The Euphoria community currently is in the process of creating
a basic "math.e" library.
> Anyway I thing is good to have specialiced
> advanced functions as:
>
> - Advanced trigonometrics.
> - Advanced statistics, ANOVA, Correlations, experimental test
> - Complex numbers
> - Matrix and equation systems
> - Electronics
> - Structures engineering
> - Hidraulic engineer
Some of these things (e.g. statistics) are already planned.
> But as complementary libraries and not as part of the
> official release.
Do you know that there are already a lot of "complementary libraries"
on the User contributions page <http://rapideuphoria.com/contrib.htm>?
However, if an additional library, say "statistics.e" will be shipped
with the official realease, that will not hurt anyone who doesn't use it.
But it might attract new users to the language.
Regards,
Juergen
61. Re: Proposal for 'math.e' (2007-08-23)
Marco Achury wrote:
>
>
> I'm reading late this discussion about math.e
>
> My opinion, in the official euphoria release
> must to be included basic math definitions.
>
> Will be great to have specialized library for
> advanced math and statistic, complex numbers,
> matrix, etc. Is important for student, academics
> engineers.
To that end, i ask for SSE2 extensions in Euphoria, for *user* integers.
I am not asking for Euphoria to have internal pointers over 32bits,
and
i am not asking for 32bit+ floating point. Only that, for instance,
in a sequence of integers the existing 32bit pointers point to 48 or
64bit integers. I understand existing code relies on 32bit integers.
Using a top level "with SSE2" may provide all the integer math/logic
required without changing existing Eu assy code. I understand if "with SSE2"
is used, assignment to a existing Eu 32bit atom may fail if the value
of the 48_/64_bit integer value is too large. I am not asking that existing
atoms (or their automatic integer - floatingpoint behavior) be changed.
I am not asking that Euphoria try to access memory beyond what the OS
(windoze) can allocate per application. I would suggest that the existing
Euphoria bit operations access these larger integers.
I am thinking this is merely a matter of using a compiler that understands
SSE2 instructions? See:
http://www.google.com/search?hl=en&q=SSE2+math
And i don't care if this is in math.e or hidden internal to the backend,
or whatever,
only that i can say:
integer x
x = 1099511627776
(just thinking of terabyte harddrive arrays
at this particular moment
as i am writing this)
and
poke(somewhere,x)
and
if x > blah then
And maybe, i seriously don't know
<genuflecting to the C and assy coding geniuses>,
SSE2 has all this covered already
if you hand
it Euphoria's existing and unchanged 32bit pointers
to the proposed new 48/64bit integers?
<peeve>
And btw, why is the web interface set to:
<textarea wrap=off
? At least with the olde email interface, i could set viewing
and
editing
preferences
myself.
Word
wrap
is
a
basic, good grief,
i had wordwrap on Commodore C64 in a windowing system over 10 years ago,
and i realise some here will tell me to use a C64 from now on to access
this forum rather than set
<textarea wrap=on
in the html for the postback page. Remembering this is such an adversarial
forum to me because i believe in goto, i am putting on my asbestos now,
and eating antacids for lunch. Flame away.
</peeve>
Kat,
still with the goto and string execution.
62. Re: Proposal for 'math.e' (2007-08-23)
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).
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
63. Re: Proposal for 'math.e' (2007-08-23)
Marco Achury wrote:
>
>
> I'm reading late this discussion about math.e
>
> My opinion, in the official euphoria release
> must to be included basic math definitions.
>
> Will be great to have specialized library for
> advanced math and statistic, complex numbers,
> matrix, etc. Is important for student, academics
> engineers.
>
> But 99% of the programs will never need this
> kind of advanced maths.
>
Are you sure?
What are you calling "advanced maths" precisely?
> If I only need to use in one program power()
> or sin() function, why must I to overload the
> compile time with a lot of advanced complex
> maths.
>
> My suggest is keep a very simple math.e
> Including basic math of any kind, power,
> root, sin, log, abs
power(), sin(), log(), sqrt() are all builtins, so they are in no include file
at all.
>
> Anyway I thing is good to have specialiced
> advanced functions as:
>
> - Advanced trigonometrics.
> - Advanced statistics, ANOVA, Correlations, experimental test
> - Complex numbers
> - Matrix and equation systems
> - Electronics
> - Structures engineering
> - Hidraulic engineer
>
> But as complementary libraries and not as part of the
> official release.
The point is: what is advanced and what is basic? You should tell us and we may
have to agree.
CChris
>
> +-+-+-+-+-+-+-+
> Marco A. Achury
> Caracas, Venezuela
> +58-414-3142282
64. Re: Proposal for 'math.e' (2007-08-23)
Hey, nice to see you back around!
Indeed, accessing 64/128 bit integer would require some builtin support, and I
have no idea whether all supported C compilers support it. For accessing large
integers, I use word64.e at http://oedoc.free.fr/Fichiers/ESL/
As for string execution, did you look at Matt's OOEu variant?
Regarding word wrap: when RDS at last implements a digest email service, I'll
switch to it fast. They would balk at receiving 50-80 individual emails a day.
CChris
65. Re: Proposal for 'math.e' (2007-08-23)
- Posted by Juergen Luethje <j.lue at g?x.?e>
Aug 29, 2007
-
Last edited Aug 30, 2007
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". )
Regards,
Juergen
66. Re: Proposal for 'math.e' (2007-08-23)
- Posted by Robert Craig <rds at RapidEupho?ia?com>
Aug 29, 2007
-
Last edited Aug 30, 2007
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". )
Yes. I don't recall any serious objections to any of that.
I'd say we have official agreement.
Please go ahead.
There will be time to make some code-breaking changes,
as long as it's before a lot of people start
using it.
If you'd like SourceForge access, get a
SourceForge userid and let me know.
Otherwise you'll need myself or another
developer to get involved whenever you want
to officially change something.
TortoiseSVN for Windows is really quite easy
to learn and use. It works fine for me on XP and Vista.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
67. Re: Proposal for 'math.e' (2007-08-23)
- Posted by Kat <KAT12 at coos?h?.net>
Aug 29, 2007
-
Last edited Aug 30, 2007
CChris wrote:
>
>
> Hey, nice to see you back around!
Thanks!
> Indeed, accessing 64/128 bit integer would require some builtin support, and I
> have no idea
> whether all supported C compilers support it. For accessing large integers, I
> use word64.e at
> <a
> href="http://oedoc.free.fr/Fichiers/ESL/">http://oedoc.free.fr/Fichiers/ESL/</a>
Nice! and you cleverly disguised a poke64() as a conversion
to a memory location in word_to_int64(). 
Question: line 947 in word64.e says:
-- Description: Stores 8 bits at address from input word.
Did you mean 8*bytes* ?
I like function sprint_word(word w), that's also going to be quite
handy during testing. Have you tested this library to death for
accuracy? It looks like it will be really handy when i can sit
back down at the computer for productive work.
> As for string execution, did you look at Matt's OOEu variant?
Yes, i did, and i like OOEU a lot. OOEU's oop-ish if you like,
but it isn't if you don't want. I like that implementation of classes a lot.
But.. it can be *extremely* slow at some things. I suspect converting
it to the newer Eu versions would speed it up, since most of the lag
seems to be in memory allocation when dealing with dozens of megabytes
of data coming in.
I hope all of OOEU appears in some form in openeu, with appropriate
credits to Matt.
Kat
68. Re: Proposal for 'math.e' (2007-08-23)
- Posted by CChris <christian.cuvier at agricult?re?gouv.fr>
Aug 29, 2007
-
Last edited Aug 30, 2007
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
69. Re: Proposal for 'math.e' (2007-08-23)
- Posted by CChris <christian.cuvier at ag?iculture.gou?.fr>
Aug 29, 2007
-
Last edited Aug 30, 2007
Kat wrote:
>
> CChris wrote:
> >
> >
> > Hey, nice to see you back around!
>
> Thanks!
>
> > Indeed, accessing 64/128 bit integer would require some builtin support, and
> I have no idea</font></i>
> > whether all supported C compilers support it. For accessing large integers,
> I use word64.e at</font></i>
> > <a
> > href="http://oedoc.free.fr/Fichiers/ESL/">http://oedoc.free.fr/Fichiers/ESL/</a>
>
> Nice! and you cleverly disguised a poke64() as a conversion
> to a memory location in word_to_int64().
>
> Question: line 947 in word64.e says:
> -- Description: Stores 8 bits at address from input word.
> Did you mean 8*bytes* ?
>
Yep, lol
> I like function sprint_word(word w), that's also going to be quite
> handy during testing. Have you tested this library to death for
> accuracy? It looks like it will be really handy when i can sit
> back down at the computer for productive work.
>
I don't have tested it a lot further than what is in the test file. And I
havedn't looked at the code for 18-24 months. As you can see, it was to be
possibly included in the ESL, with some minimalist ayatollahs being against.
ESL doesn't have any activity, so the files in that directory were left in
limbo. I advertise for one or another from time to time, when there's an
opportunity.
So it was tested, but I wouldn't swear it is 100% bug free, just 97%.
> > As for string execution, did you look at Matt's OOEu variant?
>
> Yes, i did, and i like OOEU a lot. OOEU's oop-ish if you like,
> but it isn't if you don't want. I like that implementation of classes a lot.
>
As an Eiffel programmer, OOP is not a problem for me
> But.. it can be *extremely* slow at some things. I suspect converting
> it to the newer Eu versions would speed it up, since most of the lag
> seems to be in memory allocation when dealing with dozens of megabytes
> of data coming in.
>
This one is tough. One supposedly easy answer would be "let's have a native
array of bytes/words/doublewords type", so as to avoid the costly conversion. But
the type system of Eu is highly optimised, and a complete, detailed examination
would be needed to see if this addition is possible while keeping performance at
its current level. When I suggested that, I got some jeers and sneers, so smart,
so I haven't looked much further into the matter.
> I hope all of OOEU appears in some form in openeu, with appropriate
> credits to Matt.
>
Me too, but... I am not optimistic.
CChris
> Kat
70. Re: Proposal for 'math.e' (2007-08-23)
- Posted by Juergen Luethje <j.lue at g?x?de>
Aug 29, 2007
-
Last edited Aug 30, 2007
CChris wrote:
> 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.
The function polynom() is already contained in your file
<http://www.rapideuphoria.com/uploads/gamma_erf.e>, so it's not a new function.
> 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,
I'm so sorry that my posts do not always come up to your expectations.
This is probably because I decide myself what I'm going to write in what
context.
> 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.
I'm not playing any game here. Get your facts first, and then you can
distort them as you please.
In contrast to you, I don't want to discuss for the next 2 years about
each and every dot and comma in "math.e", without ever actually
realeasing it. I want that we somewhat earlier come to a RESULT.
Because I saw people making repeatedly new suggestions for routines that
they would like to see in "math.e", I realized that we'd never come to a
RESULT that way. So my proposal was to stop suggesting new routines for
the first release of "math.e". This should not be too hard to understand.
(And I have written about that point in the past at least twice or
threefold, BTW.)
This was a _proposal_, the "official decision" was made by Rob.
I also wonder why you didn't object during the last days. But now --
a few hours _after_ Rob has made the official decision -- you are
objecting. What a strange gane is it that you are playing?
Not actually surprised,
Juergen
71. Re: Proposal for 'math.e' (2007-08-23)
Juergen Luethje wrote:
>
> CChris wrote:
>
> > 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.
>
> The function polynom() is already contained in your file
> <<a
> href="http://www.rapideuphoria.com/uploads/gamma_erf.e">http://www.rapideuphoria.com/uploads/gamma_erf.e</a>>,
> so it's not a new function.
>
> > 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,
>
> I'm so sorry that my posts do not always come up to your expectations.
> This is probably because I decide myself what I'm going to write in what
> context.
Don't we all do that?
I suspect something may have got lost in translation, but I cannot figure out
what, sorry.
>
> > 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.
>
> I'm not playing any game here. Get your facts first, and then you can
> distort them as you please.
> In contrast to you, I don't want to discuss for the next 2 years about
> each and every dot and comma in "math.e", without ever actually
> realeasing it. I want that we somewhat earlier come to a RESULT.
Which means forcing hasty decisions without considering implementation isssues
and without even gaving the votes you have requested so many times in the past.
Again, I don't buy that.
> Because I saw people making repeatedly new suggestions for routines that
> they would like to see in "math.e", I realized that we'd never come to a
> RESULT that way. So my proposal was to stop suggesting new routines for
> the first release of "math.e". This should not be too hard to understand.
> (And I have written about that point in the past at least twice or
> threefold, BTW.)
Early, with possible flaws or inconsistencies that were not studied, which are
harder to fix once the release is out, because code written thereafter might be
broken.
> This was a _proposal_, the "official decision" was made by Rob.
> I also wonder why you didn't object during the last days.
I did, and you carefully ommitted to acknowledge it.
Additionally, I had time to port the C code and test it last weekend only, so I
could not be aware of some issues before that point. I reported them as soon as I
could.. Get your facts first.
> But now --
> a few hours _after_ Rob has made the official decision -- you are
> objecting. What a strange gane is it that you are playing?
>
> Not actually surprised,
> Juergen
CChris
72. Re: Proposal for 'math.e' (2007-08-23)
CChris wrote:
<snip>
>> In contrast to you, I don't want to discuss for the next 2 years about
>> each and every dot and comma in "math.e", without ever actually
>> realeasing it. I want that we somewhat earlier come to a RESULT.
>
> Which means forcing hasty decisions without considering implementation isssues
No, it doesn't mean that at all.
> and without even gaving the votes you have requested so many times in the
> past.
I don't know what you are talking about. I just proposed to stop
suggesting new global routines and constants for the first version of
"math.e". That's all.
> Again, I don't buy that.
I'm not trying to sell anything to you.
It would help if you were able to stop confusing fantasy with reality,
though.
> > Because I saw people making repeatedly new suggestions for routines that
> > they would like to see in "math.e", I realized that we'd never come to a
> > RESULT that way. So my proposal was to stop suggesting new routines for
> > the first release of "math.e". This should not be too hard to understand.
> > (And I have written about that point in the past at least twice or
> > threefold, BTW.)
>
> Early, with possible flaws or inconsistencies that were not studied, which are
> harder to fix once the release is out, because code written thereafter might
> be broken.
I just proposed to stop suggesting new routines and constants for the
first version of "math.e". That's all.
> > This was a _proposal_, the "official decision" was made by Rob.
> > I also wonder why you didn't object during the last days.
>
> I did, and you carefully ommitted to acknowledge it.
Rob wrote yesterday:
<quote>
I don't recall any serious objections to any of that.
</quote>
Do you believe he also "carefully ommitted to acknowledge" your
objection? Maybe an international conspiracy?
==>> So where is your post that contains the objection??? <<==
> Additionally, I had time to port the C code and test it last weekend only, so
> I could not be aware of some issues before that point. I reported them as soon
> as I could.. Get your facts first.
You are confusing facts with stupid misrepresentations such as
"you carefully ommitted to acknowledge it".
> > But now --
> > a few hours _after_ Rob has made the official decision -- you are
> > objecting. What a strange gane is it that you are playing?
> >
> > Not actually surprised,
> > Juergen
>
> CChris
Regards,
Juergen
73. Re: Proposal for 'math.e' (2007-08-23)
Juergen Luethje wrote:
>
> CChris wrote:
>
> <snip>
>
> >> In contrast to you, I don't want to discuss for the next 2 years about
> >> each and every dot and comma in "math.e", without ever actually
> >> realeasing it. I want that we somewhat earlier come to a RESULT.
> >
> > Which means forcing hasty decisions without considering implementation
> > isssues
>
> No, it doesn't mean that at all.
>
Ok, but your posts sound exactly like that.
> > and without even gaving the votes you have requested so many times in the
> > past.
>
> I don't know what you are talking about. I just proposed to stop
> suggesting new global routines and constants for the first version of
> "math.e". That's all.
>
Then you should say "stop adding any new feature which is not implied, or
required, by the known contents of the file". Your intent was certainly stated
imprecisely.
> > Again, I don't buy that.
>
> I'm not trying to sell anything to you.
> It would help if you were able to stop confusing fantasy with reality,
> though.
There is no fantasy here, simply a disagreement on the methods you are using and
a strong belief that they are harmful.
>
> > > Because I saw people making repeatedly new suggestions for routines that
> > > they would like to see in "math.e", I realized that we'd never come to a
> > > RESULT that way. So my proposal was to stop suggesting new routines for
> > > the first release of "math.e". This should not be too hard to understand.
> > > (And I have written about that point in the past at least twice or
> > > threefold, BTW.)
> >
> > Early, with possible flaws or inconsistencies that were not studied, which
> > are
> > harder to fix once the release is out, because code written thereafter
> > might
> > be broken.
>
> I just proposed to stop suggesting new routines and constants for the
> first version of "math.e". That's all.
>
> > > This was a _proposal_, the "official decision" was made by Rob.
> > > I also wonder why you didn't object during the last days.
> >
> > I did, and you carefully ommitted to acknowledge it.
>
> Rob wrote yesterday:
> <quote>
> I don't recall any serious objections to any of that.
> </quote>
>
> Do you believe he also "carefully ommitted to acknowledge" your
> objection? Maybe an international conspiracy?
> ==>> So where is your post that contains the objection??? <<==
>
Ot was posted on monday (implementation of exp()) and saturday (possible
inclusion of polynom()).
> > Additionally, I had time to port the C code and test it last weekend only,
> > so
> > I could not be aware of some issues before that point. I reported them as
> > soon
> > as I could.. Get your facts first.
>
> You are confusing facts with stupid misrepresentations such as
> "you carefully ommitted to acknowledge it".
>
If you were so "clean" about ythe way you proceed, you wouldn't need to be rude
towards dissenters. You have done so repeatedly in the past, I'm going to be less
lenient on that in the future. You have been warned.
If there is any misrepresentation, it comes from you bullyish way to push
things. There is no timetable for 3.2, nor is there any for regular candidate
releases (could be a good idea if we could state something like that - fork to
other thread -). So I am quite suspicious about why this rush of yours.
> > > But now --
> > > a few hours _after_ Rob has made the official decision -- you are
> > > objecting. What a strange gane is it that you are playing?
> > >
> > > Not actually surprised,
> > > Juergen
> >
> > CChris
>
> Regards,
> Juergen
CChris
74. Re: Proposal for 'math.e' (2007-08-23)
CChris wrote:
> Juergen Luethje wrote:
> >
> > CChris wrote:
> >
> > <snip>
> >
> > >> In contrast to you, I don't want to discuss for the next 2 years about
> > >> each and every dot and comma in "math.e", without ever actually
> > >> realeasing it. I want that we somewhat earlier come to a RESULT.
> > >
> > > Which means forcing hasty decisions without considering implementation
> > > isssues
> >
> > No, it doesn't mean that at all.
> >
>
> Ok, but your posts sound exactly like that.
Maybe they sound like that _to you_. That's not my cup of tea.
> > > and without even gaving the votes you have requested so many times in the
> > > past.
> >
> > I don't know what you are talking about. I just proposed to stop
> > suggesting new global routines and constants for the first version of
> > "math.e". That's all.
> >
>
> Then you should say "stop adding any new feature which is not implied, or
> required,
> by the known contents of the file". Your intent was certainly stated
> imprecisely.
False.
BTW, since you did understand my intention now, I wonder why you didn't
understand
it before, since I wrote almost the same stuff again and again.
> > > Again, I don't buy that.
> >
> > I'm not trying to sell anything to you.
> > It would help if you were able to stop confusing fantasy with reality,
> > though.
>
> There is no fantasy here, simply a disagreement on the methods you are using
> and a strong belief that they are harmful.
>
> >
> > > > Because I saw people making repeatedly new suggestions for routines that
> > > > they would like to see in "math.e", I realized that we'd never come to a
> > > > RESULT that way. So my proposal was to stop suggesting new routines for
> > > > the first release of "math.e". This should not be too hard to
> > > > understand.
> > > > (And I have written about that point in the past at least twice or
> > > > threefold, BTW.)
> > >
> > > Early, with possible flaws or inconsistencies that were not studied, which
> > > are
> > > harder to fix once the release is out, because code written thereafter
> > > might
> > > be broken.
> >
> > I just proposed to stop suggesting new routines and constants for the
> > first version of "math.e". That's all.
> >
> > > > This was a _proposal_, the "official decision" was made by Rob.
> > > > I also wonder why you didn't object during the last days.
> > >
> > > I did, and you carefully ommitted to acknowledge it.
> >
> > Rob wrote yesterday:
> > <quote>
> > I don't recall any serious objections to any of that.
> > </quote>
> >
> > Do you believe he also "carefully ommitted to acknowledge" your
> > objection? Maybe an international conspiracy?
> > ==>> So where is your post that contains the objection??? <<==
> >
>
> Ot was posted on monday (implementation of exp()) and saturday (possible
> inclusion
> of polynom()).
Of course I need a _link_ to each posting that contains an objection to my
proposal, before Rob made the official decision. Without precise links,
there is good potential for new misunderstandings. We already have enough of
them.
>
> > > Additionally, I had time to port the C code and test it last weekend only,
> > > so
> > > I could not be aware of some issues before that point. I reported them as
> > > soon
> > > as I could.. Get your facts first.
> >
> > You are confusing facts with stupid misrepresentations such as
> > "you carefully ommitted to acknowledge it".
> >
>
> If you were so "clean" about ythe way you proceed, you wouldn't need to be
> rude
> towards dissenters.
When someone posts a stupid misrepresentation, he probably shouldn't be
surprised when he gets a rude reply.
> You have done so repeatedly in the past, I'm going to be
> less lenient on that in the future. You have been warned.
You are mixing up cause and effect.
> If there is any misrepresentation, it comes from you bullyish way to push
> things.
Making a suggestion is a "bullyish way to push things" in your opinion?
Interesting.
> There is no timetable for 3.2, nor is there any for regular candidate releases
> (could be a good idea if we could state something like that - fork to other
> thread -). So I am quite suspicious about why this rush of yours.
>
> > > > But now --
> > > > a few hours _after_ Rob has made the official decision -- you are
> > > > objecting. What a strange gane is it that you are playing?
> > > >
> > > > Not actually surprised,
> > > > Juergen
> > >
> > > CChris
> >
> > Regards,
> > Juergen
>
> CChris
Regards,
Juergen
75. Re: Proposal for 'math.e' (2007-08-23)
Juergen Luethje wrote:
>
> CChris wrote:
>
> > Juergen Luethje wrote:
> > >
> > > CChris wrote:
> > >
> > > <snip>
> > >
> > > >> In contrast to you, I don't want to discuss for the next 2 years about
> > > >> each and every dot and comma in "math.e", without ever actually
> > > >> realeasing it. I want that we somewhat earlier come to a RESULT.
> > > >
> > > > Which means forcing hasty decisions without considering implementation
> > > > isssues
> > >
> > > No, it doesn't mean that at all.
> > >
> >
> > Ok, but your posts sound exactly like that.
>
> Maybe they sound like that _to you_. That's not my cup of tea.
>
> > > > and without even gaving the votes you have requested so many times in
> > > > the past.
> > >
> > > I don't know what you are talking about. I just proposed to stop
> > > suggesting new global routines and constants for the first version of
> > > "math.e". That's all.
> > >
> >
> > Then you should say "stop adding any new feature which is not implied, or
> > required,
> > by the known contents of the file". Your intent was certainly stated
> > imprecisely.
>
> False.
> BTW, since you did understand my intention now, I wonder why you didn't
> understand
> it before, since I wrote almost the same stuff again and again.
>
All is in the "almost". Like your implementation of exp(), this was inaccurate.
> > > > Again, I don't buy that.
> > >
> > > I'm not trying to sell anything to you.
> > > It would help if you were able to stop confusing fantasy with reality,
> > > though.
> >
> > There is no fantasy here, simply a disagreement on the methods you are using
> > and a strong belief that they are harmful.
> >
> > >
> > > > > Because I saw people making repeatedly new suggestions for routines
> > > > > that
> > > > > they would like to see in "math.e", I realized that we'd never come to
> > > > > a
> > > > > RESULT that way. So my proposal was to stop suggesting new routines
> > > > > for
> > > > > the first release of "math.e". This should not be too hard to
> > > > > understand.
> > > > > (And I have written about that point in the past at least twice or
> > > > > threefold, BTW.)
> > > >
> > > > Early, with possible flaws or inconsistencies that were not studied,
> > > > which
> are</font></i>
> > > > harder to fix once the release is out, because code written thereafter
> > > > might
> > > > be broken.
> > >
> > > I just proposed to stop suggesting new routines and constants for the
> > > first version of "math.e". That's all.
> > >
> > > > > This was a _proposal_, the "official decision" was made by Rob.
> > > > > I also wonder why you didn't object during the last days.
> > > >
> > > > I did, and you carefully ommitted to acknowledge it.
> > >
> > > Rob wrote yesterday:
> > > <quote>
> > > I don't recall any serious objections to any of that.
> > > </quote>
> > >
> > > Do you believe he also "carefully ommitted to acknowledge" your
> > > objection? Maybe an international conspiracy?
> > > ==>> So where is your post that contains the objection??? <<==
> > >
> >
> > Ot was posted on monday (implementation of exp()) and saturday (possible
> > inclusion
> > of polynom()).
>
> Of course I need a _link_ to each posting that contains an objection to my
> proposal, before Rob made the official decision. Without precise links,
> there is good potential for new misunderstandings. We already have enough of
> them.
>
http://wwww.rapideuphoria.org/EUforum/m16293.htm
http://wwww.rapideuphoria.org/EUforum/m16309.htm
> >
> > > > Additionally, I had time to port the C code and test it last weekend
> > > > only, so
> > > > I could not be aware of some issues before that point. I reported them
> > > > as soon
> > > > as I could.. Get your facts first.
> > >
> > > You are confusing facts with stupid misrepresentations such as
> > > "you carefully ommitted to acknowledge it".
> > >
> >
> > If you were so "clean" about ythe way you proceed, you wouldn't need to be
> > rude
> > towards dissenters.
>
> When someone posts a stupid misrepresentation, he probably shouldn't be
> surprised when he gets a rude reply.
>
> > You have done so repeatedly in the past, I'm going to be
> > less lenient on that in the future. You have been warned.
>
> You are mixing up cause and effect.
>
The cause are _your_ posts and the language you use. No mixup there.
> > If there is any misrepresentation, it comes from you bullyish way to push
> > things.
>
> Making a suggestion is a "bullyish way to push things" in your opinion?
> Interesting.
>
It all depends on its wording.
> > There is no timetable for 3.2, nor is there any for regular candidate
> > releases
> > (could be a good idea if we could state something like that - fork to other
> > thread -). So I am quite suspicious about why this rush of yours.
> >
> > > > > But now --
> > > > > a few hours _after_ Rob has made the official decision -- you are
> > > > > objecting. What a strange gane is it that you are playing?
> > > > >
> > > > > Not actually surprised,
> > > > > Juergen
> > > >
> > > > CChris
> > >
> > > Regards,
> > > Juergen
> >
> > CChris
>
> Regards,
> Juergen
CChris
76. Re: Proposal for 'math.e' (2007-08-23)
- Posted by Juergen Luethje <j.lue at g?x?de>
Aug 30, 2007
-
Last edited Aug 31, 2007
CChris wrote:
> Juergen Luethje wrote:
>
>> CChris wrote:
>>
>>> Juergen Luethje wrote:
<snip>
>>>> ==>> So where is your post that contains the objection??? <<==
>>>>
>>>
>>> Ot was posted on monday (implementation of exp()) and saturday (possible
>>> inclusion
>>> of polynom()).
>>
>> Of course I need a _link_ to each posting that contains an objection to my
>> proposal, before Rob made the official decision. Without precise links,
>> there is good potential for new misunderstandings. We already have enough of
>> them.
>
> http://wwww.rapideuphoria.org/EUforum/m16293.htm
> http://wwww.rapideuphoria.org/EUforum/m16309.htm
"Error: Server not found" for both links.
<snip>
Regards,
Juergen
