You started with
4 * 3 + 2 * 3 - 1
28
not happy with the result expecting
12+ 6-1
17
You could rethink
First rewrite this
4 2 * 3 3
12 6
Getting close so add these two together
+/4 2 * 3 3
18
Now get the minus in you could add _1 to the result like this
_1++/4 2 * 3 3
17
or use ~ to turn the operation around
1-~+/4 2 * 3 3
17
This is not too hard is it?
The step over to
1-~4 2+/ . * 3 3
17
is then easy
2006/3/23, p j <[EMAIL PROTECTED]>:
>
> Thanks for engaging, and thanks for thinking about it.
>
> While a great deal of sentences that use parentheses
> could be rewritten and reordered not to, we often
> think out a solution in a certain order of operation,
> and parentheses lets us implement the order we
> considered most natural. Unless you are arguing that
> parentheses should be removed from the language, then
> a clearer way to group parameters, if it exists is a
> good thing too.
>
> if
> 1-~4 2+/ . * 3 3
> is equivalent to the 5-level parenthesis expression I
> used as an example doesn't change the fact that it
> would require reflection from experts to produce the
> equivalent form, and deleting one parenthesis and
> adding another, probably requires the above expression
> completely from scratch changing the number of
> operators.
> While on the topic, it would be nice if the . operator
> on the vocabulary page offered a mini refresher course
> in matrix algebra
>
> In addition to clearer intent, and easier reading
> writing and editing of code, as justification for a
> more flexible parentheses system, I do feel that a
> common mistake I and others used to other parsing
> orders, and used to writting equality tests one way,
> consistently make:
> if. 2|x = 0 do. f end.
> while easily fixed by wording the sentence as if.
> 0=2|x do. f end., doesn't change the fact that the
> code comes out of my head the first way... and when I
> eventually catch the error, will end up looking like
> (2|x) = 0.
> I don't think the space character is hard to parse.
> multiple spaces will not have any impact. Even the
> "crazy people" using proportional fonts can make them
> out between tokens. A space between all tokens and no
> space between any tokens will parse to the same
> sentence.
> I'll come up with a translator function in a couple of
> days. It doesn't look complicated, but I'm learning
> sequential machines first, because that might simplify
> implementing the solution further.
>
> --- Devon McCormick <[EMAIL PROTECTED]> wrote:
>
> > Though I initially mis-interpreted this thread as an
> > argument for a
> > throwback
> > to order-of-operation parsing, now that I better
> > understand it, I remain
> > unconvinced
> > this proposal's usefulness outweighs its
> > complication.
> >
> > Consider that the original example would be better
> > written in a more J-like
> > fashion, without parens, like this:
> >
> > 1-~4 2+/ . * 3 3
> >
> > (assuming the two "3"s only accidently have the same
> > value and avoiding the
> > special decrement function "<:" on the same
> > assumption for "1".)
> >
> > It's hard to abstract from one simple, scalar,
> > example like
> > this to understand the advantage of changing the
> > parsing order,
> > especially one which places such heavy syntactic
> > lifting on
> > an invisible character.
> >
> > This reminds me of a lecture on C++ by Bjarne
> > Stroustrup I attended a few
> > years ago.
> > I ran into a friend from the APL community there and
> > we sat next to each
> > other. Bjarne
> > began talking about the advantages of overloading
> > certain symbols. When he
> > started
> > showing examples where he was overloading the " "
> > (space) operator, my
> > friend and
> > I both looked at each other in amusement as we
> > simultaneously realized that
> > the
> > date was April 1st and Bjarne was having us on.
> >
> > But it's a little too early for that to be the case
> > here.
> >
> > Devon
> >
> > On 3/23/06, p j <[EMAIL PROTECTED]> wrote:
> > >
> > > I assume that was directed to me.
> > >
> > > Many of you will somehow ignore the next sentence,
> > or
> > > disbelieve my sincerity regarding it. I fully
> > > understand the reason and practicality for right
> > to
> > > left parsing in J, and have no desire to change
> > it.
> > >
> > > Having the ability to override the default parsing
> > > order is an undisputed good thing. Working with
> > > parens is usually a needlessly complicated way to
> > > override that parsing order. The proposal is to
> > allow
> > > the programmer to use a single token ' ' in
> > situations
> > > that currently require 2 matching '()'. Its hoped
> > > that the option makes code clearer and easier to
> > read
> > > write and edit.
> > >
> > ...
> > --
> > Devon McCormick
> > ^me^ at acm.
> > org is my
> > preferred e-mail
> >
> ----------------------------------------------------------------------
> > For information about J forums see
> > http://www.jsoftware.com/forums.htm
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
Björn Helgason, Verkfræðingur
Fugl&Fiskur ehf, Þerneyjarsund 23,
Skype: gosiminn, gsm: +3546985532
801 Grímsnes ,t-póst: [EMAIL PROTECTED]
http://groups.google.com/group/J-Programming
Tæknikunnátta höndlar hið flókna, sköpunargáfa er meistari einfaldleikans
góður kennari getur stigið á tær án þess að glansinn fari af skónum
/|_ .-----------------------------------.
,' .\ / | Með léttri lund verður |
,--' _,' | Dagurinn í dag |
/ / | Enn betri en gærdagurinn |
( -. | `-----------------------------------'
| ) |
(`-. '--.)
`. )----'
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
