Split followed by Transpose

[Glen Bojsza]

I like a lot of your points. But for reality anything being done in 
this area would eventually have to be put in Revolution's core engine 
(if Rev users are going to develop any intensive products around this 
functionality).

But you have given me a side project to investigate and that would be 
seeing if an array/matrix/math external would

1. give any substantial performance over a transcript solution (my 
first thoughts would be yes)

2. the amount of work in defining, sourcing and creating the external

If anyone has ideas of what should be put into such an external please 
contact me off the list.



On Tuesday, March 23, 2004, at 01:31 PM, Dar Scott wrote:

>
> On Tuesday, March 23, 2004, at 07:33 AM, Glen Bojsza wrote:
>
>> This really clears up everything....but then the question I have to 
>> ask is why would you have one command (split) create a 1D array and 
>> have another command that only works with a 2D array (transpose)?
>
>> Arrays are very powerful but if you need to write repeat loops to 
>> work with them in one direction you seem to lose a lot of the power.
>>
>> I would love to hear what others think about this...maybe I'm missing 
>> the point?
>
> Good questions.
>
> I look at it like this.
>
> The building blocks for values are the chunks in strings (char, word, 
> item, line...) and arrays.  You can also build with stack, card and 
> control objects.  Arrays are also called associative arrays or maps or 
> arbitrary functions in other environments.  The keys or subscripts are 
> strings, so they are naturally 1D.  We can simulate 2D arrays by 
> combining values in a way that is easy to read, such as comma.
>
> For these, we designers have some choices in building up a 
> representation of what we want.  For example, we can build matrices 
> from these.
>
> If we decide to build them out of arrays we have a little of a head 
> start.  Array polymorphism for simple arithmetic is great for 
> multiplying by a scaler or adding vectors.  There are also extents, 
> transpose and matrix multiply functions that can be helpful.  (There 
> is also some polygon support.)
>
> That's all there is.  But if you decide to go with arrays to represent 
> matrices, they can be handy.  I don't think of matrix functions as 
> lacking.  Normally, you wouldn't find such features in this class of 
> product.  I think of them as something extra.  Don't get me wrong; I'd 
> enjoy good matrix support, but I don't expect it.  (On the other hand, 
> 2D position vector and color vector (4D) support is more important for 
> this product.)
>
> However you got in building your matrix op library, you should plan on 
> making a core set of functions and build on those.  I would have a 
> tendency to hid the implementation, but I would lose (or is it loose?) 
> array notation.  Remember, once you have your core functions, you can 
> build on those.
>
> There are some advantages and disadvantages to using arrays.  Access 
> time is not constant (I'm guessing slightly over log n).  Keys are 
> strings, so there is conversion time.  Numeric keys are formatted with 
> numberFormat, so you have to watch out for that.  Elements keep full 
> numeric precision, so that is good.  You can make sparse matrices, but 
> some functions do not work on those.  A feature enhancement in 
> bugzilla that is marked for "future" is nested arrays.  This will 
> allow fast row slicing, but is not compatible with current matrix 
> functions.  You cannot use an array function expression as a parameter 
> to another function.
>
> You don't have to go with arrays.
>
> If you know your matrices are going to be always small, say 6X6 or 
> smaller, then consider a word and line organization.  This is great 
> for a fixed size 3X3 matrix.  You might want to allow ';' as an 
> alternative to line end and comma as an alternative to white space in 
> input.  This method is nice in that it allows you to look at values in 
> debugging.  You would refer to A[i,k] as 'word k of line i of A'.  
> This also allows direct mutation, that is, modification of cells.  (I 
> always get row and column mixed up.)
>
> Another method is to use strings with a fixed cell size and fixed row 
> and matrix overhead (if any).  For example, you can allocate 20 
> characters per cell and have a newline at the end of each row.  This 
> is readable, but input needs to be formatted just right.  This will 
> have constant access time.  (However, mutation is currently not 
> constant; there is a feature request in to fix that, but if you use 
> only functions, this is OK.)  You will have to calculate the starting 
> and ending char for each access, though.  I have used a variation that 
> packs values as floating point representations.  You might be more 
> comfortable with readable text.
>
> I was recently reading a book on MatLab in preparation for work for a 
> customer.  In reading that, I thought about my math functions and my 
> desire to maybe someday make an arithmetic library for Revolution.  I 
> noticed that there is a lot that can be done for matrices with only a 
> core dozen or so functions. Other functions can be built on this.  (My 
> math is old and I did not recognize some of the functions in MatLab.)  
>  Maybe, if I ever get out of the clouds and make an arithmetic 
> library, I can also add a matrix library.
>
> Where should arrays go?  What do those who are creating matrix 
> libraries need?  Should the core functionality be in Revolution?  
> Should there be an alternate built-in method for text to 2D array.  If 
> not matrices, what about simple vectors?
>
> Dar Scott
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>