<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>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.<br>The only way seems to analyze execution traces and make prediction models.<br>However I don't think this is more important than to make more efficient computer models. And current advances are not encouraging.<br>Thanks in advance<br><br><br>--- El <b>lun, 1/10/12, Jay K <i><jay.krell@cornell.edu></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Jay K <jay.krell@cornell.edu><br>Asunto: Re: [M3devel] STL
algorithms? sort/unique?<br>Para: "Rodney M. Bates" <rodney_bates@lcwb.coop>, "m3devel" <m3devel@elegosoft.com><br>Fecha: lunes, 1 de octubre, 2012 12:29<br><br><div id="yiv391221152">
<style><!--
#yiv391221152 .yiv391221152hmmessage P
{
margin:0px;padding:0px;}
#yiv391221152 body.yiv391221152hmmessage
{
font-size:12pt;font-family:Calibri;}
--></style><div><div dir="ltr">C++ already has this to some extent and has for a long time.<div> 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.</div><div><br></div><div><br></div><div>But if you are just writing loops over <span style="font-size: 12pt;">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....</span></div><div><br></div><div><br><div>What you want though is, I guess, "more composition", more flowing of data.</div><div>A lot more.</div><div>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....</div><div><br></div><div><br></div><div> - Jay<br><br><br><div><div id="yiv391221152SkyDrivePlaceholder"></div>> Date: Mon, 1 Oct 2012 11:18:50 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] STL algorithms? sort/unique?<br>> <br>> <br>> <br>> On 10/01/2012 08:14 AM, Hendrik Boom wrote:<br>> > On Sun, Sep 30, 2012 at 04:02:26PM -0500, Rodney M. Bates wrote:<br>> >><br>> >><br>> >> On 09/29/2012 01:29 PM, mika@async.caltech.edu wrote:<br>> >>> Well that depends on how you maintain the vector, no?<br>> >>><br>> >>> SortedTable uses "treaps" which are supposed to be good data structures.<br>> >>> Too new to have made it into Knuth, last I checked. The amortized cost<br>> >>> of your operations shouldn't be much worse than with your method, with<br>> >>> the
additional benefit that the sorted order is maintained dynamically.<br>> >>><br>> >>> The separation of algorithms from containers sounds a bit like a bug.<br>> >>> You have to be careful so you don't shoot yourself in the foot there!<br>> >>> (Sorting a list using an algorithm that randomly accesses elements,<br>> >>> say...)<br>> >>><br>> >>> The Modula-3 approach is that you figure out what you want to do, pick<br>> >>> the ADT you want that provides the minimal set of operations, import<br>> >>> that interface, then instantiate a more carefully chosen implementation<br>> >>> of the ADT. The language itself obviously can be coaxed into supporting the<br>> >>> algorithm/data structure separation but no one uses it that way as<br>> >>> far as I know. (Modula-3 generics are not that well explored,
actually.<br>> >>> I suspect there are many things you can do with them that no one has<br>> >>> tried.)<br>> >>><br>> >>> Mika<br>> >>><br>> >>><br>> >><br>> >> I do think the ability to easily and inadvertently create mashups with<br>> >> horrible asymptotic efficiency problems is a fundamental problem with<br>> >> abstractions of any kind. Just plain old-fashioned procedural abstractions<br>> >> give plenty of opportunity. Write one loop and call your code O(n).<br>> >> Call something inside the loop. That guy did the same. Quickly, you<br>> >> can O(n^3) etc., and nobody realizes it.<br>> >><br>> >> Functional style abstractions are often just oh-so-easy to use, but<br>> >> they can hide a lot. Even Modula-3 Text operations, immeasurably<br>> >> more versatile and easy
than when you have to worry about allocation,<br>> >> have created some unpleasant surprises. Documenting the performance<br>> >> characteristics in comments seems to be only solution. This has been<br>> >> done in some places by both C++ and Modula-3 library writers.<br>> ><br>> > It might be interesting to speculate on language features that coul<br>> > track performance problems the way type-checking checks types.<br>> ><br>> <br>> Yes, I agree.<br>> <br>> > Not tht I expect a practical solution today or tomorrow.<br>> ><br>> <br>> Yes, I agree here too.<br>> <br>> > -- hendrik<br>> ><br>> <br></div></div></div> </div></div>
</div></blockquote></td></tr></table>