Hello everyone,
so we all agree that adding these structures to CM would be
compartively easy (reusing what has been done with
FieldElement/Field). Whether it would be useful is another issue...
>
> What is most interesting is the example use cases. I think we all
> know that it is straightforward and easy to define the interfaces
> and classes, which basically just amount to removing structure or
> closure properties from fields. The question is do they really get
> you anything? You mentioned above a Taylor series example. I did
> not follow what was going on there exactly. Were the coefficients
> over Z, or the values? What other rings were you considering? What
> groups, exactly? That is what I meant by having the use cases
> first, then introducing the abstractions as needed. Before
> introducing the mathematical objects, we need "real world
> applications" in mind that are going to use them. Of course, our
> "real world" can include some pretty arcane stuff; but at the end of
> the day, we need to have internal or external application use cases
> in mind for everything that we add to [math].
>
> Phil
>
This approach is indeed the most reasonable path to follow. Quite
frankly, I must work on my example before I can tell you anymore about
it. In fact, I'm not convinced these extensions are absolutely
necessary, I think aesthetics was also part of my initial motivation
(bad, bad, I must admit...). I will get back to you as soon as my mind
is clearer.
As for the numerical/non-numerical question. The application I have in
mind is very similar (but more involved on the symbolic side) to
hierarchic finite-elements (p-FEM). This is a *numerical* algorithm,
which comes down to solving a linear system. Assembly of the matrix is
the tough part, as closed-form expressions for the entries are a
nightmare. Their derivation, however, is very systematic, and involves
only taylor expansions. So I figured I would *compute* the closed-form
expression of the entries, prior to assembling the matrix. I'm a bit
afraid about floating-point errors in these preliminary computations,
so I would like to be able to use several number representations
("exact" fractions, as well as faster doubles). Also, exact
calculations would be useful per se (publication of the method). But
for the time being, fields are really what I need. As I said, I might
have been carried by a wave of mathematical abstraction... I'm in the
middle of writing the code, and need to check I *really* need groups
or rings.
Whether or not these extensions are a must do is highly questionable;
however, the over feature requests I've communicated
(opposite()/inverse()) would indeed be very useful.
If you agree, I'll keep you posted on this topic once I've reached a
conclusion. But this conclusion will probably be: I like them, but I
don't need them...
Sorry for taking your time.
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
