pure-lang-users Mailing List for Pure (Page 4)
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-09-09 11:13:04
|
John Cowan wrote: > Division with slash effectively promotes its arguments to floats, so > 0.0 should be promoted to 0.0+:0.0. Good point! In fact gcc seems to do that, too (I get nan+:nan for /0.0 just as well as for /(0.0+I*0.0). However, that's *not* what ISO/IEC9899, Annex G [1] says (see G.5.1, especially Example 2). It requires an inf+I*inf result in the /0.0 case, if I read it right. That has the "informative" sticker (i.e., "recommended" but not "normative"), so implementations may differ. AFAICT, my implementation in math.pure conforms with Annex G (at least the multiplicative operators, still have to check the others). So I guess I'll just leave it at that for now. [1] I'm referring to the 2005 draft, couldn't find anything newer. Here's the URL: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf 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-09-09 10:58:18
|
Eddie Rucker wrote: > In Pure, ln 0 => -inf and ln 0.0 -> -inf. Yes, that's because int args of those floating point operations are generally promoted to double. It's the most sensible way to do it. The same is true for / (which is *always* an inexact floating point division in Pure, just like in C). > Hm. if we start worrying about 0.0+:0 vs 0.0+:0.0, then should we also > worry about ln 0 vs ln 0.0 too? I think I've already mentioned that > mzscheme says that (log 0) is undefined and (log 0.0) => -inf.0. > Am I'm flogging a dead horse here? Yes, you are, I'm afraid. :) The Scheme way doesn't make much sense there because log is always an inexact operation. 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-09-09 00:27:29
|
On Mon, 2008-09-08 at 20:14 -0400, John Cowan wrote: > Albert Graef scripsit: > > > - The divisor should be promoted to a complex 0.0+:0.0 in the first > > case, so you get nan+:nan in either case. > > Division with slash effectively promotes its arguments to floats, so > 0.0 should be promoted to 0.0+:0.0. Allrighty then! I know Albert already has enough flies to swat without me fanning the turds :( Sorry. e.r. |
|
From: John C. <co...@cc...> - 2008-09-09 00:14:30
|
Albert Graef scripsit: > - The divisor should be promoted to a complex 0.0+:0.0 in the first > case, so you get nan+:nan in either case. Division with slash effectively promotes its arguments to floats, so 0.0 should be promoted to 0.0+:0.0. -- As you read this, I don't want you to feel John Cowan sorry for me, because, I believe everyone co...@cc... will die someday. http://www.ccil.org/~cowan --From a Nigerian-type scam spam |
|
From: Eddie R. <er...@bm...> - 2008-09-08 23:07:57
|
On Tue, 2008-09-09 at 00:31 +0200, Albert Graef wrote: > Eddie Rucker wrote: > > > (2.0+:1.0)/0.0; > > inf+:inf > > > (2.0+:1.0)/(0.0+:0.0); > > nan+:nan > > > > Um. Should this be consistent? > > Maybe, not sure. AFAICS, there are three possible perspectives: > > - (2.0+:1.0)/0.0 has an exact 0 in the imaginary part of the divisior, > so it's actually a vector multiplied with an infinite scalar, whereas in > the case of (2.0+:1.0)/(0.0+:0.0) it's an inexact zero so the general > formula must be used which yields nan+:nan because a zero meets a pole > in both components. (OTOH, if we take this view then probably > (2.0+:1.0)/(0.0+:0) should yield the same result as the former, whereas > right now it yields the same result as the latter.) In Pure, ln 0 => -inf and ln 0.0 -> -inf. The former is an exact zero so in real math ln 0 should be undefined. The second is a number close to zero which yields -inf. So I'm thinking the exact 0 for the imaginary part of 0.0 should also be promoted to double just like in ln 0. If I'm wrong then I'm Ok with that. > - The divisor should be promoted to a complex 0.0+:0.0 in the first > case, so you get nan+:nan in either case. > > - The divisior should be promoted to a real 0.0 in the second case, > yielding inf+:inf in either case. That's what I get with mzscheme, but > it doesn't make any real sense (pun intended) to me because 0.0+:0.0 is > *not* the same as 0.0+:0 (or just 0.0) in the IEEE 754 sense (the > imaginary zero might as well be just an underflow). Hm. if we start worrying about 0.0+:0 vs 0.0+:0.0, then should we also worry about ln 0 vs ln 0.0 too? I think I've already mentioned that mzscheme says that (log 0) is undefined and (log 0.0) => -inf.0. Am I'm flogging a dead horse here? Oh woe woe woe is me! e.r. |
|
From: John C. <co...@cc...> - 2008-09-08 23:04:35
|
Albert Graef scripsit: > I must admit that I don't know all that much about web programming, so I > have to ask what's the difference between the ordinary and the fast cgi > interface? The FastCGI interface keeps the language processor running rather than starting a new process for every incoming request, so it is much more lightweight. The web server talks with the processor over a local domain socket. (Unix) or named pipe (Windows; named pipes in Windows are really sockets). The wire protocol is at http://www.fastcgi.com/devkit/doc/fcgi-spec.html ; there are many libraries. -- Take two turkeys, one goose, four John Cowan cabbages, but no duck, and mix them http://www.ccil.org/~cowan together. After one taste, you'll duck co...@cc... soup the rest of your life. --Groucho |
|
From: Albert G. <Dr....@t-...> - 2008-09-08 22:35:15
|
Hi Andrew, nice to hear from you, it's been a while! How are you? Andrew Berg wrote: > For my money, a fast-cgi interface would be a log more fun than an apache one. I must admit that I don't know all that much about web programming, so I have to ask what's the difference between the ordinary and the fast cgi interface? 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-09-08 22:29:45
|
Eddie Rucker wrote: > > (2.0+:1.0)/0.0; > inf+:inf > > (2.0+:1.0)/(0.0+:0.0); > nan+:nan > > Um. Should this be consistent? Maybe, not sure. AFAICS, there are three possible perspectives: - (2.0+:1.0)/0.0 has an exact 0 in the imaginary part of the divisior, so it's actually a vector multiplied with an infinite scalar, whereas in the case of (2.0+:1.0)/(0.0+:0.0) it's an inexact zero so the general formula must be used which yields nan+:nan because a zero meets a pole in both components. (OTOH, if we take this view then probably (2.0+:1.0)/(0.0+:0) should yield the same result as the former, whereas right now it yields the same result as the latter.) - The divisor should be promoted to a complex 0.0+:0.0 in the first case, so you get nan+:nan in either case. - The divisior should be promoted to a real 0.0 in the second case, yielding inf+:inf in either case. That's what I get with mzscheme, but it doesn't make any real sense (pun intended) to me because 0.0+:0.0 is *not* the same as 0.0+:0 (or just 0.0) in the IEEE 754 sense (the imaginary zero might as well be just an underflow). I haven't checked the Goldberg paper, though. Maybe there's a "more defined" formula in the complex divisor case? 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-09-08 18:15:23
|
While piddling with some math problems, I noticed the following behavior. > (2.0+:1.0)/0.0; inf+:inf > (2.0+:1.0)/(0.0+:0.0); nan+:nan Um. Should this be consistent? e.r. |
|
From: Albert G. <Dr....@t-...> - 2008-09-08 16:49:35
|
> Rob Hubbard wrote: >> I had been eagerly anticipating QCalc for Windoze, wondering whether >> that has essentially been shelved now. > > This will happen at some point. For the time being, I did a quick-and-dirty hack on Qpad to make it work with Pure. "PurePad" will also be included in the 0.6 release for Windows. -- 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: Andrew B. <and...@ya...> - 2008-09-08 04:58:10
|
--- On Sun, 9/7/08, Albert Graef <Dr....@t-...> wrote: > Do we need an Apache module? There's a Q Apache module which shouldn't > be that hard to port to Pure, but it never offered much more than cgi > functionality anyway, and I'm not sure whether anybody really used it. For my money, a fast-cgi interface would be a log more fun than an apache one. -andrew |
|
From: Albert G. <Dr....@t-...> - 2008-09-08 03:17:47
|
Eddie Rucker wrote: > With a few libraries like GSL, ODBC, a GUI kit, and some kind of mechanism to move my > programs to the office computers, I'll have a nice tool for most if not all of my tasks. Well, with the base package nearly-feature complete now (vector/matrix and multithreading support is still on my TODO list), maybe we can start collecting a wishlist of essential library interfaces to turn Pure into a practical programming tool. Maybe we even find some brave souls who are willing to work on some of these. ;-) Here's what I can think of from the top of my head: - GSL - ODBC and SQLite3 - XML/XSLT (wrapper for the Gnome libxml2/libxslt libraries) - Qt4 So that lines up with Eddie's needs pretty well. :) ODBC, XML/XSLT and Qt3 are available for Q, so it shouldn't be a big deal to port these. (Well, Qt4 might still be quite some work, but there's a half-finished Qt4 module for Q lying around on my harddrive. I'd be willing to start working on that one when the matrix/vector support and the Pd module I need for my computer music courses are finished.) Probably we also need to add some stuff to the system interface (low-level I/O, sockets, etc.), but that can be ported from Q's clib module as needed. Do we need an Apache module? There's a Q Apache module which shouldn't be that hard to port to Pure, but it never offered much more than cgi functionality anyway, and I'm not sure whether anybody really used it. 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-09-07 16:42:16
|
On Sun 07/09/08 7:05 AM , Albert Graef Dr....@t-... sent: > release, as it's taken shape in svn during the past two weeks. If you > still have some bug reports, now is the time! I haven't been able to test lately. Sorry, I've been having to use Java to do some GUI/ODBC/CSV stuff for work. Some of you will probably tell me that I should be using VB for this, but VB costs more than my budget. I would like to use Pure for this someday time willing :) Java used to be small and clean but now it's an ugly hack and I had forgoten how verbose it is. I would use mzscheme for this, but srpersist only works on version 209 and there is no table or list view widget in the GUI kit. There is a table widget in PlaneT but that doesn't work on version 209. John, do you know of a scheme that has a GUI kit with a table, grid, or list view widget and an ODBC library? If Ocaml's ODBC module came as a binary, I would used that, but I cannot afford the VC compiler to compile it. I don't know if Mingw will compile it or not. Anyway, Java is already on all of the office computers and so my applications are ready to go with no installing. > (Eddie, I haven't forgotten about the matrix/vector stuff, but with all > the important new features already in 0.6, I just think it's better to > do a release now and then start working on the GSL support > immediately.) That is ok, I haven't had time see above. > - Macros: These are implemented as rewriting rules which are applied at > - Thunks a.k.a. "futures": These are realized as anonymous > - Private namespaces. You can now declare symbols as private in a > - Sentries (object finalizers) and references (mutable expression > - User-defined hook for the expression printer (__show__). This allows > The manual has been updated, too, so you can find further details Wow, Albert has been a busy bee ;-) With a few libraries like GSL, ODBC, a GUI kit, and some kind of mechanism to move my programs to the office computers, I'll have a nice tool for most if not all of my tasks. e.r. |
|
From: Albert G. <Dr....@t-...> - 2008-09-07 12:03:39
|
Hi everybody, this is *not* a release announcement (Pure 0.6 isn't out yet, I hope to get to that in the next few days). But as I've fallen a bit silent lately, here is a quick summary of the new stuff in the forthcoming 0.6 release, as it's taken shape in svn during the past two weeks. If you still have some bug reports, now is the time! (Eddie, I haven't forgotten about the matrix/vector stuff, but with all the important new features already in 0.6, I just think it's better to do a release now and then start working on the GSL support immediately.) - Macros: These are implemented as rewriting rules which are applied at compile time, and can be used for all usual preprocessing purposes, including the optimization and inlining of function calls at the source level, and the programming of user-defined special forms. And of course they're "hygienic". - Thunks a.k.a. "futures": These are realized as anonymous parameterless closures (a la Alice ML) which are "called by need" (including memoization), and are used to implement lazy data structures. As a showcase, the prelude now implements lazy lists a.k.a. "streams". - Private namespaces. You can now declare symbols as private in a module, to hide away internal helper functions and constructor symbols, and to keep the global public namespace clean. - Sentries (object finalizers) and references (mutable expression pointers). File objects in the system module now employ sentries in order to close themselves when they're garbage-collected. - New interactive startup files (.purerc). These are just normal Pure scripts with additional definitions for interactive usage. - The 'list' command was renamed to 'show' (to avoid a clash with the prelude function 'list'), and a new 'dump' command was added. The latter is similar to 'show', but saves a snapshot of your current interactive environment in a file. - User-defined hook for the expression printer (__show__). This allows you to define your own custom print representations for expressions at runtime. - Syntax highlighting for gedit (contributed by Eddie Rucker, thanks!). The manual has been updated, too, so you can find further details there. 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-09-07 11:15:55
|
> Rob Hubbard wrote: >> Perhaps the installer could have an "install for all users" option >> (putting this variable in the system rather than user environment)? > > Right, I'll have to look into that, I'm running as admin myself so I > never noticed this. Silly, I had those environment variables configured for the user environment. I fixed this now. I also added a warning message to the interactive startup if the prelude isn't found, which instructs the user to check the PURELIB variable. This will in the forthcoming 0.6 release. 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-09-05 01:18:19
|
Albert Graef wrote: > (I also changed the <<external object>> notation, which could be > mistaken as ordinary expression syntax, to those double curly braces > which aren't -- and won't be -- legal Pure. If anyone has a better > suggestion, or prefers it the way it was, I'd like to hear about it.) Well, actually that turned out to be a bad idea as well, so I changed it to the #<...> syntax which should be familiar to Schemers. This won't parse as a Pure expression no matter in which context (although you might still fool the interpreter by declaring an '#<' operator, oh well). (Note that this is all about print syntax only, so it doesn't affect any programs except possibly the regression tests.) -- 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-09-05 00:00:41
|
John Lunney wrote: > I REALLY think there should be some sort of character before these > commands, such as list and friends. It's one of my few qualms about > Pure! John, I understand your pov, and we actually had a fairly heated debate over this issue when Libor brought it up. But I do value convenience more than safety here. Just think of it as if those commands were additional keywords. With the exception of the 'list' command (which I now renamed to 'show') those commands aren't really what you'd frequently want to use as a function or variable name. However, I admit that there should at least be a warning if you happen to do that, I'm working on that now. 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-09-04 23:51:00
|
Eddie Rucker wrote: > How about lr for list rules. It's not only rules that can be listed, but also variable and constant definitions, as well as assembler code and other information. In fact, with -s no rules will be listed at all. Anyway, John convinced me that this command is too important to fall victim to an acronym. And 'show' isn't bad at all, so I changed it to that now. That's already in svn. I think it would be a good idea to warn the programmer when he uses one of these special commands as an ordinary identifier in his programs, even though they're not really keywords of the language. That should make it easier for people who are not familiar with the interactive command language yet. Those warnings could be restricted to interactive mode, so that they wouldn't bother you with a program that's only run in batch mode. 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-09-04 23:31:28
|
On Fri, 2008-09-05 at 00:21 +0200, Albert Graef wrote: > ! is already being used for shell escapes, which is pretty much standard > for any kind of Unix program with a command line. For the occasional > shell command that's good enough. But I hate it if I have to prefix > basic stuff like 'cd' or 'ls' which are in my muscle memory. How about lr for list rules. e.r. |
|
From: Albert G. <Dr....@t-...> - 2008-09-04 22:19:34
|
Eddie Rucker wrote: > LOL. Call it shrooms for mushrooms or dc for Divine Cactus (Peyote)! I like the sound of that. :) It vaguely reminds me of the arcane command syntax of the monitor program on early SUN workstations. We didn't get to toggle in a boot loader program, but that was almost as good. ;-) > Maybe a '!' as an escape? ! is already being used for shell escapes, which is pretty much standard for any kind of Unix program with a command line. For the occasional shell command that's good enough. But I hate it if I have to prefix basic stuff like 'cd' or 'ls' which are in my muscle memory. Besides that, it's really cool if I run Pure in the Kate terminal pane and Kate properly synchronizes the interpreter with the directory of the current edit window. That only works because the interpreter knows how to handle a plain 'cd' command. It's a minor point, but actually Kate works pretty well as an edit+run environment for Pure, and its folding support rocks. 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-09-04 21:54:57
|
John Cowan wrote: > Strong associations with LSD-25 for me, Ha, I thought that nobody would notice. ;-) > How about "show"? I actually thought about that, too. But then I remembered that I might want a 'show' function for some H(ask)ellish purpose. > Or how about using a signal character before all commands, and think > of it as part of the command? Yeah, we discussed that idea when Pure was just born (I think Libor originally brought that up), but I very strongly prefer unstropped commands (at least as much as others hate them ;-). Anyway, it's really only an issue with that one command, and that can be resolved by picking something that's less generic than 'list'. 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 L. <joh...@gm...> - 2008-09-04 21:23:48
|
On 4 Sep 2008, at 21:12, Eddie Rucker wrote: >> Or how about using a signal character before all commands, and think >> of it as part of the command? Lisp folks like to use comma, >> because it >> never appears at the beginning of an expression. > > Maybe a '!' as an escape? I think the ',' as a first char might be > interpreted as a tuple but I could be (probably) wrong. > > e.r. I REALLY think there should be some sort of character before these commands, such as list and friends. It's one of my few qualms about Pure! I think the ! could work, but I don't really mind. John |
|
From: Eddie R. <er...@bm...> - 2008-09-04 20:12:36
|
On Thu, 2008-09-04 at 15:32 -0400, John Cowan wrote: > Albert Graef scripsit: > > > How about calling the interactive 'list' command 'lsd' (for "list > > definition") instead? In any case it should be short, memoizable and > > not likely to be used as a function name. Any better ideas? > > Strong associations with LSD-25 for me, and with pounds shillings and > pence for older Brits. How about "show"? LOL. Call it shrooms for mushrooms or dc for Divine Cactus (Peyote)! Just joking ;-) show sounds fine to me. Mabye rlist for "rule list." > Or how about using a signal character before all commands, and think > of it as part of the command? Lisp folks like to use comma, because it > never appears at the beginning of an expression. Maybe a '!' as an escape? I think the ',' as a first char might be interpreted as a tuple but I could be (probably) wrong. e.r. |
|
From: John C. <co...@cc...> - 2008-09-04 19:32:28
|
Albert Graef scripsit: > How about calling the interactive 'list' command 'lsd' (for "list > definition") instead? In any case it should be short, memoizable and > not likely to be used as a function name. Any better ideas? Strong associations with LSD-25 for me, and with pounds shillings and pence for older Brits. How about "show"? Or how about using a signal character before all commands, and think of it as part of the command? Lisp folks like to use comma, because it never appears at the beginning of an expression. -- And through this revolting graveyard of the universe the muffled, maddening beating of drums, and thin, monotonous whine of blasphemous flutes from inconceivable, unlighted chambers beyond Time; the detestable pounding and piping whereunto dance slowly, awkwardly, and absurdly the gigantic tenebrous ultimate gods --the blind, voiceless, mindless gargoyles whose soul is Nyarlathotep. (Lovecraft) John Cowan co...@cc... |
|
From: Albert G. <Dr....@t-...> - 2008-09-04 18:18:16
|
Eddie Rucker wrote:
> They seem to be down quite a bit :(
svn is back up, and I committed the latest changes (see ChangeLog). The
manual also has a subsection with (hopefully) instructive stream
examples now. (See the end of the EXAMPLES section.)
> Uhm. Mine don't do that. I'm using revision 698 that latest.
> > ones = 1 : ones&;
> > integers=1 : zipwith (+) ones integers&;
> > let ints = integers;
> > take 10 ints;
> 1:{{thunk 0x7fe5e17d0488}}
Yes, the results you got are correct. I fixed up take/takewhile which
were too eager. Use, e.g., list (take 10 ints) to force the stream, like
in Q.
(I also changed the <<external object>> notation, which could be
mistaken as ordinary expression syntax, to those double curly braces
which aren't -- and won't be -- legal Pure. If anyone has a better
suggestion, or prefers it the way it was, I'd like to hear about it.)
Talking about the dreaded 'list' at the beginning of a line ambiguity, I
really think I have to do something about this, it bites me all the
time, too. I don't have that problem with other commands, it's just that
darn 'list' command, because the 'list' function gets used so frequently.
How about calling the interactive 'list' command 'lsd' (for "list
definition") instead? In any case it should be short, memoizable and not
likely to be used as a function name. Any better ideas?
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
|
6 messages has been excluded from this view by a project administrator.
