> On some other thread i read, that core has different version on linux than
> windows (4.80 vs 4.79).
> Maybe they just do different computation? Maybe difference is too big?
For database reasons we are currently keeping a separate minor version number for each architecture. However, the Apps 4.78/79/80 are built from exactly the same (science) code.
A stunningly simple example for architecture and rounding issues is (int)(10*0.3) (described here).
> Not sure what calculator you used to come to 1/2=4.9999999999999 John,
> but I would throw it in the bin and use some old fashioned paper and a pencil.
> ;)
>
You had better throw your computer in the trash then. That is the answer most computers will come up with if you are not careful how you program the expression. The way I typed it normally expands to int(1)/int(2)=float(4.99999999) notice the mixed numeric types. If you force all float type numbers float(1.0000000)/float(2.000000)=float(5.000000) it will normally get the correct answer.
Where this really affects things like how well the validator works is: computation1 yeilds result 1.23456789 on one platform and 1.23456788 on another platform. That is not much different and would be considered correct either way however the final result might do that computation many times and each time that little difference gets multiplied. Multiply that enough times and you get answers that are different enough not to match.
In the real calculations done for the project double percision numbers are most likely used. They are generally stored internally at 80 bits and then rounded to 64 bits when the result is sent back. This is done to reduce the rounding errors but they do creep in.
> > Not sure what calculator you used to come to 1/2=4.9999999999999
> John,
> > but I would throw it in the bin and use some old fashioned paper and a
> pencil.
> > ;)
> >
> You had better throw your computer in the trash then. That is the answer most
> computers will come up with if you are not careful how you program the
> expression. The way I typed it normally expands to
> int(1)/int(2)=float(4.99999999) notice the mixed numeric types. If you force
> all float type numbers float(1.0000000)/float(2.000000)=float(5.000000) it
> will normally get the correct answer.
What do you get when you divide 1 by 2?
your answer : 4.99999999
my answer : one half
my good old slide rule : 0.49999999
my mathematics teacher : there is a solution to your problem
my computer : 42
And one more piece of evidence that this project is too generous when it comes to resources of contributors. Another thing is the fourfold calculation of the same workunit when just two "identical" results are enough to mark the outcome as valid. What about sending 1 WU to only two sites first and use the third site only to select the liar in the case of different results? And if we get three divers reports, well, is it still science? The code really should be robust enough not to allow that. Wijata is right, we probably should wait some time until E@H matures.
> Well i guess there are some differences in computation
>between linux and windows versions.
>
> I guess it's time for developers to say something here....
Actually, it seems they are aware of the problem and looking at it. Take a look at this thread.
> Actually, it seems they are aware of the problem and looking at it.
We are. It turned out that it's not done by just adjusting some parameters, but we need to change the validator as a whole, which means basically to rewrite it. We are working on this.
>> Actually, it seems they are aware of the problem and
>>looking at it....
>
> We are. It turned out that it's not done by just adjusting
>some parameters, but we need to change the validator as a whole,
>which means basically to rewrite it. We are working on this.
Ouch, sounds like a big job. I wish you well with it!
> On some other thread i
)
> On some other thread i read, that core has different version on linux than
> windows (4.80 vs 4.79).
> Maybe they just do different computation? Maybe difference is too big?
For database reasons we are currently keeping a separate minor version number for each architecture. However, the Apps 4.78/79/80 are built from exactly the same (science) code.
A stunningly simple example for architecture and rounding issues is (int)(10*0.3) (described here).
BM
BM
> A stunningly simple example
)
> A stunningly simple example for architecture and rounding issues is
> (int)(10*0.3) (described here).
How can the project trust ANY of the results it's getting? The choice of which result is "canonical" seems to be pretty arbitrary.
> Not sure what calculator
)
> Not sure what calculator you used to come to 1/2=4.9999999999999 John,
> but I would throw it in the bin and use some old fashioned paper and a pencil.
> ;)
>
You had better throw your computer in the trash then. That is the answer most computers will come up with if you are not careful how you program the expression. The way I typed it normally expands to int(1)/int(2)=float(4.99999999) notice the mixed numeric types. If you force all float type numbers float(1.0000000)/float(2.000000)=float(5.000000) it will normally get the correct answer.
Where this really affects things like how well the validator works is: computation1 yeilds result 1.23456789 on one platform and 1.23456788 on another platform. That is not much different and would be considered correct either way however the final result might do that computation many times and each time that little difference gets multiplied. Multiply that enough times and you get answers that are different enough not to match.
In the real calculations done for the project double percision numbers are most likely used. They are generally stored internally at 80 bits and then rounded to 64 bits when the result is sent back. This is done to reduce the rounding errors but they do creep in.
BOINC WIKI
BOINCing since 2002/12/8
> > Not sure what calculator
)
> > Not sure what calculator you used to come to 1/2=4.9999999999999
> John,
> > but I would throw it in the bin and use some old fashioned paper and a
> pencil.
> > ;)
> >
> You had better throw your computer in the trash then. That is the answer most
> computers will come up with if you are not careful how you program the
> expression. The way I typed it normally expands to
> int(1)/int(2)=float(4.99999999) notice the mixed numeric types. If you force
> all float type numbers float(1.0000000)/float(2.000000)=float(5.000000) it
> will normally get the correct answer.
What do you get when you divide 1 by 2?
your answer : 4.99999999
my answer : one half
my good old slide rule : 0.49999999
my mathematics teacher : there is a solution to your problem
my computer : 42
SCNR
Back to real problem, it's
)
Back to real problem, it's depressing, look at my linux hosts
Should I quit contributing to E@H ???
Here
Here
Here
Here
Sobbing...
I am also having this
)
I am also having this problem.
Link.
And one more piece of
)
And one more piece of evidence that this project is too generous when it comes to resources of contributors. Another thing is the fourfold calculation of the same workunit when just two "identical" results are enough to mark the outcome as valid. What about sending 1 WU to only two sites first and use the third site only to select the liar in the case of different results? And if we get three divers reports, well, is it still science? The code really should be robust enough not to allow that. Wijata is right, we probably should wait some time until E@H matures.
Hi, > Well i guess there
)
Hi,
> Well i guess there are some differences in computation
>between linux and windows versions.
>
> I guess it's time for developers to say something here....
Actually, it seems they are aware of the problem and looking at it. Take a look at this thread.
TTFN - Pete.
> Actually, it seems they are
)
> Actually, it seems they are aware of the problem and looking at it.
We are. It turned out that it's not done by just adjusting some parameters, but we need to change the validator as a whole, which means basically to rewrite it. We are working on this.
BM
BM
Hi, >> Actually, it
)
Hi,
>> Actually, it seems they are aware of the problem and
>>looking at it....
>
> We are. It turned out that it's not done by just adjusting
>some parameters, but we need to change the validator as a whole,
>which means basically to rewrite it. We are working on this.
Ouch, sounds like a big job. I wish you well with it!
Thanks for the information.
TTFN - Pete.