Re: Proposed templated integer_sort

On Mon, Jun 30, 2008 at 12:26 PM, Simonson, Lucanus J <
lucanus.j.simonson <at> intel.com> wrote:

> Steven Ross wrote:
> >For larger n, the advantage vs. pure comparison-based algorithms
> increases.
> >In effect, Spreadsort smoothly transitions from pure MSB Radix sort to
> >std::sort
> >with its data cut up by a couple iterations of MSB Radix sort
> >(reducing the size of the log(n) factor),
> >depending upon the distribution and size of the data.
>
> The analysis seems a little too optimistic and seems to be based upon
> the assumption that the input is evenly distributed.  To analyze the
> complexity you need to think like an adversary who knows your algorithm
> and intentionally creates an input that will make it perform poorly.  In
> the worst case your algorithm would be slower than std::sort because a
> data set with a cluster of values that all fall within the same bin and
> a handful of outliers that give rise to the unfortunate binning would
> result in runtime for std::sort + runtime for one or more recursive
> stages of profitless binning.  So, the algorithm should be expected to
> be faster than std::sort alone for some inputs, but slower for others.
>

The worst case is actually binning that only marginally splits up the data
each iteration in such a fashion that std::sort must be called on an only
slightly reduced size list at the end.  This corresponds to the
square_root(bit_sizeof(T)) + a constant number of std::sort
iterations situation.  Because each radix-based sorting iteration is
significantly slower than an introsort iteration, this situation may

Subject: Broken bug reports

The reporting mechanism in Trac has changed from 0.10 to 0.11; 
breaking my scripts that generate (most of) the bug reports I send 
out in the mornings.

It will be a few days until I figure out how to fix them.
--

-- 
-- Marshall

Marshall Clow     Idio Software   <mailto:marshall <at> idio.com>

It is by caffeine alone I set my mind in motion.
It is by the beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [range/iterators/algorithms/phoenix/bind...] Coordinated Approach

On Mon, Jun 30, 2008 at 9:37 PM, David Abrahams <dave <at> boostpro.com> wrote:
> Dean Michael Berris wrote:
>> I think it would be easy to
>> agree that we'd love to have everything in Boost work like it new
>> every other library in it, but that makes Boost more a Framework than
>> a library collection. I don't necessarily think that would be a Bad
>> Thing, but rather too close a coupling for my taste.
>
> I don't think there's anything "coupled" about coordinating foundational
> parts so they interoperate properly.
>

Right, but I was stating this more in terms of dependency
between/among components.

>>> Here are the parts and topics that I see as being in the category:
>>>
>>> result_of
>
> * Too hard to define result<> templates for polymorphic function objects.
>

Isn't this one of the issues the EGG library is supposed to address?

[snip]
>
>>> BOOST_TYPEOF
>
> * Doesn't coordinate with result_of
>

Re: [range/iterators/algorithms/phoenix/bind...] Coordinated Approach

On Mon, Jun 30, 2008 at 10:51 PM, Giovanni Piero Deretta
<gpderetta <at> gmail.com> wrote:
> On Mon, Jun 30, 2008 at 3:37 PM, David Abrahams <dave <at> boostpro.com> wrote:
>>>> range_ex
>>
>> * Not in Boost.  Should have pipe syntax.  Maybe should use expression
>> templates and be lazier.
>
> Does it really need expression templates? That is, given the range
> builders make_*_view [1], it should return a *_view (for example a
> filtered_view). Combining multiple views, you get for example:
>
>   filtered_view<mapped_view<taken_view<BaseRange> , Mapper>, Filter> >
>
> I.e.  a series of range views are already an expression templates.
> Now, if you make some (reasonable, and hopefully documented)
> assumptions about Filter and Mapper, you should be always able to
> convert sequences of nested views that contains only views known to
> range_ex in a normal form: for example:
>
>   taken_view<mapped_view<filtered_view<BaseRange, compose<Mapper,
> Filter> >, Mapper> >
>
> You can of course collapse multiple mapped, filtered and taken range
> in a single instance of each range. [2]
> A top level boost::for_each could be able to unwind the normalized
> expression and apply a simple iteration over the Base range instead of
> relying on the compiler of eliminating the abstraction overhead of
> four different iterators.
>

Re: A branching/tagging idea for releases

On Mon, Jun 30, 2008 at 11:15 PM, Rene Rivera <grafikrobot <at> gmail.com> wrote:
> Dean Michael Berris wrote:
>>
>> Sorry to jump in here... Not being a Boost author myself makes this a
>> little awkward, but I'd like to get my $0.02 worth in there.
>
> Commentary by developers who deal with software releases of any form is very
> much welcome in these!
>

Thanks. :)

>>
>> On Mon, Jun 30, 2008 at 11:20 AM, Rene Rivera <grafikrobot <at> gmail.com>
>> wrote:
>>>
>>> David Abrahams wrote:
>>>>
>>>> James Sharpe wrote:
>
>> I think the diversion here comes from the fact that only authors (or
>> maintainers) are able to check in code to the subversion repository --
>> and patches that go towards a 'bugfix point release' need to go
>> through the authors/maintainers. This is a problem of the
>> 'not-always-stable' trunk paradigm, where major/minor development
>> happens on the trunk which gets tested day by day.
>
> Hm, I don't see how that follows. I can see the bottleneck authors time is,
> and is one of my main points. But I don't see how that follows to the
> problem of 'not-always-stable' trunk method.

Subversion problem(s)?

I tried doing the following just now... Anything going on?

$ svn co http://svn.boost.org/svn/boost/trunk boost-trunk-flux
svn: REPORT request failed on '/svn/boost/!svn/vcc/default'
svn: REPORT of '/svn/boost/!svn/vcc/default': 400 Bad Request
(http://svn.boost.org)

--

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [interprocess] Bug in os_file_functions.hpp

Excellent!

Ion Gaztañaga wrote:
> Lars Hagström wrote:
>> Hi,
>>
>> I've just tried to use the file_locks from the boost trunk, and 
>> stumbled across a bug (well, two related bugs, really) when using the 
>> try_lock* metods.
>> The problem occurs on linux systems only.
> 
> Thanks, fixed in SVN. I'll merge it to release in a few days.
> 
> Regards,
> 
> Ion
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: Inspection report and non-ASCII characters

Beman Dawes wrote:
>> John Maddock wrote:
>>>
>>> Would it be possible for the inspection report to print out the line
>>> containing the non-ASCII characters?  There are a few files that are
>>> being flagged up, where I just can't find anything wrong with them
>>> 
>>
>> Hum... Take a look at trunk\tools\inspect\ascii_check.cpp
>>
>> It seems misnamed; it is apparently really checking for characters
>> the
>> c++ standard says are OK in source programs, regardless of encoding.
>>
>> Also, I notice the code:
>>
>>          if ( c >= 'a' && c <= 'z' ) return false;
>>          if ( c >= 'A' && c <= 'Z' ) return false;
>>
>> That isn't right for EBCDIC. See http://en.wikipedia.org/wiki/EBCDIC.
>> Although that is being pedantic - there is little chance the code
>> will
>> ever run on an non-ASCII system.
>>
>> But before changing anything, we really need to figure out what our
>> Boost standard is. How about anything 0x20-0x7E plus 0x09, 0x0A,
>> 0x0D?
>>
>> (0x09 is a tab, but we already have a more specific check for that.)

Re: Inspection report and non-ASCII characters

2008/6/29 John Maddock <john <at> johnmaddock.co.uk>:
>
> Would it be possible for the inspection report to print out the line
> containing the non-ASCII characters?

That's a good idea, but will take a little effort. Can you create a
ticket? A quicker fix might be to just to list the problematic
characters.

> There are a few files that are being
> flagged up, where I just can't find anything wrong with them 

You forgot the 'A' in ASCII:

http://svn.boost.org/trac/boost/changeset/46943/

If you can get your text editor to help you, this is a lot easier to
fix. If it doesn't have explicit support or a plugin, you could just
try opening it with the wrong encoding and seeing what looks weird. I
suppose running Visual C++ with full warnings would also help.

Daniel
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [range/iterators/algorithms/phoenix/bind...] Coordinated Approach

On Tue, Jul 1, 2008 at 7:12 AM, Dean Michael Berris
<mikhailberis <at> gmail.com> wrote:
> On Mon, Jun 30, 2008 at 10:51 PM, Giovanni Piero Deretta
> <gpderetta <at> gmail.com> wrote:
>> On Mon, Jun 30, 2008 at 3:37 PM, David Abrahams <dave <at> boostpro.com> wrote:
>>>>> range_ex
>>>
>>> * Not in Boost.  Should have pipe syntax.  Maybe should use expression
>>> templates and be lazier.
>>
>> Does it really need expression templates? That is, given the range
>> builders make_*_view [1], it should return a *_view (for example a
>> filtered_view). Combining multiple views, you get for example:
>>
>>   filtered_view<mapped_view<taken_view<BaseRange> , Mapper>, Filter> >
>>
>> I.e.  a series of range views are already an expression templates.
>> Now, if you make some (reasonable, and hopefully documented)
>> assumptions about Filter and Mapper, you should be always able to
>> convert sequences of nested views that contains only views known to
>> range_ex in a normal form: for example:
>>
>>   taken_view<mapped_view<filtered_view<BaseRange, compose<Mapper,
>> Filter> >, Mapper> >
>>
>> You can of course collapse multiple mapped, filtered and taken range
>> in a single instance of each range. [2]
>> A top level boost::for_each could be able to unwind the normalized
>> expression and apply a simple iteration over the Base range instead of
>> relying on the compiler of eliminating the abstraction overhead of