[
https://issues.apache.org/jira/browse/MATH-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772285#action_12772285
]
Jake Mannix commented on MATH-313:
----------------------------------
bq. I agree with Luc on limiting abstract infrastructure to what we have
practical use cases for. See "guiding principles" on the home page.
Maybe I misunderstood the uses for this library - when I see classes like
"Field<T>" and "FeildElement<T>" in the main o.a.c.math package, I assumed that
building in generic mathematical actions is desired as well as simply a toolbox
of specific use-cases.
bq. One thing to consider is do we require that Composable functions be total
and finite-valued. If not, documenting and debugging NaN/Inf/Exceptions could
be tricky for users.
I wondered the same thing: why does UnivariateRealFunction throw a checked
exception, forcing users to deal with it on every call? Could this not be a
(specific subclass of) RuntimeException, and let users who need to deal with it
deal with it, and other people can ignore it, knowing that they have
safe/entire functions, or that they will handle the NaN/Inf cases on their own.
bq. Also, do we require that composition be only "with" ComposableFunctions?
I didn't think that was necessary, no. The implementation of preCompose,
postCompose, plus, minus, times, divide, scale don't require that the argument
be ComposableFunction, but they will return an anonymous subclass of
ComposableFunction, which has the side benefit of trivially allowing you to
turn a non-composable function (Luc's HeatSensor) into a composable one, with
ComposableFunction composableHeatSensorFunction =
Identity.postCompose(heatSensor); (this could just as easily be implemented
with a delgating function as well, of course).
bq. I guess another thing to think about is inverses.
How would you implement this, in general?
> Functions could be more object-oriented without losing any power.
> -----------------------------------------------------------------
>
> Key: MATH-313
> URL: https://issues.apache.org/jira/browse/MATH-313
> Project: Commons Math
> Issue Type: New Feature
> Affects Versions: 2.0
> Environment: all
> Reporter: Jake Mannix
> Fix For: 2.1
>
>
> UnivariateRealFunction, for example, is a map from R to R. The set of such
> functions has tons and tons of structure: in addition to being an algebra,
> equipped with +,-,*, and scaling by constants, it maps the same space into
> itself, so it is composable, both pre and post.
> I'd propose we add:
> {code}
> UnivariateRealFunction plus(UnivariateRealFunction other);
> UnivariateRealFunction minus(UnivariateRealFunction other);
> UnivariateRealFunction times(UnivariateRealFunction other);
> UnivariateRealFunction times(double scale);
> UnivariateRealFunction preCompose(UnivariateRealFunction other);
> UnivariateRealFunction postCompose(UnivariateRealFunction other);
> {code}
> to the interface, and then implement them in an
> AbstractUnivariateRealFunction base class. No implementer would need to
> notice, other than switching to extend this class rather than implement
> UnivariateRealFunction.
> Many people don't need or use this, but... it makes for some powerfully easy
> code:
> {code}UnivariateRealFunction gaussian =
> Exp.preCompose(Negate.preCompose(Pow2));{code}
> which is even nicer when done anonymously passing into a map/collect method
> (a la MATH-312).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
