A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Excel » Worksheet Functions
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Bug in Excel's (not VBA's) MOD function



 
 
Thread Tools Display Modes
  #1  
Old October 7th, 2003, 08:04 AM
Harlan Grove
external usenet poster
 
Posts: n/a
Default Bug in Excel's (not VBA's) MOD function

The value 12,345,678,000 is too large to store as a long integer but well
within the range of integers that a double precision floating point real can
store. Excel's worksheet MOD function seems to be able to work with reals,
e.g., MOD(2.25,1/3) returns 0.25 and MOD(2.5,1/3) returns 0.166666666666667.
However, there seems to be a glitch in it when it comes to large integer
values divided by small integer values.

For instance, MOD(12345678000,64) returns #NUM! even though the equivalent
(per online help) expression 12345678000-64*INT(12345678000/64) returns 48
as expected. Clearly Excel's worksheet MOD function isn't just argument
checking wrapped around a call to standard C's fmod(3) call. [No, Microsoft
must have decided they needed to 'enhance' it.]

Maybe this is just a glitch on this particular machine. Does anyone else get
#NUM! from the preceding MOD call? I'm running Excel 97 SR-2 and 2000 SP-3
on this particular machine.


  #2  
Old October 7th, 2003, 08:17 AM
J.E. McGimpsey
external usenet poster
 
Posts: n/a
Default Bug in Excel's (not VBA's) MOD function

I get #NUM! in XL01 and XLv.X.


In article ,
"Harlan*Grove" wrote:

Maybe this is just a glitch on this particular machine. Does anyone else get
#NUM! from the preceding MOD call? I'm running Excel 97 SR-2 and 2000 SP-3
on this particular machine.

  #3  
Old October 7th, 2003, 10:01 AM
Harlan Grove
external usenet poster
 
Posts: n/a
Default Bug in Excel's (not VBA's) MOD function

"J.E. McGimpsey" wrote...
I get #NUM! in XL01 and XLv.X.


So will Microsoft consider this a bug or a feature?


  #4  
Old October 7th, 2003, 10:14 AM
Harlan Grove
external usenet poster
 
Posts: n/a
Default Bug in Excel's (not VBA's) MOD function

"Harlan Grove" wrote...
....
For instance, MOD(12345678000,64) returns #NUM! . . .

....

FWIW, the Works 2000 (ver 5) spreadsheet also returns an error, but
OpenOffice Calc 1.0 returns 48 as expected. While I haven't tested this
under other spreadsheets (yet), I think it's safe to say this, er,
functionality is unique to Microsoft.


  #5  
Old October 7th, 2003, 10:18 AM
Arvi Laanemets
external usenet poster
 
Posts: n/a
Default Bug in Excel's (not VBA's) MOD function

Hi

Win98: Excel2000 - the same result. It looks like the error is returned
whenever quotient reaches the value 134217728


Arvi Laanemets


"Harlan Grove" wrote in message
...
The value 12,345,678,000 is too large to store as a long integer but well
within the range of integers that a double precision floating point real

can
store. Excel's worksheet MOD function seems to be able to work with reals,
e.g., MOD(2.25,1/3) returns 0.25 and MOD(2.5,1/3) returns

0.166666666666667.
However, there seems to be a glitch in it when it comes to large integer
values divided by small integer values.

For instance, MOD(12345678000,64) returns #NUM! even though the equivalent
(per online help) expression 12345678000-64*INT(12345678000/64) returns 48
as expected. Clearly Excel's worksheet MOD function isn't just argument
checking wrapped around a call to standard C's fmod(3) call. [No,

Microsoft
must have decided they needed to 'enhance' it.]

Maybe this is just a glitch on this particular machine. Does anyone else

get
#NUM! from the preceding MOD call? I'm running Excel 97 SR-2 and 2000 SP-3
on this particular machine.




  #6  
Old October 7th, 2003, 01:14 PM
Jerry W. Lewis
external usenet poster
 
Posts: n/a
Default Bug in Excel's (not VBA's) MOD function

I agree with your analysis. 134217728 is 2^27, but I have no clue why
2^27 as the integer part of the division (regardless of divisor) would
be a problem.

Jerry

Arvi Laanemets wrote:

Hi

Win98: Excel2000 - the same result. It looks like the error is returned
whenever quotient reaches the value 134217728


Arvi Laanemets


"Harlan Grove" wrote in message
...

The value 12,345,678,000 is too large to store as a long integer but well
within the range of integers that a double precision floating point real

can

store. Excel's worksheet MOD function seems to be able to work with reals,
e.g., MOD(2.25,1/3) returns 0.25 and MOD(2.5,1/3) returns

0.166666666666667.

However, there seems to be a glitch in it when it comes to large integer
values divided by small integer values.

For instance, MOD(12345678000,64) returns #NUM! even though the equivalent
(per online help) expression 12345678000-64*INT(12345678000/64) returns 48
as expected. Clearly Excel's worksheet MOD function isn't just argument
checking wrapped around a call to standard C's fmod(3) call. [No,

Microsoft

must have decided they needed to 'enhance' it.]

Maybe this is just a glitch on this particular machine. Does anyone else

get

#NUM! from the preceding MOD call? I'm running Excel 97 SR-2 and 2000 SP-3
on this particular machine.


  #7  
Old October 7th, 2003, 02:02 PM
J.E. McGimpsey
external usenet poster
 
Posts: n/a
Default Bug in Excel's (not VBA's) MOD function

In article ,
"Harlan*Grove" wrote:

"J.E. McGimpsey" wrote...
I get #NUM! in XL01 and XLv.X.


So will Microsoft consider this a bug or a feature?


Given their big "mea culpa" on statistical functions,

http://support.microsoft.com/?kbid=828888

I'm hopeful.
  #8  
Old October 7th, 2003, 02:24 PM
Arvi Laanemets
external usenet poster
 
Posts: n/a
Default Bug in Excel's (not VBA's) MOD function

Hi


"Jerry W. Lewis" wrote in message
...
I agree with your analysis. 134217728 is 2^27, but I have no clue why
2^27 as the integer part of the division (regardless of divisor) would
be a problem.



The only explanation I can think of - by calculation is the quotient as
intermediate value temporarily stored into some variable with upper limit as
2^27, and it's overflow causes error.


Arvi Laanemets



Jerry

Arvi Laanemets wrote:

Hi

Win98: Excel2000 - the same result. It looks like the error is returned
whenever quotient reaches the value 134217728


Arvi Laanemets


"Harlan Grove" wrote in message
...

The value 12,345,678,000 is too large to store as a long integer but

well
within the range of integers that a double precision floating point real

can

store. Excel's worksheet MOD function seems to be able to work with

reals,
e.g., MOD(2.25,1/3) returns 0.25 and MOD(2.5,1/3) returns

0.166666666666667.

However, there seems to be a glitch in it when it comes to large integer
values divided by small integer values.

For instance, MOD(12345678000,64) returns #NUM! even though the

equivalent
(per online help) expression 12345678000-64*INT(12345678000/64) returns

48
as expected. Clearly Excel's worksheet MOD function isn't just argument
checking wrapped around a call to standard C's fmod(3) call. [No,

Microsoft

must have decided they needed to 'enhance' it.]

Maybe this is just a glitch on this particular machine. Does anyone else

get

#NUM! from the preceding MOD call? I'm running Excel 97 SR-2 and 2000

SP-3
on this particular machine.




  #9  
Old October 7th, 2003, 06:33 PM
Harlan Grove
external usenet poster
 
Posts: n/a
Default Bug in Excel's (not VBA's) MOD function

"J.E. McGimpsey" wrote...
"Harlan*Grove" wrote:

...
Given their big "mea culpa" on statistical functions,

http://support.microsoft.com/?kbid=828888

I'm hopeful.


OK, so how does one submit a bug report for Excel to Microsoft without having to
call their support number and pay for the priviledge of reporting it?

--
Never attach files.
Snip unnecessary quoted text.
Never multipost (though crossposting is usually OK).
Don't change subject lines because it corrupts Google newsgroup archives.
  #10  
Old October 7th, 2003, 06:45 PM
Harlan Grove
external usenet poster
 
Posts: n/a
Default Bug in Excel's (not VBA's) MOD function

"Harlan*Grove" wrote...
"Harlan Grove" wrote...
...
For instance, MOD(12345678000,64) returns #NUM! . . .

...

FWIW, the Works 2000 (ver 5) spreadsheet also returns an error, but
OpenOffice Calc 1.0 returns 48 as expected. While I haven't tested this
under other spreadsheets (yet), I think it's safe to say this, er,
functionality is unique to Microsoft.


And FWIW, Lotus 123 releases 5 and 9.7, Quattro Pro 10 and OpenOffice Calc 1.1
all give the correct/expected result of 48. I'm not going to bother testing
various windows shareware/freeware or Linux spreadsheets.


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 03:51 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.