Boost logo

Boost :

Subject: Re: [boost] [odeint] Documentation comments
From: Mario Mulansky (mario.mulansky_at_[hidden])
Date: 2012-09-25 22:38:12

John Bytheway <jbytheway+boost_at_[hidden]> wrote:

>On 22/09/12 13:41, Karsten Ahnert wrote:
>>> - The resizing policy names are a bit clumsy; I think always_resize,
>>> initially_resize, and never_resize might be better.
>> you are right. I am also not happy with their names. But renaming
>> might break some code. Of course, one can also introduce some typedef
>> for backward compatibility.
>Yes, I was thinking of something like that.
>>> - Rather than having a dedicated array_algebra, could you not have
>>> range_algebra automatically switch to the more efficient
>>> when it detects a suitable State type?
>> Yes, in principle this is possible. You can extend the idea to
>> a algebra and operations dispatcher which finwd the appropirate
>> for every state type not only for ranges or arrays, but also for
>> Thrust's vector types or Boost.Fusion sequences for example. If
>> really like to have such a feature we can implement this.
>These aren't quite the same thing. I'm suggesting an optimization,
>rather than a notational convenience. It shouldn't change observable

So you mean essentially the range algebra should forward to the array algebra when it encounters an array? At some point there has to be an automatic deduction. At the moment the range algebra is the standard and whenever something else is wanted it has to be user-specified. I think it might be reasonable to give an automatic mechanism, but allow for overriding by explicit definition.

The more general idea of automatically dispatching to the
>right algebra is more dangerous, because for example it is entirely
>possible to have a type which is both a Fusion sequence and a Range
>with different semantics in each interpretation). So, I am not
>suggesting that (though I wouldn't argue against it either).

This would be an edge case where explicit user definition is required, but i think in 99% an algebra dispatcher would be sufficient.


>Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at