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
 =

new topic     » topic index » view message » categorize

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

new topic     » goto parent     » topic index » view message » categorize

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

new topic     » goto parent     » topic index » view message » categorize

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

new topic     » goto parent     » topic index » view message » categorize

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.








----------------------------------------------------

new topic     » goto parent     » topic index » view message » categorize

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/

new topic     » goto parent     » topic index » view message » categorize

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

new topic     » goto parent     » topic index » view message » categorize

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/

new topic     » goto parent     » topic index » view message » categorize

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/

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu