[M3devel] STL algorithms? sort/unique?

[Daniel Alejandro Benavides D.]

Hi all:
None of this languages of today can predict anything about unbounded termination less they provide a clear solution for the problem of finding compile  time solutions for programs of bigger classes of complexity than what it takes to type check a given program if you consider both at each time is very hard problem probably to give a model itself.
The only way seems to analyze execution traces and make prediction models.
However I don't think this is more important than to make more efficient computer models. And current advances are not encouraging.
Thanks in advance


--- El lun, 1/10/12, Jay K <jay.krell at cornell.edu> escribió:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] STL algorithms? sort/unique?
Para: "Rodney M. Bates" <rodney_bates at lcwb.coop>, "m3devel" <m3devel at elegosoft.com>
Fecha: lunes, 1 de octubre, 2012 12:29



C++ already has this to some extent and has for a long time.  You can't actually request to qsort a std::list. The type system doesn't allow it. They don't come up with random access that is ridiculously slow. They come up with none at all, and it is a compilation error.

But if you are just writing loops over loops over loops over random access to large working sets and network I/O, talking to a server, that does more of the same..yeah....

What you want though is, I guess, "more composition", more flowing of data.A lot more.Tough problem...order of runtime is a factor of so many things, size of a file, or lines in the file, or tokens in a file, or number of heap allocations, or number of network I/O, or number of memory reads, or memory writes, etc....

 - Jay


> Date: Mon, 1 Oct 2012 11:18:50 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] STL algorithms? sort/unique?
> 
> 
> 
> On 10/01/2012 08:14 AM, Hendrik Boom wrote:
> > On Sun, Sep 30, 2012 at 04:02:26PM -0500, Rodney M. Bates wrote:
> >>
> >>
> >> On 09/29/2012 01:29 PM, mika at async.caltech.edu wrote:
> >>> Well that depends on how you maintain the vector, no?
> >>>
> >>> SortedTable uses "treaps" which are supposed to be good data structures.
> >>> Too new to have made it into Knuth, last I checked.  The amortized cost
> >>> of your operations shouldn't be much worse than with your method, with
> >>> the additional benefit that the sorted order is maintained dynamically.
> >>>
> >>> The separation of algorithms from containers sounds a bit like a bug.
> >>> You have to be careful so you don't shoot yourself in the foot there!
> >>> (Sorting a list using an algorithm that randomly accesses elements,
> >>> say...)
> >>>
> >>> The Modula-3 approach is that you figure out what you want to do, pick
> >>> the ADT you want that provides the minimal set of operations, import
> >>> that interface, then instantiate a more carefully chosen implementation
> >>> of the ADT.  The language itself obviously can be coaxed into supporting the
> >>> algorithm/data structure separation but no one uses it that way as
> >>> far as I know.  (Modula-3 generics are not that well explored, actually.
> >>> I suspect there are many things you can do with them that no one has
> >>> tried.)
> >>>
> >>>       Mika
> >>>
> >>>
> >>
> >> I do think the ability to easily and inadvertently create mashups with
> >> horrible asymptotic efficiency problems is a fundamental problem with
> >> abstractions of any kind.  Just plain old-fashioned procedural abstractions
> >> give plenty of opportunity.  Write one loop and call your code O(n).
> >> Call something inside the loop. That guy did the same.  Quickly, you
> >> can O(n^3) etc., and nobody realizes it.
> >>
> >> Functional style abstractions are often just oh-so-easy to use, but
> >> they can hide a lot.  Even Modula-3 Text operations, immeasurably
> >> more versatile and easy than when you have to worry about allocation,
> >> have created some unpleasant surprises.  Documenting the performance
> >> characteristics in comments seems to be only solution.  This has been
> >> done in some places by both C++ and Modula-3 library writers.
> >
> > It might be interesting to speculate on language  features that coul
> > track performance problems the way type-checking checks types.
> >
> 
> Yes, I agree.
> 
> > Not tht I expect a practical solution today or tomorrow.
> >
> 
> Yes, I agree here too.
> 
> > -- hendrik
> >
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20121001/adaca1e8/attachment-0002.html>