Re: Accessing parts of arrays
At 10:34 PM +0200 9/29/2004, jbv wrote: another interesting feature would be some sort of find function for arrays... for instance : put myText into T[5,8] find myText in T would return 5,8 or a list of found chunks if it is in more than 1 array cell I like that idea - have you bugzillaed it as a feature request? (Now I'm wondering about the canonical spelling for the past tense of to bugzilla... ;-) -- jeanne a. e. devoto ~ [EMAIL PROTECTED] http://www.jaedworks.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Accessing parts of arrays
--- Jeanne A. E. DeVoto [EMAIL PROTECTED] wrote: At 10:34 PM +0200 9/29/2004, jbv wrote: another interesting feature would be some sort of find function for arrays... for instance : put myText into T[5,8] find myText in T would return 5,8 or a list of found chunks if it is in more than 1 array cell I like that idea - have you bugzillaed it as a feature request? (Now I'm wondering about the canonical spelling for the past tense of to bugzilla... ;-) I like the idea too, but I'd prefer the function name 'elementOffset' (to be in line with itemOffset, etc.) which would return the key of the first elemnet in which it was found. If my memory serves me well, Geoff Canyon started a thread on the xTalk mailing list a while ago that proposed functions itemOffsets, wordOffsets and lineOffsets which would return all the occurences' locations. So if we could have an elementOffsets() function, this would be the best solution for the above request, I think. Jan Schenkel. = As we grow older, we grow both wiser and more foolish at the same time. (La Rochefoucauld) __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Accessing parts of arrays
On Thursday, September 30, 2004, at 12:35 PM, Jan Schenkel wrote: If my memory serves me well, Geoff Canyon started a thread on the xTalk mailing list a while ago that proposed functions itemOffsets, wordOffsets and lineOffsets which would return all the occurences' locations. So if we could have an elementOffsets() function, this would be the best solution for the above request, I think. Jan Schenkel. I have been talking to people at the mothership about this. First off my software that I created with Rev is starting to sell. This gives me the money to pay for the externals suggested below by Mark. The reason that I bring it up here on the list in the open is that the external will speed up my XML based database and if it where later to be added to the engine then it would speed up my software that I'm selling now. This sounds like it might be a great tool for array power if you are willing to use a parser for the manipulations. Before I proceed does this suggestion sound good for this array thread? (see below) Pull-parsing an XML structure at high speed could give us all kinds of array manipulations if you where to use numbered tag sets like 1[data]/1, 2[more data here]/2, 3[even more data]/3etc... and 1,1 1,2 and 1,3,1 for dimensional arrays. Mark Brownell On Wednesday, September 29, 2004, at 09:50 AM, Mark Waddingham wrote: Hi Mark, [snip] In terms of your request for the suggested matchGlobal function [see below] then while it would be nice to have, in comparison with other feature requests that we have, it is difficult to justify putting development time into this as opposed to other extensions/enhancements and features that people have requested. However, as I mentioned before, we would be perfectly willing to develop an external with the functionality you require which can then be integrated into the engine at the next opportunity. This both mitigates the development cost to us, and provides you a more flexible solution should you require specialization and/or optimization of the functions in the future. If you are interested in proceeding in this manner then I will happily put together a more concrete proposal to you, including technical details and time costings, and leave you to negotiate with Kevin the costs and finer contractual details. To give you an idea of the substance of such a proposal I would suggest implementing an external with the following functions: matchOffsets(needle, haystack, [ from ], [ to ]) - return a list of offsets of the needle in char from to to of haystack one per line. matchParallelOffsets(needles, needle_sep, haystack, [ from ], [ to ]) - return a list of offsets of each chunk of needles in char from to to of haystack The chunks of needles would be delimited by the character needle_sep. Each line of this list would be of the form offset of needle_1, offset of needle_2, ...,, offset of needle_n (i.e. the functionality of your parser would be given by doing a single call of matchParallelOffsets with two chunks in the needles) matchSetCacheSize size - The Boyer-Moore algorithm has a set-up cost for each pattern which incurs a memory overhead. This call would set the maximum number of patterns that should be cached at any one time. To give an idea about how these might be implemented in the engine, then Jeanne's suggestion for syntax is a good one (assuming it doesn't cause any conflicts - I make no promises as to whether this syntax is feasible): the offsets of needle in haystack the offsets of the lines/words/items of needles in haystack Anyway, I shall leave you to think on this way forward, and I promise to be more efficient in getting back to you next time. Warmest Regards, Mark. On Thu, 16 Sep 2004, Mark Brownell wrote: Hi Mark, I was wondering, now that things might have gotten a little less hectic, what or if any progress has been made on adding this to the Rev engine? This is exactly what I was hoping to get. I can use it to isolate large portions of huge documents for the purpose of creating something I might need very badly in the next few months. also this single function could be highly useful to others as you pointed out. Thanks, Mark Brownell On Wednesday, August 18, 2004, at 03:10 AM, Mark Waddingham wrote: The one of most interest is the Boyer-Moore algorithm as this is reputed to be the fastest. So, one idea is to implement a function: matchGlobal(stringToSearch, token) returning a list of all indices in stringToSearch of token. e.g. get matchGlobal(afoo/aabar/aabaz/a, a) would give it[1] = 1 it[2] = 10 it[3] = 20 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Accessing parts of arrays
At 12:07 PM -0400 9/29/2004, Gregory Lypny wrote: In doing some statistical work, it occurred to me that Revolution's arrays would be greatly enhanced if we could access sub-arrays just like we can with itemized and line-delimited lists. I agree it's a good idea. It might be harder than it looks, because all Rev's arrays are associative arrays (what look like numeric arrays are actually associative), so I suspect some major reworking would be needed. -- jeanne a. e. devoto ~ [EMAIL PROTECTED] http://www.jaedworks.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Accessing parts of arrays
At 12:07 PM -0400 9/29/2004, Gregory Lypny wrote: In doing some statistical work, it occurred to me that Revolution's arrays would be greatly enhanced if we could access sub-arrays just like we can with itemized and line-delimited lists. I agree it's a good idea. It might be harder than it looks, because all Rev's arrays are associative arrays (what look like numeric arrays are actually associative), so I suspect some major reworking would be needed. -- another interesting feature would be some sort of find function for arrays... for instance : put myText into T[5,8] find myText in T would return 5,8 or a list of found chunks if it is in more than 1 array cell I know this can be emulated using the combine function, and then itemoffset of lineoffset, but it would be more elegant (and probably faster). And I don't think this means a major rewriting... JB ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Accessing parts of arrays
Maybe you could use the intersect command to split out subarrays. Otherwise, remember that you can easily combing an array by comma and then use the average(item 1 to 4 of x) approach. At 6:23 PM -0400 29/9/04, Greg wrote: To: Revolution [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed Hello everyone, In doing some statistical work, it occurred to me that Revolution's arrays would be greatly enhanced if we could access sub-arrays just like we can with itemized and line-delimited lists. For example, in a comma-delimited list of the natural numbers, 1 to 10, we can compute the average of any subset of the numbers using the average() function: put 1,2,3,4,5,6,7,8,9,10 into x put average(item 1 to 4 of x) \ average(x) \ average(item 1 to 8 of x) --yields 2.5, 5.5 and 4.5. But as far as I know, we cannot refer to element 1 to 4 of array x, and we can only take the average of all the values in x to get 5.5 as below. multiply t by 0 repeat 10 times add 1 to t put t into x[t] end repeat put average(x) -- yields 5.5 Greg -- Michael J. Lew Senior Lecturer Department of Pharmacology The University of Melbourne Parkville 3010 Victoria Australia Phone +613 8344 8304 ** New email address: [EMAIL PROTECTED] ** ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
