1. Rob's going to hate me... (Remainder bug)
Heh, twice in a week, lol
? remainder(100,0.01)
gives 0.01 and I am sure that's not supposed to happen
This is reproducable with all numbers <= 0.2
for some reason, all numbers > .2 work as they should.
Also, this only affects numbers which are cleanly divisable.
? remainder(100.001,0.01) returns 0.001 as it should
Running Euphoria 2.4
2. Re: Rob's going to hate me... (Remainder bug)
Urzumph wrote:
> Heh, twice in a week, lol
> ? remainder(100,0.01)
> gives 0.01 and I am sure that's not supposed to happen
> This is reproducable with all numbers <= 0.2
> for some reason, all numbers > .2 work as they should.
> Also, this only affects numbers which are cleanly divisable.
> ? remainder(100.001,0.01) returns 0.001 as it should
>
> Running Euphoria 2.4
Au contraire. He's going to love you for helping make EUPHORIA more
robust. ;)
3. Re: Rob's going to hate me... (Remainder bug)
Urzumph wrote:
> Heh, twice in a week, lol
> ? remainder(100,0.01)
> gives 0.01 and I am sure that's not supposed to happen
> This is reproducable with all numbers <= 0.2
> for some reason, all numbers > .2 work as they should.
> Also, this only affects numbers which are cleanly divisable.
> ? remainder(100.001,0.01) returns 0.001 as it should
Don't lol too hard.
Your first one wasn't a bug, and neither is this one.
This remainder issue came up on the mailing list
a few years ago. It's basically an incarnation of the old
"0.1 (0.01 etc.) can't be represented exactly on
Intel hardware" problem. Once or twice every year
someone on this list is shocked to find that
floating-point calculations aren't perfectly exact,
and the error can sometimes be magnified into an
obviously incorrect answer...
http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=2&fromYear=5&toMonth=2&toYear=5&postedBy=rds&keywords=remainder
(the URL might wrap - be careful)
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Rob's going to hate me... (Remainder bug)
- Posted by kbochert at copper.net
Nov 07, 2003
On 7 Nov 2003 at 1:30, Robert Craig wrote:
>
>
> Urzumph wrote:
> > Heh, twice in a week, lol
> > ? remainder(100,0.01)
> > gives 0.01 and I am sure that's not supposed to happen
> > This is reproducable with all numbers <= 0.2
> > for some reason, all numbers > .2 work as they should.
> > Also, this only affects numbers which are cleanly divisable.
> > ? remainder(100.001,0.01) returns 0.001 as it should
>
> Don't lol too hard.
> Your first one wasn't a bug, and neither is this one.
>
> This remainder issue came up on the mailing list
> a few years ago. It's basically an incarnation of the old
> "0.1 (0.01 etc.) can't be represented exactly on
> Intel hardware" problem. Once or twice every year
> someone on this list is shocked to find that
> floating-point calculations aren't perfectly exact,
> and the error can sometimes be magnified into an
> obviously incorrect answer...
>
>
> http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=2&fromYear=5&toMonth=2&toYear=5&postedBy=rds&keywords=remainder
>
> (the URL might wrap - be careful)
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>From a number of sources:
"The fmod() function returns the value x - i * y, for some
integer i, such that, if y is non-zero, the result has the
same sign as x and magnitude less than the
magnitude of y.
in Dremainder():
double x, y;
if (b->dbl < 1) { // fmod() seems to sometimes goof this!
x = a->dbl < 0? -a->dbl: a->dbl;
y = b->dbl < 0? -b->dbl: b->dbl;
x = x - floor(x / y) * y;
if (a->dbl < 0) // sign matches a
return (object)NewDouble(-x);
return (object)NewDouble(x);
}
Works for the (100, .01) case (and others I have tried).
This leads me to believe that it is a bug in the implementation
of fmod() (In Intel's hardware?).
Maybe remainders of fractional divisors are seldom done??
Can also be done in Eu code, of course.
Ktb
Note that the above code is invoked for both fractional and negative
divisors -- both work fine.
5. Re: Rob's going to hate me... (Remainder bug)
kbochert at copper.net wrote:
>>From a number of sources:
> "The fmod() function returns the value x - i * y, for some
> integer i, such that, if y is non-zero, the result has the
> same sign as x and magnitude less than the
> magnitude of y.
>
>
> in Dremainder():
>
> double x, y;
> if (b->dbl < 1) { // fmod() seems to sometimes goof this!
> x = a->dbl < 0? -a->dbl: a->dbl;
> y = b->dbl < 0? -b->dbl: b->dbl;
> x = x - floor(x / y) * y;
> if (a->dbl < 0) // sign matches a
> return (object)NewDouble(-x);
> return (object)NewDouble(x);
> }
>
> Works for the (100, .01) case (and others I have tried).
> This leads me to believe that it is a bug in the implementation
> of fmod() (In Intel's hardware?).
I doubt it.
> Maybe remainders of fractional divisors are seldom done??
>
> Can also be done in Eu code, of course.
>
> Ktb
>
> Note that the above code is invoked for both fractional and negative
> divisors -- both work fine.
I'm sure, by changing the way something is calculated,
you can often eliminate anomalies for some cases.
But you can't eliminate the fundamental mathematical
problem with finite-precision floating-point.
Because it only uses a finite number of digits,
Intel (and most other) floating-point hardware can't
represent all numbers with perfect accuracy.
As humans who use the decimal system we are
surprised to find that numbers like .1 .01 etc.
can't be represented perfectly in Intel's
binary floating-point system.
Instead, the hardware uses something like .01 +/- epsilon to
represent .01, where epsilon is a very tiny positive number.
In remainder(100, .01),
suppose the hardware uses .01 + epsilon.
To calculate the remainder after dividing 100 by
(.01 + epsilon), we see that
99 * (.01 + epsilon) = .99 + 99 * epsilon
which is as high as we can get before we exceed 100.
So we will say:
100 = 99 * (.01 + epsilon)
with a remainder of .01 - 99 * epsilon
When we print this remainder to (say) 10 digits,
we will see: 0.01, a far cry from the 0 we expected.
If on the other hand, the machine uses .01 - epsilon,
We will have:
100 = 100 * (.01 - epsilon)
with a remainder of 100 * epsilon
When we print this remainder, we will see 0 as we expected.
I still like the simpler example:
if 1.0 != .1 + .1 + .1 + .1 + .1 +
.1 + .1 + .1 + .1 + .1 then
puts(1, "Not accurate!!!\n")
end if
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: Rob's going to hate me... (Remainder bug)
----- Original Message -----
From: "Urzumph" <Urzumph at HotPOP.com>
To: "Mailing List" <EUforum at topica.com>
Subject: Rob's going to hate me... (Remainder bug)
>
>
> Heh, twice in a week, lol
> ? remainder(100,0.01)
> gives 0.01 and I am sure that's not supposed to happen
> This is reproducable with all numbers <= 0.2
> for some reason, all numbers > .2 work as they should.
> Also, this only affects numbers which are cleanly divisable.
> ? remainder(100.001,0.01) returns 0.001 as it should
>
> Running Euphoria 2.4
>
Try this then...
function rmder(atom a, atom b)
atom x
x = a / b
return (x - floor(x)) * b
end function
? remainder(100, 0.01)
? rmder(100, 0.01)
? remainder(100, 0.2)
? rmder(100, 0.2)
? remainder(100, 1.01)
? rmder(100, 1.01)
7. Re: Rob's going to hate me... (Remainder bug)
- Posted by kbochert at copper.net
Nov 07, 2003
On 7 Nov 2003 at 15:11, Robert Craig wrote:
>
>
> kbochert at copper.net wrote:
> >>From a number of sources:
> > "The fmod() function returns the value x - i * y, for some
> > integer i, such that, if y is non-zero, the result has the
> > same sign as x and magnitude less than the
> > magnitude of y.
> >
> >
> > in Dremainder():
> >
> > double x, y;
> > if (b->dbl < 1) { // fmod() seems to sometimes goof this!
> > x = a->dbl < 0? -a->dbl: a->dbl;
> > y = b->dbl < 0? -b->dbl: b->dbl;
> > x = x - floor(x / y) * y;
> > if (a->dbl < 0) // sign matches a
> > return (object)NewDouble(-x);
> > return (object)NewDouble(x);
> > }
> >
> > Works for the (100, .01) case (and others I have tried).
> > This leads me to believe that it is a bug in the implementation
> > of fmod() (In Intel's hardware?).
>
> I doubt it.
>
> > Maybe remainders of fractional divisors are seldom done??
> >
> > Can also be done in Eu code, of course.
> >
> > Ktb
> >
> > Note that the above code is invoked for both fractional and negative
> > divisors -- both work fine.
>
> I'm sure, by changing the way something is calculated,
> you can often eliminate anomalies for some cases.
> But you can't eliminate the fundamental mathematical
> problem with finite-precision floating-point.
>
> Because it only uses a finite number of digits,
> Intel (and most other) floating-point hardware can't
> represent all numbers with perfect accuracy.
> As humans who use the decimal system we are
> surprised to find that numbers like .1 .01 etc.
> can't be represented perfectly in Intel's
> binary floating-point system.
> Instead, the hardware uses something like .01 +/- epsilon to
> represent .01, where epsilon is a very tiny positive number.
>
> In remainder(100, .01),
> suppose the hardware uses .01 + epsilon.
> To calculate the remainder after dividing 100 by
> (.01 + epsilon), we see that
> 99 * (.01 + epsilon) = .99 + 99 * epsilon
> which is as high as we can get before we exceed 100.
> So we will say:
> 100 = 99 * (.01 + epsilon)
> with a remainder of .01 - 99 * epsilon
> When we print this remainder to (say) 10 digits,
> we will see: 0.01, a far cry from the 0 we expected.
>
> If on the other hand, the machine uses .01 - epsilon,
> We will have:
> 100 = 100 * (.01 - epsilon)
> with a remainder of 100 * epsilon
> When we print this remainder, we will see 0 as we expected.
>
> I still like the simpler example:
>
> if 1.0 != .1 + .1 + .1 + .1 + .1 +
> .1 + .1 + .1 + .1 + .1 then
> puts(1, "Not accurate!!!\n")
> end if
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
It seems to me that given that fmod(a,b) is defined as returning a value
which is less than b, failure to do so is not just inaccurate but a real bug.
>From a Google search:
http://www.boic.com/b1mnum.pdf. (dated Nov 3 2003 !!)
QUOTE:
Appendix
Microsoft Modulo Bugs
Over the years of testing of the Number Class, we've discovered nasty bugs in
Microsoft's fmod()
function, which you can easily confirm for yourself. For example, using the
Windows
95 Calculator
accessory (evidently built on the same fmod function) try this simple
calculation:
5.5 mod 1.1
Instead of giving the correct result, which should be 0, it shows the result as
1.1.
Similar errors are not
hard to find, e.g. try 5.1 mod 1.7, 49 mod 9.8, 21.9 mod 7.3, and 36 mod 7.2.
Interestingly, this
problem occurs only with certain choices of values and the pattern of failures
is not
trivially discerned,
but there are obviously many more cases. In fact we found it increasingly rare
not to
encounter such
errors with more decimal places. We were unable to find any reference to this
disturbing bug in the
Microsoft Knowledge Base.
Considering how much flack Intel took over an even more obscure arithmetic bug
in
its Pentium
processor, one can only wonder how Microsoft ever got away with this one.
Fortunately, the problem
seems to have been quietly fixed in Windows 98, but that's not much consolation
to
those of us who
expect our programs to work properly under Windows 95 and early versions of
Windows NT 4.0. In
any case, rest assured that the Base/1 Number Class computes the modulo function
correctly under any
version of Windows.
The modulo bug described above seems to have been fixed in the latest operating
systems and service
packs from Microsoft. However, here's a new one we discovered in recent testing
of
the Number
Class:
d1 = 8853.41959899;
d2 = 2951.13986633;
fmod( d1, d2 ) returns the same value as that of d2 instead of returning zero.
In this
example, d1 is a
perfect multiple of d2 (d1 = d2 * 3). We got this error on Windows NT Service
Pack
5 and 6a and
Windows 2000 server. For some versions, the bug did NOT appear in the calculator
program, but
using fmod() ALWAYS produces this bug. The Number Class properly returns the
correct remainder of zero
UNQUOTE
Ktb
8. Re: Rob's going to hate me... (Remainder bug)
- Posted by kbochert at copper.net
Nov 07, 2003
On 8 Nov 2003 at 8:10, Derek Parnell wrote:
>
>
> ----- Original Message -----
> From: "Urzumph" <Urzumph at HotPOP.com>
> To: "Mailing List" <EUforum at topica.com>
> Subject: Rob's going to hate me... (Remainder bug)
>
>
> > Heh, twice in a week, lol
> > ? remainder(100,0.01)
> > gives 0.01 and I am sure that's not supposed to happen
> > This is reproducable with all numbers <= 0.2
> > for some reason, all numbers > .2 work as they should.
> > Also, this only affects numbers which are cleanly divisable.
> > ? remainder(100.001,0.01) returns 0.001 as it should
> >
> > Running Euphoria 2.4
> >
>
> Try this then...
>
> function rmder(atom a, atom b)
> atom x
> x = a / b
> return (x - floor(x)) * b
> end function
>
>
> ? remainder(100, 0.01)
> ? rmder(100, 0.01)
>
> ? remainder(100, 0.2)
> ? rmder(100, 0.2)
>
> ? remainder(100, 1.01)
> ? rmder(100, 1.01)
>
Yes, but don't forget about negative arguments.
remainder, like fmod(), is defined to return a result of the same sign
as its first argument.
(took me about a dozen tries to get it right!)
ktb
9. Re: Rob's going to hate me... (Remainder bug)
kbochert at copper.net wrote:
> It seems to me that given that fmod(a,b) is defined as returning a value
> which is less than b, failure to do so is not just inaccurate but a real bug.
I'm sure it *does* return a value less than b.
But when you print a result such as 0.01 - 99 * epsilon
to 10 significant digits, like Euphoria does by default,
you see: 0.01
>>From a Google search:
> http://www.boic.com/b1mnum.pdf. (dated Nov 3 2003 !!)
>
> QUOTE:
> Appendix
> Microsoft Modulo Bugs
> Over the years of testing of the Number Class, we've discovered nasty bugs in
> Microsoft's fmod()
> function, which you can easily confirm for yourself. For example, using the
> Windows
> 95 Calculator
> accessory (evidently built on the same fmod function) try this simple
> calculation:
> 5.5 mod 1.1
> Instead of giving the correct result, which should be 0,
> it shows the result as 1.1.
> ...
This person obviously is not aware of the pitfalls of
binary, limited-precision floating-point.
> We were unable to find any reference to this
> disturbing bug in the
> Microsoft Knowledge Base.
Because it's not really a bug in the library.
It's a limitation of the floating-point hardware.
> ... For some versions, the bug did NOT appear in the calculator
> program, but
> using fmod() ALWAYS produces this bug.
No doubt because the calculator program uses
*decimal* floating-point, where numbers like 0.1, 0.01 etc.
*can* be represented with perfect accuracy (but then
lots of other numbers can't, so this is not a
perfect solution either.)
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
10. Re: Rob's going to hate me... (Remainder bug)
- Posted by kbochert at copper.net
Nov 08, 2003
On 7 Nov 2003 at 18:07, Robert Craig wrote:
>
>
> kbochert at copper.net wrote:
> > It seems to me that given that fmod(a,b) is defined as returning a value
> > which is less than b, failure to do so is not just inaccurate but a real
> > bug.
>
> I'm sure it *does* return a value less than b.
> But when you print a result such as 0.01 - 99 * epsilon
> to 10 significant digits, like Euphoria does by default,
> you see: 0.01
>
Yes it does. A value is calculated that looks like .00999... which rounds to .01
But note that even with a precise decimal (extending to infinity) the result is
nearly as bad as it can be. (Given that it must be less than .01).
Whats at fault is the algorithm, which can magnify small errors into disasters.
Consider instead:
rslt = X - floor( X/Y) * Y
Slight inaccuracies in the subtraction or multiplication leave you with small
inaccuracies in the result.
A slight inaccuracy in the division can cause the floor function to return a
value that
is (exactly) one too small, which multiplied by Y gives a value that is Y too
small,
and subtracted from X gives a result that is exactly Y too large, a huge error
just
like we see now.
For floor(X/Y) to produce this kind of step error requires that X/Y be very
close
to an integral value. So either X is a multiple of Y, in which case the result
can be
Y when it should be 0, or they are near values whose difference is close to the
accuracy
limits of a double (Like 111111111111 /111111111112, or some such)
So:
rslt = X - floor (X/Y) * Y
if (rslt == Y)
rslt = 0
The step error can still happen, but it is confined to more uncommon cases.
> >>From a Google search:
> > http://www.boic.com/b1mnum.pdf. (dated Nov 3 2003 !!)
> >
> > QUOTE:
> > Appendix
> > Microsoft Modulo Bugs
> > Over the years of testing of the Number Class, we've discovered nasty bugs
> > in
> > Microsoft's fmod()
> > function, which you can easily confirm for yourself. For example, using the
> > Windows
> > 95 Calculator
> > accessory (evidently built on the same fmod function) try this simple
> > calculation:
> > 5.5 mod 1.1
> > Instead of giving the correct result, which should be 0,
> > it shows the result as 1.1.
> > ...
>
> This person obviously is not aware of the pitfalls of
> binary, limited-precision floating-point.
>
> > We were unable to find any reference to this
> > disturbing bug in the
> > Microsoft Knowledge Base.
>
> Because it's not really a bug in the library.
> It's a limitation of the floating-point hardware.
>
Exacerbated by a fragile algorithm.
> > ... For some versions, the bug did NOT appear in the calculator
> > program, but
> > using fmod() ALWAYS produces this bug.
>
> No doubt because the calculator program uses
> *decimal* floating-point, where numbers like 0.1, 0.01 etc.
> *can* be represented with perfect accuracy (but then
> lots of other numbers can't, so this is not a
> perfect solution either.)
>
Would be good for checking the results of the binary math.
KtB
11. Re: Rob's going to hate me... (Remainder bug)
- Posted by kbochert at copper.net
Nov 08, 2003
On 7 Nov 2003 at 18:07, Robert Craig wrote:
>
>
> kbochert at copper.net wrote:
> > It seems to me that given that fmod(a,b) is defined as returning a value
> > which is less than b, failure to do so is not just inaccurate but a real
> > bug.
>
> I'm sure it *does* return a value less than b.
> But when you print a result such as 0.01 - 99 * epsilon
> to 10 significant digits, like Euphoria does by default,
> you see: 0.01
>
> >>From a Google search:
> > http://www.boic.com/b1mnum.pdf. (dated Nov 3 2003 !!)
> >
> > QUOTE:
> > Appendix
> > Microsoft Modulo Bugs
> > Over the years of testing of the Number Class, we've discovered nasty bugs
> > in
> > Microsoft's fmod()
> > function, which you can easily confirm for yourself. For example, using the
> > Windows
> > 95 Calculator
> > accessory (evidently built on the same fmod function) try this simple
> > calculation:
> > 5.5 mod 1.1
> > Instead of giving the correct result, which should be 0,
> > it shows the result as 1.1.
> > ...
>
> This person obviously is not aware of the pitfalls of
> binary, limited-precision floating-point.
>
> > We were unable to find any reference to this
> > disturbing bug in the
> > Microsoft Knowledge Base.
>
> Because it's not really a bug in the library.
> It's a limitation of the floating-point hardware.
>
> > ... For some versions, the bug did NOT appear in the calculator
> > program, but
> > using fmod() ALWAYS produces this bug.
>
> No doubt because the calculator program uses
> *decimal* floating-point, where numbers like 0.1, 0.01 etc.
> *can* be represented with perfect accuracy (but then
> lots of other numbers can't, so this is not a
> perfect solution either.)
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
Update:
I think you are right. Seems a pity though. Loss of accuracy is one thing
but flat out wrong results from ordinary inputs is bothersome.
Bach may add a default argument, the precision, and round the division
internally
KtB
12. Re: Rob's going to hate me... (Remainder bug)
----- Original Message -----
From: <kbochert at copper.net>
To: <EUforum at topica.com>
Subject: Re: Rob's going to hate me... (Remainder bug)
>
>
> On 8 Nov 2003 at 8:10, Derek Parnell wrote:
>
> >
> > ----- Original Message -----
> > From: "Urzumph" <Urzumph at HotPOP.com>
> > To: "Mailing List" <EUforum at topica.com>
> > Sent: Friday, November 07, 2003 11:19 AM
> > Subject: Rob's going to hate me... (Remainder bug)
> >
> >
> > > Heh, twice in a week, lol
> > > ? remainder(100,0.01)
> > > gives 0.01 and I am sure that's not supposed to happen
> > > This is reproducable with all numbers <= 0.2
> > > for some reason, all numbers > .2 work as they should.
> > > Also, this only affects numbers which are cleanly divisable.
> > > ? remainder(100.001,0.01) returns 0.001 as it should
> > >
> > > Running Euphoria 2.4
> > >
> >
> > Try this then...
> >
> > function rmder(atom a, atom b)
> > atom x
> > x = a / b
> > return (x - floor(x)) * b
> > end function
> >
> >
> > ? remainder(100, 0.01)
> > ? rmder(100, 0.01)
> >
> > ? remainder(100, 0.2)
> > ? rmder(100, 0.2)
> >
> > ? remainder(100, 1.01)
> > ? rmder(100, 1.01)
> >
> Yes, but don't forget about negative arguments.
> remainder, like fmod(), is defined to return a result of the same sign
> as its first argument.
> (took me about a dozen tries to get it right!)
> ktb
>
Ok then, how about ...
function rmder(atom a, atom b)
atom x
integer sign
if a < 0 then
sign = -1
a = -a
else
sign = 1
end if
if b < 0 then
b = -b
end if
x = a / b
return ((x - floor(x)) * b) * sign
end function
13. Re: Rob's going to hate me... (Remainder bug)
Wait, my bad, I can see the reason behind having the same include file
referanced by multiple namespaces now, nevermind me.
14. Re: Rob's going to hate me... (Remainder bug)
> Don't lol too hard.
> Your first one wasn't a bug, and neither is this one.
As far as I am concerned, the first one WAS a bug. If someone wants to
include the same file twice within their program, and have them act as
two completely seperate copies of the same file, they should be able to
- and the only concieveable way I can see of refering to them seperately
is by usage of the namespace function. I re-wrote my include file so it
handled being initated twice differently, but the point is, I should
have been able to do it that way.
And this one IS a bug, just not a bug with euphoria :P
> This remainder issue came up on the mailing list
> a few years ago. It's basically an incarnation of the old
> "0.1 (0.01 etc.) can't be represented exactly on
> Intel hardware" problem. Once or twice every year
> someone on this list is shocked to find that
> floating-point calculations aren't perfectly exact,
> and the error can sometimes be magnified into an
> obviously incorrect answer...
>
>
> http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=2&fromYear=5&toMonth=2&toYear=5&postedBy=rds&keywords=remainder
>
My bad - I should have checked first.
Pitty being on an AMD doesn't insulate you from that problem :(
15. Re: Rob's going to hate me... (Remainder bug)
----- Original Message -----
From: "Urzumph" <Urzumph at HotPOP.com>
To: <EUforum at topica.com>
Subject: Re: Rob's going to hate me... (Remainder bug)
>
>
> > Don't lol too hard.
> > Your first one wasn't a bug, and neither is this one.
>
> As far as I am concerned, the first one WAS a bug. If someone wants to
> include the same file twice within their program, and have them act as
> two completely seperate copies of the same file, they should be able to
> - and the only concieveable way I can see of refering to them seperately
> is by usage of the namespace function. I re-wrote my include file so it
> handled being initated twice differently, but the point is, I should
> have been able to do it that way.
>
> And this one IS a bug, just not a bug with euphoria :P
The definition of BUG that I use is "an implementation that does not conform to
the designer's specifications". Thus I do not see this as a bug, anymore than
'goto' not being supported is a bug.
Not that I'm saying that a way of multiple 'include'-ing file is a bad thing. I
would support a new key word, like 'insert', to implement this concept though and
leave 'include' alone.
--
Derek
16. Re: Rob's going to hate me... (Remainder bug)
I think it would be good to have multiple instances of the same include
running, like
include something.e {insta,instb,instc,instd,inste,instf}
but I dont know if that is a good Idea maybe havinga better handle on scope
while writing the include is better
Daniel Kluss
----- Original Message -----
From: "Urzumph" <Urzumph at HotPOP.com>
To: <EUforum at topica.com>
Sent: Friday, November 07, 2003 10:47 PM
Subject: Re: Rob's going to hate me... (Remainder bug)
>
>
> Wait, my bad, I can see the reason behind having the same include file
> referanced by multiple namespaces now, nevermind me.
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
17. Re: Rob's going to hate me... (Remainder bug)
On Saturday 08 November 2003 06:38 pm, Daniel wrote:
> I think it would be good to have multiple instances of the same include
> running, like
> include something.e {insta,instb,instc,instd,inste,instf}
> but I dont know if that is a good Idea maybe havinga better handle on
> scope while writing the include is better
It *is* a good idea. I'm doing that right now, and it is very useful.
A program I'm working on has 3 different lists. Each "include" which
managed a list (adding, deleting, editing items) was about 160 lines of code.
I've replaced those 3 with a single include, included 3 times, saving 2/3 of
the code, and making changes, bug fixes, etc. far easier (there's only one
place to fix, instead of 3)
Later, when I have 6 or 7 lists, I'll _still_ have only about 160 lines of
code driving all the lists, so the savings could be significant.
Irv
--
Robert Tappen Morris, Jr., got six months in jail for crashing 10% of the
computers that Bill Gates made $100 million crashing last weekend.
18. Re: Rob's going to hate me... (Remainder bug)
----- Original Message -----
From: "Irv Mullins" <irvm at ellijay.com>
To: <EUforum at topica.com>
Subject: Re: Rob's going to hate me... (Remainder bug)
>
>
> On Saturday 08 November 2003 06:38 pm, Daniel wrote:
>
> > I think it would be good to have multiple instances of the same include
> > running, like
> > include something.e {insta,instb,instc,instd,inste,instf}
> > but I dont know if that is a good Idea maybe havinga better handle on
> > scope while writing the include is better
>
> It *is* a good idea. I'm doing that right now, and it is very useful.
> A program I'm working on has 3 different lists. Each "include" which
> managed a list (adding, deleting, editing items) was about 160 lines of code.
> I've replaced those 3 with a single include, included 3 times, saving 2/3 of
> the code, and making changes, bug fixes, etc. far easier (there's only one
> place to fix, instead of 3)
>
> Later, when I have 6 or 7 lists, I'll _still_ have only about 160 lines of
> code driving all the lists, so the savings could be significant.
>
>
Which is exactly the effect I get in win32lib but without multiple includes.
--
Derek
19. Re: Rob's going to hate me... (Remainder bug)
On Saturday 08 November 2003 10:02 pm, you wrote:
>
> Hello Irv,
>
> That's interesting news too.
> I've been trying to convince Pete and Matt in another thread
> "Pete: Your Question"
> for the past several days now that this is a good thing 
> If you like you can check that thread to see if the
> examples make sense to you.
>
> I see Derek might not exactly be 'pro' 'new includes' either.
>
> I think it depends on how much you have already used namespace
> prefixes. If you have used them a lot then you tend to
> like this new technique it seems. The way i see it,
> everyone will catch on sooner or later
> It's a very a powerful technique of namespace useage, but
> in order to understand it people have to have see and understand
> exactly why it's so powerful. It's not just another way of
> doing something, it's doing it better in some cases.
> When something cant benefit directly from this, sometimes it's
> just plain ol faster to write and easier to maintain.
> Apparently you have already discovered the maintainence part
It's not as complete a solution as true object-orientation would be, since
there's no easy way to override "methods".
The only way I've found so far is to put the methods (routines that need to
be different for different instances) into their own small includes. This has
the unpleasant effect of increasing the number of files to juggle, and Eu's
namespacing isn't quite up to the task of putting TWO includes into the same
namespace, so the naming can get awkward.
Irv
--
Robert Tappen Morris, Jr., got six months in jail for crashing 10% of the
computers that Bill Gates made $100 million crashing last weekend.
