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

Re: [q-lang-users] Re: Newbie questions and comments

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

John Cowan wrote:
> Thanks.  I am only the maintainer faute de mieux:  I haven't done a thing
> with it for years, and indeed I never did learn how the basic rendering
> engine works; I am only responsible for the Unicode wrapper.

Interested in retrofitting unicode support to some strange obscure 
functional programming language? ;-)

I have this unicode stuff on my TODO list for a _very_ long time, but 
somehow I can't wrap my head around it.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag

Re: [q-lang-users] Re: Newbie questions and comments

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

Tim Haynes wrote:
>> | zsh/scr, straw  9:16PM q-src/ % epm -qaG| grep gmp
>> | dev-libs/gmp-4.1.4
>>
>>And/or experimental error, maybe?
> 
> Oh, also I've being giving you results from a box:
> 
>  | vendor_id       : AuthenticAMD
>  | cpu family      : 6
>  | model           : 10
>  | model name      : AMD Athlon(tm) XP 2500+
>  | stepping        : 0
>  | cpu MHz         : 1830.002
>  | cache size      : 512 KB

Now this is rather strange. My gmp is older (4.1.3) and my hardware 
virtually the same:

vendor_id       : AuthenticAMD
cpu family      : 6
model           : 10
model name      : AMD Athlon(tm) XP 2500+
stepping        : 0
cpu MHz         : 1838.532
cache size      : 512 KB

Are you sure you compiled gmp with all optimizations? Or did you use a 
ready-made package? What distro?

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag

Re: [q-lang-users] Re: Newbie questions and comments

[John C. <jc...@re...>]

Albert Graef scripsit:

> Well, I really need the bignums for doing some number-theoretic stuff. 
> Of course, you could reimplement them yourself using lists but this is 
> inconvenient and slow.

Yes, that would be a pain.

> I also thought about adding arbitrary precision floats, but if I take a 
> look at the bigint vs. float performance, that's probably not a good 
> idea. ;-)

Agreed.

> Hey, I just noticed that you are the current maintainer of figlet! Good 
> program. I've been playing around with it, to make a nicer sign-on 
> message for the Q interpreter. Maybe in the next version. :)

Thanks.  I am only the maintainer faute de mieux:  I haven't done a thing
with it for years, and indeed I never did learn how the basic rendering
engine works; I am only responsible for the Unicode wrapper.

-- 
"Well, I'm back."  --Sam        John Cowan <jc...@re...>

Re: [q-lang-users] Re: Newbie questions and comments

[Tim H. <q...@st...>]

Tim Haynes <q...@st...> writes:

[snip]
> > Yes, that's pretty much in line with my results, thanks. Well, your
> > int/float performance ratio is 10% worse than mine, I wonder why's that,
> > maybe an older gmp version?
> 
>  | zsh/scr, straw  9:16PM q-src/ % epm -qaG| grep gmp
>  | dev-libs/gmp-4.1.4
> 
> And/or experimental error, maybe?

Oh, also I've being giving you results from a box:

 | vendor_id       : AuthenticAMD
 | cpu family      : 6
 | model           : 10
 | model name      : AMD Athlon(tm) XP 2500+
 | stepping        : 0
 | cpu MHz         : 1830.002
 | cache size      : 512 KB

if that makes any difference. :)

~Tim
-- 
<http://spodzone.org.uk/>

Re: [q-lang-users] Re: Newbie questions and comments

[Tim H. <q...@st...>]

Albert Graef <Dr....@t-...> writes:

> Tim Haynes wrote:
> >  | ==> takfp::takintstart 10; stats
> >  | 11
> >  | 563 secs, 278308696 reductions, 78 cells
> > Int slow, float quite nice.
> 
> Yes, that's pretty much in line with my results, thanks. Well, your
> int/float performance ratio is 10% worse than mine, I wonder why's that,
> maybe an older gmp version?

 | zsh/scr, straw  9:16PM q-src/ % epm -qaG| grep gmp
 | dev-libs/gmp-4.1.4

And/or experimental error, maybe?

~Tim
-- 
<http://spodzone.org.uk/>

Re: [q-lang-users] Re: Newbie questions and comments

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

John Cowan wrote:
> If I were implementing a language from scratch today for anything but
> bare-metal programming, I'd probably leave off machine-size integers
> altogether, as you have done, and just have doubles and bignums, or even
> just doubles (like Perl and Lua).

Well, I really need the bignums for doing some number-theoretic stuff. 
Of course, you could reimplement them yourself using lists but this is 
inconvenient and slow.

I also thought about adding arbitrary precision floats, but if I take a 
look at the bigint vs. float performance, that's probably not a good 
idea. ;-)

Hey, I just noticed that you are the current maintainer of figlet! Good 
program. I've been playing around with it, to make a nicer sign-on 
message for the Q interpreter. Maybe in the next version. :)

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag

Re: [q-lang-users] Re: Newbie questions and comments

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

Tim Haynes wrote:
>  | ==> takfp::takintstart 10; stats
>  | 11
>  | 563 secs, 278308696 reductions, 78 cells
> 
> Int slow, float quite nice.

Yes, that's pretty much in line with my results, thanks. Well, your 
int/float performance ratio is 10% worse than mine, I wonder why's that, 
maybe an older gmp version?

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag

Re: [q-lang-users] Re: Newbie questions and comments

[John C. <jc...@re...>]

Albert Graef scripsit:

> Also with double precision floats? Then GMP's bigint implementation must 
> be quite good. (Q uses those for integer arithmetic. So the two test 
> runs I gave were actually GMP vs. machine double precision floats.)

Internally it's typical to do everything with extended-precision floats
(on Intel machines these are 80-bit objects) and then trim to single or
double precision only when storing.

If I were implementing a language from scratch today for anything but
bare-metal programming, I'd probably leave off machine-size integers
altogether, as you have done, and just have doubles and bignums, or even
just doubles (like Perl and Lua).

-- 
John Cowan  jc...@re...  www.reutershealth.com  www.ccil.org/~cowan
Heckler: "Go on, Al, tell 'em all you know.  It won't take long."
Al Smith: "I'll tell 'em all we *both* know.  It won't take any longer."

Re: [q-lang-users] Re: Newbie questions and comments

[Tim H. <q...@st...>]

Albert Graef <Dr....@t-...> writes:

> Tim Haynes wrote:
> > Yeah. I spot the `-1.0' everywhere. OK, will try again....
> 
> And don't forget the *3.0 etc. ;-)

 | ==> takfp::takintstart 10; stats
 | 11
 | 563 secs, 278308696 reductions, 78 cells

Int slow, float quite nice.

HTH :)

~Tim
-- 
<http://spodzone.org.uk/>

Re: [q-lang-users] Re: Newbie questions and comments

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

Tim Haynes wrote:
> Yeah. I spot the `-1.0' everywhere. OK, will try again....

And don't forget the *3.0 etc. ;-)

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag

Re: [q-lang-users] Re: Newbie questions and comments

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

Albert Graef wrote:
> Hmm, that looks like your tak program forces floating point arithmetic 
> in any case; otherwise the first result should have been 10, not 10.0. 
> Can you post your program here?

Of course I meant 11 vs. 11.0. ;-)

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag

Re: [q-lang-users] Re: Newbie questions and comments

[Tim H. <q...@st...>]

Albert Graef <Dr....@t-...> writes:

[snip]
> Hmm, that looks like your tak program forces floating point arithmetic in
> any case; otherwise the first result should have been 10, not 10.0. Can you
> post your program here?

Oh, ahh... D'oh!


#!/usr/bin/env q
#! -cmain ARGS || quit

takfp (X, Y, Z) = Z if Y>=X;
            = takfp (
               takfp (X-1.0, Y, Z),
               takfp (Y-1.0, Z, X),
               takfp (Z-1.0, X, Y)) 
                 otherwise;

takstart N = takfp (N*3.0, N*2.0, N*1.0);

main ARGS = writes (str (takstart (val (ARGS!1)))) || writes "\n" || quit;


Yeah. I spot the `-1.0' everywhere. OK, will try again....

~Tim
-- 
<http://spodzone.org.uk/>

Re: [q-lang-users] Re: Newbie questions and comments

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

Tim Haynes wrote:
> On the same box as I did the hugs-v-q comparison:
> 
>  | ==> takfp::takstart 10 ; stats
>  | 11.0
>  | 453 secs, 278308696 reductions, 78 cells
>  | 
>  | ==> takfp::takstart 10.0 ; stats
>  | 11.0
>  | 452 secs, 278308696 reductions, 78 cells

Hmm, that looks like your tak program forces floating point arithmetic 
in any case; otherwise the first result should have been 10, not 10.0. 
Can you post your program here?

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag

Re: [q-lang-users] Re: Newbie questions and comments

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

John Cowan wrote:
>>Did you use integer or floating point arithmetic? 
> 
> On modern hardware the performance is often just about the same.
> In certain cases, floating-point is actually faster.

Also with double precision floats? Then GMP's bigint implementation must 
be quite good. (Q uses those for integer arithmetic. So the two test 
runs I gave were actually GMP vs. machine double precision floats.)

Anyway, thanks for the hint.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag

Re: [q-lang-users] Re: Newbie questions and comments

[Tim H. <q...@st...>]

John Cowan <co...@cc...> writes:

> Albert Graef scripsit:
> 
> > Did you use integer or floating point arithmetic? 
> 
> On modern hardware the performance is often just about the same.
> In certain cases, floating-point is actually faster.

On the same box as I did the hugs-v-q comparison:

 | ==> takfp::takstart 10 ; stats
 | 11.0
 | 453 secs, 278308696 reductions, 78 cells
 | 
 | ==> takfp::takstart 10.0 ; stats
 | 11.0
 | 452 secs, 278308696 reductions, 78 cells


<http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=delta&action=Search>,
sense 3 ;)

~Tim
-- 
<http://spodzone.org.uk/>

Re: [q-lang-users] Re: Newbie questions and comments

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

Albert Graef scripsit:

> Did you use integer or floating point arithmetic? 

On modern hardware the performance is often just about the same.
In certain cases, floating-point is actually faster.

-- 
Mark Twain on Cecil Rhodes:                     John Cowan
I admire him, I freely admit it,               http://www.ccil.org/~cowan
and when his time comes I shall                http://www.reutershealth.com
buy a piece of the rope for a keepsake.        co...@cc...

Re: [q-lang-users] Q similar to Maude?

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

Greg Buchholz wrote:
>     Can anyone point me in the direction of documentation or papers
> which compare Q and the equational/term-rewriting language Maude
> (http://maude.cs.uiuc.edu/overview.html)?  Or am I mistaken to think
> there is a similarity between the two?

Q is very different from Maude. Maude clearly shows its heritage from 
the algebraic specification world and the OBJ system in particular. In 
contrast, Q uses dynamic typing, which is less safe but more convenient 
for "getting things done quickly". So while the focus of Maude is on 
executable specifications, Q is more of a "hacker's tool" for practical 
programming, akin to other modern scripting languages.

There are probably many more differences, but this is what I can say 
after taking a quick look at the Maude primer.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag

Re: [q-lang-users] Re: Newbie questions and comments

[Tim H. <q...@st...>]

Albert Graef <Dr....@t-...> writes:

> Yes, Q is a bit slow w.r.t. plain recursion. Well, if I take the
> datapoints at http://shootout.alioth.debian.org/ as a reference that
> would mean that Q is within a factor of <2 compared to Python. That's
> consistent with my observations for this type of programs.
> 
> Has anyone tried the Haskell version of the benchmark with Hugs yet? Some
> time ago I did a tak benchmark with both Q and Hugs, and IIRC they were
> pretty much at par.

 | zsh/scr, straw 10:18AM haskell/ % time runhugs takfp.lhs 10
 | 11.0
 | runhugs takfp.lhs 10  407.06s user 0.82s system 99% cpu 6:51.01 total
 | 
 | zsh/scr, straw 10:25AM haskell/ % ~/q-src                  
 | zsh/scr, straw 10:28AM q-src/ % time ./takfp.q 5
 | 10.0
 | ./takfp.q 5  0.09s user 0.00s system 21% cpu 0.412 total
 | 
 | zsh/scr, straw 10:28AM q-src/ % time ./takfp.q 10
 | 11.0
 | ./takfp.q 10  450.37s user 0.64s system 99% cpu 7:33.92 total
 | zsh/scr, straw 10:36AM q-src/ % 

HTH :)

~Tim
-- 
<http://spodzone.org.uk/>

Re: [q-lang-users] Re: Newbie questions and comments

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

Tim Haynes wrote:
> Random datapoint: on my machine it took Q 28mins to do the takfp test
> listed there.

Did you use integer or floating point arithmetic? Here are two runs from 
my machine:

==> tak 30 20 10; stats
11
485 secs, 278308692 reductions, 133 cells

==> tak 30.0 20.0 10.0; stats
11.0
431 secs, 278308692 reductions, 133 cells

I'd guess that with machine integers the performance would be closer to 
that of Python. Not that this is a real option, since Q's integers are 
always bigints.

> (However, at least it did it in constant memory; my obvious implementation
> in Perl took 7mins but blew to 1.4Gb VSZ...)

Languages without tail call elimination suck. ;-) Q uses only 133 
expression cells (~3KB), so the memory requirements would be just what 
the interpreter needs for global data anyway...

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag

Re: [q-lang-users] Re: Newbie questions and comments

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

Tim Haynes wrote:
> Random datapoint: on my machine it took Q 28mins to do the takfp test
> listed there.
> 
> (However, at least it did it in constant memory; my obvious implementation
> in Perl took 7mins but blew to 1.4Gb VSZ...)

Yes, Q is a bit slow w.r.t. plain recursion. Well, if I take the 
datapoints at http://shootout.alioth.debian.org/ as a reference that 
would mean that Q is within a factor of <2 compared to Python. That's 
consistent with my observations for this type of programs.

Has anyone tried the Haskell version of the benchmark with Hugs yet? 
Some time ago I did a tak benchmark with both Q and Hugs, and IIRC they 
were pretty much at par.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag

[q-lang-users] ANN: Q at LAC 2005

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

Hi all,

FYI: Next week Q will be presented at the 3rd International Linux Audio 
Conference (LAC 2005, see http://lac.zkm.de/). My talk 
(http://lac.zkm.de/abstracts.shtml#albert_graef) will be mostly
about Q's multimedia interface (which now also comprises yet unreleased 
OpenGL and Xine modules; please check out CVS at 
http://sourceforge.net/cvs/?group_id=96881 for those!). If
you're interested in Q and/or Linux audio and music applications and 
have the opportunity to come to Karlsruhe I hope to meet you there! (The 
conference is free. A registration form is provided at the conference 
website.)

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag

Re: [q-lang-users] Re: Newbie questions and comments

[Tim H. <q...@st...>]

Greg Buchholz <Gre...@sl...> writes:

>    For more exposure, you could always try to get Q included in "The
> Great Computer Language Shootout"...
> 
>     http://shootout.alioth.debian.org/

Random datapoint: on my machine it took Q 28mins to do the takfp test
listed there.

(However, at least it did it in constant memory; my obvious implementation
in Perl took 7mins but blew to 1.4Gb VSZ...)

~Tim
-- 
<http://spodzone.org.uk/>

[q-lang-users] Q similar to Maude?

[Greg B. <gr...@sl...>]

    Can anyone point me in the direction of documentation or papers
which compare Q and the equational/term-rewriting language Maude
(http://maude.cs.uiuc.edu/overview.html)?  Or am I mistaken to think
there is a similarity between the two?


Thanks,

Greg Buchholz

[q-lang-users] Re: Newbie questions and comments

[Greg B. <Gre...@sl...>]

Albert Graef wrote:
 
>Matt Gushee wrote:
>>  * So why isn"t Q better known?
> 
> Good question. Well, maybe I don"t advertise it enough. This year will
> be the first time that I actually present Q at an international
> conference. You see, for a long time Q has just been one of my "hobby
> projects", and it has only been "out there" on SourceForge for about
> one year. But I guess that the most prominent factor is that
> functional languages are still perceived as something fairly exotic,
> and many programmers can"t easily wrap their head around this way of
> programming.  It just takes time I guess.

   For more exposure, you could always try to get Q included in "The
Great Computer Language Shootout"...

    http://shootout.alioth.debian.org/


Greg Buchholz

Re: [q-lang-users] Newbie questions and comments

[Tim H. <q...@st...>]

Albert Graef <Dr....@t-...> writes:

[snippus maximus]
> When you want to make good use of the debugger, I'd also recommend
> getting familiar with the way that the interpreter evaluates an
> expression by performing reductions on its rule stack:
> http://q-lang.sourceforge.net/qdoc/qdoc_7.html#SEC32
> 
> 
> Well, maybe the description in the manual is too terse? Do we need a
> debugger tutorial??

The descriptions are good - but the example right at the end of
<http://q-lang.sourceforge.net/qdoc/qdoc_16.html#SEC152> I would say is
probably a bit terse, yes. I think you've written an admirable replacement
up above, so with a bit of markup (perhaps distinguishing input from Q
output by means of colour) your mail could go right in there happily.

~Tim
-- 
<http://spodzone.org.uk/>