Hmm... I had overlooked that.

And, for multinomials, I think it's more efficient than my
hypothetical sparse based implementation could have been.

I guess degree, here, would be

pdegree=: {{
  if. L. y do. >./+/}.|:> y
  else. >./I.0~:y
  end.
}}

And, I should study https://code.jsoftware.com/wiki/Vocabulary/pdot to
see if I've overlooked anything else important.

Thanks,


--
Raul

On Thu, Jan 5, 2023 at 3:49 PM Henry Rich <henryhr...@gmail.com> wrote:
>
> See https://code.jsoftware.com/wiki/Vocabulary/pdot#multinomial
>
>     (<_3 ]\ 7 2 3  4 1 0   9 0 0) p. 1 1,:2 2
> 20 241
>
> Henry Rich
>
> On 1/5/2023 3:43 PM, Raul Miller wrote:
> > On Thu, Jan 5, 2023 at 7:07 AM Ak O <akin...@gmail.com> wrote:
> >> The point I mean to highlight is the represention (for the purpose of
> >> calculation).
> > It's probably worth noting here that J's p. verb does not, by itself,
> > support polynomials like  7x^2y^3 + 4x^1y^0 - 9x^0y^0. And without a
> > representation for the polynomial we don't have a representation for
> > degrees of that polynomial.
> >
> > Also...
> >
> > To implement that, in a general case form, I guess you'd need a verb
> > which matched dimensions on the left with items on the right (and, for
> > efficiency purposes, the left argument would need to be a sparse
> > array. So in recent versions of J we'd be limited to at most 63
> > variables -- arrays of at most 63 items in the right hand argument.
> > That said, we'd also want improved sparse array handling.
> >
> > This concept might be motivating for a re-implementation of J's type
> > and rank system, with several details changing:
> >
> > (1) The sparse system itself could be made more efficient and general
> > (currently we can't put sparse arrays in boxes),
> >
> > (2) The implementation of the type and rank system could be made more
> > space efficient (allowing for higher ranked arrays of numeric types at
> > the expense of no rank support for certain syntactic types which are
> > not exposed to the user), and
> >
> > (3) The sparse system -- where something other than location in memory
> > is used to represent "array index" -- could be extended to support
> > something other than a fixed length list of numbers as an index (in
> > other words: the system could support a "dictionary type").
> >
> > This is getting to be a bit of a reach, from where we currently stand.
> > And, there's still some important missing pieces which would need
> > careful thought before this sketch could be turned into something
> > practical. But it's interesting to think about...
> >
> > Also... computers do have limits, so it's always going to be the case
> > that a person could invent mathematical structures which strain (or
> > break) a particular implementation of some math concepts.
> >
> > Thanks,
> >
> >
> > --
> > Raul
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to