Thread: Re: [q-lang-users] New stuff in cvs: multichar ops, views
Brought to you by:
agraef
Menu
▾
▴
q-lang-users
|
From: Keith T. <kaz...@ea...> - 2007-05-31 05:38:01
|
Hello Albert -- --- Albert Graef <Dr....@t-...> writes: - As a first exercise, I just comitted some changes which turn - Complex into an ADT with the virtual constructor (:+). - So the constant i now prints as 0:+1. - - But I'd actually prefer +: for Q. Other suggestions, anyone?) Why not '0:-1' (as opposed to '0:+1')? After all, the constant i is the square root of -1, is it not? I know that it is not much of a difference (exchanging '-' for '+'), but at least ':-' reminds me (if no one else ;-) of imaginary numbers. Am I all wet here, or what? Cheers, Keith |
|
From: Keith T. <kaz...@ea...> - 2007-05-31 19:22:35
|
Hello Albert -- --- Albert Graef <Dr....@t-...> writes: - Hmm, for me X:-Y looks too much like a '-' where there should be '+'. I was thinking too small (i.e., 0:-1) and not looking at the bigger picture (i.e., all X:+Y). My bad. One suggestion: is it not possible to implement '+:' _AND_ ':+', with the latter form serving as a "safety net" for thick-fingered Haskell programmers? Maybe a warning could be printed to indicate that '+:' is the preferred form for expressing complex numbers (X+:Y) Did I just pour another bucket of water over my head? ;-) Cheers, Keith |
|
From: Albert G. <Dr....@t-...> - 2007-05-31 20:28:46
|
Keith Trenton wrote: > One suggestion: is it not possible to implement '+:' _AND_ ':+', with the latter form serving as a "safety net" for thick-fingered Haskell programmers? Yes sure, that's a good idea. In fact, I've already implemented it! So (+:) is now the "official" constructor, with (:+) provided as an alias for Haskell aficionados. Ok, is everybody happy with that now? Or can at least live with it? > Maybe a warning could be printed to indicate that '+:' is the preferred form for expressing complex numbers (X+:Y) Unfortunately that's not possible, since the compiler doesn't even "know" about (+:) and (:+); they're defined in the standard library. Hmm, maybe we need a new '__do_not_use_that_or_else__' modifier in symbol declarations which causes the interpreter to print a nasty warning when such a symbol is used. On repeated use of some such symbol the interpreter might then explode. ;-) > Did I just pour another bucket of water over my head? ;-) I could use some of that. ;-) I have a terrible headache today. Probably the weird weather over here, one day it's already summer with 30C (86F), the next day we have rain and 10C (50F). It's killing me. Best April weather (in contrast, April was nice and sunny and no rain at all). Best, 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...> - 2007-05-31 21:10:52
|
Keith Trenton scripsit: > One suggestion: is it not possible to implement '+:' _AND_ ':+', > with the latter form serving as a "safety net" for thick-fingered > Haskell programmers? How about "+|*", which actually does look like "+ i *"? -- John Cowan co...@cc... http://ccil.org/~cowan Female celebrity stalker, on a hot morning in Cairo: "Imagine, Colonel Lawrence, ninety-two already!" El Auruns's reply: "Many happy returns of the day!" |
|
From: Keith T. <kaz...@ea...> - 2007-05-31 23:02:39
|
Hello John -- --- John Cowan <co...@cc...> scripsit: - How about "+|*", which actually does look like "+ i *"? True enough, but as my "less is more" preference wrt. typing extra characters has a higher precedence, my vote stays with '+:' (X+:Y). Cheers, Keith |
|
From: John C. <co...@cc...> - 2007-05-31 23:43:52
|
Keith Trenton scripsit: > > Hello John -- > > --- John Cowan <co...@cc...> scripsit: > - How about "+|*", which actually does look like "+ i *"? > > True enough, but as my "less is more" preference wrt. typing extra > characters has a higher precedence, my vote stays with '+:' (X+:Y). What about "+*", then? The colon is only relevant because of a rule of Haskell lexical syntax that does not apply to Q. > Cheers, > Keith > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > q-lang-users mailing list > q-l...@li... > https://lists.sourceforge.net/lists/listinfo/q-lang-users -- All Norstrilians knew what laughter was: John Cowan it was "pleasurable corrigible malfunction". co...@cc... --Cordwainer Smith, Norstrilia |
|
From: Albert G. <Dr....@t-...> - 2007-06-01 01:06:06
|
John Cowan wrote: > Keith Trenton scripsit: >> >> Hello John -- >> >> --- John Cowan <co...@cc...> scripsit: >> - How about "+|*", which actually does look like "+ i *"? >> >> True enough, but as my "less is more" preference wrt. typing extra >> characters has a higher precedence, my vote stays with '+:' (X+:Y). I have to agree with Keith here. > What about "+*", then? The colon is only relevant because of a > rule of Haskell lexical syntax that does not apply to Q. True enough, but the current solution ((:+) aliased to (+:)) has the big advantage that it looks familiar (for Haskell programmers anyway) and is actually Haskell-compatible. I don't know any other language that has an infix operator to create complex numbers, does anyone else? 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: Eddie R. <ed...@bm...> - 2007-06-01 03:59:50
|
Albert Graef wrote, > actually Haskell-compatible. I don't know any other language that has an > infix operator to create complex numbers, does anyone else? What about Python: >>> 2+3j + 2-4i (4-1j) Eddie |
|
From: Albert G. <Dr....@t-...> - 2007-06-01 11:03:43
|
Eddie Rucker wrote:
> What about Python:
>
>>>> 2+3j + 2-4i
> (4-1j)
Yes, Scheme offers something similar. But this is just builtin syntax;
you can't match against a pattern like X+Yj. In Q you can now do that:
coords (X+:Y) = (X,Y);
I wonder whether this is compelling enough so that you might be willing
to put up with the unfamiliar X+:Y syntax? :)
Anyway, assuming that we want Complex to have a virtual constructor (I
do, if only for consistency with Rational), I'd say that (+:) is as at
least as good as any other, so I'm going to stick with it for now. Note
that if you don't like this then you can always get the old X+i*Y
pretty-printing back by just adding the old definition of Complex's view
to your programs:
view C:Complex = if Y<0 then '(X-~(-Y)*i) else '(X+Y*i)
where (X,Y) = re_im C;
Of course then you lose the ability to pattern-match against complex
values, but the standard library doesn't depend on that.
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: Rob H. <hub...@gm...> - 2007-06-01 10:04:27
|
On 01/06/07, Eddie Rucker <ed...@bm...> wrote:
> Albert Graef wrote,
>
> > I don't know any other language that has an
> > infix operator to create complex numbers, does anyone else?
>
> What about Python:
>
> >>> 2+3j + 2-4i
> (4-1j)
>
> Eddie
But beware that Python doesn't really get this quite right:
>>> (1+2j) * (3+4j)
(-5+10j)
>>> 1 + (2j*3) + 4j
(1+10j)
>>> 1+2j * 3+4j
(1+10j)
That is, the '+' and '*' operators have their usual precedences. There
is no 'special' high-precedence operator for complex construction.
Also, the latest 'C' standard (C99?) has support for imaginary and
complex numbers, but I'm not sure of the lexing details...
Rob.
|
|
From: Rob H. <hub...@gm...> - 2007-06-26 21:50:26
|
Hello Albert and all,
Here's what the new complex operators do in Q7.7:
==> (1+:2) * (3+:4)
-5+:10
==> 1 +: (2*3) +: 4
1+:10
==> 1+:2 * 3+:4
1+:10
I think that the last here is the wrong result. Could the precedence
of (+:) be raised? I think that (+:) should bind more tightly even
than (^) exponentiation, so perhaps it should have the precedence of
(.) function composition.
On the subject of (+:), I wondered whether there could be another
operator (-:) having the meaning "-i*", just as (+:) has meaning
"+i*". Then rather that this:
==> 5 - sqrt (-16)
5.0 +: -4.0
the result would be
==> 5 - sqrt (-16)
5.0-:4.0
which looks closer to "5.0 - i 4.0", and is I think prettier.
> But beware that Python doesn't really get this quite right:
>
> >>> (1+2j) * (3+4j)
> (-5+10j)
>
> >>> 1 + (2j*3) + 4j
> (1+10j)
>
> >>> 1+2j * 3+4j
> (1+10j)
Thanks,
Rob.
|
|
From: John C. <co...@cc...> - 2007-06-27 02:27:03
|
Rob Hubbard scripsit: > I think that the last here is the wrong result. Could the precedence > of (+:) be raised? I think that (+:) should bind more tightly even > than (^) exponentiation, so perhaps it should have the precedence of > (.) function composition. +1 > On the subject of (+:), I wondered whether there could be another > operator (-:) having the meaning "-i*", just as (+:) has meaning > "+i*". Then rather that this: This is clever but not really necessary, I think. -- John Cowan co...@cc... http://ccil.org/~cowan The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. --Edsger Dijkstra |
|
From: Rob H. <hub...@gm...> - 2007-06-27 09:47:16
|
Thanks John, On 27/06/07, John Cowan <co...@cc...> wrote: > > On the subject of (+:), I wondered whether there could be another > > operator (-:) having the meaning "-i*", just as (+:) has meaning > > "+i*". ... > > This is clever but not really necessary, I think. I think it would genuinely make complex values more readable and more 'natural' to express. My thinking is that (-:) is somewhat like a "unary minus for the complex part" (although it's a binary operator). Upon a little further thought, I would want only (+:) to be available for pattern matching. If the presence of a (-:) operator would upset the pattern matching, then I'd withdraw the suggestion in any case... Rob. |
|
From: Albert G. <Dr....@t-...> - 2007-06-27 16:00:46
|
Sorry for chiming in so late, I'm still trying to catch up on my email. Rob Hubbard wrote: > Upon a little further thought, I would want only (+:) to be available > for pattern matching. If the presence of a (-:) operator would upset > the pattern matching, then I'd withdraw the suggestion in any case... Unfortunately, with the current Wadler view system, you can't define alternative views like that. I.e., if you define a view which returns X+:Y and X-:Y for the two half-planes, then you'll also have to write rules matching against both. That's why I didn't include '-:' in the first place, in fact I had the same idea a while back. ;-) For more elaborate kinds of views, so-called value input would be needed which would allow you to pick a certain variation of a view in the lhs pattern. One such proposal can be found on the Haskell site. Also, a while back LtU mentioned an ICFP07 submission from the Microsoft FP team, which also discusses a generalized view mechanism (for F#, IIRC). I still have to take a closer look at that. I know that some of you guys are on this list, maybe you could comment on that? :) Considering the precedence of '+:' a.k.a. ':+', I can see that it would be convenient to have a higher priority for some uses, but wouldn't that confuse Haskell programmers where ':+' has the same precedence as '+'? After all the current representation was meant to be more or less compatible with Haskell. 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: John C. <co...@cc...> - 2007-06-27 16:19:41
|
Albert Graef scripsit: > Considering the precedence of '+:' a.k.a. ':+', I can see that it would > be convenient to have a higher priority for some uses, but wouldn't that > confuse Haskell programmers where ':+' has the same precedence as '+'? > After all the current representation was meant to be more or less > compatible with Haskell. I have mixed feelings about it. Scheme of course does not have infix operator priorities, but does allow complex constants of the form 3+4i, which is equivalent to (make-rectangular 3 4). So tight binding feels right to me. OTOH, Haskell compatibility is a strong argument; on the gripping hand, Haskell may simply have gotten this wrong, as C did with && and ||. -- Income tax, if I may be pardoned for saying so, John Cowan is a tax on income. --Lord Macnaghten (1901) co...@cc... |
|
From: Albert G. <Dr....@t-...> - 2007-06-27 23:04:34
|
John Cowan wrote: > I have mixed feelings about it. Scheme of course does not have infix > operator priorities, but does allow complex constants of the form 3+4i, > which is equivalent to (make-rectangular 3 4). So tight binding feels > right to me. OTOH, Haskell compatibility is a strong argument; on the > gripping hand, Haskell may simply have gotten this wrong, as C did with && > and ||. Well, I see a rationale behind this, as :+ really is an addition operator, so there is a case for treating it as such. 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: Rob H. <hub...@gm...> - 2007-06-28 10:19:52
|
Hello, On 28/06/07, Albert Graef <Dr....@t-...> wrote: > Well, I see a rationale behind this, as :+ really is an addition > operator, so there is a case for treating it as such. This is a rare occasion where I *strongly* disagree. The purpose of (+:) is to form complex numbers syntactically, when they are in some sense 'atomic' or 'literal' semantically. For (+:) to bind so weakly (i.e. as if it is an ordinary addition operator) makes its behaviour surprising. Python get this wrong, but only because it really does just use the ordinary + operator. Haskell certainly gets this wrong. Please don't let Q follow suit and also get this wrong. ==> 1+:2 * 3+:4 1+:10 // is wrong (and surprising) -5+:10 // is right Rob. |
|
From: Albert G. <Dr....@t-...> - 2007-06-29 01:58:24
|
Rob Hubbard wrote: > This is a rare occasion where I *strongly* disagree. The purpose of > (+:) is to form complex numbers syntactically, when they are in some > sense 'atomic' or 'literal' semantically. I see your point, but note that in common mathematical notation complex numbers aren't atomic either (unless you write them as pairs), so you face the same kind of problem. But let's assume, just for fun, that X+:Y really is atomic, how should foo 2 +: 3 be parsed? Or -2+:3 ? I think that it would be rather surprising if -2+:3 returned (-2)+:(-3). Note the parentheses; these would be obligatory if (+:) had, say, the same precedence as (.). I really think that 'X+:Y' should be seen as an abbreviation for 'X+i*Y' (in fact, that's just how it is implemented, but this doesn't count in this discussion). Consequently, '+:' should have the same precedence as '+', anything else is just awkward in subtler but equally annoying ways, as pointed out above. > ==> 1+:2 * 3+:4 > 1+:10 // is wrong (and surprising) I have no problem with that if I read '1+:2*3+:4' as '1+i*2*3+i*4'. BTW, this apparent weirdness is somewhat mitigated in Haskell because Haskell's ':+' is non-associative (which makes sense in Haskell since ':+' only takes Real operands there). But why should we arbitrarily limit the scope of Q's '+:' when it can be applied to complex operands just as easily? Besides, this also makes '+:' work exactly analogous to exact division '%' which is a Good Thing, IMHO. 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: Rob H. <hub...@gm...> - 2007-06-29 08:23:39
|
Hello Albert, On 29/06/07, Albert Graef <Dr....@t-...> wrote: > But let's assume, just for fun, that X+:Y really is atomic, how should > foo 2 +: 3 be parsed? Or -2+:3 ? I think that it would be rather > surprising if -2+:3 returned (-2)+:(-3). Note the parentheses; these > would be obligatory if (+:) had, say, the same precedence as (.). Ah, yes. That's a good point. Okay, (+:) at the precedence of (+) it is then. Thanks, Rob. |
|
From: Albert G. <Dr....@t-...> - 2007-06-29 19:46:43
|
Rob Hubbard wrote: > Okay, (+:) at the precedence of (+) it is then. Ok, I'm happy that we agree on this now. A precedence system is almost always a compromise, and I agree that Q's is not perfect either. Actually I've mostly adopted it from Pascal, because I just can't remember the precedence of all C operators for more than five minutes. ;-) 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: Keith T. <kaz...@ea...> - 2007-06-01 00:42:40
|
--- John Cowan <co...@cc...> scripsit: - What about "+*", then? The colon is only relevant because of - a rule of Haskell lexical syntax that does not apply to Q. Then why not '+i' (as in X+iY)? I understand about the colon; can the Q interpreter parse '+i' as intended? In any event, Albert has already implemented '+:'. =) Cheers, Keith |
|
From: Albert G. <Dr....@t-...> - 2007-06-01 01:13:03
|
Keith Trenton wrote: > Then why not '+i' (as in X+iY)? I understand about the colon; can the Q interpreter parse '+i' as intended? Nope. It's either punctuation or an identifier, but not both. -- 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: Keith T. <kaz...@ea...> - 2007-06-28 11:00:46
|
Hello All -- --- Rob Hubbard <hub...@gm...> writes: - The purpose of (+:) is to form complex numbers syntactically, - when they are in some sense 'atomic' or 'literal' semantically. I'm with Rob on this one: '+:' is not simply another way of saying '+'. It should always do the right thing wrt. PoLS (Principle of Least Surprise). --- Rob Hubbard <hub...@gm...> writes: - Python get this wrong...Haskell certainly gets this wrong. - Please don't let Q follow suit and also get this wrong. *** AND *** --- John Cowan <co...@cc...> writes: - Haskell may simply have gotten this wrong, as C did with && and ||. If compatibility with Haskell (i.e., low precedence) leads to incorrect results (i.e., *surprise*), then let's not be compatible. Let's add an explanation to the manual that warns Haskell programmers to expect to "get their sums right with Q". ;-) Cheers, Keith |
|
From: <ed...@ri...> - 2007-06-28 18:06:26
|
<p><br /> This seams to be the same argument as the -1 thingy. Do we want -=
1 to mean - is an operator and 1 is a number or -1 to be an integer? Is 1+:=
2 a complex number or is 1+:2 and operator to create a complex number from =
reals 1 and 2? Too bad white space isn't significant because, then you coul=
d have the best of both worlds - 1 (with space) as a unary minus and -1 wit=
h no space as an integer; 1 +: 2 (with space) as a constructor for a comple=
x number and 1+:2 as complex number.</p><p>1+:2 * 3+:4 =3D=3D> 11+:2</p>=
<p>1 +: 2 * 3 +: 4 =3D=3D> 1+:10</p>I wish I new more about PL theory.<p=
> Eddie<br /><br /><br /><strong>On Wed Jun 27 18:15 , Albert Graef s=
ent:<br /><br /></strong><blockquote style=3D"border-left: 2px solid rgb(24=
5, 245, 245); margin-left: 5px; margin-right: 0px; padding-left: 5px; paddi=
ng-right: 0px;">John Cowan wrote:<br />=0D
> I have mixed feelings about it. Scheme of course does not have infix<=
br />=0D
> operator priorities, but does allow complex constants of the form 3+4i=
,<br />=0D
> which is equivalent to (make-rectangular 3 4). So tight binding feels=
<br />=0D
> right to me. OTOH, Haskell compatibility is a strong argument; on the=
<br />=0D
> gripping hand, Haskell may simply have gotten this wrong, as C did wit=
h &&<br />=0D
> and ||.<br />=0D
<br />=0D
Well, I see a rationale behind this, as :+ really is an addition<br />=0D
operator, so there is a case for treating it as such.<br />=0D
<br />=0D
Albert<br />=0D
<br />=0D
-- <br />=0D
Dr. Albert Gr"af<br />=0D
Dept. of Music-Informatics, University of Mainz, Germany<br />=0D
Email: <a href=3D"javascript:top.opencompose('Dr....@t-...','','',=
'')">Dr....@t-...</a>, <a href=3D"javascript:top.opencompose('ag@mu=
wiinfa.geschichte.uni-mainz.de','','','')">ag...@mu...schichte.uni-mainz=
.de</a><br />=0D
WWW: <a target=3D"_blank" href=3D"../parse.pl?redirect=3Dhttp%3A%2F%2Fww=
w.musikinformatik.uni-mainz.de%2Fag">http://www.musikinformatik.uni-mainz.d=
e/ag</a><br />=0D
<br />=0D
-------------------------------------------------------------------------<b=
r />=0D
This SF.net email is sponsored by DB2 Express<br />=0D
Download DB2 Express C - the FREE version of DB2 express and take<br />=0D
control of your XML. No limits. Just data. Click to get it now.<br />=0D
<a target=3D"_blank" href=3D"../parse.pl?redirect=3Dhttp%3A%2F%2Fsourceforg=
e.net%2Fpowerbar%2Fdb2%2F">http://sourceforge.net/powerbar/db2/</a><br />=
=0D
_______________________________________________<br />=0D
q-lang-users mailing list<br />=0D
<a href=3D"javascript:top.opencompose('q-l...@li...',=
'','','')">q-l...@li...</a><br />=0D
<a target=3D"_blank" href=3D"../parse.pl?redirect=3Dhttps%3A%2F%2Flists.sou=
rceforge.net%2Flists%2Flistinfo%2Fq-lang-users">https://lists.sourceforge.n=
et/lists/listinfo/q-lang-users</a><br />=0D
</blockquote>=0D
</p><BR>=
|
|
From: Keith T. <kaz...@ea...> - 2007-06-29 07:16:16
|
--- Albert Graef <Dr....@t-...> writes: - ...'X+:Y' should be seen as an abbreviation for 'X+i*Y'... - - Why should we arbitrarily limit the scope of Q's '+:' - when it can be applied to complex operands just as easily? Okay. I understand you *much* better now, and will abandon my objection. However, is there an explanation, implementation note, or a warning that should be added to the manual so that programmers (from all backgrounds) can be confident when using '+:' (i.e., prevent unexpected math errors)? Cheers, Keith |
×
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