Thread: [pure-lang-users] Yet another quirk with MinGW
Status: Beta
Brought to you by:
agraef
Menu
▾
▴
pure-lang-users
|
From: Jiří S. <jir...@bl...> - 2008-07-09 09:20:25
|
Hi, There is yet another quirk with math under MinGW after compiling it. > using math; math.pure:34.7-26: external symbol 'round' cannot be found math.pure:34.29-48: external symbol 'trunc' cannot be found math.pure:92.7-26: external symbol 'asinh' cannot be found math.pure:93.7-36: external symbol 'acosh' cannot be found math.pure:93.39-68: external symbol 'atanh' cannot be found > They are all defined in math.h. Jiri |
|
From: Albert G. <Dr....@t-...> - 2008-07-09 19:30:06
|
Jiří Spitz wrote: > There is yet another quirk with math under MinGW after compiling it. > > > using math; > math.pure:34.7-26: external symbol 'round' cannot be found Adding '-lm' to LIBS should help with that. I'll fix that asap. I can't test it myself right now since I left my laptop in the office. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Jiri S. <jir...@bl...> - 2008-07-10 09:33:35
|
Albert Graef wrote: > Jiri Spitz wrote: > Adding '-lm' to LIBS should help with that. I'll fix that asap. I can't > test it myself right now since I left my laptop in the office. > No change here :-( : $ make g++ -shared -o libpure-0.5.dll -Wl,--enable-auto-import expr.o interpreter.o mat cher.o printer.o runtime.o symtable.o util.o lexer.o parser.o `llvm-config --ldflags --libs core jit native` -lregex -lglob -liconv -lreadline -lgmp -limagehlp -lpsapi -lm ln -sf libpure-0.5.dll libpure.dll g++ -o pure.exe -Wl,--enable-auto-import pure.o -L. -lpure-0.5 -lregex -lglob -liconv -lreadline -lgmp -limagehlp -lpsapi -lm $ ./pure ... > using math; math.pure:34.7-26: external symbol 'round' cannot be found ... Jiri |
|
From: Albert G. <Dr....@t-...> - 2008-08-20 09:19:19
|
Jiri Spitz wrote: > Albert Graef wrote: >> Jiri Spitz wrote: >> Adding '-lm' to LIBS should help with that. I'll fix that asap. I can't >> test it myself right now since I left my laptop in the office. >> > No change here :-( : Ok, I finally got around fixing this (r549). Seems that round et al are in C99 but not in POSIX.1. But it's possible to get them from libmingwex.a. The mingw version now builds cleanly, passes all checks and math.pure also loads fine. If anyone has noticed bugs which haven't been fixed yet, please report them *now*, as I'm about to release Pure 0.5 in the course of the next few hours. Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Eddie R. <er...@bm...> - 2008-08-20 14:26:23
|
On Wed, 2008-08-20 at 11:20 +0200, Albert Graef wrote: > If anyone has noticed bugs which haven't been fixed yet, please report > them *now*, as I'm about to release Pure 0.5 in the course of the next > few hours. I started playing around with the following script: ------------------------------------------------------ using math; // Handle the unary stuff first let f = [sqrt, sin, cos, tan, ln, log, exp, atan, asin, acos, sinh, cosh, tanh, asinh, acosh, atanh, abs, re, im, arg, conj, rect, polar, cis, ceil, floor, round, frac, complexp, realp, rationalp, numberp, exactp, inexactp, infp, nanp]; let x = [1, -1, 0, 0.0, 1.2, -1.2, 1%3, -1%4, 1+:2, -1+:2, 1+:-2, -1.2 +:4.3, 1.2+:-4.3, 1%2+:1, 1%2+:3%4, 3<:1, -3<:1, 3.0<:-3, 3.1<:2.5, (2%3)<:2, (1%2)<:(3%4), -inf, nan]; // Handle binary stuf; let X = [(i,j); i=x; j=x]; let f2 = [(+), (-), (*), (/), (^), atan2, pow]; let unary = map (\f -> (map (\x -> f x) x)) f; let binary = map (\f -> (map (\(x,y) -> f x y) X)) f2; -------------------------------------------------------- But I have to go to a meeting. Looking through the stuff: > unary; (1) Is sqrt supposed to be defined for nan and inf? ln, sin, cos, etc, are. (2) ceil, floor, round, and frac for complex numbers are undefined and IMHO should stay that way. (3) Shouldn't polar (x<:y) => x<:y ? (4) Shouldn't rect (x+:y) => x+:y ? > binary; (1) pow and atan2 for complex numbers is undefined for a lot of combinations. I'll try to weed through this after work. Got to go. e.r. |
|
From: Albert G. <Dr....@t-...> - 2008-08-22 09:13:40
|
Eddie Rucker wrote: > On Wed, 2008-08-20 at 11:20 +0200, Albert Graef wrote: > >> If anyone has noticed bugs which haven't been fixed yet, please report >> them *now*, as I'm about to release Pure 0.5 in the course of the next >> few hours. > > I started playing around with the following script: > [snip] I committed Eddie's math.pure test as test020.pure now, massaged somewhat to produce a nicely formatted test log. (r563) You can see the results at: http://pure-lang.svn.sourceforge.net/viewvc/pure-lang/pure/trunk/test/test020.log?revision=563 Watch out for the line reading "*** UNARY ***", that's where the relevant stuff starts. Each line lists the function/operator, arguments and the result. Failed (i.e., irreducible) computations are flagged with '__failed__', exceptions with '__error__'. I already skimmed over these and AFAICT they should be ok. What remains is the unattractive task to check all the untagged results. As we say over here, that's a "job for someone who killed mom and dad", so I'd rather suggest that we take a "many eyes" approach to that. Everyone here who feels like it and has some spare time on his hands can just scan a few results at a time and report on the mailing list if he notices anything suspicious. (Eddie, maybe we should also add another check on the result type and flag results which aren't numbers? I leave that up to you.) Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-08-24 00:26:32
|
> Well, I had to fiddle with the output format some more, since 'make
> check' would fail on this test due to (more or less) small rounding
> discrepancies between systems. ("Almost zero" values are particularly
> nasty.) Therefore I'm rounding floating point numbers to 3 significant
> digits now, I hope that this is good enough. The latest log can be found
> here:
>
> http://pure-lang.svn.sourceforge.net/viewvc/pure-lang/pure/trunk/test/test020.log
If you want to give a helping hand checking some of the results, it's
actually easier to just run test020.pure interactively yourself. That
also gives you the opportunity to rerun the tests after changing the
printed precision of results, like so:
let double_format = "%#0.6g"; tests;
In the meantime I also checked some of the complex operations manually
against my HP-50G calculator, whose numeric algorithms are based on
earlier HP calculator software designed by William Kahan, so they should
be pretty much standard. ;-) All bad branch cuts I noticed are corrected
now, so that math.pure now shows pretty much the same results as the
calculator (up to rounding). That gives me some confidence that the
definitions in math.pure actually work now. :)
I also added the type guards necessary to ensure that symbolic terms
involving these operations are irreducible, so that all math.pure
functions and operators can be extended as necessary later.
This is all in svn now, so I guess it's release time. :) A bit late
tonight, but tomorrow...
Cheers,
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr....@t-..., ag...@mu...
WWW: http://www.musikinformatik.uni-mainz.de/ag
|
|
From: Albert G. <Dr....@t-...> - 2008-08-24 02:40:32
Attachments:
win32-math-bugs.txt
|
Albert Graef wrote: > This is all in svn now, so I guess it's release time. :) A bit late > tonight, but tomorrow... Just a quick note: test020.pure fails on Windows due to broken pow() and atan2() routines in the MS C library, which give nan's when they shouldn't in a few cases (I've attached the diffs of the test log for reference). Of course. What did I expect? :) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-08-22 13:00:22
|
Albert Graef wrote:
> I committed Eddie's math.pure test as test020.pure now, massaged
> somewhat to produce a nicely formatted test log. (r563)
Well, I had to fiddle with the output format some more, since 'make
check' would fail on this test due to (more or less) small rounding
discrepancies between systems. ("Almost zero" values are particularly
nasty.) Therefore I'm rounding floating point numbers to 3 significant
digits now, I hope that this is good enough. The latest log can be found
here:
http://pure-lang.svn.sourceforge.net/viewvc/pure-lang/pure/trunk/test/test020.log
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr....@t-..., ag...@mu...
WWW: http://www.musikinformatik.uni-mainz.de/ag
|
|
From: Albert G. <Dr....@t-...> - 2008-07-10 19:58:20
|
Jiri Spitz wrote: > > using math; > math.pure:34.7-26: external symbol 'round' cannot be found Ok, then they are probably defined as macros and so we need a workaround in runtime.cc, I'll have a look at that asap. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Libor S. <li...@gm...> - 2008-07-10 21:31:01
|
Here is another "quirk", this time on Linux. So much for those wonderful fast doubles ;) > round 1.4999999999999999; 2.0 > round 1.499999999999999; 1.0 L. On Thu, 10 Jul 2008 21:51:09 +0100, John Cowan <co...@cc...> wrote: > Albert Graef scripsit: >> Jiri Spitz wrote: >> > > using math; >> > math.pure:34.7-26: external symbol 'round' cannot be found >> >> Ok, then they are probably defined as macros and so we need a workaround >> in runtime.cc, I'll have a look at that asap. > > If "round" is defined only as a macro, the implementation is out of > compliance. However, "round" is only required by SUS3 and C99, > so older implementations may simply lack it. > > http://www.opengroup.org/onlinepubs/000095399/functions/round.html > > |
|
From: Albert G. <Dr....@t-...> - 2008-07-11 00:41:26
|
John Cowan wrote: > If "round" is defined only as a macro, the implementation is out of > compliance. In contrast to Cygwin, Mingw uses the native Windows libraries which at best pay lip service to POSIX. Some functions aren't implemented at all, others need a '_' prefix etc. etc. Both Mingw and LLVM try to work around some of these quirks, but that doesn't guarantee that each and every POSIX function is dlsym'able under its POSIX name, even if some compatible replacement is available. I work around this by providing wrappers for stuff that appears to be missing on Windows in runtime.cc. That's what I'm going to do with those functions, too. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: John C. <co...@cc...> - 2008-07-11 04:15:26
|
Albert Graef scripsit: > John Cowan wrote: > > If "round" is defined only as a macro, the implementation is out of > > compliance. > > In contrast to Cygwin, Mingw uses the native Windows libraries which at > best pay lip service to POSIX. Sorry, I lost track of the context and didn't realize we were talking MinGW here. There's certainly no reason to expect either SUS3 or C99 there! -- John Cowan co...@cc... http://ccil.org/~cowan The present impossibility of giving a scientific explanation is no proof that there is no scientific explanation. The unexplained is not to be identified with the unexplainable, and the strange and extraordinary nature of a fact is not a justification for attributing it to powers above nature. --The Catholic Encyclopedia, s.v. "telepathy" (1913) |
|
From: Albert G. <Dr....@t-...> - 2008-07-11 01:41:06
|
John Cowan wrote: > "Doing floating-point arithmetic is like making sand castles: > every time you move one, you get a little less sand and a little > more dirt." -quoted by Knuth, but I forget who he attributes it to. Most likely the quote is from Prof. William Kahan, the father of IEEE 754, Turing Award winner and ACM fellow. That's the same guy who also designed the numeric algorithms powering the legendary HP 10C "Voyager" series of programmable RPN calculators, so he's very well-known to HP calculator fans like me. :) Considering the metaphor, I'd say that the quote is from the "Mathematics Written in Sand" paper, which is available as a PDF from Kahan's website at http://www.cs.berkeley.edu/~wkahan/. It's been a while since I read the paper, so I can't say for sure. But it's recommended reading for everyone dabbling in numeric algorithms. Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: John C. <co...@cc...> - 2008-07-11 04:40:03
|
Albert Graef scripsit: > Considering the metaphor, I'd say that the quote is from the > "Mathematics Written in Sand" paper, which is available as a PDF from > Kahan's website at http://www.cs.berkeley.edu/~wkahan/. It's been a > while since I read the paper, so I can't say for sure. But it's > recommended reading for everyone dabbling in numeric algorithms. That PDF is searchable, and it doesn't include the word "dirt". But I agree that the sentiment sounds like Kahan. -- John Cowan co...@cc... http://www.ccil.org/~cowan O beautiful for patriot's dream that sees beyond the years Thine alabaster cities gleam undimmed by human tears! America! America! God mend thine every flaw, Confirm thy soul in self-control, thy liberty in law! --one of the verses not usually taught in U.S. schools |
|
From: Eddie R. <er...@bm...> - 2008-08-20 15:47:22
|
On Wed, 2008-08-20 at 11:34 -0400, John Cowan wrote: > Eddie Rucker scripsit: > > > (1) Is sqrt supposed to be defined for nan and inf? ln, sin, cos, etc, > > are. > > The hardware says that sqrt(inf) is inf and sqrt(nan) is nan, which > is what you expect given that inf*inf = inf and nan*nan = nan. Yep! But they aren't defined in math.pure. sqrt inf => sqrt inf and sqrt nan => sqrt nan. > In IEEE floats, the less tampering with the hardware the better. Most of the time I'd agree, but I still think log 0 => -inf sucks big time. Even though the limit of log x -> -inf as x -> 0 that is very different from saying log 0 == -inf. That's like saying 9/0 = inf because lim 9/x -> inf as x -> 0. > There was a young fellow of Trinity > Who solved the square root of infinity, > But while counting the digits > Was seized by the fidgets > Dropped maths and took up divinity. > > No wonder! Floating point is a bugger. e.r. |
|
From: Eddie R. <er...@bm...> - 2008-08-20 17:33:17
|
On Wed, 2008-08-20 at 12:16 -0400, John Cowan wrote: > Eddie Rucker scripsit: > > > Most of the time I'd agree, but I still think log 0 => -inf sucks big > > time. > > You have to remember what -inf and 0.0 actually mean: respectively > "a negative number too small to represent" and "a positive number too > close to zero to represent." And indeed, if you take the log of a number > too close to zero to represent, such as 1/(10^10^10) you will indeed > get a number too small to represent. You are right for 0.0. Yep, we have to use the |a-b| < epsilon definition for equality. However, for the integer 0 and the rational 0% 1, shouldn't log 0 be undefined? e.r. |
|
From: Albert G. <Dr....@t-...> - 2008-08-21 13:31:41
|
John Cowan wrote: > There was a young fellow of Trinity > Who solved the square root of infinity, > But while counting the digits > Was seized by the fidgets > Dropped maths and took up divinity. > > No wonder! LOL, I have to file that one in my quotes collection. Where is it from? >> (3) Shouldn't polar (x<:y) => x<:y ? >> (4) Shouldn't rect (x+:y) => x+:y ? > > Looks good to me. Fixed (r556). Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: John C. <co...@cc...> - 2008-08-21 14:22:58
|
Albert Graef scripsit: > LOL, I have to file that one in my quotes collection. Where is it from? That most prolific of all authors, Anonymous. It appears in several books that I know of and all over the Internet, with lots of variants. -- Yes, chili in the eye is bad, but so is your John Cowan ear. However, I would suggest you wash your co...@cc... hands thoroughly before going to the toilet. http://www.ccil.org/~cowan --gadicath |
|
From: Eddie R. <er...@bm...> - 2008-08-22 13:01:23
|
On Fri, 2008-08-22 at 11:14 +0200, Albert Graef wrote: > Eddie Rucker wrote: > I committed Eddie's math.pure test as test020.pure now, massaged > somewhat to produce a nicely formatted test log. (r563) Thanks. I've been rattled this week over here with the fall semester starting. > What remains is the unattractive task to check all the untagged results. > As we say over here, that's a "job for someone who killed mom and dad", > so I'd rather suggest that we take a "many eyes" approach to that. > Everyone here who feels like it and has some spare time on his hands can > just scan a few results at a time and report on the mailing list if he > notices anything suspicious. > > (Eddie, maybe we should also add another check on the result type and > flag results which aren't numbers? I leave that up to you.) Yea, I need to add max, min, and the relational operations. I say go ahead and release 0.5 even though I haven't finished with the full test. It is just too much happening right now for me to focus on what I'm doing. I was thinking of splitting the number tests up like the following: using math; using system; // unary functions let f = [sqrt, sin, cos, tan, ln, log, exp, atan, asin, acos, sinh, cosh, tanh, asinh, acosh, atanh, abs, re, im, arg, conj, rect, polar, cis, ceil, floor, round, frac, complexp, realp, rationalp, numberp, exactp, inexactp, infp, nanp]; // binary operations on complex let f2 = [(+), (-), (*), (/), (^), (==), (!=)]; // binary operations on everything but complex let f2_ordered = [(+), (-), (*), (/), (^), max, min, atan2, (!=), (==), (<), (>), (<=), (>=)]; // binary operations on just integers and rationals let fw = [(pow), (div), (mod)]; // number sets let Ns = [2,3000000000000000000000000000000000L]; let Zs = [-2,-1,0,1,2,5]; let Qs = [(-2)%3,0%4,4%5]; let Qno0s= [-1%2,5%4]; let Rs = [0.0, -e, pi]; let INs = [-inf,inf,-nan,nan]; let Cs = [a+:b; a=Zs+Qs+Rs+INs; b=Zs+Qs+Rs+INs]; ... I'll have to finish later. e.r. |
|
From: Albert G. <Dr....@t-...> - 2008-08-22 13:18:12
|
Eddie Rucker wrote: > Thanks. I've been rattled this week over here with the fall semester > starting. Fortunately, we still have 2 more months over here. :) I hope to spend a big slice of that time on Pure. > Yea, I need to add max, min, and the relational operations. I say go > ahead and release 0.5 even though I haven't finished with the full test. Yes, it will take some time to review all the test results anyway. At least we do have a test for math.pure now. Any remaining bugs will be slashed in the 0.6 release. I still have to build the Windows package, but I hope that I can release 0.5 tomorrow. It's taken long enough. ;-) But I think that it's also the most polished Pure release yet, and offers a lot of Good New Stuff(TM). Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: John C. <co...@cc...> - 2008-07-10 20:51:02
|
Albert Graef scripsit: > Jiri Spitz wrote: > > > using math; > > math.pure:34.7-26: external symbol 'round' cannot be found > > Ok, then they are probably defined as macros and so we need a workaround > in runtime.cc, I'll have a look at that asap. If "round" is defined only as a macro, the implementation is out of compliance. However, "round" is only required by SUS3 and C99, so older implementations may simply lack it. http://www.opengroup.org/onlinepubs/000095399/functions/round.html -- I marvel at the creature: so secret and John Cowan so sly as he is, to come sporting in the pool co...@cc... before our very window. Does he think that http://www.ccil.org/~cowan Men sleep without watch all night? |
|
From: John C. <co...@cc...> - 2008-07-10 21:34:32
|
Libor Spacek scripsit: > Here is another "quirk", this time on Linux. > So much for those wonderful fast doubles ;) > > > round 1.4999999999999999; > 2.0 > > round 1.499999999999999; > 1.0 They aren't called quick and dirty for nothing, and the C library is *not* guaranteed to preserve correctness when converting doubles to strings or vice versa. "Doing floating-point arithmetic is like making sand castles: every time you move one, you get a little less sand and a little more dirt." -quoted by Knuth, but I forget who he attributes it to. -- John Cowan http://ccil.org/~cowan co...@cc... SAXParserFactory [is] a hideous, evil monstrosity of a class that should be hung, shot, beheaded, drawn and quartered, burned at the stake, buried in unconsecrated ground, dug up, cremated, and the ashes tossed in the Tiber while the complete cast of Wicked sings "Ding dong, the witch is dead." --Elliotte Rusty Harold on xml-dev |
|
From: Eddie R. <er...@bm...> - 2008-07-10 21:48:17
|
On Thu, 2008-07-10 at 17:34 -0400, John Cowan wrote:
> Libor Spacek scripsit:
> > Here is another "quirk", this time on Linux.
> > So much for those wonderful fast doubles ;)
> >
> > > round 1.4999999999999999;
> > 2.0
> > > round 1.499999999999999;
> > 1.0
>
> They aren't called quick and dirty for nothing, and the C library
> is *not* guaranteed to preserve correctness when converting
> doubles to strings or vice versa.
You can bet your bippie it's a C thingy.
#include <stdio.h>
#include <math.h>
int main(int argc, char **argv) {
printf("%g\n", round(1.4999999999999999));
printf("%g\n", round(1.499999999999999));
return 0;
}
$ ./a.out
2
1
> "Doing floating-point arithmetic is like making sand castles:
> every time you move one, you get a little less sand and a little
> more dirt." -quoted by Knuth, but I forget who he attributes it to.
LOL. Knuth is *the* man.
e.r.
|
|
From: John C. <co...@cc...> - 2008-08-20 15:34:19
|
Eddie Rucker scripsit:
> (1) Is sqrt supposed to be defined for nan and inf? ln, sin, cos, etc,
> are.
The hardware says that sqrt(inf) is inf and sqrt(nan) is nan, which
is what you expect given that inf*inf = inf and nan*nan = nan.
In IEEE floats, the less tampering with the hardware the better.
There was a young fellow of Trinity
Who solved the square root of infinity,
But while counting the digits
Was seized by the fidgets
Dropped maths and took up divinity.
No wonder!
> (2) ceil, floor, round, and frac for complex numbers are undefined and
> IMHO should stay that way.
Agreed. Implementing them would imply that there is a natural ordering
on the complex numbers corresponding to <, and there obviously isn't.
> (3) Shouldn't polar (x<:y) => x<:y ?
> (4) Shouldn't rect (x+:y) => x+:y ?
Looks good to me.
--
Andrew Watt on Microsoft: John Cowan
Never in the field of human computing co...@cc...
has so much been paid by so many http://www.ccil.org/~cowan
to so few! (pace Winston Churchill)
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X