1. atom() ambiguity
Thanks, Graeme. I get the first question on the for...loops, indeed, I
suspected it was for that purpose.
>>>>>
the second line here means:
If the variable "line" is an atom then...
<<<<<
Well, atom returns something. Should this line be
if atom(line) =3D 1 then
This is because couldn't you write
if atom(line) =3D 0 then
Maybe if atom(line) then is a shorthand, but I don't think it is a good o=
ne
because it is ambiguous.
--Alan
=
2. Re: atom() ambiguity
Hello Alan,
>the second line here means:
>If the variable "line" is an atom then...
>Well, atom returns something. Should this line be
>if atom(line) = 1 then
>This is because couldn't you write
>if atom(line) = 0 then
>Maybe if atom(line) then is a shorthand, but I don't think it is a
>good one
>because it is ambiguous.
>
>--Alan
if atom(line) then
and
if atom(line) = 1 then --(or 0)
are two different types of statements
if atom(line) returns 1 then
if atom(line) then
would be the same as:
if 1 then
1 means TRUE and 0 means FALSE so
if 1 then
would execute the if statment and
if 0 then
would skip over the if statement
however
if atom(line) = 0
would execute the if statement if
line is not an atom and not if it is
You could say that
if atom(line) then
is a shorter way to say
if atom(line) = 1 then
but be careful that you know the difference
before you use them interchangably.
This is IMHO of course so I suppose there
could be other explanations.
Lewis Townsend
|\ ____ _ _ _ _ __
| \ | __/ || / | // || / __ \
| \ ||_ || //|| // || ||__\|
| \ | _| || // || // || \___ \
| |\ \ ||__ ||// ||// || |\__||
| | \ \|___\ |_/ |_/ || \____/
| | \ \ _____ ________
| | \ \ | __ \ | _ _ |
| | \ \ ||__|| |/ | | \|
| | \ \ | __ / | |
| |______\ \ || \\ | |
|___________\ || || |_|
Keroltarr at hotmail.com
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
3. Re: atom() ambiguity
-----Original Message-----
De: Alan Tu <ATU5713 at COMPUSERVE.COM>
Para: EUPHORIA at cwisserver1.mcs.muohio.edu
<EUPHORIA at cwisserver1.mcs.muohio.edu>
Fecha: viernes 19 de junio de 1998 11:45
Asunto: atom() ambiguity
>Well, atom returns something. Should this line be
>if atom(line) = 1 then
>This is because couldn't you write
>if atom(line) = 0 then
>Maybe if atom(line) then is a shorthand, but I don't think it is a good one
>because it is ambiguous.
Euphoria performs if..then..end if, while..end while, and such control
structures on true/false statements. false is evaluated to 0 (zero) and true
to any number different from 0 (!=0). If it's more clear to you you can
define constants:
constant true=1
constant false=0
or type:
type boolean (integer x)
if x then -- If 'x' is != 0
return 1
else
return 0 -- If x = 0
end type
Regards,
Daniel Berstein
daber at pair.com
4. Re: atom() ambiguity
Alan Tu wrote:
>
> Thanks, Graeme. I get the first question on the for...loops, indeed, I
> suspected it was for that purpose.
>
> >>>>>
> the second line here means:
>
> If the variable "line" is an atom then...
> <<<<<
>
> Well, atom returns something. Should this line be
>
> if atom(line) = 1 then
>
> This is because couldn't you write
>
> if atom(line) = 0 then
>
> Maybe if atom(line) then is a shorthand, but I don't think it is a good one
> because it is ambiguous.
>
> --Alan
>
Alan,
You have had several responses to your question. Here is one more.
You have read that you can define:
constant
true = 1
false = 0
You can also define:
false = 0
true = not false
An expression is false if it evaluates to 0.
It is true if it evaluates to non-zero.
Thus:
if 1 then ...
if true then ...
if not false then ...
if not 0 then ...
if 5 then ...
all produce a true condtion
if 0 then ...
if false then ...
if not true then ...
if not 1 then ...
all produce a false condition
Assume that a is an atom, then
if atom(a) then ...
is the same as
if atom(a) = 1 then ...
that is, "atom(a)" and "atom(a) = 1" both produce or result in 1, a true
condition
Assume that s is a sequence, then
if atom(s) then ...
is the same as
if atom(s) = 1 then ...
that is, "atom(s)" and "atom(s) = 1" both produce or result in 0, a
false condition.
There are multiple ways to make conditional tests and to use conditions.
Its not that any one of them is a shortcut. Use the one you like. There
is no absolutely correct way to program lines of code like these.
Just a few thoughts that I hope help.
--
Terry Constant
mailto:constant at flash.net
5. Re: atom() ambiguity
As I go to send this message, I see a couple
of you have already said this, but here's
my stab at it anyway.
At 10:44 AM 6/19/98 -0400, Alan wrote:
>Maybe if atom(line) then is a shorthand, but I don't think it is a good one
>because it is ambiguous.
"if atom(a) then" translates to "if atom(a)!=0 then"
It works because of the way the if..then
statement works. If..then accepts a numeric
input and branches around (skips) the enclosed
code if that input is zero.
Numeric input? Yes.
All comparisons are equated to a
numeric result, 1 for true and 0 for
false. The comparison (3=5) has a
value of 0 as three obviously does
not equal five.
You can assign the result of a comparison
to a variable;
integer comp
comp=(6=3)
print(1,comp)
The output is 0 (false)
-----------------
integer comp
comp=(5>3)+(6!=4)+(2<9)
print(1,comp)
The output is 3 (true+true+true)
-----------------
integer comp
comp=1/(2>5)
The output is division by zero (false) error
-----------------
sequence comp
comp=({3,6,8,4}>6)
print(1,comp)
The output is {0,0,1,0} (false,false,true,false)
-----------------
So, if you put "if atom(line)=1 then" in
your program, the comparison (atom(line)=1)
will be evaluated to a one or a zero and that
value will be passed to the if..then statement.
But, as you have a 1 or a 0 returned from the
type check anyway, it hardly seems worth the
effort.
Graeme.
----------------------------------------------------
6. Re: atom() ambiguity
On Fri, 19 Jun 1998, Daniel Berstein wrote:
> constant true=1
> constant false=0
>
> or type:
>
> type boolean (integer x)
> if x then -- If 'x' is != 0
> return 1
> else
> return 0 -- If x = 0
> end type
This code won't work. A program would crash if it a boolean was set to
false(0) and wouldn't crash if x = 7 (for instance).
After thinking a lot recently, this is the best solution (IMHO):
constant TypeFail = 0
constant True = 1, False = 0
type boolean(object x)
if not integer(x) then
return TypeFail
end if
return x=not(not x)
end type
-- Example code
boolean a,b,q
a = True
b = False
q = (a or b) and not (a and b)
--
Carl R White
E-mail...: cyrek- at -bigfoot.com / Remove the hyphens before
Finger...: crwhite- at -dcsun1.comp.brad.ac.uk \ mailing or fingering...
Url......: http://www.bigfoot.com/~cyrek/
7. Re: atom() ambiguity
-----Original Message-----
De: Carl R. White <C.R.White at SCM.BRAD.AC.UK>
Para: EUPHORIA at cwisserver1.mcs.muohio.edu
<EUPHORIA at cwisserver1.mcs.muohio.edu>
Fecha: lunes 22 de junio de 1998 12:26
Asunto: Re: atom() ambiguity
>> type boolean (integer x)
>> if x then -- If 'x' is != 0
>> return 1
>> else
>> return 0 -- If x = 0
>> end type
>
>This code won't work. A program would crash if it a boolean was set to
>false(0) and wouldn't crash if x = 7 (for instance).
Quite right Carl... Mea Culpa ;)
>After thinking a lot recently, this is the best solution (IMHO):
>
>constant TypeFail = 0
>constant True = 1, False = 0
>
>type boolean(object x)
> if not integer(x) then
> return TypeFail
> end if
> return x=not(not x)
>end type
Does it work? If x=False (0) then:
return x=not(not x)
return x=not(1)
return x=0 --->False
Isn't this the same I posted before, giving a type_check error?
The type declaration should be:
type boolean(object x)
integer t
if sequence(x) then
if length(x) = 0 then
t = 0
else
for i=1 to length(x)-1 do
t = boolean(x[i]) and boolean(x[i+1])
end for
end if
else
t = 1
end if
return t
end type
This type declaration says an object is a valid boolean variable if and only
if:
1.- It's an atom (can be true or false).
2.- It's a tautological (all true: != 0)or completly negational (all false:
= 0) sequence.
Regards,
Daniel Berstein
daber at pair.com
8. Re: atom() ambiguity
On Mon, 22 Jun 1998, Daniel Berstein wrote:
> Carl R. White wrote:
> >> type boolean (integer x)
> >> if x then -- If 'x' is != 0
> >> return 1
> >> else
> >> return 0 -- If x = 0
> >> end type
> >
> >This code won't work. A program would crash if it a boolean was set to
> >false(0) and wouldn't crash if x = 7 (for instance).
>
> Quite right Carl... Mea Culpa ;)
>
> >After thinking a lot recently, this is the best solution (IMHO):
> >
> >constant TypeFail = 0
> >constant True = 1, False = 0
> >
> >type boolean(object x)
> > if not integer(x) then
> > return TypeFail
> > end if
> > return x=not(not x)
> >end type
>
> Does it work? If x=False (0) then:
> return x=not(not x)
> return x=not(1)
> return x=0 --->False
> Isn't this the same I posted before, giving a type_check error?
Errm... (/me thinks hard) It does work.
I'm not returning 0, I'm returning *(x = 0)*...
if x = 0 then (x = not(not 0))
=> (x = not(1))
=> (x = 0)
=> True => 1 => no failure
if x = 1 then (x = not(not 1))
=> (x = not(0))
=> (x = 1)
=> True => 1 => no failure
The function not(not x) will always return 1 or 0, so *any other* values
cause a type_check failure.
> The type declaration should be:
>
> type boolean(object x)
> integer t
> if sequence(x) then
> if length(x) = 0 then
> t = 0
> else
> for i=1 to length(x)-1 do
> t = boolean(x[i]) and boolean(x[i+1])
> end for
> end if
> else
> t = 1
> end if
> return t
> end type
If you wanted a boolean_sequence type then this is it:
type boolseq(object x)
if not sequence(x)
return TypeFail -- Defined as 0
end if
return compare(x, not(not x)) = 0
end type
Combining the two types is easier and a lot simpler than it seems:
type boolobj(object x)
return compare({x}, not(not {x})) = 0
end type
This is fun... :)
--
Carl R White
E-mail...: cyrek- at -bigfoot.com / Remove the hyphens before
Finger...: crwhite- at -dcsun1.comp.brad.ac.uk \ mailing or fingering...
Url......: http://www.bigfoot.com/~cyrek/
9. Re: atom() ambiguity
It occured to me after I went home, after I posted the last message in
this thread that:
not(not {x})
...could be replaced with:
{x} != 0
...which is a heck of a lot less typing and probably faster too :)
--
Carl R White
E-mail...: cyrek- at -bigfoot.com / Remove the hyphens before
Finger...: crwhite- at -dcsun1.comp.brad.ac.uk \ mailing or fingering...
Url......: http://www.bigfoot.com/~cyrek/