fastest way to turn the string s to its value is

". s

You may get an error if it's ill-formatted.

Henry Rich 

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Amelia Stein
> Sent: Sunday, April 15, 2007 1:44 PM
> To: Programming forum
> Subject: Re: [Jprogramming] J script files
> 
> So how do you actually "scan" in a number from standard 
> input?  What is the
> syntax? Whether or not it is of good form in J, I have a 
> presentation to do
> tomorrow where I need input from the keyboard.
> 
> On 4/15/07, Devon McCormick <[EMAIL PROTECTED]> wrote:
> >
> > Randy -
> >
> > I think it's a mis-characterization to say that J "isn't 
> meant for user
> > input".
> > In fact, due to its interpretive nature, J handles user 
> input beautifully
> > compared
> > to any conventional language, if you use the language 
> itself.  Of course,
> > as
> > an avid APLer, I'm sure this isn't news to you.
> >
> > But this prompt-based notion won't die, no matter how crippled it is
> > compared
> > to simply using native J.  Take, for instance, the outline 
> of the program
> > that
> > Amelia is writing: allow someone to enter some numbers, 
> then return some
> > descriptive statistics about them.  Using J, I would naturally do
> > something
> > like
> >
> >    (<./,>./,mean,stddev) 97.1 4.7 33 1.3 22 60 27.6 96.4 87.1 67.5
> > 1.3 97.1 49.67 36.744585
> >
> > However, as Amelia's professor has constrained the problem, 
> the "correct"
> > session might look more like this:
> >
> > Enter some numbers: 97.1 4.7 33 1.3 22 60 27.6 96.4 87.1 67.5
> > ** Error: can only accept 5 numbers.
> > Enter some numbers: 97.1 4.7 33 1.3 22
> > The minimum is 1.3.
> > The maximum is 97.1.
> > The mean is 31.62.
> > The standard deviation is 38.813876.
> >
> > or some such limited, simplistic implementation.  Notice 
> how thoroughly
> > inadequate this prompt-based paradigm is for getting any 
> serious work
> > done:
> > it's probably constrained to some fixed number of entries 
> or necessitates
> > added complexity to acommodate a variable number of 
> entries.  Furthermore,
> > an input mistake can only be corrected by re-typing the 
> entire set of
> > entries
> > and the result can only be used by manually transferring it.
> >
> > (Of course, using a spreadsheet may also be a good way to 
> handle a problem
> > like this.)
> >
> > This prompt+manual input notion is a lousy paradigm that is 
> encumbered by
> > widely-accepted, unnecessary limitations of the past 50 
> years.  Today, we
> > have
> > scalpels and laser beams but most people still insist on 
> using sticks and
> > rocks.
> >
> > However true all this all is, the problem of user input 
> seems to be a
> > recurring one in J.
> > Those of us who use the language a lot have solved it for 
> ourselves but it
> > recurs
> > regularly for beginners.  We've talked about this a bit in 
> the NYCJUG and
> > the
> > consensus seems to be 1) use file-based input, or 2) use a 
> spreadsheet
> > front-end.
> >
> > One other idea is to use the GUI-building capabilities of some other
> > language,
> > like Java or VB, and
> > interface the resulting GUI with J.  Until get something like
> > this fully fleshed out on the Wiki, we may have to make do 
> by referring
> > people to
> > the character-based solutions for Amelie that came out of 
> this thread.
> >
> > Devon
> >
> > On 4/15/07, ramacd <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >
> > > Dan Bron wrote:
> > > > This is easy to see if we take a reductionist approach: 
> a single J
> > > > token is either a built-in J primitive, or it's a 
> user-defined name
> > > > with an arbitrary definition. Primitives never change 
> their definition
> > > > (good thing!). And the dictionary of J explicitly states, at
> > > > http://www.jsoftware.com/help/dictionary/dict2.htm that:
> > > Primitives don't change their definition over a single 
> version of  J,
> > > that is true.  Over multiple versions it is a different 
> story. In fact,
> > > I long ago coined a term ("getting henked") for the suffering one
> > > undergoes when one assumes upward compatibility.
> > >
> > > On the original idea of this thread, having a REPL facility, which
> > > doesn't come in primitive-only J, doesn't strike me as a 
> stretch of its
> > > capabilities. I do wonder at the (if you want a 
> responsive computer,
> > > don't let a user near J) attitude, and where it comes 
> from. Amelia's
> > > note that J "isn't meant for user input." crystallizes a 
> big misgiving I
> > > have about J, even though I have been pro-J since J has 
> been around.
> > >
> > > >: ...
> > >
> > > 
> ----------------------------------------------------------------------
> > > For information about J forums see 
> http://www.jsoftware.com/forums.htm
> > >
> >
> >
> >
> > --
> > Devon McCormick, CFA
> > ^me^ at acm.
> > org is my
> > preferred e-mail
> > 
> ----------------------------------------------------------------------
> > For information about J forums see 
> http://www.jsoftware.com/forums.htm
> >
> ----------------------------------------------------------------------
> For information about J forums see 
> http://www.jsoftware.com/forums.htm

----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to