Re: [Jgeneral] spreadsheets
You are talking about user macros here.
Yes, the macros are meant to mimic just
use actions, like keystroke commands and
menu selections.
But Excel, which uses an OOP approach,
already operates the Object Model, where you
can say Sheet(1).Range("A1:B2").
Although some macros were useful and kept
in Excel 4.0 compatibility. AFIR, since you dont
have to program in the IDE, but can put a macro
expression right in the cell.
- Original Message
From: dly <[EMAIL PROTECTED]>
To: General forum
Sent: Friday, June 16, 2006 7:21:14 AM
Subject: Re: [Jgeneral] spreadsheets
In general, you can put expressions in cells of spreadsheets which
direct there results to other cell ranges. You can put script-like
code in cells that don't get displayed in the viewing section. The
spreadsheet can actually be much like a workspace in many respects.
In my first Lotus123 application I was using (if I recall) a {left}
{left}{left}... command to move the cursor around the spreadsheet.
(Used APL to read budget data into a worksheet and have Budget
managers update etc--directing them to input fields.) Being dyslexic
I initially used {left}{left}{left}... when I meant {right}{right}
{right}...in those days you couldn't just say move left 20 cells.
Worth looking into? I hope you have other options.
Donna
[EMAIL PROTECTED]
On 10-Jun-06, at 8:40 PM, Randy MacDonald wrote:
> This ability to express array constants seems like a trivial
> extension of
> cell ranges. I don't see how the result of the expression can be an
> array.
> Does Excel display a cell with the formula '({1,2,3})' for example,
> or does
> something like "<>" show up in the cell?
>
> I've got the Open Office spreadsheet on my box someplace. Is _that_
> worth
> exploring, anyone?
--
For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
Well, then you need to get to the real problem of coordination. Once
there is more than 6 things (if I recall) to coordinate the overhead
is more than the gain--like having 100 developers be less productive
than 6.
Lots of variation in architecture trying to deal with thins difficult
mathematical universal limitation to no real avail.
But if you can get things to be independently productive, then you
have something.
Donna
[EMAIL PROTECTED]
On 16-Jun-06, at 10:51 AM, Randy MacDonald wrote:
Hello Donna;
Today's computers seem slower because they are more buggy. I
discount that
as being almost too obvious.
Is the sense of being slower in the same way the ground underneath
the plane
you're travelling in seems slower. Perhaps in the same way that
World Cup
matches seem slow. Is it that the context has expanded faster?
--
--
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| [EMAIL PROTECTED] |
|\ | |If you cannot describe what you are doing
BSc(Math) UNBF'83þas a process, you don't know what you're
doing.
Sapere Aude | - W. E. Deming
Natural Born APL'er | Demo website: http://156.34.64.225/
-(INTP)
{ gnat }-
- Original Message -
From: "dly" <[EMAIL PROTECTED]>
To: "General forum"
Sent: Friday, June 16, 2006 8:40 AM
Subject: Re: [Jgeneral] spreadsheets
On 10-Jun-06, at 8:47 PM, Randy MacDonald wrote:
I'd love to see examples of where today's computers seem slower
than those
of the 1970s. It's just not the impression I get.
A bug in the MS Window operating system was slowing down and crashing
a Web system used for realtime activation of cellular phones.
Investigated for four years before I came along and demonstrated that
MS OS was not doing proper garbage collection and memory management.
MS had kept blaming the application code (Visual Basic) which did
have performance problems of its own--mostly limitations of the
language.
Donna
[EMAIL PROTECTED]
-
-
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
Re: [Jgeneral] spreadsheets
Hello Donna;
Today's computers seem slower because they are more buggy. I discount that
as being almost too obvious.
Is the sense of being slower in the same way the ground underneath the plane
you're travelling in seems slower. Perhaps in the same way that World Cup
matches seem slow. Is it that the context has expanded faster?
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| [EMAIL PROTECTED] |
|\ | |If you cannot describe what you are doing
BSc(Math) UNBF'83þas a process, you don't know what you're doing.
Sapere Aude | - W. E. Deming
Natural Born APL'er | Demo website: http://156.34.64.225/
-(INTP){ gnat }-
- Original Message -
From: "dly" <[EMAIL PROTECTED]>
To: "General forum"
Sent: Friday, June 16, 2006 8:40 AM
Subject: Re: [Jgeneral] spreadsheets
>
>
>
> On 10-Jun-06, at 8:47 PM, Randy MacDonald wrote:
>
> > I'd love to see examples of where today's computers seem slower
> > than those
> > of the 1970s. It's just not the impression I get.
>
> A bug in the MS Window operating system was slowing down and crashing
> a Web system used for realtime activation of cellular phones.
> Investigated for four years before I came along and demonstrated that
> MS OS was not doing proper garbage collection and memory management.
> MS had kept blaming the application code (Visual Basic) which did
> have performance problems of its own--mostly limitations of the
> language.
>
> Donna
> [EMAIL PROTECTED]
>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
Hello Donna;
The only reason I have for looking at spreadsheets is to see what all the
fuss is about. I looked at them once, in the early 80's, when VisiCalc was
all there was, and didn't see much of note. Spreadtheets don't give me
anything desireable that APL/J doean't. I'm still wondering what all the
fuss is about. Maybe someone can tell me.
I am aware of expressions like:
range PUT expression
which I saw in earlier attempts at APL spreadsheets. They appeared to me to
be a negation of the advantage of spreadsheets, like the goto was
reintroduced where it had been eliminated.
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| [EMAIL PROTECTED] |
|\ | |If you cannot describe what you are doing
BSc(Math) UNBF'83þas a process, you don't know what you're doing.
Sapere Aude | - W. E. Deming
Natural Born APL'er | Demo website: http://156.34.64.225/
-(INTP){ gnat }-
- Original Message -
From: "dly" <[EMAIL PROTECTED]>
To: "General forum"
Sent: Friday, June 16, 2006 8:21 AM
Subject: Re: [Jgeneral] spreadsheets
> In general, you can put expressions in cells of spreadsheets which
> direct there results to other cell ranges. You can put script-like
> code in cells that don't get displayed in the viewing section. The
> spreadsheet can actually be much like a workspace in many respects.
>
> In my first Lotus123 application I was using (if I recall) a {left}
> {left}{left}... command to move the cursor around the spreadsheet.
> (Used APL to read budget data into a worksheet and have Budget
> managers update etc--directing them to input fields.) Being dyslexic
> I initially used {left}{left}{left}... when I meant {right}{right}
> {right}...in those days you couldn't just say move left 20 cells.
>
> Worth looking into? I hope you have other options.
>
> Donna
> [EMAIL PROTECTED]
>
>
>
> On 10-Jun-06, at 8:40 PM, Randy MacDonald wrote:
>
> > This ability to express array constants seems like a trivial
> > extension of
> > cell ranges. I don't see how the result of the expression can be an
> > array.
> > Does Excel display a cell with the formula '({1,2,3})' for example,
> > or does
> > something like "<>" show up in the cell?
> >
> > I've got the Open Office spreadsheet on my box someplace. Is _that_
> > worth
> > exploring, anyone?
>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
dly wrote: > Code management tools were so late to be implemented--like architects > living in hovels while they design other peoples palaces. I believe SCCS for the IBM System/370 dates back to the early 1970s, and was later ported to the PDP-11 running early versions of Unix. To me, this does not seem particularly late in the scheme of things, especially when many programmers at the time were managing source code with rubber bands and boxes. SCCS remained the state of the art, at least in the Unix world, until the mid-1980s, when RCS came along. Best wishes, John -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
dly wrote: > By the way--did anyone implement a Logos (Leslie Goldsmith et all) > environment for J or what do you use for code management? > > Code management tools were so late to be implemented--like architects > living in hovels while they design other peoples palaces. There is no Logos, nor any need for one. Instead, use any standard source code management system. For example, see Alex Rufon's pages on Subversion: http://www.jsoftware.com/jwiki/Subversion. -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
J (or any language) should be used to build tools for yourself and grab the best tools from anywhere for the task at hand--like editors or spreadsheets By the way--did anyone implement a Logos (Leslie Goldsmith et all) environment for J or what do you use for code management? Code management tools were so late to be implemented--like architects living in hovels while they design other peoples palaces. Donna [EMAIL PROTECTED] On 10-Jun-06, at 11:27 AM, Bill Harris wrote: With a spreadsheet, the numbers are in the foreground; with J, the functions seem to be. -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
On 10-Jun-06, at 8:47 PM, Randy MacDonald wrote: I'd love to see examples of where today's computers seem slower than those of the 1970s. It's just not the impression I get. A bug in the MS Window operating system was slowing down and crashing a Web system used for realtime activation of cellular phones. Investigated for four years before I came along and demonstrated that MS OS was not doing proper garbage collection and memory management. MS had kept blaming the application code (Visual Basic) which did have performance problems of its own--mostly limitations of the language. Donna [EMAIL PROTECTED] -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
In general, you can put expressions in cells of spreadsheets which
direct there results to other cell ranges. You can put script-like
code in cells that don't get displayed in the viewing section. The
spreadsheet can actually be much like a workspace in many respects.
In my first Lotus123 application I was using (if I recall) a {left}
{left}{left}... command to move the cursor around the spreadsheet.
(Used APL to read budget data into a worksheet and have Budget
managers update etc--directing them to input fields.) Being dyslexic
I initially used {left}{left}{left}... when I meant {right}{right}
{right}...in those days you couldn't just say move left 20 cells.
Worth looking into? I hope you have other options.
Donna
[EMAIL PROTECTED]
On 10-Jun-06, at 8:40 PM, Randy MacDonald wrote:
This ability to express array constants seems like a trivial
extension of
cell ranges. I don't see how the result of the expression can be an
array.
Does Excel display a cell with the formula '({1,2,3})' for example,
or does
something like "<>" show up in the cell?
I've got the Open Office spreadsheet on my box someplace. Is _that_
worth
exploring, anyone?
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
On 10-Jun-06, at 2:34 PM, Roy A. Crabtree wrote: Spreadsheets were for accounting, specific. As such, APL was never in the running. Not so. Up to 1987, the large insurance company I worked for did much of their accounting and financial planning in APL. Up until then, the Comptroller function had been filled by Actuaries. Then CA's (chartered accountants) took over (a glut in the CA firms I guess and CA's sought jobs in corporations). I was asked to convert all the accounting systems out of APL which the CA's deemed to be obsolete. I looked at other options. Eventual I contacted the accounting department at IBM--IBM ran the entire company in APL (many different versions). Through IPSharp I learned of many other companies running their company with APL accounting systems. After Reuters bought IPSharp and after Black Tuesday (and Morgan Stanley & their early APL stock trading system), the CA's swooped into Reuters and told them APL was obsolete. Eventually companies bought accounting systems like SAP etc. Database accounting systems were introduced and no-one realized that databases did not keep a proper accounting audit trail. Not being able to produce final results--spreadsheets were ubiquitous with lots of labor intensive, impossible to verify but very nicely formated financial statements. Hyperion came along trying to fill the gap with clumsy ways to handle arrays. I can only imagine the scenarios at Enron. One of my friends just left Reuters as they think this year they may be able to retire some APL systems they relied on--it merely took 20 years to develop the replacements. Donna [EMAIL PROTECTED] -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
On 10-Jun-06, at 1:54 PM, Björn Helgason wrote: The two dimensional case is the most important case for most people I certainly found this to be the case for Accountants. For engineers— 3. Philosophers— 4. Mathematicians— n. Here is the theory of some Physicists— 'Brane-Storm' Challenges Part of Big Bang Theory . . .the fifth dimension is all there, is out there, and embedded in it are multiple branes. http://www.space.com/scienceastronomy/astronomy/ bigbang_alternative_010413-2.html Donna [EMAIL PROTECTED] On 10-Jun-06, at 1:54 PM, Björn Helgason wrote: The two dimensional case is the most important case for most people -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While we're on the subject of language-enhanced spreadsheets, see http://siag.nu/siag/ Bill - -- Bill Harris http://facilitatedsystems.com/weblog/ Facilitated Systems Everett, WA 98208 USA http://facilitatedsystems.com/ phone: +1 425 337-5541 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (MingW32) Comment: For more information, see http://www.gnupg.org iD8DBQFEjH7g3J3HaQTDvd8RAotoAJ44/JxJcPAdLVBDTLueKaREYN91ZgCdGIQH UA8M4vV/furuuOBJITLNdq8= =dFr6 -END PGP SIGNATURE- -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
ALl true, usually; ad it does result in faster reslts. But does not truly address the 200,000 fold improvement we still do not see from 486/33 to P6/3GHz. Much less the 1e10 improvement inb SW we only see about 1e4 part of as yet. Though this may change, sea change comingh, I think. Now is the time for all good J to get on board, or we all may drown as the wave passeth by. On 6/11/06, Steven H. Rogers <[EMAIL PROTECTED]> wrote: Roy A. Crabtree wrote: > ... > I do not get the impression that today's _computers_ seem slower tha the > 70s. > > I do get the impression that today's _software_ _is_ slower. > Relatively, as well as in many to most cases absolutely. > > Do the math. ... Hardware speeds have improved and costs decreased dramatically. Software has become bloated and slow because the producers have been largely focused on providing more features that users want. An effective software strategy is: 1. make it work 2. make it beautiful 3. if necessary, make it faster. If you make the effort to clean up your working code, it will generally be more robust and efficient. Unfortunately, most projects get stuck at step 1, because there is always pressure for another feature. Moore's Law and faster clock speeds have provided a free ride that allowed developers to get away with this. Heat dissipation and I/O bottlenecks have begun to render this approach ineffective and more parallelism at the hardware level is beginning to appear. This may be an opportunity for J and friends. Steve -- Steven H. Rogers, Ph.D., [EMAIL PROTECTED] Weblog: http://shrogers.com/weblog "He who refuses to do arithmetic is doomed to talk nonsense." -- John McCarthy -- For information about J forums see http://www.jsoftware.com/forums.htm -- -- Roy A. Crabtree UNC '76 gaa.lifer#11086 Room 207 Studio Plus 123 East McCullough Drive Charlotte, NC 28262-3306 336-340-1304 (office/home/cell/vmail) 704-510-0108x7404 (voicemail residence) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.authorsden.com/royacrabtree http://skyscraper.fortunecity.com/activex/720/resume/full.doc -- (c) RAC/IP, ARE,PRO,PAST (Copyright) Roy Andrew Crabtree/In Perpetuity All Rights/Reserved Explicitly Public Reuse Only Profits Always Safe Traded -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
I love ya, Steve. On 6/11/06, Steven H. Rogers <[EMAIL PROTECTED]> wrote: dly wrote: > The strategy has always been to have machines make up for the > inefficiency of bad code--after all its easier to get machines to do > what you want them to do than the people who write bad code > Donna > [EMAIL PROTECTED] > Right, and the current management fashion is to offshore a lot of coding so that bad code can be produced more cheaply. Not that there aren't good arguments for doing work offshore, but in many cases they're solving the wrong problem. Steve -- Steven H. Rogers, Ph.D., [EMAIL PROTECTED] Weblog: http://shrogers.com/weblog "He who refuses to do arithmetic is doomed to talk nonsense." -- John McCarthy -- For information about J forums see http://www.jsoftware.com/forums.htm -- -- Roy A. Crabtree UNC '76 gaa.lifer#11086 Room 207 Studio Plus 123 East McCullough Drive Charlotte, NC 28262-3306 336-340-1304 (office/home/cell/vmail) 704-510-0108x7404 (voicemail residence) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.authorsden.com/royacrabtree http://skyscraper.fortunecity.com/activex/720/resume/full.doc -- (c) RAC/IP, ARE,PRO,PAST (Copyright) Roy Andrew Crabtree/In Perpetuity All Rights/Reserved Explicitly Public Reuse Only Profits Always Safe Traded -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
On 6/11/06, Don Guinn <[EMAIL PROTECTED]> wrote: Acceptable speed for interactive computing is psychological. A person Only if you define it that wayj. My points were on the basis fo actual functional capacity: this is not psychologically based. (Though the intet to FIND that is). TSO (on iBM ainfrme) used a dela y oop to _slow_down_ responses during lightly loaded times because user perceied that the system was _slow_ durig normal load times and would therein complain about slow perfomnce _all_the_time_ on th basis of encountering it _some_of_the_time_. My commets dealt with _all_ conditions, and perforce, to discuss SW/HW lack of meeting _uniform_ packing fractions _all_ of the time _had_ to deal with the peaks and valleys. My own _psychological_ condition is that I regard it with distaste when some computr (lawn, house, TV, product) company sells me schpui for too high a price and asked me to repay it every (so often), making me PAY for this "priilege" (of repeatedly repayig them for a SW idea now 3 decades old; or, like KOss, for the privilege of sseing their next new portable CD has no power cable stress elief, or that drains the underpowered two AA batterie faster for Everready) just fast enough so I do not have enough funds to do what I would rather do with them. While actually psychologically based, probably not what you intended to point at. Most companies these days, in the era of mass advertising, with definite semiotic cognitive (especially the ligtly trained or ineperienced or arrogant ones like PhDs, all of those who think they can NOT be so impacted) controlk aspects (buy when they tell you), tend to prefer the Microsoft approach: train your slave to buy on demand. Oversimplified and over-angst ridden, but about as best I can do on short notice. expects a certain level of performance which matches one's thought processes. Not too fast, not too slow. What people really want is consistent performance. What people are trained to want is what they then expect wil satisfy them: which is whatever they were trained to want. Bak in the 70s, Stanford participated in an AI program after ETAOIN SHRDLU in the field of medicine; on the topic of neurophysicians, The progrma used rudimentary analsis techniques to come up with a q&a pitter patter pattern to inimize session length and maximize prognosticative effectiveness. It was judged against a panel of ntionally eminent neurophysiologists. The program won. But the MDs involved recommended against the program, seekingh, on a psychological basis, to be given a more HUBLE program that would, instead of definitively STATING the most probably diagnosis, instead supplicatively ASK the imminent (Not a typo) doctors what they would RECOMMEND as the best diagnosis. They did not like to be bypassed as peers. In short they neede their go stroked to function. Result: It is now nigh 30 years later, an the organization of advanced prognosticative data is not only not done and on the shelf, the more importnt process of (a) using it to heal patients, (b) using it to train new neuros (not a typo) to learn to diagnose by reasoning WITHOUT it, (c) preparing and adoting a medicie wide systematic approach to actually capturing NEW such data and reducig it to universal availability for practie, daya to day, yer to year ongoing: is not only not done, it i now being co-opted for another round of decades of profit from the new thieves of Mankind's knowledge. I watched a friend of mine who had given me all kinds of grief on the horrible performance of TSO because it sometimes took 20 seconds to edit a file, but normally just a few seconds. He brought a 4300 down from our See the above. New York office to demonstrate APL. He stood there smiling, happy as could be, while it took almost a minute to load his workspace. Several things. Something he could see was happening. The tape was spinning. It always took that long to load a workspace. He was in control of the situation. Psycho control. Plese note you bypassed all the TSO steps. Valid observations; just not the topic I was addressing. Many PC owner PReFEr a PC they can rebot, which in turn, when reporting _reliability_ ..they wll conveniently "forget" to accurately report. Typical, normal: expecially when the user wants the for the PC over central control spending it (and hacing the centrl resource wrk more cost effectively). I too got that sinking feeling when occasionally on our TSO system I pressed the enter key and nothing happened for a few seconds. Did the system go down and I just lost the last hour of work? WHich was why IBM aded the delay loop to _uniformly_ delay response. As well as the special privileges falgs to allow the "privileged" user accounts to BYPASS it. Thus was born the concept of computer aristocracy ... CDC, on one of their time sharing systems, had an interesting parameter. It was a delay in sending back the results o
Re: [Jgeneral] spreadsheets
If you are making software for yourself and make sure you are lazy so that
you are not typing more than you need eventually you can give it to others
and it works there too
Too many people just produce something for others and it never gets even to
stage 1.
If you think of yourself as the customer and do not lets others have it
until it has reached stage 3.5 a long time ago then you are a real J
programmer
2006/6/11, Steven H. Rogers <[EMAIL PROTECTED]>:
1. make it work
2. make it beautiful
3. if necessary, make it faster.
--
Björn Helgason, Verkfræðingur
Fugl&Fiskur ehf, Þerneyjarsund 23,
Skype: gosiminn, gsm: +3546985532
801 Grímsnes ,t-póst: [EMAIL PROTECTED]
Landslags og skrúðgarðagerð, gröfuþjónusta
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
Re: [Jgeneral] spreadsheets
Roy A. Crabtree wrote: ... I do not get the impression that today's _computers_ seem slower tha the 70s. I do get the impression that today's _software_ _is_ slower. Relatively, as well as in many to most cases absolutely. Do the math. ... Hardware speeds have improved and costs decreased dramatically. Software has become bloated and slow because the producers have been largely focused on providing more features that users want. An effective software strategy is: 1. make it work 2. make it beautiful 3. if necessary, make it faster. If you make the effort to clean up your working code, it will generally be more robust and efficient. Unfortunately, most projects get stuck at step 1, because there is always pressure for another feature. Moore's Law and faster clock speeds have provided a free ride that allowed developers to get away with this. Heat dissipation and I/O bottlenecks have begun to render this approach ineffective and more parallelism at the hardware level is beginning to appear. This may be an opportunity for J and friends. Steve -- Steven H. Rogers, Ph.D., [EMAIL PROTECTED] Weblog: http://shrogers.com/weblog "He who refuses to do arithmetic is doomed to talk nonsense." -- John McCarthy -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
dly wrote: The strategy has always been to have machines make up for the inefficiency of bad code--after all its easier to get machines to do what you want them to do than the people who write bad code Donna [EMAIL PROTECTED] Right, and the current management fashion is to offshore a lot of coding so that bad code can be produced more cheaply. Not that there aren't good arguments for doing work offshore, but in many cases they're solving the wrong problem. Steve -- Steven H. Rogers, Ph.D., [EMAIL PROTECTED] Weblog: http://shrogers.com/weblog "He who refuses to do arithmetic is doomed to talk nonsense." -- John McCarthy -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
Acceptable speed for interactive computing is psychological. A person expects a certain level of performance which matches one's thought processes. Not too fast, not too slow. What people really want is consistent performance. I watched a friend of mine who had given me all kinds of grief on the horrible performance of TSO because it sometimes took 20 seconds to edit a file, but normally just a few seconds. He brought a 4300 down from our New York office to demonstrate APL. He stood there smiling, happy as could be, while it took almost a minute to load his workspace. Several things. Something he could see was happening. The tape was spinning. It always took that long to load a workspace. He was in control of the situation. I too got that sinking feeling when occasionally on our TSO system I pressed the enter key and nothing happened for a few seconds. Did the system go down and I just lost the last hour of work? CDC, on one of their time sharing systems, had an interesting parameter. It was a delay in sending back the results of an interactive request. If the calculations were completed in less time than this delay the response was held until that time interval was met. Therefore, performance was consistent even though the load on the processor varied tremendously. Wordstar under DOS took about 5 to 10 seconds to load a document. As we have moved through word processors to the present it has always taken about this amount of time. Much slower people get impatient. Much faster and there's not time for a quick sip of coffee and a chance to compose one's self for the task at hand. If I had my way, software developers would have to use the smallest configuration on which their product was supposed to run to test and demonstrate their applications. If the latest version or Windows or whatever is supposed to run on a 256M one GH processor then Bill ought to use that size PC hooked to his big screen when he demonstrates it to the world. And, before he shows it off, maybe he ought to put on all the applications we don't use but must have like virusware, spyware and all the other cute stuff that seems to come with PCs for "free". Our PCs are like refrigerators. No matter how big they are they are always full and there is unidentifiable green stuff at the back we couldn't find for months. Randy MacDonald wrote: Hello J.R.; I'd love to see examples of where today's computers seem slower than those of the 1970s. It's just not the impression I get. -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
I like this new Google spreadsheet
It is interesting that I could share my spreadsheets with others if I want
I uploaded a few spreadsheets and I note that Google is using Unicode and
the translation of the spreadsheets I uploaded creates a lot of unreadable
signs
We have a lot of translations left to do with our old documents
I investigated what is being produced with J504 as well as with J601 and it
is a good thing J is coming out with Unicode support otherwise I would have
had no idea what I am looking at
- J504
a=.'L??:'
a. i. a
76 63 63 58
b=.'Lóð:'
a. i. b
76 243 240 58
c=.'Lóð:'
a. i. c
76 243 240 58
J601
a=.'L��:'
a. i. a
76 239 191 189 239 191 189 58
a
L��:
b=.'Lóð:'
a. i. b
76 195 179 195 176 58
c=.'Lóð:'
c=.'Lóð:'
a. i. c
76 195 179 195 176 58
I can write in the correct Unicodes from the keyboard but the uploaded
translated signs are garbage
I am going to use J601 to do the translation of the files before uploading
Google does not seem to have a replace function yet
Even at this early stage I like it more than the M$ spreadsheets already
Will be interesting to see how J will communicate with this web spreadsheet
--
Björn Helgason, Verkfræðingur
Fugl&Fiskur ehf, Þerneyjarsund 23,
Skype: gosiminn, gsm: +3546985532
801 Grímsnes ,t-póst: [EMAIL PROTECTED]
Landslags og skrúðgarðagerð, gröfuþjónusta
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
Re: [Jgeneral] spreadsheets
The results of array function fill a range of cells.
They are special, because they are not scalar,
i.e. the result is inseperable as a whole.
According to Calc documentation, they have the array finctions
See done in Excel, but should be compatible
http://www.jsoftware.com/jwiki/OlegKobchenko/Array_Spreadsheet
- Original Message
From: Randy MacDonald <[EMAIL PROTECTED]>
To: General forum
Sent: Saturday, June 10, 2006 8:40:18 PM
Subject: Re: [Jgeneral] spreadsheets
Hello Stuart;
This ability to express array constants seems like a trivial extension of
cell ranges. I don't see how the result of the expression can be an array.
Does Excel display a cell with the formula '({1,2,3})' for example, or does
something like "<>" show up in the cell?
I've got the Open Office spreadsheet on my box someplace. Is _that_ worth
exploring, anyone?
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| [EMAIL PROTECTED] |
|\ | |If you cannot describe what you are doing
BSc(Math) UNBF'83þas a process, you don't know what you're doing.
Sapere Aude | - W. E. Deming
Natural Born APL'er | Demo website: http://156.34.89.50/
-(INTP){ gnat }-
- Original Message -
From: "Stuart Bruff" <[EMAIL PROTECTED]>
To: "'General forum'"
Sent: Saturday, June 10, 2006 6:53 PM
Subject: RE: [Jgeneral] spreadsheets
Not all spreadsheet applications limit their results to scalars. Excel, at
least, has array entities. I quote, hopefully without treading on anybody's
copyright toes, from the help:
A basic, single-value formula produces a single result from one or more
arguments or values; you can enter either a reference to a cell that
contains a
value or the value itself. In an array formula, where you might usually use
a
reference to a range of cells, you can instead type the array of values
contained within the cells. The array of values you type is called an array
constant and generally is used when you do not want to enter each value into
a
separate cell on the worksheet. To create an array constant, you must do the
following:
· Enter the values directly into the formula, enclosed in braces ( { } )
· Separate values in different columns with commas (,)
· Separate values in different rows with semicolons (;)
For example, you can enter {10,20,30,40} in an array formula instead of
entering
10, 20, 30, 40 in four cells in one row. This array constant is known as a
1-by-4 array and is equivalent to a 1-row-by-4-column reference. To
represent
the values 10, 20, 30, 40 in one row and 50, 60, 70, 80 in the row
immediately
below, you would enter a 2-by-4 array constant: {10,20,30,40;50,60,70,80}.
As with many things, users start off with the 'simple' cases, but can find
it
frustrating when they gain more experience and hit problems that require
more
complex results. Perhaps a J-based spreadsheet could offer an interesting
migration path for such people?
Stuart
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
Behalf Of Randy MacDonald
Sent: 10 June 2006 5:14 PM
To: General forum
Subject: Re: [Jgeneral] spreadsheets
Hello Donna;
I've noticed this with my experience with APL spreadsheets: because the
possible
result from an APL/J expression can be any valid APL/J object, it is not so
clear where the result goes. Spreadsheets, with an expression system that
can
return only scalars, "put the result here" is obvious and trivial. If you do
limit the possible APL/J expressions to only the ones that return scalars,
you
severely limit the language. This was a showstopper for me.
Perhaps if spreadsheet cells could contain arbitrary arrays...
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| [EMAIL PROTECTED] |
|\ | |If you cannot describe what you are doing
BSc(Math) UNBF'83þas a process, you don't know what you're doing.
Sapere Aude | - W. E. Deming
Natural Born APL'er | Demo website: http://156.34.89.50/
---------(INTP)----{ gnat }-
- Original Message -
From: "dly" <[EMAIL PROTECTED]>
To: "General forum"
Sent: Saturday, June 10, 2006 12:31 PM
Subject: Re: [Jgeneral] spreadsheets
> what is needed is a spreadsheet where j or apl can be invoked in each
> cell and that could be added to an existing spreadsheet as an option
> if there is any open code spreadsheet application Donna
> [EMAIL PROTECTED]
>
>
>
> On 10-Jun-06, at 11:27 AM, Bill Harris wrote:
>
> >
Re: [Jgeneral] spreadsheets
itional support bands (think of a crossing form pattern) could
then be use either at original design
time (to reduce sway: loss of 1/3rd building weight would make it more
mobile) or later as a retrofit
to icrase buildig suppport.
And, if you have movalbe floor as a design CONCEPT, then increased
hardiness in the STAYS that
would be used to HLD the floors would have come up: allowing for
periodic etra durable
stays to be used.
In short, the progressive collapse might not have occured.
Even if all these are correct and workable (they may not be, or may nnot
provide the benefits I am suggesting)
I AM NOT criticizing the original team (the design was brilliat for its time
and the amount of time and
resouces they wee given).
But; I _am_ critiquing later genertions for not using more modern materials
technology to _fix_ the problembefore a collapse occurred.
(PLEASE do not tell me it could not be anticipated).
Similar things are true in the cuomputer world using analogies to carry the
concepts.
_THis_ is the problem facig technologists: failure to use and teach what we
lready have to solve existing problems
before NEW ones (like Katrina/New Orleans: known for 120 years by report to
Congress) overwhelm us as a civilization.
It can be done, but you really have to open up your head/hear/soul space to
do it.
The first step IMOHO, is to admit internlly and recognie where _you_ see
_you_ have been an idiot.
(Not by my standards or measures: your own).
Then: fix thar first. It is (sigh, painfully, first person) a lifelong
painful process at times.
But it can also be fun. If you work at it corectly.
The USA has done a very poor job over the lat 50 years of that. We need to
shift gears. Carefully. NOW.
TYime is always crtical.
CHeers. More later.
Thumbs up to Jsoft.
If you ar satisfied, fine.
But me, I do get tired of waiting 3-15 seconds ofor Win/XP to upll up the
d-mned- drop up menu
On 6/10/06, Randy MacDonald <[EMAIL PROTECTED]> wrote:
>
> Hello Roy;
>
> No low expectations here! I've been happy with APL's performance since
> 1991.
> Sure, APL/J is slower, but it's no longer easy to notice.
>
>
>
> |\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
> |/\| [EMAIL PROTECTED] |
> |\ | |If you cannot describe what you are doing
> BSc(Math) UNBF'83þas a process, you don't know what you're
> doing.
> Sapere Aude | - W. E. Deming
> Natural Born APL'er | Demo website: http://156.34.89.50/
> -(INTP){ gnat }-
>
>
> - Original Message -----
> From: "Roy A. Crabtree" <[EMAIL PROTECTED]>
> To: "General forum" < [email protected]>
> Sent: Saturday, June 10, 2006 11:02 PM
> Subject: Re: [Jgeneral] spreadsheets
>
>
> Wow. Perhaps your expectations over the years hve been istortd by
> repeated
> disappontment;
> leading to the _expectation_ of paying a $$$ and getting a fraction
> back.
>
> On 6/10/06, Randy MacDonald <[EMAIL PROTECTED]> wrote:
> >
> > Hello J.R.;
> >
> > I'd love to see examples of where today's computers seem slower than
> those
> > of the 1970s. It's just not the impression I get.
>
>
>
> I do not get the impression that today's _computers_ seem slower tha the
> 70s.
>
> I do get the impression that today's _software_ _is_ slower.
> Relatively, as well as in many to most cases absolutely.
>
> Do the math. I leave out networking, graphics, 2ndary storage, etc;
> just an
> oversimpified firrst cut anaysis;
> please note that the computer I am citing is in fact NOT 70s but late
> 80s; I
> have to do this to even begin
> to demonstrate how far the difference actually is:
>
> 486 (32bit/32bit) DX 33MHz with 256KB cache at 20nsec using 64B RAM at
> 120
> to 150 nsec
> P6 (64bit/32bit) 3072MHz 4096 KB cache at 2 nsec using 1024 MB DDR at 15
>
> nsec (roughly).
>
> P6/486: .realtive rchitectue comparison, leave it 1:1
> 32:64bit: 2:1
> 32/32: 1:1
> 33/3072: 93:1
> 256/4096: 16:1
> 2:20: 10:1
> 1024/64: 16:1 (but main memory on a WIndows box seems to need 4GB for
> mutitasking and graphics to work well): 64:1
> RAM/DDR: Should be thunk width ratio, lets leave it at 1:1
> 15/150: 10:1
> You do not like my ratios or figures? Use(r) your own.
>
> HW: 1 x 2 x 1 x 93(100) x 16 x 10 x 16/64 x 1 x 10 == 51200/204800
>
> You want to argue agais the other throughput metrics? Feel free.
>
> Yah, your rough hardware throughput power envelope, comptationally, is
> 50,000 to 200,000 times more than the la
Re: [Jgeneral] spreadsheets
Actually, is _faster_. In most ways; one of the points of brilliance in
its design and designers.
I do not expect the world's foremost optimizing incremental compiler (but I
almost get it,
simply because _clean_code_ is so rare that it performs almost the same
interpreted
as dirty language implementations and programs do comled with an optimizer).
Thumbs up to Jsoft.
If you ar satisfied, fine.
But me, I do get tired of waiting 3-15 seconds ofor Win/XP to upll up the
d-mned- drop up menu
On 6/10/06, Randy MacDonald <[EMAIL PROTECTED]> wrote:
Hello Roy;
No low expectations here! I've been happy with APL's performance since
1991.
Sure, APL/J is slower, but it's no longer easy to notice.
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| [EMAIL PROTECTED] |
|\ | |If you cannot describe what you are doing
BSc(Math) UNBF'83þas a process, you don't know what you're doing.
Sapere Aude | - W. E. Deming
Natural Born APL'er | Demo website: http://156.34.89.50/
-(INTP){ gnat }-
- Original Message -
From: "Roy A. Crabtree" <[EMAIL PROTECTED]>
To: "General forum"
Sent: Saturday, June 10, 2006 11:02 PM
Subject: Re: [Jgeneral] spreadsheets
Wow. Perhaps your expectations over the years hve been istortd by
repeated
disappontment;
leading to the _expectation_ of paying a $$$ and getting a fraction back.
On 6/10/06, Randy MacDonald <[EMAIL PROTECTED]> wrote:
>
> Hello J.R.;
>
> I'd love to see examples of where today's computers seem slower than
those
> of the 1970s. It's just not the impression I get.
I do not get the impression that today's _computers_ seem slower tha the
70s.
I do get the impression that today's _software_ _is_ slower.
Relatively, as well as in many to most cases absolutely.
Do the math. I leave out networking, graphics, 2ndary storage, etc; just
an
oversimpified firrst cut anaysis;
please note that the computer I am citing is in fact NOT 70s but late 80s;
I
have to do this to even begin
to demonstrate how far the difference actually is:
486 (32bit/32bit) DX 33MHz with 256KB cache at 20nsec using 64B RAM at 120
to 150 nsec
P6 (64bit/32bit) 3072MHz 4096 KB cache at 2 nsec using 1024 MB DDR at 15
nsec (roughly).
P6/486: .realtive rchitectue comparison, leave it 1:1
32:64bit: 2:1
32/32: 1:1
33/3072: 93:1
256/4096: 16:1
2:20: 10:1
1024/64: 16:1 (but main memory on a WIndows box seems to need 4GB for
mutitasking and graphics to work well): 64:1
RAM/DDR: Should be thunk width ratio, lets leave it at 1:1
15/150: 10:1
You do not like my ratios or figures? Use(r) your own.
HW: 1 x 2 x 1 x 93(100) x 16 x 10 x 16/64 x 1 x 10 == 51200/204800
You want to argue agais the other throughput metrics? Feel free.
Yah, your rough hardware throughput power envelope, comptationally, is
50,000 to 200,000 times more than the late 1980s early 1990s.
... oh, I forgot the $$$ factor ... you could buy the 486 system for
around $1500-4500, where the 3GHz is $750-1500;
build your own and strip to just the populated motherboard, tke out
laptop factor and you get $250 versus $500.
SO you lose a 2:1 factor, relaively.
But: salaries and inflation tae back in give you another discretionary
(though today such a purchase is NOT) ratio fo 4:1 _for_.
You understand why I cannot easily go back to the 70s?
I lerned on an IBM 1401. An 8 bit minus architecture with an
instruction set 1,000 times more powerful than todays;
12K total core with liklely NO cache memory (direct) on God KNows
what
clock rate (go look it up).
This inb turn ran the entire Guilford County school district,
and
left over tie was used for high schoo student projects.
SO, likely, the step p is another 100,00 times at LEAST.
-
Now take the software then versus he software today: lat 80s versus now.
I cannot do so without brraing out the actual categories, and do not have
the time to do any kind of real analysis:
I can only point to the monumental levels of SLOP involved in todays'
software
(J being a very powerful pocket example that shows it does not need to be
so).
I) OS software: The number of assembly steps to get a sinlge OS level
executive ABI done:
70s: 20-100 instructions (go look)
80s: 1000-4000 instructions
90s: 5000-25000 instructions.
Approximately; go look up your own factors, yeeesh.
This INCLUDES the SAME functions that WERE present then, as wll as
the later ones of more complexity.
Step down ratios seem to be 6:1 for the late 80s and up to 10,000:1
since the 70s.
In other words, common OS functin cost 10,000 times more compared to
1970s OSes.
Oversimplified? Yes. Always correct ra
Re: [Jgeneral] spreadsheets
Hello Roy;
No low expectations here! I've been happy with APL's performance since 1991.
Sure, APL/J is slower, but it's no longer easy to notice.
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| [EMAIL PROTECTED] |
|\ | |If you cannot describe what you are doing
BSc(Math) UNBF'83þas a process, you don't know what you're doing.
Sapere Aude | - W. E. Deming
Natural Born APL'er | Demo website: http://156.34.89.50/
-(INTP){ gnat }-
- Original Message -
From: "Roy A. Crabtree" <[EMAIL PROTECTED]>
To: "General forum"
Sent: Saturday, June 10, 2006 11:02 PM
Subject: Re: [Jgeneral] spreadsheets
Wow. Perhaps your expectations over the years hve been istortd by repeated
disappontment;
leading to the _expectation_ of paying a $$$ and getting a fraction back.
On 6/10/06, Randy MacDonald <[EMAIL PROTECTED]> wrote:
>
> Hello J.R.;
>
> I'd love to see examples of where today's computers seem slower than those
> of the 1970s. It's just not the impression I get.
I do not get the impression that today's _computers_ seem slower tha the
70s.
I do get the impression that today's _software_ _is_ slower.
Relatively, as well as in many to most cases absolutely.
Do the math. I leave out networking, graphics, 2ndary storage, etc; just an
oversimpified firrst cut anaysis;
please note that the computer I am citing is in fact NOT 70s but late 80s; I
have to do this to even begin
to demonstrate how far the difference actually is:
486 (32bit/32bit) DX 33MHz with 256KB cache at 20nsec using 64B RAM at 120
to 150 nsec
P6 (64bit/32bit) 3072MHz 4096 KB cache at 2 nsec using 1024 MB DDR at 15
nsec (roughly).
P6/486: .realtive rchitectue comparison, leave it 1:1
32:64bit: 2:1
32/32: 1:1
33/3072: 93:1
256/4096: 16:1
2:20: 10:1
1024/64: 16:1 (but main memory on a WIndows box seems to need 4GB for
mutitasking and graphics to work well): 64:1
RAM/DDR: Should be thunk width ratio, lets leave it at 1:1
15/150: 10:1
You do not like my ratios or figures? Use(r) your own.
HW: 1 x 2 x 1 x 93(100) x 16 x 10 x 16/64 x 1 x 10 == 51200/204800
You want to argue agais the other throughput metrics? Feel free.
Yah, your rough hardware throughput power envelope, comptationally, is
50,000 to 200,000 times more than the late 1980s early 1990s.
... oh, I forgot the $$$ factor ... you could buy the 486 system for
around $1500-4500, where the 3GHz is $750-1500;
build your own and strip to just the populated motherboard, tke out
laptop factor and you get $250 versus $500.
SO you lose a 2:1 factor, relaively.
But: salaries and inflation tae back in give you another discretionary
(though today such a purchase is NOT) ratio fo 4:1 _for_.
You understand why I cannot easily go back to the 70s?
I lerned on an IBM 1401. An 8 bit minus architecture with an
instruction set 1,000 times more powerful than todays;
12K total core with liklely NO cache memory (direct) on God KNows what
clock rate (go look it up).
This inb turn ran the entire Guilford County school district, and
left over tie was used for high schoo student projects.
SO, likely, the step p is another 100,00 times at LEAST.
-
Now take the software then versus he software today: lat 80s versus now.
I cannot do so without brraing out the actual categories, and do not have
the time to do any kind of real analysis:
I can only point to the monumental levels of SLOP involved in todays'
software
(J being a very powerful pocket example that shows it does not need to be
so).
I) OS software: The number of assembly steps to get a sinlge OS level
executive ABI done:
70s: 20-100 instructions (go look)
80s: 1000-4000 instructions
90s: 5000-25000 instructions.
Approximately; go look up your own factors, yeeesh.
This INCLUDES the SAME functions that WERE present then, as wll as
the later ones of more complexity.
Step down ratios seem to be 6:1 for the late 80s and up to 10,000:1
since the 70s.
In other words, common OS functin cost 10,000 times more compared to
1970s OSes.
Oversimplified? Yes. Always correct ratios? No, But: whne you
establish ANY ratio over 4:1 you then have to
worry about WSS CHR (look it up) verus main memory to cache to
processor speeds and aliased goal missing for clock stall.
Your 100:1 processor gets down fro 4th gear to 1rst really fast
that way, all software bound.
Think of a Lamborghini Omtache gon' down the highway doin' 5MPH.
because: who does eithe overlays (address space reduction, memory
reduction) or cache memory hit rates (HW monitor needed) or
cache versus main memory hit rate (static analysis at
Re: [Jgeneral] spreadsheets
Hello J.R.;
If you're using "load a word processing file" as a rough benchmark, I could
see your impression of lack of speedup. That concept has become heavyweight
over the years, probably overtaking Moore's law. for something closer to the
math, like:
+/?#!1
I suspect things have improved.
Software bloat will continue to be with us. I'm sure the feature of mapping
a nested array onto a spreadsheet screen will be part of that.
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| [EMAIL PROTECTED] |
|\ | |If you cannot describe what you are doing
BSc(Math) UNBF'83þas a process, you don't know what you're doing.
Sapere Aude | - W. E. Deming
Natural Born APL'er | Demo website: http://156.34.89.50/
-(INTP){ gnat }-
- Original Message -
From: "John Randall" <[EMAIL PROTECTED]>
To: "General forum"
Sent: Saturday, June 10, 2006 10:22 PM
Subject: Re: [Jgeneral] spreadsheets
> Randy MacDonald wrote:
> > Hello J.R.;
> >
> > I'd love to see examples of where today's computers seem slower than
those
> > of the 1970s. It's just not the impression I get.
> >
>
> Randy:
>
> Of course today's computers are faster, and we expect them to do more. I
> am arguing that the increase in computational resources (processor speed,
> memory, disk size) has not been matched by software performance. This is
> especially true with programs such as word processors, where the I/O speed
> is glacial.
>
> Let's look at a comparison from the late 1980s. I had an AT&T Unix PC
> (PC7300, 3b1) with 1MB memory, a 20MB disk and a 68010 at 10MHz. My
> current computer running Linux has 1000x more memory, 5000x more disk and
> is 500x as fast. The Unix PC ran a full version of Unix System V with a
> graphical interface (but not X-Windows). I would not go back, but I do not
> think the performance of my current computer is 500x better.
>
> Best wishes,
>
> John
>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
Here, here. The old guys/gals in the old days wre not always all that dumb. If ou are intereste, take alook at the Bendix RLH architecture: "run like hell"; the organizing principle was roughly the idea that: in order to run as fast as possible never wait. In short, each _previous_ stage in the architecture s responsible to _always_ have the _inputs_ to the next stage (outputs _fro_ the previous stage) by the time the next stage needed them. That died with the Bendix computers in the 50s/60s. True data flow reductiongrids at the bit level still do not exist. On 6/10/06, Don Guinn <[EMAIL PROTECTED]> wrote: Building a spreadsheet is still programming. It's just not procedural. Entering a document with markup into a word processor is also programming. Don't forget the old EAM machines with boards. That was programming too. I am still impressed by that architecture as those were machines with cycle times of as little as 3 hertz and could still outperform today's PCs with gigahertz speeds. John Randall wrote: >Steven H. Rogers writes: > > >>Spreadsheets are often used to edit, view, and present data with little >>actual computation performed on spreadsheet values. While APL and J are >>"better" at most computations, spreadsheets are "good enough" for most >>people's needs. >> >> >> > >The good enough is the enemy of the good. > >I agree with Oleg's comments about intuitiveness being a major appeal with >spreadsheets. Anything that can be used instantly to solve the task at >hand is better than something which has to be deliberately learned. > >I know a number of people who know very little about programming but are >absolute whizzes with spreadsheets. In general, they are incapable of >explaining what they are doing, but get they the correct result, >reinforcing the idea that spreadsheets tap into some kind of intuition. > >Best wishes, > >John > >-- >For information about J forums see http://www.jsoftware.com/forums.htm > > > > -- For information about J forums see http://www.jsoftware.com/forums.htm -- -- Roy A. Crabtree UNC '76 gaa.lifer#11086 Room 207 Studio Plus 123 East McCullough Drive Charlotte, NC 28262-3306 336-340-1304 (office/home/cell/vmail) 704-510-0108x7404 (voicemail residence) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.authorsden.com/royacrabtree http://skyscraper.fortunecity.com/activex/720/resume/full.doc -- (c) RAC/IP, ARE,PRO,PAST (Copyright) Roy Andrew Crabtree/In Perpetuity All Rights/Reserved Explicitly Public Reuse Only Profits Always Safe Traded -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
st itself to the end user's needed bandwidth: some need 1 inch
by inch; others need a laptop 17 inch at 32 bit.
As ear s I can te the common software currently in use is actually using
1,000,000 time the resources it actually needs to consume;
both on the network, as well as on the DTE (look it up: in this case the
displayng PC). More correctly, this ratio:
OLD needed versus used / NEW needed versus used
is improvable by about 1e5 to 1e8.
(If you disagree, I will want $$$ up front before I go through the
whole analysis).
How about primary versus tiered 2ndary storage speeds and buffering? Do I
need to do the analysis?
ANyone know of an OS or compiler or DB or OLTP that does H versus Z
buffer analysis or
localized CPU potting (most disk drives have a CPU smart enough to form
a true array processor;
you can push the TPC benchmark rates up to 1000 times the performance
at 100% storage
usage if you apply that lever: defeatig the purpose of the
specifications).
How about selective processing load stall (See TSO) for he purpose of
accumulating a list (See HASP)
of jobs to locally apply in oder to reduce critical resource
contstraint stalls (se disk head movement delys verus
H,I, T, and Z scheduling). Much less a full tiling anti-alising
anti-missed deadline packig fraction optimizer in real time.
JIT or incremental optimization or re-optimizing when conditions shift?
Not a chance.
_yet_. RSN. Watch the FP and gridding arenas.
I have not even begun to list them. The truly effective folks are already
using these techniques. You just do not hear bout it.
Basically,on almost any problem a single user can invoke on a single
computer, and MOST of the ones regarded as big on Beowulfs or grids,
... if you sneeze and it ain't done, the software (hardware integration
& optimization) suck(s).
Bur; I never got used to paying twice more every two years for more sofware
that ran relatively too much slower, so that in two years ...
Microswift could do it again. While I paid for it.
Of course, perhaps I am wrong.
But I doubt it.
(I did not invent the analyses or effiiciency methods: so I get no Kudos.
Ther REALLY bright people did that; all I did was READ it;
and REMEMBER where to apply it).
SO, basically, I am giving a thumbs up to J in hthe area of gridding.
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| [EMAIL PROTECTED] |
|\ | |If you cannot describe what you are doing
BSc(Math) UNBF'83þas a process, you don't know what you're doing.
Sapere Aude | - W. E. Deming
Natural Born APL'er | Demo website: http://156.34.89.50/?JGeneral
-(INTP){ gnat }-
- Original Message -
From: "John Randall" <[EMAIL PROTECTED]>
To: "General forum"
Sent: Saturday, June 10, 2006 7:44 PM
Subject: Re: [Jgeneral] spreadsheets
> Don Guinn wrote:
> > Building a spreadsheet is still programming. It's just not procedural.
> > Entering a document with markup into a word processor is also
> > programming. Don't forget the old EAM machines with boards. That was
> > programming too. I am still impressed by that architecture as those
were
> > machines with cycle times of as little as 3 hertz and could still
> > outperform today's PCs with gigahertz speeds.
> >
>
> Point taken. I think many people are more comfortable with hitting
recalc
> until the spreadsheet stabilizes than trying to understand how u^:_
works.
>
> I, too am unimpressed with the speed of current computers, especially
when
> they are used interactively. My first personal computer was a TRS-80
> Model III, with 16K RAM and a 2 MHz Z80. My current computer is about
> 1000 times as fast and has about 5 times as much memory. I do not
see
> comparable improvements in performance. In a recent post, Roy Crabtree
> gave examples in the same vein.
>
> Texas Instruments still uses the Z80 (overclocked to 4 MHz) in its
> calculators. This is a chip which has no floating point arithmetic, and
> does not even have a hardware (integer) multiplication. The arguments
for
> sticking with this come down to the fact that it is good enough for
> interactive use, TI has mature libraries, and power consumption is
low. A
> calculator will run for months on AA batteries. Compare this with cell
> phones.
>
> Best wishes,
>
> John
>
>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http:/
Re: [Jgeneral] spreadsheets
The strategy has always been to have machines make up for the inefficiency of bad code--after all its easier to get machines to do what you want them to do than the people who write bad code Donna [EMAIL PROTECTED] On 10-Jun-06, at 9:22 PM, John Randall wrote: Randy MacDonald wrote: Hello J.R.; I'd love to see examples of where today's computers seem slower than those of the 1970s. It's just not the impression I get. Randy: Of course today's computers are faster, and we expect them to do more. I am arguing that the increase in computational resources (processor speed, memory, disk size) has not been matched by software performance. This is especially true with programs such as word processors, where the I/ O speed is glacial. Let's look at a comparison from the late 1980s. I had an AT&T Unix PC (PC7300, 3b1) with 1MB memory, a 20MB disk and a 68010 at 10MHz. My current computer running Linux has 1000x more memory, 5000x more disk and is 500x as fast. The Unix PC ran a full version of Unix System V with a graphical interface (but not X-Windows). I would not go back, but I do not think the performance of my current computer is 500x better. Best wishes, John -- For information about J forums see http://www.jsoftware.com/forums.htm -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
Randy MacDonald wrote: > Hello J.R.; > > I'd love to see examples of where today's computers seem slower than those > of the 1970s. It's just not the impression I get. > Randy: Of course today's computers are faster, and we expect them to do more. I am arguing that the increase in computational resources (processor speed, memory, disk size) has not been matched by software performance. This is especially true with programs such as word processors, where the I/O speed is glacial. Let's look at a comparison from the late 1980s. I had an AT&T Unix PC (PC7300, 3b1) with 1MB memory, a 20MB disk and a 68010 at 10MHz. My current computer running Linux has 1000x more memory, 5000x more disk and is 500x as fast. The Unix PC ran a full version of Unix System V with a graphical interface (but not X-Windows). I would not go back, but I do not think the performance of my current computer is 500x better. Best wishes, John -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
Hello J.R.;
I'd love to see examples of where today's computers seem slower than those
of the 1970s. It's just not the impression I get.
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| [EMAIL PROTECTED] |
|\ | |If you cannot describe what you are doing
BSc(Math) UNBF'83þas a process, you don't know what you're doing.
Sapere Aude | - W. E. Deming
Natural Born APL'er | Demo website: http://156.34.89.50/?JGeneral
-(INTP){ gnat }-
- Original Message -
From: "John Randall" <[EMAIL PROTECTED]>
To: "General forum"
Sent: Saturday, June 10, 2006 7:44 PM
Subject: Re: [Jgeneral] spreadsheets
> Don Guinn wrote:
> > Building a spreadsheet is still programming. It's just not procedural.
> > Entering a document with markup into a word processor is also
> > programming. Don't forget the old EAM machines with boards. That was
> > programming too. I am still impressed by that architecture as those were
> > machines with cycle times of as little as 3 hertz and could still
> > outperform today's PCs with gigahertz speeds.
> >
>
> Point taken. I think many people are more comfortable with hitting recalc
> until the spreadsheet stabilizes than trying to understand how u^:_ works.
>
> I, too am unimpressed with the speed of current computers, especially when
> they are used interactively. My first personal computer was a TRS-80
> Model III, with 16K RAM and a 2 MHz Z80. My current computer is about
> 1000 times as fast and has about 5 times as much memory. I do not see
> comparable improvements in performance. In a recent post, Roy Crabtree
> gave examples in the same vein.
>
> Texas Instruments still uses the Z80 (overclocked to 4 MHz) in its
> calculators. This is a chip which has no floating point arithmetic, and
> does not even have a hardware (integer) multiplication. The arguments for
> sticking with this come down to the fact that it is good enough for
> interactive use, TI has mature libraries, and power consumption is low. A
> calculator will run for months on AA batteries. Compare this with cell
> phones.
>
> Best wishes,
>
> John
>
>
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
Hello Stuart;
This ability to express array constants seems like a trivial extension of
cell ranges. I don't see how the result of the expression can be an array.
Does Excel display a cell with the formula '({1,2,3})' for example, or does
something like "<>" show up in the cell?
I've got the Open Office spreadsheet on my box someplace. Is _that_ worth
exploring, anyone?
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| [EMAIL PROTECTED] |
|\ | |If you cannot describe what you are doing
BSc(Math) UNBF'83þas a process, you don't know what you're doing.
Sapere Aude | - W. E. Deming
Natural Born APL'er | Demo website: http://156.34.89.50/
-(INTP){ gnat }-
- Original Message -
From: "Stuart Bruff" <[EMAIL PROTECTED]>
To: "'General forum'"
Sent: Saturday, June 10, 2006 6:53 PM
Subject: RE: [Jgeneral] spreadsheets
Not all spreadsheet applications limit their results to scalars. Excel, at
least, has array entities. I quote, hopefully without treading on anybody's
copyright toes, from the help:
A basic, single-value formula produces a single result from one or more
arguments or values; you can enter either a reference to a cell that
contains a
value or the value itself. In an array formula, where you might usually use
a
reference to a range of cells, you can instead type the array of values
contained within the cells. The array of values you type is called an array
constant and generally is used when you do not want to enter each value into
a
separate cell on the worksheet. To create an array constant, you must do the
following:
· Enter the values directly into the formula, enclosed in braces ( { } )
· Separate values in different columns with commas (,)
· Separate values in different rows with semicolons (;)
For example, you can enter {10,20,30,40} in an array formula instead of
entering
10, 20, 30, 40 in four cells in one row. This array constant is known as a
1-by-4 array and is equivalent to a 1-row-by-4-column reference. To
represent
the values 10, 20, 30, 40 in one row and 50, 60, 70, 80 in the row
immediately
below, you would enter a 2-by-4 array constant: {10,20,30,40;50,60,70,80}.
As with many things, users start off with the 'simple' cases, but can find
it
frustrating when they gain more experience and hit problems that require
more
complex results. Perhaps a J-based spreadsheet could offer an interesting
migration path for such people?
Stuart
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
Behalf Of Randy MacDonald
Sent: 10 June 2006 5:14 PM
To: General forum
Subject: Re: [Jgeneral] spreadsheets
Hello Donna;
I've noticed this with my experience with APL spreadsheets: because the
possible
result from an APL/J expression can be any valid APL/J object, it is not so
clear where the result goes. Spreadsheets, with an expression system that
can
return only scalars, "put the result here" is obvious and trivial. If you do
limit the possible APL/J expressions to only the ones that return scalars,
you
severely limit the language. This was a showstopper for me.
Perhaps if spreadsheet cells could contain arbitrary arrays...
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| [EMAIL PROTECTED] |
|\ | |If you cannot describe what you are doing
BSc(Math) UNBF'83þas a process, you don't know what you're doing.
Sapere Aude | - W. E. Deming
Natural Born APL'er | Demo website: http://156.34.89.50/
-(INTP){ gnat }-
- Original Message -
From: "dly" <[EMAIL PROTECTED]>
To: "General forum"
Sent: Saturday, June 10, 2006 12:31 PM
Subject: Re: [Jgeneral] spreadsheets
> what is needed is a spreadsheet where j or apl can be invoked in each
> cell and that could be added to an existing spreadsheet as an option
> if there is any open code spreadsheet application Donna
> [EMAIL PROTECTED]
>
>
>
> On 10-Jun-06, at 11:27 AM, Bill Harris wrote:
>
> > "Steven H. Rogers" <[EMAIL PROTECTED]> writes:
> >
> >> Focusing on J Grid development to make it a tool for this type of
> >> application that people would use even if they don't know J might
> >> be a good marketing tactic.
> >
> > I agree. I think that spreadsheets for many (me, too, sometimes)
> > are sheets of electronic paper. It's easy to change the number in a
> > particular cell without worrying
Re: [Jgeneral] spreadsheets
Don Guinn wrote: > Building a spreadsheet is still programming. It's just not procedural. > Entering a document with markup into a word processor is also > programming. Don't forget the old EAM machines with boards. That was > programming too. I am still impressed by that architecture as those were > machines with cycle times of as little as 3 hertz and could still > outperform today's PCs with gigahertz speeds. > For those nostalgic for the old days, when data flow was done with wires not formulas, here are some pictures. http://www.columbia.edu/acis/history/plugboard.html Best wishes, John -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
Don Guinn wrote: > Building a spreadsheet is still programming. It's just not procedural. > Entering a document with markup into a word processor is also > programming. Don't forget the old EAM machines with boards. That was > programming too. I am still impressed by that architecture as those were > machines with cycle times of as little as 3 hertz and could still > outperform today's PCs with gigahertz speeds. > Point taken. I think many people are more comfortable with hitting recalc until the spreadsheet stabilizes than trying to understand how u^:_ works. I, too am unimpressed with the speed of current computers, especially when they are used interactively. My first personal computer was a TRS-80 Model III, with 16K RAM and a 2 MHz Z80. My current computer is about 1000 times as fast and has about 5 times as much memory. I do not see comparable improvements in performance. In a recent post, Roy Crabtree gave examples in the same vein. Texas Instruments still uses the Z80 (overclocked to 4 MHz) in its calculators. This is a chip which has no floating point arithmetic, and does not even have a hardware (integer) multiplication. The arguments for sticking with this come down to the fact that it is good enough for interactive use, TI has mature libraries, and power consumption is low. A calculator will run for months on AA batteries. Compare this with cell phones. Best wishes, John -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
Building a spreadsheet is still programming. It's just not procedural. Entering a document with markup into a word processor is also programming. Don't forget the old EAM machines with boards. That was programming too. I am still impressed by that architecture as those were machines with cycle times of as little as 3 hertz and could still outperform today's PCs with gigahertz speeds. John Randall wrote: Steven H. Rogers writes: Spreadsheets are often used to edit, view, and present data with little actual computation performed on spreadsheet values. While APL and J are "better" at most computations, spreadsheets are "good enough" for most people's needs. The good enough is the enemy of the good. I agree with Oleg's comments about intuitiveness being a major appeal with spreadsheets. Anything that can be used instantly to solve the task at hand is better than something which has to be deliberately learned. I know a number of people who know very little about programming but are absolute whizzes with spreadsheets. In general, they are incapable of explaining what they are doing, but get they the correct result, reinforcing the idea that spreadsheets tap into some kind of intuition. Best wishes, John -- For information about J forums see http://www.jsoftware.com/forums.htm -- For information about J forums see http://www.jsoftware.com/forums.htm
RE: [Jgeneral] spreadsheets
Not all spreadsheet applications limit their results to scalars. Excel, at
least, has array entities. I quote, hopefully without treading on anybody's
copyright toes, from the help:
A basic, single-value formula produces a single result from one or more
arguments or values; you can enter either a reference to a cell that contains a
value or the value itself. In an array formula, where you might usually use a
reference to a range of cells, you can instead type the array of values
contained within the cells. The array of values you type is called an array
constant and generally is used when you do not want to enter each value into a
separate cell on the worksheet. To create an array constant, you must do the
following:
· Enter the values directly into the formula, enclosed in braces ( { } )
· Separate values in different columns with commas (,)
· Separate values in different rows with semicolons (;)
For example, you can enter {10,20,30,40} in an array formula instead of entering
10, 20, 30, 40 in four cells in one row. This array constant is known as a
1-by-4 array and is equivalent to a 1-row-by-4-column reference. To represent
the values 10, 20, 30, 40 in one row and 50, 60, 70, 80 in the row immediately
below, you would enter a 2-by-4 array constant: {10,20,30,40;50,60,70,80}.
As with many things, users start off with the 'simple' cases, but can find it
frustrating when they gain more experience and hit problems that require more
complex results. Perhaps a J-based spreadsheet could offer an interesting
migration path for such people?
Stuart
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Randy MacDonald
Sent: 10 June 2006 5:14 PM
To: General forum
Subject: Re: [Jgeneral] spreadsheets
Hello Donna;
I've noticed this with my experience with APL spreadsheets: because the possible
result from an APL/J expression can be any valid APL/J object, it is not so
clear where the result goes. Spreadsheets, with an expression system that can
return only scalars, "put the result here" is obvious and trivial. If you do
limit the possible APL/J expressions to only the ones that return scalars, you
severely limit the language. This was a showstopper for me.
Perhaps if spreadsheet cells could contain arbitrary arrays...
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| [EMAIL PROTECTED] |
|\ | |If you cannot describe what you are doing
BSc(Math) UNBF'83þas a process, you don't know what you're doing.
Sapere Aude | - W. E. Deming
Natural Born APL'er | Demo website: http://156.34.89.50/
-(INTP){ gnat }-
- Original Message -
From: "dly" <[EMAIL PROTECTED]>
To: "General forum"
Sent: Saturday, June 10, 2006 12:31 PM
Subject: Re: [Jgeneral] spreadsheets
> what is needed is a spreadsheet where j or apl can be invoked in each
> cell and that could be added to an existing spreadsheet as an option
> if there is any open code spreadsheet application Donna
> [EMAIL PROTECTED]
>
>
>
> On 10-Jun-06, at 11:27 AM, Bill Harris wrote:
>
> > "Steven H. Rogers" <[EMAIL PROTECTED]> writes:
> >
> >> Focusing on J Grid development to make it a tool for this type of
> >> application that people would use even if they don't know J might
> >> be a good marketing tactic.
> >
> > I agree. I think that spreadsheets for many (me, too, sometimes)
> > are sheets of electronic paper. It's easy to change the number in a
> > particular cell without worrying about the other numbers or about
> > the syntax of amend. With a spreadsheet, the numbers are in the
> > foreground; with J, the functions seem to be. That's generally
> > good, but sometimes
> > it's comforting to write down the numbers and have them sit there,
> > waiting to be transformed or perhaps edited.
> >
> > Bill
> > --
> > Bill Harris http://facilitatedsystems.com/weblog/
> > Facilitated Systems Everett, WA 98208 USA
> > http://facilitatedsystems.com/ phone: +1 425 337-5541
> >
> >
> > --
> > 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
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
Not really: the community of interest only apparently conjoins.
Matrix languages are general purpose.
Spreadsheets were for accounting, specific.
As such, APL was never in the running.
Visicalc did this (before Lotus stole it into 1-2-3) on systems with < 64K:
1) It had the spreadsheet.
2) It had dependency graphs (taking the best of UNIX "make(1)" into its
functions)
3) It avoided language discussion with a text oriented or menu drop down
"point & click" type
of interface (using cell ranges is jus tthat: minimal language, maximal
function).
4) Early on the designers recognized tht _performance_ was an issue, so
they put in the best inbtrnal _coding_ to get the performance up:
minimal memory (RAM), maximal spreadsheet size, maximal performance.
Visicalc blaed for the HW it had.
1-2-3 and Excel do not even get on the playing field.
They get on the _paying_ field.
I am on a laptop with 1GB RAM, 3GHz processor, and it is SLOW.
I am not arguing in FAVOR of interpretd spreadsheets and ad hoc syntax.
I am noting that to make a mrket position in such a specialized niche,
Matrix languages have to offer referential transparency:
(you have to run Excel and 1-2-3 ad OpenOffice spredsheets, at least,
95% of the time)
and offer the underlying power of your language WITH A BACK TRANSLATOR
if you expect to make pay for play inroads.
Alternatively, I would recommend reading "A Prolog Database System", by Deyi
Li (1984).
It has all the notations for referential transparency among all fors of
database languages:
SQL
Natural language
Artificial language (Prolog in this case)
Relational calculus
QBE: query by example
QBF: Query by Form
Graphically oriented QBE
and, most importantly: mix-mastering: using ALL of the above forms in ONE
query.
That is the most importnt part of the book: the specification of interfacers
in such a way as to be able to use them ALL, at ANY time.
If J wants to make spreadsheets look obsolete to _master_ users (not
apprentices)< this should be your goal.
You still will NOT make headway among the vast market: but you MAY
attract enough _experts_
to pull an udertowe about 18 months into it.
BUT: you will have to work at it now; the web community and its inherent
noise level are drowning out the rational voices ongoing.
How many of you een know what an overlay is, or how Visicalc coud get
ANYthing done
in 64KB memory: it is not the memory size, it is the ADDRESS space
size ... (as well as the memory size).
And, here we are, 25 years later, and we still do not have the HW secondary
tier memory architecture peripheral type
to fill the speed gap between main memory speed and hard disk speed: and
please do not tell me the tech ain' there.
It is.
_Inteliigent_ use of _existing_ methods is what is needed; and ongoing with
that, even before that,
braod application ad use of already existng techniques to actually
_solve_problems_ by ordinary users;
the novices, not the experts.
I think this was oe of the reasons Dr. KEI went wth the shift to J/English,
away from APL/rhunes.
Losng the connection to the intended end beneficiary: the ordinary
_mathematics_ student may well be a death knell if J does it.
On 6/10/06, Björn Helgason <[EMAIL PROTECTED]> wrote:
I have always been a bit surprised how APL lost out to spreadsheets
APL had it al except the presentation part
J has been much better and the Grids are a good step in the right
direction
The spreadsheet wars are hotting up with Google now entering
http://www.google.com/googlespreadsheets/tour3.html
--
Björn Helgason, Verkfræðingur
Fugl&Fiskur ehf, Þerneyjarsund 23,
Skype: gosiminn, gsm: +3546985532
801 Grímsnes ,t-póst: [EMAIL PROTECTED]
Landslags og skrúðgarðagerð, gröfuþjónusta
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
--
--
Roy A. Crabtree
UNC '76 gaa.lifer#11086
Room 207 Studio Plus
123 East McCullough Drive
Charlotte, NC 28262-3306
336-340-1304 (office/home/cell/vmail)
704-510-0108x7404 (voicemail residence)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.authorsden.com/royacrabtree
http://skyscraper.fortunecity.com/activex/720/resume/full.doc
--
(c) RAC/IP, ARE,PRO,PAST
(Copyright) Roy Andrew Crabtree/In Perpetuity
All Rights/Reserved Explicitly
Public Reuse
Re: [Jgeneral] spreadsheets
The two dimensional case is the most important case for most people
one spreadsheet is two dimensional
workbook includes several spreadsheets and adds extra dimensions
One cell in a spreadsheet could contain boxed items that could be opened in
a html popup manner
2006/6/10, Randy MacDonald <[EMAIL PROTECTED]>:
because the
possible result from an APL/J expression can be any valid APL/J object, it
is not so clear where the result goes.
--
Björn Helgason, Verkfræðingur
Fugl&Fiskur ehf, Þerneyjarsund 23,
Skype: gosiminn, gsm: +3546985532
801 Grímsnes ,t-póst: [EMAIL PROTECTED]
Landslags og skrúðgarðagerð, gröfuþjónusta
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
Re: [Jgeneral] spreadsheets
Yes--I wasn't meaning to replace J with this idea-just expand the
current function of typical spreadsheets--perhaps a little too
powerful causing the end of the spreadsheet world as we know it
forgive me this is my first day playing with J after many many years
in exile
Donna
[EMAIL PROTECTED]
On 10-Jun-06, at 12:13 PM, Randy MacDonald wrote:
Hello Donna;
I've noticed this with my experience with APL spreadsheets: because
the
possible result from an APL/J expression can be any valid APL/J
object, it
is not so clear where the result goes. Spreadsheets, with an
expression
system that can return only scalars, "put the result here" is
obvious and
trivial. If you do limit the possible APL/J expressions to only the
ones
that return scalars, you severely limit the language. This was a
showstopper
for me.
Perhaps if spreadsheet cells could contain arbitrary arrays...
--
--
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| [EMAIL PROTECTED] |
|\ | |If you cannot describe what you are doing
BSc(Math) UNBF'83þas a process, you don't know what you're
doing.
Sapere Aude | - W. E. Deming
Natural Born APL'er | Demo website: http://156.34.89.50/
-(INTP)
{ gnat }-
- Original Message -
From: "dly" <[EMAIL PROTECTED]>
To: "General forum"
Sent: Saturday, June 10, 2006 12:31 PM
Subject: Re: [Jgeneral] spreadsheets
what is needed is a spreadsheet where j or apl can be invoked in each
cell and that could be added to an existing spreadsheet as an option
if there is any open code spreadsheet application
Donna
[EMAIL PROTECTED]
On 10-Jun-06, at 11:27 AM, Bill Harris wrote:
"Steven H. Rogers" <[EMAIL PROTECTED]> writes:
Focusing on J Grid development to make it a tool for this type of
application that people would use even if they don't know J might
be a
good marketing tactic.
I agree. I think that spreadsheets for many (me, too, sometimes)
are
sheets of electronic paper. It's easy to change the number in a
particular cell without worrying about the other numbers or about
the
syntax of amend. With a spreadsheet, the numbers are in the
foreground;
with J, the functions seem to be. That's generally good, but
sometimes
it's comforting to write down the numbers and have them sit there,
waiting to be transformed or perhaps edited.
Bill
--
Bill Harris http://facilitatedsystems.com/
weblog/
Facilitated Systems Everett, WA
98208 USA
http://facilitatedsystems.com/ phone: +1 425
337-5541
--
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
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
"Randy MacDonald" <[EMAIL PROTECTED]> writes: > Perhaps if spreadsheet cells could contain arbitrary arrays... Or, from my perspective, if there were a simple grid control which one could use to enter data and then act on it in the .ijx window and see results there or in viewmat or a graph or Bill -- Bill Harris http://facilitatedsystems.com/weblog/ Facilitated Systems Everett, WA 98208 USA http://facilitatedsystems.com/ phone: +1 425 337-5541 -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
Hello Donna;
I've noticed this with my experience with APL spreadsheets: because the
possible result from an APL/J expression can be any valid APL/J object, it
is not so clear where the result goes. Spreadsheets, with an expression
system that can return only scalars, "put the result here" is obvious and
trivial. If you do limit the possible APL/J expressions to only the ones
that return scalars, you severely limit the language. This was a showstopper
for me.
Perhaps if spreadsheet cells could contain arbitrary arrays...
|\/| Randy A MacDonald | APL: If you can say it, it's done.. (ram)
|/\| [EMAIL PROTECTED] |
|\ | |If you cannot describe what you are doing
BSc(Math) UNBF'83þas a process, you don't know what you're doing.
Sapere Aude | - W. E. Deming
Natural Born APL'er | Demo website: http://156.34.89.50/
-(INTP){ gnat }-
- Original Message -
From: "dly" <[EMAIL PROTECTED]>
To: "General forum"
Sent: Saturday, June 10, 2006 12:31 PM
Subject: Re: [Jgeneral] spreadsheets
> what is needed is a spreadsheet where j or apl can be invoked in each
> cell and that could be added to an existing spreadsheet as an option
> if there is any open code spreadsheet application
> Donna
> [EMAIL PROTECTED]
>
>
>
> On 10-Jun-06, at 11:27 AM, Bill Harris wrote:
>
> > "Steven H. Rogers" <[EMAIL PROTECTED]> writes:
> >
> >> Focusing on J Grid development to make it a tool for this type of
> >> application that people would use even if they don't know J might
> >> be a
> >> good marketing tactic.
> >
> > I agree. I think that spreadsheets for many (me, too, sometimes) are
> > sheets of electronic paper. It's easy to change the number in a
> > particular cell without worrying about the other numbers or about the
> > syntax of amend. With a spreadsheet, the numbers are in the
> > foreground;
> > with J, the functions seem to be. That's generally good, but
> > sometimes
> > it's comforting to write down the numbers and have them sit there,
> > waiting to be transformed or perhaps edited.
> >
> > Bill
> > --
> > Bill Harris http://facilitatedsystems.com/weblog/
> > Facilitated Systems Everett, WA 98208 USA
> > http://facilitatedsystems.com/ phone: +1 425 337-5541
> >
> > --
> > 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
Re: [Jgeneral] spreadsheets
what is needed is a spreadsheet where j or apl can be invoked in each cell and that could be added to an existing spreadsheet as an option if there is any open code spreadsheet application Donna [EMAIL PROTECTED] On 10-Jun-06, at 11:27 AM, Bill Harris wrote: "Steven H. Rogers" <[EMAIL PROTECTED]> writes: Focusing on J Grid development to make it a tool for this type of application that people would use even if they don't know J might be a good marketing tactic. I agree. I think that spreadsheets for many (me, too, sometimes) are sheets of electronic paper. It's easy to change the number in a particular cell without worrying about the other numbers or about the syntax of amend. With a spreadsheet, the numbers are in the foreground; with J, the functions seem to be. That's generally good, but sometimes it's comforting to write down the numbers and have them sit there, waiting to be transformed or perhaps edited. Bill -- Bill Harris http://facilitatedsystems.com/weblog/ Facilitated Systems Everett, WA 98208 USA http://facilitatedsystems.com/ phone: +1 425 337-5541 -- For information about J forums see http://www.jsoftware.com/forums.htm -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
"Steven H. Rogers" <[EMAIL PROTECTED]> writes: > Focusing on J Grid development to make it a tool for this type of > application that people would use even if they don't know J might be a > good marketing tactic. I agree. I think that spreadsheets for many (me, too, sometimes) are sheets of electronic paper. It's easy to change the number in a particular cell without worrying about the other numbers or about the syntax of amend. With a spreadsheet, the numbers are in the foreground; with J, the functions seem to be. That's generally good, but sometimes it's comforting to write down the numbers and have them sit there, waiting to be transformed or perhaps edited. Bill -- Bill Harris http://facilitatedsystems.com/weblog/ Facilitated Systems Everett, WA 98208 USA http://facilitatedsystems.com/ phone: +1 425 337-5541 -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
Some reasons: At the point the PC was introduced many people had access to computers and wanted applications not tools for programming There were more developers who did not know APL than those that did Marketing took over I know very well as I was forced to make a Lotus spreadsheet interface to my APL financial system for all the people in the company that suddenly had a PC with a spreadsheet application (1987 if I recall) Donna [EMAIL PROTECTED] On 10-Jun-06, at 10:46 AM, Oleg Kobchenko wrote: That's a very interesting point to note, how come: a very powerful engine and notation fades in view of seemingly more basic medium-skilled user application with modest operations capacity, percieved as entry and presentation convenience supplemented with casual calculations. There is something missing in this comparison. VisiCalc went on to become the first "killer app" (WikiPedia). It doesn't seem that it's accountants alone or even on the most part percieved its potential and made up all those record sales. There should be a very lucky combination of factors that played that important role. They belong to the usability category: - "what-if" factor: the ability to construct cascading calculation model, which updates in real time (*). - highly visual and feedback based - seeing the big picture: ability to easily create and modify a layout of multiple subviews that are fixed in space and represent many different aspects of the model - lightening rapid application development for a common person - bottom low entry barrier: just type in and get instant results, for simple to medium level applications *) "spread" is attributed to accounting ledger page spread, but it also could be viewed as instant "spread of calculation" to all parts of the model with a change in a single value In APL you can create hierachical calculations, but they are not visual -- user/developer needs additional effort to see them. There is an interactive factor in APL, but user can see only one result at a time. There is no observing of the whole picture with instant feedback. It can be argued that the rectangular cell layout, also referred to as "Grid" is an accidental rather then a decisive factor. There other instances of very appealing UI solutions with a different controls structure, for example, visual modelers, such as CAD and 3D designers, to a minor extent another killer app: Photoshop -- it doesn't do functionally any more than any decent image library. But especially close to the above factors is recent Apple's Quartz Composer -- it's like spreadsheet inside out, so you actually observe and manipulate the connections between freely floating cascades of clustered image, compositing, video and animation operations each of whose parameters you observe changing dynamically in addition to the resulting scene view; in addition to entering numerical values, physical manipulators are used like trackers and round knobs. To sum up, it's possibility to create complex models with small effort by direct intuitive manipulation, instant feedback and observation of all the details and the model and as a whole. What they say about good car design -- it's a natural extension of the human body. So, think of the goal of a good application design as producing the natural extension of the human mind. - Original Message From: Steven H. Rogers <[EMAIL PROTECTED]> To: General forum Sent: Saturday, June 10, 2006 8:41:44 AM Subject: Re: [Jgeneral] spreadsheets Spreadsheets are often used to edit, view, and present data with little actual computation performed on spreadsheet values. While APL and J are "better" at most computations, spreadsheets are "good enough" for most people's needs. Focusing on J Grid development to make it a tool for this type of application that people would use even if they don't know J might be a good marketing tactic. Regards, Steve Björn Helgason wrote: I have always been a bit surprised how APL lost out to spreadsheets APL had it al except the presentation part J has been much better and the Grids are a good step in the right direction The spreadsheet wars are hotting up with Google now entering http://www.google.com/googlespreadsheets/tour3.html -- Steven H. Rogers, Ph.D., [EMAIL PROTECTED] Weblog: http://shrogers.com/weblog "He who refuses to do arithmetic is doomed to talk nonsense." -- John McCarthy -- 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
Re: [Jgeneral] spreadsheets
Steven H. Rogers writes: > Spreadsheets are often used to edit, view, and present data with little > actual computation performed on spreadsheet values. While APL and J are > "better" at most computations, spreadsheets are "good enough" for most > people's needs. > The good enough is the enemy of the good. I agree with Oleg's comments about intuitiveness being a major appeal with spreadsheets. Anything that can be used instantly to solve the task at hand is better than something which has to be deliberately learned. I know a number of people who know very little about programming but are absolute whizzes with spreadsheets. In general, they are incapable of explaining what they are doing, but get they the correct result, reinforcing the idea that spreadsheets tap into some kind of intuition. Best wishes, John -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
That's a very interesting point to note, how come: a very powerful engine and notation fades in view of seemingly more basic medium-skilled user application with modest operations capacity, percieved as entry and presentation convenience supplemented with casual calculations. There is something missing in this comparison. VisiCalc went on to become the first "killer app" (WikiPedia). It doesn't seem that it's accountants alone or even on the most part percieved its potential and made up all those record sales. There should be a very lucky combination of factors that played that important role. They belong to the usability category: - "what-if" factor: the ability to construct cascading calculation model, which updates in real time (*). - highly visual and feedback based - seeing the big picture: ability to easily create and modify a layout of multiple subviews that are fixed in space and represent many different aspects of the model - lightening rapid application development for a common person - bottom low entry barrier: just type in and get instant results, for simple to medium level applications *) "spread" is attributed to accounting ledger page spread, but it also could be viewed as instant "spread of calculation" to all parts of the model with a change in a single value In APL you can create hierachical calculations, but they are not visual -- user/developer needs additional effort to see them. There is an interactive factor in APL, but user can see only one result at a time. There is no observing of the whole picture with instant feedback. It can be argued that the rectangular cell layout, also referred to as "Grid" is an accidental rather then a decisive factor. There other instances of very appealing UI solutions with a different controls structure, for example, visual modelers, such as CAD and 3D designers, to a minor extent another killer app: Photoshop -- it doesn't do functionally any more than any decent image library. But especially close to the above factors is recent Apple's Quartz Composer -- it's like spreadsheet inside out, so you actually observe and manipulate the connections between freely floating cascades of clustered image, compositing, video and animation operations each of whose parameters you observe changing dynamically in addition to the resulting scene view; in addition to entering numerical values, physical manipulators are used like trackers and round knobs. To sum up, it's possibility to create complex models with small effort by direct intuitive manipulation, instant feedback and observation of all the details and the model and as a whole. What they say about good car design -- it's a natural extension of the human body. So, think of the goal of a good application design as producing the natural extension of the human mind. - Original Message From: Steven H. Rogers <[EMAIL PROTECTED]> To: General forum Sent: Saturday, June 10, 2006 8:41:44 AM Subject: Re: [Jgeneral] spreadsheets Spreadsheets are often used to edit, view, and present data with little actual computation performed on spreadsheet values. While APL and J are "better" at most computations, spreadsheets are "good enough" for most people's needs. Focusing on J Grid development to make it a tool for this type of application that people would use even if they don't know J might be a good marketing tactic. Regards, Steve Björn Helgason wrote: > I have always been a bit surprised how APL lost out to spreadsheets > > APL had it al except the presentation part > > J has been much better and the Grids are a good step in the right direction > > The spreadsheet wars are hotting up with Google now entering > > http://www.google.com/googlespreadsheets/tour3.html > -- Steven H. Rogers, Ph.D., [EMAIL PROTECTED] Weblog: http://shrogers.com/weblog "He who refuses to do arithmetic is doomed to talk nonsense." -- John McCarthy -- For information about J forums see http://www.jsoftware.com/forums.htm -- For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] spreadsheets
Spreadsheets are often used to edit, view, and present data with little actual computation performed on spreadsheet values. While APL and J are "better" at most computations, spreadsheets are "good enough" for most people's needs. Focusing on J Grid development to make it a tool for this type of application that people would use even if they don't know J might be a good marketing tactic. Regards, Steve Björn Helgason wrote: I have always been a bit surprised how APL lost out to spreadsheets APL had it al except the presentation part J has been much better and the Grids are a good step in the right direction The spreadsheet wars are hotting up with Google now entering http://www.google.com/googlespreadsheets/tour3.html -- Steven H. Rogers, Ph.D., [EMAIL PROTECTED] Weblog: http://shrogers.com/weblog "He who refuses to do arithmetic is doomed to talk nonsense." -- John McCarthy -- For information about J forums see http://www.jsoftware.com/forums.htm
