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

Re: [q-lang-users] q in Q

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

John Cowan wrote:
> Well, there's a few approaches to that.  I presume a classical compiler
> to assembly language chain is out.  Then there's compilation to C,
> or compilation to something else (Chicken, e.g.) that compiles to C.
> Then there is compilation to some standard byte code set with JIT
> compilation in place, like the JVM or the CLR.  Any or all of these
> would probably make q-in-Q feasible.

Yes, we already discussed this here a while ago... Translating Q's 
bytecode would be the most straightforward approach. JIT compilation 
looks nice, but I'm also considering compilation to C or maybe Ksi (the 
latter approach would be tied to gcc, however). This is still a while 
away, though (I first want to resolve all the remaining portability 
issues and finish the Q companion book).

> Reference counting has its own costs, though, specifically the cost of
> recursive freeing, which is unpredictable in scope.

Yes, that's true. But in my experience it seems to work well enough for 
soft-realtime apps even on slower PCs (especially the computer music 
applications wouldn't work at all if this wasn't the case; there you can 
hear timing glitches quite easily). Doing low-latency audio stuff is 
more demanding, of course, but there are other, more specialized audio 
engines like SuperCollider for that, which can be controlled from Q via OSC.

> Q has a global interpreter lock, right?  So all threads except one have
> to be running C code, but which one it is can change.

Yes, that's right. That global mutex will probably have to go before we 
all run computers with 1024 cpus. ;-) But right now this implementation 
seems to work pretty well and also makes the job for the external module 
writer much simpler.

> The whole idea probably isn't practical.

:(

-- 
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] Complex numbers

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

bri...@co... wrote:
> These languages typically offer a block-structuring thing, called 
> "using" in VB [and I can't remember what it's called in C#], and any 
> types that implement interface IDisposable get, well, disposed of when 
> control leaves the block.

Unfortunately, a stack-based discipline isn't enough for Q here, since a 
stateful object may be referenced from other expressions and also from 
different threads at the same time.

-- 
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] q in Q

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

Albert Graef scripsit:

> Yes, that should be possible, but I'm probably not the one who is going 
> to do it. ;-) I'd rather like to bootstrap Q in Q once we have native 
> compilation.

Well, there's a few approaches to that.  I presume a classical compiler
to assembly language chain is out.  Then there's compilation to C,
or compilation to something else (Chicken, e.g.) that compiles to C.
Then there is compilation to some standard byte code set with JIT
compilation in place, like the JVM or the CLR.  Any or all of these
would probably make q-in-Q feasible.

> I'm not sure about that. At least it would still need to do reference 
> counting, since I want objects encapsulating state to be cleaned up 
> (closing files, etc.) as soon as possible. This makes handling temporary 
> stateful objects much more convenient.

Reference counting has its own costs, though, specifically the cost of
recursive freeing, which is unpredictable in scope.

Chicken has two garbage collectors, both stop-and-copy.  The first one
is intertwined with how Chicken uses the stack.  All Scheme objects
are initially allocated on the C stack, and each Scheme procedure is
compiled into a C procedure which explicitly calls its continuation.
However, the continuation never returns.  Instead, when the stack gets
full, all live Scheme objects are copied to the heap and a longjmp()
is done to reset the stack.  A regular Baker two-space collector is
periodically run on the two halves of the heap.  Any object can have a
finalizer, which is run when the object becomes garbage.

> > Chicken doesn't do native threads, though, only call/cc based ones.
> 
> I guess that this would be a showstopper for me, with all the realtime 
> multimedia applications I'm doing.

Q has a global interpreter lock, right?  So all threads except one have
to be running C code, but which one it is can change.  I'm not sure
whether Chicken can safely spawn OS threads, but if so, they can't be
running Chicken code, at least not easily, given the mechanism
explained above.

The whole idea probably isn't practical.

-- 
John Cowan                                <co...@cc...>
Yakka foob mog.  Grug pubbawup zink wattoom gazork.  Chumble spuzz.
    -- Calvin, giving Newton's First Law "in his own words"

Re: [q-lang-users] Complex numbers

[<bri...@co...>]

Just a note to point out that most of the CLR-based languages (examples: VB.NET, C#) have, in addition to standard garbage collection based on reachable roots of language objects, another, separate protocol for disposing of non-GC'd system resources like database locks, video-card contexts, midi channels. So there's an example of handling normal GC separately from this concern.

These languages typically offer a block-structuring thing, called "using" in VB [and I can't remember what it's called in C#], and any types that implement interface IDisposable get, well, disposed of when control leaves the block.

CLR has yet-another protocol called finalizers, but I don't use them, they interact strangely with the rest of the VM [they're executed at unpredictable times on different threads], and I don't remember much more about them (they're viewed with jaundiced eyes by most sophisticated CLR users). 



--
BBeckman http://weblogs.asp.net/brianbec http://data/tesla 
------------------------------------------------------------------------------------ 
| Type inference | Object initializers | Anonymous types | XML CRUD | 
| Extension members | LINQ | Relationships | Nested functions | 
| Nullable of T | Relaxed delegates | Dynamic identifiers | Duck typing | 
| Pattern matching | Contracts | AJAX | Iterators | 
| Continuations | REPL | Join Patterns | Transactions | 
| XML Streams | Code Literals | Morphisms | Embedded DSLs | 
------------------------------------------------------------------------------------

-------------- Original message -------------- 
From: Albert Graef <Dr....@t-...> 

> John Cowan wrote: 
> > I suppose we could bit-by-bit replace the entire Q-in-C system with 
> > a Q-in-Scheme system, compiler, interpreter, user program and all. 
> 
> Yes, that should be possible, but I'm probably not the one who is going 
> to do it. ;-) I'd rather like to bootstrap Q in Q once we have native 
> compilation. 
> 
> > It wouldn't need its own garbage collector any more 
> 
> I'm not sure about that. At least it would still need to do reference 
> counting, since I want objects encapsulating state to be cleaned up 
> (closing files, etc.) as soon as possible. This makes handling temporary 
> stateful objects much more convenient. 
> 
> > Chicken doesn't do native threads, though, only call/cc based ones. 
> 
> I guess that this would be a showstopper for me, with all the realtime 
> multimedia applications I'm doing. 
> 
> -- 
> 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 mailing list 
> q-l...@li... 
> https://lists.sourceforge.net/lists/listinfo/q-lang-users 

Re: [q-lang-users] Complex numbers

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

John Cowan wrote:
> I suppose we could bit-by-bit replace the entire Q-in-C system with
> a Q-in-Scheme system, compiler, interpreter, user program and all.

Yes, that should be possible, but I'm probably not the one who is going 
to do it. ;-) I'd rather like to bootstrap Q in Q once we have native 
compilation.

> It wouldn't need its own garbage collector any more

I'm not sure about that. At least it would still need to do reference 
counting, since I want objects encapsulating state to be cleaned up 
(closing files, etc.) as soon as possible. This makes handling temporary 
stateful objects much more convenient.

> Chicken doesn't do native threads, though, only call/cc based ones.

I guess that this would be a showstopper for me, with all the realtime 
multimedia applications I'm doing.

-- 
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] Complex numbers

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

Albert Graef scripsit:

> Yes, I understand. That's a good idea, it might even lure some Schemers 
> into trying Q itself. ;-)

Well, they'll have to if they want to write rules, since there is no
S-expression version of rules.

I suppose we could bit-by-bit replace the entire Q-in-C system with
a Q-in-Scheme system, compiler, interpreter, user program and all.
It wouldn't need its own garbage collector any more, and would
probably be much easier to maintain -- provided the maintainer
knows Scheme.  I'd think the performance would be about as good.

Chicken doesn't do native threads, though, only call/cc based ones.

-- 
Time alone is real                      John Cowan <co...@cc...>
  the rest imaginary
like a quaternion       --phma          http://www.ccil.org/~cowan

Re: [q-lang-users] Query about Type Tests (Complex and Rational).

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

Albert Graef scripsit:

> You can only use a type guard on the lhs of equations and variable 
> definitions, whereas the predicates can be used everywhere on the rhs 
> and on temporary computed values, too. So, yes, they are both useful.

Oops, yes, of course.

> Like isintnum, iscomplexnum, etc. Maybe we should also add isexact?

Sounds good.  And isinexact (which would be true of floats and of
complex numbers with at least one float component).

-- 
In politics, obedience and support      John Cowan <co...@cc...>
are the same thing.  --Hannah Arendt    http://www.ccil.org/~cowan

Re: [q-lang-users] Query about Type Tests (Complex and Rational).

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

John Cowan wrote:
> Albert Graef scripsit:
>   
>> I don't think that this is a good idea. The other type checking 
>> predicates isxyz for a type Xyz all follow the scheme that the predicate 
>> is equivalent to the type guard, so iscomplex should follow that 
>> principle, too (that wasn't the case previously, but previously there 
>> was no Complex type and iscomplex was a semantic predicate).
>>     
I'd be happy with that. I was trying to get a handle on what the 
convention was.
> I'm not sure I see the utility of this.  Granted that non-numeric
> types work this way, why should the numeric ones?  I'd favor a scheme
> in which you use the guards for syntactic types and the isX predicates
> for semantic types.  What can you do with iscomplex that you can't do
> with a type guard?
>
>   
This?

func X = func1 Temp
    if iscomplex Temp
    where Temp = func2 X;
> Or if you think this is essential, how about going to a scheme in which
> isX means "is it the representation type" and "is_X_number" means "does
> it actually fit the model for that kind of number"?  So iscomplex would
> be true only of objects of type Complex, but is_complex_number would be
> true of any number (except hypothetical quaternions and octonions to be
> added later).
>   
If you decide to go down this route, then what about "isComplexType" 
versus "isComplexValue"? (But shorter.)
Or e.g. "isComplex" versus "inComplex". (Perhaps these are too similar.)

Re: [q-lang-users] Query about Type Tests (Complex and Rational).

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

John Cowan wrote:
> I'm not sure I see the utility of this.  Granted that non-numeric
> types work this way, why should the numeric ones?  I'd favor a scheme
> in which you use the guards for syntactic types and the isX predicates
> for semantic types.  What can you do with iscomplex that you can't do
> with a type guard?

You can only use a type guard on the lhs of equations and variable 
definitions, whereas the predicates can be used everywhere on the rhs 
and on temporary computed values, too. So, yes, they are both useful.

> Or if you think this is essential, how about going to a scheme in which
> isX means "is it the representation type" and "is_X_number" means "does
> it actually fit the model for that kind of number"?  So iscomplex would
> be true only of objects of type Complex, but is_complex_number would be
> true of any number (except hypothetical quaternions and octonions to be
> added later).

That's a good idea! I can work out something along this line, but 
suggestions and code are welcome.

> In particular, is_integral_number would be true of Floats with integer
> values.  A less verbose naming scheme would be good, though.

Like isintnum, iscomplexnum, etc. Maybe we should also add isexact?

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] Query about Type Tests (Complex and Rational).

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

Albert Graef scripsit:

> I don't think that this is a good idea. The other type checking 
> predicates isxyz for a type Xyz all follow the scheme that the predicate 
> is equivalent to the type guard, so iscomplex should follow that 
> principle, too (that wasn't the case previously, but previously there 
> was no Complex type and iscomplex was a semantic predicate).

I'm not sure I see the utility of this.  Granted that non-numeric
types work this way, why should the numeric ones?  I'd favor a scheme
in which you use the guards for syntactic types and the isX predicates
for semantic types.  What can you do with iscomplex that you can't do
with a type guard?

Or if you think this is essential, how about going to a scheme in which
isX means "is it the representation type" and "is_X_number" means "does
it actually fit the model for that kind of number"?  So iscomplex would
be true only of objects of type Complex, but is_complex_number would be
true of any number (except hypothetical quaternions and octonions to be
added later).

In particular, is_integral_number would be true of Floats with integer
values.  A less verbose naming scheme would be good, though.

-- 
John Cowan    http://ccil.org/~cowan    co...@cc...
[T]here is a Darwinian explanation for the refusal to accept Darwin.
Given the very pessimistic conclusions about moral purpose to which his
theory drives us, and given the importance of a sense of moral purpose
in helping us cope with life, a refusal to believe Darwin's theory may
have important survival value. --Ian Johnston

Re: [q-lang-users] Complex numbers

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

John Cowan wrote:
> So we could, although I think the current C-based version does well
> enough.

Yes it does, but it's a PITA having to maintain all that C code. ;-) 
Because of this, I consider turning the Q machine (i.e., the interpreter 
minus the user interface) into a Q module and then reimplement the user 
interface in Q itself.

> My main ambition is not to compete with the Q interpreter,
> but to make the power of generalized term rewriting readily available
> to Scheme programmers.  For that they need an appropriately Schemish
> and S-expression-based interface.

Yes, I understand. That's a good idea, it might even lure some Schemers 
into trying Q itself. ;-)

> Thanks, fixed.  On most systems you should only need to say -lqint anyhow.

Right.

> I spotted another typo in the Q manual in at least two places: "quadrupel"
> should be "quadruple".

Another one of those annoying "German English" things. ;-) Thanks, it's 
fixed now.

-- 
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] Query about Type Tests (Complex and Rational).

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

Rob Hubbard wrote:
> Perhaps these should be
> 
>     iscomplex _:Complex  = true;
>     iscomplex R          = isreal R otherwise; //behavioural change

I don't think that this is a good idea. The other type checking 
predicates isxyz for a type Xyz all follow the scheme that the predicate 
is equivalent to the type guard, so iscomplex should follow that 
principle, too (that wasn't the case previously, but previously there 
was no Complex type and iscomplex was a semantic predicate).

-- 
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] Query about Type Tests (Complex and Rational).

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

Hi Rob,

well, you caught me "in flagranti" before the new "numeric tower" (which 
is in fact more like an appartment building with 3 floors ;-) is 
actually finished (I still have to add Rational to the picture). I 
haven't discussed this on the list yet, because I first wanted to test 
out things for myself.

Rob Hubbard wrote:
>            Num
>             |
>             |
>           C[R] denoting Complex [with Real parts]
>            / \
>           /   \
>        C[Q]    R = Real
>         / \   /
>        /   \ /
>     C[Z]    Q = Rational
>        \   /
>         \ /
>          Z = Int
> 
>         (C[Z] is the ring of Gaussian Integers.)
> 
> Should these types be related as supertype:subtype, and can Q express
> these (especially where there is more than one supertype)?

Unfortunately not, since Q only has single inheritance. Another 
limitation is that you cannot make Rational a supertype of Int. The 
supertype is set when a type is declared and it cannot be changed after 
that; so Int, as a built-in type, can only be given another built-in 
type as a supertype.

As John has pointed out, it's useful to distinguish between syntax and 
semantics here. Data types are a syntactic concept; they are all about 
representations of certain kinds of data, and which operations apply to 
what data. Then there's the semantic level, our interpretation of what 
these representations actually mean in an ideal mathematical world.

Right now I'm just trying to get the data types right so that they will 
work in the intended way. So I've introduced the abtract data type Real 
purely out of practical considerations, since I want to be able to 
extend the built-in system of number types at all levels. In the new 
system alternative integer types can now be derived from Int, 
alternative floating point types from Float, other subtypes of real 
numbers (like Rational) from Real, and other types of non-real numbers 
(like Complex) from Num.

So the new system looks like this (Rational already included in the 
picture, although this hasn't been implemented in the standard library yet):

Num --> Real --> Int
     +        +-> Float
     +        +-> Rational
     +-> Complex

This has the big advantage over the former system with just two levels 
(Num as a supertype versus the rest) that Complex (which is now a 
subtype of Num) can now be an aggregate of two Real's and will hence 
just work with any other user-defined data types derived from Real or 
any of its subtypes, too.

The (syntactic) predicates associated with these types are isnum, 
isreal, isint, isfloat, isrational and iscomplex. If we also add the 
(semantic) predicates is_complex_rational, is_complex_int as well as 
is_real_or_complex and is_int_or_rational, then all remaining 
memberships in your diagram can be tested easily.

I obviously just followed the KISS principle here, but so far it seems 
to work pretty well. The only real shortcoming I see is that Int is not 
a subtype of Rational and Real not a subtype of Complex. So, e.g., if 
you want to have a function which operates on both Int's and Rational's 
you cannot just define it on Rational arguments and be done with it. 
OTOH, Rational and Int are sufficiently different so that this can 
actually be justified, and if you really have an operation which can be 
defined in a generic fashion on both Int's and Rational's then chances 
are good that it can actually be defined on Real anyway. The same 
applies to Real and Complex and their common supertype Num.

If you hold on for a little longer then I can complete the new 
implementation by integrating Rational into the standard library (maybe 
tonight). I could then release a candidate so that everybody can 
actually try it out and we can go on discussing it. Ok?

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

Re: [q-lang-users] Complex numbers

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

Albert Graef scripsit:

> Cool. :) So all that we need now is an additional API to change the 
> internal state of the Q interpreter. Then we could rewrite the toplevel 
> loop of the Q interpreter in Scheme.

So we could, although I think the current C-based version does well
enough.  My main ambition is not to compete with the Q interpreter,
but to make the power of generalized term rewriting readily available
to Scheme programmers.  For that they need an appropriately Schemish
and S-expression-based interface.

The next release will provide those things, but will not have numeric
tower support or list memoization; when you pass a list to Q and Q
returns a syntactically equal list, it will be only semantically equal
(equal and not eq) on the Scheme side.

> BTW, there's a typo in the compile line in your README: s/-lgpm/-lgmp/. 
> (At least I think so, I haven't actually tried it yet, need to install 
> Chicken first.)

Thanks, fixed.  On most systems you should only need to say -lqint anyhow.
I spotted another typo in the Q manual in at least two places: "quadrupel"
should be "quadruple".

-- 
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                co...@cc...
buy a piece of the rope for a keepsake.

Re: [q-lang-users] Query about Type Tests (Complex and Rational).

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

Rob Hubbard scripsit:

> I think I need clarification on
> (1) When one type should be a subtype of another.
> (2) What the semantics of type test function (such as iscomplex) is
> supposed to be.

Well, FWIW I'll tell you how Scheme does it.  (For Schemers, I'm
oversimplifying some and blurring some distinctions between R5RS and
R6RS-draft.)

In Scheme, the predicates "number?", "complex?", "real?", "rational?", and
"integer?" refer to the mathematical concepts, not the representations.
Thus on "normal" implementations, "number?"  and "complex?" are
the same thing, and "integer?" returns true for any integral value,
even if the underlying representation is floating-point.  "Real?" and
"rational?" are not quite the same, because the former conventionally
includes IEEE infinities whereas the latter does not.

Cutting across this hierarchy or "tower", there are also the predicates
"exact?" and "inexact?".  On "normal" implementations, standard machine
floating-point representations are inexact; machine integers ("fixnums"),
arbitrary-precision integers ("bignums"), and pairs whose numerator and
denominator are integers ("ratnums") are exact.  Note that a complex
number is only real if its imaginary part, expressed or implied, is
an *exact* 0, because 0.0 actually represents every number between the
smallest representable positive float and its negation.

So 1 is exact and integer (and therefore also rational, real, and
complex); 1.0 is inexact and integer (and rational and real and complex);
1.1 is inexact and rational (and real and complex); 11/10 is exact and
rational (and real and complex); 1+2i is exact and complex; 1.0+0i is
inexact and real (and complex); 1.0+0.0i is inexact and complex.

Though not part of the standard, one can write some predicates that
enquire about representations, assuming that the shortest representation
is always used.  It's impossible to write "fixnum?" in portable Scheme,
because it depends on the size of machine integers.  The others can
be written for "normal" Scheme implementations as follows (not Scheme
syntax):

bignum? = integer? and exact? and not fixnum?
ratnum? = rational? and exact? and not integer?
compnum? = complex? and not real?

Some Schemes use different representations for exact and inexact
compnums, where the former is a pair of pointers and the latter is a
pair of unboxed floats.

I hope this is helpful in clarifying everyone's thinking.  Feel free to
ask questions about unclarities.

-- 
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...|ccil.org/~cowan

[q-lang-users] Query about Type Tests (Complex and Rational).

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

The following are from Albert's complex.q revision 1.5, which is
undergoing review at the moment, and my rational.q revision 160.

    public type Complex : Num;

    iscomplex _:Complex = true;
    iscomplex _         = false otherwise;

    public type Rational : Num;

    is_rational _:Rational = true;
    is_rational _          = false;

    is_rat_or_int _:Rational = true;
    is_rat_or_int _:Int      = true;
    is_rat_or_int _          = false;

I'm not sure the type guard "C:Complex" and function application
"iscomplex C" should be related this closely; Similarly for
"Q:Rational" and "is_rational Q".

Perhaps these should be

    iscomplex _:Complex  = true;
    iscomplex R          = isreal R otherwise; //behavioural change

    isreal _:Real  = true;
    isreal Q       = isrational Q otherwise;
    // this won't work unless rational.q is included (or preluded)
    // thus might need to do e.g. "isint Q or else ..."

    isrational _:Rational  = true; // slight rename
    isrational Z           = isint Z otherwise; //behavioural change

    /* (scrap is_rat_or_int) */

    isint _:Int = true;
    isint _ = false otherwise;

(On the other hand, I think it would be wrong for Real to be a subtype
of Complex.)

I think I need clarification on
(1) When one type should be a subtype of another.
(2) What the semantics of type test function (such as iscomplex) is
supposed to be.

For example, for (1), suppose that there are the following types:

           Num
            |
            |
          C[R] denoting Complex [with Real parts]
           / \
          /   \
       C[Q]    R = Real
        / \   /
       /   \ /
    C[Z]    Q = Rational
       \   /
        \ /
         Z = Int

        (C[Z] is the ring of Gaussian Integers.)

Should these types be related as supertype:subtype, and can Q express
these (especially where there is more than one supertype)?

Alternatively, should the only relationships be with Num as the common
supertype?

For (2), should e.g. "iscomplex" mean "is of Complex type or has a
value that may be expressed (exactly?) as a Complex". (I'm ignoring,
for the moment, the problem that a large Int can only be converted
approximately to a Float. I'm assuming that Real and Float are
equivalent.)

I'd appreciate any feedback; it would help with my rational.q and an
experimental "hypercomplex.q" that I'm (tentatively) working on.

Thanks,
Rob.

Re: [q-lang-users] Complex numbers

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

John Cowan wrote:
> But hey, it does work!  Any Chicken user who wants to play around with
> this version can grab it (with a temporary README and a few examples)
> from http://www.ccil.org/~cowan/q-lolevel.zip .  License is GPL, bug
> reports invited, guarantees not provided.

Cool. :) So all that we need now is an additional API to change the 
internal state of the Q interpreter. Then we could rewrite the toplevel 
loop of the Q interpreter in Scheme.

BTW, there's a typo in the compile line in your README: s/-lgpm/-lgmp/. 
(At least I think so, I haven't actually tried it yet, need to install 
Chicken first.)

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] Complex numbers

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

Albert Graef scripsit:

> Yes, it's called complex, and it's in cvs now. I still have to do a 
> little massage to Q's system of number types to make it easier to 
> integrate stuff like rational.q, but you should already be able to test 
> your Chicken egg with the version that is in cvs now.

No hurry.  I'm not going to even start with the support for the full
numeric tower until the basic S-expression support (which thinks all
numbers outside the 2^30 Chicken fixnum range are flonums) is written.
And I haven't even started on that yet -- I just finished the Chicken-to-C
glue code.

So as of now you can do the same things with Q from Scheme, using mostly
the same routines, that a C programmer can.  That is, you can load a
script, define global variables, and evaluate expressions using either
Scheme strings or c-pointer objects.  You have to play by the same rules
as the C programmer as far as allocating and freeing qexprs, too.

But hey, it does work!  Any Chicken user who wants to play around with
this version can grab it (with a temporary README and a few examples)
from http://www.ccil.org/~cowan/q-lolevel.zip .  License is GPL, bug
reports invited, guarantees not provided.

-- 
You know, you haven't stopped talking           John Cowan
since I came here. You must have been           http://www.ccil.org/~cowan
vaccinated with a phonograph needle.            co...@cc...
        --Rufus T. Firefly

Re: [q-lang-users] Complex numbers

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

Hi John,

> The Complex constructor will probably be named just 'complex', but I'll 
> let you know when I know for sure.

Yes, it's called complex, and it's in cvs now. I still have to do a 
little massage to Q's system of number types to make it easier to 
integrate stuff like rational.q, but you should already be able to test 
your Chicken egg with the version that is in cvs 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

Re: [q-lang-users] Complex numbers

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

bri...@co... wrote:
> With frightening regularity, the arcane, abstruse, obscure corners of 
> yesterday's math become tomorrow's indispensible practical tools. I'd 
> hoped my little joke to be a reminder that "arcane" perhaps doesn't mean 
> "not useful," rather "not useful YET."

Point taken. :)

-- 
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] Complex numbers

[<bri...@co...>]

Yes, I was making a little joke :)  But I would like to point out that quaternions are quite useful in simulations of the physics of rotation as one sees in video games, which is fairly 'everyday programming,' though perhaps not in the target domain of Q.

With frightening regularity, the arcane, abstruse, obscure corners of yesterday's math become tomorrow's indispensible practical tools. I'd hoped my little joke to be a reminder that "arcane" perhaps doesn't mean "not useful," rather "not useful YET."

--
BBeckman http://weblogs.asp.net/brianbec http://data/tesla 
------------------------------------------------------------------------------------ 
| Type inference | Object initializers | Anonymous types | XML CRUD | 
| Extension members | LINQ | Relationships | Nested functions | 
| Nullable of T | Relaxed delegates | Dynamic identifiers | Duck typing | 
| Pattern matching | Contracts | AJAX | Iterators | 
| Continuations | REPL | Join Patterns | Transactions | 
| XML Streams | Code Literals | Morphisms | Embedded DSLs | 
------------------------------------------------------------------------------------

-------------- Original message -------------- 
From: Albert Graef <Dr....@t-...> 

> bri...@co... wrote: 
> > long-term suggestion made while strolling down the lane, whistling 
> > nonchalantly enjoying the spring flowers and sunshine: 
> 
> Hi Brian, I realize that you are probably joking here :), but anyway... 
> 
> > quaternions and octonians also as algebraic data types, together with 
> > the reals and the complexes under the class of the "Normed Algebras." 
> 
> That's fun stuff for us mathematicians to play with, but of little or no 
> use for everyday programming. Complex and rational numbers are fine, 
> they should certainly be in the stdlib (complex nums already are, for 
> rational numbers I'll probably add a stripped-down version of Rob's 
> module in the near future). 
> 
> But lets not go overboard with this, otherwise people will soon be 
> demanding vector spaces over polynomial rings and whatelse... And why 
> should we take away all the fun for the programmer to find out how to 
> implement stuff like this him/herself? ;-) 
> 
> 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 mailing list 
> q-l...@li... 
> https://lists.sourceforge.net/lists/listinfo/q-lang-users 

Re: [q-lang-users] Complex numbers

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

John Cowan wrote:
> Excellent.  Just let me know when you've settled on the constructors
> for rationals and rectangular complex numbers, and I'll make sure they
> get into my Chicken egg appropriately.  I've asked Felix for help on
> the bignum issue.

Rationals aren't in the stdlib yet, but as I said elsewhere in this 
thread I might soon add a stripped-down version of Rob's module to fix that.

The Complex constructor will probably be named just 'complex', but I'll 
let you know when I know for sure.

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

Re: [q-lang-users] Complex numbers

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

bri...@co... wrote:
> long-term suggestion made while strolling down the lane, whistling 
> nonchalantly enjoying the spring flowers and sunshine:

Hi Brian, I realize that you are probably joking here :), but anyway...

>  quaternions and octonians also as algebraic data types, together with 
> the reals and the complexes under the class of the "Normed Algebras."  

That's fun stuff for us mathematicians to play with, but of little or no 
use for everyday programming. Complex and rational numbers are fine, 
they should certainly be in the stdlib (complex nums already are, for 
rational numbers I'll probably add a stripped-down version of Rob's 
module in the near future).

But lets not go overboard with this, otherwise people will soon be 
demanding vector spaces over polynomial rings and whatelse... And why 
should we take away all the fun for the programmer to find out how to 
implement stuff like this him/herself? ;-)

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] Release 7.1 Installation Failure

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

Larry Gregg wrote:
> This turned out to be more of a chore than I expected.   Apparently, I 
> tried to delete RC3 manually, before installing V7.1.  This left the 
> Registry with a lot of entries pointing to missing files, etc.  I had to 
> use a Registry fixer to get rid of the missing links.  I had no idea 
> that Q modified the reqistry, and with so many items!

The interpreter and all the other command line programs included will 
never use the registry. Never. The QPad editor/mini IDE does, just like 
about any other Windows application, but it keeps all its entries 
(mostly option settings of the application) under a single parent key 
and it should never be necessary to manually remove those, Qpad will 
update them as needed.

But I guess that MSI also updates the registry, so that it knows where 
to find stuff that it needs to remove when upgrading a package to a 
newer version. Or maybe it's just the way that "Advanced Installer" does 
things. If anyone can recommend another freeware MSI builder which just 
works, and makes it reasonably easy to just create a simple package with 
a few files and some menu and desktop links, I'll be happy to give that 
a try.

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] Release 7.1 Installation Failure

[Larry G. <lg...@ac...>]

lg...@in... wrote:
> Quoting Albert Graef <Dr....@t-...>:
>
>   
>> Larry Gregg wrote:
>>     
>>> I just downloaded Qpad-7.1.msi  The installation failed with message "A
>>> network error occurred while attempting to read from the file
>>> 'C:\windows\installer\qpad-7.1rc3.msi'".
>>>       
>> Hmm, did you install RC3 before? If so, then try removing that version
>> before installing the final release, maybe that helps. (That shouldn't
>> actually happen, but apparently the "Advanced Installer" freeware that
>> I'm using to build the MSIs has its problems with proper versioning.)
>>
>> HTH,
>> 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 mailing list
>> q-l...@li...
>> https://lists.sourceforge.net/lists/listinfo/q-lang-users
>>
>>     
>
> Yes, I did install RC3 first.  I will uninstall it and then install 7.1.
>
> Thanks,
>
> Larry Gregg
>
>
>
>
> _______________________________________________
> q-lang-users mailing list
> q-l...@li...
> https://lists.sourceforge.net/lists/listinfo/q-lang-users
>
> .
>
>   
This turned out to be more of a chore than I expected.   Apparently, I 
tried to delete RC3 manually, before installing V7.1.  This left the 
Registry with a lot of entries pointing to missing files, etc.  I had to 
use a Registry fixer to get rid of the missing links.  I had no idea 
that Q modified the reqistry, and with so many items!

So, beware.  Use the Windows uninstaller for any  version of Q, when you 
need to uninstall it.

Larry Gregg