I know...
there is a lot of programs doing table calculations excell-style, but this
is different :-)
Use your favorite matrix writer/editor to create a matrix excell sheet-like
style.
Formulas, functions, external variables, even links to other tables or lists
are supported.
Fields in those tables or lists may be a result of their own calculations
(can evaluate sheets recursively).
Since forms give lists as a result of entry, you can combine your INFORM
form data in to lists and process the data
using a list of lists and MXeval.
NOTE: library is in the early stage and not yet optimal so... all
precautions advised :-)
Check out ARM/Saturn section (or news):
http://fly.srk.fer.hr/~manjo/openfire
...later,
manjo
** MAJOR NEWS !!!
> Use your favorite matrix writer/editor to create a matrix excell
> sheet-like style.
> Formulas, functions, external variables, even links to other tables
> or lists are supported.
> Fields in those tables or lists may be a result of their own
> calculations (can evaluate sheets recursively).
> Since forms give lists as a result of entry, you can combine your
> INFORM form data in to lists and process the data
> using a list of lists and MXeval.
>
> NOTE: library is in the early stage and not yet optimal so... all
> precautions advised :-)
Oh..it's Alpha? (not Beta)
> Check out ARM/Saturn section (or news):
> http://fly.srk.fer.hr/~manjo/openfire
>
> ...later,
> manjo
There will be a few "most wanted" programs
and this certainly will be a metalist - medalist
VMRL of the 50G, please?
(the golden model is too shiny - it hurts my eyes)
Point taken, will do :-)
-when i get some extra-spare time :-)
manjo
AFTER the spreadsheet is finished, please!
(or just for relaxing, get Santa Fe stay Babooza)
:-D
Updated the MXeval
added:
-type checking
-error checking
-error messages
It is stable and quite safe to play with :-)
manjo
http://fly.srk.fer.hr/~manjo/openfire
Marvellous!
but...AXL already does this or...?
M->L (Matrix to List)
-converts matrix to list (sometimes usefull)
True :-(
i was not aware of AXL so... M->L is not needed OR
usefull for people (like me) not aware of AXL :-)
-i think i should remove M->L what do you think ?
manjo
-removed M->L (built in AXL does the same thing)
-added argument checking, error checking, and error messages
-added sequences for MGET
Example:
---------
[[1 2 3]
[4 5 6]
[7 8 9]]
'A1-B3' MGET
will return 1 2 4 5 7 8
'B2-B3' MGET
will return 5 8 etc...
have fun :-)
manjo
http://fly.srk.fer.hr/~manjo/openfire
Aaaah!
Now just the relative addressing
(using variables or matrix element value)
and we are very close to a spreadsheet
****************
Doesn't anyone else even try this?
*****************
Just use stored matrices for your calculation formulas
and recall them to stack for MatrixEVALuation
very very nice
--
Veli-Pekka
PS:
Special Thanks to Manjo!
Library commands:
MEVAL
MGET
MPUT
MGET and MPUT both capable of sequencing cells of course with compatible
syntax
Example (assuming you have 3x3 cells matrix or list):
DUP 'A1-C1' MGET 2 * 'C1-C3' MPUT
-takes cell sequence from A1 to C1 (first row) multiply these by 2 and put
them in to cells C1 to C3 (third column)
as you can see MPUT very nice and flexible.
(more in the readme.txt included with the MXeval package)
have fun !
manjo
http://fly.srk.fer.hr/~manjo/openfire
Fantastico!
How could one implement relative references in the matrix?
Can other users also say "thanks" to Manjo, please?!
--
Veli-Pekka
PS:
I used TRAN to solve the row/column order problen
eg.
M1
TRAN
MEVAL
TRAN
You don't need flags or a new command
just updated "manual"
:-D
> Example:
> ---------
> [[1 2 3]
> [4 5 6]
> [7 8 9]]
>
> 'A1-B3' MGET
> will return 1 2 4 5 7 8
Compare with
[[1 2 3]4 5 6 7 8 9] {1 1} {3 2} SUB
-or-
[[1 2 3]4 5 6 7 8 9] 1 8 SUB
(optionally followed by OBJ\-> DROP)
VPN> Doesn't anyone else even try this?
Have you ever looked at the SUB command in the AUR?
I'm sure that MX does a whole lot more than is built in,
but now and then we forget how much is already built in!
(in this case going back at least to the HP48SX in 1990)
--
Flashback to 1990-1991:
"A TI rep at the Consumer Electronics Show stated to me
that the TI 85 is trying to compete with the 48S,
not the 48SX (which has no competition from anybody)"
[JKH, per http://www.finseth.com/hpdata/hp48s.html]
> Example (assuming you have 3x3 cells matrix or list):
> take cell sequence from A1 to C1 (first row)
> multiply these by 2 and put them
> into cells C1 to C3 (third column)
[[1 2 3]4 5 6 7 8 9]
DUP {1 1}{1 3} SUB 2 * {3 1} SWAP REPL
Array coordinates may be specified
either as {row col} or as the element number
(the latter in the same order as OBJ\-> produces).
The HP48G-series designers were ahead of their time
(and way ahead of TI), and it's all still in there.
These array functions do not handle "lists of lists," however
(except when convertible to "array" via AXL,
which is disallowed for non-algebraic object elements),
so it would be cool to extend that gap, if possible
(perhaps some of the built-in ROM functions
that work for arrays could be used as helpers).
[r->] [OFF]
-i am aware of most built in things (was not aware of AXL though :-)
-as i stated in readme.txt (in the package) my goal is to use as much as
possible from built in functions, objects and tools
-just enhanced those aspects i thought would be usefull
Although your statement of built-in functions DOESN'T DO what was intended
NOTE: "take first ROW, multiply by 2 and put in to third COLUMN"
let's still compare the 2 :
----------------------------------------------------------------------------
DUP {1 1}{1 3} SUB 2 * {3 1} SWAP REPL (total of 9 objects)
DUP 'A1-C1' MGET 2 * 'C1-C3' MPUT (7 objects)
My point of view:
------------------
It is easier for me to type in 'A1-C1' rather than {1 1} {1 3} not to
mention that
A1-C1 is more intuitive and spredsheet-like
note: 'A1-C1' can be a result of simple symbolic function or equation
{1 1} {1 3} will hardly be a result of simple equation
MPUT actualy does much more than REPL :
-works on list of lists as well as matrices
-replaces or fills rows, columns, areas or single cell with : numeric, list
of objects,
or pattern
-note statement of built in commands has SWAP REPL -no need for SWAP
MPUT (MPUT is ready to use output from MGET)
-not much, but nice :-)
For examples on MPUT look it up in readme.txt
Conclusion:
------------
Shorter and more friendly looking statements, meaning less and easier
typing.
Works on both matrices and list of lists therefore MXeval can be considered
as a uniform way to manipulate both matrices and lists.
With only 3 (soon 4) commands doing nifty stuff i do belive it is worth
installing a library not greater than 1.7k
Can we agree on that ? :-)
Finally lookout for "fourth command" which will do
specialy-extra-ordenery-wonderfull-obvious-simple BUT nice stuff !!!
In order to find out what... stay tuned :-)
manjo
http://fly.srk.fer.hr/~manjo/openfire
P.S.
If you are good... maybe you will see the Smurfs as well :-)
> NOTE: "take first ROW, multiply by 2 and put into third COLUMN"
I misread; sorry.
[[1 2 3]4 5 6 7 8 9]
DUP {1 1}{1 3} SUB 2 * TRN {1 3} SWAP REPL @ using {row col}
-or-
DUP 1 3 SUB 2 * TRN 3 SWAP REPL @ using single element numbers
> note: 'A1-C1' can be a result of simple symbolic function or equation
> {1 1} {1 3} will hardly be a result of simple equation
I once used a Unix spreadsheet whose developers thought
that columns are better calculated with numbers
than with letters (where Z is followed by AA etc., in base 26),
but of course Microsoft always wins in the end :)
{row col} converts to element number as 'ncols*(row-1)+col'
which in turn can be encapsulated into an internal function
[but row col 2 \->LIST is simpler, since 'ncols'
isn't then required to be calculated by the user].
> Works on both matrices and list of lists
I meant only to illustrate, for those not yet aware,
that there are built-in functions which work on arrays
in exactly this manner,
and welcomed any extension to generalized lists,
which it seems you have already done
(though using a different grammar),
so nice job!
> Can we agree on that ? :-)
I wasn't actually aware of disagreeing, so I guess so :)
[r->] [OFF]
> This does not go far enough.
Some see a glass half empty; others a glass half full :)
-[ ]-
Hello Francisco,
-nice of you to show interest in the subject
You seem to be very critical about usefulnes :-)
MXeval is intended first and foremost for programing and for people who are
not too demanding about
interface these people will be happy to use built in matrix writer and
lists/matrices.
It could have a nice grid-like graphics interface, but then without a mouse
for convenient control
the usefulnes of over-advanced interface is questionable :-)
Further all other commands, CAS, vector operations and so on...
are all based on commands (no graphics interface... so...)
That's why i decided to make a small library of flexible commands which will
come handy for matices and lists manipulation.
Actualy it is quite powerfull in all its simplicty :-)
It's nice to see that VPN understood the idea right from the start :-)
manjo
The 4-th command is: MSPREAD
Q) what it does you ask....
A) something wonderfull :-)
assume the following matrix :
[[1 2 3]
[4 5 6]
[7 8 9]]
'B1-B3' MSPREAD will spread the B1 cell trough B colum so it will become "2"
'B1-C2' MSPREAD will spread the B1 cell in 4 upper right cells and so on
this is all as expected
BUT:
assume this one:
[['A2+A3' 2 3]
[ 4 5 6]
[ 7 8 9]]
'A1-C1' MSPREAD will treat cell addresses as relative and adjust your
formula acordingly
it's using CAS to do it -so you can knock yourself out with the complexity
of your formula :-)
if CAS can handle it MSPRED will as well.
Of course in this case you will end up with following matrix:
[['A2+A3' 'B2+B3' 'C2+C3']
[ 4 5 6 ]
[ 7 8 9 ]]
enjoy your matrices and lists :-)
manjo
Hello John H. :-)
-i was not so critical about this (like it may looked like)
-once you get to know me you will not take me so seriously :-)
no hard feelings...
manjo
MX uses Spreatsheet syntax
and thus nicely complements the SUB command
I like it!
"manjo" <not-avail...@rocketmail.com> wrote in message
news:ehn2s2$ocl$1...@ss408.t-com.hr...
I think that professor Wolfgang Rautenberg would agree that
i hope i did :-)
i guess i did :-)
see you later
have fun !
manjo
> are now:
> HPGCC 3.0 by ...many many people
> MXEVAL by Manjo
> Steen Smiths Spacial FUnctions (or whatever) library using C-language
X
Special Functions
It seems that my PC keyboard is
"Made in China"
(or was that the place where my parents spend their honeymoon?)
> assuming you have 3x3 cells matrix or list,
> take cell sequence from A1 to C1 (first row)
> multiply these by 2 and put them
> into cells C1 to C3 (third column)
Corrected solution(s), using built-in commands:
Sample initial array:
[[ 1 2 3 ]
[ 4 5 6 ]
[ 7 8 9 ]]
DUP {1 1}{1 3} SUB 2 * TRAN {1 3} SWAP REPL @ using {row col}
-or-
DUP 1 3 SUB 2 * TRAN 3 SWAP REPL @ using absolute element numbers
Result is:
[[ 1 2 2 ]
[ 4 5 4 ]
[ 7 8 6 ]]
> These array functions do not handle "lists of lists,"
> however (except when convertible to "array" via AXL,
> which is disallowed for non-algebraic object elements),
> so it would be cool to extend that gap, if possible
> (perhaps some of the built-in ROM functions
> that work for arrays could be used as helpers).
Here is a crude replacement for AXL,
which removes that bothersome restriction,
permitting non-algebraic objects as elements:
\<< IF DUP TYPE 5. == THEN
1. \<< DUP TYPE 5. == { #16A006h FLASHEVAL } IFT
\>> DOLIST #16A006h FLASHEVAL ELSE AXL END \>> 'LXA' STO
Using LXA, you can now start with a list [of sub-lists],
change it to an array, and then use the built-in SUB and REPL
commands, which have the special abilities used above when
applied to arrays (SUB extracts any rectangular sub-array,
defined by two opposite corner elements, REPL overlays
any sub-array onto another array at any position,
TRAN can be used to transpose, and -91 SF EDITB will edit).
For example, to perform the original challenge upon *lists*
{ { A B C }
{ "D" "E" "F" }
{ "G" "H" "I" } }
we can now do LXA DUP 1 3 SUB 2 * TRAN 3 SWAP REPL LXA,
producing
{ { A B 'A*2' }
{ "D" "E" 'B*2' }
{ "G" "H" 'C*2' } }
And LXA was only 115.5 bytes :)
Though we don't need it, here also is Michael Hoppe's elegant
UserRPL to directly transpose a "list of lists," just to admire :)
\<< LIST\-> DUP \-> n \<<
\<< n \->LIST \>> DOLIST \>> \>> @ 52 bytes
Hope it was interesting to discover perhaps unknown capabilities
that have always been built in, just as there are in all of us :)
Best wishes from http://www.mum.edu
and http://www.maharishischooliowa.org
> This is why I value John so much
So bid -- I'm now "for auction" on eBay all this week;
note than non-domestic postage and handling
(by First Class airfare) will be determined after sale :)
> If he only could speak ()write) Finnish...
How about Elvish?
http://www.elvish.org/
Yours truly,
Findecáno Lúinwë
(according to http://www.chriswetherell.com/elf/)
P.S.:
Go to http://www.chriswetherell.com/hobbit/
and insert "Brother" "Peter" :)
but still, MXE's MPUT does a just bit more than REPL :-)
also there is MEVAL and not to forget MSPREAD, spredsheet-type addresses are
nice :-)
-you pointed out some very good ideas which could make MXE even smaller
-i hope you don't mind if i use some of those to optimize MXE ?
see you later,
manjo
MXE is ment to be used with built in matrix writer -it has NO editor of its
own
(for my purpose matrix writer is great -can hardly imagine something better)
John H. did you try MXE ?
-please do, and i promise -you will get hooked or sure :-)
Ability to write formulas inside the table with that familiar 'A1+B4' syntax
will bring you very close
to the feeling of working with true spredsheet application.
MSPREAD is realy great for larger tables and repeating formulas or data
-almost as if you would clone your cell down the column (or row for that
matter) in trusty Excell :-)
-it would be great if we would have a mode similar to 2 FIX which would
completely ignore the decimals past 2nd
(all calculations would be done strictly in 2,3 ... whatever decimal paces)
Imagine processing long table of statistical data:
-write a single formula
-spread it across and MEVAL
Of course with not much trouble you could write a simple program to do the
sam job, but why bother when you can do it without programming !?
Need to adjust the formula ?
-no need to edit your program
-just modify your original formula in the table and MSPREAD again
Already wrote simple "applications" (tables)
-i just punch in few numbers and it gives me complete invoice with
intermediate results, taxes etc :-)
-even added formatting to final and intermediate results (like: bold,
inverse, underline... etc) all inside single table and familiar syntax.
(matrix writer seems to have no problems with formatting, although text
formatting will not be intuitive to some :-)
Example:
In matrix writer when you edit your string cell hit TOOLS button and NXT to
Style and there you have it
manjo
P.S.
i think i'm getting a bit euphoric about this MXE stuff :-))
4) if you plan to use MXE as a tool for matrix manipulation in your regular
work
rather than programming you could add key assignments:
You could bind keys to commands:
------------------------------------
[hold-shift]-[EVAL] could MEVAL
[hold-shift]-[UP ARROW] it would MPUT
[hold-shift]-[DOWN ARROW] it would << DUP MGET >> (so you can MPUT back easy
without the need to DUP with ENTER)
[hold-shift]-[RIGHT ARROW] it would MSPREAD
or [hold-alpha] variation if you use the above keypress combinations for
other things
so you would just write sequences to render the table and push buttons :-)
this is soo much fun... even better than the real thing :-)
manjo
NOW
you have updated your documentation
but...
what do I assign to Shift-hold LEFT arrow ???
eg.
What is your next command?
perhaps MCOUNT to count values between 'D3-G2'
so one can calculate MMEAN of those values?
should all the commands start with "M" ?
Now I got it: Adress translation commands!!!
Change { 5 3 } to 'E3' and back
M~ADDR (or simply M~A)
that way one mix & match the programs inside a matrix
so one could calculate statistics using ordinary GET
and then store into SigmaDAT and do some math
and then put the results back
seems cumbersome and a lot of work
but it can be done
also other system commands can be embedded
as long as the M~ADDR (or simply M~A)
makes it easy to change the addressing style
--
Veli-Pekka
Did I already metion that I like this application...
:-D
Attolma i menelessie, nai airitainiéva esselya.
Nai ardalya tuluva.
Nai Ãrelya tyarniéva mardesse ve menelesse.
Anta men sÃre ilyaurea mastalma.
Ar avanta men raikalmar ve avantalme raikatyarolmain.
Ar nai útukuvalye me mailenna
ná fainu me ulkallo
Amen
> Yours truly,
>
> Findecáno Lúinwë
> (according to http://www.chriswetherell.com/elf/)
>
> P.S.:
>
> Go to http://www.chriswetherell.com/hobbit/
> and insert "Brother" "Peter" :)
I prefer Veli-Pekka Nousiainen
:-D
Ponto Brandybuck of Buckland
Did you try the examples (included files) ?
yes that's my heading (pirate talk)
i will most probably do a cell address translation
this way it will be more integrated (compatible) with built in commands.
most of the commands will start with M so that they will be grouped in the
CAT menu AND
they will be less mixed up with other commands.
stay tuned and enjoy :-)
manjo
I'm holding breath while I wait for the new command
to translate the cell addresses
M~A
Veli-Pekka
the Great Manjo Fan Club number #1
> Change { 5 3 } to 'E3' and back
Well, it's 'E3' <-> { 3 5 } and 'Y12' <-> { 12 25 }
\<< S~N DUP TAIL STR\-> I\->R SWAP NUM 8. SQ - 2. \->LIST \>>
\<< LIST\-> DROP 8. SQ + CHR SWAP R\->I \->STR + S~N \>>
The first character gets dicey after Z :)
[r->] [OFF]
> Ability to write formulas inside the table
> with that familiar 'A1+B4' syntax
> will bring you very close to the feeling
> of working with true spredsheet application.
Yes, nice idea.
Are you handling all possible formulas
(all functions, nested parens, etc.)?
What about circular dependencies during evaluation?
Use of built-in array editor,
with library commands for operations,
would seem to simplify things.
[r->] [OFF]
> I'm holding breath while I wait for the new command
Don't turn blue!
http://www.soka.nu/filmer/bigblue/index-e.shtml
Here is a calculation which no one can avoid;
let's hope the right answers are found:
http://www.bloomberg.com/apps/news?pid=20601086&sid=asybYkLBp_tk
[r->] [OFF]
\<< CASE DUP TYPE 6. == THEN
S~N DUP TAIL STR\-> I\->R SWAP NUM 8. SQ - 2. \->LIST
END DUP TYPE 5. == THEN
LIST\-> DROP 8. SQ + CHR SWAP R\->I \->STR + S~N
END LIST\-> END \>>
Examples:
'E3' <-> { 3 5 } and 'Y12' <-> { 12 25 }
No warranty after column Z :)
[r->] [OFF]
Combined into a single "toggle" program:
\<< DUP TYPE 6. == {
S~N DUP TAIL STR\-> I\->R SWAP NUM 8. SQ - 2. \->LIST } {
LIST\-> DROP 8. SQ + CHR SWAP R\->I \->STR + S~N } IFTE \>>
Examples:
'E3' <-> { 3 5 } and 'Y12' <-> { 12 25 }
Warranty void after column Z :)
[r->] [OFF]
Of course it handles all possible formulas, all math functions supported. It
works with symbolics as well
(not only numbers)
The issue may come up if you LINK 2 or more tables in cycle :-) but that
will not happen in normal work
(only if you want to kill the concept :-)
other cases will work as expected.
> Use of built-in array editor,
> with library commands for operations,
> would seem to simplify things.
Of course built in editor is great that's one of reasons why i choose not to
write my own.
-try the examples i included in the last version of the MXE package
-i think you will like those :-) some are quite fancy looking :-)
manjo
Hello John H.
Yes, i understand :-)
but not a problem for MEVAL can handle columns past Z (no error checking
there) :-)
-not sure but most likely all the way to y with dots :-) (chr 255)
i will rather do 2 separate commands so that code would be more readable :
MCELL-> and ->MCELL (or maybe shorter ->MC MC->)
like R->B and B->R or
HMS-> and ->HMS
also i will have MSEQ-> and MSEQ-> (->MS and MS-> for short) which will
convert pairs to sequences:
{1 3}
{2 2}
->MSEQ will do 'C1-B2'
manjo
> The issue may come up if you LINK 2 or more tables in cycle :-)
See http://en.wikipedia.org/wiki/Spreadsheet
http://www.arulesxl.com/docs/manual2/introduction.htm
Very simple situation:
Cell Contents
---- --------
A1 'A2+1'
A2 'A3+1'
A3 'A4+1'
A4 'A5'
A5 'Sigma(n=B1,B2,n^2)'
There's no predicting in advance what dependencies will turn up
during evaluation, so unless you prohibit such "chaining,"
some general evaluation strategy is needed,
including how to detect (or limit) any "cycle"
[r->] [OFF]
[for columns after Z]
> not a problem for MEVAL can handle columns past Z
> (no error checking there) :-)
It's when the user tries to create or edit any formula
involving any cell in some columns past Z
that the problem may arise.
For example, with only a 1-character column name,
a formula involving the value in row 1, column 27
would need to be composed using a variable name '[1'
whereupon "Invalid syntax" would occur.
A somewhat fancier parsing function could of course
deal with the leading alphabetic portion
of a cell name as a kind of "base26" number,
using "digits" A-Z as 1-26 (no zero),
as is done by those commercial products,
but the elementary UserRPL example I posted
assumed a leading portion of exactly one character.
You could always announce a 26-column limit for now,
and if someday there arises demand for more,
then you could simply enhance the parsing function
at that time :)
[r->] [OFF]
> There's no predicting in advance what dependencies will turn up
> during evaluation, so unless you prohibit such "chaining,"
> some general evaluation strategy is needed,
> including how to detect (or limit) any "cycle"
Hello,
I was not lasy so i punched something like that
of course i added the B column {1 2 3 4 5}and i have no Sigma function so i
just put in 'B1+B2' -it's all the same actualy.
The result:
Actualy the result was not so weird, it is logical.
Important is that it did not break the calculator :-) !!!
The problem was with A4 field, here's why :
it references the A5 (via ID) at the time when it is evaluated it pulls out
the FORMULA, A5 IS a formula
A3 takes the reference to A5 which is FORMULA and evaluates it actualy
substitutes A4 with contents of A5 which is formula :-) and so on....
When all is done you will notice A4 unevaluated:
here are 2 workarounds for your case:
1) either write 'A5+0' in to A4 or
2) MEVAL the table once again, and there you are :-)
Let's face it -your chain is not everyday like:
-A4 value you already have in A5 so why not chain all to A5 ?
Like you said there is no chance i could tell in advance what possible pit
will be layed in the table.
It doesn't break the program, it has logical explanation... so why bother ?
Look on practical side of the thing: you can preserve formula unevaluated in
any field that way
showing used formula in the result table :-)
I belive to disable chaining would be kinda limiting.
manjo
True at this time
MXE is only 26 columns wide which is not so small after all :-)
I was also thinking about RxCy format of addresses
but i had my doubts about how practical would formula with trigonometry or
something fancy look like
when arguments where (SIN(R1C2/R5C17)+COS(R45C2^2))^R7C6
Here's what i CAN promise
-if i decided the RC format (at that time) i would'n call it MXE i would
rather call it R2D2 :-)
see you later,
when i finish optimising this thingy it will be a real beauty
(even smaller and even faster)
and VPN will jump all over the Finland :-)
thanks for your ideas & thoughts
manjo
> Cell Contents
> ---- --------
> A1 'A2+1'
> A2 'A3+1'
> A3 'A4+1'
> A4 'A5'
> A5 'Sigma(n=B1,B2,n^2)'
> When all is done you will notice A4 unevaluated
Shouldn't a cell containing another cell's name
be treated exactly the same
as if that name were a formula (which it really is),
and be replaced with the value?
(Isn't this an easy fix? Why make the user work around it?)
The CAS also has to be alert to this, generally
treating names as equivalent to very simple formulas :)
It all sounds great; hope I've not been too bothersome :)
[r->] [OFF]
> I was also thinking about RxCy format of addresses
> but i had my doubts about '(SIN(R1C2/R5C17)+COS(R45C2^2))^R7C6'
Good decision :)
[r->] [OFF]
@ {{1 2}{3 "4"}} <-> [[1 2][3 "4"]] [allowing any objects]
\<< -91. SF IF DUP TYPE 5. == THEN
1. \<< DUP TYPE 5. == { #16A006h FLASHEVAL } IFT
\>> DOLIST #16A006h FLASHEVAL ELSE AXL END \>> 'LXA' STO
@ 'Y12' <-> { 12 25 }
\<< DUP TYPE 6. == {
S~N DUP TAIL STR\-> I\->R SWAP NUM 8. SQ - 2. \->LIST } {
LIST\-> DROP 8. SQ + CHR SWAP R\->I \->STR + S~N } IFTE \>>
'MCOORD' STO
@ [[...]] -> DUP then EVAL
\<< DUP TYPE 5. == { LXA } IFT
'M.dir' DUP PGDIR DUP CRDIR EVAL
DUP SIZE LIST\-> DROP \-> r c
\<< 1. r FOR r 1. c FOR c
r c 2. \->LIST DUP2 GET SWAP MCOORD STO NEXT NEXT
DUP 1. r FOR r 1. c FOR c
r c 2. \->LIST DUP2 GET EVAL PUT NEXT NEXT
UPDIR 'M.dir' PGDIR \>> \>> 'MSEVAL' STO
Then try:
{{'B1+B2' A2 'Y8' }
{ 2 5 'A1+B1+C1' }} MSEVAL
Yes, 'Y8' is "external" to the spreadsheet itself
(perhaps you've stored it elsewhere :)
Calculation is faster if executed in the "hidden directory"
(or in a user directory at the end of HOME).
Error checking is minimal or non-existent
(left entirely to the inherent safety of UserRPL :)
[r->] [OFF]
@ [[...]] -> DUP then EVAL
\<< DUP TYPE 5. == { LXA } IFT
'M.dir' DUP PGDIR DUP CRDIR EVAL
DUP SIZE LIST\-> DROP \-> r c
\<< 1. r FOR r 1. c FOR c
r c 2. \->LIST DUP2 GET SWAP MCOORD STO NEXT NEXT
DUP 1. r FOR r 1. c FOR c r c 2. \->LIST DUP2 GET
{ 6. 9. } OVER TYPE POS { EVAL PUT } { DROP2 } IFTE
NEXT NEXT UPDIR 'M.dir' PGDIR \>> \>> 'MSEVAL' STO
Now we can do:
{{'B1+B2' A2 8 "ABC" }
{ 2 5 'A1+B1+C1' "XYZ" }} MSEVAL
[r->] [OFF]
Actualy it is a simple fix,
-the only problem is that it is breaking of the general roule :-(
the fix is:
if it is ID -evaluate 2twice
(first to pull out the formula and second time to evaluate it)
it would work fine, but then
-what if somone has put inside that field an ID which is linked external to
a program
which does something which SHOULD NOT be evaluated twice
You see my issue with this ?
that's why this behavior must be set as a roule of thumb (a standard)
-even if it doesn't work for few special cases
I don't want to limit this just for numbers and formula crounching inside
the single table
i need this flexible -execute programs inside cells or links etd...
At this time i will let it be as is.
There is other thing that concerns me :
when you use matrix writer for lists editing -91 SF it automatically
converts matrices to lists of lists
so i wonder if there is any use for me to handle lists AND matices. I tried
some sysRPL commands
to make "dirty" matrices -they seem fine but these are almost useless in
usrRPL.
That's why i'm close to idea to focus on list of lists only -any thoughts ?
manjo
> Actualy it is a simple fix,
> -the only problem is that it is breaking of the general rule :-(
>
> the fix is:
> if it is ID -evaluate 2twice
> (first to pull out the formula and second time to evaluate it)
>
> it would work fine, but then
> -what if somone has put inside that field an ID
> which is linked external to a program
> which does something which SHOULD NOT be evaluated twice
> You see my issue with this ?
Begin
ID? -> RCL (or leave as ID if non-existent)
Formula? -> EVAL
Repeat until nothing changes.
Include program under "Formula" if desired.
What if a *formula* contains a variable name,
and the variable contains a program?
What about 'variable(args)' ?
> that's why this behavior must be set
> as a rule of thumb (a standard)
> -even if it doesn't work for few special cases
Have you seen my working MSEVAL program?
> At this time i will let it be as is.
"Let it be, let it be..."
http://www.allspirit.co.uk/let.html
http://en.wikipedia.org/wiki/Let_It_Be_(song) [see "Origins"]
http://en.wikipedia.org/wiki/Let_It_Be_(album)
http://en.wikipedia.org/wiki/Let_It_Be_(film)
> There is another thing that concerns me :
> when you use matrix writer for lists editing -91 SF
> it automatically converts matrices to lists of lists
[when you press ENTER to conclude MW]
> so i wonder if there is any use for me to handle lists AND matrices.
Yes, because it's perfectly legitimate to have an array
containing only numbers, symbols and formulae,
which can be edited without flag -91 and remains as an array.
> I tried some sysRPL commands to make "dirty" matrices
> -they seem fine but these are almost useless in usrRPL.
Except for how SUB and REPL depend on using the "array" type,
as well as the GET and PUT used in the just-posted
UserRPL 'MSEVAL' program :)
> That's why i'm close to idea to focus on list of lists only
> -any thoughts ?
Besides that if a matrix is offered, you could start by doing AXL?
It's too late for thinking; let's "just do it" :)
[r->] [OFF]
Actualy your MSEVAL is on the same trail like MEVAL :-)
MEVAL is actualy brute force in 2 passes (3 steps) :-)
1) in the first pass it rolls out the table in to variables
2) in the second pass it evaluates the cells
3) finaly cleans up the mess :-)
of course my version is sysRPL with error catching and stuf so it should not
break and leave mess behind :-)
manjo
DUP
> Actualy your MSEVAL is on the same trail like MEVAL :-)
Never expected anything like that!
> MEVAL is actualy brute force in 2 passes (3 steps) :-)
> 1) in the first pass it rolls out the table into variables
I had been expecting something like doing \->LST on any
formulas (to get the RPL program), then evaluating each
element in turn, replacing any IDs corresponding to table cells
with GETting that cell's content, and iterating this evaluation
until no more substitutions were made -- because storing variables
is pretty "expensive" in execution time.
> 2) in the second pass it evaluates the cells
Storing variables puts the burden on the calc
to do much of the above, at the expense of all the time
it takes to store so many variables (and then purge again later),
especially when HOME is large (time is least when vars are
nearest the end of HOME, and the hidden directory is at the very end,
which is part of the clever OS design, using hidden vars all the time).
> 3) finaly cleans up the mess :-)
> of course my version is sysRPL with error catching and stuf
> so it should not break and leave mess behind :-)
No problem when a separate "temporary directory" is created,
since we can even manually just 'specialdir' PGDIR
(that's why I never bothered with IFERR..END)
So you're not doing fancy function evaluation,
just forcing the calc to do all the work by storing
every cell into its own var -- we're both lazy, then :)
I still don't see any problem with 'A1' being considered
a formula exactly like 'A1+0'; so that it would be
easier for a user to simply copy values; after all,
formula 'A1+0' is the list { A1 0 + }, and evaluating
that formula evaluates 'A1' anyway, and then adds 0 to that,
which is more than just evaluating 'A1' once.
See ya next time; G'day!
use the longer names, please - they are selfdocumenting!
A..Z is long enough for now
You can have almost unlimit number of rows
Perhaps later one could think of
A..Z then AA..ZZ
that is about 26+26^2 = 26+ (25+1)^2 = 26+ 625+50+1 = 26 + 676 = 702 columns
but why it's not needed so badly?!
Well, I used to have something like this:
A1...Z1 @ the explanation texts on 1st row
A2...Z2 @ column names on 2nd row
A3...An @ JANuary figures
B3...Bn @ FEBruary
C=MAR; D=APR; E=MAY; F=JUN;
G=JUL; H=AUG; I=SEP; J=OCT; K=NOV; L=DEC
M = Formula for RESult for the last year
N = Formula for RESult for the current year
O=JAN; P=FEB; Q= MAR; R=APR; S=MAY; T=JUN
U=JUL; V=AUG; W=SEP; X=OCT; Y=NOV; Z=DEC
Phew!
It did just fit - the rows are almost unlimited
IF I want to have next year predictions there as well
I TRAN the whole thing to use rows as months
BUT
then I have "only" 26 items per year
=> The limitations keep me innovative
*******************************************
I sum some columns in other spreadsheet to keep it simpler
OR
I simply use one year per spreadsheet
and then bring just the sums to the MAIN spreadsheet
Therefore there is no big limitations for me
I now have
last two years predictions and actual figures
current year and it's prediction
future prediction and corrected prediction (based on this years figures)
and a moving average row
that's 9 rows + the first row for explanations
Those nine rows will fit to one screen!
I usually have three columns
VPN
with time and if it will be interesting to more users to have such feature
as spreadsheet
i will spend time to optimize :-)
right... one has to sleep sometime too :-)
manjo
Of course i'm lazy
-that's the point isn't it ? :-)
of course i do use temporary directory in a very nice manner so it is
capable to
breakup as many tables as free memory allows.
Although i didn nothing special to allow this -i spent some time thinking in
advance if it will work :-)
I agree it would be a killer to purge each cell "by hand"
you see we actualy think very much alike :-)
as i said -for now i will settle with this version,
i will try to find a nice way to fix the ID -> formula thing.
see you later,
manjo
Don't fix it!
Expand it!
New feature of unevaueted elements
{ { "1st" "2nd" "Formula" "value"}
{ 0. 0. :D1: 'A1+A2' 0. } }
MEVAL will find a tagged value with tag :D1:
then it will EVALuate the formula
but the output goes to the cell speciafied by the tag :D1:
--
Veli-Pekka
> always use stack as much as possible
And yet, having it work at all (and ready now)
is of some value too.
One new thought for today is that if we *don't*
purge the variables (or a fixed temporary directory
which contains them), repetitions of the evaluation
with substantially the same content might be faster,
so consider the possibility of separating the cleanup
from the evaluation (also remove "up front" cleanup,
perhaps also shift it all to a "folder"
in the hidden directory), and see what happens.
[r->] [OFF]
Like the original 49G CATalog was faster after 1st lookup
cahing result and/or formulas is faster
especially if the parsing takes a long time
What do you think of the idea having
:RecultCellTag: 'Formula'
> [desired] new feature:
>
> { { "1st" "2nd" "Formula" "value"}
> { 0. 0. :D1: 'A1+A2' 0. } }
>
> MEVAL will find a tagged value with tag :D1:
> then it will EVALuate the formula
> but the output goes to the cell speciafied by the tag :D1:
Why not just put 'A1+A2' in the D1 cell?
The above would conflict with anything already in D1,
and it would also take up another cell's space, no?
In your example, it would in fact replace the title "value" :)
[r->] [OFF]
JHM:
> I still don't see any problem with 'A1' being considered
> a formula exactly like 'A1+0'; so that it would be
> easier for a user to simply copy values; after all,
> formula 'A1+0' is the list { A1 0 + }, and evaluating
> that formula evaluates 'A1' anyway, and then adds 0 to that,
> which is more than just evaluating 'A1' once.
Manjo:
> i will try to find a nice way to fix the ID -> formula thing.
What about the question above -- if 'A1+0' is okay to evaluate
(which has to start by evaluating 'A1' in the process),
why is it not okay to evaluate 'A1' and just skip adding a zero
to its result? Alternatively, one could assume that 'A1'
means 'A1+0' and always evaluate that instead.
I'd be interested in an example to illustrate
the sort of situation you have in mind,
where it makes a difference.
Since VPN has just suggested something about a tagged formula,
it so happens that the UserRPL 'MSEVAL' will not evaluate
tagged objects at all, so tagging (even eith an empty tag)
can be used to keep unevaluated formulas in the array.
Well, sorry to be like a fan in the grandstand,
yelling at the team manager to suggest strategy;
I just got interested in doing the same thing in UserRPL
(as always :)
Best wishes.
John H. >
I thing the difference is obvious :
'A1' is ID
'A1+0' is a symbolic
when ID is evaluated -only the content of A1 is recalled
when symbolic 'A1+0' is evaluated A1 is recalled within the symbolic and
evaluated (that's why it produces the expected result)
(actualy system works that way all the time)
VPN and John H >
I like the idea of having :D1:'A1+A3' VERY much !
-this is a thing for Tips and Tricks (VPN, you are a MXE instructor :-)
it's not that it has crutial use (true you can put 'A1+A3' in to the D1
field BUT) it is kinda more flexible supporting that feature
it would be a loss to limit this.
manjo
> when ID is evaluated -only the content of A1 is recalled
[unless it's another ID]
\<< IFERR WHILE DUP TYPE 6. == REPEAT RCL END THEN END EVAL \>>
'EVALany' STO
'2+3' 'A1' STO
'A1+0' EVALany
'A1' EVALany
[r->] [OFF]
@ Purge temp. directory [will use Hidden dir later]
\<< 'M.dir' PGDIR \>> 'MPURGD' STO
@ {{1 2}{3 "4"}} <-> [[1 2][3 "4"]] [allowing any objects]
\<< -91. SF IF DUP TYPE 5. == THEN
1. \<< DUP TYPE 5. == { #16A006h FLASHEVAL } IFT
\>> DOLIST #16A006h FLASHEVAL ELSE AXL END \>> 'LXA' STO
@ 'Y12' <-> { 12 25 }
\<< DUP TYPE 6. == {
S~N DUP TAIL STR\-> I\->R SWAP NUM 8. SQ - 2. \->LIST } {
LIST\-> DROP 8. SQ + CHR SWAP R\->I \->STR + S~N } IFTE \>>
'MCOORD' STO
@ 'A3-B1' <-> { 3 1 } { 1 2 }
\<< IF DUP TYPE 9. == THEN \->LST 1. 2. SUB
1. 'MCOORD' DOLIST LIST\-> DROP ELSE 2. \->LIST
1. 'MCOORD' DOLIST { - } + \->ALG END \>> 'MRANGE' STO
@ [[...]] -> DUP then EVAL (now re-use temp directory)
\<< -55. CF DUP TYPE 5. == { LXA } IFT
'M.dir' DUP IFERR CRDIR THEN DROP END EVAL
DUP SIZE LIST\-> DROP \-> r c
\<< 1. r FOR r 1. c FOR c
r c 2. \->LIST DUP2 GET SWAP MCOORD STO NEXT NEXT
DUP 1. r FOR r 1. c FOR c r c 2. \->LIST DUP2 GET
IFERR WHILE DUP TYPE 6. == REPEAT RCL END THEN END
IFERR EVAL PUT THEN DROP2 END
NEXT NEXT UPDIR \>> \>> 'MSEVAL' STO
{{'B1+B2' A2 'Y8' "ABC" }
{ '1+2' 5 'A1+B1+C1' "XYZ" }} MSEVAL
@ [End]
This gives "Error: Bad Argument Type":
[[5]] { 1 1 } "X" PUT
But this is fine:
[[5]] { 1 1 } [["X"]] REPL ==> [[ "X" ]]
So I've replaced all use of PUT by REPL
in the following elementary UserRPL implementation.
Flag -91 (use lists for arrays)
is set only if non-algebraic lists are input;
result (list or array) is of the same type as input.
Note that to avoid introducing potential dependence
upon the sequence of evaluation of individual cells,
all input should be taken only from the *original*
array, and all results should be stored only into
the *results* array, and not into the original array!
That's been strictly followed here, and syntax such as
D1=A1+B1 (via a "tag" in a cell *other* than D1 itself)
is for the same reason verboten, because it similarly
creates a potential dependence upon evaluation sequence,
no matter whether you decide to store it into the results
or into the original (or both!)
Saving the original into the Hidden directory likewise
creates a problem if we want to allow IDs of user
variables in the cells (it's a bit hard to search
upwards from the HD to a user subdirectory :)
so I've left the temporary directory in the
current path; much time is saved, however, if we
re-use the temp directory when re-evaluating an arrary
after minor edits, so the temp directory purging
has been made a separate command.
The nearer to the end of HOME is the current PATH
when you run this, the faster it will run (recent
ARM-based calcs, however, have an "accelerator"
which minimizes this effect).
@ Purge temp. directory
\<< 'M.dir' PGDIR \>> 'MPURGD' STO
@ {{1 2}{3 "4"}} <-> [[1 2][3 "4"]] [allowing any objects]
\<< -55. CF IFERR AXL THEN -91. SF
1. \<< DUP TYPE 5. == { #16A006h FLASHEVAL } IFT
\>> DOSUBS #16A006h FLASHEVAL END \>> 'LXA' STO
@ 'A3-B1' <-> { 3 1 } { 1 2 }
\<< IF DUP TYPE 9. == THEN \->LST 1. 2. SUB
1. 'MCOORD' DOLIST LIST\-> DROP ELSE 2. \->LIST
1. 'MCOORD' DOLIST { - } + \->ALG END \>> 'MRANGE' STO
@ 'Y12' <-> { 12 25 }
\<< DUP TYPE 6. == {
S~N DUP TAIL STR\-> I\->R SWAP NUM 64. - 2. \->LIST } {
LIST\-> DROP 64. + CHR SWAP R\->I \->STR + S~N } IFTE \>>
'MCOORD' STO
@ [[...]] -> DUP then EVAL
\<< -55. CF DUPDUP TYPE 5. == { LXA } IFT
'M.dir' DUP IFERR CRDIR THEN DROP END EVAL DUP SIZE
LIST\-> DROP \-> r c \<< 1. r FOR r 1. c FOR c
r c 2. \->LIST DUP2 GET SWAP MCOORD STO NEXT NEXT
1. r FOR r 1. c FOR c r c 2. \->LIST DUP2 GET
WHILE DUP TYPE 6. == REPEAT RCL END EVAL @ must exist
1. \->LIST #16A006h FLASHEVAL 1. \->LIST #16A006h FLASHEVAL
REPL NEXT NEXT UPDIR OVER TYPE 5. == { AXL } IFT \>> \>>
'MSEVAL' STO
@ Example (no need for 'A2+0' in cell B1):
{{'B1+B2' A2 4 "ABC" }
{ '1+2' 5 'A1+B1+C1' D1 }} MSEVAL
@ [End]
Check out ARM/Saturn section
http://fly.srk.fer.hr/~manjo/openfire
...later,
manjo
> and it would also take up another cell's space, no?
yes
> In your example, it would in fact replace the title "value" :)
Right on that one
{ { "1st" "2nd" "Formula" "value"}
{ 0. 0. :D2: 'A2+B2' 0. } }
but you can reuse the formula "as is"
don't you get it - am I 2 clever (once again)
Hello Manjo,
This looks great. Just to give you more ideas Did you ever take a look
to my CMTX library?
http://www.hpcalc.org/search.php?query=cmtx
Regards
Luis
---------------------
http://www.arrakis.es/~lboisset/hp49.htm
> Regards
>
> Luis
Hello Luis,
actualy i didn't i checked few other programs
and they all seemed quite different from what i had in mind so
i decided to give it a try with this experiment.
at first it was realy only experiment, but then it turned out quite
interesting to play with
VPN has thrown in some prity good ideas and here it is:
version 1.9
MSPREAD updated
-it respects the relative AND absolute addressing as well as external
variables when cloning cells
TAGGED formula functionality added (as defined by VPN) :-)
(read more in readme.txt)
So much for this time... enjoy your tables (i do) :-)
manjo
http://fly.srk.fer.hr/~manjo/openfire
NOW
it's time to ask one little favourite from HP
[ALPHA]&[EVAL] eg. -42.41 executes the 1st command from Manjos lib
(if that is where your MEVAL is)
so that the current matrix could be evalueted
WHILE
still in the Matrix Writer
OR
if Cyrille somehow can't help
CUSTOM eg. CST seems to be active during EDIIT and entry
so is it possible to use a TakeOver new version of MEVAL
(or you could have a different command MXEVAL just for that)
from a CST menu so it evaluetes the current matrix
=>
1st 2nd formula SUM
5 3 :D2: 'A2+B2' 8
Then one can change the numbers and MXEVAL again
*directly* from the MatrixEditor
I love this spreadsheet system - to my opinion it is simply the best
and fits to RPL expandability and philosophy just the right way
> http://fly.srk.fer.hr/~manjo/openfire
Warning:
I have to take a 35 hour sleep session during sunday
(I will BZ it in just 24 hours)
Needs to be updated so that it spreads the tagged formulas, too
AUTOIMATED example
Cell C3 is :D3:A3-B3
'C3-C5' MSPREAD
:D3:A3-B3
:D4:A4-B4
:D5:A5-B5
and after MEVAL
:D3:A3-B3 answer
:D4:A4-B4 answer
:D5:A5-B5 answer
so that that TAGGED fromula is really exploided to the max
> TAGGED formula functionality added (as defined by VPN) :-)
> (read more in readme.txt)
>
> So much for this time... enjoy your tables (i do) :-)
> manjo
> http://fly.srk.fer.hr/~manjo/openfire
I can't sleep.....
NOTE :
MSPREAD does spread TAGGED formulas only syntax of formulas used wiht
MSPREAD is more powerfull now
(you must prefix the cells which should be considered relative with $) in
above case $D3:$A3-$B3
but it could also be something like: $D3:($A3-$B3)*B1 (in B1 cell you would
be applied to all formulas as expected)
I was sleepeng in 2 terms :-)
-now wake again
-normal wake (not zombie wake like)
-yes i updated the automated sample but i just made it compatible with new
MSPREAD
we can't actualy re-use the formulas in AUTOMATED case because if you would
add a ROW once the
formula has been MSPREAD it would consider it as absolute and all spreaded
cells would have the same formula
It COULD be re-used ONLY if the table size would remain the same :-)
AUTOMATED is not perfect -just showing the application potential
manjo
TAG should be spread too - that is the whole idea of that expansion
Your magnificent application becomes a true spreadsheet
when both the tags and the formulas are MSPREAD
and when the formulas MEVALuated
are stored accorsing to the :TAG: designated cell
*THAT* will make it MxEval^2
(or version 2.0)
> MSPREAD is more powerfull now
> (you must prefix the cells which should be considered relative with
> $) in above case $D3:$A3-$B3
> but it could also be something like: $D3:($A3-$B3)*B1 (in B1 cell you
> would be applied to all formulas as expected)
> I was sleepeng in 2 terms :-)
> -now wake again
> -normal wake (not zombie wake like)
> -yes i updated the automated sample but i just made it compatible
> with new MSPREAD
>
> we can't actualy re-use the formulas in AUTOMATED case because if
> you would add a ROW once the
> formula has been MSPREAD it would consider it as absolute and all
> spreaded cells would have the same formula
> It COULD be re-used ONLY if the table size would remain the same :-)
Then some NOVAL or zero cell needs to be where the answers will be
also AUGMENT will work, no?
> AUTOMATED is not perfect -just showing the application potential
It does not have to be perfect, it is beautiful as it is
I made a little make-up (prettier now, huh?)
...
{{ the sheet}} MEVAL 'C3' "C" OVER SIZE R->I + STR-> - MSPREAD
...
Perhaps the lib version text was not updated
At least the date on Majos web-apge is still 20.10.2006
so he has forgotten the to update that too
I donno...zzzzzz....
Yeez :-(
Mea culpa !
I forgot to update the LIB file in the package :-(
-version 1.9 now available
(i hope :-)
manjo
with :D3: 'A3-B3' (and "" "Diff" 0. on D1 D2 D3)
the MSPREAD gave absolute formulas, eg.
:D3: 'A3-B3' 18
:D3: 'A3-B3'
:D3: 'A3-B3'
the formulas were absolutely MSPREADed
but the MEVAL calculated only the first formula
>>>> TAGGED formula functionality added (as defined by VPN) :-)
>>>> (read more in readme.txt)
with :$D3: '$A3-$B3' (and D1 as ""; D2 as "Diff"; D3 as 0. - just to be
sure)
the MSPREAD gave absolute formulas, eg.
:D3: 'A3-B3' 18
:D4: 'A4-B4' 11
:D5: 'A5-B5' 10
the formulas were MSPREADed correctly, but changed to absolute???
the MEVAL calculated all the formulas
I'm not sure about the behaviour
.I have to sleep more.....
zzzz
> I just got interested in doing the same thing in UserRPL
> (as always :)
John, I'm really glad that you are still interested in User RPL!
Sometimes I feel overwhelmed here, and your User RPL postings are
always a delight to read. You always inspire me to search for better
ways of doing it, which I never find, but the search is fun.
Meanwhile, thanks to all the brainiacs who are creating whiz-bang
goodies with HPGCC and other nifty tools! Many of us can't join in the
programming fun, but we sure enjoy using the results of your labor!
Thanks for sharing 'em!
-Joe-
Yes this looks very nice
-but it won't work rught if you don't add ROWs
if you don't add rows you would get:
C3-C3 which would automatically be evaluated by "-" (minus) to 0 "zero" and
program would break
that's why you should use + * / > < = whatever other operation.
Actualy i liked ">" it looks kinda logical :-)
'A1>C1' but i didn't decide for this because it's harder to type then "-" it
was :-)
BUT since the operation is ignored... you can use watever is the best in
your specific case.
manjo
MLINK (link to external table) example:
(links are tagged symbolics)
:mx1:'A1' MLINK
will evaluate mx1 table and return the A1 cell
:mx1:'A1-C1' MLINK
will evaluate mx1 table and return cells A1 to C1
to get values without evaluation use MGET:
:mx1:'A1' MGET or
:mx1:'B2-C3' MGET
if you don't want to recall the mx1 to stack, but you want to update cells
A1-C1 with zeros (or something else) you can:
{0} :mx1:'A1-C1' MPUT
or single cell:
0 :mx1:'C3' MPUT
Reminder:
when using MLINK mx1 can be ID of a program
(which should return a table acceptable by MXEval)
-fixed a small bug in MSPREAD
-everything else should work as expected
Check out ARM/Saturn section (or news):
http://fly.srk.fer.hr/~manjo/openfire
...later,
manjo
Yes i was thinking about $ prefix
-it may seem unlogical to have it like it is now (kinda upside-down)
(on the other hand RPN is upside-down too :-)
-it would SEEM to be more logical if only absolute cells should be prefixed
with $ AND true, it would better follow the
spreadsheet standard
Main reason why i decided to go with current prefixing roule is
(upside-down):
-unlike with "normal" spreadsheet your formula may contain external
variables or functions defined somwhere in your directory tree.
-it is easier to distinguish prefixed cells as symbols which should be
updated when cloning cells, rather than doing additional guess
work wether the variable is a cell address or external, should we update it
within formula or not.
-this way it's simple : all symbolics not prefixed are not altered
I needed a way for user to specify which cell addresses are expected to be
automatically adjusted to new position in the table.
The further i think the more i'm sure there is no secure way to do that.
Simple example :
You may be using a global variable D16 for somehing which may look like
ordinary cell address BUT in your case you may be referncing your global
variable.
The roule i'm using now would have no problems with that. You would put D16
it in the formula unprefixed and it would be evaluated as is.
Of course if you would have a table with D16 cell, cell's value takes
precedence but doesn't modify your original D16.
From programming point of view it could very quick (exponentialy) become a
true nightmare :-)
-at this time user is able to define exactly what is needed and get the
expected results.
-maybe the best way would be a compromise :
to choose other prefix so it would not get confused with other $ (standard
prefix for absolute addresses) used in spreadsheets
(maybe a &, lowercase letter or something like that, graphic, easy to
remember but allowed in symbolics)
> PS: using absolutes in the TAG doesn't serve any point
> Why would someone want only the last result in the absolute cell
When i was about to write this part i decided it would offer more
flexibility AND it had to follow the roule explained above
(easier to make it a general roule rahter than make tons of exceptions).
This is not so much important for storing last result in to the cell, it is
rather important for creating temporary objects at run-time (during
evaluation).
NOTE:
We passed number crounching, now we're expanding it and making it flexible
(able to cover every imaginable case)
-we're dealing with formula transformations and scripts (programs) within
tables, also evaluating tables in series combined with external user
programs and linking cells and tables.
Atualy it covers so many possible scenarios and ways of operation that we
could start writing a small brochure for it :-)
so much for now,
-see you later (got to go to sleep as well)
manjo
P.S. how much daylight (if any) you get this time of the year ?
i doubt Cyrille will have the time for us on this one,
but it would be nice if he could join us on our
"jurney trough the matrix"
:-)
manjo
What is the difference if I use + instead ??
> Actualy i liked ">" it looks kinda logical :-)
> 'A1>C1' but i didn't decide for this because it's harder to type then
> "-" it was :-)
> BUT since the operation is ignored... you can use watever is the best
> in your specific case.
Nice....
Is there a new version on the works?
:-D
yes, yes....
but before that...
Follow the white rabbit !!!
(for starters.... -we will think of something else later :-)
manjo
I should have taken the red pill...
Now that HP has a new ROM
see: Re: ROM 2.10-7 / HP49G+/50G
with a "real" spreadsheet directly in the matrix writer
see:Re: [49G] Spreadsheet built-in ROM 2.10-7
Why not update your program to support that
so that we could still use link and so on
You can forget about TAGs now that there is this EVAL feature
One could those use tags as cell :NAME:
so that you could IMHO refer to a cell using
[2-elem. vector] or (complex. , pair.) or {row col }
AND <char:A-Z>row style plus with the :NAME: tag
in all possible calclations
New programmable commands using MxEval
would still greatky enhance the usefullness of the in-build Spreadsheet
I wonder ho Manjo, JOhn, Me & HP (Parisse?)
all started to think about the matrices as a spreadsheet
Publicly Manjo was 1st, but I think HP started earlier
Strange as it is - it's real
and now the beautifully integrated system is superior to anything else
we can concentrade on expanding it via external software
Manjo: can you now adapt to the standard beahviour of the
$
Please?
I'm waiting for all these combinations to go together
with examples from John HHH Meyers
I think I will write/translate something in Finnish
*GENE*
are there some new Training Modules of the Matrix in works?
--
Reagan
No difference whatsoever (as explained below) operator is ignored.
> > Actualy i liked ">" it looks kinda logical :-)
> > 'A1>C1' but i didn't decide for this because it's harder to type then
> > "-" it was :-)
> > BUT since the operation is ignored... you can use watever is the best
> > in your specific case.
>
> Nice....
>
> Is there a new version on the works?
> :-D
Not at the time
-i was playing with current version (V2) seems to be working fine in all
currently available aspects :-)
Checked the rumored ROM 2.10-7 it matrixwriter has nice ABC labeled columns
:-)
(it "supports" absolute and relative addresses, but it seems that it doesn't
make any difference
when cloning the cells. Cell addresses get updated the same way as the ones
without $)
Conclusion:
-seams to be not as flexible as MXEval, and unfinished,
-but it looks very nice
-it would be nice to have matrixwriter like this in an official version
Also, the mentoned ROM has KEYTIME issues back on
(seamingly it sets and recalls the valid keytime value BUT it is ignored and
i get double pressesss :-)
have fun,
manjo
The cloning seems to depend on the EVAL flag
> Conclusion:
> -seams to be not as flexible as MXEval, and unfinished,
sure
> -but it looks very nice
:-D
> -it would be nice to have matrixwriter like this in an official
> version
If Cyrille can persuade the Markedroids & Legalbots + Bossputer
that this will increase sales
> Also, the mentoned ROM has KEYTIME issues back on
> (seamingly it sets and recalls the valid keytime value BUT it is
> ignored and i get double pressesss :-)
Huh?
That should be impossible with the new keyboard design...
> have fun,
> manjo
nowadays more than ever
I'm learning French while trying to read Parisse's documents...
I take that back !
just didn't test properly :-)
(it's the 'Excell format' -both row and column must be prefixed with $ for
both to be absolute)
'A1+$A$2'
-still don't know how to clone formula across several cells :-(
-it works great on single cell
manjo
HEhe, true,
i will get some sleep too and then look in to it.
here are some clues:
ABSOLUTE address is A1
RELATIVE address is $A1
-at this time $A1 is not realy a relative address it's (technically more
correct) address
prefixed (marked) to be updated by the MSPREAD when cloning cells
only absolute addresses are supported by MEVAL
i was thinking about $A$1 syntax but i doubt if there will ever be a need to
define mixed addresses
-form about every excell sheet i've seen, either relative addresses or
absolute were used i don't recall if somone ever used mixed addressing.
again this is not true RELATIVE addressing this is marker for a MSPREAD to
see which cells should be updated when spreading the formula.
it allows you to have C13 variable which may be your ID *variable* rather
than cell value.
example:
if i use C5 variable in a 3x3 table it would be updated when spreaded
because it is a valid relative cell address
MSPREAD culd not possibly know that it's my external C5 variable.
IF i discard this possibility maybe in that case i could choose to mark
absolute addresses with $ but i would still put my vote for clean relative
or absolute addressing
(it is much simpler)
manjo
(will think about it all again
-the more i think the more it seems that i should choose some other prefix
symbol and
-make meval work with prefixed cells as well :-)
IF
we use relative addressing in the excell style
THEN
we're stuck with long syntax ($A$1) -almost like R2D2
and we have no ability to use global variables which have cell like address
END
I think all my personal spreadsheets on my 720LX use mixed addressing (too)
> again this is not true RELATIVE addressing this is marker for a
> MSPREAD to see which cells should be updated when spreading the
> formula.
> it allows you to have C13 variable which may be your ID *variable*
> rather than cell value.
>
> example:
> if i use C5 variable in a 3x3 table it would be updated when spreaded
> because it is a valid relative cell address
> MSPREAD culd not possibly know that it's my external C5 variable.
Well then external variables are simpoly ignored if they are "cell style"
> IF i discard this possibility maybe in that case i could choose to
> mark absolute addresses with $ but i would still put my vote for
> clean relative or absolute addressing
> (it is much simpler)
Please try to follow the standard
Because HP will release new ROM with bug fixes
and Cyrille will patch it for the HPGCC
then Bernads work will go to history
and we STILL need *your* spreadsheet, Manjo!
> (will think about it all again
> -the more i think the more it seems that i should choose some other
> prefix symbol and
> -make meval work with prefixed cells as well :-)
>
> IF
> we use relative addressing in the excell style
> THEN
> we're stuck with long syntax ($A$1) -almost like R2D2
> and we have no ability to use global variables which have cell like
> address END
Parisse also uses 'A1.B2' for cell ranges
would it be easier to parce - or do you still prefer 'A1-B2'
I don't much care
BUT
it would be nice to use same spreadsheets with both ROMs
Why you should adapt and not Parisse?
1) his works is already very close to stanrd
2) his French, he will not change anything
3) you are still developing more and more features (I hope)
BTW: your work is more stable & faster!
Actualy
'A1-B2' is easier to parse, more flexible too
'A1' 'B2' +
'A1.B2' looks nice, but you have to play with strings to do this by a
program
At this point i made a little "turn away" from the standard -it works easier
and faster this way.
(i will consider to turn back to standard later)
Here's why :
By default addresses are cosidered ABSOLUTE
(this is easier because i don't need no additional work to do to identify if
some variable is cell or external variable/function),
"%" prefixed cells are relative, and will be correctly adjusted by MSPREAD
when cloning the formula,
also they evaluated as expected by MEVAL.
In version 2.1
-fixed the issue with tagged formulas (not being able to update preceding
cells and itself)
-MEVAL works with both absolute and relative cell addresses
-MSPREAD respects relative addresses (doesn't convert to absolute anymore)
manjo
http://fly.srk.fer.hr/~manjo/openfire
"from A1 to B2" as 'a1-b2' is ok to me, too!
> At this point i made a little "turn away" from the standard -it works
> easier and faster this way.
> (i will consider to turn back to standard later)
>
> Here's why :
> By default addresses are cosidered ABSOLUTE
> (this is easier because i don't need no additional work to do to
> identify if some variable is cell or external variable/function),
> "%" prefixed cells are relative, and will be correctly adjusted by
> MSPREAD when cloning the formula,
> also they evaluated as expected by MEVAL.
I really hope you will reverse this to standard (later then)
> In version 2.1
> -fixed the issue with tagged formulas (not being able to update
> preceding cells and itself)
OK !!
> -MEVAL works with both absolute and relative cell addresses
Great
> -MSPREAD respects relative addresses (doesn't convert to absolute
> anymore)
This is it!
Domold Trupgh should say "You're hired!" (not fired - HIRED)
Do you have another day job Manjo?
It's time for HP to contract you on their next project
(as well as the Man of Steen, all HPGCC people and Hydrix and...)
> manjo
> http://fly.srk.fer.hr/~manjo/openfire
Again great job
Now I wan't to see what John has in the works...
It's nice to have all three Spreadsheets available
While I think that when ROM 2.10 (or...?) get released
with HOGCC patched special version
Parisse's beautiful job will go to history
since it's unlikely that HP will include his Speadsheet in the ROM
so
Manjo & John: keep on working - I'll keep on testing
I thinkk the work is almost done