You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ole Ersoy <ol...@gmail.com> on 2016/01/04 02:41:46 UTC

[math] RealVector Fluid API vs. Java 8 Arrays.setAll

Hi,

RealVector supports the following type of fluid API:

|RealVectorresult =v.mapAddToSelf(3.4).mapToSelf(newTan()).mapToSelf(newPower(2.3)); IIUC each time we call v.mapXXX an iteration happens, so with the above expression we loop 3 times. With Java 8 Arrays.setAll we can do the same thing like this (Using static imports): ||Arrays.setAll(arr, i -> pow(tan(arr[i] + 3.4), 2.3)); So that seems like a pretty good fit for ArrayRealVector. WDYT? I have not looked at SparseRealVector yet... Cheers, Ole |

||


Re: [math] RealVector Fluid API vs. Java 8 Arrays.setAll

Posted by Ole Ersoy <ol...@gmail.com>.

On 01/03/2016 08:41 PM, Gilles wrote:
> On Sun, 3 Jan 2016 19:41:46 -0600, Ole Ersoy wrote:
>> Hi,
>>
>> RealVector supports the following type of fluid API:
>>
>> |RealVectorresult
>> =v.mapAddToSelf(3.4).mapToSelf(newTan()).mapToSelf(newPower(2.3));
>> IIUC each time we call v.mapXXX an iteration happens, so with the
>> above expression we loop 3 times. With Java 8 Arrays.setAll we can do
>> the same thing like this (Using static imports): ||Arrays.setAll(arr,
>> i -> pow(tan(arr[i] + 3.4), 2.3)); So that seems like a pretty good
>> fit for ArrayRealVector. WDYT? I have not looked at SparseRealVector
>> yet... Cheers, Ole |
>>
>> ||
>
> [Above message is a tad mangled.]
That's weird...
>
> result = v.mapToSelf(FunctionUtils.compose(new Power(2.3),
>                                            new Tan(),
> FunctionUtils.combine(new Add(),
> new Constant(3.4),
> new Identity())));
> Feasible with one loop in CM: yes.
> Less compact than the above syntax: yes.
> Less efficient than the Java8 construct: I'd guess so...

So I'm trying to think out whether a more minimal RealVector design makes sense and what it would look like ... that still works in all collaborative CM vector / matrix calculation use cases.  For example RealVector has an method:
      public abstract RealVector append(double d);

This seems like it belongs in the Collections domain and can be split off (But is that going to kill kittens?).  Same thing with getSubVector and setSubVector, etc.  It seems like with Arrays.setAll and Arrays.parallelSetAll the mapToSelf could be performed by more universally applicable Java 8 components. Possibly the walk methods as well.

WDYT?

Cheers,
Ole


>
>
> Regards,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [math] RealVector Fluid API vs. Java 8 Arrays.setAll

Posted by Gilles <gi...@harfang.homelinux.org>.
On Sun, 3 Jan 2016 19:41:46 -0600, Ole Ersoy wrote:
> Hi,
>
> RealVector supports the following type of fluid API:
>
> |RealVectorresult
> =v.mapAddToSelf(3.4).mapToSelf(newTan()).mapToSelf(newPower(2.3));
> IIUC each time we call v.mapXXX an iteration happens, so with the
> above expression we loop 3 times. With Java 8 Arrays.setAll we can do
> the same thing like this (Using static imports): ||Arrays.setAll(arr,
> i -> pow(tan(arr[i] + 3.4), 2.3)); So that seems like a pretty good
> fit for ArrayRealVector. WDYT? I have not looked at SparseRealVector
> yet... Cheers, Ole |
>
> ||

[Above message is a tad mangled.]

result = v.mapToSelf(FunctionUtils.compose(new Power(2.3),
                                            new Tan(),
                                            FunctionUtils.combine(new 
Add(),
                                                                  new 
Constant(3.4),
                                                                  new 
Identity())));
Feasible with one loop in CM: yes.
Less compact than the above syntax: yes.
Less efficient than the Java8 construct: I'd guess so...


Regards,
Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org