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

[q-lang-users] Q 7.2 RC1 Issue 2: Notation

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

I still really don't like the option of (%) for division.

The problem could be solved by having (/) return a Rational rather
than a Float where possible. That, in my view, would be desirable
anyway, but I suspect that this would be unpopular, as such a change
might break existing code.

An alternative suggestion: Could the unparse/quotation code be made to
produce "(1 over 5)+(2 over 3)", or is there a reason why such
redundant parenthesis can't/shouldn't be generated?

Rob.

Re: [q-lang-users] Q 7.2 RC1 Issue 2: Notation

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

John Cowan wrote:
> I think that's right in principle; the compound symbol could either begin
> or end in /.  How about |/ or /|?  Neither should cause syntax problems.

I don't see that something like "1/|5+2/|3" has any advantage over "1 
over 5+2 over 3". In fact for me the former is much less readable than 
the latter.

Let's face it, the only punctuation symbols in 7 bit ASCII which look 
right for a division operator are /, %, \ and |. We can't use /, \ or |, 
so the only obvious choice left is %. Since Q uses the div/mod pair for 
integer division and Int/Int yields a Float, I don't see how someone 
could mistake % for the remainder of integer division.

Is this really such a big issue, considering that Haskell also uses % 
for the same purpose?

If it is, then I'd rather stick with the current notation.

-- 
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] Q 7.2 RC 1 issue 1: Nomenclature

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

Albert Graef scripsit:

> No, with "fail" I mean that, e.g., nan=0.0 would be a normal form. In Q, 
> that makes much more sense than returning false in such a case. Either 
> those numbers are incomparable and then the operation should fail; or 
> they _are_ comparable but then the result should make sense (which it 
> doesn't if both nan=0.0 and nan<>0.0 return false because the latter 
> should be the negation of the former).

This argument is compelling.  The IEEE behavior makes sense in the
limited terms of forcing NaNs into the straitjacket of two-valued
logic, but Q can neatly provide a 3-valued true/false/fail system.
This also fits with the way SRFI-77 talks about NaN:

	a real number whose value is so indeterminate that it
	might represent any real number within the closed interval
	[-inf.0,+inf.0].

-- 
Go, and never darken my towels again!           John Cowan
        --Rufus T. Firefly                      http://ccil.org/~cowan

Re: [q-lang-users] Q 7.2 RC1 Issue 2: Notation

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

Rob Hubbard scripsit:

> If you really need a symbol, can't a compound symbol be used? Perhaps
> '//', although that would then mean that '/' and '//' would be the
> "wrong way around" compared to Python.

Unfortunately, // is single-line comment, as in C99, C++, C#, or Java.

> What about some other combination along the lines of '/.', '/^', '/!', ...?
I think that's right in principle; the compound symbol could either begin
or end in /.  How about |/ or /|?  Neither should cause syntax problems.

-- 
John Cowan   co...@cc...    http://ccil.org/~cowan
I am he that buries his friends alive and drowns them and draws them
alive again from the water. I came from the end of a bag, but no bag
went over me.  I am the friend of bears and the guest of eagles. I am
Ringwinner and Luckwearer; and I am Barrel-rider.  --Bilbo to Smaug

Re: [q-lang-users] Q 7.2 RC1 Issue 2: Notation

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

On 19/06/06, Albert Graef <Dr....@t-...> wrote:
> John Cowan wrote:
> > I'm not happy with "over" as the notation for rational numbers.
> > In particular, "1 over 5+2 over 3" looks totally wrong for 1/5 + 2/3;
> > the visual grouping is hopelessly broken.  I realize that we can't use
> > "/" for this purpose, but can't we use another symbol operator?

> So I'm afraid that the only 7 bit ASCII punctuation symbol that's left
> is "%" (incidentally, this is also what Haskell uses for the same
> purpose). It's been a while since this has been used as a comment
> character, so I'd say it's safe to reuse it now. Then you could type
> your example as "1%5 + 2%3". Acceptable?

> Rob, what's your take on this? Do you prefer "over" or "%"? After all
> it's your module. ;-)

Please don't use '%' for division.
I know that Q is not similar to 'C', but '%' really looks like
remainder/modulus to me.

If you really need a symbol, can't a compound symbol be used? Perhaps
'//', although that would then mean that '/' and '//' would be the
"wrong way around" compared to Python.

What about some other combination along the lines of '/.', '/^', '/!', ...?

I do agree that the formatting would look far better with a symbol
than with (over).

Rob.

Re: [q-lang-users] Q 7.2 RC 1 issue 1: Nomenclature

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

John Cowan wrote:
> Time to go to bed.

G'night. :) And thanks for the thorough testing.

-- 
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] Q 7.2 RC 1 issue 1: Nomenclature

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

John Cowan wrote:
> The latter, since an inexact 0.0 might not really be zero, and so the
> true number that is inexactly represented might be close to the real
> axis but not actually on it.

Makes perfect sense. I'll do it that way.

>>Which makes me wonder whether that would be the right thing in Q.
>>Actually I think it would be better if comparisons with nan just fail.
> 
> In fact, this is what IEEE-compliant hardware *already* does, so you
> don't need to do anything.

No, with "fail" I mean that, e.g., nan=0.0 would be a normal form. In Q, 
that makes much more sense than returning false in such a case. Either 
those numbers are incomparable and then the operation should fail; or 
they _are_ comparable but then the result should make sense (which it 
doesn't if both nan=0.0 and nan<>0.0 return false because the latter 
should be the negation of the former).

> Well, I suppose you could trap the SIGFPE exception.

Ugh. In fact I already do that but only to print backtraces and exit 
from the interpreter in an orderly manner. I wouldn't want to emulate 
IEEE floating point numbers that way. Let's just say that systems 
without a proper IEEE floating point arithmetic loose; ppl will just 
have to put up with the deficiencies of those systems or have to set up 
their own SIGFPE handling in their Q scripts.

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] Q 7.2 RC1 Issue 3: IEEE floats

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

Albert Graef scripsit:

> Hmm, I guess that should actually be:
> 
> 	return (f - f != f && f + f == f);
> 
> We shouldn't forget that 0.0 is idempotent for (+), too. ;-)

Oops yet again.

Still f == f + 1 should still work; no finite value will work there,
and neither will nan, because although nan + 1 is nan, it is false
that nan == nan.

-- 
John Cowan  co...@cc...  http://ccil.org/~cowan
And now here I was, in a country where a right to say how the country should
be governed was restricted to six persons in each thousand of its population.
For the nine hundred and ninety-four to express dissatisfaction with the
regnant system and propose to change it, would have made the whole six
shudder as one man, it would have been so disloyal, so dishonorable, such
putrid black treason.  --Mark Twain's Connecticut Yankee

Re: [q-lang-users] Q 7.2 RC1 Issue 3: IEEE floats

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

John Cowan wrote:
> int isinf(double f) {
>         return (f + f == f);
>         }

Hmm, I guess that should actually be:

	return (f - f != f && f + f == f);

We shouldn't forget that 0.0 is idempotent for (+), too. ;-)

-- 
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] Q 7.2 RC 1 issue 1: Nomenclature

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

John Cowan scripsit:

> It is. See http://q-lang.sourceforge.net/qdoc/qdoc_3.html#SEC8. Maybe
> you're looking at an old version of the manual?

Oops.

> The numeric draft material for R6RS appears at
> http://srfi.schemers.org/srfi-75/srfi-75.html .

Oops, that should be http://srfi.schemers.org/srfi-77/srfi-77.html .
Time to go to bed.

-- 
In my last lifetime,                            John Cowan
I believed in reincarnation;                    http://www.ccil.org/~cowan
in this lifetime,                               co...@cc...
I don't.  --Thiagi

Re: [q-lang-users] Q 7.2 RC 1 issue 1: Nomenclature

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

Albert Graef scripsit:

> I like isintval etc., that looks much more "Q'ish" than isinZ etc.

Okay.

> > That reminds me that the rules for isintnum, isratnum, and isrealnum
> > when applied to type Complex do not check that the imaginary form
> > is an *exact* 0.  As I pointed out before, an inexact 0 is really
> > a representation for any number n such that -d < n < d, where d is
> > the smallest positive float.
> 
> So what's the right way to implement these? R5RS gives these as examples 
> (I couldn't find the relevant part of the R6RS draft):
> 
> (real? -2.5+0.0i)               ===>  #t
> (integer? 3+0i)                 ===>  #t

The numeric draft material for R6RS appears at
http://srfi.schemers.org/srfi-75/srfi-75.html .

> So should isrealval Z return true if im Z=0 but isintval Z => true only 
> if eq (im Z) 0? Or do you suggest that both predicates should always 
> return false when im Z is inexact?

The latter, since an inexact 0.0 might not really be zero, and so the
true number that is inexactly represented might be close to the real
axis but not actually on it.

> I'll also have to fix the built-in comparison of floating point numbers 
> so that any comparison with nan always returns false. 
> Which makes me wonder whether that would be the right thing in Q.
> Actually I think it would be better if comparisons with nan just fail.

In fact, this is what IEEE-compliant hardware *already* does, so you
don't need to do anything.

> Some builtins like
> ln and atan/atan2 probably have to be modified, too. And some of the 
> definitions in complex.q need to be fixed so that they only fail with 
> exact zeros.

Yes.

> And what happens with all of that if the host system doesn't have IEEE 
> floating point? A division by 0.0 causing the interpreter to segfault? 
> That would be rather unfortunate.

Well, I suppose you could trap the SIGFPE exception.

-- 
There are three kinds of people in the world:   John Cowan
those who can count,                            co...@cc...
and those who can't.

Re: [q-lang-users] Q 7.2 RC1 Issue 2: Notation

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

John Cowan wrote:
> In that case it too should be at the bottom of Section 3.

It is. See http://q-lang.sourceforge.net/qdoc/qdoc_3.html#SEC8. Maybe 
you're looking at an old version of the manual?

-- 
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] Q 7.2 RC1 Issue 2: Notation

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

Albert Graef scripsit:

> "&" is the memoization operator (Q 7.1 and later; see the "Special 
> Forms" chapter).  

In that case it too should be at the bottom of Section 3.

-- 
There are three kinds of people in the world:   John Cowan
those who can count,                            co...@cc...
and those who can't.

Re: [q-lang-users] Q 7.2 RC 1 issue 1: Nomenclature

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

I wrote:
> I'll also have to fix the built-in comparison of floating point numbers 
> so that any comparison with nan always returns false.

Which makes me wonder whether that would be the right thing in Q. 
Actually I think it would be better if comparisons with nan just fail.

-- 
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] Q 7.2 RC1 Issue 2: Notation

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

John Cowan wrote:
> The list at the bottom of Section 3 does not mention $ but should.

Thanks, I'll fix that.

> I don't know what & and ? mean, if anything (I agree they don't work
> for ratios).

"&" is the memoization operator (Q 7.1 and later; see the "Special 
Forms" chapter). "?" isn't actually used in the language, but is used as 
a kind of explicit "evaluate" command on the interpreter and debugger 
command lines (see the "Command Language" section in Appendix B). That 
doesn't collide with its potential use as an (operator) identifier, but 
as you rightfully noticed it wouldn't look great in ratios. ;-)

-- 
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] Q 7.2 RC 1 issue 1: Nomenclature

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

John Cowan wrote:
> I have two suggestions, neither of which I am wild about.  One is is
> "isintval", "isratval", etc.  This is verbose but clear: it's about
> values, not representations.  The other is cleverer and can't be confused
> with the existing predicates, but may be *too* clever:  "isinZ", "isinQ",
> "isinR", "isinC".

I like isintval etc., that looks much more "Q'ish" than isinZ etc.

> That reminds me that the rules for isintnum, isratnum, and isrealnum when
> applied to type Complex do not check that the imaginary form is an *exact*
> 0.  As I pointed out before, an inexact 0 is really a representation for
> any number n such that -d < n < d, where d is the smallest positive float.

So what's the right way to implement these? R5RS gives these as examples 
(I couldn't find the relevant part of the R6RS draft):

(real? -2.5+0.0i)               ===>  #t
(integer? 3+0i)                 ===>  #t

So should isrealval Z return true if im Z=0 but isintval Z => true only 
if eq (im Z) 0? Or do you suggest that both predicates should always 
return false when im Z is inexact?

I'll also have to fix the built-in comparison of floating point numbers 
so that any comparison with nan always returns false. Some builtins like 
ln and atan/atan2 probably have to be modified, too. And some of the 
definitions in complex.q need to be fixed so that they only fail with 
exact zeros.

And what happens with all of that if the host system doesn't have IEEE 
floating point? A division by 0.0 causing the interpreter to segfault? 
That would be rather unfortunate.

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] Q 7.2 RC1 Issue 2: Notation

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

Albert Graef scripsit:

> I think that this shouldn't actually be a serious issue, since Q uses an 
> operator system based on that of Pascal, not C. You won't find many 
> similarities with C there (except for the basic arithmetic operators, of 
> course, but any language with infix arithmetic has those).

Or postfix (Joy) or prefix (Scheme/Lisp), for that matter.

-- 
At the end of the Metatarsal Age, the dinosaurs     John Cowan
abruptly vanished. The theory that a single         co...@cc...
catastrophic event may have been responsible        http://www.ccil.org/~cowan
has been strengthened by the recent discovery of
a worldwide layer of whipped cream marking the
Creosote-Tutelary boundary.             --Science Made Stupid

Re: [q-lang-users] Q 7.2 RC1 Issue 3: IEEE floats

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

John Cowan wrote:
> Indeed.  You can define nan as inf - inf.

Right.

> int isinf(double f) {
>         return (f + f == f);
>         }
> 
> int isnan(double f) {
>         return !(f == f);
>         }

Thanks.

-- 
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] Q 7.2 RC1 Issue 2: Notation

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

Tim Haynes wrote:
> Eek. There's the small issue of those who're used to C, Perl et al
> confusing it with mod...

I think that this shouldn't actually be a serious issue, since Q uses an 
operator system based on that of Pascal, not C. You won't find many 
similarities with C there (except for the basic arithmetic operators, of 
course, but any language with infix arithmetic has those).

-- 
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] Q 7.2 RC1 Issue 2: Notation

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

Albert Graef scripsit:

> So I'm afraid that the only 7 bit ASCII punctuation symbol that's left 
> is "%" (incidentally, this is also what Haskell uses for the same 
> purpose). It's been a while since this has been used as a comment 
> character, so I'd say it's safe to reuse it now. Then you could type 
> your example as "1%5 + 2%3". Acceptable?

The list at the bottom of Section 3 does not mention $ but should.  I
don't know what & and ? mean, if anything (I agree they don't work
for ratios).

-- 
Verbogeny is one of the pleasurettes    John Cowan <co...@cc...>
of a creatific thinkerizer.             http://www.ccil.org/~cowan
   -- Peter da Silva

Re: [q-lang-users] Q 7.2 RC 1 issue 1: Nomenclature

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

Albert Graef scripsit:

> So we'll have to change the name of the semantic predicates then. Any 
> suggestions? How about intp, rationalp, realp, complexp? Looks familiar 
> to Lisp programmers, non-Lispers will surely hate it, but it is short 
> and at least reminiscent of the Scheme functions.

These are the representational predicates in Lisp rather than the
number-theoretic ones, though they can mostly do the work of both because
Lisp aggressively reduces complex representations to real and rational
representations to integer when possible.

I have two suggestions, neither of which I am wild about.  One is is
"isintval", "isratval", etc.  This is verbose but clear: it's about
values, not representations.  The other is cleverer and can't be confused
with the existing predicates, but may be *too* clever:  "isinZ", "isinQ",
"isinR", "isinC".

That reminds me that the rules for isintnum, isratnum, and isrealnum when
applied to type Complex do not check that the imaginary form is an *exact*
0.  As I pointed out before, an inexact 0 is really a representation for
any number n such that -d < n < d, where d is the smallest positive float.

-- 
Samuel Johnson on playing the violin:           John Cowan
"Difficult do you call it, Sir?                 co...@cc...
 I wish it were impossible."                    http://www.ccil.org/~cowan

Re: [q-lang-users] Q 7.2 RC1 Issue 4: isinfty

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

Albert Graef scripsit:

> BTW, using "+" for the test doesn't work over here, but "/" does 
> (inf/inf=nan, nan/nan=nan).

My last message contains what I think is the best test.  + was a
brain fart on my part; I meant to write -, but the fact that NaN
always compares false with everything is a better method.

-- 
A rabbi whose congregation doesn't want         John Cowan
to drive him out of town isn't a rabbi,         http://www.ccil.org/~cowan
and a rabbi who lets them do it                 co...@cc...
isn't a man.    --Jewish saying

Re: [q-lang-users] Q 7.2 RC1 Issue 3: IEEE floats

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

Albert Graef scripsit:

> > But none of "on inf", "-inf", or "nan" has the correct meaning input.
> > This should be cleaned up.
> 
> I don't understand, what's "on inf"?

An editing blunder on my part: it should read:

> > But none of "inf", "-inf", or "nan" has the correct meaning on input.

> Defining inf and nan as const variables in the library would probably do 
> the trick. In fact, this is what I do (for inf) in some of my scripts.

Indeed.  You can define nan as inf - inf.

> > This should be cleaned up by defining a syntax for these values to
> > be used on input and output, and by not failing when doing a floating
> > division by zero (though an exact division by zero should still fail).
> 
> Is there a portable way to check for inf and nan values? (So that I 
> don't have to rely on the C library to do the right thing when printing 
> those numbers.)

int isinf(double f) {
        return (f + f == f);
        }

int isnan(double f) {
        return !(f == f);
        }

These depend on the "stickiness" of infinity and the fact that NaN
doesn't compare equal to anything, not even NaN.  (Do not simplify to
"f != f", as NaN doesn't compare *unequal* to anything either.)

-- 
Values of beeta will give rise to dom!          John Cowan
(5th/6th edition 'mv' said this if you tried    http://www.ccil.org/~cowan
to rename '.' or '..' entries; see              co...@cc...
http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)

Re: [q-lang-users] Q 7.2 RC1 Issue 2: Notation

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

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

[snip]
> So I'm afraid that the only 7 bit ASCII punctuation symbol that's left is
> "%" (incidentally, this is also what Haskell uses for the same purpose).
> It's been a while since this has been used as a comment character, so I'd
> say it's safe to reuse it now. Then you could type your example as "1%5 +
> 2%3". Acceptable?

Eek. There's the small issue of those who're used to C, Perl et al
confusing it with mod...

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

Re: [q-lang-users] Q 7.2 RC1 Issue 4: isinfty

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

John Cowan wrote:
> The current test for infinity also applies to NaNs.  These should be
> split into isinfty and isnan, perhaps depending on the fact that nan +
> nan = nan, whereas infinity plus itself is also nan, not infinity.

Oops, yes. That also answers my question about the portable inf/nan 
tests. ;-)

BTW, using "+" for the test doesn't work over here, but "/" does 
(inf/inf=nan, nan/nan=nan).

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