1. RE: Uninitialized Variables
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.
>
> 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:
I don't think you understand what a uninitialized variable is.
When a compiler or interpreter allocates a storage location
to contain a variable. There is know way to know what that
memory location contains. The variable is therefore
called a unintialized variable. If the compiler or interpreter
assigns a known value at creation time, then the variable
is called a initialized variable. What you are doing above
is assigning a known value to a uninitialized variable.
Bernie
2. 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.
Chris
Bernie Ryan wrote:
>
> 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.
> >
> > 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:
> I don't think you understand what a uninitialized variable is.
> When a compiler or interpreter allocates a storage location
> to contain a variable. There is know way to know what that
> memory location contains. The variable is therefore
> called a unintialized variable. If the compiler or interpreter
> assigns a known value at creation time, then the variable
> is called a initialized variable. What you are doing above
> is assigning a known value to a uninitialized variable.
> Bernie
>
>
3. RE: Uninitialized Variables
> > > 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?
> > >
I just ran into this problem yesterday -- how do you test for a nan? It
registers equal to everything if you use '=' but not equal(). The
behavior also changes if you compile to C, and is different with every
compiler. This always works:
x = <nan>
if x and compare(x/x,1) then
...
(a nan passes the first test, which is neccessary to avoid div by zero
for non-nans -- it also passes the second test, which for any real
number will compare() to 0)
It also occured to be that the representation of a nan might be
consistent if you atom_to_float() it, but I haven't tried that yet.
Either way seems expensive -- is there a good way to test if something
is a nan?
4. RE: Uninitialized Variables
Refer to my includeed original message, paragraph 4 :P.
It is useful nonetheless.
No, you can't use it in 3rd-party libs, because it's a manual
convention. And no, you can't use it in cases where you are dealing with
extremeley large numbers.
The factor that it's a manual effeort is a nuisance, but worst case, you
run your program, and it tells you that's it's uninitialized (heh,
oxymoron).
I know it's not the solution, but I have stumbled on this case before,
and my method would have worked just fine.
Chris
Derek Parnell wrote:
> ----- 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.
>
>
>
5. RE: Uninitialized Variables
Andy Serpa wrote:
>
> > > > 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?
> > > >
>
> I just ran into this problem yesterday -- how do you test for a nan? It
>
> registers equal to everything if you use '=' but not equal(). The
> behavior also changes if you compile to C, and is different with every
> compiler. This always works:
>
> x = <nan>
>
> if x and compare(x/x,1) then
> ...
>
> (a nan passes the first test, which is neccessary to avoid div by zero
> for non-nans -- it also passes the second test, which for any real
> number will compare() to 0)
>
> It also occured to be that the representation of a nan might be
> consistent if you atom_to_float() it, but I haven't tried that yet.
> Either way seems expensive -- is there a good way to test if something
> is a nan?
>
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
Chris
6. 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...
7. RE: Uninitialized Variables
You need to use equal(), instead of =
? not equal(324876,NAN)
Chris
Andy Serpa wrote:
>
>
> > 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...
>
>
8. 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...
9. RE: Uninitialized Variables
Yeah, I tried it, and is definitely *NOT* what I get -- maybe it is a
CPU thing. I have an AMDK6-2/450.
For this version I get:
x is not a number
y is not a number
1
0
1
0
1
0
-nan
inf
Now I checked atom_to_float32()/float32_to_atom() and that works
consistently -- note that (nan) & (-nan) are different though.
Derek Parnell wrote:
> > >
> > > 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.
>
>
10. 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
11. RE: Uninitialized Variables
No difference on my system. It might also be you are being tripped up
by an optimization:
atom x,y,nan,inf
inf = 1e300 * 1e300
nan = inf / inf
x = nan
Now equal(x,nan) will be TRUE, probably because Euphoria doesn't
actually even compare them, since they both will share the same internal
pointer at this point.
Now do:
y = x + 5 <= y is now also a nan (actually -nan)
? equal(y,nan)
-- This is FALSE. Once again, we can't determine a nan this way.
? x
? y
-nan
-nan
Chris Bensler wrote:
> You need to use equal(), instead of =
>
> ? not equal(324876,NAN)
>
>
> Chris
>
> Andy Serpa wrote:
> >
> >
> > > 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...
> >
> >
12. RE: Uninitialized Variables
Derek Parnell wrote:
> ----- Original Message -----
> From: "Chris Bensler" <bensler at mail.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Sunday, March 24, 2002 10:58 AM
> 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
<snip>
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
13. RE: Uninitialized Variables
Derek Parnell wrote:
> >
> > 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?
>
>
How odd.
I'm SURE I didn't snip your msg.
If I did, I would have wrote <SNIP>. I always capitalize those tags.
A portion of my post is also missing. I assume that is what was snipped.
Probably something to do with the auto moderator.
I'll try again...
I get the same results as Andy gets for your example. Like you, I'm also
using a PIII, so 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
14. RE: Uninitialized Variables
If this message comes through twice, I'm sorry -- the web interface is
very slow today:
Ok, here's the test so we don't get tricked by the optimizer:
equal(anything,copy of anything) will always be true -- you have to make
a nan that isn't just a copy of your definition.
-------------------
atom x,y,nan,inf, z, unknown
inf = 1e300 * 1e300
nan = -(inf / inf) -- ( inf / inf = -nan )
x = 10 -- not a nan
y = -tan(inf) -- a nan
z = nan -- a different nan
----------------------------
Now, assume you don't know what x,y, & z are. Show me a way to identify
the nans & non-nans, AND continues to work when translated to C (except
with Borland -- all of these big number things crash Borland).
THIS works in all cases I know of:
------------------------------------
unknown = x
if unknown and compare(unknown/unknown,1) then
puts(1,"NAN!\n")
else
puts(1,"non-NAN!\n")
end if
unknown = y
if unknown and compare(unknown/unknown,1) then
puts(1,"NAN!\n")
else
puts(1,"non-NAN!\n")
end if
unknown = z
if unknown and compare(unknown/unknown,1) then
puts(1,"NAN!\n")
else
puts(1,"non-NAN!\n")
end if
---------------
This works in the interpreter, but not when compiled:
unknown = x
if unknown = 1 and unknown = 2 then
puts(1,"NAN!\n")
else
puts(1,"non-NAN!\n")
end if
-----------------
As I said, using atom_to_float32() also would work it seems, but you
have to account for nan & -nan.
So one way involves two comparisons & a division; the other involves
converting to a sequence & then up to two comparisions. Isn't there a
cheaper way?
15. RE: Uninitialized Variables
-------Phoenix-Boundary-07081998-
Hi Andy Serpa, you wrote on 3/23/02 6:09:54 PM:
<SNIP>
>
>So one way involves two comparisons & a division; the other involves
>converting to a sequence & then up to two comparisions. Isn't there a
>cheaper way?
>
I tried your code and it failed for me -- the 'y'
case came out "non-NaN"
Have you tried:
if unknown >= 1e255 then
puts( 1, "it's a NaN!")
....
Works under the interpreter but I haven't tried the compiler
The '1e255' comes directly from the IEEE 754 NaN definition,
so it should be o.k.
The test probably should be:
if unknown >= 1e255 or unknown <= -1e255 then
Karl Bochert
-------Phoenix-Boundary-07081998---
16. RE: Uninitialized Variables
>
> I tried your code and it failed for me -- the 'y'
> case came out "non-NaN"
>
Boy, what a nightmare.
> Have you tried:
> if unknown >= 1e255 then
> puts( 1, "it's a NaN!")
> ....
>
> Works under the interpreter but I haven't tried the compiler
> The '1e255' comes directly from the IEEE 754 NaN definition,
> so it should be o.k.
>
> The test probably should be:
> if unknown >= 1e255 or unknown <= -1e255 then
>
> Karl Bochert
>
Well, Euphoria handles atoms up to 1e300 or so, and after that they end
up as "inf", which is something else entirely. So maybe
atom_to_float32() is the only reliable way, which uses IEEE format...
17. RE: Uninitialized Variables
-------Phoenix-Boundary-07081998-
Hi Andy Serpa, you wrote on 3/23/02 10:13:12 PM:
>> I tried your code and it failed for me -- the 'y'
>> case came out "non-NaN"
>
>Boy, what a nightmare.
>
You sure got that right. My method is useless.
Have you noticed that real math (IEEE 754) has
+infinity, -infinity, quiet NaNs, signaling NaNs,
indeterminates, as well as normalized and
denormalized numbers!
Combine that with Eu's 'atoms' which change silently
from integers to doubles.
The best solution may be a DLL that knows how to ask the
floating point processor (nicely) for its secrets.
Karl Bochert
-------Phoenix-Boundary-07081998---
18. RE: Uninitialized Variables
kbochert at ix.netcom.com wrote:
> -------Phoenix-Boundary-07081998-
> Content-type: text/plain; charset=ISO-8859-1
> Content-transfer-encoding: 8bit
>
> Hi Andy Serpa, you wrote on 3/23/02 10:13:12 PM:
>
> >> I tried your code and it failed for me -- the 'y'
> >> case came out "non-NaN"
>
> >
> >Boy, what a nightmare.
> >
> You sure got that right. My method is useless.
> Have you noticed that real math (IEEE 754) has
> +infinity, -infinity, quiet NaNs, signaling NaNs,
> indeterminates, as well as normalized and
> denormalized numbers!
> Combine that with Eu's 'atoms' which change silently
> from integers to doubles.
> The best solution may be a DLL that knows how to ask the
> floating point processor (nicely) for its secrets.
>
Been looking for one, but haven't found one that's compiled already. I
never get get c source to compile correctly...
19. RE: Uninitialized Variables
kbochert at ix.netcom.com wrote:
> You sure got that right. My method is useless.
> Have you noticed that real math (IEEE 754) has
> +infinity, -infinity, quiet NaNs, signaling NaNs,
> indeterminates, as well as normalized and
> denormalized numbers!
> Combine that with Eu's 'atoms' which change silently
> from integers to doubles.
> The best solution may be a DLL that knows how to ask the
> floating point processor (nicely) for its secrets.
>
Karl:
You can use the floating point processor with assembler
in euphoria. asm.e supports the floating point processor.
Bernie
20. RE: Uninitialized Variables
Derek Parnell wrote:
<snip>
> 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.
But uninitialized variables are caught at "compile" time. Why
would you want to wait until runtime to catch them? What would
be the point?
Rod
21. RE: Uninitialized Variables
Andy Serpa wrote:
<snip>
> 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...
Andy,
If you don't mind me asking, what sorts of expressions are
your genes coming up with that yield NAN? Are you using
INF on occasion? Or square root of negative numbers? I'm
asking because, while this needs to be addressed (and so
far the discussion is very revealing,) it might save you time
if a workaround can be found.
Rod
22. RE: Uninitialized Variables
> If you don't mind me asking, what sorts of expressions are
> your genes coming up with that yield NAN? Are you using
> INF on occasion? Or square root of negative numbers? I'm
> asking because, while this needs to be addressed (and so
> far the discussion is very revealing,) it might save you time
> if a workaround can be found.
>
I have simple checks to avoid division by zero, taking the log of a
negative, etc., but if you mix a bunch of random mathmatical functions
with a bunch of random values, you're going to get some strange results
sometimes. The checks I have are all for *before* a function is
performed. For instance, if the second argument is zero in a division,
don't do the calculation. This will avoid an outright crash. Other
functions, like tan(), will output nan or -nan if the value going in is
too extreme. Since it doesn't actually crash, it would be much easier
to check for a nan after the function is performed then try to set
strict limits that must be checked before each individual function is
performed. If I can check for nans reliably, I can just set up a custom
"non_nan" type that catches it (a type that always returns TRUE to avoid
a crash, but sets another global flag so I can throw out that function
internally)...
23. RE: Uninitialized Variables
Andy Serpa wrote:
>
> > If you don't mind me asking, what sorts of expressions are
> > your genes coming up with that yield NAN? Are you using
> > INF on occasion? Or square root of negative numbers? I'm
> > asking because, while this needs to be addressed (and so
> > far the discussion is very revealing,) it might save you time
> > if a workaround can be found.
> >
>
> I have simple checks to avoid division by zero, taking the log of a
> negative, etc., but if you mix a bunch of random mathmatical functions
> with a bunch of random values, you're going to get some strange results
> sometimes. The checks I have are all for *before* a function is
> performed. For instance, if the second argument is zero in a division,
> don't do the calculation. This will avoid an outright crash. Other
> functions, like tan(), will output nan or -nan if the value going in is
> too extreme. Since it doesn't actually crash, it would be much easier
> to check for a nan after the function is performed then try to set
> strict limits that must be checked before each individual function is
> performed. If I can check for nans reliably, I can just set up a custom
>
> "non_nan" type that catches it (a type that always returns TRUE to avoid
>
> a crash, but sets another global flag so I can throw out that function
> internally)...
>
>
I still don't understand what is wrong with equal(x,nan)
Chris
24. RE: Uninitialized Variables
>
> 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"!
25. RE: Uninitialized Variables
jbrown1050 at yahoo.com wrote:
> 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"!
> >
>
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...
26. RE: Uninitialized Variables
jbrown1050 at yahoo.com wrote:
> 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.
>
Yeah, that would work too. I need to detect for either one of them, so
I combined them. If equal works with inf that is probably faster,
you're right...
