"Tiago Gasiba" <tiago.gasiba@gmail.com> wrote in message news:dllbpq$1rda$1@digitaldaemon.com...
> Sean Kelly schrieb:
>
>> Would it be alright if these functions were added to Ares as well?
>>
> Yes! Definitively. And I would encourage you to do so.
> The routines that I have posted previously are GPL. As for MathExtra Don
> can tell you about that, licensing, etc!
> As I said before, I'll post a few more routines after some time. Those you
> can also add to Ares as well. :)
>
> Best,
> Tiago

Ok this really worries me.

I assumed that all code which is accepted into the standard library would be covered under a single license.  In particular, one which allows for commercial, closed-source development.

Is this the case, or do we have a hodge podge of different licensing schemes?

Tony
Melbourne, Australia

In article <dlmu0v$3ci$1@digitaldaemon.com>, Tony says...
>
>"Tiago Gasiba" <tiago.gasiba@gmail.com> wrote in message news:dllbpq$1rda$1@digitaldaemon.com...
>> Sean Kelly schrieb:
>>
>>> Would it be alright if these functions were added to Ares as well?
>>>
>> Yes! Definitively. And I would encourage you to do so.
>> The routines that I have posted previously are GPL. As for MathExtra Don
>> can tell you about that, licensing, etc!
>> As I said before, I'll post a few more routines after some time. Those you
>> can also add to Ares as well. :)
>>
>> Best,
>> Tiago
>
>Ok this really worries me.
>
>I assumed that all code which is accepted into the standard library would be covered under a single license.  In particular, one which allows for commercial, closed-source development.
>
>Is this the case, or do we have a hodge podge of different licensing schemes?
>
>Tony
>Melbourne, Australia

I can't find the post, but I think Walter requested that contributions either be "contributed to Digital Mars" or "public domain". But I could be remembering it wrong. Since the DMD front-end source is licensed as dual GPL and Artistic something has to be done to keep it consistent. I think Phobos has similar license conditions.

jcc7

Tony wrote:

> Ok this really worries me.
> 
> I assumed that all code which is accepted into the standard library would be covered under a single license.  In particular, one which allows for commercial, closed-source development.
> 
> Is this the case, or do we have a hodge podge of different licensing schemes?

It used to be a real hodge-podge, but it's getting better...

Most of it is now under the BSDish "zlib/libpng" license:

http://www.prowiki.org/wiki4d/wiki.cgi?PhobosLicenseIssues

(if there are changes lately, feel free to update that page)

--anders

Tony wrote:
> 
> Ok this really worries me.
> 
> I assumed that all code which is accepted into the standard library would be covered under a single license.  In particular, one which allows for commercial, closed-source development.
> 
> Is this the case, or do we have a hodge podge of different licensing schemes?

Anything accepted into Ares will be covered under a single license, which has yet to be determined.  I'd expect it to be some variant of the BSD license however.  I know Walter has accepted things into Phobos in the past that had their own license requirements (the old std.math), but I don't expect that to continue unless there's something highly specialized that needs to be in which simply has no free implementation available.


Sean

Sean Kelly wrote:
> Don Clugston wrote:
> 
>> Tiago Gasiba wrote:
>>
>>> Hi all,
>>>
>>>   In my work I use a lot of complex number computations.
>>>   It's great that D has a native support for them but, the std.math is still missing a lot of functions for complex math.
>>>   Attached you can find a small file with some routines that I hope to be integrated in future std.math versions.
>>>   These routines might need a bit workout, but they are working fine right now . At least in my code - have not stress tested the routines.
>>
>>
>> Yes, we definitely need to get into the standard before 1.0.
> 
> 
> Would it be alright if these functions were added to Ares as well?

Sean, everything in mathextra is public domain, and the project description specifically mentions Ares. (In fact, part of the reason I've made it as a seperate project is to ensure there's a public domain version of it, to make it easy to plug into Ares). Have a look, several of these functions are already there, with a reasonable level of documentation.

-----

I would like to see D move a little away from the C/C++ library structure -- "math.h" is a monster, it's ridiculous that the whole of mathematics gets ONE header file! It's particularly bad in D, where implementation and header are stored in one.


If I could do it from scratch, I'd make std.math a directory, and do it this way:

I see three broad categories:
(1) Special interest stuff that is not frequently used; certainly it would be rare for more than one of these to be used in a single source file. Most programmers won't use most of this.

std.math.statistics -- functions from mathemematical statistics (almost all of these are already implemented in MathExtra)
std.math.discrete -- things like factorials, primes, the nChoosek function just submitted, etc.
std.math.special -- Mathematical Special Functions. Bessel functions, Airy functions, hyperfluent geometrics, etc. A couple of these are in MathExtra.

?std.math.random -- random number generators with specific distributions, eg Poissonian. More suitable for Monte-Carlo type simulations than crypotographic ones. Uses the basic random number from somewhere else, eg std.random, (which is used for games, and is also extended by cryptographic stuff).

(2) Low level stuff, that is virtually built-in, but is computer hardware-oriented rather than genuinely mathematical.

std.math.ieee -- low-level stuff which manipulates bit patterns in IEEE reals. Includes things like isnan(), but also the stuff from "fenv.h" in C, including setting rounding modes.

(3) General purpose stuff from the C standard library, except for the things already covered above. Less sure about these. General idea being that anyone who uses these functions doesn't pull in any functions that they didn't learn about in high school.

std.math.core (?) -- elementary functions (circular and hyperbolic trig, exp, log, pow, sqrt) and basic operations on built-in types (absolute value, complex conjugates, etc).

std.math.matrix -- linear algebra

std.math.all (? except that it is NOT everything!) std.math.cmath (?? meaning the stuff that comes in C libraries. ?but it looks like "complex math" Aaargh) -- Wrapper file that publicly imports std.math.core, std.math.ieee.

Ideally, this last one would just be called std.math, but it does not seem possible to have a module name with the same as a directory name.

Some kind of arrangement like this seems to late for Phobos, but not for Ares.
Another possibility, that might work with Phobos, would be to have a subdirectory "advmath", for advanced mathematics. Then we'd have

std.advmath.statistics, std.advmath.special, etc.
but unfortunately also
std.advmath.matrix

---
Sorry everyone, I've realised that probably belongs in the Ares forum, (although it is also relevant for Phobos). I just think that this is something that C got badly wrong, and is worth further thought.

-Don.

Don Clugston wrote:
> 
> Sean, everything in mathextra is public domain, and the project description specifically mentions Ares. (In fact, part of the reason I've made it as a seperate project is to ensure there's a public domain version of it, to make it easy to plug into Ares). Have a look, several of these functions are already there, with a reasonable level of documentation.

Thanks!  I will.


Sean