pure-lang-users Mailing List for Pure (Page 11)
Status: Beta
Brought to you by:
agraef
Menu
▾
▴
pure-lang-users — Discussion of the Pure programming language.
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(31) |
May
(422) |
Jun
(241) |
Jul
(268) |
Aug
(281) |
Sep
(109) |
Oct
(1) |
Nov
|
Dec
|
|---|
|
From: Albert G. <Dr....@t-...> - 2008-08-20 23:28:49
|
John Lunney wrote: > Should runaway things like this be detected or not? I'm guessing not... Solving the halting problem today, are we? :-P No, seriously, in some cases you *want* to write loops which run forever, so it's not a good idea to forbid that! 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-20 23:04:24
|
John Lunney wrote: > So I entered the following line: > -(a) = -a; I don't understand what you're trying to do there. (a) is just a, so you might just as well write 'loop = loop;' instead. In either case it's a tail-recursive loop which will run forever. > Another time I tried it, Pure just quit with no error. I can't reproduce that, I always get the same expected non-terminating behaviour. Maybe you killed and restarted the interpreter, and forgot to reenter the equation before starting the evaluation? 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-20 22:57:36
|
Eddie Rucker wrote: > > using math; > > let x = [1+:2, 1%4]; > > [(i,j); i=x; j=x]; > [(0+:1,1+:2),(0+:1,1L%4L),(0+:1,1+:2),(0+:1,1L%4L)] Yeah, that's certainly a bug. List comprehensions get processed like some kind of macro internally, and it looks like there's some bad name capturing going on there. Thanks for the report, I will have to look into this. 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-20 22:54:35
|
>> I'd avoid this: it's easy enough to add a post-processing ruleset >> to make the change. Just because the real side of a computation has >> lost significance doesn't mean the imaginary side doesn't still contain >> useful data (or vice versa). The whole point of inf and nan is to allow >> computation to continue, postponing the check for significance to the end. Spot on. > Thanks John! You and Albert keep it coming. That's rather remarkable, since I didn't even comment yet. ;-) Sorry, I'm still catching up on the flood of messages in this thread. It's getting late over here, so I think I'll have to reply tomorrow. A brief look indicates that probably some bugfixes in math.pure are in order, so I'm going to postpone the release until that stuff is sorted out. 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 22:03:53
|
> using math; > let x = [1+:2, 1%4]; > [(i,j); i=x; j=x]; [(0+:1,1+:2),(0+:1,1L%4L),(0+:1,1+:2),(0+:1,1L%4L)] As if this weren't weird enough, if you type this in right after > let y = [1%2, 3%4]; > [(i,j); i=y; j=y] [(0+:1,1L%2L),(0+:1,3L%4L),(0+:1,1L%2L),(0+:1,3L%4L)] Note that > let x = [1%2, 3%4]; > [(j,k); j=x; k=x]; [(1L%2L,1L%2L),(1L%2L,3L%4L),(3L%4L,1L%2L),(3L%4L,3L%4L)] Works. So my guess is that the constant i defined in math.pure is getting mixed up with the i in [(i,j); i=x; j=x]; e.r. |
|
From: Eddie R. <er...@bm...> - 2008-08-20 21:42:12
|
On Wed, 2008-08-20 at 17:32 -0400, John Cowan wrote: > Eddie Rucker scripsit: > > Should we have the following rules? > > _+:nan = nan; > > nan+:_ = nan; > > nan<:_ = nan; > > _<:nan = nan; > > > > My thinking is that if any part of a complex number is nan then the > > whole thing is not a number. OTOH, inf+:inf, 0+:inf, inf+:0, etc, you > > might want to keep that way for either further processing or to let the > > user know the result is a complex number. What does everyone think about > > this? > > I'd avoid this: it's easy enough to add a post-processing ruleset > to make the change. Just because the real side of a computation has > lost significance doesn't mean the imaginary side doesn't still contain > useful data (or vice versa). The whole point of inf and nan is to allow > computation to continue, postponing the check for significance to the end. > Thanks John! You and Albert keep it coming. e.r. |
|
From: John C. <co...@cc...> - 2008-08-20 21:32:50
|
Eddie Rucker scripsit: > Should we have the following rules? > _+:nan = nan; > nan+:_ = nan; > nan<:_ = nan; > _<:nan = nan; > > My thinking is that if any part of a complex number is nan then the > whole thing is not a number. OTOH, inf+:inf, 0+:inf, inf+:0, etc, you > might want to keep that way for either further processing or to let the > user know the result is a complex number. What does everyone think about > this? I'd avoid this: it's easy enough to add a post-processing ruleset to make the change. Just because the real side of a computation has lost significance doesn't mean the imaginary side doesn't still contain useful data (or vice versa). The whole point of inf and nan is to allow computation to continue, postponing the check for significance to the end. -- John Cowan http://ccil.org/~cowan co...@cc... Monday we watch-a Firefly's house, but he no come out. He wasn't home. Tuesday we go to the ball game, but he fool us. He no show up. Wednesday he go to the ball game, and we fool him. We no show up. Thursday was a double-header. Nobody show up. Friday it rained all day. There was no ball game, so we stayed home and we listened to it on-a the radio. --Chicolini |
|
From: Eddie R. <er...@bm...> - 2008-08-20 21:17:40
|
On Wed, 2008-08-20 at 16:05 -0500, Eddie Rucker wrote: > If atan is defined for complex numbers, shouldn't atan2 ? Nope. Forget that. e.r. |
|
From: Eddie R. <er...@bm...> - 2008-08-20 21:05:41
|
If atan is defined for complex numbers, shouldn't atan2 ? e.r. On Wed, 2008-08-20 at 15:49 -0500, Eddie Rucker wrote: > Should we have the following rules? > _+:nan = nan; > nan+:_ = nan; > nan<:_ = nan; > _<:nan = nan; > > My thinking is that if any part of a complex number is nan then the > whole thing is not a number. OTOH, inf+:inf, 0+:inf, inf+:0, etc, you > might want to keep that way for either further processing or to let the > user know the result is a complex number. What does everyone think about > this? > > e.r. > > On Wed, 2008-08-20 at 13:31 -0500, Eddie Rucker wrote: > > Albert, > > While testing, I looked over some of the logs and here are my > > suggestions: > > > > Add the rules > > sqrt inf = inf; > > sqrt nan = nan; > > ln inf = inf; > > ln nan = nan; > > > > Both of these rules also fix > > acosh and atanh of nan and inf > > > > I think cis is broken for complex numbers. I've got to run give another > > test. > > > > e.r. > > > > > > > > ------------------------------------------------------------------------- > > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > > Build the coolest Linux based applications with Moblin SDK & win great prizes > > Grand prize is a trip for two to an Open Source event anywhere in the world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > pure-lang-users mailing list > > pur...@li... > > https://lists.sourceforge.net/lists/listinfo/pure-lang-users > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > pure-lang-users mailing list > pur...@li... > https://lists.sourceforge.net/lists/listinfo/pure-lang-users |
|
From: Eddie R. <er...@bm...> - 2008-08-20 20:49:41
|
Should we have the following rules? _+:nan = nan; nan+:_ = nan; nan<:_ = nan; _<:nan = nan; My thinking is that if any part of a complex number is nan then the whole thing is not a number. OTOH, inf+:inf, 0+:inf, inf+:0, etc, you might want to keep that way for either further processing or to let the user know the result is a complex number. What does everyone think about this? e.r. On Wed, 2008-08-20 at 13:31 -0500, Eddie Rucker wrote: > Albert, > While testing, I looked over some of the logs and here are my > suggestions: > > Add the rules > sqrt inf = inf; > sqrt nan = nan; > ln inf = inf; > ln nan = nan; > > Both of these rules also fix > acosh and atanh of nan and inf > > I think cis is broken for complex numbers. I've got to run give another > test. > > e.r. > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > pure-lang-users mailing list > pur...@li... > https://lists.sourceforge.net/lists/listinfo/pure-lang-users |
|
From: Eddie R. <er...@bm...> - 2008-08-20 18:31:33
|
Albert, While testing, I looked over some of the logs and here are my suggestions: Add the rules sqrt inf = inf; sqrt nan = nan; ln inf = inf; ln nan = nan; Both of these rules also fix acosh and atanh of nan and inf I think cis is broken for complex numbers. I've got to run give another test. e.r. |
|
From: Eddie R. <er...@bm...> - 2008-08-20 17:46:40
|
On Wed, 2008-08-20 at 13:38 -0400, John Cowan wrote: > Eddie Rucker scripsit: > > > 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? > > Well, in general all the trig functions first cast their argument to a float; > I think everyone expects that in whatever language, though some do provide > integer square root functions, probably because they're easy to implement. > Ok. I can live with that. I another note, mz-scheme says (log 0) is undefined and (log 0.0) is -inf.0. IOW, It really does the right thing. e.r. |
|
From: John C. <co...@cc...> - 2008-08-20 17:38:36
|
Eddie Rucker scripsit:
> 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?
Well, in general all the trig functions first cast their argument to a float;
I think everyone expects that in whatever language, though some do provide
integer square root functions, probably because they're easy to implement.
--
John Cowan <co...@cc...>
http://www.ccil.org/~cowan
.e'osai ko sarji la lojban.
Please support Lojban! http://www.lojban.org
|
|
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: John C. <co...@cc...> - 2008-08-20 16:16:39
|
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. > different from saying log 0 == -inf. That's like saying 9/0 = inf > because lim 9/x -> inf as x -> 0. 9/0 is indeed inf, though 9%0 ought to be an error (in Q it's inf). -- Even a refrigerator can conform to the XML John Cowan Infoset, as long as it has a door sticker co...@cc... saying "No information items inside". http://www.ccil.org/~cowan --Eve Maler |
|
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: 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)
|
|
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: John L. <joh...@gm...> - 2008-08-20 13:30:23
|
On Wed, Aug 20, 2008 at 2:18 PM, Eddie Rucker <er...@bm...> wrote: > On my box: > > -(a); > -a > > So the lhs is the same as the rhs already. Ah, I didn't realize that was already defined. Should have checked I suppose! > The second one sounds > weird and something seems wrong with quiting. Memory usage should be > constant because nothing is being allocated, the interpreter is just > firing the same rule over and over. I've been trying to replicate it, but haven't managed to. Interestingly, memory usage was constant for a while, about 9MB, and then dropped to 160KB after a while. Of course, I am on Windows here in work, so those figures could mean anything! > The interpreter is just going to evaluate whatever rule you give it. If > you code "while (1) ;" in C the resulting program is going sit there and > loop until you kill it. Yeah, now that I see that LHS and RHS are equal, that's fine. Thanks, John |
|
From: Eddie R. <er...@bm...> - 2008-08-20 13:18:52
|
On Wed, 2008-08-20 at 13:48 +0100, John Lunney wrote: > Hey guys, > I was playing round with the symbolic computation stuff from the > examples, and had the idea of trying to reduce -(a) to -a. > So I entered the following line: > -(a) = -a; On my box: > -(a); -a So the lhs is the same as the rhs already. So your making a rule like x = x; The interpreter is reducing -(a) to -a which is the same as -(a) and then reducing -a to -a and then reducing -a to -a and then ... Shazam! an infinite loop. > Pure instantly took almost 100% of my processor and went into what I > presume was an infinite loop. I had seen this coming, of course. > Another time I tried it, Pure just quit with no error. Memory usage > seems to remain constant. Yes, the first one is caused by an infinite loop. The second one sounds weird and something seems wrong with quiting. Memory usage should be constant because nothing is being allocated, the interpreter is just firing the same rule over and over. > Should runaway things like this be detected or not? I'm guessing not... The interpreter is just going to evaluate whatever rule you give it. If you code "while (1) ;" in C the resulting program is going sit there and loop until you kill it. HTH. I know Albert can do a better job with this. e.r. |
|
From: John L. <joh...@gm...> - 2008-08-20 12:48:35
|
Hey guys, I was playing round with the symbolic computation stuff from the examples, and had the idea of trying to reduce -(a) to -a. So I entered the following line: -(a) = -a; I had a bad feeling about that, but went with it anyway. When I tried to test it with: -(a); Pure instantly took almost 100% of my processor and went into what I presume was an infinite loop. I had seen this coming, of course. Another time I tried it, Pure just quit with no error. Memory usage seems to remain constant. Should runaway things like this be detected or not? I'm guessing not... John |
|
From: Eddie R. <er...@bm...> - 2008-08-20 10:24:26
|
On Wed 20/08/08 4:20 AM , Albert Graef Dr....@t-... sent: > 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 would really like to finish my regression tests on math.pure but I don't know if it is going to be possible within the next few hours. Yesterday was a killer at work and today promises to be another :( I've got an hour to get it coded between ordering accuplacers this morning and the insurance committee meeting. e.r. |
|
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: Ryan S. <rya...@us...> - 2008-08-19 12:22:08
|
On Aug 19, 2008, at 06:52, Albert Graef wrote: > Ryan Schmidt wrote: >> You're not passing -n before -v7. You're passing $(ECHO_N), and >> you've set $(ECHO_N) to empty on Leopard. But I don't think you >> should: > > Rrright. Counting 2+2=5, it just dawned on me, too. ;-) Silly editing > blunder! Of course that's supposed to be a -n there, but apparently I > just did a global s/-n/$(ECHO_N)/ when "fixing" the Makefile for the > Leopard shell. That's how it seemed to me too! :) > Aaahrgh, I can't tell you how silly I feel now... > > Ok, this should be fixed now, along with the missing $(ECHO_C) thing. > Can you please give it another go? It is considerably less silly now, and in fact all tests pass on Tiger and Leopard and the make check output is formatted correctly on both. Long live $(ECHO_C)! Thanks for fixing this. I updated the pure-devel port in MacPorts to r543. |
|
From: Albert G. <Dr....@t-...> - 2008-08-19 11:52:07
|
Ryan Schmidt wrote: > You're not passing -n before -v7. You're passing $(ECHO_N), and > you've set $(ECHO_N) to empty on Leopard. But I don't think you should: Rrright. Counting 2+2=5, it just dawned on me, too. ;-) Silly editing blunder! Of course that's supposed to be a -n there, but apparently I just did a global s/-n/$(ECHO_N)/ when "fixing" the Makefile for the Leopard shell. Aaahrgh, I can't tell you how silly I feel now... Ok, this should be fixed now, along with the missing $(ECHO_C) thing. Can you please give it another go? 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 |
6 messages has been excluded from this view by a project administrator.
