Thread: [q-lang-users] Q 7.2 RC1 Issue 2: Notation
Brought to you by:
agraef
Menu
▾
▴
q-lang-users
|
From: John C. <co...@cc...> - 2006-06-19 18:55:12
|
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? I would propose "|", which is visually close to "/" and is used in the "units" program for the same purpose. A non-ASCII alternative would be ÷ (division sign). These would be very minor changes to the lexer. -- 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 |
|
From: Albert G. <Dr....@t-...> - 2006-06-19 20:07:47
|
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? Actually I've been tossing around the idea to make the "/" builtin undefined on Int Int so that it could be defined in the library. But that would probably break just about any Q script out there, so it's not really an option. > > I would propose "|", which is visually close to "/" and is used in the > "units" program for the same purpose. A non-ASCII alternative would be ÷ > (division sign). These would be very minor changes to the lexer. "|" is not possible as it is already used as a delimiter in list/stream/tuple notation, so we'd get very evil ambiguities in the expression grammar. And I don't like the idea of using something which is not 7 bit ASCII. Of course a programmer can easily define his own aliases using extended characters, but the language and the library should be 7 bit only IMHO. 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? ATM user-defined operator symbols can only be made from punctuation symbols outside the 7 bit range, but I guess that I could change that, even if it's only to be used in this single case. Rob, what's your take on this? Do you prefer "over" or "%"? After all it's your module. ;-) -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Tim H. <q...@st...> - 2006-06-19 20:37:22
|
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/> |
|
From: John C. <co...@cc...> - 2006-06-19 21:56:53
|
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 |
|
From: Albert G. <Dr....@t-...> - 2006-06-20 02:58:32
|
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 |
|
From: John C. <co...@cc...> - 2006-06-20 03:11:42
|
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 |
|
From: Albert G. <Dr....@t-...> - 2006-06-20 03:58:40
|
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 |
|
From: Rob H. <hub...@gm...> - 2006-06-20 07:55:44
|
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. |
|
From: John C. <co...@cc...> - 2006-06-20 14:44:12
|
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 |
|
From: Albert G. <Dr....@t-...> - 2006-06-20 16:08:07
|
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 |
|
From: Rob H. <hub...@gm...> - 2006-06-20 16:33:46
|
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. |
|
From: Albert G. <Dr....@t-...> - 2006-06-20 22:30:25
|
Rob Hubbard wrote: > 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. Well, I know that I'm guilty of that idea as well, but unfortunately I didn't think it through... This wouldn't just be unpopular and break backwards compatibility, it's also a misfeature (in a programming language, as opposed to a computer algebra system), because you could never be sure which type is returned by (/). This in turn will make some code involving numbers as arguments to other functions very error-prone. It's true that it doesn't really matter what the type of the result of (/) is as long as you stay within the realm of arithmetic expressions, but when you eventually pass the result to another function (printf, e.g.) then it does matter a lot. A similar (but even worse) issue has already been beaten to death over at the Python mailing list, see, e.g., http://www.python.org/dev/peps/pep-0238/ > 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? That would make pretty-printing very inconsistent. Then why not always parenthesize "div"/"mod", too? And "and then"? Or just every expression? Which would essentially give us something which looks more like infix s-expressions than anything else. Not that I have anything against s-expressions, but it's just not "the right thing" for Q. So where do we go from here? I'd be happy with both "over" and "%", but I think that John raised a legitimate concern about "over" which, in this form, only arises with "over" because it's used as in the visual representation of numbers. I think it's not quite as bad as he makes it out to be, though. You'd never see something like "1 over 5+2 over 3" in a printed result unless it's in a quoted term or a symbolic expression. Typically, you'd just have something like "5 over 13" occurring as a toplevel expression, list member (where no parentheses are necessary for humans to parse it correctly) or an argument of a constructor application (where it would be parenthesized anyway). Should we have a poll now? :) Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2006-06-20 22:55:16
|
Albert Graef wrote: > this form, only arises with "over" because it's used as in the visual s/as in/in/ > a printed result unless it's in a quoted term or a symbolic expression. s/or a symbolic/or another suspended/ Sorry, it's already getting quite later over here. :) -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: John C. <co...@cc...> - 2006-06-20 23:13:22
|
Albert Graef scripsit: > This wouldn't just be unpopular and break backwards compatibility, it's > also a misfeature (in a programming language, as opposed to a computer > algebra system), because you could never be sure which type is returned > by (/). This in turn will make some code involving numbers as arguments > to other functions very error-prone. It's true that it doesn't really > matter what the type of the result of (/) is as long as you stay within > the realm of arithmetic expressions, but when you eventually pass the > result to another function (printf, e.g.) then it does matter a lot. A > similar (but even worse) issue has already been beaten to death over at > the Python mailing list, see, e.g., http://www.python.org/dev/peps/pep-0238/ I agree: we need different operators for exact and inexact division. > So where do we go from here? I'd be happy with both "over" and "%", but > I think that John raised a legitimate concern about "over" which, in > this form, only arises with "over" because it's used as in the visual > representation of numbers. I think it's not quite as bad as he makes it > out to be, though. You'd never see something like "1 over 5+2 over 3" in > a printed result unless it's in a quoted term or a symbolic expression. True, but you will see "1 over 5+2 over 3*i", which was the example in the first draft of my original e-mail. I removed the "*i", thinking it would just confuse the issue, and not realizing that removing it made the expression no longer in normal form. I'm beginning to wonder if this unparsing is the Right Thing after all: it makes it harder to see what is a normal form and what is not. If you type "1 over 5+2 over 3*i" into a Q 7.2 RC1 interpreter, you get back "1 over 5+2 over 3*i", as if the expression were in fact in normal form. But it's not; the underlying normal form is "complex::complex (rational::rat 1 5) (rational::rat 2 3)", which is then effectively denormalized for printing purposes. -- May the hair on your toes never fall out! John Cowan --Thorin Oakenshield (to Bilbo) co...@cc... |
|
From: Albert G. <Dr....@t-...> - 2006-06-21 00:00:08
|
John Cowan wrote: > True, but you will see "1 over 5+2 over 3*i", which was the example in > the first draft of my original e-mail. Yes, you're right, I forgot about that case. So that really makes it an issue. "1%5+2%3*i" is a lot more readable than "1 over 5+2 over 3*i", I fully agree with that now. > I'm beginning to wonder if this unparsing is the Right Thing after all: > it makes it harder to see what is a normal form and what is not. If you > type "1 over 5+2 over 3*i" into a Q 7.2 RC1 interpreter, you get back > "1 over 5+2 over 3*i", as if the expression were in fact in normal > form. But it's not; the underlying normal form is "complex::complex > (rational::rat 1 5) (rational::rat 2 3)", which is then effectively > denormalized for printing purposes. Yes, I really should add some remarks about this to the manual. I still think that this is very desirable or even essential for the benefit of readability. And it also resolves the issue of external objects not being printable and serializable, which was another one of my pet peeves. BTW, it's easy to get rid of the custom unparsings if you don't want them (e.g., for debugging purposes). Just add the equation "unparse = ();" to your program. I should mention that in the manual, too. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2006-06-24 08:06:12
|
John Cowan wrote: > I agree: we need different operators for exact and inexact division. There's one last issue concerning division that we should think about before the final release: How should (/) behave with rational (and complex rational) operands? Note that (%) returns an exact (rational or complex rational) result for any combination of exact operands, and that's what it's supposed to do. With (/) we currently (RC2) have that (/) returns a Float if both operands are Int and a Rational if at least one of them is a Rational. That's also the way it works in Haskell: Haskell (Hugs, May 2006 version): Ratio> 12/8 1.5 Ratio> 12%1/8 3 % 2 Q (7.2 RC2): ==> 12/8 1.5 ==> 12%1/8 3%2 In Q the same also applies to complex integer vs. complex rational values: ==> 1/i 0.0-1.0*i ==> 1%1/i -(1%1)*i But note that the machinery behind this in Haskell is quite different from Q. In Q there is *only one* (/) function which happens to be defined on both Int and Rational, so we have ad-hoc polymorphism here. In contrast, in the Haskell example the two instances of (/) come from two different instances of the Fractional type class and so they are in fact *two different* functions which just happen to be called by the same name. (At least that's how I understand the notion of type classes in Haskell. I'm not an expert Haskell programmer, so someone please correct me if I'm wrong.) Therefore one could argue that in Q, following the principle of the least surprise, one should expect that (/) _always_ denotes inexact division and thus 12%1/8 should return 1.5 just like 12/8. This would also be consistent with the behaviour of (^) which also returns inexact values for all combinations of operands. What do you all think? Should (/) always return inexact results? Or would you prefer exact results when possible? (With the notable exception of the builtin (/): Int Int -> Float; we really need to keep this for backward compatibility, and thus (/) on complex integers should also return inexact values.) (Rob, I realize that changing (/) to always return inexact results might break ratutils.q in some places. But that should be easy to fix if we use (%) instead of (/) in those situations.) Comments? TIA, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: John C. <co...@cc...> - 2006-06-24 17:01:11
|
Albert Graef scripsit:
> John, it would be nice if you (and everyone else who cares about the
> numeric stuff) could once again apply a bit of torture to the
> float/rational/complex arithmetic to see if everything now works as you
> proposed and we discussed. ;-) There have been quite a few changes, so
> I'd really appreciate your feedback.
:c
I'll try to do this in the next few days. As yet I haven't had a chance
to build RC2 today.
> Therefore one could argue that in Q, following the principle of the
> least surprise, one should expect that (/) _always_ denotes inexact
> division and thus 12%1/8 should return 1.5 just like 12/8. This would
> also be consistent with the behaviour of (^) which also returns inexact
> values for all combinations of operands.
I prefer this behavior: % produces exact results always, / produces
inexact results always. (This implies that (1+2*i)/(3+4*i) is also
inexact.)
--
John Cowan <co...@cc...>
http://www.ccil.org/~cowan
.e'osai ko sarji la lojban.
Please support Lojban! http://www.lojban.org
|
|
From: Albert G. <Dr....@t-...> - 2006-06-24 18:59:57
|
John Cowan wrote: > I'll try to do this in the next few days. As yet I haven't had a chance > to build RC2 today. Thanks. Take your time, there's no hurry as I probably do a new RC in the next few hours (see below). Keith Trenton wrote: > Yes; this is in conformity with my previous "suggestion #1" and "suggestion #3". ;-) John Cowan wrote: > I prefer this behavior: % produces exact results always, / produces > inexact results always. (This implies that (1+2*i)/(3+4*i) is also > inexact.) Thanks for your replies. Since I haven't heard any complaints and I also think that this is the right thing, I'll do the necessary changes and make a new RC available immediately afterwards. Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2006-06-25 10:37:54
|
Albert Graef wrote: > Thanks for your replies. Since I haven't heard any complaints and I also > think that this is the right thing, I'll do the necessary changes and > make a new RC available immediately afterwards. RC3 is out now, enjoy. :) -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2006-06-20 22:39:12
|
John Cowan wrote: > I'm okay with %. Although it is used in C-ish languages including Perl, > the operation is not exactly common anywhere. Exactly. > And if you tilt your head > a bit to the left, % even looks like a division sign. Yes. > That reminds me. Thinking about | gave me to wonder: since improper > tuples like (1|2) are not stored contiguously, and the 2 is not accessible > with !, do they really make any sense? Ancient Lisp tradition requires us > to allow improper lists like [A|B], but I think improper tuples should go, > and improper streams as well. "Improper" tuples are vital in symbolic computations, e.g., you will often find them as a pattern in lambdas or "case" constructs. Redefining this syntax to something else would thus not only raise orthogonality concerns, it would also kill Q's reflective capabilities. > (My current plan for the Q egg is to treat improper tuples as opaque > objects, whereas ordinary tuples will be mapped to Chicken vectors.) I don't think that this is a good idea, for the reason sketched out above. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2006-06-19 20:09:46
|
John Cowan wrote: > In particular, "1 over 5+2 over 3" looks totally wrong for 1/5 + 2/3; Of course, the same issue arises with "div". But then again you don't see that very often in expressions printed by the interpreter. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: John C. <co...@cc...> - 2006-06-20 04:18:35
|
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. |
|
From: Albert G. <Dr....@t-...> - 2006-06-20 04:27:07
|
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 |
|
From: John C. <co...@cc...> - 2006-06-20 16:35:46
|
Albert Graef scripsit: > 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. I'm okay with %. Although it is used in C-ish languages including Perl, the operation is not exactly common anywhere. And if you tilt your head a bit to the left, % even looks like a division sign. That reminds me. Thinking about | gave me to wonder: since improper tuples like (1|2) are not stored contiguously, and the 2 is not accessible with !, do they really make any sense? Ancient Lisp tradition requires us to allow improper lists like [A|B], but I think improper tuples should go, and improper streams as well. (My current plan for the Q egg is to treat improper tuples as opaque objects, whereas ordinary tuples will be mapped to Chicken vectors.) -- You escaped them by the will-death John Cowan and the Way of the Black Wheel. co...@cc... I could not. --Great-Souled Sam http://www.ccil.org/~cowan |
|
From: Tim H. <q...@st...> - 2006-06-20 17:20:18
|
John Cowan <co...@cc...> writes: > I'm okay with %. Although it is used in C-ish languages including Perl, > the operation is not exactly common anywhere. And if you tilt your head a > bit to the left, % even looks like a division sign. FWIW, I raised C/Perl et al, not because they define what's `right', but more to consider for the rule of least surprise, from the perspective of folks coming from those languages. It might be that we have more folks coming with significant Haskell experience, in which case that's a non-issue. So on average, I'm still 50-50 about it. :) ~Tim -- <http://spodzone.org.uk/> |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X