RE: [boost] Draft of new Boost Software License
Thanks Beman, >No, including the Boost license doesn't make your source open. There is >nothing in either the new or old Boost licenses which requires that source >code be redistributed or otherwise made available. I understand the intention and realize that this is the way it has always been. It is wonderful to have great work like boost at the finger tips. "Is my work a derivate work?", I guess is the gist of the question. How do you firewall it? Does a contract with a third party need to address the boundary of boost code (which maybe modified and embedded or not) and the proprietary code. >When you cut-and-paste a bit of copyrighted code into your own code, you've >created a derived work of the copyrighted code. That's the way copyright >law works, even if your code is really large and the cut-and-paste >copyright code is fairly trivial. (Under some circumstances copying a small >portion can be considered "fair use", but that is starting to drift >off-topic.) If a work is a derivate work and you do redistribute, sell or otherwise license your own proprietary _source_ what is the impact of including the following statement? __ Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software covered by this license (the "Software") to use, reproduce, display, distribute, execute, and transmit the Software, and to prepare derivative works of the Software, and to permit third-parties to whom the Software is furnished to do so, all subject to the following __ If I have the desire to license source code, which uses boost code, to a third party, on the basis that my code may not be redistributed then this statement confuses the issue if I am a derivative work. For example, I build a risk system for an asset manager. I use some boost, perhaps modified. I include the license as required... and I get confused trying to separate the consequences in a contract with the third party. I had one such messy contract that took over a year to resolve to mutual agreement :-( Perhaps this is a non issue as the issue may exist for alternative licenses. If you desire to have your derivative work under a different umbrella for source distribution then the issue seems significant to me. Cheers, Matt. PS: does #include make you a derived work? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Draft of new Boost Software License
>Matt Hurd wrote: >> >> >The author of a derivative work can put in a more restrictive license >> >right? In this case, wording that gives the full Boost permission must >> >still be included according to the draft license. >> >This would lead to a license text like: >> >> >> I am a little confused. Like Jaakko, I read it as viral. >> >> If you produced a derivative work, or copy paste a little code, then you >> are bound to include the boost license which makes your source open as >> well... >> >> Seems akin to LGPL. >> >> Is this the intention or have I misread it? > >"derivative works of the Software" != "the Software" Sorry, I must be having a bad hair day... I still read it as including the copyright in derivative works from the second paragraph... I would prefer to see acknowledgement of the origin/author(s) as viral. Still confused but I am a little slow, Matt. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Draft of new Boost Software License
>The author of a derivative work can put in a more restrictive license >right? In this case, wording that gives the full Boost permission must >still be included according to the draft license. >This would lead to a license text like: I am a little confused. Like Jaarko, I read it as viral. If you produced a derivative work, or copy paste a little code, then you are bound to include the boost license which makes your source open as well... Seems akin to LGPL. Is this the intention or have I misread it? Regards, Matt. Australian is my native tongue... ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Stats - smallish points
I see in the Wiki a couple of comments about variance/std dev with n and n-1
being referred to at the denominator. Just to clear it up:
when it is a complete population the denominator should be n.
when it is a random sample it is n-1.
sample variance = sum(Xi - mean(X))^2/(n-1)
or more usefully = (n*sum(Xi^2))-sum(Xi)^2
__
n(n-1)
For those of you with MS Excel you will see both supported.
I note the idea of using accumulators for the various sums to determine
stats in the Wiki.
I would like to see this idea extended...
I think a noble goal would be to accumulate sums over populations in
collection or sliding windows of sequences but only those sums you need.
Like AOP this would be best if done generatively. That is, don't generate
sum(X^2) if you only need a mean. Have state to generate max and min if
needed.
Another noble goal would be to harness the power of incremental
calculations:
The simple case is a mean:
- This is generated from sum(X)
- add X to the old sum(X) for a collection
- for a window on a sequence, take the old X off and put the new X on
This seems trivial but adds much more power for calcs, especially windows.
Say you have a one variable linear regression over a window, typically you
would use a library function to calc the stats and it would be O(n). If the
state were accumulated incrementally, then the first window is O(n) and
moving the window a point is O(1).
Say over 10 years of typical data you have 2500 points you are doing a
year's window, 250 points. Using the usual way, calling a library function,
you get, if you pardon my abuse of the notation, O(250 * 2500) or of order
625,000. If you do it incrementally, you get of order of 250 + 2500*1 =
2750 calcs which is a 227 times speed up or 4.4% of the calc.
Interestingly, this can also apply to things like min and max over a window
where you see if the point rolling off is the min or max, if not then you
only have to compare the current min, max to the new point, otherwise you
have to scan...
This is just finite differencing... just like Bresenham's line algorithm.
You sometimes see such incremental approaches in some FORTRAN stats
libraries, but not as often as you should. Also, users often ignore them
anyway as they are typically conditioned to call the regression or whatever.
Below is some code I wrote to do this with an MS compiler before templates
was supported to illustrate the incremental case. This code is oriented to
timeseries of numbers being treated as "streams" for a market trading
application. Please excuse the old historic ugliness...
Now, the idea is to translate such concepts into vogue C++ with policies
etal ;-)
Regards,
matt.
___
Using a NR call
Non-incremental
___
void FunctorLineFit::evaluate(Offset day) {
Offset order = Offset(parameter(0));
float *x = floatVectorGet(day,order,0);
float *y = floatVectorGet(day,order,1);
float a,b,siga,sigb,chi2,q;
fit(x-1,y-1, (int) order, NULL, 0, &a,&b,&siga,&sigb,&chi2,&q);
setResult(day,0,PriceType(a));
setResult(day,1,(PriceType)b);
setResult(day,2,(PriceType)siga);
setResult(day,3,(PriceType)sigb);
setResult(day,4,(PriceType)chi2);
floatVectorRelease(x,0);
floatVectorRelease(y,1);
} // FunctorLineFit
__
Using incremental calc
__
class FunctorLineFitSeriesIncremental : public FunctorStored {
RWDECLARE_COLLECTABLE(FunctorLineFitSeriesIncremental)
public:
virtual Offset waste() const { return Offset(parameter(0)); };
virtual void evaluate(Offset j);
private:
virtual void setPrivate();
PriceType
n,n2,n3,sumX,sumXX,a1,a2,b1,b2,np1,syx1,syx2,syx3,syx4,seny1,r21,ar21,pb1,pb
2,pb3;
Offset intN;
};
void FunctorLineFitSeriesIncremental::evaluate(Offset day) {
assert(invariant());
Offset counter;
PriceType sumY, sumYY, sumXY;
PriceType a,b,yx,syx,seny,r2,ar2,pb,yxLow, yxHigh;
PriceType oldY, newY, oldXY, newXY;
PriceType sumY2, syxTemp, r2Temp, t, t2;
PriceType temp;
// This code relies on the left to right conditional evaluation of &&
if (day>0 && cached(day-1)) {
// Use tomorrow's data to calculate today.
oldY = datum(day-1,0);
newY = datum(day+intN-1,0);
sumY = value(day-1,10) - oldY + newY;
sumYY = value(day-1,11) - oldY*oldY + newY*newY;
oldXY = n*oldY;
newXY = sumY;
sumXY = value(day-1,12) - oldXY + newXY;
} else if (day0 && cached(day-1)) {
// Use tomorrow's data to calculate today.
oldX = datum(day-1,0);
newX = datum(day+n-1,0);
oldXbottom = oldX;
newXbottom = datum(day+lag-1,0);
oldXtop = datum(day-1+n-lag,0);
newXtop = newX;
oldXXlag = oldX*datum(day-1+lag,0);
newXXlag = datum(day+n-lag-1,0)*newX;
sumX = value(day-1
RE: [boost] Re: resource manager naming
> -Original Message- > Behalf Of Alisdair Meredith > Subject: [boost] Re: resource manager naming > > Larry Evans wrote: > > > Would the GOF name, proxy, be too non-specific? Policy names > might provide > > the specifics (whether it's a pointer or a resource). > > Proxy, if anything, sends the wrong message to me. The name suggests > 'reference', rather then 'owner' > > 'bookkeeper' is the best I can come up with so far, but that is a very > odd word to type and still too long. bookkeeper makes me think: keep - it's mine - the inner sanctum of the castle - short and unconfusing to me $0.02 matt. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
