q-lang-users — general discussion, questions, suggestions, etc.

Re: [q-lang-users] Polynomial module.

[Rob H. <hub...@gm...>]

That should have been

    sieve {X|Xs} = {X|sieve {var Y_sieve: Y_sieve in Xs, Y_sieve mod X<>0}};

below. I forgot the "var". Sorry.

Rob.

On 02/11/06, Rob Hubbard <hub...@gm...> wrote:
> Hello Albert,
>
> Thanks for the information...
>
> On 31/10/06, Albert Graef <Dr....@t-...> wrote:
> > Hi Rob,
> >
> > I'm redirecting this to the list so that we can discuss it here. I tend
> > to agree that this problem calls for a general solution which also
> > adresses the weirdness of lambda reported in Eddie's recent post.
> >
> > Rob Hubbard wrote:
> > > If you run polynomial.q with --pedantic, you may notice the message
> > >    Warning polynomial.q, line 722: undeclared variable symbol `Y'
> > > which comes from my use of your sieve:
> > >    sieve {X|Xs} = {X|sieve {Y:Y in Xs,Y mod X<>0}};
> > > I think I've seen similar warnings for lambdas.
> > > Is that a bug? From a recent posting on the mailing list, I understand
> > > that such variables are not bound as they would be with a 'real' lambda,
> > > but could the warnings on such 'pseudo-bound' variables be suppressed?
> >
> > It's not a bug, but a misfeature, or a wart if you prefer. Currently
> > there is no way for the interpreter to distinguish the "pseudo bindings"
> > performed by lambda and list/stream comprehensions from ordinary uses of
> > free variables. Therefore right now the only way to get rid of those
> > --pedantic warnings is to explicitly declare the symbols as free
> > variables (because that's just what they are, as far as the interpreter
> > is concerned). You can also do that with embedded "var" keywords in the
> > definitions.
>
> I understand.
>
> I would like to use inline "var"s. Unfortunately, that might then hide
> another undeclared symbol elsewhere in my script.
>
> One option is to "postfix" any free variable with the name of the
> function definition containing it.
> For example:
>     sieve {X|Xs} = {X|sieve {Y_sieve: Y_sieve in Xs, Y_sieve mod X<>0}};
>
> The "workaround" I've opted for is to have an explicit
>     var FreeVar;
> early in my *.q file, and to use that in all contexts where the
> variable is intentionally free.
>
> (Similarly, if more that one was needed anywhere, I could use
>     var FreeVar1;
>     var FreeVar2;
>     //and so on...
> )
>
> > But the warnings are only a symptom, not the real cause. Having
> > meditated about this some more, I think that it might be useful if the
> > interpreter was able to deal with variable bindings performed by special
> > forms like lambda and listof/streamof. But this needs some new kind of
> > "variable scoping" declarations for special forms, and I haven't found a
> > general solution for that yet. Of course I could hardwire the desired
> > custom scoping rules for lambda and comprehensions into the interpreter,
> > but that's not a real solution, because the programmer may wish to
> > derive his own special forms from these, or create his own
> > variable-binding special forms from scratch.
> >
> > So what we need are some special directives which tell the interpreter
> > which parameters of a special form bind variables and which other
> > parameters the scope of these variables extends to. Something like this:
> >
> > public special lambda __bind__ X __scope__ Y;
> >
> > Unfortunately, such a simple construct won't do the trick for
> > listof/streamof, since these actually perform their bindings in the "in"
> > clauses, so the lexical scoping rules would be rather complicated in
> > this case. And such a feature might also wreak havoc on the ability to
> > treat lambdas as ordinary expressions which can be constructed and
> > manipulated at runtime.
> >
> > Any ideas, anyone? I don't recall seeing anything like this in any other
> > programming language, but Q is also rather unusual in that it allows the
> > programmer to define his own special forms (apart from the macro
> > facilities of Lisp, but these are compile-time only).
>
> I'm not sufficiently competent in Q to offer any good suggestions yet
> I'm afraid. However, I can see that what is needed is a way to bound
> the scope of a free variable or "var" declaration.
>
> Perhaps something along the lines of
>
>     var Y in
>     sieve {X|Xs} = {X|sieve {Y:Y in Xs,Y mod X<>0}};
>
> would be a possible approach.
>
> > 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
> >
>
> Thanks,
> Rob.
>

Re: [q-lang-users] Polynomial module.

[Rob H. <hub...@gm...>]

Hello Albert,

Thanks for the information...

On 31/10/06, Albert Graef <Dr....@t-...> wrote:
> Hi Rob,
>
> I'm redirecting this to the list so that we can discuss it here. I tend
> to agree that this problem calls for a general solution which also
> adresses the weirdness of lambda reported in Eddie's recent post.
>
> Rob Hubbard wrote:
> > If you run polynomial.q with --pedantic, you may notice the message
> >    Warning polynomial.q, line 722: undeclared variable symbol `Y'
> > which comes from my use of your sieve:
> >    sieve {X|Xs} = {X|sieve {Y:Y in Xs,Y mod X<>0}};
> > I think I've seen similar warnings for lambdas.
> > Is that a bug? From a recent posting on the mailing list, I understand
> > that such variables are not bound as they would be with a 'real' lambda,
> > but could the warnings on such 'pseudo-bound' variables be suppressed?
>
> It's not a bug, but a misfeature, or a wart if you prefer. Currently
> there is no way for the interpreter to distinguish the "pseudo bindings"
> performed by lambda and list/stream comprehensions from ordinary uses of
> free variables. Therefore right now the only way to get rid of those
> --pedantic warnings is to explicitly declare the symbols as free
> variables (because that's just what they are, as far as the interpreter
> is concerned). You can also do that with embedded "var" keywords in the
> definitions.

I understand.

I would like to use inline "var"s. Unfortunately, that might then hide
another undeclared symbol elsewhere in my script.

One option is to "postfix" any free variable with the name of the
function definition containing it.
For example:
    sieve {X|Xs} = {X|sieve {Y_sieve: Y_sieve in Xs, Y_sieve mod X<>0}};

The "workaround" I've opted for is to have an explicit
    var FreeVar;
early in my *.q file, and to use that in all contexts where the
variable is intentionally free.

(Similarly, if more that one was needed anywhere, I could use
    var FreeVar1;
    var FreeVar2;
    //and so on...
)

> But the warnings are only a symptom, not the real cause. Having
> meditated about this some more, I think that it might be useful if the
> interpreter was able to deal with variable bindings performed by special
> forms like lambda and listof/streamof. But this needs some new kind of
> "variable scoping" declarations for special forms, and I haven't found a
> general solution for that yet. Of course I could hardwire the desired
> custom scoping rules for lambda and comprehensions into the interpreter,
> but that's not a real solution, because the programmer may wish to
> derive his own special forms from these, or create his own
> variable-binding special forms from scratch.
>
> So what we need are some special directives which tell the interpreter
> which parameters of a special form bind variables and which other
> parameters the scope of these variables extends to. Something like this:
>
> public special lambda __bind__ X __scope__ Y;
>
> Unfortunately, such a simple construct won't do the trick for
> listof/streamof, since these actually perform their bindings in the "in"
> clauses, so the lexical scoping rules would be rather complicated in
> this case. And such a feature might also wreak havoc on the ability to
> treat lambdas as ordinary expressions which can be constructed and
> manipulated at runtime.
>
> Any ideas, anyone? I don't recall seeing anything like this in any other
> programming language, but Q is also rather unusual in that it allows the
> programmer to define his own special forms (apart from the macro
> facilities of Lisp, but these are compile-time only).

I'm not sufficiently competent in Q to offer any good suggestions yet
I'm afraid. However, I can see that what is needed is a way to bound
the scope of a free variable or "var" declaration.

Perhaps something along the lines of

    var Y in
    sieve {X|Xs} = {X|sieve {Y:Y in Xs,Y mod X<>0}};

would be a possible approach.

> 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
>

Thanks,
Rob.

Re: [q-lang-users] Good news, everyone!

[Albert G. <Dr....@t-...>]

John Cowan wrote:
> Chicken is migrating to CMake, and in fact no longer supports autotools
> for Windows builds (except Cygwin, which can go either way).  CMake is
> also capable of generating Microsoft Visual C++ projects, which is a
> nice feature.  CMake also works fine on Unixoid systems.

I've taken a look at cmake quite a while ago, but the only thing that I
can remember is that at that time cmake wasn't capable enough to handle
all of Q's build requirements.

Can current cmake versions check for certain libc features? Most of Q's
autoconf deals with the incompatibilities in some parts of the system
interface. Another critical requirement is the ability to handle the
horrible complexities of cross-platform shared library handling, how
does cmake deal with this?

> CMake is also considerably faster, because it figures out only what
> the application need to figure out and then only once.  The current Q
> autotools build is horribly slow because there are so many "./configure"
> runs, all of which essentially discover the same thing.

Yes, that's because for modularity the various subpackages which come
bundled with Q have their own autoconf, and AFAICT there's no way to
make a sub-configure use the cache of the main package.

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

Re: [q-lang-users] ANN: Q 7.5 and Pd/Q 0.1

[Albert G. <Dr....@t-...>]

Albert Graef wrote:
> Also new (cue drum roll here): Pd/Q External 0.1, a Pd plugin which
> allows you to execute Q scripts from Pd. Using this interface you can
> write new Pd objects in Q. Great fun. ;-)

As promised, and just in time for ICMC 2006, I've made a couple of new
examples available in the Multimedia Examples section (see the bottom of
the page): http://q-lang.sourceforge.net/examples.html#Multimedia

The new stuff there includes a tiny Pd/Q algorithmic composition example
(seqdemo.tar.gz) and faust2pd (faust2pd-1.0.tar.gz; software to
interface between Faust and Pd, including a Q script to generate Pd
patches from Faust programs). The guitar players among you might be
interested in the little collection of guitar effects I've put together
(written in Faust and accompanied by Pd patches generated with
faust2pd); see guitarfx-0.1.tar.gz.

Cheers,
Albert

> For those who have never heard of it: Pd a.k.a. Pure Data
> (http://puredata.info) is Miller Puckette's popular open source "Max"
> successor, a visual programming environment for patching together
> computer music and other realtime multimedia applications.

-- 
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

Re: [q-lang-users] Good news, everyone!

[Andrew B. <and...@ya...>]

Albert Graef wrote:=0A=0A> I agree that the autotools can be a PITA, but wh=
at other solution is=0A> there to ease cross-platform building? I know abou=
t scons, but IMHO it=0A> still needs time to mature, and it would also be a=
 lots of work to port=0A> all of Q over to a new build system.=0A=0AHey, ju=
st because they are far-and-away the best tools out there does not mean tha=
t I cannot complain about them!  You should hear me whine when I have to ma=
intain someone else's C++ code!  It sounds like the demonstration room at a=
 vacuum cleaner convention.=0A=0A-andrew=0A=0A=0A=0A=0A

Re: [q-lang-users] Good news, everyone!

[John C. <co...@cc...>]

Albert Graef scripsit:

> I agree that the autotools can be a PITA, but what other solution is
> there to ease cross-platform building? I know about scons, but IMHO it
> still needs time to mature, and it would also be a lots of work to port
> all of Q over to a new build system.

Chicken is migrating to CMake, and in fact no longer supports autotools
for Windows builds (except Cygwin, which can go either way).  CMake is
also capable of generating Microsoft Visual C++ projects, which is a
nice feature.  CMake also works fine on Unixoid systems.

CMake is also considerably faster, because it figures out only what
the application need to figure out and then only once.  The current Q
autotools build is horribly slow because there are so many "./configure"
runs, all of which essentially discover the same thing.

-- 
If you understand,                      John Cowan
   things are just as they are;         http://www.ccil.org/~cowan
if you do not understand,               co...@cc...
   things are just as they are.

Re: [q-lang-users] Good news, everyone!

[Albert G. <Dr....@t-...>]

Andrew Berg wrote:
> I just finished getting q 7.5 to build on Mac OS X 10.4.  I have XCode
> 2.3 installed.  This process has once again reinforced my long standing
> distaste for autoconf and automake, but at least I did not have to fight
> with libtool.

Great, thanks a lot for these hints. I'll add your patches to the next Q
release.

I agree that the autotools can be a PITA, but what other solution is
there to ease cross-platform building? I know about scons, but IMHO it
still needs time to mature, and it would also be a lots of work to port
all of Q over to a new build system.

Thanks,
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

Re: [q-lang-users] Polynomial module.

[Albert G. <Dr....@t-...>]

Hi Rob,

I'm redirecting this to the list so that we can discuss it here. I tend
to agree that this problem calls for a general solution which also
adresses the weirdness of lambda reported in Eddie's recent post.

Rob Hubbard wrote:
> If you run polynomial.q with --pedantic, you may notice the message
>    Warning polynomial.q, line 722: undeclared variable symbol `Y'
> which comes from my use of your sieve:
>    sieve {X|Xs} = {X|sieve {Y:Y in Xs,Y mod X<>0}};
> I think I've seen similar warnings for lambdas.
> Is that a bug? From a recent posting on the mailing list, I understand
> that such variables are not bound as they would be with a 'real' lambda,
> but could the warnings on such 'pseudo-bound' variables be suppressed?

It's not a bug, but a misfeature, or a wart if you prefer. Currently
there is no way for the interpreter to distinguish the "pseudo bindings"
performed by lambda and list/stream comprehensions from ordinary uses of
free variables. Therefore right now the only way to get rid of those
--pedantic warnings is to explicitly declare the symbols as free
variables (because that's just what they are, as far as the interpreter
is concerned). You can also do that with embedded "var" keywords in the
definitions.

But the warnings are only a symptom, not the real cause. Having
meditated about this some more, I think that it might be useful if the
interpreter was able to deal with variable bindings performed by special
forms like lambda and listof/streamof. But this needs some new kind of
"variable scoping" declarations for special forms, and I haven't found a
general solution for that yet. Of course I could hardwire the desired
custom scoping rules for lambda and comprehensions into the interpreter,
but that's not a real solution, because the programmer may wish to
derive his own special forms from these, or create his own
variable-binding special forms from scratch.

So what we need are some special directives which tell the interpreter
which parameters of a special form bind variables and which other
parameters the scope of these variables extends to. Something like this:

public special lambda __bind__ X __scope__ Y;

Unfortunately, such a simple construct won't do the trick for
listof/streamof, since these actually perform their bindings in the "in"
clauses, so the lexical scoping rules would be rather complicated in
this case. And such a feature might also wreak havoc on the ability to
treat lambdas as ordinary expressions which can be constructed and
manipulated at runtime.

Any ideas, anyone? I don't recall seeing anything like this in any other
programming language, but Q is also rather unusual in that it allows the
programmer to define his own special forms (apart from the macro
facilities of Lisp, but these are compile-time only).

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

[q-lang-users] fwd: GSNH Up (+4.83% with 2X Average Volume) already on anticipation of Friday's After-Market News Release - ref. Adela Carpenter

[Kendrick M. <Cro...@gm...>]

clothe cowhand

Up On the News - GSNH closes Up Friday, After-Market News Release - Get GSNH Quote Here. sprout.
http://moneycentral.msn.com/detail/stock_quote?Symbol=gsnh

After weeks of speculation it's finally here, and the news is even bigger than we thought. carefree.

We first knew something was up with GSNH when news came out Thursday regarding Drill LOMT #1. But GSNH really popped up on our radar with Friday's After-Market news. GSNH has announced its partners for the LOMT #1 sidetrack well and you are not going to believe who they are. maltreat.

GSNH Names Partners for LOMT #1 Sidetrack Well downstairs.
Friday October 27, 4:05 pm ET complementation.
HOUSTON, Texas--(BUSINESS WIRE) - GSNH announces...has awarded drilling services for the LOMT #1 Sidetrack well to the following providers: lunate
* Patterson-UTI (Nasdaq: PTEN), Revenue: 2.23 billion, UP 63.30% telethon
* Schlumberger (NYSE: SLB), Revenue: 17.90 billion, UP 34.00% gerhardt
* Halliburton (NYSE: HAL), Revenue: 22.90 billion, UP 13.40% clinging

Oct. 27, 2006 (BUSINESS WIRE) - GSNH Names Partners for Sidetrack Well... poach
http://biz.yahoo.com/bw/061027/20061027005324.html?.v=1

GSNH has been releasing steady news worldwide, from Yahoo Finance, AOL, & MSN Money to Marketwatch & Bloomberg---even the NYSE & the NASDAQ have gotten in on the action. Exposure for GSNH is expansive. The increased frequency of news led us to believe that something big was coming for GSNH, and as usual, we were dead-on right. physiology

Oct. 26, 2006 (BUSINESS WIRE) – GSNH to Drill LOMT #1... amerada.
http://money.aol.com/news/articles/_a/greater-sooner-holdings-inc-to-drill/n20061026162609990029

Oct. 12, 2006 (BUSINESS WIRE) – GSNH Reports Drilling Success... impost.
http://www.marketwatch.com/News/Story/Story.aspx?guid={05206016-17D5-4077-B8A3-3D8A763487E2}&siteid=mktw&sid=2133723&symb=

Oct. 11, 2006 (BUSINESS WIRE) – GSNH Announces the Anthony 33... agent.
http://news.moneycentral.msn.com/ticker/article.asp?Feed=BW&Date=20061011&ID=6094112&Symbol=US:GSNH

Oct. 4, 2006 (BUSINESS WIRE) – GSNH...285 million in Probable Reserves... simplex.
http://bloomberg.com/apps/news?pid=conewsstory&refer=conews&tkr=GSNH:US&sid=a6F2jO13PWCU

Friday's After-Market news on GSNH and its newfound partnership with these major corporations (over 43 billion in revenue combined) is just the beginning. We believe that there is even bigger news coming, and as always, we are bringing you the news ahead of time, ahead of everyone else, and ahead of a major spike in GSNH stock price.

moat cushing douglass

[q-lang-users] Good news, everyone!

[Andrew B. <and...@ya...>]

I just finished getting q 7.5 to build on Mac OS X 10.4.  I have  
XCode 2.3 installed.  This process has once again reinforced my long  
standing distaste for autoconf and automake, but at least I did not  
have to fight with libtool.

Anyhow, steps, in case anyone cares:

1) Download each of the following GNU packages, in their current  
versions:
    * m4 (1.4.7)
    * automake (1.9)
    * autoconf (2.60)
    * libiconv (1.11)
    * readline (5.2)
    * gmp (4.2.1)

2) Build and install each of them, I think in this order (but I may  
have autoconf/automake swapped).  Gmp will not build "out of the  
box", so I used the suggestion from here, which was to remove the  
"dive_1" and "modelo" x86 assembly files.  On each of them I added "-- 
prefix=$HOME/local", but that's just my preference.

3) Build and install q.  I had to tweak clib.c a little bit to make  
it compile.  Here is what Subversion has to say on that topic:


tic:~/q-7.5 andrewb$ svn diff modules/clib/clib.c
Index: modules/clib/clib.c
===================================================================
--- modules/clib/clib.c (revision 149)
+++ modules/clib/clib.c (working copy)
@@ -147,6 +147,10 @@
#endif
#ifdef HAVE_SYS_SOCKET_H
+#ifdef __APPLE__
+/* Need to undef _POSIX_C_SOURCE to get AF_LOCAL defined. */
+#undef _POSIX_C_SOURCE
+#endif
#include <sys/socket.h>
#ifdef HAVE_SYS_UN_H
#include <sys/un.h>
@@ -7127,6 +7131,11 @@
#undef SETPGRP_VOID
#endif
+/* This one actually does not get it wrong... */
+#if defined(__APPLE__)
+#define SETPGRP_VOID
+#endif
+
FUNCTION(clib,setpgrp,argc,argv)
{
#ifdef HAVE_SETPGRP


4) Enjoy your new q interpreter.  This is just a basic one, without  
many of the fancy extensions, but (so far) it seems to work ok.   
Fancy extensions are left as an exercise for the reader.

God bless,

-andrew

[q-lang-users] fwd: Do away with card balances or loans - acct Elinor19595184

[Irving L. <Onl...@gm...>]

bronx uppermost
Our attorneys have discovered a loop hole in the banking laws. apricot.

Using this discovery we have been successful at totally eliminating peoples CreditCardDebt with out them paying another dime. candidacy.

We GuaranteeThat we can do this for you. plexiglas.

http://89.0x000000068.112.0x0000015

friedrich privilege plural

[q-lang-users] Real profit

[Lupe B. <dg...@ba...>]

The first thing to do in tuesday is to get in on EQTD. It will RISE
up next days.  There will be ovse 100%
appreciation within the first few hours, so do it fast .

With oil markets retreating, big traders are turning to
gold, driving it to levels never before seen.  EQTD has
made an announcement of staggering proportions related to a
recent survey on one of their gold properties.  The internal
scoop is that we will be looking at a quadrupling of stock price once the public takes notice:

CHICAGO, ILLINOIS-(MARKETWIRE)-Oct 23, 2006 - Equal trading
is pleased to announce advertisement results which have far
exceeded expectations. The results from our British
Columbia property show 58,000 ounce potential.  Plans are
already underway for immediate development.  We look
forward to this remarkable discovery bringing value to
our sharer.

At 600$ an ounce this discovery is worth 34.8 mil$.  With
865mil shares outstanding, this would give us a book value
of 0.04 (current price is under 0.01$).

Don't let it pass you by. The value and the opportunity are there.
Nowadays is the lowest price it can be.
It's high time to buy in! The profitable time to invest!
Good PR will help you to sell it with higher price later. 

[q-lang-users] =?iso-2022-jp?b?GyRCPXUkMSRGJC8kQCQ1JCQbKEI=?=

[<koi...@ez...>]

突然すみません。竹中　眞子と申します。結婚して１２年未だに子供が出来ません。何かにつけてその事に関して姑にいやみを言われます、しかも夫は外に女がいるようで最近はほとんど相手にしてくれません。そこで、どなたか私に精子を提供してくださいませんでしょうか？中だしで構いません。お礼もさせていただきます。一切ご迷惑はお掛けしません。子供さえ出来れば全てうまくいくと思うんです。　No,278392に電話番号を載せましたの、連絡下さい。どうか宜しくお願いします。　http://vlzh.com/?nh05

Re: [q-lang-users] lambda

[Eddie R. <ed...@bm...>]

Albert Graef,

Ahh! I remember reading this before but, now it comes to bare. Thanks!

Eddie

> Eddie Rucker wrote:
>> Why should it matter that I'm using X inside of the lambda function? I
>> know that X is a parameter to the outliers equation, but shouldn't
>> lambda's X be private to (\X. (X < LF) or (X > RF))?
>
> This is explained here:
> http://q-lang.sourceforge.net/qdoc/qdoc_10.html#SEC57, "Lambdas versus
> Equations".
>
> --
> 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
>

Re: [q-lang-users] lambda

[Albert G. <Dr....@t-...>]

Eddie Rucker wrote:
> Why should it matter that I'm using X inside of the lambda function? I
> know that X is a parameter to the outliers equation, but shouldn't
> lambda's X be private to (\X. (X < LF) or (X > RF))?

This is explained here:
http://q-lang.sourceforge.net/qdoc/qdoc_10.html#SEC57, "Lambdas versus
Equations".

-- 
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

[q-lang-users] Weighty message. You should to read.

[Quinton S. <ybf...@ba...>]

The great predictions are made. 
The increase is up to 70% in the last three days.
(MXXR) is the profitable deal and those who knows it is making money.
The drilling achivements of this highly capable oil partnership exceeded all its expectations. 
One time this data hits the road there will be no stopping this one.
Right now it's around 0.025 but we are expecting it to triple. 
Once the info is made and the PR gets into full brandish.
Don't waste time and miss out.  We propose you to buy today.
The key is getting in early and time is limited. It was said that Monday is the day it will shoot. Take your place 
before that happens.

[q-lang-users] lambda

[Eddie R. <ed...@bm...>]

Me again. When I run the following:

// assume X is sorted
medianS X = if (#X) mod 2 = 0 then
	      (X!(#X div 2 - 1) +  X!(#X div 2))/2
	    else
	      X!(#X div 2);

outliers X = filter (\X. (X < LF) or (X > RF)) X
	       where (LF, RF) = (LQ - IRQ, UQ + IRQ)
	       where IRQ = 1.5 * (UQ - LQ)
	       where UQ = medianS (drop (trunc (#X/2 + 0.5)) L)
	       where LQ = medianS (take (trunc (#X/2)) L)
	       where L = sort (<) X;

> outliers $ [1] ++ [20..30]
! Error in conditional

the debugger's last line before the "! Error in conditional"
  0>  stdlib.q, line 134: filter (\[...] . (...) or (...)) [1,20,21,...] 
==>  [1|filter (...) [...]] if (\[...] . (...) or (...)) 1


When I change the (\X. (X < LF) or (X > RF)) to (\Y. (Y < LF) or (Y > RF))
it works

> outliers $ [1] ++ [20..30]
=> [1]

Why should it matter that I'm using X inside of the lambda function? I
know that X is a parameter to the outliers equation, but shouldn't
lambda's X be private to (\X. (X < LF) or (X > RF))?

Eddie

P.S. I really don't mean to be such an aggrivation. I really am enjoying Q!

[q-lang-users] formating

[Eddie R. <ed...@bm...>]

Aaaarrrrrrgggggggh! I got my subject lines crossed for two different topics.
The topic is supposed to be formating source code.

Sorry!

Eddie

[q-lang-users] Float * Big Integers

[Eddie R. <ed...@bm...>]

Im' curious to what is the correct way to format equations in Q. Is the
following proper? On a line wrap, should || come at the end of the
current line or the beginning of the next line? Should I mix styles or
should I always be consistent (I would think always consistent but see
below)?

Eddie

fac 0
  = 1;
fac N:Int
  = assert (N >= 0)
    || N * fac (N-1);

/* or if the line is short should I freely mix styles
fac 0 = 1;
fac N:Int = assert (N >= 0) || N * fac (N-1);
*/

partialFac 0 R:Int
  = 1;
partialFac R:Int R:Int
  = assert (R >= 0) || 1;
partialFac N:Int R:Int
  = assert ((N >= 0) and (R >= 0))
    || N * partialFac (N-1) R;

comb N:Int R:Int
   = 0                                if N < R;
   = (partialFac N R) div (fac (N-R)) if R >= (N-R);
   = (partialFac N (N-R)) div (fac R) otherwise;

binomial X:Int N:Int P:Float
   = assert ((X >= 0) and (0<=P) and (P<=1))
     || (comb N X) * (P^X) * (1-P)^(N-X);

Re: [q-lang-users] License of Q programs

[Peter M. <pet...@wa...>]

Albert Graef wrote:
> Peter Minten wrote:
>> Actually there might be a very easy way out: GPLv3. Q already contains 
>> "or later" text so it's usable under v3 (once that comes out) and v3 
>> seems to be compatible with a lot more licenses than v2.
> 
> That would be the easiest option, of course. I've also considered the
> LGPL but I'm not sure whether the rationale behind that license really
> applies to Q. Also, the GNU regex code which is bundled with the Q core
> distribution and linked into the clib module is GPL, not LGPL. I guess
> that this might be an issue if Q would be licensed under the LGPL?

Yes. It would trump the LGPL making Q GPLed.

Greetings,

Peter

Re: [q-lang-users] License of Q programs

[Albert G. <Dr....@t-...>]

Peter Minten wrote:
> Actually there might be a very easy way out: GPLv3. Q already contains 
> "or later" text so it's usable under v3 (once that comes out) and v3 
> seems to be compatible with a lot more licenses than v2.

That would be the easiest option, of course. I've also considered the
LGPL but I'm not sure whether the rationale behind that license really
applies to Q. Also, the GNU regex code which is bundled with the Q core
distribution and linked into the clib module is GPL, not LGPL. I guess
that this might be an issue if Q would be licensed under the LGPL?

Well, as there isn't a current demand for a license change I guess I'll
just postpone that decision again. :) But it will eventually be
necessary to resolve that question...

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

Re: [q-lang-users] License of Q programs

[Peter M. <pet...@wa...>]

John Cowan wrote:
> Albert Graef scripsit:
> 
>> Not really. I think that it shouldn't be too difficult to freely use Q
>> in other open source projects (i.e., projects under some OSI-approved
>> license, is that the case with Erlang?). But IANAL so any advice is
>> appreciated. 
> 
> There really aren't any open-source licenses of the type you are
> discussing (i.e. that allow the code to be used in open-source but not
> proprietary projects).

Actually there might be a very easy way out: GPLv3. Q already contains 
"or later" text so it's usable under v3 (once that comes out) and v3 
seems to be compatible with a lot more licenses than v2.

Whether it's compatable with the Erlang Public License isn't clear yet, 
but probably not an important point as I've given up on the Erlang node 
project. It turned out the Erlang API lacks documentation in various 
important points (like what the fields of a basic struct are and how 
they behave under what circumstances) so porting is a bit too 
complicated for me. Plus the current Erlang C lib didn't provide the 
high level support that I kinda expected (unlike the Java lib which is 
plug-in-and-use).

Greetings,

Peter

Re: [q-lang-users] License of Q programs

[John C. <co...@cc...>]

Albert Graef scripsit:

> Not really. I think that it shouldn't be too difficult to freely use Q
> in other open source projects (i.e., projects under some OSI-approved
> license, is that the case with Erlang?). But IANAL so any advice is
> appreciated. 

There really aren't any open-source licenses of the type you are
discussing (i.e. that allow the code to be used in open-source but not
proprietary projects).

If you want to make Q embeddable in non-GPL programs, I recommend that
you switch the license from GPL to LGPL.  It may still wind up being used
in some proprietary programs, but not many -- the LGPL conditions are
onerous enough to make that unlikely.  Specifically, they would have
to ship the Q parts as a separate .so or .dll in order to make them
field-upgradeable to a new compatible version of Q.

> What I do know is that it's hard to augment the GPL with
> special clauses without rendering the whole license invalid. 

Actually it isn't.  The FSF does it routinely.  They use three licenses
for library code:

1) The GPL alone,

2) The LGPL,

3) The GPL plus an exception saying you can use this code in any derived
   work, proprietary or not.

Cases #2 and #3 are used when the FSF decides it is in its best interest
to get the software widely used rather than trying to keep it as a
special facility available only to GPL-licensed programs.  Thus glibc
is LGPL, because there are plenty of other C libraries and there is no
special advantage from it; and Guile (the FSF's pseudo-Scheme scripting
language) is GPL+exception, because the FSF wants to actively encourage
its incorporation into proprietary programs.

-- 
Unless it was by accident that I had            John Cowan
offended someone, I never apologized.           co...@cc...
        --Quentin Crisp                         http://www.ccil.org/~cowan

Re: [q-lang-users] where

[Eddie R. <ed...@bm...>]

Albert Graef,

> All of these are imperative languages, or at least the relevant
> features
> (mutable variables) are imperative. Q's local variables are immutable,
> so the imperative mindset isn't applicable. Regarding dynamic binding,
> that's generally frowned upon nowadays, all modern FPs use lexical
> binding. Well, I have to admit that Q's *global* variable environment
> uses dynamic binding, but that's just a convenience for interactive
> usage and shouldn't be abused. ;)

Thanks for the explanation. I agree about dynamic binding and global
variables. I was thinking that the "let" expression would have to follow
block structure (for variable scope) which does not fit into Q's basic
design. However, as you point out, Q's local variables are immutable so
this isn't really relevant.

Eddie

Re: [q-lang-users] where

[Albert G. <Dr....@t-...>]

Eddie Rucker wrote:
> I really didn't mean to open a can of worms ;)

Too late now. :)

> This is somewhat related to the topic at hand. I've seen Fortran's
> "common," Algol's (scheme, pascal, ada, etc...) block structure, lisp's
> dynamic scoping, and global variables.

All of these are imperative languages, or at least the relevant features
(mutable variables) are imperative. Q's local variables are immutable,
so the imperative mindset isn't applicable. Regarding dynamic binding,
that's generally frowned upon nowadays, all modern FPs use lexical
binding. Well, I have to admit that Q's *global* variable environment
uses dynamic binding, but that's just a convenience for interactive
usage and shouldn't be abused. ;)

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