1. Re: EUPHORIA Digest - 11 Jun 1998 to 12 Jun 1998 (#1998-26)
At 12:00 AM 6/13/98 -0400, Automatic digest processor wrote:
>Date: Fri, 12 Jun 1998 01:59:45 -0700
>From: Mathew Hounsell <mat.hounsell at MAILEXCITE.COM>
>Subject: RESP: Temprature, Logs and Mouse
>
>Thanks Andy Kurnia I would never have gotten those bugs. And the small
You're welcome.
>This is a mathematical error. The log function in euphoria will tell you what
> power e (2.57) has to be raised to to make the number passed to it.
e is not 2.57 (it's 2.718, see below).
>[ Mouse Help ]
I have read somewhere, though I haven't experimented, that mouse drivers
are implemented to always map the mouse coordinates to an imaginary screen
that is at least 640 pixels wide and at least 200 pixels high. So, assuming
{x,y} are zero-based:
- in a 80x25 screen (usually text), {x,y} * 8 is returned
- in a 40x25 screen (usually text), {x,y} * {16,8} is returned
- in a 320x200 screen, {x,y} * {2,1} is returned
- in a 640x200 screen, {x,y} is returned
- in a 640x350 screen, {x,y} is returned (remember the words "at least"?)
- in a 640x480 screen, {x,y} is returned
- etc.
I haven't tried them...
>Date: Fri, 12 Jun 1998 22:49:28 +1000
>From: "Graeme." <hmi at POWERUP.COM.AU>
>Subject: Re: RESPCODE : Bload
>
>> c = fn
>> while c != -1 do
>> c = getc(fn)
>> r = r&c
>> end while
>
>for the open fail case. The only
>problem with it is that it adds and
>extra byte to the file every time
>you load it.
Nice idea, but buggy. Perhaps we should use the old-style code:
if fn != -1 then
c = getc(fn)
while c != -1 do
r = r & c
c = getc(fn)
end while
end if
>Date: Fri, 12 Jun 1998 22:55:05 GMT
>From: Jeff Zeitlin <jeff.zeitlin at MAIL.EXECNET.COM>
>Subject: <No subject given>
>
>global function exp(x)
> return power(n,x/log(n))
>end function
Nice try, but it should be
global function exp(atom x)
^^^^
(integer x would have worked as well).
An unoptimized experiment:
-- exp.ex begins
atom n
function exp(atom x)
return power(n, x / log(n))
end function
for i = 0.5 to 10 by 0.5 do
if i != 1 then
n = i
printf(1, "n = %4.1f, e = %.15f\n", {n, exp(1)})
end if
end for
-- exp.ex ends
yields this result:
>ex exp
n = 0.5, e = 2.718281828459045
n = 1.5, e = 2.718281828459045
n = 2.0, e = 2.718281828459045
n = 2.5, e = 2.718281828459045
n = 3.0, e = 2.718281828459045
n = 3.5, e = 2.718281828459045
n = 4.0, e = 2.718281828459045
n = 4.5, e = 2.718281828459045
n = 5.0, e = 2.718281828459045
n = 5.5, e = 2.718281828459045
n = 6.0, e = 2.718281828459045
n = 6.5, e = 2.718281828459045
n = 7.0, e = 2.718281828459045
n = 7.5, e = 2.718281828459045
n = 8.0, e = 2.718281828459045
n = 8.5, e = 2.718281828459045
n = 9.0, e = 2.718281828459045
n = 9.5, e = 2.718281828459045
n = 10.0, e = 2.718281828459045
i.e. the e remains the same for every n 
Another way to calculate e, without using log, is to calculate
e = power(1 + 1 / k, k) -- or e = power((k + 1) / k, k)
with k being (an integer?) as large as possible. For example,
(5001/5000)^5000 = 2.718010050102
(10001/10000)^10000 = 2.718145926825
(50001/50000)^50000 = 2.718254646127
(123457/123456)^123456 = 2.718270819444
(654322/654321)^654321 = 2.718279751283
(123456790/123456789)^123456789 = 2.718281794077
The following are against the limit theorem, or else Microsoft's calc.exe
has a bug:
(987654322/987654321)^987654321 = 2.718282052029
(9876543211/9876543210)^9876543210 = 2.718279072627
(1000000000000/999999999999)^999999999999 = 2.718523496035
