Xojo Conferences
XDCMay2019MiamiUSA

Division by zero (Real Studio network user group Mailinglist archive)

Back to the thread list
Previous thread: Interesting Database Autocompletes...
Next thread: IDE Scripting Syntax Question


Reading *CSV Files versus *.Txt Files   -   Claude Stone
  Division by zero   -   Harrie Westphal
   Re: Division by zero   -   Arnaud Nicolet
   Re: Division by zero   -   Joe Huber
   Re: Division by zero   -   Joe Strout
   Re: Division by zero   -   Eric Williams
   Re: Division by zero   -   Frank Condello
   Re: Division by zero   -   Charles Yeomans
   Re: Division by zero   -   Harrie Westphal
    RE: Division by zero   -   Robin Lauryssen-Mitchell
     Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   Terry Ford
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   Terry Ford
   Re: Division by zero   -   Terry Ford
    Re: Division by zero   -   Jose Maria Terry Jimenez
   Re: Division by zero   -   Andrew Keller
   Re: Division by zero   -   Charles Yeomans
   Re: Division by zero   -   Joe Huber
   Re: Division by zero   -   Joe Strout
   Re: Division by zero   -   Joe Huber
   Re: Division by zero   -   Andrew Keller
   Re: Division by zero   -   Harrie Westphal
    Re: Division by zero   -   Fargo Holiday
   Re: Division by zero   -   Joe Huber
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   Tim Jones
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   Karen
   Re: Division by zero   -   Karen
   Re: Division by zero   -   John Jobe
   Re: Division by zero   -   Eric Richards
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   John Jobe
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   Joe Huber
   Re: Division by zero   -   John Jobe
   Re: Division by zero   -   Joe Huber
   Re: Division by zero   -   Terry Ford
   Re: Division by zero   -   John Jobe
   Re: Division by zero   -   Terry Ford
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   John Jobe
   Re: Division by zero   -   Joe Huber
   Re: Division by zero   -   John Jobe
   Re: Division by zero   -   Joe Huber
   Re: Division by zero   -   Tim Jones
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   Joe Huber
   Re: Division by zero   -   John Jobe
   Re: Division by zero   -   John Jobe
   Re: Division by zero   -   Joe Huber
   Re: Division by zero   -   Karen
   Re: Division by zero   -   Karen
   Re: Division by zero   -   John Jobe
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   John Jobe
   Re: Division by zero   -   Joe Huber
   Re: Division by zero   -   Arnaud Nicolet
   Re: Division by zero   -   Arnaud Nicolet
   Re: Division by zero   -   Arnaud Nicolet
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   John Jobe
   Re: Division by zero   -   Arnaud Nicolet
   Re: Division by zero   -   Arnaud Nicolet
   Re: Division by zero   -   Arnaud Nicolet
   Re: Division by zero   -   Karen
   Re: Division by zero   -   Joe Huber
    Re: Division by zero   -   Andre Kuiper
   Re: Division by zero   -   Arnaud Nicolet
   Re: Division by zero   -   John Jobe
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   Arnaud Nicolet
   Re: Division by zero   -   Arnaud Nicolet
    Re: Division by zero   -   Metsis
   Re: Division by zero   -   Joe Huber
   Re: Division by zero   -   Rubber Chicken Software Co.
   Re: Division by zero   -   Arnaud Nicolet
    Re: Division by zero   -   Andre Kuiper
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   John Jobe
   Re: Division by zero   -   Arnaud Nicolet
   Re: Division by zero   -   Arnaud Nicolet
   Re: Division by zero   -   Andy Dent
    Re: Division by zero   -   Bart Silverstrim
   Re: Division by zero   -   Arnaud Nicolet
   Re: Division by zero   -   Joe Strout
   Re: Division by zero   -   Joe Strout
   Re: Division by zero   -   Joe Strout
    Re: Division by zero   -   Metsis
   Re: Division by zero   -   Charles Yeomans
   Re: Division by zero   -   Joe Huber
   Re: Division by zero   -   Frank Condello
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   Charles Yeomans
   Re: Division by zero   -   Joe Strout
   Re: Division by zero   -   Joe Strout
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   Tim Jones
   Re: Division by zero   -   Terry Ford
   Re: Division by zero   -   Tim Jones
    Re: Division by zero   -   Bart Silverstrim
     Re: Division by zero   -   Bart Silverstrim
   Re: Division by zero   -   Harrie Westphal
   Re: Division by zero   -   Tim Jones
   Re: Division by zero   -   Frank Condello
   Re: Division by zero   -   Norman Palardy
   Re: Division by zero   -   Norman Palardy
   Re: Division by zero   -   Norman Palardy
   Re: Division by zero   -   Norman Palardy
   Re: Division by zero   -   Tim Jones
   Re: Division by zero   -   Terry Ford
   Re: Division by zero   -   Arnaud Nicolet
   Re: Division by zero   -   Arnaud Nicolet
   Re: Division by zero   -   Arnaud Nicolet
   Re: Division by zero   -   Arnaud Nicolet
   Re: Division by zero   -   Tim Jones
   Re: Division by zero   -   Terry Ford
   Re: Division by zero   -   Karen
   Re: Division by zero   -   Joe Huber
   Re: Division by zero   -   Theodore H. Smith
   Re: Division by zero   -   Charles Yeomans
   Re: Division by zero   -   Theodore H. Smith
   Re: Division by zero   -   Theodore H. Smith
   Re: Division by zero   -   Theodore H. Smith
   Null debate (was Re: Division by zero)   -   Andy Dent

Division by zero
Date: 02.08.08 16:47 (Sat, 2 Aug 2008 10:47:35 -0500)
From: Harrie Westphal
I am wondering if anyone can give me a logical reason why REALbasic
allows division by zero with no exceptions being raised. Maybe it is
just my experience in programming on IBM mainframes where you would
get slapped in the face any time you tried to divide by zero.

I was helping someone find a problem with their RB program and
finally determined that the problem stemmed from a division by zero.
In further testing after discovering this I have found that a
division by zero gives the following results when printed with the
format command:

Uint8 = 255
UInt16 =565535
UInt32 ==4294967295
UInt64 = 18446744073709551615
Int8 =I-1
Int16 = -1
Int32 = 2147483647
Int64 =7-1
Integer = 2147483647
Single =DINF.00
Double =iINF.00
Currency = -0.00

These can be carried forward in further computations with no warning.
Now, I realize that good defensive programming should always check
for the possibility of dividing by zero. But it is alarming, and
disturbing, to me that RB allows you do make a mistake and not raise
an exception. I am just wondering what others think in regards to
this. Even the singles and doubles, who report INF when displayed
still allow computations to carry on with the bogus results.

=oD A Mac addict in Tennessee =h

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 02.08.08 17:24 (Sat, 02 Aug 2008 18:24:06 +0200)
From: Arnaud Nicolet
Le 2 août 08 à 17:47 (soir), Harrie Westphal a écrit:

> I am wondering if anyone can give me a logical reason why REALbasic
> allows division by zero with no exceptions being raised. Maybe it
> is just my experience in programming on IBM mainframes where you
> would get slapped in the face any time you tried to divide by zero.
>
> I was helping someone find a problem with their RB program and
> finally determined that the problem stemmed from a division by
> zero. In further testing after discovering this I have found that a
> division by zero gives the following results when printed with the
> format command:
>
> Uint8 ==> 255
> UInt16 ==> 65535
> UInt32 ==> 4294967295
> UInt64 ==> 18446744073709551615
> Int8 ==> -1
> Int16 ==> -1
> Int32 ==> 2147483647
> Int64 ==> -1
> Integer ==> 2147483647
> Single ==> INF.00
> Double ==> INF.00
> Currency ==> -0.00
>
> These can be carried forward in further computations with no
> warning. Now, I realize that good defensive programming should
> always check for the possibility of dividing by zero. But it is
> alarming, and disturbing, to me that RB allows you do make a
> mistake and not raise an exception. I am just wondering what others
> think in regards to this. Even the singles and doubles, who report
> INF when displayed still allow computations to carry on with the
> bogus results.

I think it's because an exception, in RB, is when the program cannot
continue because of something wrong (e.g: nil object, out of bounds,
stack overflow, out of memory, etc. All these force the program to
stop because something cannot be done). As for dividing by zero, it
"can" be done, it just has to be trapped by the programmer.

Seems to be the global philosophy of RB, which I understand.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 02.08.08 17:59 (Sat, 2 Aug 2008 09:59:04 -0700)
From: Joe Huber
At 10:47 AM -0500 8/2/08, Harrie Westphal wrote:
>I am wondering if anyone can give me a logical reason why REALbasic
>allows division by zero with no exceptions being raised. Maybe it is
>just my experience in programming on IBM mainframes where you would
>get slapped in the face any time you tried to divide by zero.

Hi Harry

I completely agree with you.

This has come up in the past and I believe the answer was due to
performance. RS didn't want to slow down calculations by including a
lot of error checking and exception handling code.

Personally I prefer correctness over performance any day and wish
they did pay more attention to flagging various calculation errors
like overflow, divide by zero or assignments that loose precision or
sign information.

But that's not currently how RB works... It's up to the programmer to
either avoid or detect these issues himself.

Best regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 02.08.08 18:44 (Sat, 2 Aug 2008 11:44:16 -0600)
From: Joe Strout
On Aug 2, 2008, at 10:59 AM, Joe Huber wrote:

> Personally I prefer correctness over performance any day and wish
> they did pay more attention to flagging various calculation errors
> like overflow, divide by zero or assignments that loose precision or
> sign information.

Then you should avoid the built-in data types and make your own
numeric types that do all this checking for you.

Best,
- Joe

Re: Division by zero
Date: 02.08.08 19:11 (Sat, 2 Aug 2008 11:11:47 -0700)
From: Eric Williams

On Aug 2, 2008, at 10:44 AM, Joe Strout wrote:

> On Aug 2, 2008, at 10:59 AM, Joe Huber wrote:
>
>> Personally I prefer correctness over performance any day and wish
>> they did pay more attention to flagging various calculation errors
>> like overflow, divide by zero or assignments that loose precision
>> or sign information.
>
> Then you should avoid the built-in data types and make your own
> numeric types that do all this checking for you.

Holy cow - that sounds like a pain in the toochus.

Eric Williams
Oxalyn Software
http://software.oxalyn.com/

AE Monitor
http://software.oxalyn.com/AEMonitor/

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 02.08.08 19:42 (Sat, 2 Aug 2008 14:42:03 -0400)
From: Frank Condello
On 2-Aug-08, at 1:44 PM, Joe Strout wrote:

> On Aug 2, 2008, at 10:59 AM, Joe Huber wrote:
>
>> Personally I prefer correctness over performance any day and wish
>> they did pay more attention to flagging various calculation errors
>> like overflow, divide by zero or assignments that loose precision
>> or sign information.
>
> Then you should avoid the built-in data types and make your own
> numeric types that do all this checking for you.

Assignments that result in type conversions should be warnings (at the
very least) for a language billed as "strongly typed". The recent
addition of the CType operator and posts on Aaron's blog suggest this
will be the case at some point, but yeah, I don't want more slow auto-
exception-checking for things like divide by zero shoved down my
throat either. I wouldn't object to optional debugger settings that
could be enabled for this sort of thing however.

Frank.
<http://developer.chaoticbox.com/blog/>



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 02.08.08 19:50 (Sat, 2 Aug 2008 14:50:47 -0400)
From: Charles Yeomans

On Aug 2, 2008, at 2:11 PM, Eric Williams wrote:

>
> On Aug 2, 2008, at 10:44 AM, Joe Strout wrote:
>
>> On Aug 2, 2008, at 10:59 AM, Joe Huber wrote:
>>
>>> Personally I prefer correctness over performance any day and wish
>>> they did pay more attention to flagging various calculation errors
>>> like overflow, divide by zero or assignments that loose precision
>>> or sign information.
>>
>> Then you should avoid the built-in data types and make your own
>> numeric types that do all this checking for you.
>
> Holy cow - that sounds like a pain in the toochus.
>

Actually, it would be fairly easy.

Charles Yeomans

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 02.08.08 19:57 (Sat, 2 Aug 2008 13:57:49 -0500)
From: Harrie Westphal

On Aug 2, 2008, at 11:24 AM, Arnaud Nicolet wrote:

> I think it's because an exception, in RB, is when the program
> cannot continue because of something wrong (e.g: nil object, out of
> bounds, stack overflow, out of memory, etc. All these force the
> program to stop because something cannot be done). As for dividing
> by zero, it "can" be done, it just has to be trapped by the
> programmer.

Well, in my opinion, a divide by zero should be an exception the same
as a nil object. If you try to continue on with a nil object you
abend, the same should happen with a divide by zero since to
unknowingly continue on will cause nothing but errant data. I have
never had a language allow this before.

On Aug 2, 2008, at 12:44 PM, Joe Strout wrote:
> Then you should avoid the built-in data types and make your own
> numeric types that do all this checking for you.

Yes, you can do that; however, I feel it should be built into the
compiler. As I say, I was helping someone who is not a professional
program figure out his error. Had the program raised a zero divide
exception he would never have had to call me. As it is he has been
running with these problems, has a file full of crud due to it and
wondered where all of these weird values were coming from. Myself,
having had a career programming on IBM mainframes I know to always
test divisors for zero but not everyone is going to know that.

On Aug 2, 2008, at 11:59 AM, Joe Huber wrote:
> I completely agree with you.
>
> This has come up in the past and I believe the answer was due to
> performance. RS didn't want to slow down calculations by including
> a lot of error checking and exception handling code.
>
> Personally I prefer correctness over performance any day and wish
> they did pay more attention to flagging various calculation errors
> like overflow, divide by zero or assignments that loose precision
> or sign information.

Thanks for agreeing. Todays computers are too damn fast to worry
about this. Besides, you can always add a #Pragma for turning off
zero divide checks if you want the extra kick in speed and are
willing to chance an abend the same as turning of bounds checking on
arrays. Seems simple enough to me and sure doesn't seem like it would
be a major compiler change but I am not a compiler author by any
means. I'd put in a request but it sounds like it would be fruitless
if it has existed this long.

=#D A Mac addict in Tennessee =

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

RE: Division by zero
Date: 02.08.08 21:30 (Sat, 2 Aug 2008 22:30:21 +0200)
From: Robin Lauryssen-Mitchell
> abend, the same should happen with a divide by zero since to
Abend (Abnormal End) now there's a term I haven't heard in a loooong time :)

Another aged bit-twiddler
Robin

> -----Original Message-----
> From: <email address removed> [mailto:realbasic-nug-
> <email address removed>] On Behalf Of Harrie Westphal
> Sent: 02 August 2008 20:58
> To: REALbasic NUG
> Subject: Re: Division by zero
>
> On Aug 2, 2008, at 11:24 AM, Arnaud Nicolet wrote:
>
> > I think it's because an exception, in RB, is when the program
> > cannot continue because of something wrong (e.g: nil object, out of
> > bounds, stack overflow, out of memory, etc. All these force the
> > program to stop because something cannot be done). As for dividing
> > by zero, it "can" be done, it just has to be trapped by the
> > programmer.
>
> Well, in my opinion, a divide by zero should be an exception the same
> as a nil object. If you try to continue on with a nil object you
> abend, the same should happen with a divide by zero since to
> unknowingly continue on will cause nothing but errant data. I have
> never had a language allow this before.
>
> On Aug 2, 2008, at 12:44 PM, Joe Strout wrote:
> > Then you should avoid the built-in data types and make your own
> > numeric types that do all this checking for you.
>
> Yes, you can do that; however, I feel it should be built into the
> compiler. As I say, I was helping someone who is not a professional
> program figure out his error. Had the program raised a zero divide
> exception he would never have had to call me. As it is he has been
> running with these problems, has a file full of crud due to it and
> wondered where all of these weird values were coming from. Myself,
> having had a career programming on IBM mainframes I know to always
> test divisors for zero but not everyone is going to know that.
>
> On Aug 2, 2008, at 11:59 AM, Joe Huber wrote:
> > I completely agree with you.
> >
> > This has come up in the past and I believe the answer was due to
> > performance. RS didn't want to slow down calculations by including
> > a lot of error checking and exception handling code.
> >
> > Personally I prefer correctness over performance any day and wish
> > they did pay more attention to flagging various calculation errors
> > like overflow, divide by zero or assignments that loose precision
> > or sign information.
>
> Thanks for agreeing. Todays computers are too damn fast to worry
> about this. Besides, you can always add a #Pragma for turning off
> zero divide checks if you want the extra kick in speed and are
> willing to chance an abend the same as turning of bounds checking on
> arrays. Seems simple enough to me and sure doesn't seem like it would
> be a major compiler change but I am not a compiler author by any
> means. I'd put in a request but it sounds like it would be fruitless
> if it has existed this long.
>
> =#D A Mac addict in Tennessee =>>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 01:30 (Sat, 2 Aug 2008 19:30:58 -0500)
From: Harrie Westphal

On Aug 2, 2008, at 3:30 PM, Robin Lauryssen-Mitchell wrote:

> Abend (Abnormal End) now there's a term I haven't heard in a
> loooong time :)

Hey, you gotta remember I retired from programming on IBM mainframes
where that term is the term used.
=oD A Mac addict in Tennessee =*

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 02.08.08 20:12 (Sat, 2 Aug 2008 14:12:22 -0500)
From: Harrie Westphal

On Aug 2, 2008, at 1:50 PM, Charles Yeomans wrote:

> Actually, it would be fairly easy.

Now, this, to me, is pure BS. If the reason RB doesn't do the check
of the divisor for zero is because of speed, how in the world can all
of this method writing be speed efficient.

I will agree that there should be a compiler option for turning off
the checking for those people who are working on software that
demands the greatest of speed. I don't agree however that the
compiler should offer no means of testing for zero divide.

Now, bear in mind that this comes from one of the older geezers on
this list, who started programming when 64K was huge and you had to
get an act from congress to want to run in a larger partition. Back
when you were lucky to get one turnaround a day. When you had to
write code as efficient as possible.

I know there are some out there who work on programs that demand
speed but todays machines are just too damn fast for the majority of
applications to just ignore zero divides and return JUNK for
results. The whole concept of OOPs is anti-speed efficiency to this
old guys mind; however, todays machines have the capability to
process all that extra code in what for most projects is exceptional
speed. So with all that said, why in the world does a language
totally ignore the fact that in mathematics division by zero has no
meaning.

Okay, I have said my piece. I, out of habit, always test for divisors
of zero, so I was very surprised to find out how RB treats division
by zero.

=#D A Mac addict in Tennessee =i

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 02.08.08 20:40 (Sat, 2 Aug 2008 12:40:15 -0700)
From: Terry Ford

On Aug 2, 2008, at 12:12 PM, Harrie Westphal wrote:

> Now, bear in mind that this comes from one of the older geezers on
> this list, who started programming when 64K was huge and you had to
> get an act from congress to want to run in a larger partition. Back
> when you were lucky to get one turnaround a day. When you had to
> write code as efficient as possible.

I prefer to think of us as ARCP's (Age Relative Challenged Persons). :)

Terry

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 02.08.08 20:47 (Sat, 2 Aug 2008 14:47:01 -0500)
From: Harrie Westphal

On Aug 2, 2008, at 2:40 PM, Terry Ford wrote:

> I prefer to think of us as ARCP's (Age Relative Challenged
> Persons). :)

I'll have to write that one down and then hope I can remember where I
put it.

=/D A Mac addict in Tennessee =n

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 02.08.08 21:27 (Sat, 2 Aug 2008 13:27:01 -0700)
From: Terry Ford

On Aug 2, 2008, at 12:47 PM, Harrie Westphal wrote:

>
> On Aug 2, 2008, at 2:40 PM, Terry Ford wrote:
>
>> I prefer to think of us as ARCP's (Age Relative Challenged
>> Persons). :)
>
> I'll have to write that one down and then hope I can remember where
> I put it.

What is Zero anyway. The Romans never had it or negative numbers. It
wasn't until the concept of relative values came into existence that
zero and negative values happened. Blame them Greeks I guess.

Terry

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 02.08.08 21:41 (Sat, 2 Aug 2008 13:41:18 -0700)
From: Terry Ford

On Aug 2, 2008, at 1:27 PM, Terry Ford wrote:

> What is Zero anyway. The Romans never had it or negative numbers.
> It wasn't until the concept of relative values came into existence
> that zero and negative values happened. Blame them Greeks I guess.

Sorry, I found out otherwise:

"Now the ancient Greeks began their contributions to mathematics
around the time that zero as an empty place indicator was coming into
use in Babylonian mathematics. The Greeks however did not adopt a
positional number system."

I even found references to earlier Indian calculation.

Terry


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 11:16 (Sun, 03 Aug 2008 12:16:38 +0200)
From: Jose Maria Terry Jimenez
Terry Ford escribió:
>
> On Aug 2, 2008, at 1:27 PM, Terry Ford wrote:
>
>> What is Zero anyway. The Romans never had it or negative numbers. It
>> wasn't until the concept of relative values came into existence that
>> zero and negative values happened. Blame them Greeks I guess.
>
> Sorry, I found out otherwise:
>
> "Now the ancient Greeks began their contributions to mathematics
> around the time that zero as an empty place indicator was coming into
> use in Babylonian mathematics. The Greeks however did not adopt a
> positional number system."
>
> I even found references to earlier Indian calculation.
>
> Terry
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
It seems the zero was introduced by arabian mathematic Muhammad Bin
Ahmad (Who got the idea from India)

http://www.arabicnews.com/ansub/Daily/Day/980422/1998042208.html

http://www.abc.net.au/rn/science/ss/stories/s853212.htm

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Scanned with Copfilter Version 0.84beta3a (ProxSMTP 1.6)
AntiVirus: ClamAV 0.91.2/7918 - Sun Aug 3 04:45:57 2008
by Markus Madlener @ http://www.copfilter.org

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 02.08.08 21:52 (Sat, 2 Aug 2008 16:52:36 -0400)
From: Andrew Keller
Exceptions should only be raised in exceptional situations. That's
rule number one.

Rule number two is that is that it is possible for a situation to be
too exceptional to be even attempted.

The first problem here is that dividing by zero is not mathematically
consistent, so we don't have a clear definition. Some regressions
suggest that dividing by zero should result in zero, some suggest it
should be infinity, and some suggest... wtf???

This leads some programmers to write code that does not care about
what happens when dividing by zero.

This causes different programmers to use their own mathematical
optimizations to speed up math. This causes dividing by zero to be
able to return different results in different languages (and some
different processors, too)

This leads to the conclusion that dividing by zero is too
exceptional. Writing code that requires a certain behavior when
dividing by zero creates code that is not very portable. You have no
idea what might happen on another processor. Heck, your program will
all out crash if you try to do it in C.

Dividing by zero should not be attempted because it is inconsistent in
different languages. Take the speed optimization you get when
programmers don't have to write code that cares about zero with open
arms. You'll need it if you are trying to go as fast as a math
crunching program written in C. There is always a way to write code
efficiently that doesn't try to divide by zero.

HTH -
Andrew Keller

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 02.08.08 22:17 (Sat, 2 Aug 2008 17:17:10 -0400)
From: Charles Yeomans

On Aug 2, 2008, at 4:52 PM, Andrew Keller wrote:

> Exceptions should only be raised in exceptional situations. That's
> rule number one.

And though oft-cited, it is in my opinion meaningless.

>
> Rule number two is that is that it is possible for a situation to be
> too exceptional to be even attempted.
>
> The first problem here is that dividing by zero is not
> mathematically consistent, so we don't have a clear definition.
> Some regressions suggest that dividing by zero should result in
> zero, some suggest it should be infinity, and some suggest... wtf???
>
> This leads some programmers to write code that does not care about
> what happens when dividing by zero.
>
> This causes different programmers to use their own mathematical
> optimizations to speed up math. This causes dividing by zero to be
> able to return different results in different languages (and some
> different processors, too)
>
> This leads to the conclusion that dividing by zero is too
> exceptional. Writing code that requires a certain behavior when
> dividing by zero creates code that is not very portable. You have
> no idea what might happen on another processor. Heck, your program
> will all out crash if you try to do it in C.

I think this depends on the particular implementation of C and the
processor that's executing the object code.
>
> Dividing by zero should not be attempted because it is inconsistent
> in different languages. Take the speed optimization you get when
> programmers don't have to write code that cares about zero with open
> arms. You'll need it if you are trying to go as fast as a math
> crunching program written in C. There is always a way to write code
> efficiently that doesn't try to divide by zero.
>

Where did you get the idea that C is a good math-crunching language :?

Charles Yeomans

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 00:51 (Sat, 2 Aug 2008 16:51:34 -0700)
From: Joe Huber
At 4:52 PM -0400 8/2/08, Andrew Keller wrote:
>Dividing by zero should not be attempted because it is inconsistent
>in different languages. Take the speed optimization you get when
>programmers don't have to write code that cares about zero with open
>arms. You'll need it if you are trying to go as fast as a math
>crunching program written in C. There is always a way to write code
>efficiently that doesn't try to divide by zero.

Why should an application programmer have to worry about this at
every point he does a division instead of the compiler (optionally)
handling it for him in a uniform way?

Why should the compiler gracefully handle Nil object references and
not divide by zero? I'm sure that dereferencing would run faster if
there weren't any nil object checks to slow it down.... :-)

Regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 01:49 (Sat, 2 Aug 2008 18:49:47 -0600)
From: Joe Strout
On Aug 2, 2008, at 12:11 PM, Eric Williams wrote:

>> Then you should avoid the built-in data types and make your own
>> numeric types that do all this checking for you.
>
> Holy cow - that sounds like a pain in the toochus.

Well I certainly wouldn't bother, but then I *like* speedy code, and
can't remember the last time I had a bug in my code due to overflow or
division by zero. But that's just me. The point is, if you want
slower-but-safer numeric types (which I can imagine wanting in some
situations), you can make 'em.

Best,
- Joe

Re: Division by zero
Date: 03.08.08 02:05 (Sat, 2 Aug 2008 18:05:58 -0700)
From: Joe Huber
At 6:49 PM -0600 8/2/08, Joe Strout wrote:
>I *like* speedy code, and can't remember the last time I had a bug
>in my code due to overflow or division by zero.

Without some sort of automated detection, how can you be so sure? :-)

RB already holds our hand in so many ways, and we're used to paying
for it with a bit of performance tradeoff. Better numeric safety
should at least be an option for those of us who'd like to use it.

Regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 05:09 (Sun, 3 Aug 2008 00:09:43 -0400)
From: Andrew Keller
On Aug 2, 2008, at 5:17 PM, Charles Yeomans wrote:
>
> Where did you get the idea that C is a good math-crunching language :?

Yes, I know, there are languages and libraries dedicated to math that
aren't straight C. But in my latest set of work, good is simple. I'm
not saying C is the best for math (it actually isn't), but it sure is
easy to get some simple parallel computing agent up and running in C.
Then I write the GUI in RB.

- Andrew Keller

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 15:19 (Sun, 3 Aug 2008 09:19:06 -0500)
From: Harrie Westphal

On Aug 2, 2008, at 7:49 PM, Joe Strout wrote:

> Well I certainly wouldn't bother, but then I *like* speedy code,

Joe,

I highly respect you as a person and user of REALbasic. But, I have
to chuckle when you comment about wanting speedy code and not wanting
the compiler to put in checks for division by zero. I have to chuckle
because the whole concept of Object Oriented coding is not predicated
on the fastest of code. I came from a world where OOPs had not become
prevelant, IBM mainframes. Perhaps it is in use in that environment
now, but not when I retired. I got my first taste of OOPs with RB. I
don't profess to be highly skilled at writing code in the proper OOPs
manner but when I look at code written by others and see the enormous
number of method calls with getters and setters and all of that good
stuff I see why OOPs did not exist when I first started out. It would
have gagged machines that were in existence at that time. Now with
the speed of newer machines this is no longer a problem but to
suggest that checks for zero divide would severly slow down execution
seem a bit over the top when you consider all the other stuff going
on in object oriented coding.

I too have never had a problem with going awry due to zero divides in
RB. I learned long ago to test divisors before doing the divides when
I could not be sure of the divisor being non-zero. It's just that not
checking is leaving a door open for errors that really shouldn't be
there in the first place in my mind. How many divides does a typical
program do. Certainly no where near the number of method calls that
it probably makes so what is the big deal. I guess I am just a
stubborn old IBM person and feel that they did it the correct way.

=wD A Mac addict in Tennessee =a

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 17:27 (Sun, 03 Aug 2008 09:27:03 -0700)
From: Fargo Holiday
Harrie Westphal wrote:
I got my first taste of OOPs with RB. I don't
> profess to be highly skilled at writing code in the proper OOPs manner
> but when I look at code written by others and see the enormous number of
> method calls with getters and setters and all of that good stuff I see
> why OOPs did not exist when I first started out. It would have gagged
> machines that were in existence at that time. Now with the speed of
> newer machines this is no longer a problem but to suggest that checks
> for zero divide would severly slow down execution seem a bit over the
> top when you consider all the other stuff going on in object oriented
> coding.

This strikes me as saying that because your car already has seatbelts,
smog controls, power steering, a heavy frame, and brakes, adding a drag
chute shouldn't be a problem for anyone, because the car has already
been slowed down by these other things. Never mind that it's not a
general use item, let's put it into production.

Now, normally I try not to comment on the fiestas of "I have slight
issue with how RB does something and feel that they should focus a lot
of energy on something that's not really a problem", but seriously now.
If a programmer can't do proper math or handle checking it in their
code, that's nobody's fault but their own. This isn't like creating gui
layouts in raw code, or data structures for databases, or other items
that are complex enough to warrant something built into to RB for small
developers short on time to use. It's something easy enough to implement
yourself if you need it, and if you want to share it, then share it.

Sometimes tackling a problem in programming doesn't mean insisting on a
new feature, it means doing some more programming.

Anyway, that's my thoughts on the matter.

Best of luck,
Fargo

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 17:45 (Sun, 3 Aug 2008 09:45:31 -0700)
From: Joe Huber
At 9:27 AM -0700 8/3/08, Fargo Holiday wrote:
>Sometimes tackling a problem in programming doesn't mean insisting
>on a new feature, it means doing some more programming.

So explain why RS does NIL object checking but not divide by zero
checking? It seems to me that these are directly analogous, one for
objects and the other for scalars.

And why does RB bother with bounds checking on array accesses? A good
programmer should already be accessing only existing array elements.

And how about all the other exceptions? Surely a good programmer
could prevent those too.

The point is to have bullet proof code, and to get some help from RB
when practical to know when it's not.

The CPU and FPU generally give divide by zero exceptions and
indications of overflow, because those are important things to know.
It would be good if RB could communicate those things to our apps too.

Getting an app to behave properly when everything goes right is only
20% of the work. Some people stop there. The real challenge is to get
it to behave reasonably when things aren't going right and to clearly
tell you when it has a tummy ache. It should not just continue
churning along, silently failing.

Regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 18:18 (Sun, 3 Aug 2008 12:18:28 -0500)
From: Harrie Westphal

On Aug 3, 2008, at 11:27 AM, Fargo Holiday wrote:

> Now, normally I try not to comment on the fiestas of "I have slight
> issue with how RB does something and feel that they should focus a
> lot of energy on something that's not really a problem", but
> seriously now. If a programmer can't do proper math or handle
> checking it in their code, that's nobody's fault but their own.
> This isn't like creating gui layouts in raw code, or data
> structures for databases, or other items that are complex enough to
> warrant something built into to RB for small developers short on
> time to use. It's something easy enough to implement yourself if
> you need it, and if you want to share it, then share it.

Then to your way of thinking lets get rid of bounds checking. A GOOD
programmer can certainly avoid that. Let's get rid of NIL object
checking, a GOOD programmer can certainly avoid that. And if you
screw up you will just about, for sure crash your program along the
way. Problem is with no zero divide check your program is very
unlikely to crash because the zero divide returned an acceptable
number. I just don't understand your logic in this.


=oD A Mac addict in Tennessee =t

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 18:21 (Sun, 3 Aug 2008 12:21:57 -0500)
From: Harrie Westphal

On Aug 3, 2008, at 11:45 AM, Joe Huber wrote:

> So explain why RS does NIL object checking but not divide by zero
> checking? It seems to me that these are directly analogous, one for
> objects and the other for scalars.
>
> And why does RB bother with bounds checking on array accesses? A
> good programmer should already be accessing only existing array
> elements.
>
> And how about all the other exceptions? Surely a good programmer
> could prevent those too.
>
> The point is to have bullet proof code, and to get some help from
> RB when practical to know when it's not.

Joe,

You don't know how glad I am to see that at least one person out
there agrees with me, or at least is willing to say that they agree
with me. The best of programmers can screw up. The best of languages
show them when they have screwed up, or at least give them an option
to check for screwing up.

=3D A Mac addict in Tennessee =3

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 18:22 (Sun, 3 Aug 2008 10:22:08 -0700)
From: Tim Jones
On Aug 3, 2008, at 9:45 AM, Joe Huber wrote:

> At 9:27 AM -0700 8/3/08, Fargo Holiday wrote:
>> Sometimes tackling a problem in programming doesn't mean insisting
>> on a new feature, it means doing some more programming.
>
> So explain why RS does NIL object checking but not divide by zero
> checking? It seems to me that these are directly analogous, one for
> objects and the other for scalars.
>
> And why does RB bother with bounds checking on array accesses? A
> good programmer should already be accessing only existing array
> elements.

Because accessing memory address 0 or uninitialized memory outside the
bounds of your array can cause a SEGFAULT, dividing by zero can't.
Additionally, dividing by zero is not necessarily an error as some
calculations may return "infinite" instead of an error.

As to why not add these types of checks, as an example I've got a
Montgomery Multiplication math function that I had to move to C in a
plugin as the overhead in RB (without these checks) caused a single
instance to take 48 seconds (after unrolling a series of for ... next
loops) compared to the same function requiring 4 ms in C, 14 ms in
Python, and 115 ms in TCL on my 1.5GHz PowerBook. Imagine if every
time a division occurred the runtime checked for divide by zero...

> And how about all the other exceptions? Surely a good programmer
> could prevent those too.

Absolutely. This is why almost every reference to accessing a
FolderItem always has a statement like:

If f = Nil or Not f.Exists Then
....
End If

We're all trying to be good programmers, but sometimes, a divide by
zero scenario is not necessarily an error. Therefore, if a divide by
zero is an error in what you're doing, then you should add the
overhead required. For others, to pay the penalty for that overhead
when it's not required would be too much to ask.

Sounds like a good opportunity for an Operator_IntegerDivide()
overload...

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 18:32 (Sun, 3 Aug 2008 12:32:46 -0500)
From: Harrie Westphal

On Aug 3, 2008, at 12:22 PM, Tim Jones wrote:

> We're all trying to be good programmers, but sometimes, a divide by
> zero scenario is not necessarily an error. Therefore, if a divide
> by zero is an error in what you're doing, then you should add the
> overhead required. For others, to pay the penalty for that
> overhead when it's not required would be too much to ask.

Can you give me an instance of when a divide by zero is not an error?
Particularly when the system returns a value that is totally legal to
continue on with. I'll stick with IBM's way of doing it until Hell
freezes over. You divide by zero and you are informed of the matter.

> As to why not add these types of checks, as an example I've got a
> Montgomery Multiplication math function that I had to move to C in
> a plugin as the overhead in RB (without these checks) caused a
> single instance to take 48 seconds (after unrolling a series of
> for ... next loops) compared to the same function requiring 4 ms in
> C, 14 ms in Python, and 115 ms in TCL on my 1.5GHz PowerBook.
> Imagine if every time a division occurred the runtime checked for
> divide by zero...

As I stated before, there are some people whose applications demand
the ultimate in speed. RB does not do zero divide checks and you
still had to go to an external routine. I have no problem with a
compiler directive that allows those who need the speed to turn the
checking off as you can for bounds checking.

=cD A Mac addict in Tennessee =c

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 18:41 (Sun, 03 Aug 2008 13:41:55 -0400)
From: Karen

On Aug 3, 2008, at 1:21 PM, Harrie Westphal wrote:

> You don't know how glad I am to see that at least one person out
> there agrees with me, or at least is willing to say that they agree
> with me. The best of programmers can screw up. The best of
> languages show them when they have screwed up, or at least give
> them an option to check for screwing up.

I agree too (as long as there is pragma to turn it off in final built
apps for speed). Having exceptions thrown on divide by 0 when testing/
debugging can save a lot problems when doing a lot of calculations...

But I too originally learned to program on mainframes in FORTRAN (IV
BTW), BASIC and later on VAXs in Pascal... and got my share of
division by 0 crashes for sure! And they were usually about not
considering all boundary situations. most of which I shoukd have been!

The things is these days it seems most programmers don't seem to do a
lot of numerical calcuations/scientific programming and so it affects
them less. Back in he day the majority of programming seemed to be of
that type... Now it's more of niche it seems.

- Karen


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 18:45 (Sun, 03 Aug 2008 13:45:10 -0400)
From: Karen

On Aug 3, 2008, at 1:22 PM, Tim Jones wrote:

> We're all trying to be good programmers, but sometimes, a divide by
> zero scenario is not necessarily an error.

Could you provide a reasonable example of that? Would that not be a
very rare case and one that should be coded around because it IS an
undefined mathematical operation?

- Karen

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 18:49 (Sun, 3 Aug 2008 12:49:54 -0500)
From: John Jobe
It's technically not an error... it's "meaningless". If IBM defined
it as an "error" then they have simply taken a "meaningless" aka
"undefined" result and applied the term "error" to it because it fit
their need. If you prefer to stick with any certain view until Hell
or IBM freezes over; that is entirely up to you.

4 / 0 aka
4 divide by 0 equals

The problem:
We have 4 apples and we are dividing them amongst 0 people. How many
apples does each get?

The answer:
The question is meaningless because there are no people to divide them
between. (Another option is to divide them amongst imaginary sock
monsters... the question is just as meaningless.)

boolean=(integer != (4/0)) should always result in TRUE
boolean=(integer ==4/0)) should always result in FALSE
integers always have a meaning
a divide by 0 would never have a meaning

I am at a loss to think of a specific purpose for deriving a boolean
based off a comparison between an integer and a meaningless statement,
but that doesn't mean someone doesn't or hasn't needed it.

On Aug 3, 2008, at 12:32 PM, Harrie Westphal wrote:

> Can you give me an instance of when a divide by zero is not an
> error? Particularly when the system returns a value that is totally
> legal to continue on with. I'll stick with IBM's way of doing it
> until Hell freezes over. You divide by zero and you are informed of
> the matter.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 19:01 (Sun, 3 Aug 2008 13:01:28 -0500)
From: Eric Richards

>
> Can you give me an instance of when a divide by zero is not an
> error? Particularly when the system returns a value that is totally
> legal to continue on with. I'll stick with IBM's way of doing it
> until Hell freezes over. You divide by zero and you are informed of
> the matter.
>>

Didn't hell freeze over when Apple went intel ? ;-)

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 19:18 (Sun, 3 Aug 2008 13:18:04 -0500)
From: Harrie Westphal

On Aug 3, 2008, at 1:01 PM, Eric Richards wrote:

> Didn't hell freeze over when Apple went intel ? ;-)

Almost, but not quite. Global warming had already started. ;-)

=7D A Mac addict in Tennessee =r

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 19:27 (Sun, 3 Aug 2008 13:27:20 -0500)
From: John Jobe
I created a project that contained one default editfield with
multiline enabled and one default pushbutton object.

I put this code in the pushbutton

------------
dim b as boolean
dim i as double
dim s as string

for i=-100 to 100
b=(i*4<>(i/4))
if b=TRUE then
s=s+str(i)+" TRUE"+EndOfLine()
else
s=s+str(i)+" FALSE"+EndOfLine()
end if
next

editfield.text=s
------------

Based upon execution of this code it appears that RB does handle
divide by 0 as it should. If you specifically want to check for and
disallow /0 (call it "error"); you can do so quite easily. However,
it should be noted that in your case and many cases it may be proper
to label /0 as "error", but that is not the "correct" answer. The
"correct" answer is "meaningless" or "undefined". If you put a label
other than "meaningless" or "undefined" on /0 the answer and whether
it is correct or not is specific to your circumstance.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 19:30 (Sun, 3 Aug 2008 13:30:35 -0500)
From: Harrie Westphal

On Aug 3, 2008, at 12:49 PM, John Jobe wrote:

> It's technically not an error... it's "meaningless". If IBM
> defined it as an "error" then they have simply taken a
> "meaningless" aka "undefined" result and applied the term "error"
> to it because it fit their need. If you prefer to stick with any
> certain view until Hell or IBM freezes over; that is entirely up to
> you.

Yes, it is meaningless. The problem is that RB gives you a number
that can be used in subsequent calculations. Hence, they are
violating the consequences of a zero divide. The floating points,
Single and Doubles at least print INF if displayed on the screen or
paper, but even those do not stop you from doing further
calculations. Just everything calculated from them, that stays a
Single or Float will print INF, I believe. However, move the Double
to an Int64 and you again have no indication of a problem.

There were a lot of wild data conversions that were allowed in PL/I
my main IBM language. In fact there was a whole book written as part
of the PL/I series that showed what would take place internally when
assigning the multitude of data types to one another. But, in no case
would a zero divide not raise an exception and abend the program if
you had no exception catching code.

Dim Bonkers, BadDivisor, WhatTheHeck As Int64

BadDivisor = 0
Bonkers = 1000 / BadDivisor // Bonkers is now -1
.
.
.
WhatTheHeck = Bonkers + 1

And at this point WhatTheHeck is equal to 0. Absolutely no logic in
that progression.

=cD A Mac addict in Tennessee =

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 19:44 (Sun, 3 Aug 2008 11:44:44 -0700)
From: Joe Huber
John

I don't see where you're even attempting a divide by 0 operation in your test.

Regards,
Joe Huber

At 1:27 PM -0500 8/3/08, John Jobe wrote:
>I created a project that contained one default editfield with
>multiline enabled and one default pushbutton object.
>
>I put this code in the pushbutton
>
>------------
> dim b as boolean
> dim i as double
> dim s as string
>
> for i=-100 to 100
> b=(i*4<>(i/4))
> if b=TRUE then
> s=s+str(i)+" TRUE"+EndOfLine()
> else
> s=s+str(i)+" FALSE"+EndOfLine()
> end if
> next
>
> editfield.text=s
>------------
>
>Based upon execution of this code it appears that RB does handle
>divide by 0 as it should. If you specifically want to check for and
>disallow /0 (call it "error"); you can do so quite easily. However,
>it should be noted that in your case and many cases it may be proper
>to label /0 as "error", but that is not the "correct" answer. The
>"correct" answer is "meaningless" or "undefined". If you put a
>label other than "meaningless" or "undefined" on /0 the answer and
>whether it is correct or not is specific to your circumstance.
>
>_______________________________________________
>Unsubscribe or switch delivery mode:
><http://www.realsoftware.com/support/listmanager/>
>Search the archives:
><http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 19:44 (Sun, 3 Aug 2008 13:44:52 -0500)
From: John Jobe

On Aug 3, 2008, at 1:30 PM, Harrie Westphal wrote:

>
> On Aug 3, 2008, at 12:49 PM, John Jobe wrote:
>
>> It's technically not an error... it's "meaningless". If IBM
>> defined it as an "error" then they have simply taken a
>> "meaningless" aka "undefined" result and applied the term "error"
>> to it because it fit their need. If you prefer to stick with any
>> certain view until Hell or IBM freezes over; that is entirely up to
>> you.
>
> Yes, it is meaningless. The problem is that RB gives you a number
> that can be used in subsequent calculations.

dim i as double
dim s as string

for ito 100
i=i+i/0
s=s+str(i)+endofline
next

i=i+1
s=s+str(i)

editfield1.text=s

Results in

INF
INF

which is correct.

I can do more calculations, but they do not result in numbers.

> Hence, they are violating the consequences of a zero divide.

There are no consequences unless you artificially create them.
Dividing by 0 does not cause black holes, computer melt downs, etc.
It is neither good nor evil.

You can create a "consequence" but it would only be accurate or
inaccurate within the specific confines of your problem.

I think the biggest problem here is that somewhere along the line it
has been embedded within you that /0 is somehow universally evil. It
isn't. In your specific application/usage it may be, but that is not
universal. RB is handling it correctly.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 19:47 (Sun, 3 Aug 2008 11:47:03 -0700)
From: Joe Huber
At 12:49 PM -0500 8/3/08, John Jobe wrote:
>It's technically not an error... it's "meaningless".

Attempting to "divide by 0" may not be a mathematical error, but it
is an outright error for RB to return a numerical result.

Regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:10 (Sun, 3 Aug 2008 12:10:13 -0700)
From: Terry Ford

On Aug 3, 2008, at 11:44 AM, Joe Huber wrote:

> John
>
> I don't see where you're even attempting a divide by 0 operation in
> your test.
>
> Regards,
> Joe Huber
>
> At 1:27 PM -0500 8/3/08, John Jobe wrote:
>> I created a project that contained one default editfield with
>> multiline enabled and one default pushbutton object.
>>
>> I put this code in the pushbutton
>>
>> ------------
>> dim b as boolean
>> dim i as double
>> dim s as string
>>
>> for i=-100 to 100
>> b=(i*4<>(i/4))
>> if b=TRUE then
>> s=s+str(i)+" TRUE"+EndOfLine()
>> else
>> s=s+str(i)+" FALSE"+EndOfLine()
>> end if
>> next
>>
>> editfield.text=s
>> ------------
>>
>> Based upon execution of this code it appears that RB does handle
>> divide by 0 as it should. If you specifically want to check for
>> and disallow /0 (call it "error"); you can do so quite easily.
>> However, it should be noted that in your case and many cases it
>> may be proper to label /0 as "error", but that is not the
>> "correct" answer. The "correct" answer is "meaningless" or
>> "undefined". If you put a label other than "meaningless" or
>> "undefined" on /0 the answer and whether it is correct or not is
>> specific to your circumstance.

Actually, it occurs once when i This displays "0 False" which is
what I would expect in this example.

What is significant is that he has handled the error in his code.

Terry

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:10 (Sun, 3 Aug 2008 14:10:54 -0500)
From: John Jobe
Just checked your code:

------------
Dim Bonkers, BadDivisor, WhatTheHeck As Int64

BadDivisor = 0
Bonkers = 1000 / BadDivisor // Bonkers is now -1

WhatTheHeck = Bonkers + 1

editfield1.text=str(WhatTheHeck)
--------------

This is bad! It appears to be an error with using Int64 rather than a
problem with /0 though. /0 should be allowed, but should never result
in a numeric result.

When using integers or doubles RB does not return a numeric value. My
tests have all been using integers and doubles.

It appears the error is not that RB allows /0, but rather the
implementation of Int64 is incomplete or incorrect.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:14 (Sun, 3 Aug 2008 12:14:17 -0700)
From: Terry Ford

On Aug 3, 2008, at 11:47 AM, Joe Huber wrote:

> At 12:49 PM -0500 8/3/08, John Jobe wrote:
>> It's technically not an error... it's "meaningless".
>
> Attempting to "divide by 0" may not be a mathematical error, but it
> is an outright error for RB to return a numerical result.

I agree; but what should Rb do? Crash the built app, have an
exception in the debugger, or what it does now?

Terry

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:15 (Sun, 3 Aug 2008 14:15:06 -0500)
From: Harrie Westphal

On Aug 3, 2008, at 1:44 PM, John Jobe wrote:

> There are no consequences unless you artificially create them.
> Dividing by 0 does not cause black holes, computer melt downs,
> etc. It is neither good nor evil.
>
> You can create a "consequence" but it would only be accurate or
> inaccurate within the specific confines of your problem.
>
> I think the biggest problem here is that somewhere along the line
> it has been embedded within you that /0 is somehow universally
> evil. It isn't. In your specific application/usage it may be, but
> that is not universal. RB is handling it correctly.

Yes, doubles and singles give a result of INF for divide by zero. But
the INF values are still usable in further calculations. But, use any
form of integer, unsigned integer, or currency and it is a totally
different thing since they have no means of reporting INF as the
floating point standard designed.

=GD A Mac addict in Tennessee =D

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:16 (Sun, 3 Aug 2008 14:16:49 -0500)
From: John Jobe
Actually in the program, as it is written, the /0 is not an error at
all. It is considered an important part of, a regular occurrence, and
normal within the operating parameters of the program. Actually if /0
didn't or weren't allowed to happen the program would be in a state of
error and since the /0 event is the single most important part of the
program... without it, the program would be useless.

However, the handling of /0 as applied to Int64 within RB is
incorrect. That was something I wasn't aware of until Harrie posted
the code. And that does need to be fixed.

Thank you for bugging it.

On Aug 3, 2008, at 2:10 PM, Terry Ford wrote:

>
> On Aug 3, 2008, at 11:44 AM, Joe Huber wrote:
>
> Actually, it occurs once when i This displays "0 False" which is
> what I would expect in this example.
>
> What is significant is that he has handled the error in his code.
>
> Terry

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:21 (Sun, 3 Aug 2008 12:21:42 -0700)
From: Joe Huber
At 10:22 AM -0700 8/3/08, Tim Jones wrote:
>>And why does RB bother with bounds checking on array accesses? A
>>good programmer should already be accessing only existing array
>>elements.
>
>Because accessing memory address 0 or uninitialized memory outside
>the bounds of your array can cause a SEGFAULT, dividing by zero
>can't.

Getting a SegFault is PREFERED to getting silent errors, unless your
only goal is to get your program to run and not necessarily provide
dependable results.

>Additionally, dividing by zero is not necessarily an error as some
>calculations may return "infinite" instead of an error.

And exactly how does RB return "infinite"? Infinite is NOT the same
as "really big".

>Imagine if every time a division occurred the runtime checked for
>divide by zero...

OK let's imagine that. It would be very similar to the Nil object
check that already occurs EVERYTIME you use the DOT operator. How may
DOTs do you have in your code?

And I would estimate that the overhead of checking for a zero operand
should be much much less than the division operator itself. I don't
know the specific numbers for the current Intel processors, but
previous generations would have less than 0.1% overhead. And if it's
an FPU based operation there is already an exception mechanism built
into the hardware so there's no overhead at all unless an exception
is taken.

Regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:27 (Sun, 3 Aug 2008 14:27:02 -0500)
From: John Jobe
Returning INF (or more precisely UNDEFINED) is correct.

It should be up to the programmer to decide if they want to do
anything special with INF. The program should not crash, throw an
exception, etc..

As long as any future operations on INF (+,-,*,/) also result in INF
behavior would be correct.

What Harrie has found is that when using Int64 it is possible to /0
and end with real numerical values. That is incorrect.


On Aug 3, 2008, at 2:14 PM, Terry Ford wrote:

>>
>> Attempting to "divide by 0" may not be a mathematical error, but it
>> is an outright error for RB to return a numerical result.
>
> I agree; but what should Rb do? Crash the built app, have an
> exception in the debugger, or what it does now?
>
> Terry

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:29 (Sun, 3 Aug 2008 12:29:01 -0700)
From: Joe Huber
At 12:10 PM -0700 8/3/08, Terry Ford wrote:
>Actually, it occurs once when i This displays "0 False" which is
>what I would expect in this example.
>
>What is significant is that he has handled the error in his code.

Terry

I still don't see ANYWHERE in this test where the DENOMINATOR is
zero. Sure the numerator becomes zero in the loop, but that's not the
issue in this whole thread.

I still believe the John's test is fatally flawed.

Regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:30 (Sun, 3 Aug 2008 12:30:16 -0700)
From: Tim Jones
On Aug 3, 2008, at 12:14 PM, Terry Ford wrote:

> On Aug 3, 2008, at 11:47 AM, Joe Huber wrote:
>
>> Attempting to "divide by 0" may not be a mathematical error, but it
>> is an outright error for RB to return a numerical result.
>
> I agree; but what should Rb do? Crash the built app, have an
> exception in the debugger, or what it does now?

What it does now(*). What if we're dealing with user input - should
our app die because a user entered 0 for a value that will be used as
a divisor later? Or should we, as the designer, prepare for that and
post a warning that 0 is not a valid entry? I believe that this is
one that *we* are better suited to watch out for in code.

(*)I've submitted a bug report about the inconsistency in the Int
class numeric types in this situation.

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:36 (Sun, 3 Aug 2008 14:36:46 -0500)
From: Harrie Westphal

On Aug 3, 2008, at 2:10 PM, John Jobe wrote:
> When using integers or doubles RB does not return a numeric value.
> My tests have all been using integers and doubles.

That sure isn't what I am seeing. Dual 2.3Ghz Power PC, Mac 10.4.11
and the following code with the results shown in a multiline
statictext. The second half is just to show that after the zero
divide the value is still usable in computations.

Dim u8, zu8 As UInt8
Dim u16, zu16 As UInt16
Dim u32, zu32 As UInt32
Dim u64, zu64 As UInt64
Dim i8, zi8 As Int8
Dim i16, zi16 As Int16
Dim i32, zi32 As Int32
Dim i64, zi64 As Int64
Dim oint, zoint As Integer
Dim sng, zsng As Single
Dim dbl, zdbl As Double
Dim cur, zcur As Currency
Dim s As String

zu8 zu16 = 0
zu32 = 0
zu64 = 0
zi8 = 0
zi16 = 0
zi32 = 0
zi64 = 0
zoint = 0
zsng = 0.0
zdbl = 0.0
zcur = 0.00
u8 = 10/zu8
u16 = 10/zu16
u32 = 10/zu32
u64 = 1000/zu64
i8 = 10/zi8
i16 = 10/zi16
i32 = 10/zi32
i64 = 10/zi64
oint = 10/zoint
sng = 10.0/zsng
dbl = 10.0/zdbl
cur = 10.00/zcur
s ="Result of zero divide" + EndOfLine _
+" Uint8 =v" + format(u8, "-#") + EndOfLine _
+ " UInt16 =," + format(u16, "-#") + EndOfLine _
+ " UInt32 =(" + format(u32, "-#") + EndOfLine _
+ " Uint64 =r" + Format(u64, "-#") + EndOfLine _
+ " Int8 ="" + format(i8, "-#") + EndOfLine _
+ " Int16 =D" + format(i16, "-#") + EndOfLine _
+ " Int32 = " + Format(i32, "-#") + EndOfLine _
+ " Int64 =n" + Format(i64, "-#") + EndOfLine _
+ " Integer = " + Format(oint, "-#") + EndOfLine _
+ " Single = " + Format(sng, "-#.00") + EndOfLine _
+ " Double =+" + Format(dbl, "-#.00") + EndOfLine _
+ " Currency = " + Format(cur, "-#.00") + EndOfLine + EndOfLine

u8 = u8 + 1
u16 = u16 + 1
u32 = u32 + 1
u64 = u64 + 1
i8 = i8 + 1
i16 = i16 + 1
i32 = i32 + 1
i64 = i64 + 1
oint = oint + 1
sng = sng + 1
dbl = dbl + 1
cur = cur + 1
i64 = dbl

s = s + "After using zero divide value in further calcs" +
EndOfLine _
+" Uint8 =+" + format(u8, "-#") + EndOfLine _
+ " UInt16 =v" + format(u16, "-#") + EndOfLine _
+ " UInt32 =i" + format(U32, "-#") + EndOfLine _
+ " Uint64 = " + Format(u64, "-#") + EndOfLine _
+ " Int8 = " + format(i8, "-#") + EndOfLine _
+ " Int16 =e" + format(i16, "-#") + EndOfLine _
+ " Int32 =O" + Format(i32, "-#") + EndOfLine _
+ " Int64 =n" + Format(i64, "-#") + EndOfLine _
+ " Integer = " + Format(oint, "-#") + EndOfLine _
+ " Single = " + Format(sng, "-#.00") + EndOfLine _
+ " Double = " + Format(dbl, "-#.00") + EndOfLine + EndOfLine

stResults.Text = s

=#D A Mac addict in Tennessee =t

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:38 (Sun, 3 Aug 2008 12:38:26 -0700)
From: Joe Huber
At 12:14 PM -0700 8/3/08, Terry Ford wrote:
>On Aug 3, 2008, at 11:47 AM, Joe Huber wrote:
>
>>At 12:49 PM -0500 8/3/08, John Jobe wrote:
>>>It's technically not an error... it's "meaningless".
>>
>>Attempting to "divide by 0" may not be a mathematical error, but it
>>is an outright error for RB to return a numerical result.
>
>I agree; but what should Rb do? Crash the built app, have an
>exception in the debugger, or what it does now?

It should behave exactly like a NilObjectException or an OutOfBounds
exception. It should fire a DivideByZero exception and there should
be a pragma to disable them in speed critical code segments.

And it's hard for me to imagine why anyone would be against making
this part of RB consistent with similar mechanisms already in place.

Regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:38 (Sun, 3 Aug 2008 14:38:39 -0500)
From: John Jobe

On Aug 3, 2008, at 2:21 PM, Joe Huber wrote:
>
>> Additionally, dividing by zero is not necessarily an error as some
>> calculations may return "infinite" instead of an error.
>
> And exactly how does RB return "infinite"? Infinite is NOT the same
> as "really big".

In at least some cases (as with integers and doubles) it returns INF.

>> Imagine if every time a division occurred the runtime checked for
>> divide by zero...
>
> OK let's imagine that. It would be very similar to the Nil object
> check that already occurs EVERYTIME you use the DOT operator. How
> may DOTs do you have in your code?
>
> And I would estimate that the overhead of checking for a zero
> operand should be much much less than the division operator itself.

Even if /0 checks added no overhead I would suggest that they should
not be stopped. Returning the proper answer (INF) is preferred to
disallowing the operation.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:40 (Sun, 3 Aug 2008 14:40:57 -0500)
From: John Jobe
Run this

dim b as boolean
dim i as double
dim s as string

for i=-100 to 100
b=(i<>(i/0)) // <--- this is where we divide by zero
if b=TRUE then
s=s+str(i)+" TRUE"+EndOfLine()
else
s=s+str(i)+" FALSE"+EndOfLine()
end if
next

editfield1.text=s

At this point is there a flaw? Is the divide by 0 an error? Is the
result correct?

On Aug 3, 2008, at 2:29 PM, Joe Huber wrote:
>
> I still don't see ANYWHERE in this test where the DENOMINATOR is
> zero. Sure the numerator becomes zero in the loop, but that's not
> the issue in this whole thread.
>
> I still believe the John's test is fatally flawed.
>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:41 (Sun, 3 Aug 2008 12:41:37 -0700)
From: Joe Huber
At 2:27 PM -0500 8/3/08, John Jobe wrote:
>Returning INF (or more precisely UNDEFINED) is correct.
>
>It should be up to the programmer to decide if they want to do
>anything special with INF. The program should not crash, throw an
>exception, etc..
>
>As long as any future operations on INF (+,-,*,/) also result in INF
>behavior would be correct.

And exactly how do any of the integer data types return an INF?

Regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:43 (Sun, 03 Aug 2008 15:43:36 -0400)
From: Karen

On Aug 3, 2008, at 3:30 PM, Tim Jones wrote:

> What it does now(*). What if we're dealing with user input -
> should our app die because a user entered 0 for a value that will
> be used as a divisor later? Or should we, as the designer, prepare
> for that and post a warning that 0 is not a valid entry? I believe
> that this is one that *we* are better suited to watch out for in code.

User input should always be checked for validity IMO.

The real issue is with division intermediate steps in complex multi-
step calculations. Division by 0 is rarely if ever done intentionally
and is a mathematically undefined operation. Having a complier switch
for checking for it and rising exceptions would be best... The
switch IMO should be on for debugging and testing to report such
errors and COULD be turned off for final build for speed when needed.

While I don't expect that to be close to the top of RSes to-do list,
I don't understand the resistance to the idea in principle from some
here. It does not have to cause speed loss and would help make your
code more robust.

So what is the logical reason for the opposition?

- Karen

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:47 (Sun, 03 Aug 2008 15:47:02 -0400)
From: Karen

On Aug 3, 2008, at 3:38 PM, John Jobe wrote:

>
> Even if /0 checks added no overhead I would suggest that they
> should not be stopped. Returning the proper answer (INF) is
> preferred to disallowing the operation.
>

If it throws an exception you can assign what you wish there... Or if
you check in code first (because you want it allowed there) you could
also set it to whatever you want

- Karen

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:50 (Sun, 3 Aug 2008 14:50:22 -0500)
From: John Jobe
This works right

dim i as double

iP i=i/0
i=i+1
i=i-5
i=i*6
editfield1.text=str(i)

Answer is INF and seems to properly stay INF no matter what we do with
it.

However, this behavior is not present across data types (even lowly
integer seems to have problems).


On Aug 3, 2008, at 2:36 PM, Harrie Westphal wrote:

>
> On Aug 3, 2008, at 2:10 PM, John Jobe wrote:
>> When using integers or doubles RB does not return a numeric value.
>> My tests have all been using integers and doubles.
>
> That sure isn't what I am seeing. Dual 2.3Ghz Power PC, Mac 10.4.11
> and the following code with the results shown in a multiline
> statictext. The second half is just to show that after the zero
> divide the value is still usable in computations.
>
> Dim u8, zu8 As UInt8
> Dim u16, zu16 As UInt16
> Dim u32, zu32 As UInt32
> Dim u64, zu64 As UInt64
> Dim i8, zi8 As Int8
> Dim i16, zi16 As Int16
> Dim i32, zi32 As Int32
> Dim i64, zi64 As Int64
> Dim oint, zoint As Integer
> Dim sng, zsng As Single
> Dim dbl, zdbl As Double
> Dim cur, zcur As Currency
> Dim s As String
>
> zu8> zu16 = 0
> zu32 = 0
> zu64 = 0
> zi8 = 0
> zi16 = 0
> zi32 = 0
> zi64 = 0
> zoint = 0
> zsng = 0.0
> zdbl = 0.0
> zcur = 0.00
> u8 = 10/zu8
> u16 = 10/zu16
> u32 = 10/zu32
> u64 = 1000/zu64
> i8 = 10/zi8
> i16 = 10/zi16
> i32 = 10/zi32
> i64 = 10/zi64
> oint = 10/zoint
> sng = 10.0/zsng
> dbl = 10.0/zdbl
> cur = 10.00/zcur
> s ="Result of zero divide" + EndOfLine _
> +" Uint8 =e" + format(u8, "-#") + EndOfLine _
> + " UInt16 ==" + format(u16, "-#") + EndOfLine _
> + " UInt32 ==" + format(u32, "-#") + EndOfLine _
> + " Uint64 =t" + Format(u64, "-#") + EndOfLine _
> + " Int8 = " + format(i8, "-#") + EndOfLine _
> + " Int16 =>" + format(i16, "-#") + EndOfLine _
> + " Int32 =_" + Format(i32, "-#") + EndOfLine _
> + " Int64 =i" + Format(i64, "-#") + EndOfLine _
> + " Integer =f" + Format(oint, "-#") + EndOfLine _
> + " Single =d" + Format(sng, "-#.00") + EndOfLine _
> + " Double = " + Format(dbl, "-#.00") + EndOfLine _
> + " Currency = " + Format(cur, "-#.00") + EndOfLine + EndOfLine
>
> u8 = u8 + 1
> u16 = u16 + 1
> u32 = u32 + 1
> u64 = u64 + 1
> i8 = i8 + 1
> i16 = i16 + 1
> i32 = i32 + 1
> i64 = i64 + 1
> oint = oint + 1
> sng = sng + 1
> dbl = dbl + 1
> cur = cur + 1
> i64 = dbl
>
> s = s + "After using zero divide value in further calcs" +
> EndOfLine _
> +" Uint8 = " + format(u8, "-#") + EndOfLine _
> + " UInt16 = " + format(u16, "-#") + EndOfLine _
> + " UInt32 =L" + format(U32, "-#") + EndOfLine _
> + " Uint64 =f" + Format(u64, "-#") + EndOfLine _
> + " Int8 =+" + format(i8, "-#") + EndOfLine _
> + " Int16 ="" + format(i16, "-#") + EndOfLine _
> + " Int32 =u" + Format(i32, "-#") + EndOfLine _
> + " Int64 =a" + Format(i64, "-#") + EndOfLine _
> + " Integer =m" + Format(oint, "-#") + EndOfLine _
> + " Single =o" + Format(sng, "-#.00") + EndOfLine _
> + " Double =o" + Format(dbl, "-#.00") + EndOfLine + EndOfLine
>
> stResults.Text = s
>
> =gD A Mac addict in Tennessee =>>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 20:58 (Sun, 3 Aug 2008 14:58:55 -0500)
From: Harrie Westphal

On Aug 3, 2008, at 2:30 PM, Tim Jones wrote:

> What it does now(*). What if we're dealing with user input -
> should our app die because a user entered 0 for a value that will
> be used as a divisor later? Or should we, as the designer, prepare
> for that and post a warning that 0 is not a valid entry? I believe
> that this is one that *we* are better suited to watch out for in code.

Totally agree. That is what we should do. We should write defensive
code and never allow the division by zero in the first place. But,
what about that case where you mess up and forget to perform the
check. Is it right for RB to return a totally bogus value and then
allow any further computations using that number to carry forward.
With the right equations involved the error could produce results
that are not off enough to raise an immediate alarm and hence carry
forward for some time to come.

I abhor that fact that something like that can happen when there is
absolutely no good reason for the language to allow it. Sure, if you
add that in now it could cause a lot of programs out there to hiccup.
But, they were broken programs in the first place. Better finally
catch the error than to allow it to carry on forever. This is the
kind of error that can lurk for weeks, months, even years before it
jumps out and bites the user. Depending on the field this application
is supporting it could be very serious.

=sD A Mac addict in Tennessee =t

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 21:00 (Sun, 3 Aug 2008 15:00:59 -0500)
From: Harrie Westphal

On Aug 3, 2008, at 2:41 PM, Joe Huber wrote:

> And exactly how do any of the integer data types return an INF?

Agreed, that is something the authors of floating point took into
consideration in the design. Integers, unsigned integers and currency
values have no such capability.

=kD A Mac addict in Tennessee =_

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 21:09 (Sun, 3 Aug 2008 15:09:35 -0500)
From: John Jobe
Yep, you are right. Although I strongly believe /0 shouldn't
automatically be disallowed. RBs handling of this in MOST cases is a
mess.

On Aug 3, 2008, at 3:00 PM, Harrie Westphal wrote:

> Agreed, that is something the authors of floating point took into
> consideration in the design. Integers, unsigned integers and
> currency values have no such capability.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 21:16 (Sun, 3 Aug 2008 13:16:47 -0700)
From: Joe Huber
John

Thanks for fixing your test so it finally involves a divide by zero.

But I don't see how showing that (i<>(i/0)) proves that (i/0) is
returning an appropriate value. It just proves that it doesn't return
i. If (i/0) always returned some big number outside your test range
of -100 to 100 then your test would show the same results.

Guess what it does! For integer numbers (i/0) always returns
2147483648. So either we've solved the long pondered div by zero
question and now we can tell the world that (i/0) = 2147483648, or RB
has generated an error.

Try this slight enhancement of your test program.

dim b as boolean
dim i, result as integer
dim s as string

for i=-10 to 10
b=(i<>(i/0)) // <--- this is where we divide by zero
result = (i/0)
if b=TRUE then
s=s+str(i)+" TRUE "+ format(result, "0.0")+EndOfLine()
else
s=s+str(i)+" FALSE "+ format(result, "0.0")+EndOfLine()
end if
next

editfield1.text=s

Result does not return "undefined", not "Nan" nor "meaningless".
There is no encoding for those states in an integer data type. RB
returns 2147483648, which may be its closest choice but is blatantly
wrong nevertheless.

So RB needs a better way to communicate the result of integer divide by zero.

I propose a DivByZero exception, what approach do you think is appropriate?

Regards,
Joe Huber



At 2:40 PM -0500 8/3/08, John Jobe wrote:
>Run this
>
> dim b as boolean
> dim i as double
> dim s as string
>
> for i=-100 to 100
> b=(i<>(i/0)) // <--- this is where we divide by zero
> if b=TRUE then
> s=s+str(i)+" TRUE"+EndOfLine()
> else
> s=s+str(i)+" FALSE"+EndOfLine()
> end if
> next
>
> editfield1.text=s
>
>At this point is there a flaw? Is the divide by 0 an error? Is the
>result correct?
>
>On Aug 3, 2008, at 2:29 PM, Joe Huber wrote:
>>
>>I still don't see ANYWHERE in this test where the DENOMINATOR is
>>zero. Sure the numerator becomes zero in the loop, but that's not
>>the issue in this whole thread.
>>
>>I still believe the John's test is fatally flawed.
>>
>_______________________________________________
>Unsubscribe or switch delivery mode:
><http://www.realsoftware.com/support/listmanager/>
>Search the archives:
><http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 21:34 (Sun, 03 Aug 2008 22:34:11 +0200)
From: Arnaud Nicolet
Le 3 août 08 à 21:43 (soir), Karen a écrit:

> On Aug 3, 2008, at 3:30 PM, Tim Jones wrote:
>
>> What it does now(*). What if we're dealing with user input -
>> should our app die because a user entered 0 for a value that will
>> be used as a divisor later? Or should we, as the designer,
>> prepare for that and post a warning that 0 is not a valid entry?
>> I believe that this is one that *we* are better suited to watch
>> out for in code.
>
> User input should always be checked for validity IMO.
>
> The real issue is with division intermediate steps in complex multi-
> step calculations. Division by 0 is rarely if ever done
> intentionally and is a mathematically undefined operation. Having a
> complier switch for checking for it and rising exceptions would be
> best... The switch IMO should be on for debugging and testing to
> report such errors and COULD be turned off for final build for
> speed when needed.
>
> While I don't expect that to be close to the top of RSes to-do
> list, I don't understand the resistance to the idea in principle
> from some here. It does not have to cause speed loss and would help
> make your code more robust.
>
> So what is the logical reason for the opposition?

My thoughts:
an exception is something raised when the OS can't do what we ask it
to do (either a bad memory access, a stack overflow or things like
that). Dividing by zero does not make your app crashing, so it should
not throw an exception since they are made for unsupported-by-the-
computer operations.
(like in Mac OS where negative errors don't make the app crashing
while positive ones are not even catchable by the app).
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 21:36 (Sun, 03 Aug 2008 22:36:36 +0200)
From: Arnaud Nicolet
Le 3 août 08 à 21:38 (soir), Joe Huber a écrit:

> At 12:14 PM -0700 8/3/08, Terry Ford wrote:
>> On Aug 3, 2008, at 11:47 AM, Joe Huber wrote:
>>
>>> At 12:49 PM -0500 8/3/08, John Jobe wrote:
>>>> It's technically not an error... it's "meaningless".
>>>
>>> Attempting to "divide by 0" may not be a mathematical error, but
>>> it is an outright error for RB to return a numerical result.
>>
>> I agree; but what should Rb do? Crash the built app, have an
>> exception in the debugger, or what it does now?
>
> It should behave exactly like a NilObjectException or an
> OutOfBounds exception. It should fire a DivideByZero exception and
> there should be a pragma to disable them in speed critical code
> segments.

Sorry, but it should not. Exceptions aren't designed to be thrown
when you simply don't want the obtained result. They are thrown
because something went wrong with the OS handling.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 21:39 (Sun, 03 Aug 2008 22:39:26 +0200)
From: Arnaud Nicolet
Le 3 août 08 à 22:16 (soir), Joe Huber a écrit:

> Guess what it does! For integer numbers (i/0) always returns
> 2147483648. So either we've solved the long pondered div by zero
> question and now we can tell the world that (i/0) = 2147483648, or
> RB has generated an error.

2147483648 is the highest integer value. Since x/0 results in
infinite, the closer integer is indeed 2147483648. Instead, the
programmer should check in code that the denominator is not 0 (is
that really so hard to do?). This is a general rule, like the fact
that you should always check if a file exists before opening it!
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 21:52 (Sun, 3 Aug 2008 15:52:04 -0500)
From: Harrie Westphal

On Aug 3, 2008, at 3:34 PM, Arnaud Nicolet wrote:

> My thoughts:
> an exception is something raised when the OS can't do what we ask
> it to do (either a bad memory access, a stack overflow or things
> like that). Dividing by zero does not make your app crashing, so it
> should not throw an exception since they are made for unsupported-
> by-the-computer operations.

The app does not crash because the person writing the code for this
part of the RB compiler appears to have decided to return a number
for an illegal operation. Division by zero is illegal. There is no
number represented by division by zero and therefore it is better for
the COMPILER to insert code to raise an exception in this case.
Infinity isn't a number, in my mind, it is a concept.

If you use the pragma to turn off bounds checking and dim an array to
have 100 elements you can put something in element 101, or 106, or
203. As long as the address generated by the element number does not
exceed the storage boundaries of your application the program will
store the value and continue on. If there were no bounds checking you
would ultimately get some weird things to happen. Dividing by zero
and returning a value and continuing on is no different in my mind.

=3D A Mac addict in Tennessee =C

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 21:54 (Sun, 3 Aug 2008 15:54:38 -0500)
From: Harrie Westphal

On Aug 3, 2008, at 3:39 PM, Arnaud Nicolet wrote:

> 2147483648 is the highest integer value. Since x/0 results in
> infinite, the closer integer is indeed 2147483648. Instead, the
> programmer should check in code that the denominator is not 0 (is
> that really so hard to do?). This is a general rule, like the fact
> that you should always check if a file exists before opening it!

Arnaud,

I don't actually wish this upon you, but there is a chance that
someday you will write a routine that fails to check a divisor for
zero and series consequences will result due to that momentary loss
of thought. Perhaps if the consequences were serious enough you would
understand where those of us on the other side of the fence are
coming from.


=oD A Mac addict in Tennessee =s

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 22:03 (Sun, 3 Aug 2008 16:03:24 -0500)
From: John Jobe

On Aug 3, 2008, at 3:52 PM, Harrie Westphal wrote:
> Infinity isn't a number

Yeah, "infinity" is only truly valid in certain contexts with /0.
UNDEFINED or MEANINGLESS is the proper answer for other contexts. For
RB, what we need is a descriptive term that we can check for (when
needed) that is generic enough to fit regular needs within the context
of RB. That could be something as simple as DIVBYZERO. If all
numeric data types returned DIVBYZERO (much as INF is returned for
doubles) when a /0 operation has happened and there were set rules
for /0 within the RB context (like once we arrive at DIVBYZERO the
value can not be changed) the problem is pretty much solved.



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 22:12 (Sun, 03 Aug 2008 23:12:26 +0200)
From: Arnaud Nicolet
Le 3 août 08 à 22:52 (soir), Harrie Westphal a écrit:

> On Aug 3, 2008, at 3:34 PM, Arnaud Nicolet wrote:
>
>> My thoughts:
>> an exception is something raised when the OS can't do what we ask
>> it to do (either a bad memory access, a stack overflow or things
>> like that). Dividing by zero does not make your app crashing, so
>> it should not throw an exception since they are made for
>> unsupported-by-the-computer operations.
>
> The app does not crash because the person writing the code for this
> part of the RB compiler appears to have decided to return a number
> for an illegal operation. Division by zero is illegal. There is no
> number represented by division by zero and therefore it is better
> for the COMPILER to insert code to raise an exception in this case.
> Infinity isn't a number, in my mind, it is a concept.

I'm not sure this person actually did something special. It's
certainly the default returned value by the... <unknown english term
here referencing the component that computes numbers in the computer>.
So, getting the square root of -24, RB should also throw an
exception, you'd think?

> If you use the pragma to turn off bounds checking and dim an array
> to have 100 elements you can put something in element 101, or 106,
> or 203. As long as the address generated by the element number does
> not exceed the storage boundaries of your application the program
> will store the value and continue on. If there were no bounds
> checking you would ultimately get some weird things to happen.
> Dividing by zero and returning a value and continuing on is no
> different in my mind.

Ah, didn't know that (never had to use pragma, in fact).
I'm not against having a pragma such as to allow an exception to be
thrown when dividing by zero (through I'd be very disappointed
because it's not what exceptions are made for), as long as the
behaviour of RB defaults to "no check".
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 22:24 (Sun, 03 Aug 2008 23:24:08 +0200)
From: Arnaud Nicolet
Le 3 août 08 à 22:54 (soir), Harrie Westphal a écrit:

> On Aug 3, 2008, at 3:39 PM, Arnaud Nicolet wrote:
>
>> 2147483648 is the highest integer value. Since x/0 results in
>> infinite, the closer integer is indeed 2147483648. Instead, the
>> programmer should check in code that the denominator is not 0 (is
>> that really so hard to do?). This is a general rule, like the fact
>> that you should always check if a file exists before opening it!
>
> Arnaud,
>
> I don't actually wish this upon you, but there is a chance that
> someday you will write a routine that fails to check a divisor for
> zero and series consequences will result due to that momentary loss
> of thought. Perhaps if the consequences were serious enough you
> would understand where those of us on the other side of the fence
> are coming from.

Trust me, I know those loss of thoughts are a pain. But, generally,
as soon as I write "/", I think about the fact that dividing by zero
is a special case (thought I sometimes forget to handle that
immediately, going on the next line).

I think, if I should make an application with caution (such as
medical ones), I would be so worried about things that can be wrong
that I would think, sooner or later, about the division by zero.

Well, I can understand that forgetting such a check can cause a bad
effect, but anything in an application can go wrong (deleting the
wrong file, hanging other processes, causing write failures; all
these things aren't causing an exception either). For these facts,
there are lasterrorcode properties set by the system. The programmer
has to watch them in order to know that, for instance, a file has
actually been copied. All that to say that, again in my opinion,
anything should be checked, it's the principle of programming.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 22:26 (Sun, 03 Aug 2008 23:26:33 +0200)
From: Arnaud Nicolet
Le 3 août 08 à 23:03 (soir), John Jobe a écrit:

> On Aug 3, 2008, at 3:52 PM, Harrie Westphal wrote:
>> Infinity isn't a number
>
> Yeah, "infinity" is only truly valid in certain contexts with /0.
> UNDEFINED or MEANINGLESS is the proper answer for other contexts.
> For RB, what we need is a descriptive term that we can check for
> (when needed) that is generic enough to fit regular needs within
> the context of RB. That could be something as simple as
> DIVBYZERO. If all numeric data types returned DIVBYZERO (much as
> INF is returned for doubles) when a /0 operation has happened and
> there were set rules for /0 within the RB context (like once we
> arrive at DIVBYZERO the value can not be changed) the problem is
> pretty much solved.

If you check wether an integer has the value of 'DIVBYZERO', why not
simply checking if it is 2147483648?
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 22:33 (Sun, 03 Aug 2008 17:33:48 -0400)
From: Karen

On Aug 3, 2008, at 5:26 PM, Arnaud Nicolet wrote:

> If you check wether an integer has the value of 'DIVBYZERO', why
> not simply checking if it is 2147483648?

Because that IS a valid integer that might be a legitimate results
depending on the integer datatypes involved.

- Karen

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 22:35 (Sun, 3 Aug 2008 14:35:30 -0700)
From: Joe Huber
At 2:50 PM -0500 8/3/08, John Jobe wrote:
>this behavior is not present across data types (even lowly integer
>seems to have problems).

Only Double and Single floating point data types have a way to encode
the Inf and NaN states, and so all other numeric data types would
have this problem. Hence way we've been advocating an out of band
mechanism like exceptions to handle it better.

Regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 23:17 (Mon, 04 Aug 2008 00:17:55 +0200)
From: Andre Kuiper
I agree full 100% with Joe and Harrie, there must an exception being raised.
Especially because all kinds of 'automatic' type conversions are taking
place, so if you do a test with doubles using str-function you don't
even know if you see the result of the type conversion of the double to
a single float that is shown by the str-function, do you test with the
format function, all datatypes are converted to doubles, val-function
returns a double, "0.0" (without the quotes) is that a single or a
double, what about expressions with several datatypes in it, what is the
exact value of the zerodivider, look at it in the binary representation,
you could be surprised.
IMO if the system isn't able to provide an error / exception for a
division by zero how can you as user of that system?
The performance issue as mentioned earlier is IMO neglectable, if
correct use is made of the aritmetic units of the processors, most of
the time its no more than a check for one bit switching value.
Regards, Andre

Joe Huber schreef:
> At 2:50 PM -0500 8/3/08, John Jobe wrote:
>> this behavior is not present across data types (even lowly integer
>> seems to have problems).
>
> Only Double and Single floating point data types have a way to encode
> the Inf and NaN states, and so all other numeric data types would have
> this problem. Hence way we've been advocating an out of band mechanism
> like exceptions to handle it better.
>
> Regards,
> Joe Huber
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 22:37 (Sun, 03 Aug 2008 23:37:50 +0200)
From: Arnaud Nicolet
Le 3 août 08 à 23:33 (soir), Karen a écrit:

> On Aug 3, 2008, at 5:26 PM, Arnaud Nicolet wrote:
>
>> If you check wether an integer has the value of 'DIVBYZERO', why
>> not simply checking if it is 2147483648?
>
> Because that IS a valid integer that might be a legitimate results
> depending on the integer datatypes involved.

Yes, but since it's the highest available, you should have a clue on
why it has this value (you can't easily get that number by chance).
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 22:44 (Sun, 3 Aug 2008 16:44:33 -0500)
From: John Jobe
Is 2147483648 guaranteed to always mean a /0 has happened?

Could a person arrive at 2147483648 without doing a /0?

Can a person perform math on the value 2147483648?

If a value was converted to the label DIVBYZERO (in much the same way
we end up with INF when doing a /0 on doubles) it would be clear that
you arrived at that value because of a /0. The only way to arrive at
that value would be to do a /0. And it should be setup so that once a
value is set to DIVBYZERO any further operations on the DIVBYZERO
result in DIVBYZERO.

If we are going to return values they should be correct and behave
correctly.

I get what you are saying though.

On Aug 3, 2008, at 4:26 PM, Arnaud Nicolet wrote:
>
> If you check wether an integer has the value of 'DIVBYZERO', why not
> simply checking if it is 2147483648?

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 22:46 (Sun, 3 Aug 2008 16:46:41 -0500)
From: Harrie Westphal

On Aug 3, 2008, at 4:26 PM, Arnaud Nicolet wrote:

> If you check wether an integer has the value of 'DIVBYZERO', why
> not simply checking if it is 2147483648?

Because that number could be a proper value. Arnaud, I believe that
there is only one thing that you and I can agree on and that is to
agree that we disagree on this subject. In my mind I cannot for the
life of me understand your fear of having the compiler raise an
exception for dividing by zero like it ""automatically" does for
array bounds. It appears that you cannot understand why I think it
should be done. Don't fret, seems like, at least in the way of
respondents, that there are a lot more people taking your side on
this issue.

You and I will both hopefully remember to check every divisor for
zero so that this never becomes an issue in our code. Personally I no
longer write code other than for myself and friends so I have no
consequences to worry about should I once again prove myself human
and screw up. Yeah, my friend may cuss at me, but more than likely,
somewhere along the line I have been called worse. ;-)

=sD A Mac addict in Tennessee =_

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 22:52 (Sun, 03 Aug 2008 23:52:29 +0200)
From: Arnaud Nicolet
Le 3 août 08 à 23:44 (soir), John Jobe a écrit:

> Is 2147483648 guaranteed to always mean a /0 has happened?
> Could a person arrive at 2147483648 without doing a /0?
> Can a person perform math on the value 2147483648?

Correct.

> If a value was converted to the label DIVBYZERO (in much the same
> way we end up with INF when doing a /0 on doubles) it would be
> clear that you arrived at that value because of a /0. The only way
> to arrive at that value would be to do a /0. And it should be
> setup so that once a value is set to DIVBYZERO any further
> operations on the DIVBYZERO result in DIVBYZERO.

Ok, I see this value as being like a constant (it has a value behind
its meaning, so why not using the value directly?), but, what do you
choose to be its value? It has to fit in an integer (or whatever
datatype).

> If we are going to return values they should be correct and behave
> correctly.

Agreed, but, again, is DIVBYZERO a value understood by anyone who
will call your function?

> I get what you are saying though.

And vice-versa ;-)
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 23:04 (Mon, 04 Aug 2008 00:04:44 +0200)
From: Arnaud Nicolet
Le 3 août 08 à 23:46 (soir), Harrie Westphal a écrit:

> On Aug 3, 2008, at 4:26 PM, Arnaud Nicolet wrote:
>
>> If you check wether an integer has the value of 'DIVBYZERO', why
>> not simply checking if it is 2147483648?
>
> Because that number could be a proper value. Arnaud, I believe that
> there is only one thing that you and I can agree on and that is to
> agree that we disagree on this subject. In my mind I cannot for the
> life of me understand your fear of having the compiler raise an
> exception for dividing by zero like it ""automatically" does for
> array bounds. It appears that you cannot understand why I think it
> should be done. Don't fret, seems like, at least in the way of
> respondents, that there are a lot more people taking your side on
> this issue.

Well, I think it's simply a matter of logic. What is an exception?
It's something that happen when the computer encounters an error.
Dividing by zero "can" be done at the level of the CPU, so an
exception is not logical.

Another example: have you ever tried this?:
dim i As Integer

i=2147483647
i=i+1

In the debugger, i is now equal to -2147483648. I have the feeling
that it's mathematically wrong... But it's not illegal from a CPU's
point of view. In the opposite, accessing the properties of an object
that has not been instantiated can't be done, it's impossible, even
by the computer. Same goes for when there is not enough free memory,
etc.

In my opinion, programming should be strict (like the fact that RB is
a strong-typed language, where you can't say 'dim i As integer="My
string"+true-RGB(24,233,46)', which I'd find ridiculous by the
way ;-) ). If you want something that does everything for you and
you just have to tell it what part of code you want to execute... try
vb... (good luck ;-) )
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 10:48 (Mon, 04 Aug 2008 12:48:04 +0300)
From: Metsis
Arnaud Nicolet kirjoitti:
> Well, I think it's simply a matter of logic. What is an exception?...

Have anybody tested this with AngelLogic
(http://elfdata.com/angellogic/index.html) that unlike any other existing logic
processor features a "tri-state" system with "dunno"? Maybe it gives the
ultimate answer... ;-)

Metsis


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 23:12 (Sun, 3 Aug 2008 15:12:18 -0700)
From: Joe Huber
At 4:44 PM -0500 8/3/08, John Jobe wrote:
>Is 2147483648 guaranteed to always mean a /0 has happened?

No, it's a perfectly legitimate integer value

>
>Could a person arrive at 2147483648 without doing a /0?

Sure, just add one to 2147483647. Or (2147483648/2) * 2

>
>Can a person perform math on the value 2147483648?

Sure, it's just a legitimate integer value.

These are all reasons that it cannot be used as a special value
meaning DIVBYZERO.

There are no integer values encoded to mean NaN nor Inf. So unless
you want to come up with a completely new standard for numeric
integer representation like the IEEE did for floating point numerics,
communicating NaN and Inf from integer calculations will require an
out of band mechanism such as an exception.

Regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 23:27 (Sun, 03 Aug 2008 17:27:30 -0500)
From: Rubber Chicken Software Co.
I'm on Huber's and Harries side! =) (as if anyone cares)

If I see a grandmother crossing the street and a car is coming, I
don't think about if she should have been wearing her glasses or not.
Who cares if RB "should" do this or not. (Where did anyone write a
set of rules?) Just do it - it's beneficial for everyone anyway.

Whether RB is "supposed" to flag these things for you is besides the
point. The point that it would be nice for anyone if it would raise
and exception or whatever, if internally it's not too hard.

RB's primary focus isn't to be fully powerful, it's to make things
easy to use. So a compiler catching an instance (run-time) where you
divided by zero would be nice in anyones book, and would line up to
what RB is all about.

This isn't a "or" issue, its an "and" issue.

(BTW, I should mention that VB did this 15 years ago. I THINK RB can
do it now.)

* * * * * * * * * * * * * * * * * * * * * * * * * * *
| Garth Hjelte |
| Customer Service Representative, President |
| Chicken Systems, Inc, Rubber Chicken Software Co. |
| 714 5th Street SE |
| Willmar, MN 56201 USA |
| |
| 800-8-PRO-EPS Toll Free Order Line (US Only) |
| 320-235-9798 Tech Support, Sampler Questions |
| International Line |
| 360-838-7689 Fax |
| Product Sales: <email address removed> |
| Product Support: <email address removed> |
| Sampler Q+A: <email address removed> |
| Web Page: www.chickensys.com |
* * * * * * * * * * * * * * * * * * * * * * * * * * *

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 23:32 (Mon, 04 Aug 2008 00:32:44 +0200)
From: Arnaud Nicolet
Le 4 août 08 à 00:17 (matin), Andre Kuiper a écrit:

> IMO if the system isn't able to provide an error / exception for a
> division by zero how can you as user of that system?

By checking the denominator, perhaps?
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 23:39 (Mon, 04 Aug 2008 00:39:25 +0200)
From: Andre Kuiper
Do you know the datatype of the denominator and the exact binary
representation?

Arnaud Nicolet schreef:
> Le 4 août 08 à 00:17 (matin), Andre Kuiper a écrit:
>
>> IMO if the system isn't able to provide an error / exception for a
>> division by zero how can you as user of that system?
>
> By checking the denominator, perhaps?
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 23:35 (Sun, 3 Aug 2008 17:35:38 -0500)
From: Harrie Westphal

On Aug 3, 2008, at 5:04 PM, Arnaud Nicolet wrote:

> Another example: have you ever tried this?:
> dim i As Integer
>
> i!47483647
> i=i+1
>
> In the debugger, i is now equal to -2147483648. I have the feeling
> that it's mathematically wrong... But it's not illegal from a CPU's
> point of view.

Go to the language reference and type Integer into the location box.
Your first number above is the maximum value for a postive integer.
Your second number is the maximum value for a negative integer. Both
are perfectly legal integer values. Neither represents the fact that
a zero divide has occurred. The only reason it can be done with
floating point values is that there are a certain number of bits that
represent the number, a certain number of bits that give the power of
10 and 1 extra bit to flag a divide by zero. Integer values have no
means to indicate anything other than a number within their legal range.

=3D A Mac addict in Tennessee =e

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 23:41 (Sun, 3 Aug 2008 17:41:43 -0500)
From: John Jobe
You are kidding right?

On Aug 3, 2008, at 5:39 PM, Andre Kuiper wrote:

> Do you know the datatype of the denominator and the exact binary
> representation?
>
> Arnaud Nicolet schreef:
>> Le 4 août 08 à 00:17 (matin), Andre Kuiper a écrit:
>>
>>> IMO if the system isn't able to provide an error / exception for a
>>> division by zero how can you as user of that system?
>>
>> By checking the denominator, perhaps?

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 03.08.08 23:58 (Mon, 04 Aug 2008 00:58:26 +0200)
From: Arnaud Nicolet
Le 4 août 08 à 00:35 (matin), Harrie Westphal a écrit:
> On Aug 3, 2008, at 5:04 PM, Arnaud Nicolet wrote:
>
>> Another example: have you ever tried this?:
>> dim i As Integer
>>
>> i=2147483647
>> i=i+1
>>
>> In the debugger, i is now equal to -2147483648. I have the feeling
>> that it's mathematically wrong... But it's not illegal from a
>> CPU's point of view.
>
> Go to the language reference and type Integer into the location
> box. Your first number above is the maximum value for a postive
> integer. Your second number is the maximum value for a negative
> integer. Both are perfectly legal integer values.

Yes, thanks. I know that (I was "kidding" when I said "I have the
feeling..." in my reply).

> Neither represents the fact that a zero divide has occurred. The
> only reason it can be done with floating point values is that there
> are a certain number of bits that represent the number, a certain
> number of bits that give the power of 10 and 1 extra bit to flag a
> divide by zero. Integer values have no means to indicate anything
> other than a number within their legal range.

My point is that, since you have to check for 2147483647+i being
equal to -2147483648, it would be nonsense to have an exception when
dividing by zero but no exception when "passing beyond the integer
limit".
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 00:03 (Mon, 04 Aug 2008 01:03:10 +0200)
From: Arnaud Nicolet
Le 4 août 08 à 00:39 (matin), Andre Kuiper a écrit:

> Do you know the datatype of the denominator and the exact binary
> representation?

Not needed, just use a variable...

Something like that:

dim i As int64
dim j As integer
dim k As integer

k=32
j=k-32

if j<>0 then
i=k/j
return true
else
return false
end if
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 02:23 (Mon, 4 Aug 2008 09:23:36 +0800)
From: Andy Dent
can we now move onto a more productive discussion like the
inadequacies of only having one kind of Null in SQL please ;-)

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 02:41 (Sun, 03 Aug 2008 21:41:09 -0400)
From: Bart Silverstrim


Andy Dent wrote:
> can we now move onto a more productive discussion like the inadequacies
> of only having one kind of Null in SQL please ;-)

Pardon the noob question...but there's more than one kind of Null?

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 11:13 (Mon, 04 Aug 2008 12:13:01 +0200)
From: Arnaud Nicolet
Le 4 août 08 à 03:23 (matin), Andy Dent a écrit:

> can we now move onto a more productive discussion like the
> inadequacies of only having one kind of Null in SQL please ;-)

Well, everyone use integers; not the same about databases.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 15:36 (Mon, 4 Aug 2008 08:36:44 -0600)
From: Joe Strout
On Aug 3, 2008, at 8:19 AM, Harrie Westphal wrote:

> I highly respect you as a person and user of REALbasic. But, I have
> to chuckle when you comment about wanting speedy code and not
> wanting the compiler to put in checks for division by zero. I have
> to chuckle because the whole concept of Object Oriented coding is
> not predicated on the fastest of code.

True, it's always a balance. I like speedy code, but I like
maintainable code too. If divisions by zero were a frequent source of
maintenance problems, I would certainly want the language (or better
yet, the compiler, to the extent that is possible) to catch them.
But, in my experience, they are not.

> I too have never had a problem with going awry due to zero divides
> in RB. I learned long ago to test divisors before doing the divides
> when I could not be sure of the divisor being non-zero. It's just
> that not checking is leaving a door open for errors that really
> shouldn't be there in the first place in my mind.

But it's not as though this error isn't caught. It is caught, and
it's reported by giving you a value of INF (or maybe NAN -- whichever
it is, it is the standard agreed upon years ago by IEEE). You can
carry this through to other calculations and it will, again, do the
right thing according to numeric standards; or you can detect this and
post a "hey dummy, don't enter zero" message to the user if you
prefer. An exception wouldn't be any better, and in fact would
probably result in WORSE behavior in most apps.

Best,
- Joe

Re: Division by zero
Date: 04.08.08 15:41 (Mon, 4 Aug 2008 08:41:43 -0600)
From: Joe Strout
On Aug 3, 2008, at 1:50 PM, John Jobe wrote:

> Answer is INF and seems to properly stay INF no matter what we do
> with it.
>
> However, this behavior is not present across data types (even lowly
> integer seems to have problems).

That's a fair point -- integer types don't have INF and NAN values
like floating-points do. I don't know if there is a standard behavior
for those. However, I long for the day when this is the biggest
problem we can find in RB!

Best,
- Joe

Re: Division by zero
Date: 04.08.08 15:54 (Mon, 4 Aug 2008 08:54:20 -0600)
From: Joe Strout
On Aug 4, 2008, at 3:48 AM, Metsis wrote:

> Arnaud Nicolet kirjoitti:
>> Well, I think it's simply a matter of logic. What is an exception?...
>
> Have anybody tested this with AngelLogic (http://elfdata.com/angellogic/index.html
> ) that unlike any other existing logic processor features a "tri-
> state" system with "dunno"? Maybe it gives the ultimate answer... ;-)

That's not "unlike any other existing logic processor" -- it's just a
stripped-down version of fuzzy logic. You also see it in other
systems, like the tri-state checkbox in the Apple UI, or in databases
systems that track user responses (yes/no/no-response).

(In fact I once proposed making a tri-state Boolean type for use in
RB, which would make dealing with things like tri-state checkboxes
really trivial, but that was never met with much enthusiasm.)

Best,
- Joe

Re: Division by zero
Date: 04.08.08 17:04 (Mon, 04 Aug 2008 19:04:51 +0300)
From: Metsis
Joe Strout kirjoitti:
> That's not "unlike any other existing logic processor" -- it's just a
> stripped-down version of fuzzy logic.

I just quoted the hype on the web page of AngelLogic. I seem to have omitted the
quotes and thought a smiley would be sufficient.

I know a litte bit multivalued logic, fuzzy logic, computing with certainty
factors etc., so tri-state logic per se is not unfamiliar to me. However, I
don't know how AngelLogic operates (don't have time nor interest), but I'm
convinced it will ,when finished, find solution to the mystery of dark matter in
the universe/find the question for which "42" is the answer/<insert your
favorite problem here> :-)

> (In fact I once proposed making a tri-state Boolean type for use in RB,
> which would make dealing with things like tri-state checkboxes really
> trivial, but that was never met with much enthusiasm.)

Did you proposed any tri-state algebra for it?

Metsis

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 16:17 (Mon, 4 Aug 2008 11:17:59 -0400)
From: Charles Yeomans

On Aug 3, 2008, at 4:39 PM, Arnaud Nicolet wrote:

> Le 3 août 08 à 22:16 (soir), Joe Huber a écrit:
>
>> Guess what it does! For integer numbers (i/0) always returns
>> 2147483648. So either we've solved the long pondered div by zero
>> question and now we can tell the world that (i/0) = 2147483648, or
>> RB has generated an error.
>
> 2147483648 is the highest integer value. Since x/0 results in
> infinite, the closer integer is indeed 2147483648. Instead, the
> programmer should check in code that the denominator is not 0 (is
> that really so hard to do?). This is a general rule, like the fact
> that you should always check if a file exists before opening it!

Actually, 2147483647 is the largest Int32 value.

Charles Yeomans
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 16:46 (Mon, 4 Aug 2008 08:46:40 -0700)
From: Joe Huber
>Actually, 2147483647 is the largest Int32 value.

Yes, I was wondering about that even as I wrote that message. But I
persisted because I had copied that value right out of the RB app
where I logged the value returned by the divide by zero, and pasted
it into my email.

I later realized that I hadn't included a "-" in the Format specifier
for displaying the div by zero result and that the particular test
case was dividing a negative number by zero. So what I copied was
missing the negative sign char.

Apparently RB returns MinusMaxInt when dividing a negative number by zero.

But yes of course 2147483647 is the largest positive Int32 and
2147483648 is the largest negative Int32.

Sorry for missing the sign on the original number I posted.

Regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 17:16 (Mon, 4 Aug 2008 12:16:54 -0400)
From: Frank Condello
On 4-Aug-08, at 11:46 AM, Joe Huber wrote:

> Apparently RB returns MinusMaxInt when dividing a negative number by
> zero.

Actually, it returns -INF - it's the conversion and assignment to int
that everyone seems to be complaining about. I'm not sure -INF is
correct either (depends who you ask) but if you guys want a new
exception it should probably be some sort of runtime type mismatch or
illegal assignment, and not necessarily have anything to do with
dividing by zero.

Frank.
<http://developer.chaoticbox.com/blog/>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 17:31 (Mon, 4 Aug 2008 11:31:23 -0500)
From: Harrie Westphal

On Aug 4, 2008, at 10:46 AM, Joe Huber wrote:

> Apparently RB returns MinusMaxInt when dividing a negative number
> by zero.

It is a lot more convoluted that that.

Dividing a positive value by zero using either 10/xxx for all integer
types and 10.00/xxx for single, double and currency yields.

UInt8 --> 255
UInt16 --> 65535
UInt32 --> 4294967295
UInt64 --> 184467440737095516616
Int8 --> -1
Int16 --> -1
Int32 --> 2147483648
Int64 --> 1
Integer --> 2147483648
Single --> INF.00
Double --> INF.00
Currency --> -0.00

Now -10/xxx for all integer variations and -10.00/xxx for single
double and currency yields

UInt8 --> 0
UInt16 --> 0
UInt32 --> 2147483648
UInt64 --> 0
Int8 --> 0
Int16 --> 0
Int32 --> -2147483648
Int64 --> 1
Integer --> -2147483648
Single --> -INF
Double --> -INF
Currency --> 0.00

=wD A Mac addict in Tennessee =_

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 17:54 (Mon, 4 Aug 2008 12:54:24 -0400)
From: Charles Yeomans

On Aug 4, 2008, at 12:31 PM, Harrie Westphal wrote:

>
> On Aug 4, 2008, at 10:46 AM, Joe Huber wrote:
>
>> Apparently RB returns MinusMaxInt when dividing a negative number
>> by zero.
>
> It is a lot more convoluted that that.
>
> Dividing a positive value by zero using either 10/xxx for all
> integer types and 10.00/xxx for single, double and currency yields.
>
> UInt8 --> 255
> UInt16 --> 65535
> UInt32 --> 4294967295
> UInt64 --> 184467440737095516616
> Int8 --> -1
> Int16 --> -1
> Int32 --> 2147483648
> Int64 --> 1
> Integer --> 2147483648
> Single --> INF.00
> Double --> INF.00
> Currency --> -0.00
>
> Now -10/xxx for all integer variations and -10.00/xxx for single
> double and currency yields
>
> UInt8 --> 0
> UInt16 --> 0
> UInt32 --> 2147483648

Actually, it's even more convoluted. In the code

dim N as UInt32 = 10/0

I believe the compiler interprets the constants 10 and 0 as Int32,
performs the division, then casts the results as UInt32.

This code makes all types explicit.

dim A as UInt32 = 10
dim B as UInt32 = 0
dim N as UInt32 = A/B

Here, N is set to 0.

Charles Yeomans

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 18:29 (Mon, 4 Aug 2008 11:29:12 -0600)
From: Joe Strout
On Aug 4, 2008, at 10:04 AM, Metsis wrote:

> Joe Strout kirjoitti:
>> That's not "unlike any other existing logic processor" -- it's just
>> a stripped-down version of fuzzy logic.
>
> I just quoted the hype on the web page of AngelLogic. I seem to have
> omitted the quotes and thought a smiley would be sufficient.

Ah, sorry then.

> I know a litte bit multivalued logic, fuzzy logic, computing with
> certainty factors etc., so tri-state logic per se is not unfamiliar
> to me. However, I don't know how AngelLogic operates (don't have
> time nor interest), but I'm convinced it will ,when finished, find
> solution to the mystery of dark matter in the universe/find the
> question for which "42" is the answer/<insert your favorite problem
> here> :-)

No doubt it will be 267X faster than anything else, too.

>> (In fact I once proposed making a tri-state Boolean type for use in
>> RB, which would make dealing with things like tri-state checkboxes
>> really trivial, but that was never met with much enthusiasm.)
>
> Did you proposed any tri-state algebra for it?

But of course -- and in fact I implemented a prototype, as I recall,
using operator overloading to make it behave as you would expect. The
truth table was just the obvious one: True And Unknown = Unknown, True
Or Unknown = True, False And Unknown = False, False Or Unknown =
Unknown, etc.

Best,
- Joe

Re: Division by zero
Date: 04.08.08 18:30 (Mon, 4 Aug 2008 11:30:57 -0600)
From: Joe Strout
On Aug 4, 2008, at 10:54 AM, Charles Yeomans wrote:

> Actually, it's even more convoluted. In the code
>
> dim N as UInt32 = 10/0
>
> I believe the compiler interprets the constants 10 and 0 as Int32,
> performs the division, then casts the results as UInt32.

Actually, it's still even more convoluted than that. It would indeed
interpret 10 and 0 as Int32, but you're using them with a floating-
point operator, so they'd be first converted to doubles, and then
divided (and then the result would be cast back to a UInt32).

Best,
- Joe

Re: Division by zero
Date: 04.08.08 19:06 (Mon, 4 Aug 2008 13:06:50 -0500)
From: Harrie Westphal

On Aug 4, 2008, at 11:54 AM, Charles Yeomans wrote:

> Actually, it's even more convoluted. In the code
>
> dim N as UInt32 = 10/0
>
> I believe the compiler interprets the constants 10 and 0 as Int32,
> performs the division, then casts the results as UInt32.
>
> This code makes all types explicit.
>
> dim A as UInt32 = 10
> dim B as UInt32 = 0
> dim N as UInt32 = A/B
>
> Here, N is set to 0.

I changed my little program so that the numerator, denominator and
result in every line are dimmed as the same data type. Ran the
program and the listbox still fills with the exact same values in the
column for positive numerators and the column for negative
numerators. No conversion of any kind should have taken place. I do
not see a zero value for 10/0 in the UInt32, positive numerator cell.

But, this discussion is reaching the point of ridiculousness. I feel
VERY strongly that exceptions should be raised upon an attempt to
divide by zero. If there is a pragma to turn off the testing fine.
But just like array bounds checking it should not be allowed. I have
never worked with another language that did not raise an exception on
zero divide. Talked with my son who works at Compuware and he also
has never worked with a language that does not raise an exception on
a zero divide. However, he did say that there are other languages
besides RB that do not raise an exception after doing some searching
on the net.

I will not argue my point any longer as I can readily see that I seem
to be in the minority, at least amongst those responding. I can't
understand how checking a divisor for zero would slow things down
that much in the vast majority of programs. Some programs yes, but
for those programs zero divide checks would not be the only
hinderance. Some programs just need pure raw speed and I am not sure
that trying to accomplish that purely within an OOPs language will
give them their fastests results. I do know that it seems rather
dumb, in my mind, to allow a mathematical function to return a
meaningless value potentially causing major consequences. I truly
like RB but I think that this is a real flaw.

That's it. I shall make no further postings to this thread (as I hear
cheers joy in the distance). ;-) I have made my feelings felt. May
all of those who do divisions in RB never fail to test those divisors
for zero because if you do, you are on your own.

=cD A Mac addict in Tennessee =u

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 19:18 (Mon, 4 Aug 2008 11:18:03 -0700)
From: Tim Jones
On Aug 4, 2008, at 11:06 AM, Harrie Westphal wrote:

> That's it. I shall make no further postings to this thread (as I
> hear cheers joy in the distance). ;-) I have made my feelings felt.
> May all of those who do divisions in RB never fail to test those
> divisors for zero because if you do, you are on your own.

But, you do not appear to have ever submitted a request to the RS bug/
feature system. Discussing things in whatever duration on the NUG is
not a replacement for making a bug report or a feature request through
the RS FogBugz system.

Don't "give in", but rather submit your request through the channels
that will get it noticed by the people that can make a change. Other
than either commiserate or disagree, there's not much that the NUG
members can do to help make changes.

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 20:00 (Mon, 4 Aug 2008 12:00:36 -0700)
From: Terry Ford

On Aug 4, 2008, at 11:18 AM, Tim Jones wrote:

> Discussing things in whatever duration on the NUG is not a
> replacement for making a bug report or a feature request through
> the RS FogBugz system.
>
> Don't "give in", but rather submit your request through the
> channels that will get it noticed by the people that can make a
> change. Other than either commiserate or disagree, there's not
> much that the NUG members can do to help make changes.

In a sense, I agree with you. But I am also unhappy that "Foggy Bugs"
doesn't allow "me toos" to the list so that only leaves the NUG or
the Forums to express one's concerns easily. I'm sure that it won't
change things much of the time but it does have a roundabout
influence on the direction of Rb.

After all, RS want's you to keep subscribing so they can continue
existence. Without us users, there is no Rb.

Just my 2 cents CDN worth.

Terry

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 20:35 (Mon, 4 Aug 2008 12:35:36 -0700)
From: Tim Jones
On Aug 4, 2008, at 12:00 PM, Terry Ford wrote:

> On Aug 4, 2008, at 11:18 AM, Tim Jones wrote:
>
>> Discussing things in whatever duration on the NUG is not a
>> replacement for making a bug report or a feature request through
>> the RS FogBugz system.
>>
>> Don't "give in", but rather submit your request through the
>> channels that will get it noticed by the people that can make a
>> change. Other than either commiserate or disagree, there's not
>> much that the NUG members can do to help make changes.
>
> In a sense, I agree with you. But I am also unhappy that "Foggy
> Bugs" doesn't allow "me toos" to the list so that only leaves the
> NUG or the Forums to express one's concerns easily. I'm sure that it
> won't change things much of the time but it does have a roundabout
> influence on the direction of Rb.

Actually, you can "Me Too", but only the OP and RS can see what you
add. By sending an email to <email address removed> with the
FB report ID in the subject, you can add your comments at least. But,
they've asked us to submit separate reports in any case and they will
consolidate them internally.

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 21:04 (Mon, 04 Aug 2008 16:04:49 -0400)
From: Bart Silverstrim


Tim Jones wrote:
> On Aug 4, 2008, at 12:00 PM, Terry Ford wrote:
>
>> On Aug 4, 2008, at 11:18 AM, Tim Jones wrote:
>>
>>> Discussing things in whatever duration on the NUG is not a
>>> replacement for making a bug report or a feature request through the
>>> RS FogBugz system.
>>>
>>> Don't "give in", but rather submit your request through the channels
>>> that will get it noticed by the people that can make a change. Other
>>> than either commiserate or disagree, there's not much that the NUG
>>> members can do to help make changes.
>>
>> In a sense, I agree with you. But I am also unhappy that "Foggy Bugs"
>> doesn't allow "me toos" to the list so that only leaves the NUG or the
>> Forums to express one's concerns easily. I'm sure that it won't change
>> things much of the time but it does have a roundabout influence on the
>> direction of Rb.
>
> Actually, you can "Me Too", but only the OP and RS can see what you
> add. By sending an email to <email address removed> with the FB
> report ID in the subject, you can add your comments at least. But,
> they've asked us to submit separate reports in any case and they will
> consolidate them internally.

It is SO weird to read books and listen to podcasts with Joel Spolsky
and hear the product highlighted (understandably) and then on this list
hear it get ripped on...

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 21:24 (Mon, 04 Aug 2008 16:24:01 -0400)
From: Bart Silverstrim


Bart Silverstrim wrote:

> It is SO weird to read books and listen to podcasts with Joel Spolsky
> and hear the product highlighted (understandably) and then on this list
> hear it get ripped on...

To clarify myself a little, google "joel spolsky" and you'll see that
FogBugz is his baby :-)

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 21:08 (Mon, 4 Aug 2008 15:08:57 -0500)
From: Harrie Westphal

On Aug 4, 2008, at 1:18 PM, Tim Jones wrote:

> But, you do not appear to have ever submitted a request to the RS
> bug/feature system. Discussing things in whatever duration on the
> NUG is not a replacement for making a bug report or a feature
> request through the RS FogBugz system.

Dang! I wasn't going to reply any more. Yes, I entered a foggy bug
report, 3264, stating that exceptions should be raised on zero
divides. I know at least one other sole also posted something in this
regard. No way I could go without doing that because this is a bug, a
big bug to my way of thinking.

I shall try to go quiet now.

=CD A Mac addict in Tennessee =2

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 21:53 (Mon, 4 Aug 2008 13:53:28 -0700)
From: Tim Jones
On Aug 4, 2008, at 1:24 PM, Bart Silverstrim wrote:

> Bart Silverstrim wrote:
>
>> It is SO weird to read books and listen to podcasts with Joel
>> Spolsky and hear the product highlighted (understandably) and then
>> on this list hear it get ripped on...
>
> To clarify myself a little, google "joel spolsky" and you'll see
> that FogBugz is his baby :-)

It's not FogBugz, but rather the way REALSoftware has chosen to
implement it. FB is a very robust tool, it's just that RS has chosen
to limit the external access provided to the rest of us.

To see what FB can do, visit the main FogBugz site (http://www.fogcreek.com/FogBugz
) and give it a whirl.

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 05.08.08 00:49 (Mon, 4 Aug 2008 19:49:11 -0400)
From: Frank Condello

On 4-Aug-08, at 2:06 PM, Harrie Westphal wrote:

> ...I feel VERY strongly that exceptions should be raised upon an
> attempt to divide by zero. If there is a pragma to turn off the
> testing fine. But just like array bounds checking it should not be
> allowed. I have never worked with another language that did not
> raise an exception on zero divide.

I believe several people have totally missed the point - the problem
isn't divide-by-zero - it's assigning INF or NAN to an integer type.
Try this:

Dim i As Integer = Val("INF")

A divide-by-zero exception won't catch that, but that is essentially
what you're doing when storing the result of a division into an
integer. I'm not saying there shouldn't be a divide-by-zero exception
(that's for RS to decide) but it's not the right fix the problems I've
seen posted to this thread.

Frank.
<http://developer.chaoticbox.com/blog/>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 05.08.08 05:13 (Mon, 4 Aug 2008 22:13:34 -0600)
From: Norman Palardy

On 3-Aug-08, at 10:45 AM, Joe Huber wrote:

> At 9:27 AM -0700 8/3/08, Fargo Holiday wrote:
>> Sometimes tackling a problem in programming doesn't mean insisting
>> on a new feature, it means doing some more programming.
>
> So explain why RS does NIL object checking but not divide by zero
> checking?

I think you'll find it's not doing a check but using a nil object
that is the problem and exception being thrown as a result

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 05.08.08 05:27 (Mon, 4 Aug 2008 22:27:44 -0600)
From: Norman Palardy

On 4-Aug-08, at 1:00 PM, Terry Ford wrote:

> In a sense, I agree with you. But I am also unhappy that "Foggy
> Bugs" doesn't allow "me toos" to the list so that only leaves the
> NUG or the Forums to express one's concerns easily. I'm sure that
> it won't change things much of the time but it does have a
> roundabout influence on the direction of Rb.
>
You can "me too" by submitting a similar bug report if it's important

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 05.08.08 05:29 (Mon, 4 Aug 2008 22:29:55 -0600)
From: Norman Palardy

On 4-Aug-08, at 2:04 PM, Bart Silverstrim wrote:

> It is SO weird to read books and listen to podcasts with Joel
> Spolsky and hear the product highlighted (understandably) and then
> on this list hear it get ripped on...

FogBugz has a particular design philosophy about bug reporting
And the product is designed to support that philosophy


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 05.08.08 05:33 (Mon, 4 Aug 2008 22:33:17 -0600)
From: Norman Palardy

On 4-Aug-08, at 2:53 PM, Tim Jones wrote:

> It's not FogBugz, but rather the way REALSoftware has chosen to
> implement it. FB is a very robust tool, it's just that RS has
> chosen to limit the external access provided to the rest of us.
>
> To see what FB can do, visit the main FogBugz site (http://
> www.fogcreek.com/FogBugz) and give it a whirl.
This criticism is quite unwarranted as REAL is simply using the
hosted version of FB instead of hosting it internally
It's what Fog Creek makes available to us and you
Other than that it is FB in every way and there's nothing "custom"
about how it's implemented

If there's a valid complaint direct it to Joel and company

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 05.08.08 16:24 (Tue, 5 Aug 2008 08:24:50 -0700)
From: Tim Jones
On Aug 4, 2008, at 9:33 PM, Norman Palardy wrote:

> On 4-Aug-08, at 2:53 PM, Tim Jones wrote:
>
>> It's not FogBugz, but rather the way REALSoftware has chosen to
>> implement it. FB is a very robust tool, it's just that RS has
>> chosen to limit the external access provided to the rest of us.
>>
>> To see what FB can do, visit the main FogBugz site (http://www.fogcreek.com/FogBugz
>> ) and give it a whirl.>
> This criticism is quite unwarranted as REAL is simply using the
> hosted version of FB instead of hosting it internally
> It's what Fog Creek makes available to us and you

There was no criticism there - implied or intended, just a statement
of fact. FogBugz - yes, even the hosted version - offers far more
than what the RS team are sharing with the customers reporting bugs
and making feature requests. We have the product here and I know just
how open or closed the environment can be made. I'm not *faulting*
the RS implementation decisions here, I was just trying to get people
to stop complaining about FogBugz.

> Other than that it is FB in every way and there's nothing "custom"
> about how it's implemented

It is "custom" in the way RS are using it because they're using a
subset of the API for communicating from the bug submission form on
the Feedback page of the RS website. I suggest that you watch Joel's
video demo (http://media.fogcreek.com/fogcreek.com/FogBugz/60movie/60movie.html
) of the product and compare it to what RS are using.

> If there's a valid complaint direct it to Joel and company

No complaints about FogBugz at all, and no complaint (from me at
least) about the RS implementation. As I said, I was just stating a
fact based on my actual knowledge of FogBugz feature set and a wish to
stop people from complaining about FogBugz.

BTW, Thom, if you're reading this, the errant backslash escaping in
the reports is being added by the POST code on the submission form,
not as any part of FogBugz.

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 05.08.08 18:01 (Tue, 5 Aug 2008 10:01:30 -0700)
From: Terry Ford

On Aug 5, 2008, at 8:24 AM, Tim Jones wrote:

> As I said, I was just stating a fact based on my actual knowledge
> of FogBugz feature set and a wish to stop people from complaining
> about FogBugz.

I have never complained about FogBugz. I, however, do often refer to
"Foggy Bugs" as RS's implementation of it. That's why I use that name.

If anything, it shows disrespect for RS's usage alone.

Terry

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 05.08.08 21:22 (Tue, 05 Aug 2008 22:22:45 +0200)
From: Arnaud Nicolet
Le 4 août 08 à 00:27 (matin), Rubber Chicken Software Co. a écrit:

> RB's primary focus isn't to be fully powerful, it's to make things
> easy to use. So a compiler catching an instance (run-time) where
> you divided by zero would be nice in anyones book, and would line
> up to what RB is all about.

RB's focus is also to let the user handles things.
I don't want RB to start saying "Since your programe does not do what
I want, I throw an exception".

> (BTW, I should mention that VB did this 15 years ago. I THINK RB
> can do it now.)

If you want to use VB, use it. RB does not have to ressemble vb (and
it's preferable it does not).
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 05.08.08 21:25 (Tue, 05 Aug 2008 22:25:52 +0200)
From: Arnaud Nicolet
Le 4 août 08 à 17:17 (soir), Charles Yeomans a écrit:

> On Aug 3, 2008, at 4:39 PM, Arnaud Nicolet wrote:
>
>> Le 3 août 08 à 22:16 (soir), Joe Huber a écrit:
>>
>>> Guess what it does! For integer numbers (i/0) always returns
>>> 2147483648. So either we've solved the long pondered div by zero
>>> question and now we can tell the world that (i/0) = 2147483648,
>>> or RB has generated an error.
>>
>> 2147483648 is the highest integer value. Since x/0 results in
>> infinite, the closer integer is indeed 2147483648. Instead, the
>> programmer should check in code that the denominator is not 0 (is
>> that really so hard to do?). This is a general rule, like the fact
>> that you should always check if a file exists before opening it!
>
> Actually, 2147483647 is the largest Int32 value.

Yes, you're right. I actually took the number posted in earlier posts.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 05.08.08 21:31 (Tue, 05 Aug 2008 22:31:10 +0200)
From: Arnaud Nicolet
Le 4 août 08 à 20:18 (soir), Tim Jones a écrit:

> On Aug 4, 2008, at 11:06 AM, Harrie Westphal wrote:
>
>> That's it. I shall make no further postings to this thread (as I
>> hear cheers joy in the distance). ;-) I have made my feelings
>> felt. May all of those who do divisions in RB never fail to test
>> those divisors for zero because if you do, you are on your own.
>
> But, you do not appear to have ever submitted a request to the RS
> bug/feature system. Discussing things in whatever duration on the
> NUG is not a replacement for making a bug report or a feature
> request through the RS FogBugz system.

He's right to first discuss here, because it seems raising an
exception is not the right way (many people say that).
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 05.08.08 21:33 (Tue, 05 Aug 2008 22:33:08 +0200)
From: Arnaud Nicolet
Le 4 août 08 à 22:08 (soir), Harrie Westphal a écrit:

> On Aug 4, 2008, at 1:18 PM, Tim Jones wrote:
>
>> But, you do not appear to have ever submitted a request to the RS
>> bug/feature system. Discussing things in whatever duration on the
>> NUG is not a replacement for making a bug report or a feature
>> request through the RS FogBugz system.
>
> Dang! I wasn't going to reply any more. Yes, I entered a foggy bug
> report, 3264, stating that exceptions should be raised on zero
> divides. I know at least one other sole also posted something in
> this regard. No way I could go without doing that because this is a
> bug, a big bug to my way of thinking.

Well, I'll add a foggy bug report stating that dividing by zero
should continue to work as it does now ;-)
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 08.08.08 21:05 (Fri, 8 Aug 2008 13:05:24 -0700)
From: Tim Jones
I Didn't want to kick this sleeping dog, but Aaron has posted a blog
entry about the Divide by Zero issue:

http://ramblings.aaronballman.com/2008/08/division_by_zero.html

Just the messenger...

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 08.08.08 21:22 (Fri, 8 Aug 2008 13:22:10 -0700)
From: Terry Ford

On Aug 8, 2008, at 1:05 PM, Tim Jones wrote:

> I Didn't want to kick this sleeping dog, but Aaron has posted a
> blog entry about the Divide by Zero issue:
>
> http://ramblings.aaronballman.com/2008/08/division_by_zero.html
>
> Just the messenger...

Thanks Tim. It's an extremely interesting Blog.

Too bad Aaron never bothered to post a link to the NUG like you did.

How did you find it?

Terry

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 08.08.08 21:26 (Fri, 08 Aug 2008 16:26:51 -0400)
From: Karen

On Aug 8, 2008, at 4:22 PM, Terry Ford wrote:
> Too bad Aaron never bothered to post a link to the NUG like you did.
>
> How did you find it?
>

Maybe the way I did ... I check Aaron's blog regularly ;)

I've found over the years that I almost always can count on Aaron
disagreeing with me! ;)

- Karen

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 09.08.08 01:59 (Fri, 8 Aug 2008 17:59:02 -0700)
From: Joe Huber
At 4:26 PM -0400 8/8/08, Karen wrote:
>I've found over the years that I almost always can count on Aaron
>disagreeing with me! ;)
>
>- Karen

I've also found Aaron to be very dependable that way. :-)

Regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 09:50 (Mon, 4 Aug 2008 09:50:56 +0100)
From: Theodore H. Smith
>> On Aug 3, 2008, at 3:52 PM, Harrie Westphal wrote:
>>> Infinity isn't a number
>>
>> Yeah, "infinity" is only truly valid in certain contexts with /0.
>> UNDEFINED or MEANINGLESS is the proper answer for other contexts.
>> For RB, what we need is a descriptive term that we can check for
>> (when needed) that is generic enough to fit regular needs within
>> the context of RB. That could be something as simple as
>> DIVBYZERO. If all numeric data types returned DIVBYZERO (much as
>> INF is returned for doubles) when a /0 operation has happened and
>> there were set rules for /0 within the RB context (like once we
>> arrive at DIVBYZERO the value can not be changed) the problem is
>> pretty much solved.
>
> If you check wether an integer has the value of 'DIVBYZERO', why not
> simply checking if it is 2147483648?

All of this discussion is pretty meaningless, and theoretical, as far
as I've seen...

Why not talk about any REAL example?

the only real example I've seen... is from playing Marathon (over 10
years ago?) on 68k Macs.

It turned out, that there was a division by zero bug that could occur
sometimes. Perhaps two 3d points were right ontop of each other, and
some division was made to divide the space between each other. Perhaps
the player's foot happened to move just ontop of a point somewhere...

Anyhow, the result of this, was that Marathon would sometimes crash on
68k Macs. Because 68ks treated divide by zero as an exception.

PowerPC macs however, did NOT treat it as an exception. So the game
played fine, no crash at all.

For this reason... I think the entire discussion is meaningless.
divide by zero exception seems to be more of a pain than anything.

Unless anyone has a real world example.... where divide by zero is a
problem... whats the point in discussing it?

Re: Division by zero
Date: 04.08.08 15:58 (Mon, 4 Aug 2008 10:58:16 -0400)
From: Charles Yeomans

On Aug 4, 2008, at 4:50 AM, Theodore H. Smith wrote:

>>> On Aug 3, 2008, at 3:52 PM, Harrie Westphal wrote:
>>>> Infinity isn't a number
>>>
>>> Yeah, "infinity" is only truly valid in certain contexts with /0.
>>> UNDEFINED or MEANINGLESS is the proper answer for other contexts.
>>> For RB, what we need is a descriptive term that we can check for
>>> (when needed) that is generic enough to fit regular needs within
>>> the context of RB. That could be something as simple as
>>> DIVBYZERO. If all numeric data types returned DIVBYZERO (much as
>>> INF is returned for doubles) when a /0 operation has happened and
>>> there were set rules for /0 within the RB context (like once we
>>> arrive at DIVBYZERO the value can not be changed) the problem is
>>> pretty much solved.
>>
>> If you check wether an integer has the value of 'DIVBYZERO', why not
>> simply checking if it is 2147483648?
>
> All of this discussion is pretty meaningless, and theoretical, as
> far as I've seen...
>
> Why not talk about any REAL example?
>
> the only real example I've seen... is from playing Marathon (over 10
> years ago?) on 68k Macs.
>
> It turned out, that there was a division by zero bug that could
> occur sometimes. Perhaps two 3d points were right ontop of each
> other, and some division was made to divide the space between each
> other. Perhaps the player's foot happened to move just ontop of a
> point somewhere...
>
> Anyhow, the result of this, was that Marathon would sometimes crash
> on 68k Macs. Because 68ks treated divide by zero as an exception.
>
> PowerPC macs however, did NOT treat it as an exception. So the game
> played fine, no crash at all.
>
> For this reason... I think the entire discussion is meaningless.
> divide by zero exception seems to be more of a pain than anything.
>
> Unless anyone has a real world example.... where divide by zero is a
> problem... whats the point in discussing it?
>
> --

Well, the Ariane 5 failure <http://en.wikipedia.org/wiki/Ariane_5_Flight_501
> was traced to the failure to handle an arithmetic overflow error.
Not exactly a division by zero, but certainly in the same spirit.

Here is a recent reference to a division by zero bug in Apple's USB
code. <http://lists.apple.com/archives/usb/2007/Aug/msg00025.html>

Here's a bug report for mySQL. <http://bugs.mysql.com/bug.php?id'516>

And I expect I could find more.

Charles Yeomans

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Division by zero
Date: 04.08.08 16:08 (Mon, 4 Aug 2008 16:08:39 +0100)
From: Theodore H. Smith
> From: Metsis <<email address removed>>
> Arnaud Nicolet kirjoitti:
>> Well, I think it's simply a matter of logic. What is an exception?...
>
> Have anybody tested this with AngelLogic
> (http://elfdata.com/angellogic/index.html) that unlike any other
> existing logic
> processor features a "tri-state" system with "dunno"? Maybe it gives
> the
> ultimate answer... ;-)


My code is at about the level of complexity as the transistor.

If you think of a modern computer... like a Mac running MacOSX. And...
then think about very early computers, like ENIAC. Well there is a
huge difference in scale of complexity.

Well... if you used that as an analogy... with a self-aware AI being
analogous to MacOSX...

My code is about as complex as a transistor :P or some pre-ENIAC
device, anyhow.

But then... if no one developed better transistors or worked on ENIAC
or other simple computers, we wouldn't have MacOSX.

So while I do not claim my work is useful right now. I do claim that I
am on the right path. I can't imagine my code solving such a problem,
like how to handle division by zero, for anyone just yet...

It simply can't express such a problem! But over time, I am adding the
ability to express more and more complex problems. Right now I'm
adding "type" support. So... I can say "if this thing has a wheel, a
seat and a pole, then it's a unicycle". It's not in the current
release, but it will be in the next.

Honestly, one day a self-aware AI will be able to read an argument
like on this list, and come up with the most logical answer. Who knows
what answer it would say?

It might even say something funny, as I actually have discovered a
logical pattern behind humour, and I believe it would be too great an
opportunity to miss... the ability to have a computer generate good
jokes. Only a logic based AI could create good jokes! But I think
it'll have to be almost self-aware by that point, so it is light-years
off....

Re: Division by zero
Date: 04.08.08 21:36 (Mon, 4 Aug 2008 21:36:44 +0100)
From: Theodore H. Smith
>> Arnaud Nicolet kirjoitti:
>>> Well, I think it's simply a matter of logic. What is an
>>> exception?...
>>
>> Have anybody tested this with AngelLogic (http://elfdata.com/angellogic/index.html
>> ) that unlike any other existing logic processor features a "tri-
>> state" system with "dunno"? Maybe it gives the ultimate answer... ;-)
>
> That's not "unlike any other existing logic processor"

Yes it is.

> -- it's just a
> stripped-down version of fuzzy logic. You also see it in other
> systems, like the tri-state checkbox in the Apple UI, or in databases
> systems that track user responses (yes/no/no-response).

No, that's not true. You obviously don't understand...

It's not just "tri-state". It's also "tri-slot".

Meaning I can represent a large number of different relationships, in
a very compact manner that is super-fast to process.

For example, inside, outside, overlapping, equality, containing...
that is all done without using the "Don't know" state at all.

This makes sense, because sometimes operations result in partial
knowledge states. Where you know something about the relationship, but
not all.

> (In fact I once proposed making a tri-state Boolean type for use in
> RB, which would make dealing with things like tri-state checkboxes
> really trivial, but that was never met with much enthusiasm.)

Re: Division by zero
Date: 04.08.08 21:45 (Mon, 4 Aug 2008 21:45:06 +0100)
From: Theodore H. Smith
> On Aug 4, 2008, at 10:04 AM, Metsis wrote:
>
>> Joe Strout kirjoitti:
>>> That's not "unlike any other existing logic processor" -- it's just
>>> a stripped-down version of fuzzy logic.
>>
>> I just quoted the hype on the web page of AngelLogic. I seem to have
>> omitted the quotes and thought a smiley would be sufficient.
>
> Ah, sorry then.
>
>> I know a litte bit multivalued logic, fuzzy logic, computing with
>> certainty factors etc., so tri-state logic per se is not unfamiliar
>> to me. However, I don't know how AngelLogic operates (don't have
>> time nor interest), but I'm convinced it will ,when finished, find
>> solution to the mystery of dark matter in the universe/find the
>> question for which "42" is the answer/<insert your favorite problem
>> here> :-)
>
> No doubt it will be 267X faster than anything else, too.

No, just able to find 267X more bugs in REALbasic than REALsoftware
engineers are.

I'm sure a logic processor will be very useful in debugging
applications, in the future. It will be one of the main uses of logic
apps...

In fact, some people already use logic processors for this purpose,
and have found it can find bugs that no human could find. These are
chip-makers... can't remember which.