1. Uninitialized Variables
I have thought of a way that we can determine if a variable is
uninitialized or not. We can also set it back to being uninitialized.
constant INF = (1e300*1e300),
integer i i = -INF
atom a a = -INF
sequence s s = INF
object o o = INF
I tried to use NAN as well, but everything is equal to NAN!?
NAN=1
NAN=-NAN
NAN=INF
NAN=-5039487
Is that proper behaviour?
Chris
2. Re: Uninitialized Variables
----- Original Message -----
From: "Chris Bensler" <bensler at mail.com>
To: "EUforum" <EUforum at topica.com>
Subject: RE: Uninitialized Variables
>
> Sorry Bernie you misunderstood. This is a way AROUND that limitation.
> The best that I can think of.
>
> The circumstances are fairly limited to when it would be useful to know
> if a variable has been initialized yet. In those cases, I'm suggesting
> that you could just initialize it to -INF for atoms and integers, and
> INF for sequences and objects. Yes, there are cases where this wouldn't
> work, but they would be extremely rare.
>
> Your program would then consider variables that contain -INF or INF are
> uninitialized.
>
> I know it's not the optimal solution but it's better than none.
>
> It would be next to optimal if NAN had a unique value. Then we could
> have a unique identifier for each uninitialized variable. I don't know
> the nature of NAN though, so I assume it's supposed to be equal to
> everything.
>
A nice try. But it has at least three remaining problems:
a) It is a manual effort. So if you forget to do it, something will fail
somewhere.
b) It can't be relied on for use inside 3rd-party library files. IOW, if I
write a library routine that includes a function written like:
global function xx(sequence s)
-- check for uninitialized parameter.
if equal(s,INF) then
s = ""
end if
. . .
end function
and this library is included by somebody in their program, I cannot rely on
them using the INF convention. And likewise, if I use a somebody else's
library function, I can't rely on them testing for uninitialized values in
this manner.
c) Unfortunatly, INF is a valid value in its own right, and can be used in
situations other than checking for uninitialized variables.
The problem really needs to be addressed inside the core Eu interpreter. It
knows if a variable is truely initialized or not. The changes are simple.
- Allow uninitialized variables to be passed as parameters.
- Create a built-in way of testing a variable's initialization state.
and possibly
- Create a built-in way of setting a variable's state back to
uninitialized.
This will not break any existing code, and will enable people to write more
robust code.
------------
Derek.
3. Re: Uninitialized Variables
On 23 Mar 2002, at 20:12, Chris Bensler wrote:
>
> I have thought of a way that we can determine if a variable is
> uninitialized or not. We can also set it back to being uninitialized.
What about, you include(init.e) at the top of the main program file, and after
the declaring the vars, you do init(thisfilename), and init.e reads the source
code for thisfilename (and all includes after include(init.e)) and inits all the
vars? No, i didn't try it, busy atm.
Kat
4. Re: Uninitialized Variables
----- Original Message -----
From: "Andy Serpa" <renegade at earthling.net>
To: "EUforum" <EUforum at topica.com>
Subject: RE: Uninitialized Variables
>
>
> > Apparently NAN is (silly me) Not A Number! :P
> > using equal() compares NAN properly and consistently
> >
> > Here is my revised uninitialized values for variables:
> >
> > integer = -INF
> > atom = INF
> > sequence = NAN
> > object = -NAN
> >
>
> So how do I test if something is a nan? The "official" way is to use
> x!=x, but that is usually optimized away by most compilers (& Euphoria,
> apparently.) Using something like if x=1 and x=2 will work in the
> interpreter, but not translated to C, even with Watcom. (In fact, it is
> different depending on the compiler).
>
> Am I stuck with "if x and compare(x/x,1)"?
>
> For my genetic programming system this is a very real problem, as it
> comes up with random mathmatical expressions that sometimes are nan's.
> If you then take a predicted value (which is a nan) as output for a
> function that it has created and compare it with a target value, it will
> show as being equal (& therefore error = 0). So functions with nan's as
> output get the highest fitness, which is a disaster...
>
This seems to work:
--------------
atom x,nan,inf
inf = 1e300 * 1e300
nan = inf / inf
x = nan
if x = nan then
puts(1, "x is not a number\n")
end if
? x = nan
? x != nan
? nan
? inf
------------
5. Re: Uninitialized Variables
> >
> > This seems to work:
> > --------------
> > atom x,nan,inf
> > inf = 1e300 * 1e300
> > nan = inf / inf
> >
> > x = nan
> >
> > if x = nan then
> > puts(1, "x is not a number\n")
> > end if
> > ? x = nan
> > ? x != nan
> >
>
> Actually, it doesn't. Because
>
> (10 = nan)
> (2.3 = nan)
>
> will also evaluate as true and
>
> (10 != nan)
>
> will evaluate as false.
>
> You need to be able to tell a non-nan from a nan...
>
Umm, did you actually try it, Andy. Here is an expanded version:
------------------
atom x,y,nan,inf
inf = 1e300 * 1e300
nan = inf / inf
x = nan
y = 10
if x = nan then
puts(1, "x is not a number\n")
else
puts(1, "x is a number\n")
end if
if y = nan then
puts(1, "y is not a number\n")
else
puts(1, "y is a number\n")
end if
? x = nan
? x != nan
? y = nan
? y != nan
? 10 = nan
? 10 != nan
? nan
? inf
------------------
I get the following output:
x is not a number
y is a number
1
0
0
1
0
1
-nan
inf
-------------
which seems just what I'd expect.
----------
Derek.
6. Re: Uninitialized Variables
- Posted by rforno at tutopia.com
Mar 23, 2002
Well, integers and sequences cannot be assigned inf.
I am interested in what expression can be used to get a nan.
Regards.
----- Original Message -----
From: "Chris Bensler" <bensler at mail.com>
To: "EUforum" <EUforum at topica.com>
Subject: Uninitialized Variables
>
> I have thought of a way that we can determine if a variable is
> uninitialized or not. We can also set it back to being uninitialized.
>
> constant INF = (1e300*1e300),
>
> integer i i = -INF
> atom a a = -INF
> sequence s s = INF
> object o o = INF
>
> I tried to use NAN as well, but everything is equal to NAN!?
> NAN=1
> NAN=-NAN
> NAN=INF
> NAN=-5039487
>
> Is that proper behaviour?
>
> Chris
>
>
>
>
7. Re: Uninitialized Variables
- Posted by rforno at tutopia.com
Mar 23, 2002
I completely agree.
----- Original Message -----
From: "Derek Parnell" <ddparnell at bigpond.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Uninitialized Variables
>
> ----- Original Message -----
> From: "Chris Bensler" <bensler at mail.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Sunday, March 24, 2002 8:00 AM
> Subject: RE: Uninitialized Variables
>
>
> > Sorry Bernie you misunderstood. This is a way AROUND that limitation.
> > The best that I can think of.
> >
> > The circumstances are fairly limited to when it would be useful to know
> > if a variable has been initialized yet. In those cases, I'm suggesting
> > that you could just initialize it to -INF for atoms and integers, and
> > INF for sequences and objects. Yes, there are cases where this wouldn't
> > work, but they would be extremely rare.
> >
> > Your program would then consider variables that contain -INF or INF are
> > uninitialized.
> >
> > I know it's not the optimal solution but it's better than none.
> >
> > It would be next to optimal if NAN had a unique value. Then we could
> > have a unique identifier for each uninitialized variable. I don't know
> > the nature of NAN though, so I assume it's supposed to be equal to
> > everything.
> >
>
> A nice try. But it has at least three remaining problems:
>
> a) It is a manual effort. So if you forget to do it, something will fail
> somewhere.
>
> b) It can't be relied on for use inside 3rd-party library files. IOW, if
I
> write a library routine that includes a function written like:
>
> global function xx(sequence s)
> -- check for uninitialized parameter.
> if equal(s,INF) then
> s = ""
> end if
> . . .
> end function
>
> and this library is included by somebody in their program, I cannot rely
on
> them using the INF convention. And likewise, if I use a somebody else's
> library function, I can't rely on them testing for uninitialized values in
> this manner.
>
> c) Unfortunatly, INF is a valid value in its own right, and can be used
in
> situations other than checking for uninitialized variables.
>
> The problem really needs to be addressed inside the core Eu interpreter.
It
> knows if a variable is truely initialized or not. The changes are simple.
> - Allow uninitialized variables to be passed as parameters.
> - Create a built-in way of testing a variable's initialization state.
>
> and possibly
>
> - Create a built-in way of setting a variable's state back to
> uninitialized.
>
> This will not break any existing code, and will enable people to write
more
> robust code.
>
> ------------
> Derek.
>
>
>
>
8. Re: Uninitialized Variables
----- Original Message -----
From: "Chris Bensler" <bensler at mail.com>
To: "EUforum" <EUforum at topica.com>
Subject: RE: Uninitialized Variables
>
>
> Derek Parnell wrote:
> > ----- Original Message -----
> > From: "Andy Serpa" <renegade at earthling.net>
> > To: "EUforum" <EUforum at topica.com>
> > Sent: Sunday, March 24, 2002 10:18 AM
> > Subject: RE: Uninitialized Variables
> >
> >
> > > > Apparently NAN is (silly me) Not A Number! :P
> > > > using equal() compares NAN properly and consistently
> > > >
> > > > Here is my revised uninitialized values for variables:
> > > >
> > > > integer = -INF
> > > > atom = INF
> > > > sequence = NAN
> > > > object = -NAN
> > > >
> > >
> > > So how do I test if something is a nan? The "official" way is to use
> > > x!=x, but that is usually optimized away by most compilers (&
Euphoria,
> > > apparently.) Using something like if x=1 and x=2 will work in the
> > > interpreter, but not translated to C, even with Watcom. (In fact, it
is
> > >
> > > different depending on the compiler).
> > >
> > > Am I stuck with "if x and compare(x/x,1)"?
> > >
> > > For my genetic programming system this is a very real problem, as it
> > > comes up with random mathmatical expressions that sometimes are nan's.
> > > If you then take a predicted value (which is a nan) as output for a
> > > function that it has created and compare it with a target value, it
will
> > >
> > > show as being equal (& therefore error = 0). So functions with nan's
as
> > >
> > > output get the highest fitness, which is a disaster...
> > >
> >
> > This seems to work:
> > --------------
> > atom x,nan,inf
> > inf = 1e300 * 1e300
> > nan = inf / inf
> >
> > x = nan
> >
> > if x = nan then
> > puts(1, "x is not a number\n")
> > end if
> > ? x = nan
> > ? x != nan
> >
> > ? nan
> > ? inf
> > ------------
> >
> >
> Derek, try this.
>
> ? x=nan
> ? x=inf
> ? x=10
>
> btw: nan = -(inf/inf)
>
>
> Chris
>
>
>
>
Okay, I did those changes and now I get this:
x is not a number
y is a number
1
0
0
1
0
1
1
0
0
nan
inf
which still looks fine. I'm running with an Intel Pentium III. What did you
get?
------------
Derek.
9. Re: Uninitialized Variables
>
> it's not a CPU thing.
>
> This works for me...
>
> -------------------
> atom x,y,nan,inf
> inf = 1e300 * 1e300
> nan = -(inf / inf) -- ( inf / inf = -nan )
>
> ? equal(10,nan)
> ? not equal(10,nan)
> ? equal(nan,nan)
> -------------------
>
> my results are:
> 0
> 1
> 1
>
>
> Chris
Great. I get the same as you. I even get the same when using '=' rather than
'equal()'.
? 10 = nan
? not (10 = nan)
? nan = nan
Chris, what CPU are use running with? Why does Andy get different results?
10. Re: Uninitialized Variables
Chris, now I'm totally confused. Sorry.
Are you saying that you get the same results as Andy and get different
results to me?
And you and I are using the same CPU type, and Andy is using a different
CPU.
If this is so, what explains the difference in the results then?
Just so we are on an even footing again, here is the code I'm testing:
-----------
atom x,y,nan,inf
constant true=1, false = 0
inf = 1e300 * 1e300
nan = -(inf / inf)
x = nan
y = 10
if x = nan then
puts(1, "x is not a number - expected this.\n")
else
puts(1, "x is a number - did not expect this\n")
end if
if y = nan then
puts(1, "y is not a number - did not expect this\n")
else
puts(1, "y is a number - expected this\n")
end if
printf(1, "%d expected %d\n", {x = nan, true} )
printf(1, "%d expected %d\n", {x != nan, false})
printf(1, "%d expected %d\n", {y = nan, false})
printf(1, "%d expected %d\n", {y != nan, true})
printf(1, "%d expected %d\n", {10 = nan, false})
printf(1, "%d expected %d\n", {10 != nan, true})
printf(1, "%d expected %d\n", {x = nan, true})
printf(1, "%d expected %d\n", {x = inf, false})
printf(1, "%d expected %d\n", {x = 10, false})
printf(1, "%d expected %d\n", {x + 5, nan})
printf(1, "%d expected %d\n", {nan, nan})
printf(1, "%d expected %d\n", {inf, inf})
printf(1, "%d expected %d\n", {equal(10,nan), false})
printf(1, "%d expected %d\n", {not equal(10,nan), true})
printf(1, "%d expected %d\n", {equal(nan,nan), true})
printf(1, "%d expected %d\n", {10 = nan, false})
printf(1, "%d expected %d\n", {not (10 = nan), true})
printf(1, "%d expected %d\n", {nan = nan, true})
------------
In all these case, I got exactly what I expected.
Hopes this helps.
Derek.
11. Re: Uninitialized Variables
- Posted by jbrown1050 at yahoo.com
Mar 24, 2002
On 0, Andy Serpa <renegade at earthling.net> wrote:
>
>
> > I still don't understand what is wrong with
equal(x,nan)
> >
> >
> Simply, it doesn't work on my system. If it works
on yours, then that's
> a double-reason not to use it, as clearly it is
unpredictable. The
> other thread my have solved my problem, though --
sprint(nan) returns
> "nan"!
>
It doesnt work for me either. equal(fix_num(x),
fix_num(nan)), which uses my
sprint() hack, does work fine, but thats only because
fix_num() uses a version
of value() which is hacked so it returns the same nan
(btw the original value()
doesnt work with nan or inf at all. It returns
GET_FAILURE in either case.)
jbrown
--
"Is there peace in heaven, or is that merely an
illusion?" - Someone
"May peace find its way through the heavens to the
world of men and women
before the fires of the damned consume them." -
Someone
Linux User:190064
Linux Machine:84163
12. Re: Uninitialized Variables
- Posted by jbrown1050 at yahoo.com
Mar 24, 2002
On 0, Andy Serpa <renegade at earthling.net> wrote:
>
> Turns out sprint() is way slow. Here's my solution
for now to detect
> inf's or nan's, which are effectively the same for
my purposes:
>
> constant inf = 1e300 * 1e300
> constant nan = -(inf/inf)
> constant inf_s = atom_to_float32(inf)
> constant inf_neg_s = atom_to_float32(-inf)
> constant nan_s = atom_to_float32(nan)
> constant nan_neg_s = atom_to_float32(-nan)
> constant bad_things = {inf_s, inf_neg_s, nan_s,
nan_neg_s}
>
> type nan_or_inf(atom x)
> sequence x_seq
> x_seq = atom_to_float32(x)
> if find(x_seq, bad_things) then
> return 1
> else
> return 0
> end if
> end type
>
> Then, when I need to check, I just:
>
> if nan_or_inf(x) then...
>
You know, equal(x, inf) works fine for me. WHy not
just have bad_things
contain the nans only, and have an "is_nan" type?
And if you really need it, why not have a seperate
is_inf type? That would
allow you to distingush them.
I'm just wondering why you set it up this way, thats
all.
jbrown
--
"Is there peace in heaven, or is that merely an
illusion?" - Someone
"May peace find its way through the heavens to the
world of men and women
before the fires of the damned consume them." -
Someone
Linux User:190064
Linux Machine:84163
