## digitalmars.D - MathExp: KISS or All-Out?

• dsimcha (34/34) Oct 14 2009 I'm working on some mathy modules that I'd like to eventually contribute...
• Chad J (15/15) Oct 14 2009 I'm reminded of how annoying it is when there are different libraries
• language_fan (3/9) Oct 15 2009 Sometimes it feels like Vec3 must be the most reimplemented wheel on the...
• gzp (25/36) Oct 16 2009 Yes, i've also started to implement my own matrix/vector library, though...
• Fawzi Mohamed (18/57) Oct 16 2009 I think you are greatly underestimating the effort of making "just a
• Fawzi Mohamed (4/44) Oct 15 2009 Looks interesting, I would vote for KISS... maybe in the future with
• Bill Baxter (40/75) Oct 15 2009 I kinda think it's too niche. A nice thing to have if you're
• Don (4/16) Oct 15 2009 Probably the same as these:
dsimcha <dsimcha yahoo.com> writes:
```I'm working on some mathy modules that I'd like to eventually contribute to
Phobos, or, if they're too niche, to a standalone lib.  One that I've alluded
to here in the past few days is MathExp.  Basically what it does is
parse/interpret/evaluate/manipulate mathematical expressions at runtime.
Here's a summary of what I've got working so far:

MathExp numerator = mathExp("x^2 * cos(x)", "x");
MathExp denominator = mathExp("exp(-x)", "x");
MathExp ratio = numerator / denominator;

// Print the result of
// (x^2 * cos(x)) / (exp(-x)) evaluated at x = 5.
writeln(ratio(5));

// Compute a derivative symbolically.
MathExp derivDenominator = denominator.derivative("x");

I'm trying to figure out which one makes more sense in the grand scheme of
things.  MathExp might be best kept very simple and stupid and pretty much
left as is, possibly even with the symbolic differentiation capabilities
removed (though these contribute surprisingly little to the weight of the
code; I wrote most of them in one evening just to see if I could).  It would
be easy to use, understand and debug, but be very stupid and have virtually no
semantic understanding of the expressions it's manipulating.  It wouldn't even
be able to simplify, for example, (1 + x + 1) -> (x + 2).

On the other hand, I could take this to the nth degree and add things like
decent printing capabilities (right now, my toString() method is a huge
kludge, is intended for debugging purposes, and puts in tons of unnecessary
parentheses).  I could figure out how to add some semantic analysis to
simplify expressions, maybe symbolic equation solving in some simple cases,
etc.  The downside to this is that I would be reinventing the computer algebra
system in D, which might be a bit too much for a small hobby project that's
intended as a Phobos module.  I'd likely make the code an order of magnitude
more complicated than it is now and might end up reinventing a square wheel or
writing some really buggy code.

If the goal here is to build a Phobos module or standalone plain old library,
do you think the KISS approach or the full-fledged approach is more useful to
the D community?
```
Oct 14 2009
```I'm reminded of how annoying it is when there are different libraries
for a language that all define their mathematical types differently and
in incompatible ways (all of the Vec2D, Vec3D, etc ever).  Also
aggravating is when there is one canonical type that everyone uses, but
it is a poor choice (char* in C for strings).

It seems like you're in the position to define some canonical CAS types
for D.

So I'd say don't sweat the depth of library procedures too much, but
please get the type definitions (and anything else fundamental) right.
That way libraries that rely on CAS capabilities can talk to each other
without ugliness happening.  In depth procedures to operate on these
types can be implemented in 3rd party libs as necessary, since I can
imagine this stuff getting very very deep, way more so than is
appropriate for phobos.

Just my opinion.  I'm not a CAS pro or anything.
```
Oct 14 2009
language_fan <foo bar.com.invalid> writes:
```Thu, 15 Oct 2009 02:04:09 -0400, Chad J thusly wrote:

I'm reminded of how annoying it is when there are different libraries
for a language that all define their mathematical types differently and
in incompatible ways (all of the Vec2D, Vec3D, etc ever).  Also
aggravating is when there is one canonical type that everyone uses, but
it is a poor choice (char* in C for strings).

Sometimes it feels like Vec3 must be the most reimplemented wheel on the
world.
```
Oct 15 2009
gzp <galap freemail.hu> writes:
```language_fan Ã­rta:
Thu, 15 Oct 2009 02:04:09 -0400, Chad J thusly wrote:

I'm reminded of how annoying it is when there are different libraries
for a language that all define their mathematical types differently and
in incompatible ways (all of the Vec2D, Vec3D, etc ever).  Also
aggravating is when there is one canonical type that everyone uses, but
it is a poor choice (char* in C for strings).

Sometimes it feels like Vec3 must be the most reimplemented wheel on the
world.

Yes, i've also started to implement my own matrix/vector library, though
could not get too far yet, as I have to learn D meanwhile. I've checked
some existing ones (ex. Lyla, and some other on dsource - don't remember
the name, sorry), but my main problem was that,

- the implementation could not be altered as desired (ex. I need a
sparse matrix, where the matrix elements grouped using a quad-tree )
- didn't like the coding style ( ex. "_" in function names). In some
experiences even though we found libraries that has all the capability
we required, we did not used them. Sometimes we didn't used our
colleagues (good, well-planned) codes either b/c the style differed so
much (ex capital letters, "_", m prefix for members etc.) So if a
language can enforce a style (at least giving some warnings - and
turning on treat warnings as errors :) ), that really helps to reuse
codes. Well, it's another topic...
- too general where it is not required for me, but could not extend
where it is needed for me
- seemed to be hard to implement a "general" n-d geometry lib based on
them(ex 2d/3d/nd ray, sphere, plane, etc, simplicals, space
partitioning in n-d etc.)

So it'd be really great to create a "new" d mathematical library, that
is developed and discussed by a group.

Ok, I know there are wrappers for BLAS and other C libraries, but I'd
like to see a library written entirely in D.
```
Oct 16 2009
Fawzi Mohamed <fmohamed mac.com> writes:
```On 2009-10-16 11:13:59 +0200, gzp <galap freemail.hu> said:

language_fan írta:
Thu, 15 Oct 2009 02:04:09 -0400, Chad J thusly wrote:

I'm reminded of how annoying it is when there are different libraries
for a language that all define their mathematical types differently and
in incompatible ways (all of the Vec2D, Vec3D, etc ever).  Also
aggravating is when there is one canonical type that everyone uses, but
it is a poor choice (char* in C for strings).

Sometimes it feels like Vec3 must be the most reimplemented wheel on the world.

Yes, i've also started to implement my own matrix/vector library,
though could not get too far yet, as I have to learn D meanwhile. I've
checked some existing ones (ex. Lyla, and some other on dsource - don't
remember the name, sorry), but my main problem was that,

- the implementation could not be altered as desired (ex. I need a
sparse matrix, where the matrix elements grouped using a quad-tree )
- didn't like the coding style ( ex. "_" in function names). In some
experiences even though we found libraries that has all the capability
we required, we did not used them. Sometimes we didn't used our
colleagues (good, well-planned) codes either b/c the style differed so
much (ex capital letters, "_", m prefix for members etc.) So if a
language can enforce a style (at least giving some warnings - and
turning on treat warnings as errors :) ), that really helps to reuse
codes. Well, it's another topic...
- too general where it is not required for me, but could not extend
where it is needed for me
- seemed to be hard to implement a "general" n-d geometry lib based
on   them(ex 2d/3d/nd ray, sphere, plane, etc, simplicals, space
partitioning in n-d etc.)

So it'd be really great to create a "new" d mathematical library, that
is developed and discussed by a group.

Ok, I know there are wrappers for BLAS and other C libraries, but I'd
like to see a library written entirely in D.

I think you are greatly underestimating the effort of making "just a
library for matrixes and vectors"

I think that there are at least 3 areas that have quite different tradeoffs:
* small vectors/matrixes, fixed size
* large dense vector/matrixes
* sparse matrixes/vectors

I did just dense matrixes, in blip, and blas is used if available to
speed up things when possible (default, use version noBlas noLapack to
avoid using it), lapack to implement more complex linear algebra stuff.

For sparse matrixes Bill has hidden them in the multiarray project, the
multiarray implementation there is quite slow and has some
shortcomings, but it hasn't been the focus of bill since a long time.
But he has wrappers for sparse matrixes, and several sparse matrix libs
that he actively uses.

for small vectors/matrixes I use open math for games (omg) implementation.

ciao
Fawzi
```
Oct 16 2009
Bill Baxter <wbaxter gmail.com> writes:
```On Fri, Oct 16, 2009 at 2:57 AM, Fawzi Mohamed <fmohamed mac.com> wrote:
On 2009-10-16 11:13:59 +0200, gzp <galap freemail.hu> said:

language_fan =EDrta:
Thu, 15 Oct 2009 02:04:09 -0400, Chad J thusly wrote:

I'm reminded of how annoying it is when there are different libraries
for a language that all define their mathematical types differently an=

d
in incompatible ways (all of the Vec2D, Vec3D, etc ever). =A0Also
aggravating is when there is one canonical type that everyone uses, bu=

t
it is a poor choice (char* in C for strings).

Sometimes it feels like Vec3 must be the most reimplemented wheel on th=

e
world.

Yes, i've also started to implement my own matrix/vector library, though
could not get too far yet, as I have to learn D meanwhile. I've checked =

some
existing ones (ex. Lyla, and some other on dsource - don't remember the
name, sorry), but my main problem was that,

=A0- the implementation could not be altered as desired (ex. I need a sp=

arse
matrix, where the matrix elements grouped using a quad-tree )
=A0- didn't like the coding style ( ex. "_" in function names). In some

es
even though we found libraries that has all the capability we required, =

we
did not used them. Sometimes we didn't used our colleagues (good,
well-planned) codes either b/c the style differed so much (ex capital
letters, "_", m prefix for members etc.) So if a language can enforce a
style (at least giving some warnings - and turning on treat warnings as
errors :) ), that really helps to reuse codes. Well, it's another topic.=

..
=A0- too general where it is not required for me, but could not extend w=

here
it is needed for me
=A0- seemed to be hard to implement a "general" n-d geometry lib based o=

n
them(ex 2d/3d/nd ray, sphere, plane, etc, simplicals, space partitioning=

in
n-d etc.)

So it'd be really great to create a "new" d mathematical library, that i=

s
developed and discussed by a group.

Ok, I know there are wrappers for BLAS and other C libraries, but I'd li=

ke
to see a library written entirely in D.

I think you are greatly underestimating the effort of making "just a libr=

ary
for matrixes and vectors"

I think that there are at least 3 areas that have quite different tradeof=

fs:
* small vectors/matrixes, fixed size
* large dense vector/matrixes
* sparse matrixes/vectors

I did just dense matrixes, in blip, and blas is used if available to spee=

d
up things when possible (default, use version noBlas noLapack to avoid us=

ing
it), lapack to implement more complex linear algebra stuff.

For sparse matrixes Bill has hidden them in the multiarray project,

Wasn't really my intention to hide them :-)... but yes they are there
in the "dflat" package of multiarray.

the
multiarray implementation there is quite slow and has some shortcomings, =

but
it hasn't been the focus of bill since a long time.

Yeh, don't use the multiarray in the multiarray project.  dflat is for
sparse and dense matrices and is independent of multiarray.

But he has wrappers for sparse matrixes, and several sparse matrix libs t=

hat
he actively uses.

Well less actively these days since I changed jobs.  But as you can
see, I still hang around here anyway, just waiting for the day D
declares victory.

for small vectors/matrixes I use open math for games (omg) implementation=

.

Best named math library evar, probly. lol.

--bb
```
Oct 16 2009
Fawzi Mohamed <fmohamed mac.com> writes:
```On 2009-10-14 23:49:07 +0200, dsimcha <dsimcha yahoo.com> said:

I'm working on some mathy modules that I'd like to eventually contribute to
Phobos, or, if they're too niche, to a standalone lib.  One that I've alluded
to here in the past few days is MathExp.  Basically what it does is
parse/interpret/evaluate/manipulate mathematical expressions at runtime.
Here's a summary of what I've got working so far:

MathExp numerator = mathExp("x^2 * cos(x)", "x");
MathExp denominator = mathExp("exp(-x)", "x");
MathExp ratio = numerator / denominator;

// Print the result of
// (x^2 * cos(x)) / (exp(-x)) evaluated at x = 5.
writeln(ratio(5));

// Compute a derivative symbolically.
MathExp derivDenominator = denominator.derivative("x");

I'm trying to figure out which one makes more sense in the grand scheme of
things.  MathExp might be best kept very simple and stupid and pretty much
left as is, possibly even with the symbolic differentiation capabilities
removed (though these contribute surprisingly little to the weight of the
code; I wrote most of them in one evening just to see if I could).  It would
be easy to use, understand and debug, but be very stupid and have virtually no
semantic understanding of the expressions it's manipulating.  It wouldn't even
be able to simplify, for example, (1 + x + 1) -> (x + 2).

On the other hand, I could take this to the nth degree and add things like
decent printing capabilities (right now, my toString() method is a huge
kludge, is intended for debugging purposes, and puts in tons of unnecessary
parentheses).  I could figure out how to add some semantic analysis to
simplify expressions, maybe symbolic equation solving in some simple cases,
etc.  The downside to this is that I would be reinventing the computer algebra
system in D, which might be a bit too much for a small hobby project that's
intended as a Phobos module.  I'd likely make the code an order of magnitude
more complicated than it is now and might end up reinventing a square wheel or
writing some really buggy code.

If the goal here is to build a Phobos module or standalone plain old library,
do you think the KISS approach or the full-fledged approach is more useful to
the D community?

Looks interesting, I would vote for KISS... maybe in the future with
possible runtime compilation of a function... :)

Fawzi
```
Oct 15 2009
Bill Baxter <wbaxter gmail.com> writes:
```On Wed, Oct 14, 2009 at 2:49 PM, dsimcha <dsimcha yahoo.com> wrote:
I'm working on some mathy modules that I'd like to eventually contribute =

to
Phobos, or, if they're too niche, to a standalone lib.
One that I've alluded
to here in the past few days is MathExp.  Basically what it does is
parse/interpret/evaluate/manipulate mathematical expressions at runtime.

I kinda think it's too niche.  A nice thing to have if you're
implementing a calculator or some other program where users can input
their own expressions.  But other than that I can't think of any time
I've run across the need to evaluate expressions at runtime.  What
sort of use cases did you have in mind?

Here's a summary of what I've got working so far:

MathExp numerator =3D mathExp("x^2 * cos(x)", "x");
MathExp denominator =3D mathExp("exp(-x)", "x");
MathExp ratio =3D numerator / denominator;

// Print the result of
// (x^2 * cos(x)) / (exp(-x)) evaluated at x =3D 5.
writeln(ratio(5));

// Compute a derivative symbolically.
MathExp derivDenominator =3D denominator.derivative("x");

Not really relevant to your lib, but for cases where you have
compile-time expressions and you want to evaluate the derivative at
runtime, there is something called automatic differentiation tends to
be much more effective than symbolic differentiation if the goal is to
actually compute a numerical result.
http://en.wikipedia.org/wiki/Automatic_differentiation
I just think it's a neat trick, so I mention it here.  :-)

I'm trying to figure out which one makes more sense in the grand scheme o=

f
things. =A0MathExp might be best kept very simple and stupid and pretty m=

uch
left as is, possibly even with the symbolic differentiation capabilities
removed (though these contribute surprisingly little to the weight of the
code; I wrote most of them in one evening just to see if I could). =A0It =

would
be easy to use, understand and debug, but be very stupid and have virtual=

ly no
semantic understanding of the expressions it's manipulating. =A0It wouldn=

't even
be able to simplify, for example, (1 + x + 1) -> (x + 2).

On the other hand, I could take this to the nth degree and add things lik=

e
decent printing capabilities (right now, my toString() method is a huge
kludge, is intended for debugging purposes, and puts in tons of unnecessa=

ry
parentheses). =A0I could figure out how to add some semantic analysis to
simplify expressions, maybe symbolic equation solving in some simple case=

s,
etc. =A0The downside to this is that I would be reinventing the computer =

algebra
system in D, which might be a bit too much for a small hobby project that=

's
intended as a Phobos module. =A0I'd likely make the code an order of magn=

itude
more complicated than it is now and might end up reinventing a square whe=

el or
writing some really buggy code.

Yeh, it sounds like it to me.  Writing a serious CAS is a huge project
and most of the time people who need such functionality don't really
need it in library form.  They need an interactive program like Maple
to get some result which they then plug into their own program.

If you do decide to do it, though, the SymPy project might be a nice
one to look at.  It's coming along quite nicely.  I don't know
anything about the internals, but their stated goals are to maintain
readability and simplicity of the code as much as possible, even if it

If the goal here is to build a Phobos module or standalone plain old libr=

ary,
do you think the KISS approach or the full-fledged approach is more usefu=

l to
the D community?

I'd stick with KISS unless you really want CAS to become your full-time hob=
by.

--bb
```
Oct 15 2009
Don <nospam nospam.com> writes:
```Bill Baxter wrote:
On Wed, Oct 14, 2009 at 2:49 PM, dsimcha <dsimcha yahoo.com> wrote:
I'm working on some mathy modules that I'd like to eventually contribute to
Phobos, or, if they're too niche, to a standalone lib.
One that I've alluded
to here in the past few days is MathExp.  Basically what it does is
parse/interpret/evaluate/manipulate mathematical expressions at runtime.

I kinda think it's too niche.  A nice thing to have if you're
implementing a calculator or some other program where users can input
their own expressions.  But other than that I can't think of any time
I've run across the need to evaluate expressions at runtime.  What
sort of use cases did you have in mind?

Probably the same as these:

http://www.codeproject.com/KB/recipes/MathieuMathParser.aspx
http://www.codeproject.com/KB/recipes/FastMathParser.aspx
```
Oct 15 2009
Bill Baxter <wbaxter gmail.com> writes:
```On Thu, Oct 15, 2009 at 4:36 AM, Don <nospam nospam.com> wrote:
Bill Baxter wrote:
On Wed, Oct 14, 2009 at 2:49 PM, dsimcha <dsimcha yahoo.com> wrote:
I'm working on some mathy modules that I'd like to eventually contribut=

e
to
Phobos, or, if they're too niche, to a standalone lib.
One that I've alluded
to here in the past few days is MathExp. =A0Basically what it does is
parse/interpret/evaluate/manipulate mathematical expressions at runtime=

.
I kinda think it's too niche. =A0A nice thing to have if you're
implementing a calculator or some other program where users can input
their own expressions. =A0But other than that I can't think of any time
I've run across the need to evaluate expressions at runtime. =A0What
sort of use cases did you have in mind?

Probably the same as these:

http://www.codeproject.com/KB/recipes/MathieuMathParser.aspx
http://www.codeproject.com/KB/recipes/FastMathParser.aspx

Funny.  Yes, seems they couldn't come up with any examples either. :-)

--bb
```
Oct 15 2009