Odd or Even 
Author Message
 Odd or Even

Hi All,

            I need to look at a number and determine if it odd
or even.  Looked in the help and could not see anything.
Anybody have some code or know of a Clarion function
that could return odd\even status.  TIA

--
Ron Childs
Softpower Computer Systems
C5.5g, ABC



Fri, 21 Jan 2005 23:37:06 GMT  
 Odd or Even
Ron

Quote:
>             I need to look at a number and determine if it odd
> or even.  Looked in the help and could not see anything.
> Anybody have some code or know of a Clarion function
> that could return odd\even status.  TIA

IF NOT (Number  %  2) ! no reminder divising number per 2
  ! Even
Else
  !Odd
End

Bernard
PS- You might use choose instead

Choose(Number % 2,'Odd','Even')



Fri, 21 Jan 2005 23:37:08 GMT  
 Odd or Even
An integer is odd if band(myNumber, 1) = 1, otherwise it is even.

                            -Ray.


Quote:
> Hi All,

>             I need to look at a number and determine if it odd
> or even.  Looked in the help and could not see anything.
> Anybody have some code or know of a Clarion function
> that could return odd\even status.  TIA

> --
> Ron Childs
> Softpower Computer Systems
> C5.5g, ABC



Fri, 21 Jan 2005 23:37:14 GMT  
 Odd or Even
Hi Ron,

On Fri, 26 Jul 2002 17:16:25 -0400, "Ron Childs"

Quote:

>Anybody have some code or know of a Clarion function
>that could return odd\even status.  TIA

IsEven  Procedure(Long X),Byte
 Code
 Return(Choose(X%2=0,True,False))

Best regards,

Arnr Baldvinsson
Icetips Software        
San Antonio, Texas, USA
www.icetips.com

ICQ:  113314380

Subscribe to information from Icetips.com:
http://www.icetips.com/getnotificationinfo.htm



Fri, 21 Jan 2005 23:37:13 GMT  
 Odd or Even
How about:

EXECUTE Number%2+1
    It's Even!
   It's Odd!
.


Quote:
> Hi All,

>             I need to look at a number and determine if it odd
> or even.  Looked in the help and could not see anything.
> Anybody have some code or know of a Clarion function
> that could return odd\even status.  TIA

> --
> Ron Childs
> Softpower Computer Systems
> C5.5g, ABC



Fri, 21 Jan 2005 23:37:24 GMT  
 Odd or Even
Hi all,


Quote:
> Well, if they change the equate, it would do more than break my code.  It
> would break ABC and template generated code as they assume it can be
treated
> as a boolean also.

    I have not noticed this in the templates, which ones?   The classes, at
least the ones I use the error has been corrected.   I add several equates,
so far only on the other end 6 and up but if a new equate value was needed
before Level:benign and it made sense I would just add it to the list.

Quote:
> The standard in ABC tends to be 0 if everything is okay and a steadily
> increasing value as it all goes to hell in a hand basket.

   Yep, but I still don't like the idea.   More of a personal preference
than anything else, I seldom use negative logic, if ~x, I would normally
write if x = false or if x != true, the compiler will generate the same
code, set a couple of registers, do a cmp and test one of the flags,  which
one reads better, personal choice.  Hopefully one of the improvements to
version 6 will be exceptions.

    Dennis



Fri, 21 Jan 2005 23:38:08 GMT  
 Odd or Even
That's true, ABC classes code has this "mistake".



Quote:
> Well, if they change the equate, it would do more than break my code.  It
> would break ABC and template generated code as they assume it can be
treated
> as a boolean also.

> The standard in ABC tends to be 0 if everything is okay and a steadily
> increasing value as it all goes to hell in a hand basket.

> --

> - Andrew Guidroz II (GeeTroze)



> > Hi all,


> > >     1 - Change of bitwise storage
> > >     2 - Implementation of 3-state logic or N-state logic with
biological
> > > chips. (Althoug BAND sould be redefined in this case)

> >     If the above happens then band would have to be changed.

> > >     If access:MyFile.TryFetch() <> Level:Benign   instead of

> >        I always use the above

> > >     If access:MyFile.TryFetch()

> >     This is wrong, tryFetch is not a Boolean function, and could very
well
> > result in a lot of broken code.   The whole idea of using equates is
they
> > can be changed when needed/wanted.

> > >    cause the second fails if Level:Benign get equated as 1 in a next
> > version
> > > of ABC classes.

> >   Probably not but there is nothing that prevents SV from altering the
> > equates.  All that broken code would be a  inflicted wound.

> > >     Who would be so {*filter*} to do that? I dont know, but is to be able
to
> do
> > > that that it is equated.

> >     Don't know who would, but the moans and complaints would be
> > entertaining.

> >     Dennis



Fri, 21 Jan 2005 23:38:07 GMT  
 Odd or Even
Hi all,

Quote:

> True by now, but dangerous, as it depends on the bit represantations of
> numbers.

    Not following, when would this be dangerous? An integer will always have
a 0 or 1 as the LSB, even or odd.

    Dennis



Fri, 21 Jan 2005 23:37:57 GMT  
 Odd or Even
Well, the reason I think they did it the way they did was so you don't have
to use negative ...

IF ERROR()

and

IF TryFetch()

I mean, personally, for file i/o type stuff, I tend to code the error and
let the natural flow process the best case.

IF TryFetch()

HandleTheError(AndHopefullyTheTryFetchSetAnExceptionValueThatCanBePassedAsAP
arameterOrAccessibleAsAProperty)
ELSE
   ProcessTheGoodInformation
END

If you had to code the equate each time, your code would be littered with
CASE statements.

The process is boolean .. either it worked or it didn't.  The ABC classes
allow me to test that way.  Exception handling is best left to exception
handlers and ABC works that way too ... the non zero values are handled
somewhere else.

--

- Andrew Guidroz II (GeeTroze)



Quote:
> Hi all,


> > Well, if they change the equate, it would do more than break my code.
It
> > would break ABC and template generated code as they assume it can be
> treated
> > as a boolean also.

>     I have not noticed this in the templates, which ones?   The classes,
at
> least the ones I use the error has been corrected.   I add several
equates,
> so far only on the other end 6 and up but if a new equate value was needed
> before Level:benign and it made sense I would just add it to the list.

> > The standard in ABC tends to be 0 if everything is okay and a steadily
> > increasing value as it all goes to hell in a hand basket.

>    Yep, but I still don't like the idea.   More of a personal preference
> than anything else, I seldom use negative logic, if ~x, I would normally
> write if x = false or if x != true, the compiler will generate the same
> code, set a couple of registers, do a cmp and test one of the flags,
which
> one reads better, personal choice.  Hopefully one of the improvements to
> version 6 will be exceptions.

>     Dennis



Fri, 21 Jan 2005 23:38:11 GMT  
 Odd or Even
Exceptions is one most important clarion lack.
Hope the apperar soon.



Quote:
> Hi all,


> > Well, if they change the equate, it would do more than break my code.
It
> > would break ABC and template generated code as they assume it can be
> treated
> > as a boolean also.

>     I have not noticed this in the templates, which ones?   The classes,
at
> least the ones I use the error has been corrected.   I add several
equates,
> so far only on the other end 6 and up but if a new equate value was needed
> before Level:benign and it made sense I would just add it to the list.

> > The standard in ABC tends to be 0 if everything is okay and a steadily
> > increasing value as it all goes to hell in a hand basket.

>    Yep, but I still don't like the idea.   More of a personal preference
> than anything else, I seldom use negative logic, if ~x, I would normally
> write if x = false or if x != true, the compiler will generate the same
> code, set a couple of registers, do a cmp and test one of the flags,
which
> one reads better, personal choice.  Hopefully one of the improvements to
> version 6 will be exceptions.

>     Dennis



Fri, 21 Jan 2005 23:38:12 GMT  
 Odd or Even
Hi all,


Quote:
> IF TryFetch()

HandleTheError(AndHopefullyTheTryFetchSetAnExceptionValueThatCanBePassedAsAP

Quote:
> arameterOrAccessibleAsAProperty)
> ELSE
>    ProcessTheGoodInformation
> END

   TryFetch and Fetch are two methods that standard error code information
is available,

   if tryfetch() = Level:Benign
       MethodToDoSomethingWiththeRecord()
   else
       ErrorMethod(errorcode())
   end

Quote:
> If you had to code the equate each time, your code would be littered with
> CASE statements.

   case statements are useful if the level is needed,  but otherwise not of
much interest.

   case tryfetch()
      of level:benign
          good read
      of level:notify
          eof or whatever
      of  level:user
          deal with special condition specific to this app/procedure
      else
          format the hard disk
    end

   will generate the same code as if, elsif, else, and a little easier to
read.

While the process is Boolean, the return value is not.  The return value is
an equate that is currently equal to 0, not the same.

    Dennis



Fri, 21 Jan 2005 23:38:23 GMT  
 Odd or Even
Hi Dennis,

On Sat, 27 Jul 2002 10:04:58 -0500, "Dennis E. Evans"

Quote:

>       I always use the above

>>     If access:MyFile.TryFetch()

>    This is wrong, tryFetch is not a Boolean function, and could very well
>result in a lot of broken code.   The whole idea of using equates is they
>can be changed when needed/wanted.

I recall arguing this same case few years back because a lot of code
was being used in the templates and classes which treated non-boolean
methods as boolean, as in the example above.  If you read through the
LearnABC.pdf you will find that the very few code examples there seem
to suggest the usage of functions as boolean or as procedures (page
96):

Relate:File.Open() !This handles all error conditions
CLEAR(FIL:record)
FIL:Code = 123
Access:File.Fetch(FIL:CodeKey) !Fetch clears the record on errors
Relate:File.Close()

The use of the LEVEL: equates is very limited in that document also
and there are no practical examples that I have found in the use of
the LEVEL equates with FM or RM methods.

It seemed to be the general opinion at the time that these could and
even should be treated like boolean because they return 0
(level:benign) upon success and the limited information you can get
from the LEVEL equates was of little use to determine the actual
error, only the severity of it.  So I, like probably the majority of
Clarion programmers, code them as boolean:(

Best regards,

Arnr Baldvinsson
Icetips Software        
San Antonio, Texas, USA
www.icetips.com

ICQ:  113314380

Subscribe to information from Icetips.com:
http://www.icetips.com/getnotificationinfo.htm



Fri, 21 Jan 2005 23:38:13 GMT  
 Odd or Even
Dennis,

This is actually logical.  Sometimes it is not enough to use as a Boolean.
There can be varying degrees of failure.  ABC handles these degrees of
failure quite nicely.

I think of it as "it failed, but to what degree was the failure?".  When I
say "failure" I am not talking about something that went bang.  A failure
could range from "another person is currently editing this record, try your
edits later" to something bad, "Record not found" or catastrophic, "Record
mis-match".

I tend to think of these levels as failures, but with additional information
about the failure.

--
Russ Eggen
www.radfusion.com



Hi all,

    I have not noticed this in the templates, which ones?   The classes, at
least the ones I use the error has been corrected.   I add several equates,
so far only on the other end 6 and up but if a new equate value was needed
before Level:benign and it made sense I would just add it to the list.

Quote:
> The standard in ABC tends to be 0 if everything is okay and a steadily
> increasing value as it all goes to hell in a hand basket.

   Yep, but I still don't like the idea.   More of a personal preference
than anything else, I seldom use negative logic, if ~x, I would normally
write if x = false or if x != true, the compiler will generate the same
code, set a couple of registers, do a cmp and test one of the flags,  which
one reads better, personal choice.  Hopefully one of the improvements to
version 6 will be exceptions.

    Dennis



Fri, 21 Jan 2005 23:38:20 GMT  
 Odd or Even
My point is the severity at this level is irrelevant.

That's why there's an object to handle errors.

--

- Andrew Guidroz II (GeeTroze)



Quote:
> Hi all,


> > IF TryFetch()

HandleTheError(AndHopefullyTheTryFetchSetAnExceptionValueThatCanBePassedAsAP
Quote:
> > arameterOrAccessibleAsAProperty)
> > ELSE
> >    ProcessTheGoodInformation
> > END

>    TryFetch and Fetch are two methods that standard error code information
> is available,

>    if tryfetch() = Level:Benign
>        MethodToDoSomethingWiththeRecord()
>    else
>        ErrorMethod(errorcode())
>    end

> > If you had to code the equate each time, your code would be littered
with
> > CASE statements.

>    case statements are useful if the level is needed,  but otherwise not
of
> much interest.

>    case tryfetch()
>       of level:benign
>           good read
>       of level:notify
>           eof or whatever
>       of  level:user
>           deal with special condition specific to this app/procedure
>       else
>           format the hard disk
>     end

>    will generate the same code as if, elsif, else, and a little easier to
> read.

> While the process is Boolean, the return value is not.  The return value
is
> an equate that is currently equal to 0, not the same.

>     Dennis



Fri, 21 Jan 2005 23:38:27 GMT  
 Odd or Even
Hi Dennis,

On Sat, 27 Jul 2002 15:35:41 -0500, "Dennis E. Evans"

Quote:

>   But there is the rub, Level:Benign is an equate, it just happens to be
>equated to 0.  If the methods or the documentation stated they returned 0
>for success and non-zero for failure, like most Win32 API calls then I would
>code them as Boolean,

I know.  When I write methods that I intend to use as boolean methods,
they return true or false, nothing else.  If I write methods that
return anything other than true/false, I try to avoid them being
possibly used as boolean by not ever returning False (0)  That way
they can't be used as boolean methods and it forces me to check for a
particular value when I call the method because that was the way I
designed it (and for a reason too<g>)

But like I said, unfortunately, a lot of us have taken to the bad
habbit of not checking for the actual value returned by these
functions, but use them as boolean functions.  

Best regards,

Arnr Baldvinsson
Icetips Software        
San Antonio, Texas, USA
www.icetips.com

ICQ:  113314380

Subscribe to information from Icetips.com:
http://www.icetips.com/getnotificationinfo.htm



Fri, 21 Jan 2005 23:38:31 GMT  
 
 [ 49 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 

1. Odd and Even conjunctions

2. Odd and Even functions missing in RB

3. Printing Odd or Even page only

4. determine whether a number is odd or even

5. odd or even function?

6. Odd or Even ??

7. Odd (actually even) ROUND behavior

8. Easy was to determine a number is odd or even?

9. J: Even and Odd

10. Even/odd week number

11. Even/Odd rounding

12. Even/Odd rounding

 

 
Powered by phpBB® Forum Software