On Fri, Aug 24, 2012 at 7:15 AM, hakan <hexi...@users.sourceforge.net>wrote:
> **
> I reported this already (item #3151709, was opened at 2011-01-05 09:52),
> and I was also surprised.
> There is a note in REXXREF about sorting arrays and non-sparse arrays
> (page 285). I found out after reporting.
>
> I think it's not consistent with
> Do s over array
> say s
> end
>
These are fundamentally different constructs. Do Over actually requests a
new version from the collection which is defined as being non-sparse. The
sort is an in-place modification of the array itself.
>
> This will show all existing items in the array. Skippning removed items
>
> I prefer to think of, in this case, that removed items is nonexisting
> items and should not be included in a sort operation, which means array
> will "shrink".
> but it has already done that more or less, array~items will only count
> indexes with values (like the do over clause),
> but array~sort statment will fail if item is removed from array, if not
> last item in array is removed.
>
> As for current status shouldn't array~items return a count including
> removed entries.
>
Not allowing empty slots at the end would make the sort essentially
unusable. Consider the following:
a = .array~new(1000) -- create an array with a "best guess on the size"
do while iterator~haveMoreitems
a~append(iterator~nextItem)
end
a~sort
Raising an error if a~items < a~size would mean the above scenario would
only work if there were exactly 1000 items added to the array. The
dichotomy between items and size and the meaning of sparse is intentional.
This change is not going to be made.
Rick
>
>
> Some inconsistency here I think
> /hex
>
>
>
>
>
>
> ----- Ursprungligt Meddelande -----
> *Från:* Rony G. Flatscher
> <rony.flatsc...@wu-wien.ac.at><rony.flatsc...@wu-wien.ac.at>
> *Till:* Open Object Rexx Developer Mailing List
> <oorexx-devel@lists.sourceforge.net> <oorexx-devel@lists.sourceforge.net>
> *Kopia:*
> *Datum:* fredag, 24 augusti 2012 12:02
> *Ämne:* [Oorexx-devel] Ad sorting arrays: request for discussion/thoughts
> ...
> Yesterday I stumbled over a surprising behaviour of Array's sort, which
> led me to open a bug report
> <https://sourceforge.net/p/oorexx/bugs/1107/><https://sourceforge.net/p/oorexx/bugs/1107/>.
> Obviously the sorting is working as designed, hence the reported behaviour
> was not accepted as a bug.
>
> Having slept a night over this and thinking about my utmost surprise that
> sort would raise an error condition if it hits an empty array element (one
> without an entry) in between, I try to summarize my thoughts about the
> current behaviour, requesting a change of the design and implementation to
> get rid of the surprising factor and to remove undeterminable fragility
> from the Array sort.
>
> First, the current design and implementation:
>
> The single dimiensioned array that gets sorted must not have empty entries
> in between. If the sort tries to refer to an empty slot it raises "Error98
> .975: Missing array element at position xyz" and the program is ended, if
> the condition does not get trapped.
>
> Thoughts about this:
>
> 1. Having worked for many years sorting arrays, I was *totally
> surprised* about this unexpected (because never experienced) behaviour! The
> surprise factor for me was at the maximum.
> 2. There is no documentation going with sorting arrays that would
> communicate that the arrays to be sorted must have no empty elements in
> between that I am aware of. Therefore one cannot expect this behaviour at
> all.
> 3. If one uses single dimensioned arrays that get changed in routines
> and methods (written by others) such that elements get removed in between,
> then sorting such an array all of a sudden (and totally unforseeable)
> raises the above mentioned error condition, which makes sort quite fragile
> for programmers IMHO.
> 1. To overcome this situation, one must advice every ooRexx
> programmer to do *always* a (potentially time-consuming) makearray
> before
> sorting an array just to make sure that the aforementioned error
> condition
> does not get raised.
> 4. Finally, I would have expected that an array with empty elements
> should be sortable without a problem, therefore my utmost surprise! :)
> 1. My expectations would be simply as follows: if a single dimensioned
> array contained empty elements, then sorting would work and all the
> empty
> elements are sorted to the end of the array, no matter what the
> comparison
> method returns. This way, after a sort, all empty elements are always at
> the end of the array. (The items and size messages would remain the
> same.)
>
> The questions I would have, before contemplating about filing a RFE:
>
>
> - am I the only one who is surprised about a failing sort on a single
> dimensioned array if in between there are empty elements?
> - Independent of this, would it be acceptable to change the current
> design and implementation of the sort such that empty elements are
> tolerated and put to the end of the array (what would be arguments,
> thoughts that speak against such a change)?
>
> ---rony
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
