Mailing-List: contact dev-help@systemml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@systemml.apache.org
MIME-Version: 1.0
From: Matthias Boehm <mboehm7@googlemail.com>
Date: Fri, 22 Sep 2017 17:00:39 -0700
Message-ID: <CAOyjQwFzm-K1Bu_bj5PLmUB35qqDHJccFccdcRG2RMqCbo=_HA@mail.gmail.com>
Subject: Re: [QUESTION] XOR operations in SystemML. Thanks.
To: Janardhan Pulivarthi <janardhan.pulivarthi@gmail.com>
Cc: dev@systemml.apache.org
Content-Type: multipart/alternative; boundary="f403043c5dd018cf870559d004a9"
archived-at: Sat, 23 Sep 2017 00:00:46 -0000

--f403043c5dd018cf870559d004a9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Janardhan,

sure - I've created SYSTEMML-1931, which covers the support of boolean
operations over matrices. Your current PR for SYSTEMML-1883 already touches
some aspects of it for XOR. I would recommend to keep 1883 and 1931
separate. Hence, you don't have to deal with value type propagation and
GPU, SPARK, or MR instructions in 1883 right now.

Regarding the generalization of cumulative operations, I don't think we're
ready to create an actual task yet - it's just an observation that a lot of
operations like cumsum and  removeEmpty have a common recursive
characteristics and that there are lots of use cases, where we would want a
similar primitive with arbitrary element-wise and cumulative aggregation
functions. If you're interested in working on it, we should probably start
with a design document.

Regards,
Matthias

On Fri, Sep 22, 2017 at 9:23 AM, Janardhan Pulivarthi <
janardhan.pulivarthi@gmail.com> wrote:

> Hi Matthias,
>
> In your previous mail - you wrote,
>
> > Down the road, we can think about a generalization of our existing
> cumulative operations such as cumsum, cumprod, cummax, to arbitrary cell
> computations and aggregation functions, which would be useful for quite a
> number of applications.
>
> > would be to generalize our AND, OR, NOT, (and XOR) operations to
> matrices, because
> these are currently only supported over scalars.
>
> Is there any jira is created for this? (would you mind please, creating a
> jira for me with a little description of task). Is there anything that yo=
u
> would like to add for the above tasks, to handle in one nice PR at once.
>
> Thanks,
> Janardhan
>
>
> On Thu, Sep 7, 2017 at 12:18 PM, Matthias Boehm <mboehm7@googlemail.com>
> wrote:
>
>> thanks Janardhan, in that case I would recommend to go with R syntax
>> because (1) it's actually one of our selling points that users don't hav=
e
>> to learn a new language, (2) it simplifies the porting of R scripts to D=
ML
>> (and vice versa), and (3) I would think it's rather uncommon to have lon=
g
>> chains of xor operations.
>>
>> Btw, a nice follow-up task - in case you're interested - would be to
>> generalize our AND, OR, NOT, (and XOR) operations to matrices, because
>> these are currently only supported over scalars. It would get you in tou=
ch
>> with the parser validation, compilation, and runtime of rather simple
>> operations.
>>
>> Regards,
>> Matthias
>>
>> On Mon, Sep 4, 2017 at 8:57 PM, Janardhan Pulivarthi <
>> janardhan.pulivarthi@gmail.com> wrote:
>>
>> > Hi,
>> >
>> > yes, no big reason to deviate. But, simplicity of `*a (+) b*` or `*a >=
<
>> > b*`like
>> > ` *a ^ 2*` (compared to `*xor(a, b)`*, which of the type` *pow(a, 2)
>> `*),
>> > to be consistent with the other symbols of dml.
>> >
>> > In this simple case:
>> > 1. ` *a (+) b (+) c (+) d(+)...* `
>> > 2. ` *xor(xor(a, b), c)..)  ` (*sorry, if I written this syntax wrongl=
y)
>> >
>> > Your word will be final.
>> >
>> > Thanks,
>> > Janardhan
>> >
>> >
>> > On Mon, Sep 4, 2017 at 6:46 PM, Matthias Boehm <mboehm7@googlemail.com=
>
>> > wrote:
>> >
>> > > Could we please stick to R syntax (i.e., "xor(a, b)") here, unless
>> there
>> > is
>> > > a good reason to deviate? Thanks.
>> > >
>> > > Regards,
>> > > Matthias
>> > >
>> > > On Mon, Sep 4, 2017 at 7:55 AM, Janardhan Pulivarthi <
>> > > janardhan.pulivarthi@gmail.com> wrote:
>> > >
>> > > > Hi all, [XOR symbol]
>> > > >
>> > > > Now, I gave a sample try for the XOR operator, with caret ` ^ `
>> symbol.
>> > > > But, this have been reserved for exponentiation. So, another
>> > alternative
>> > > > would be
>> > > >
>> > > > 1. ` (+) `
>> > > > 2. ` >< `
>> > > > 3. ` >-< `
>> > > >
>> > > > Thanks,
>> > > > Janardhan
>> > > >
>> > > > On Thu, Aug 31, 2017 at 7:38 PM, Matthias Boehm <
>> > mboehm7@googlemail.com>
>> > > > wrote:
>> > > >
>> > > >> From a scalar operation perspective, you could of course emulate
>> XOR
>> > via
>> > > >> AND, OR, and negation. However, you might want to write anyway a
>> > > java-based
>> > > >> UDF to efficiently implement this recursive operator.
>> > > >>
>> > > >> Down the road, we can think about a generalization of our existin=
g
>> > > >> cumulative operations such as cumsum, cumprod, cummax, to arbitra=
ry
>> > cell
>> > > >> computations and aggregation functions, which would be useful for
>> > quite
>> > > a
>> > > >> number of applications.
>> > > >>
>> > > >> Regards,
>> > > >> Matthias
>> > > >>
>> > > >> On Thu, Aug 31, 2017 at 5:59 AM, Janardhan Pulivarthi <
>> > > >> janardhan.pulivarthi@gmail.com> wrote:
>> > > >>
>> > > >>> Hi,
>> > > >>>
>> > > >>> The following is an equation (2.4) from the algorithm for the
>> > > generation
>> > > >>> of sobol sequences. The authors of the paper have utilized the
>> > bitwise
>> > > >>> operations of C++ to calculate this efficiently.
>> > > >>>
>> > > >>> *Now, the question is:* Can we do this at script level (in dml)
>> or we
>> > > >>> should do it in the `java` itself as a builtin, function to
>> generate
>> > > the
>> > > >>> numbers?.
>> > > >>>
>> > > >>>
>> > > >>> =E2=80=8B
>> > > >>> Thanks,
>> > > >>> Janardhan
>> > > >>>
>> > > >>
>> > > >>
>> > > >
>> > >
>> >
>>
>
>

--f403043c5dd018cf870559d004a9--