Yesterday I had to write a program which rescaled and rounded off some coordinates for use in a lab. I found something that worries me quite a bit:
({ /* 22 elements */ ({ /* 2 elements */ 639.000000, 37.000000 }), ({ /* 2 elements */ 426.000000, 99.000000 }), ({ /* 2 elements */ 538.000000, 103.000000 }), ({ /* 2 elements */ 698.000000, 105.000000 }), ({ /* 2 elements */ 813.000000, 104.000000 }), ({ /* 2 elements */ 480.000000, 199.000000 }), ({ /* 2 elements */ 633.000000, 195.000000 }), ({ /* 2 elements */ 780.000000, 196.000000 }), ({ /* 2 elements */ 480.000000, 304.000000 }), ({ /* 2 elements */ 636.000000, 308.000000 }), ({ /* 2 elements */ 785.000000, 309.000000 }), ({ /* 2 elements */ 425.000000, 388.000000 }), ({ /* 2 elements */ 536.000000, 397.000000 }), ({ /* 2 elements */ 700.000000, 401.000000 }), ({ /* 2 elements */ 814.000000, 399.000000 }), ({ /* 2 elements */ 625.000000, 457.000000 }), ({ /* 2 elements */ 480.000000, 252.000000 }), ({ /* 2 elements */ 633.000000, 256.000000 }), ({ /* 2 elements */ 780.000000, 259.000000 }), ({ /* 2 elements */ 480.000000, 349.000000 }), ({ /* 2 elements */ 636.000000, 347.000000 }), ({ /* 2 elements */ 785.000000, 358.000000 }) }) ({ /* 22 elements */ ({ /* 2 elements */ 63.900002, 3.700000 }), ({ /* 2 elements */ 42.599998, 9.900000 }), ({ /* 2 elements */ 53.799999, 10.300000 }), ({ /* 2 elements */ 69.800003, 10.500000 }), ({ /* 2 elements */ 81.300003, 10.400000 }), ({ /* 2 elements */ 48.000000, 19.900000 }), ({ /* 2 elements */ 63.299999, 19.500000 }), ({ /* 2 elements */ 78.000000, 19.600000 }), ({ /* 2 elements */ 48.000000, 30.400000 }), ({ /* 2 elements */ 63.599998, 30.799999 }), ({ /* 2 elements */ 78.500000, 30.900000 }), ({ /* 2 elements */ 42.500000, 38.799999 }), ({ /* 2 elements */ 53.599998, 39.700001 }), ({ /* 2 elements */ 70.000000, 40.099998 }), ({ /* 2 elements */ 81.400002, 39.900002 }), ({ /* 2 elements */ 62.500000, 45.700001 }), ({ /* 2 elements */ 48.000000, 25.200001 }), ({ /* 2 elements */ 63.299999, 25.600000 }), ({ /* 2 elements */ 78.000000, 25.900000 }), ({ /* 2 elements */ 48.000000, 34.900002 }), ({ /* 2 elements */ 63.599998, 34.700001 }), ({ /* 2 elements */ 78.500000, 35.799999 }) }) [agehall@omicron ~] pike --version Pike v7.5 release 1 Copyright © 1994-2002 Linköping University Pike comes with ABSOLUTELY NO WARRANTY; This is free software and you are welcome to redistribute it under certain conditions; Read the files COPYING and COPYRIGHT in the Pike distribution for more details.
The first array(array(float)) are the values as read from the file. The second array(array(float)) contains the values divided by 10. Note how some numbers become +-0.000001. This is very strange and not very good at all... I am able to reproduce the bug by doing
358.0/10;
(1) Result: 35.799999
on both my PPro/Linux running Pike 7.5 and a Sun/Solaris running Pike 7.3. Is this a known bug and is there a workaround?
It's called floats. Floats are not exact. Try the following C-program:
#include <stdio.h> int main() { printf("%f %f\n", (float)35.8, 35.8); return 0; }
If you want exact calculations you don't want floats. Of course, if you compile with with doubles rather than floats, you get better approximations (but still not exact).
/ David Hedbor
Previous text:
2003-02-25 09:29: Subject: Do we have a floatingpoint bug?
Yesterday I had to write a program which rescaled and rounded off some coordinates for use in a lab. I found something that worries me quite a bit:
({ /* 22 elements */ ({ /* 2 elements */ 639.000000, 37.000000 }), ({ /* 2 elements */ 426.000000, 99.000000 }), ({ /* 2 elements */ 538.000000, 103.000000 }), ({ /* 2 elements */ 698.000000, 105.000000 }), ({ /* 2 elements */ 813.000000, 104.000000 }), ({ /* 2 elements */ 480.000000, 199.000000 }), ({ /* 2 elements */ 633.000000, 195.000000 }), ({ /* 2 elements */ 780.000000, 196.000000 }), ({ /* 2 elements */ 480.000000, 304.000000 }), ({ /* 2 elements */ 636.000000, 308.000000 }), ({ /* 2 elements */ 785.000000, 309.000000 }), ({ /* 2 elements */ 425.000000, 388.000000 }), ({ /* 2 elements */ 536.000000, 397.000000 }), ({ /* 2 elements */ 700.000000, 401.000000 }), ({ /* 2 elements */ 814.000000, 399.000000 }), ({ /* 2 elements */ 625.000000, 457.000000 }), ({ /* 2 elements */ 480.000000, 252.000000 }), ({ /* 2 elements */ 633.000000, 256.000000 }), ({ /* 2 elements */ 780.000000, 259.000000 }), ({ /* 2 elements */ 480.000000, 349.000000 }), ({ /* 2 elements */ 636.000000, 347.000000 }), ({ /* 2 elements */ 785.000000, 358.000000 }) }) ({ /* 22 elements */ ({ /* 2 elements */ 63.900002, 3.700000 }), ({ /* 2 elements */ 42.599998, 9.900000 }), ({ /* 2 elements */ 53.799999, 10.300000 }), ({ /* 2 elements */ 69.800003, 10.500000 }), ({ /* 2 elements */ 81.300003, 10.400000 }), ({ /* 2 elements */ 48.000000, 19.900000 }), ({ /* 2 elements */ 63.299999, 19.500000 }), ({ /* 2 elements */ 78.000000, 19.600000 }), ({ /* 2 elements */ 48.000000, 30.400000 }), ({ /* 2 elements */ 63.599998, 30.799999 }), ({ /* 2 elements */ 78.500000, 30.900000 }), ({ /* 2 elements */ 42.500000, 38.799999 }), ({ /* 2 elements */ 53.599998, 39.700001 }), ({ /* 2 elements */ 70.000000, 40.099998 }), ({ /* 2 elements */ 81.400002, 39.900002 }), ({ /* 2 elements */ 62.500000, 45.700001 }), ({ /* 2 elements */ 48.000000, 25.200001 }), ({ /* 2 elements */ 63.299999, 25.600000 }), ({ /* 2 elements */ 78.000000, 25.900000 }), ({ /* 2 elements */ 48.000000, 34.900002 }), ({ /* 2 elements */ 63.599998, 34.700001 }), ({ /* 2 elements */ 78.500000, 35.799999 }) }) [agehall@omicron ~] pike --version Pike v7.5 release 1 Copyright © 1994-2002 Linköping University Pike comes with ABSOLUTELY NO WARRANTY; This is free software and you are welcome to redistribute it under certain conditions; Read the files COPYING and COPYRIGHT in the Pike distribution for more details.
The first array(array(float)) are the values as read from the file. The second array(array(float)) contains the values divided by 10. Note how some numbers become +-0.000001. This is very strange and not very good at all... I am able to reproduce the bug by doing
358.0/10;
(1) Result: 35.799999
on both my PPro/Linux running Pike 7.5 and a Sun/Solaris running Pike 7.3. Is this a known bug and is there a workaround?
/ Marcus Agehall (Trådlös)
given the bignum library which supports unlimited integers, how about a "float" type that supports precise calculations?
it could be as simple as taking a bignum and adding an exponent to it.
ie: 3.141593 store as 3141593 with exponent 6.
the necessary conversions to allow calculations could then be handled in pike internally instead of burdening the user if he/she needs to avoid the usual floating point problems.
greetings, martin.
Why do the work all over again when there is Gmp.mpq? :-)
Pike v7.4 release 13 running Hilfe v3.5 (Incremental Pike Frontend)
Gmp.mpq(3580,100);
(1) Result: 179/5
(float)_;
(2) Result: 35.799999
/ Johan Sundström (a hugging punishment!)
Previous text:
2003-02-25 10:04: Subject: Re: Do we have a floatingpoint bug?
given the bignum library which supports unlimited integers, how about a "float" type that supports precise calculations?
it could be as simple as taking a bignum and adding an exponent to it.
ie: 3.141593 store as 3141593 with exponent 6.
the necessary conversions to allow calculations could then be handled in pike internally instead of burdening the user if he/she needs to avoid the usual floating point problems.
greetings, martin.
/ Brevbäraren
i knew there had to be something, but i was actually suggesting to make that available in the regular pike float type (just like bignum is available in the int type)
greetings, martin.
That's highly dangerous.
Say that you want to calculate 1/3. When do you stop expanding digits?
/ Per Hedbor ()
Previous text:
2003-02-25 10:17: Subject: Re: Do we have a floatingpoint bug?
i knew there had to be something, but i was actually suggesting to make that available in the regular pike float type (just like bignum is available in the int type)
greetings, martin.
/ Brevbäraren
On Tue, 25 Feb 2003, Per Hedbor () @ Pike (-) developers forum wrote:
That's highly dangerous.
Say that you want to calculate 1/3. When do you stop expanding digits?
depends on the base i'm in. Say we work on base 3. ;)
--- Ludger
/ Per Hedbor ()
Previous text:
2003-02-25 10:17: Subject: Re: Do we have a floatingpoint bug?
i knew there had to be something, but i was actually suggesting to make that available in the regular pike float type (just like bignum is available in the int type)
greetings, martin.
/ Brevbäraren
you just need an efficient means to store the fact that the result is periodical ( Gmp.mpq(1,3) might do the trick)
greetings, martin.
So, let's take another example. ln(1)
It's simply not possible to store all numbers correctly unless you do not do any of the actual calculations, instead storing the formulas all the time.
That might be exactly what you want, but it's not what you fwant when you write games or video-players, just to take two totally arbitrary examples.
Say that you have a scrolltext that should move according to sin(xpos) + cos(frame/10) or something, you would get a very slow scrolltext if you try to calculate it exactly.
/ Per Hedbor ()
Previous text:
2003-02-25 13:34: Subject: Re: Do we have a floatingpoint bug?
you just need an efficient means to store the fact that the result is periodical ( Gmp.mpq(1,3) might do the trick)
greetings, martin.
/ Brevbäraren
true enough, 1/3 was a bad example though. consider 16/3, it would be stored as: 5+1/3, ie, you calculate the result as far as you can and only store the rest as a fraction.
but you are right in general, using gmp is always going to be slower then actual floats and unfortunately automatic upgrades would not work like in the int->bignum case.
greetings, martin.
Such a precise class would be nice, though. With the suitable methods for resolving equations and similar it would be very cool. :)
sin(b*x²)=a :)
/ Mirar
Previous text:
2003-02-25 13:38: Subject: Re: Do we have a floatingpoint bug?
So, let's take another example. ln(1)
It's simply not possible to store all numbers correctly unless you do not do any of the actual calculations, instead storing the formulas all the time.
That might be exactly what you want, but it's not what you fwant when you write games or video-players, just to take two totally arbitrary examples.
Say that you have a scrolltext that should move according to sin(xpos) + cos(frame/10) or something, you would get a very slow scrolltext if you try to calculate it exactly.
/ Per Hedbor ()
But of course, but not as the default float type. :-)
/ Per Hedbor ()
Previous text:
2003-02-25 13:45: Subject: Re: Do we have a floatingpoint bug?
Such a precise class would be nice, though. With the suitable methods for resolving equations and similar it would be very cool. :)
sin(b*x²)=a :)
/ Mirar
Preferably not :)
Gmp.mpf could be used when the normal float isn't enough, though, the same way GMP.mpz are used when INT_TYPE isn't enough. (1e1000) But the benefit would be very small, so I'd vote against it unless someone is *really* bored and feels like doing it.
/ Mirar
Previous text:
2003-02-25 13:48: Subject: Re: Do we have a floatingpoint bug?
But of course, but not as the default float type. :-)
/ Per Hedbor ()
the problem is, to decide when normal float is not enough. given the nature of floats it would not be enough in 99% of the cases. (enough being "the value is stored correctly and with the precision the user needs)
in fact it would never be enough. we don't know what precision the user needs and the rounding issue accounts for all the values with a low precision.
greetings, martin.
Precisely, the only easily detected limit is the exponent, as in 1e1000. Low precision might even be wanted; it is not obvious that the float should increase mantissa precision when needed, even if it can.
/ Mirar
Previous text:
2003-02-25 14:08: Subject: Re: Do we have a floatingpoint bug?
the problem is, to decide when normal float is not enough. given the nature of floats it would not be enough in 99% of the cases. (enough being "the value is stored correctly and with the precision the user needs)
in fact it would never be enough. we don't know what precision the user needs and the rounding issue accounts for all the values with a low precision.
greetings, martin.
/ Brevbäraren
On Tue, 25 Feb 2003, Mirar @ Pike developers forum wrote:
Such a precise class would be nice, though. With the suitable methods for resolving equations and similar it would be very cool. :)
sin(b*x²)=a :)
well this sounds as if you want to wrap a computer algebra system with pike. If there is real interest into such a project I could try to convince the Paderborn MuPad Group to allow for such a project.
--- Ludger
/ Mirar
Previous text:
2003-02-25 13:38: Subject: Re: Do we have a floatingpoint bug?
So, let's take another example. ln(1)
It's simply not possible to store all numbers correctly unless you do not do any of the actual calculations, instead storing the formulas all the time.
That might be exactly what you want, but it's not what you fwant when you write games or video-players, just to take two totally arbitrary examples.
Say that you have a scrolltext that should move according to sin(xpos) + cos(frame/10) or something, you would get a very slow scrolltext if you try to calculate it exactly.
/ Per Hedbor ()
I guess I don't have any real need for it right now, other then I think it would be cool. I recall having a use for it now and then, though.
/ Mirar
Previous text:
2003-02-25 14:00: Subject: Re: Do we have a floatingpoint bug?
On Tue, 25 Feb 2003, Mirar @ Pike developers forum wrote:
Such a precise class would be nice, though. With the suitable methods for resolving equations and similar it would be very cool. :)
sin(b*x²)=a :)
well this sounds as if you want to wrap a computer algebra system with pike. If there is real interest into such a project I could try to convince the Paderborn MuPad Group to allow for such a project.
--- Ludger
/ Mirar
Previous text:
2003-02-25 13:38: Subject: Re: Do we have a floatingpoint bug?
So, let's take another example. ln(1)
It's simply not possible to store all numbers correctly unless you do not do any of the actual calculations, instead storing the formulas all the time.
That might be exactly what you want, but it's not what you fwant when you write games or video-players, just to take two totally arbitrary examples.
Say that you have a scrolltext that should move according to sin(xpos) + cos(frame/10) or something, you would get a very slow scrolltext if you try to calculate it exactly.
/ Per Hedbor ()
/ Brevbäraren
anything that would get new people interested in pike and spread pike usage is enough to be a real interest.
greetings, martin.
Hilfe has some handy convenience hacks. There is a history object __ as well that remembers (a confugurable amount of) recent results:
Pike v7.4 release 13 running Hilfe v3.5 (Incremental Pike Frontend)
4711;
(1) Result: 4711
"Ho!";
(2) Result: "Ho!"
__[1];
(3) Result: 4711
Type "help me more" in a hilfe for some more info.
/ Johan Sundström (a hugging punishment!)
Previous text:
2003-02-25 10:21: Subject: hilfe
On Tue, Feb 25, 2003 at 10:10:01AM +0100, Johan Sundström (a hugging punishment!) @ Pike (-) developers forum wrote:
(float)_;
^?????????????????????????????????
greetings, martin.
/ Brevbäraren
but why something perl-ish like the _ ? and not something more pike-ish (though i have no idea how that would look like...)
greetings, martin.
"¶" might be more pikeish, but not nearly as easily accessable as _ on the vast majority of keyboards out there. :) Do not use it if it gives you the creeps from its bad pedigree. ;-)
/ Johan Sundström (a hugging punishment!)
Previous text:
2003-02-25 10:42: Subject: Re: hilfe
but why something perl-ish like the _ ? and not something more pike-ish (though i have no idea how that would look like...)
greetings, martin.
/ Brevbäraren
Preferable I'd like to see $1, $2 etc (like in GDB). I find _ and __[X] to be kind-of ugly. Of course, the benefit is that you don't need special parsing.
/ David Hedbor
Previous text:
2003-02-25 10:42: Subject: Re: hilfe
but why something perl-ish like the _ ? and not something more pike-ish (though i have no idea how that would look like...)
greetings, martin.
/ Brevbäraren
And naturally I forgot the interesting part of the example;
Pike v7.4 release 13 running Hilfe v3.5 (Incremental Pike Frontend)
sprintf("%.10f", Gmp.mpq(3580,100));
(1) Result: "35.8000000000"
Just cram out as much precision as you want. :-)
/ Johan Sundström (a hugging punishment!)
Previous text:
2003-02-25 10:09: Subject: Re: Do we have a floatingpoint bug?
Why do the work all over again when there is Gmp.mpq? :-)
Pike v7.4 release 13 running Hilfe v3.5 (Incremental Pike Frontend)
Gmp.mpq(3580,100);
(1) Result: 179/5
(float)_;
(2) Result: 35.799999
/ Johan Sundström (a hugging punishment!)
Are you sure you don't want Gmp.mpf? ^ | > Gmp.mpf(47,1000)+(1e-99)==Gmp.mpf(47); | Result: 0 | > Gmp.mpf(47,10)+(1e-99)==Gmp.mpf(47); | Result: 1
Second argument is precision.
/ Mirar
Previous text:
2003-02-25 10:09: Subject: Re: Do we have a floatingpoint bug?
Why do the work all over again when there is Gmp.mpq? :-)
Pike v7.4 release 13 running Hilfe v3.5 (Incremental Pike Frontend)
Gmp.mpq(3580,100);
(1) Result: 179/5
(float)_;
(2) Result: 35.799999
/ Johan Sundström (a hugging punishment!)
Perhaps even better; I am not overly familiar with either, from their present lack of autodocs. :-]
/ Johan Sundström (a hugging punishment!)
Previous text:
2003-02-25 10:51: Subject: Re: Do we have a floatingpoint bug?
Are you sure you don't want Gmp.mpf? ^ | > Gmp.mpf(47,1000)+(1e-99)==Gmp.mpf(47); | Result: 0 | > Gmp.mpf(47,10)+(1e-99)==Gmp.mpf(47); | Result: 1
Second argument is precision.
/ Mirar
IIRC, mpn is natural numbers (0 and positive integers), it is the base class of all Gmp operations. mpz is integers (positive _and_ negative :) ) mpq is rational numbers, p/q where p and q are mpn's, plus a sign mpf is floating point numbers with variable precision
/ Mirar
Previous text:
2003-02-25 10:54: Subject: Re: Do we have a floatingpoint bug?
Perhaps even better; I am not overly familiar with either, from their present lack of autodocs. :-]
/ Johan Sundström (a hugging punishment!)
Furthermore, in the gmp lib, the interface for mpn is lower level and lot more irregular than for the other types.
/ Niels Möller ()
Previous text:
2003-02-25 10:57: Subject: Re: Do we have a floatingpoint bug?
IIRC, mpn is natural numbers (0 and positive integers), it is the base class of all Gmp operations. mpz is integers (positive _and_ negative :) ) mpq is rational numbers, p/q where p and q are mpn's, plus a sign mpf is floating point numbers with variable precision
/ Mirar
i am sure, yes :-)
sprintf("%.10f", Gmp.mpf(3580,100));
(47) Result: "3.58e3"
sprintf("%.10f", Gmp.mpq(3580,100));
(48) Result: "35.8000000000"
the second is more readable, besides:
sprintf("%.10f", Gmp.mpq(3141593,1000000));
(50) Result: "3.1415930000"
sprintf("%.10f", Gmp.mpf(3141593,1000000));
Bad argument 2 to Gmp.mpf, must be <= 0x10000.
seems that mpf won't handle more precision than regular float
greetings, martin.
The second argument is precision, in bits. It doesn't seem to like higher precision then 65535 bits, but isn't close to 20,000 decimal digits enough precision?
/ Mirar
Previous text:
2003-02-25 11:03: Subject: Re: Do we have a floatingpoint bug?
i am sure, yes :-)
sprintf("%.10f", Gmp.mpf(3580,100));
(47) Result: "3.58e3"
sprintf("%.10f", Gmp.mpq(3580,100));
(48) Result: "35.8000000000"
the second is more readable, besides:
sprintf("%.10f", Gmp.mpq(3141593,1000000));
(50) Result: "3.1415930000"
sprintf("%.10f", Gmp.mpf(3141593,1000000));
Bad argument 2 to Gmp.mpf, must be <= 0x10000.
seems that mpf won't handle more precision than regular float
greetings, martin.
/ Brevbäraren
ahh, then i missunderstood how mpf works. ok, now how do i get the value of pi into Gmp.mpf?
greetings, martin.
You don't happen to have a Pi-generating algorithm around? :)
I suppose Gmp.mpf("3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273",32*256,10); will give you something close to Pi. However, still note that sprintf %f and cast to string is broken for mpf, so I guess you'll have to do something else (cast to float?).
/ Mirar
Previous text:
2003-02-25 11:20: Subject: Re: Do we have a floatingpoint bug?
ahh, then i missunderstood how mpf works. ok, now how do i get the value of pi into Gmp.mpf?
greetings, martin.
/ Brevbäraren
On Tue, Feb 25, 2003 at 11:30:01AM +0100, Mirar @ Pike developers forum wrote:
You don't happen to have a Pi-generating algorithm around? :)
there is a website where you can download a few megabytes worth of digits. though atm i am more interrested in an algorithm to generate prime numbers actually... (but thats another topic)
Gmp.mpf("3.1415926",32*256,10);
ahh, a string. and i just noticed this: Gmp.mpf(Gmp.mpq(31415926,10000000)); also works.
thanks.
sprintf %f and cast to string is broken for mpf, so I guess you'll have to do something else (cast to float?).
wait for the bug to get fixed ;-) considering that mpf is just a subset of mpq the latter will do fine
and i just noticed this: Gmp.mpf(Gmp.mpq(31415926,10000000)); also works.
Unfortunately it does not for bigger numbers:
Gmp.mpq(314159265358979323846264338327950288419716939937510582,
100000000000000000000000000000000000000000000000000000); Bad arg 2 for Gmp.mpq(), expected integer.
/ Johan Sundström (a hugging punishment!)
Previous text:
2003-02-25 11:46: Subject: Re: Do we have a floatingpoint bug?
On Tue, Feb 25, 2003 at 11:30:01AM +0100, Mirar @ Pike developers forum wrote:
You don't happen to have a Pi-generating algorithm around? :)
there is a website where you can download a few megabytes worth of digits. though atm i am more interrested in an algorithm to generate prime numbers actually... (but thats another topic)
Gmp.mpf("3.1415926",32*256,10);
ahh, a string. and i just noticed this: Gmp.mpf(Gmp.mpq(31415926,10000000)); also works.
thanks.
sprintf %f and cast to string is broken for mpf, so I guess you'll have to do something else (cast to float?).
wait for the bug to get fixed ;-) considering that mpf is just a subset of mpq the latter will do fine
/ Brevbäraren
Wierd. It can represent them, though, so it's probably just create(). Try "Gmp.mpq(1)+1e-50".
/ Mirar
Previous text:
2003-02-25 11:56: Subject: Re: Do we have a floatingpoint bug?
and i just noticed this: Gmp.mpf(Gmp.mpq(31415926,10000000)); also works.
Unfortunately it does not for bigger numbers:
Gmp.mpq(314159265358979323846264338327950288419716939937510582,
100000000000000000000000000000000000000000000000000000);Bad arg 2 for Gmp.mpq(), expected integer.
/ Johan Sundström (a hugging punishment!)
Yes - it probably shows people have not used this much in Pike yet, so there is some polishing left to do. (To get a nice big rational number here, I can't go lower than adding 1e-45; anything smaller is lost.)
/ Johan Sundström (a hugging punishment!)
Previous text:
2003-02-25 11:58: Subject: Re: Do we have a floatingpoint bug?
Wierd. It can represent them, though, so it's probably just create(). Try "Gmp.mpq(1)+1e-50".
/ Mirar
I couldn't check on the limit, my Pike uses doubles... :-) I chanced that 50 was low enough, but I was wrong.
There is a lot of "fixme"'s in the mpf and mpq sources. I guess it's free for all if anyone wants to fix those...
/ Mirar
Previous text:
2003-02-25 12:03: Subject: Re: Do we have a floatingpoint bug?
Yes - it probably shows people have not used this much in Pike yet, so there is some polishing left to do. (To get a nice big rational number here, I can't go lower than adding 1e-45; anything smaller is lost.)
/ Johan Sundström (a hugging punishment!)
No, it's not a subset. mpq is rational numbers; these will of course work the way you want it if you set q in p/q to something useful, like 1000000. mpf is a true floating point, and will work like floats in Pike.
It's more useful if you want to play with *floats* without having to worry about large numbers, for instance 1e(1e100) will work nicely in mpf, but not very nicely in mpq. :-)
Both mpq and mpf support seems limited, though. Neither of them have "pow".
there is a website where you can download a few megabytes worth of digits. though atm i am more interrested in an algorithm to generate prime numbers actually... (but thats another topic)
next_prime might be useful? :)
| > 42->next_prime(); | Result: 43
/ Mirar
Previous text:
2003-02-25 11:46: Subject: Re: Do we have a floatingpoint bug?
On Tue, Feb 25, 2003 at 11:30:01AM +0100, Mirar @ Pike developers forum wrote:
You don't happen to have a Pi-generating algorithm around? :)
there is a website where you can download a few megabytes worth of digits. though atm i am more interrested in an algorithm to generate prime numbers actually... (but thats another topic)
Gmp.mpf("3.1415926",32*256,10);
ahh, a string. and i just noticed this: Gmp.mpf(Gmp.mpq(31415926,10000000)); also works.
thanks.
sprintf %f and cast to string is broken for mpf, so I guess you'll have to do something else (cast to float?).
wait for the bug to get fixed ;-) considering that mpf is just a subset of mpq the latter will do fine
/ Brevbäraren
Random prime number generator, N bits:
Gmp.mpz(Crypto.randomness.pike_random()->read(N/8),256)->next_prime();
/ Mirar
Previous text:
2003-02-25 11:57: Subject: Re: Do we have a floatingpoint bug?
No, it's not a subset. mpq is rational numbers; these will of course work the way you want it if you set q in p/q to something useful, like 1000000. mpf is a true floating point, and will work like floats in Pike.
It's more useful if you want to play with *floats* without having to worry about large numbers, for instance 1e(1e100) will work nicely in mpf, but not very nicely in mpq. :-)
Both mpq and mpf support seems limited, though. Neither of them have "pow".
there is a website where you can download a few megabytes worth of digits. though atm i am more interrested in an algorithm to generate prime numbers actually... (but thats another topic)
next_prime might be useful? :)
| > 42->next_prime(); | Result: 43
/ Mirar
ahh, thank you, now i can finally try if my assumption that setting the maximum mount count for fsck to different primes will minimize the chance that two fscks get sceduled at once.
greetings, martin.
I have a few Pi generators around, pick one:
http://fredrik.hubbe.net/hacks/pi.pike (small and easy to read) http://fredrik.hubbe.net/hacks/pi2.pike (more optimized) http://fredrik.hubbe.net/hacks/pi3.pike (complicated, very fast) http://fredrik.hubbe.net/hacks/pi4.pike (translated from a signature)
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2003-02-25 11:25: Subject: Re: Do we have a floatingpoint bug?
You don't happen to have a Pi-generating algorithm around? :)
I suppose Gmp.mpf("3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273",32*256,10); will give you something close to Pi. However, still note that sprintf %f and cast to string is broken for mpf, so I guess you'll have to do something else (cast to float?).
/ Mirar
Hmm. .pike is not a good extension. Internal server error. :)
/ David Hedbor
Previous text:
2003-03-21 09:40: Subject: Re: Do we have a floatingpoint bug?
I have a few Pi generators around, pick one:
http://fredrik.hubbe.net/hacks/pi.pike (small and easy to read) http://fredrik.hubbe.net/hacks/pi2.pike (more optimized) http://fredrik.hubbe.net/hacks/pi3.pike (complicated, very fast) http://fredrik.hubbe.net/hacks/pi4.pike (translated from a signature)
/ Fredrik (Naranek) Hubinette (Real Build Master)
Bugger, new urls:
http://fredrik.hubbe.net/hacks/pi.pike.gz (small and easy to read) http://fredrik.hubbe.net/hacks/pi2.pike.gz (more optimized) http://fredrik.hubbe.net/hacks/pi3.pike.gz (complicated, very fast) http://fredrik.hubbe.net/hacks/pi4.pike.gz (translated from a signature)
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2003-03-21 09:47: Subject: Re: Do we have a floatingpoint bug?
Hmm. .pike is not a good extension. Internal server error. :)
/ David Hedbor
I assume number three is fastest? Maybe something to add to the Math module, in case anyone needs Pi<tm>.
/ Mirar
Previous text:
2003-03-21 10:05: Subject: Re: Do we have a floatingpoint bug?
Bugger, new urls:
http://fredrik.hubbe.net/hacks/pi.pike.gz (small and easy to read) http://fredrik.hubbe.net/hacks/pi2.pike.gz (more optimized) http://fredrik.hubbe.net/hacks/pi3.pike.gz (complicated, very fast) http://fredrik.hubbe.net/hacks/pi4.pike.gz (translated from a signature)
/ Fredrik (Naranek) Hubinette (Real Build Master)
pi3.pike is indeed the fastest, but it's somewhat wasteful in memory usage. Someone should probably verify that they are correct before adding them into Pike. :)
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2003-03-21 10:25: Subject: Re: Do we have a floatingpoint bug?
I assume number three is fastest? Maybe something to add to the Math module, in case anyone needs Pi<tm>.
/ Mirar
Also:
: 1 neotron@stellar pike pi3.pike 1000000 ~/ zsh: 8968 segmentation fault pike pi3.pike 1000000
But my Pike might be old (7.4.13).
/ David Hedbor
Previous text:
2003-03-21 11:07: Subject: Re: Do we have a floatingpoint bug?
pi3.pike is indeed the fastest, but it's somewhat wasteful in memory usage. Someone should probably verify that they are correct before adding them into Pike. :)
/ Fredrik (Naranek) Hubinette (Real Build Master)
Me too.
Pike v7.4 release 10 running Hilfe v3.5 (Incremental Pike Frontend)
kill(getpid(),11);
Segmentation fault
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-03-21 19:01: Subject: Re: Do we have a floatingpoint bug?
Oh, I know. Just wanted to point out it can get Pike to segfault, that's all.
/ David Hedbor
That is not a bug / problem with Pike. Big difference. Rather silly comment in general actually.
/ David Hedbor
Previous text:
2003-03-21 19:54: Subject: Re: Do we have a floatingpoint bug?
Me too.
Pike v7.4 release 10 running Hilfe v3.5 (Incremental Pike Frontend)
kill(getpid(),11);
Segmentation fault
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Btw, IIRC your problem isn't a bug / problem with Pike either, but rather with Gmp.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-03-21 21:09: Subject: Re: Do we have a floatingpoint bug?
That is not a bug / problem with Pike. Big difference. Rather silly comment in general actually.
/ David Hedbor
if it crashes pike, it's a pike problem.
the ideal fix being, that it should not be possible for a buggy (malicious?) library to crash pike (i can dream, can't i? :-)
greetings, martin.
Well, I'm sure we can do something about that when Pike comes with its own operating system. Until then we are in many cases at the mercy of system libraries and kernel services, which may be bugged in ways difficult or impossible to work around.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-03-21 21:21: Subject: Re: Do we have a floatingpoint bug?
if it crashes pike, it's a pike problem.
the ideal fix being, that it should not be possible for a buggy (malicious?) library to crash pike (i can dream, can't i? :-)
greetings, martin.
/ Brevbäraren
This is where we use the weight of our big user base and get the Gmp maintainer to fix their bugs.
/ Martin Nilsson (har bott i google)
Previous text:
2003-03-21 21:24: Subject: Re: Do we have a floatingpoint bug?
Well, I'm sure we can do something about that when Pike comes with its own operating system. Until then we are in many cases at the mercy of system libraries and kernel services, which may be bugged in ways difficult or impossible to work around.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
By all means, do try. :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-03-21 22:40: Subject: Re: Do we have a floatingpoint bug?
This is where we use the weight of our big user base and get the Gmp maintainer to fix their bugs.
/ Martin Nilsson (har bott i google)
for sTeam this problem is rather serious. since we allow users to execute pike code (we can, because we have a security system) crashbugs like these will allow any prankster to kill our servers.
it's less of a problem for caudium or roxen because of the lack of a security system only trusted users should be executing pike code anyways.
ludger, tom, is there any way we can catch people trying to crash sTeam this way?
greetings, martin.
Basically, you can fix the problem by removing (or hiding, by placing another module with the same name before it in the module path) the Gmp module. But you'd have to compile Pike without bignum support, otherwise stuff like 17->pow(10000000) would still work (or not work, depending on your perspective ;).
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-03-21 23:21: Subject: sTeam DoS vulnerability (still is: Do we have a floatingpoint bug?)
for sTeam this problem is rather serious. since we allow users to execute pike code (we can, because we have a security system) crashbugs like these will allow any prankster to kill our servers.
it's less of a problem for caudium or roxen because of the lack of a security system only trusted users should be executing pike code anyways.
ludger, tom, is there any way we can catch people trying to crash sTeam this way?
greetings, martin.
/ Brevbäraren
What about this code then?
while(1);
/ Martin Nilsson (har bott i google)
Previous text:
2003-03-21 23:21: Subject: sTeam DoS vulnerability (still is: Do we have a floatingpoint bug?)
for sTeam this problem is rather serious. since we allow users to execute pike code (we can, because we have a security system) crashbugs like these will allow any prankster to kill our servers.
it's less of a problem for caudium or roxen because of the lack of a security system only trusted users should be executing pike code anyways.
ludger, tom, is there any way we can catch people trying to crash sTeam this way?
greetings, martin.
/ Brevbäraren
good catch, haven't thought about that.
hmm, for this one we need some lpc style execution-time limit.
greetings, martin.
Note that you really need execution *time*, since that construct goes into a sleep() loop...
/ Mirar
Previous text:
2003-03-21 23:45: Subject: Re: sTeam DoS vulnerability (still is: Do we have a floatingpoint bug?)
good catch, haven't thought about that.
hmm, for this one we need some lpc style execution-time limit.
greetings, martin.
/ Brevbäraren
true, instruction counting would not work here.
greetings, martin.
In the last episode (Mar 22), Mirar @ Pike developers forum said:
Note that you really need execution *time*, since that construct goes into a sleep() loop...
If you're running a threaded pike, you can run user code in a separate thread. Then only the one thread ends up sleeping.
for sTeam this problem is rather serious. since we allow users to execute pike code (we can, because we have a security system) crashbugs like these will allow any prankster to kill our servers.
Without any familiarity wiht sTeam - how about executing user pike code in a different pike process or some sort of "execution server"? This could require some sort of communication-layer - it could also not be an option =)
/ Peter Lundqvist (disjunkt)
Previous text:
2003-03-21 23:21: Subject: sTeam DoS vulnerability (still is: Do we have a floatingpoint bug?)
for sTeam this problem is rather serious. since we allow users to execute pike code (we can, because we have a security system) crashbugs like these will allow any prankster to kill our servers.
it's less of a problem for caudium or roxen because of the lack of a security system only trusted users should be executing pike code anyways.
ludger, tom, is there any way we can catch people trying to crash sTeam this way?
greetings, martin.
/ Brevbäraren
sTeam is essentially a mud. so this would not work.
greetings, martin.
Why not? Look at how apache <-> tomcat interoperates.
OTOH I belive you if you say so... you know quite a bit better ;-)
/ Peter Lundqvist (disjunkt)
Previous text:
2003-03-22 13:06: Subject: Re: sTeam DoS vulnerability (still is: Do we have a floatingpoint bug?)
sTeam is essentially a mud. so this would not work.
greetings, martin.
/ Brevbäraren
Le samedi, 22 mar 2003, à 06:15 Europe/Paris, Peter Lundqvist (disjunkt) @ Pike (-) developers forum a écrit :
for sTeam this problem is rather serious. since we allow users to execute pike code (we can, because we have a security system) crashbugs like these will allow any prankster to kill our servers.
Without any familiarity wiht sTeam - how about executing user pike code in a different pike process or some sort of "execution server"? This could require some sort of communication-layer - it could also not be an option =)
Maybe this can be do as newpikescript.pike does in Caudium 1.3. There is an external pike process waiting for data using Remote.Client/Server from Pike.
If it crashes, then Caudium just restart one new server.
I think this can be a solution for such problems.
When I will have a few hour sparing I will try to make same approch for PHP4 support in Caudium as well that have same problem :)
/Xavier
On Sat, Mar 22, 2003 at 04:39:17PM +0100, Xavier Beaudouin wrote:
Maybe this can be do as newpikescript.pike does in Caudium 1.3. There is an external pike process waiting for data using Remote.Client/Server from Pike. If it crashes, then Caudium just restart one new server.
the situation is a lot more complex. DoS is actually the least of our problems. i just discovered that things like Stdio.* are completely unprotected.
we need to somehow make sure that the security wrapper covers each and every function and class in pike, so that calls to Stdio, exit, and the like will result in a security violation.
greetings, martin.
Sounds like what SECURITY_BIT_CONDITIONAL_IO is supposed to do.
/ Henrik Grubbström (Lysator)
Previous text:
2003-03-22 18:45: Subject: Re: sTeam DoS vulnerability (still is: Do we have a floatingpoint bug?)
On Sat, Mar 22, 2003 at 04:39:17PM +0100, Xavier Beaudouin wrote:
Maybe this can be do as newpikescript.pike does in Caudium 1.3. There is an external pike process waiting for data using Remote.Client/Server from Pike. If it crashes, then Caudium just restart one new server.
the situation is a lot more complex. DoS is actually the least of our problems. i just discovered that things like Stdio.* are completely unprotected.
we need to somehow make sure that the security wrapper covers each and every function and class in pike, so that calls to Stdio, exit, and the like will result in a security violation.
greetings, martin.
/ Brevbäraren
do you have any examples how we can use that?
greetings, martin.
ok, and how does one set SECURITY_BIT_CONDITIONAL_IO ?
are there any code examples using pike security? having just seen mention of a security fix in the 7.4.20 changelog, there must be people out there using it.
please share your experience/code with us so that we can spread that.
greetings, martin.
The documentation that exists is essentially: http://pike.ida.liu.se/generated/manual/modref/ex/predef_3A_3A/Pike/Security...
/ Henrik Grubbström (Lysator)
Previous text:
2003-04-04 18:51: Subject: Re: sTeam DoS vulnerability (still is: Do we have a floatingpoint bug?)
ok, and how does one set SECURITY_BIT_CONDITIONAL_IO ?
are there any code examples using pike security? having just seen mention of a security fix in the 7.4.20 changelog, there must be people out there using it.
please share your experience/code with us so that we can spread that.
greetings, martin.
/ Brevbäraren
There is a security system (--with-security). The main problems with it is that it isn't documented and hasn't been audited, so it can't be trusted to provide complete protection. At some points we're actually aware of holes but haven't bothered to fix them (e.g. when dumped programs are decoded they can get references to things they shouldn't). A grep for "FIXME" and "security" should show those places.
(I'm not familiar with it. I suspect only Hubbe and perhaps Grubba know how it works.)
/ Martin Stjernholm, Roxen IS
Previous text:
2003-03-22 18:45: Subject: Re: sTeam DoS vulnerability (still is: Do we have a floatingpoint bug?)
On Sat, Mar 22, 2003 at 04:39:17PM +0100, Xavier Beaudouin wrote:
Maybe this can be do as newpikescript.pike does in Caudium 1.3. There is an external pike process waiting for data using Remote.Client/Server from Pike. If it crashes, then Caudium just restart one new server.
the situation is a lot more complex. DoS is actually the least of our problems. i just discovered that things like Stdio.* are completely unprotected.
we need to somehow make sure that the security wrapper covers each and every function and class in pike, so that calls to Stdio, exit, and the like will result in a security violation.
greetings, martin.
/ Brevbäraren
much worse! --with-security is a compiler option right?
that means that no installed pike out there will support it. which means we can not rely on it's existance (never mind it being tested)
it is a bit to much to ask our users to recompile pike for sTeam. we need to be able to use standard pike installations.
if you want to give this security system any chance of being tested and used, it needs to be enabled by default and at least available as a runtime option.
greetings, martin.
One reason it isn't turned on by default is just because it's still too experimental.
Another is that it incurs some runtime overhead, I suspect. That's not necessarily solved by a runtime option since that in itself would give overhead. To begin with it'd be good to see some measurements on this. Perhaps the overhead is so small that it isn't an issue.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-04-05 21:17: Subject: Re: sTeam DoS vulnerability (still is: Do we have a floatingpoint bug?)
much worse! --with-security is a compiler option right?
that means that no installed pike out there will support it. which means we can not rely on it's existance (never mind it being tested)
it is a bit to much to ask our users to recompile pike for sTeam. we need to be able to use standard pike installations.
if you want to give this security system any chance of being tested and used, it needs to be enabled by default and at least available as a runtime option.
greetings, martin.
/ Brevbäraren
that makes sense, however in order to get this feature out of the experimental stage it may need some more exposure.
who is actually working with this feature at the moment?
could this be turned into an optional runtime option, so that the impact of it being a runtime option that is turned off, can be tested?
in general, compile time options for a compiler/interpreter are a bad idea, as it eventually forces a distributor to provide all variants because some people need the option off, and others need it on.
greetings, martin.
No one is working on it at the moment, or for the last couple of years.
/ Martin Nilsson (har bott i google)
Previous text:
2003-04-05 22:47: Subject: pike security (was: sTeam DoS vulnerability (no longer is: Do we have a floatingpoint bug?))
that makes sense, however in order to get this feature out of the experimental stage it may need some more exposure.
who is actually working with this feature at the moment?
could this be turned into an optional runtime option, so that the impact of it being a runtime option that is turned off, can be tested?
in general, compile time options for a compiler/interpreter are a bad idea, as it eventually forces a distributor to provide all variants because some people need the option off, and others need it on.
greetings, martin.
/ Brevbäraren
i meant working with, not on, ie. who is using it?
the 7.4.20 changelog entry:
o Fixed security hole with running next_object in a Pike with security.
seems to indicate that at least someone must be using it...
Reinhard Pfau Reinhard.Pfau@gmx.de
/ Martin Nilsson (har bott i google)
Previous text:
2003-04-05 22:59: Subject: Re: pike security (was: sTeam DoS vulnerability (no longer is: Do we have a floatingpoint bug?))
i meant working with, not on, ie. who is using it?
the 7.4.20 changelog entry:
o Fixed security hole with running next_object in a Pike with security.
seems to indicate that at least someone must be using it...
/ Brevbäraren
I know, compile time options are only useful for debug stuff (e.g. --with-rtldebug, --with-dmalloc), external dependencies, and to some extent for things that don't affect functionality (--with-long-long-int). Other than that they're just transitional measures.
But I doubt it's useful to make a runtime option for it; wouldn't surprise me if that gave about the same overhead as the security system itself when it simply isn't used. I think you can test that easily by compiling with --with-security, run the benchmarks and compare to a pike without it.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-04-05 22:47: Subject: pike security (was: sTeam DoS vulnerability (no longer is: Do we have a floatingpoint bug?))
that makes sense, however in order to get this feature out of the experimental stage it may need some more exposure.
who is actually working with this feature at the moment?
could this be turned into an optional runtime option, so that the impact of it being a runtime option that is turned off, can be tested?
in general, compile time options for a compiler/interpreter are a bad idea, as it eventually forces a distributor to provide all variants because some people need the option off, and others need it on.
greetings, martin.
/ Brevbäraren
well, the ability to have security compiled in without using it essentially amounts to it being a runtime option, if the mere existance of compiled in security has no negative on those not using it.
if that is the expected outcome then an aditional runtime switch adds no value and the question boils down to: what is necessary to get security out of an experimental stage to warant its inclusion in the default?
given that it has not been worked on for a few years, and only very few people use it, i don't see this situation changing unless something is done proactively.
greetings, martin.
/.../ what is necessary to get security out of an experimental stage to warant its inclusion in the default?
Well, I've already given my view on that: It's a matter of measuring the overhead it gives when it isn't used and, if necessary, reduce that to an acceptable level. It also needs to be tested for stability, which essentially means that it's verified to not fail the testsuite and then turned on by default in the development branch.
/.../ i don't see this situation changing unless something is done proactively.
It hasn't gotten further simply because noone have had enough need for it to do something about it. So just go ahead and get hacking; the 7.5 branch is open.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-04-06 01:08: Subject: Re: pike security (was: sTeam DoS vulnerability (no longer is: Do we have a floatingpoint bug?))
well, the ability to have security compiled in without using it essentially amounts to it being a runtime option, if the mere existance of compiled in security has no negative on those not using it.
if that is the expected outcome then an aditional runtime switch adds no value and the question boils down to: what is necessary to get security out of an experimental stage to warant its inclusion in the default?
given that it has not been worked on for a few years, and only very few people use it, i don't see this situation changing unless something is done proactively.
greetings, martin.
/ Brevbäraren
On Sun, Apr 06, 2003 at 03:00:00AM +0200, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
and then turned on by default in the development branch.
shouldn't the mere existance of a feature no matter how experimental warant it being turned on in the development branch?
i can understand these prerequesites for the stable branch but the devel branch is there to test new and experimental stuff and shake out bugs so code that is already in the pike tree should be activated and tested unconditionally.
greetings, martin.
shouldn't the mere existance of a feature no matter how experimental warant it being turned on in the development branch?
Only if somebody is working actively on it, which has not been the case recently. I might agree that it would speed up fixing (or, in some cases, removal) of code that nobody cares for much today, but probably at the expense of other development.
i can understand these prerequesites for the stable branch but the devel branch is there to test new and experimental stuff and shake out bugs so code that is already in the pike tree should be activated and tested unconditionally.
The testing part mentioned is important. While testing for features not breaking the rest of Pike is not without value, it typically is more interesting that it works as intended and thus has good code coverage in the testsuite, documentation about intention, use and similar. We still fall a bit short on all those areas for vintage code in Pike, and improving the situation takes some work by some dedicated party who cares for particular features.
/ Johan Sundström (folkskådare)
Previous text:
2003-04-06 03:56: Subject: Re: pike security (was: sTeam DoS vulnerability (no longer is: Do we have a floatingpoint bug?))
On Sun, Apr 06, 2003 at 03:00:00AM +0200, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
and then turned on by default in the development branch.
shouldn't the mere existance of a feature no matter how experimental warant it being turned on in the development branch?
i can understand these prerequesites for the stable branch but the devel branch is there to test new and experimental stuff and shake out bugs so code that is already in the pike tree should be activated and tested unconditionally.
greetings, martin.
/ Brevbäraren
On Fri, 21 Mar 2003, Martin Baehr wrote:
for sTeam this problem is rather serious. since we allow users to execute pike code (we can, because we have a security system) crashbugs like these will allow any prankster to kill our servers.
it's less of a problem for caudium or roxen because of the lack of a security system only trusted users should be executing pike code anyways.
ludger, tom, is there any way we can catch people trying to crash sTeam this way?
You can't "catch" a segfault, all we can do is restarting the server from another task. Since all Statuschanges are persistent in sTeam that doesn't hurt too much. For this reason a malicious program in an endlessloop is the bigger risk to a system like sTeam. Thats our main reason, why we put such a feature on the wish list on the last pike conference. ("A save way to remove one thread from outside the thread itselve"), this would allow to do some housekeeping on userthreads and remove them e.g. after some time limit.
--- Ludger
greetings, martin.
On Sat, Mar 22, 2003 at 12:12:12PM +0100, Ludger Merkens wrote:
You can't "catch" a segfault
i meant catching it before it is executed. erm, we need to catch exit() too.
For this reason a malicious program in an endlessloop is the bigger risk to a system like sTeam. Thats our main reason, why we put such a feature on the wish list on the last pike conference. ("A save way to remove one thread from outside the thread itselve"), this would allow to do some housekeeping on userthreads and remove them e.g. after some time limit.
erm, right now, such an endless loop blocks the whole server. i don't see how housekeeping would solve that problem.
it seems our next sTeam project group needs to be about pike security, we have major problems in this area.
greetings, martin.
Right, it seems as such. Point being, perhaps code to be adopted in the tree shouldn't have a known crash bug (if there are similar-quality code that doesn't cause a crash).
/ David Hedbor
Previous text:
2003-03-21 21:13: Subject: Re: Do we have a floatingpoint bug?
Btw, IIRC your problem isn't a bug / problem with Pike either, but rather with Gmp.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
I'm not sure what you mean by "adopted in the tree", we are not bundling gmp with the Pike distributions.
As far as I can remember, the mpn functions in gmp can be used in a way that handles out-of-memory conditions, but the higher level functions (mpz/mpf/mpq) can not. It would be possible to rewrite the Pike glue to use mpn functions only, but that would mean reimplenting a lot of stuff that is already in gmp, and be a lot of work which nobody has been particularly interrested in doing so far.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-03-21 21:15: Subject: Re: Do we have a floatingpoint bug?
Right, it seems as such. Point being, perhaps code to be adopted in the tree shouldn't have a known crash bug (if there are similar-quality code that doesn't cause a crash).
/ David Hedbor
I'm talking about the PI generation code.
/ David Hedbor
Previous text:
2003-03-21 21:20: Subject: Re: Do we have a floatingpoint bug?
I'm not sure what you mean by "adopted in the tree", we are not bundling gmp with the Pike distributions.
As far as I can remember, the mpn functions in gmp can be used in a way that handles out-of-memory conditions, but the higher level functions (mpz/mpf/mpq) can not. It would be possible to rewrite the Pike glue to use mpn functions only, but that would mean reimplenting a lot of stuff that is already in gmp, and be a lot of work which nobody has been particularly interrested in doing so far.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
The PI generation code is not the problem. Observe:
Pike v7.3 release 55 running Hilfe v3.5 (Incremental Pike Frontend)
Gmp.mpz(17)->pow(10000000);
Segmentation fault (core dumped)
The problem with large numbers is inherent in gmp, how will including/not including the particular PI function make any difference?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-03-21 21:25: Subject: Re: Do we have a floatingpoint bug?
I'm talking about the PI generation code.
/ David Hedbor
A PI algorithm doesn't need to use Gmp.
/ David Hedbor
Previous text:
2003-03-21 21:30: Subject: Re: Do we have a floatingpoint bug?
The PI generation code is not the problem. Observe:
Pike v7.3 release 55 running Hilfe v3.5 (Incremental Pike Frontend)
Gmp.mpz(17)->pow(10000000);
Segmentation fault (core dumped)
The problem with large numbers is inherent in gmp, how will including/not including the particular PI function make any difference?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
So? How is a PI algorithm that doesn't use Gmp going to make Gmp work better? You'll still be able to write your own PI algorithm or whatever that uses Gmp and causes a core dump. So it wouldn't really solve anything.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-03-21 21:49: Subject: Re: Do we have a floatingpoint bug?
A PI algorithm doesn't need to use Gmp.
/ David Hedbor
You are entirely missing the point. A bit up in the thread it was discussed that a PI algorithm should be added. My only point is that hubbe's "pi3" shouldn't be the one because it triggers a crash in Gmp.
/ David Hedbor
Previous text:
2003-03-21 21:52: Subject: Re: Do we have a floatingpoint bug?
So? How is a PI algorithm that doesn't use Gmp going to make Gmp work better? You'll still be able to write your own PI algorithm or whatever that uses Gmp and causes a core dump. So it wouldn't really solve anything.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Only with unsuitable input. Just like all Gmp based functions. I thought your argument was that there shouldn't be any functions in Pike that can segfault no matter what their input. Should this only apply to Pi-calculating functions?
If you are not opposed to functions being able to segfault with unsuitable input, what's the problem with pi3?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-03-21 22:06: Subject: Re: Do we have a floatingpoint bug?
You are entirely missing the point. A bit up in the thread it was discussed that a PI algorithm should be added. My only point is that hubbe's "pi3" shouldn't be the one because it triggers a crash in Gmp.
/ David Hedbor
It's easy to have a pi method that doesn't crash. It's not as easy to fix Gmp. I don't think any methods should CRASH Pike but it's not always as easy to fix.
/ David Hedbor
Previous text:
2003-03-21 22:09: Subject: Re: Do we have a floatingpoint bug?
Only with unsuitable input. Just like all Gmp based functions. I thought your argument was that there shouldn't be any functions in Pike that can segfault no matter what their input. Should this only apply to Pi-calculating functions?
If you are not opposed to functions being able to segfault with unsuitable input, what's the problem with pi3?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Maybe not so easy as you may think. Shouldn't the Pi function return a Gmp.mpf in order to be useful? In that case you have to use Gmp at _some_ stage, which again opens possibility for a CRASH (why the capital letters?).
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-03-21 22:17: Subject: Re: Do we have a floatingpoint bug?
It's easy to have a pi method that doesn't crash. It's not as easy to fix Gmp. I don't think any methods should CRASH Pike but it's not always as easy to fix.
/ David Hedbor
It can return a string.
/ David Hedbor
Previous text:
2003-03-21 22:24: Subject: Re: Do we have a floatingpoint bug?
Maybe not so easy as you may think. Shouldn't the Pi function return a Gmp.mpf in order to be useful? In that case you have to use Gmp at _some_ stage, which again opens possibility for a CRASH (why the capital letters?).
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
you hardly need more than Math.pi digits for normal calculations that you'd do in Pike. I don't anyone would use Pike for calculations that needs thousands and thousands of digits.
/ David Hedbor
Previous text:
2003-03-21 22:28: Subject: Re: Do we have a floatingpoint bug?
When is that useful? Why would you want Pi if you're not going to do computations with it?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
No, but maybe for calculations that need a few tens of digits. If "nobody" needs more digits than Math.pi provides (6, or what is it?) then there's no point in having a pi function that generates more digits at all.
The whole question of Pi functions originated with Martin asking how to get pi into a Gmp.mpf in text 9797873. So far nobody has requested functionality for getting (a decimal representation of) pi into a string.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-03-21 22:34: Subject: Re: Do we have a floatingpoint bug?
you hardly need more than Math.pi digits for normal calculations that you'd do in Pike. I don't anyone would use Pike for calculations that needs thousands and thousands of digits.
/ David Hedbor
Maybe it could be rewritten to use Gmp.mpf directly instead of implicit mpz?
/ Mirar
Previous text:
2003-03-21 11:07: Subject: Re: Do we have a floatingpoint bug?
pi3.pike is indeed the fastest, but it's somewhat wasteful in memory usage. Someone should probably verify that they are correct before adding them into Pike. :)
/ Fredrik (Naranek) Hubinette (Real Build Master)
Gmp.mpf seems to be lacking in the sqrt()/pow() departement, which makes it hard to use for the guass-legrende PI formula.
Also, Gmp.mpq has some nice optimizations for dealing with operations where one of the operands is a small integer which makes it quite a bit faster.
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2003-03-22 07:36: Subject: Re: Do we have a floatingpoint bug?
Maybe it could be rewritten to use Gmp.mpf directly instead of implicit mpz?
/ Mirar
Hmm, I assumed mpf had a complete set of operations. Are they just not implemented, or is mpf that useless?
Since mpf uses mpn as much as mpq, all operations should be about equally fast...
/ Mirar
Previous text:
2003-03-22 08:21: Subject: Re: Do we have a floatingpoint bug?
Gmp.mpf seems to be lacking in the sqrt()/pow() departement, which makes it hard to use for the guass-legrende PI formula.
Also, Gmp.mpq has some nice optimizations for dealing with operations where one of the operands is a small integer which makes it quite a bit faster.
/ Fredrik (Naranek) Hubinette (Real Build Master)
speaking of hacks and code-snippets, with pike-community.org we lost a large repository of that stuff.
i am potentially thinking about resurrecting something like it (probably with the use of sTeam) and would like to get access to the remains of pike-community, to at least salvage the data that was there, before nobody can remember where the backups disappeared to.
does anybody know where the stuff currently is? is there someone who still has access to it. a simple tar might be enough for starters, just to make sure we have an accessible backup
greetings, martin.
We have the site structure and code lying around in a nearby tar file, but the interesting content is still rotting away in an off-site database. Grubba hinted he might be able to salvage it though, so there is probably hope. :-)
/ Johan Sundström (folkskådare)
Previous text:
2003-03-21 17:38: Subject: saving pike-community
speaking of hacks and code-snippets, with pike-community.org we lost a large repository of that stuff.
i am potentially thinking about resurrecting something like it (probably with the use of sTeam) and would like to get access to the remains of pike-community, to at least salvage the data that was there, before nobody can remember where the backups disappeared to.
does anybody know where the stuff currently is? is there someone who still has access to it. a simple tar might be enough for starters, just to make sure we have an accessible backup
greetings, martin.
/ Brevbäraren
On Fri, 21 Mar 2003, Martin Baehr wrote:
does anybody know where the stuff currently is? is there someone who still has access to it. a simple tar might be enough for starters, just to make sure we have an accessible backup
Look at the web archive at http://web.archive.org/web/*/http://pike-community.org/ it might contain some code.
// Calculate arctan(1/x) of arbitrary precision
Gmp.mpf arctan(int x, int prec) { // The value of the rest term is 1 / (k * x^k) // so we need to iterate at least until x^k > 2^prec / k // 1 is an upper bound for 1/k, so k > prec/log2(x) is good enough. int kbound = 1+prec/(int)(log((float)x)/log(2.0));
Gmp.mpf res = Gmp.mpf(0,prec); int sign=1, xpow=x; for(int k=1; k<=kbound; k+=2, xpow *= x*x, sign=-sign) res += Gmp.mpq(sign, k * xpow);
return res; };
// Calculate PI of arbitrary precision
Gmp.mpf pi(int prec) { return arctan(5, prec)*16-arctan(239, prec)*4; }
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-02-25 11:20: Subject: Re: Do we have a floatingpoint bug?
ahh, then i missunderstood how mpf works. ok, now how do i get the value of pi into Gmp.mpf?
greetings, martin.
/ Brevbäraren
Ok, so the name "arctan" was a really poor choice for the first function, since it computes arctan(1/x) rather than arctan(x), but anyway... :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-02-25 14:59: Subject: Re: Do we have a floatingpoint bug?
// Calculate arctan(1/x) of arbitrary precision
Gmp.mpf arctan(int x, int prec) { // The value of the rest term is 1 / (k * x^k) // so we need to iterate at least until x^k > 2^prec / k // 1 is an upper bound for 1/k, so k > prec/log2(x) is good enough. int kbound = 1+prec/(int)(log((float)x)/log(2.0));
Gmp.mpf res = Gmp.mpf(0,prec); int sign=1, xpow=x; for(int k=1; k<=kbound; k+=2, xpow *= x*x, sign=-sign) res += Gmp.mpq(sign, k * xpow);
return res; };
// Calculate PI of arbitrary precision
Gmp.mpf pi(int prec) { return arctan(5, prec)*16-arctan(239, prec)*4; }
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
neat, thanks.
now we only need to find a workaround to extract the value or fix that bug.
greetings, martin.
Speaking of which, the current CVS version of Pike seems to hang somewhere in the build/test process. Hence all the grey dots, I suppose. Anyone on it already?
/ Mirar
Previous text:
2003-02-25 14:59: Subject: Re: Do we have a floatingpoint bug?
// Calculate arctan(1/x) of arbitrary precision
Gmp.mpf arctan(int x, int prec) { // The value of the rest term is 1 / (k * x^k) // so we need to iterate at least until x^k > 2^prec / k // 1 is an upper bound for 1/k, so k > prec/log2(x) is good enough. int kbound = 1+prec/(int)(log((float)x)/log(2.0));
Gmp.mpf res = Gmp.mpf(0,prec); int sign=1, xpow=x; for(int k=1; k<=kbound; k+=2, xpow *= x*x, sign=-sign) res += Gmp.mpq(sign, k * xpow);
return res; };
// Calculate PI of arbitrary precision
Gmp.mpf pi(int prec) { return arctan(5, prec)*16-arctan(239, prec)*4; }
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Grubba committed a "fix for infinite loop" two hours ago. Maybe it's related?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-02-25 17:06: Subject: hang
Speaking of which, the current CVS version of Pike seems to hang somewhere in the build/test process. Hence all the grey dots, I suppose. Anyone on it already?
/ Mirar
It worked, though. But I wonder why every Pike tested segfaults early in the testsuite.
What is that? My gdb isn't very informative:
Program terminated with signal 11, Segmentation fault. #0 0x080d8225 in debug_mkidentifiernode. () at las.c:1323 1323 node *res = mkexternalnode(Pike_compiler->new_program, i);
Backtrace #0 0x080d8225 in debug_mkidentifiernode. () at las.c:1323 #1 0x00000000 in ?? ()
/ Mirar
Previous text:
2003-02-25 17:12: Subject: hang
One wonders why this fix wasn't necessary in 7.4 though...
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Because there is a segfault bug with nested functions and I added a test to detect it. :-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-02-26 08:40: Subject: hang
It worked, though. But I wonder why every Pike tested segfaults early in the testsuite.
What is that? My gdb isn't very informative:
Program terminated with signal 11, Segmentation fault. #0 0x080d8225 in debug_mkidentifiernode. () at las.c:1323 1323 node *res = mkexternalnode(Pike_compiler->new_program, i);
Backtrace #0 0x080d8225 in debug_mkidentifiernode. () at las.c:1323 #1 0x00000000 in ?? ()
/ Mirar
sprintf("%.10f", Gmp.mpf(3580,100));
(47) Result: "3.58e3"
sprintf("%.10f", Gmp.mpq(3580,100));
(48) Result: "35.8000000000"
The first looks like a _sprintf bug to me; shouldn't it have returned "3580.0000000000" instead?
/ Johan Sundström (a hugging punishment!)
Previous text:
2003-02-25 11:03: Subject: Re: Do we have a floatingpoint bug?
i am sure, yes :-)
sprintf("%.10f", Gmp.mpf(3580,100));
(47) Result: "3.58e3"
sprintf("%.10f", Gmp.mpq(3580,100));
(48) Result: "35.8000000000"
the second is more readable, besides:
sprintf("%.10f", Gmp.mpq(3141593,1000000));
(50) Result: "3.1415930000"
sprintf("%.10f", Gmp.mpf(3141593,1000000));
Bad argument 2 to Gmp.mpf, must be <= 0x10000.
seems that mpf won't handle more precision than regular float
greetings, martin.
/ Brevbäraren
The _sprintf support for mpf doesn't seem to be very advanced. :/ In effect, all it does is a cast-to-string:
case 'f': f_mpf_get_string(0); return;
/ Mirar
Previous text:
2003-02-25 11:12: Subject: Re: Do we have a floatingpoint bug?
sprintf("%.10f", Gmp.mpf(3580,100));
(47) Result: "3.58e3"
sprintf("%.10f", Gmp.mpq(3580,100));
(48) Result: "35.8000000000"
The first looks like a _sprintf bug to me; shouldn't it have returned "3580.0000000000" instead?
/ Johan Sundström (a hugging punishment!)
Ahh, that makes sense. Still, I think it's a bit odd, considering that the numbers are fairly small.
/ Marcus Agehall (Trådlös)
Previous text:
2003-02-25 09:44: Subject: Do we have a floatingpoint bug?
It's called floats. Floats are not exact. Try the following C-program:
#include <stdio.h> int main() { printf("%f %f\n", (float)35.8, 35.8); return 0; }
If you want exact calculations you don't want floats. Of course, if you compile with with doubles rather than floats, you get better approximations (but still not exact).
/ David Hedbor
It's about the same problem as why you can't store the value 256 in a byte, even though you can write the number 256 in decimal in the same space as you could write the number 255. Sort of, anyway. :)
/ Johan Sundström (a hugging punishment!)
Previous text:
2003-02-25 10:19: Subject: Do we have a floatingpoint bug?
Ahh, that makes sense. Still, I think it's a bit odd, considering that the numbers are fairly small.
/ Marcus Agehall (Trådlös)
Didn't we have this discussion recently? You are probably mislead by sprintf trying to cram out as many decimals as possible from imprecise (by nature) floats. Considering 358.0/10, you use at most four digits of precision, hence 35.799999 means 35.80. Use sprintf("%.2f", number) to lose sight of noise in less significant bits of the float:
Pike v7.4 release 13 running Hilfe v3.5 (Incremental Pike Frontend)
358.0/10;
(1) Result: 35.799999
sprintf("%.2f", 358.0/10);
(2) Result: "35.80"
Naturally, if you do want more than seven or eight digits of precision (I'm not sure about the guarantees of a float, but your experiments suggest the precision is somewhere around there), you should not use floats at all.
/ Johan Sundström (a hugging punishment!)
Previous text:
2003-02-25 09:29: Subject: Do we have a floatingpoint bug?
Yesterday I had to write a program which rescaled and rounded off some coordinates for use in a lab. I found something that worries me quite a bit:
({ /* 22 elements */ ({ /* 2 elements */ 639.000000, 37.000000 }), ({ /* 2 elements */ 426.000000, 99.000000 }), ({ /* 2 elements */ 538.000000, 103.000000 }), ({ /* 2 elements */ 698.000000, 105.000000 }), ({ /* 2 elements */ 813.000000, 104.000000 }), ({ /* 2 elements */ 480.000000, 199.000000 }), ({ /* 2 elements */ 633.000000, 195.000000 }), ({ /* 2 elements */ 780.000000, 196.000000 }), ({ /* 2 elements */ 480.000000, 304.000000 }), ({ /* 2 elements */ 636.000000, 308.000000 }), ({ /* 2 elements */ 785.000000, 309.000000 }), ({ /* 2 elements */ 425.000000, 388.000000 }), ({ /* 2 elements */ 536.000000, 397.000000 }), ({ /* 2 elements */ 700.000000, 401.000000 }), ({ /* 2 elements */ 814.000000, 399.000000 }), ({ /* 2 elements */ 625.000000, 457.000000 }), ({ /* 2 elements */ 480.000000, 252.000000 }), ({ /* 2 elements */ 633.000000, 256.000000 }), ({ /* 2 elements */ 780.000000, 259.000000 }), ({ /* 2 elements */ 480.000000, 349.000000 }), ({ /* 2 elements */ 636.000000, 347.000000 }), ({ /* 2 elements */ 785.000000, 358.000000 }) }) ({ /* 22 elements */ ({ /* 2 elements */ 63.900002, 3.700000 }), ({ /* 2 elements */ 42.599998, 9.900000 }), ({ /* 2 elements */ 53.799999, 10.300000 }), ({ /* 2 elements */ 69.800003, 10.500000 }), ({ /* 2 elements */ 81.300003, 10.400000 }), ({ /* 2 elements */ 48.000000, 19.900000 }), ({ /* 2 elements */ 63.299999, 19.500000 }), ({ /* 2 elements */ 78.000000, 19.600000 }), ({ /* 2 elements */ 48.000000, 30.400000 }), ({ /* 2 elements */ 63.599998, 30.799999 }), ({ /* 2 elements */ 78.500000, 30.900000 }), ({ /* 2 elements */ 42.500000, 38.799999 }), ({ /* 2 elements */ 53.599998, 39.700001 }), ({ /* 2 elements */ 70.000000, 40.099998 }), ({ /* 2 elements */ 81.400002, 39.900002 }), ({ /* 2 elements */ 62.500000, 45.700001 }), ({ /* 2 elements */ 48.000000, 25.200001 }), ({ /* 2 elements */ 63.299999, 25.600000 }), ({ /* 2 elements */ 78.000000, 25.900000 }), ({ /* 2 elements */ 48.000000, 34.900002 }), ({ /* 2 elements */ 63.599998, 34.700001 }), ({ /* 2 elements */ 78.500000, 35.799999 }) }) [agehall@omicron ~] pike --version Pike v7.5 release 1 Copyright © 1994-2002 Linköping University Pike comes with ABSOLUTELY NO WARRANTY; This is free software and you are welcome to redistribute it under certain conditions; Read the files COPYING and COPYRIGHT in the Pike distribution for more details.
The first array(array(float)) are the values as read from the file. The second array(array(float)) contains the values divided by 10. Note how some numbers become +-0.000001. This is very strange and not very good at all... I am able to reproduce the bug by doing
358.0/10;
(1) Result: 35.799999
on both my PPro/Linux running Pike 7.5 and a Sun/Solaris running Pike 7.3. Is this a known bug and is there a workaround?
/ Marcus Agehall (Trådlös)
Pike doesn't do anything magical with floats; all¹ work on floats is up to the C compiler and libc.
Pike's default float type, "float", have superbad precision (7½ digits, 1.0+1e-8==1.0). So your figures are correct as far as the precision will take you.
If you need more precision, maybe Math.Matrix can help you (it uses "double" on all systems), or you can compile Pike with --with-double-precision or --with-long-double-precision to get better default precision.
(¹ Pike has some builtin knowledge of IEEE float formats used in sprintf/sscanf %F, binary input and output. Not applicable here.)
/ Mirar
Previous text:
2003-02-25 09:29: Subject: Do we have a floatingpoint bug?
Yesterday I had to write a program which rescaled and rounded off some coordinates for use in a lab. I found something that worries me quite a bit:
({ /* 22 elements */ ({ /* 2 elements */ 639.000000, 37.000000 }), ({ /* 2 elements */ 426.000000, 99.000000 }), ({ /* 2 elements */ 538.000000, 103.000000 }), ({ /* 2 elements */ 698.000000, 105.000000 }), ({ /* 2 elements */ 813.000000, 104.000000 }), ({ /* 2 elements */ 480.000000, 199.000000 }), ({ /* 2 elements */ 633.000000, 195.000000 }), ({ /* 2 elements */ 780.000000, 196.000000 }), ({ /* 2 elements */ 480.000000, 304.000000 }), ({ /* 2 elements */ 636.000000, 308.000000 }), ({ /* 2 elements */ 785.000000, 309.000000 }), ({ /* 2 elements */ 425.000000, 388.000000 }), ({ /* 2 elements */ 536.000000, 397.000000 }), ({ /* 2 elements */ 700.000000, 401.000000 }), ({ /* 2 elements */ 814.000000, 399.000000 }), ({ /* 2 elements */ 625.000000, 457.000000 }), ({ /* 2 elements */ 480.000000, 252.000000 }), ({ /* 2 elements */ 633.000000, 256.000000 }), ({ /* 2 elements */ 780.000000, 259.000000 }), ({ /* 2 elements */ 480.000000, 349.000000 }), ({ /* 2 elements */ 636.000000, 347.000000 }), ({ /* 2 elements */ 785.000000, 358.000000 }) }) ({ /* 22 elements */ ({ /* 2 elements */ 63.900002, 3.700000 }), ({ /* 2 elements */ 42.599998, 9.900000 }), ({ /* 2 elements */ 53.799999, 10.300000 }), ({ /* 2 elements */ 69.800003, 10.500000 }), ({ /* 2 elements */ 81.300003, 10.400000 }), ({ /* 2 elements */ 48.000000, 19.900000 }), ({ /* 2 elements */ 63.299999, 19.500000 }), ({ /* 2 elements */ 78.000000, 19.600000 }), ({ /* 2 elements */ 48.000000, 30.400000 }), ({ /* 2 elements */ 63.599998, 30.799999 }), ({ /* 2 elements */ 78.500000, 30.900000 }), ({ /* 2 elements */ 42.500000, 38.799999 }), ({ /* 2 elements */ 53.599998, 39.700001 }), ({ /* 2 elements */ 70.000000, 40.099998 }), ({ /* 2 elements */ 81.400002, 39.900002 }), ({ /* 2 elements */ 62.500000, 45.700001 }), ({ /* 2 elements */ 48.000000, 25.200001 }), ({ /* 2 elements */ 63.299999, 25.600000 }), ({ /* 2 elements */ 78.000000, 25.900000 }), ({ /* 2 elements */ 48.000000, 34.900002 }), ({ /* 2 elements */ 63.599998, 34.700001 }), ({ /* 2 elements */ 78.500000, 35.799999 }) }) [agehall@omicron ~] pike --version Pike v7.5 release 1 Copyright © 1994-2002 Linköping University Pike comes with ABSOLUTELY NO WARRANTY; This is free software and you are welcome to redistribute it under certain conditions; Read the files COPYING and COPYRIGHT in the Pike distribution for more details.
The first array(array(float)) are the values as read from the file. The second array(array(float)) contains the values divided by 10. Note how some numbers become +-0.000001. This is very strange and not very good at all... I am able to reproduce the bug by doing
358.0/10;
(1) Result: 35.799999
on both my PPro/Linux running Pike 7.5 and a Sun/Solaris running Pike 7.3. Is this a known bug and is there a workaround?
/ Marcus Agehall (Trådlös)
pike-devel@lists.lysator.liu.se
-
Dan Nelson -
David Gourdelier -
David Hedbor ＠ Pike developers forum -
Fredrik (Naranek) Hubinette (Real Build Master) ＠ Pike (-) developers forum
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum
-
Johan Sundstr�m (a hugging punishment!) ＠ Pike (-) developers forum
-
Johan Sundstr�m (folksk�dare) ＠ Pike (-) developers forum
-
Ludger Merkens -
Marcus Agehall (Tr�dl�s) ＠ Pike (-) developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Baehr -
Martin Nilsson (har bott i google) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Niels M�ller () ＠ Pike (-) developers forum
-
Per Hedbor () ＠ Pike (-) developers forum
-
Peter Lundqvist (disjunkt) ＠ Pike (-) developers forum
-
Xavier Beaudouin