[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Rethinking jjramsey idea
---Scott Wedel <swedel@Tymnet.COM> wrote:
>
>
> J. J. and I had what I thought was a pretty good exchange and I think
> came up with a pretty good idea.
>
> The issue is that typically when copying a block that you get a
> copy of the expressions in each cell. If at a later time you
> want to modify one of these expressions and have it affect all
> copies as well then you have to edit every copied cell as well.
>
> A nice feature to solve this would be to create a new operator on
> a block which converts every cell to a systematically automatically
> named set of functions. Thus, when that block (or portions of that
> block) is copied then one is copying personalized functions and so
> one can edit the function and change all copied cells. example:
> one selects a block of cells (say a 3x6 region) and says "functionize"
> which then prompts for starting function name to which I say
> HOME_BUDGET at which point expression in R1C1 of selected block is
> replaced with HOME_BUDGET_R1C1(vars,,,). The expression in R1C1 is
> made into function HOME_BUDGET_R1C1 with relative cell references
> being passed as args (so a copy can keep then as relative references).
>
There's one thing that's starting to bug me about this idea. One, I'm
not entirely sure if siag has a convenient way of editing functions. I
thought that the way one would edit a function would be to open up the
file containing the function in a text editor and directly edit the
function code. Maybe I'm just missing something here, so if anyone can
clear me up on that, I'll be glad to hear it.
The other thing is that it doesn't quite answer a thought that has
been bugging me ever since I read Christopher Brownes's 'opinionated
rant' on spreadsheets
<http://www.hex.net/~cbbrowne/spreadsheets.html>--namely, the
unstructured nature of spreadsheets. I don't want to sound like I'm
trying to sound like an expert, because I'm not, but it's a thought
that I've batted around in my head, and it was sort of reflected in
the somewhat confused e-mail I sent to the siag mailing list called
"Idea on how to implement named ranges in Siag."
Here are some ideas, hopefully better than the ones I proposed last
time, for adding structure to spreadsheets. At least some, and I think
maybe all, came up in the e-mail discussion between me and Scott Wedel:
1) Allow row and column indices to be labels, not just integers, so
that, for example, the tops of the columns could read 'Quarter 1',
'Quarter 2', etc., and also so that one could make a cell reference
like (get-cell Totals December).
2) Allow one spreadsheet to retrive values from cells from another
spreadsheet. I believe this is already done, using the x-get-cell
function. I know that this function could also be used to promote
spaghetti logic, so I'll explain myself later.
3) Allow the number of rows and columns in a spreadsheet to be limited
to the number of rows and columns that actually contain data. This
wouldn't create any structure itself, but it would be helpful if one
were to store a single column vector in a spreadsheet; one could have
the spreadsheet have one column and just enough rows to contain the
data, and not have to worry about wasting hard disk space or memory.
Of course, it would be prudent to allow one to add rows and columns to
the spreadsheet as necessary.
None of these guarantee structure, but they allow a user to create it
more easily. One, I can store the data I want to manipulate in a
spreadsheet separate from the spreadsheet I actually manipulate it in.
Two, I can better see what I'm doing, since I'm using more descriptive
cell references.
I'm throwing these ideas out to see what you think, how they could be
improved, what you might add to them, subtract from them, whatever.
--J. J.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com