Re: Standard Forth versus Python: a case study

[jacko]

[EMAIL PROTECTED] wrote:
> John Doty:
> > Yes. The efficient exact algorithms for this problem use *partial*
> > sorts. The Forth one from the FSL is of this class (although I know of
> > two better ones for big arrays). But it's tough to beat the efficiency
> > of the approximate histogram-based method the Python stats module
> > implements.
>
> The usual way to compute a true median with Python may be:
>
> def median(inlist):
> newlist = sorted(inlist)
> index = len(newlist) // 2
> if len(newlist) % 2:
> return newlist[index]
> else:
> return (newlist[index] + newlist[index-1]) / 2.0
>
> If you can use Psyco and your FITS lines are really long (well, maybe
> too much, the treshold if about >~3000 in my PC) you can use something
> like this instead the builtin timsort:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/466330
> (To compute the median on a image line the median that uses sort is
> probably better in most cases, expecially if you use the built in sort
> of numerical libraries.)
>
> Bye,
> bearophile

partial bucket sort with quicksort of individual bucket needed for
index list.

APL would be fast, try a solution in J

it calculates need on demand i think, and so the calculation dependance
tree only does the one quicksort on the bucket needed, or both if on a
bucket boundry, but this can be avoided with clever bucket selection.

cheers

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Standard Forth versus Python: a case study

[jacko]

Paddy wrote:
> werty wrote:
> > Apples/oranges ?   programmers are making very little $$ today .
> >Thats software !   No one is makin money on obsolete Forth ,
> > so why a comparisom ?
> >
> >   Ultimately the best OpSys will be free and  millions of lines of code
> >  obsoleted .  Because no one can protect intellectual property , its
> > simply too costly for a Government to do this .
> >
> >   Notice the crypto fiasco , the USA govt forbad export of SSL and
> > in short order Australia gave the world a free SSLeasy !
> >
> >This is software .  No one will , for long , own software .
> >  Microsoft and Linux will die in 24 months .   No hardware will
> > produce money/profits using them .
> >
> >   Because we have a new hardware competitor , that obsoletes the BIOS
> >  chip , North bridge/South bridge USB helpers , NICs .
> >   No mo PNP (Plug_and_Pray) .
> >   In 2 chips ( CPU /SoC and LCD controller) it will be faster than
> >  a PC .  100's have allready written HDD drivers and haven't yet
> >  free'd them .  But when others give free , what good do it to
> >  hold yours !You look stupid selling what others improve and
> > free .   Trying to sell what others find easy to create !
> >   Intel made hardware too hard to program , ARM is easy .
> >   Python wont last on ARM , for WCE and Linux will be tossed .
> >   A simpler structured method will be used to customise
> >   Browsers . There will be 2 columns , one on left will be main/orig
> > but on the Right will have hyperlink result .  This way ya dont have
> >  to go back to compare !   side by side .
> >   Text editors will also work this way . You will read orig in left
> > columns
> >  and 'edit'/annotate  your stuff to the Right columns .
> >
> >   Sun microsystems et all ( the ones we seldom think about ) will
> >  all be obsoleted , bankrupted , their hardware surplused .
> >   No more h/w servers .
> >  There will be no high speed 64 bit boxes in the future .
> >   The Pocket PC will do work you could not  imagine !
> >   All will have 100 GB HDD , VGA LCD , USBH/USBD , WIFI N
> >   and no WERTY  keyboard !  full GUI ...
> >   ethernet and firewire and rs232 will die
> >
> >   Why not "see" the future ?
> >  No Linux ,no WXP , no C+ , no PC .
>
> Hah! This is the output from a program and I claim my prize.
> :-)

werty bot has to claim the prize to prove intelligence challange ;-)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

[jacko]

> is it possible to convert any and all algorithms to stack based ones and thus 
> avoid memory leaks?

No, not really. If you keep the allocated things and free them in
reverse order on exit, then well yes, but practically, early free()
frees memory for reuse on low memory systems. In this sense not
'reversed' out of order free is essential in some contexts.

The question then becomes what is the best heap fragmentation/
compaction strategy and what is the best allocation algorithm to
allocate addresses?
-- 
http://mail.python.org/mailman/listinfo/python-list