> I can't track down McDonnell's paper on the function,

An incomplete version can be found at
http://www.jsoftware.com/papers/eem/complexfloor.htm



On Tue, Jan 24, 2012 at 8:02 PM, Marshall Lochbaum <mwlochb...@gmail.com>wrote:

> You're correct about + instead of - . However, adding 0.5j0.5 rather than
> 0.25j0.25 is correct:
>
>   floor =. <.&.+.   NB. equivalent to floor in the model I described
>   floor@:(+&0.5j0.5) 5.6
> 6
>   floor@:(+&0.25j0.25) 5.6
> 5
>
> The problem with | is that it is inconsistent with the reals, which is
> unnecessary, as the | I described is consistent over reals and complex
> numbers.
>
> My issue with <. is that it's just too complicated: it's difficult to
> understand and thus to use. I also can't think of any applications of this
> use, as opposed to the simpler <.&.+. which can be used to find the nearest
> complex number. I can't track down McDonnell's paper on the function, so I
> can't find any more convincing explanation than the one included in the
> dictionary about "convexity, translatability, and compatibility," which are
> shared by a large number of floor functions.
>
> Marshall
>
>
> On Tue, Jan 24, 2012 at 10:02 PM, Shannon Ian <
> ian.shan...@environment.nsw.gov.au> wrote:
>
> > Marshal,
> >
> >
> >
> > You move a complex number too far to get the nearest (Gaussian) integer.
> >
> >
> >
> > Should be (+&0.25j0.25)
> >
> >
> >
> > That is
> >
> > round =: <. @: (+&0.25j0.25)
> >
> > will round a complex (and real and pure imaginary) number to the
> "closest"
> > integer.
> >
> >
> >
> > (Note your typo --- should be + not - for nearest integer)
> >
> >
> >
> > FWIW I support the (very well done) implementation of <. and | and #.
> >
> > The point is that going from 1D to 2D (or Real to Complex) often the
> > obvious way is not the appropriate way. You need to look at the higher
> > dimension and check that going down to a lower dimension still makes
> sense.
> > In the complex domain you need to treat the complex number as an entity,
> > rather than 2 elements.
> >
> >
> >
> > However in this case we can say "Don't adjust your TV, the problem is
> with
> > reality", well with the usual defn of modulo arithmetic on the integers.
> >
> >
> >
> > As pointed out before to do arithmetic (mod N) you just need N
> equivalence
> > classes and rules for addition (and subtraction and by extension
> > multiplication) using these equivalence classes.  These classes are
> > labelled 0, 1, 2, ... (N-1) by convention.  This is convention is so
> > ingrained that there is little chance of changing it.  However note that
> > lots of J programs would run correctly if the equivalence classes were
> > mapped to  (0, 1, 2, ... (<.-:<:N), (<.--:N), ... _1 ) because of J
> > negative indexing etc. The addition, subtraction, multiplication of the
> > equivalent classes using the mathematical rules for the integers with the
> > same labels are going to be correct.
> >
> > It is only with the final use of the numbers when the equivalence classes
> > are mapped to the integers that you may come unstuck.  However note that
> at
> > present if you do modulo 12 arithmetic (as a model of hours on a clock
> > face) you run into problems coming back to the integers because the
> labels
> > don't match!  You need to map the equivalent classes labelled (0, 1,
> 2,...
> > 11) onto hours labelled (12, 1, 2, ... 11). This is in effect similar to
> > mapping (0, 1, 2, 3, 4, 5, _6, _5, _4, _3, _2, _1) onto (0, 1, ... 11)
> >
> >
> >
> > Note: There is not any mathematical LAW about labelling these equivalence
> > classes, any more that there is a LAW of mathematics that says you need
> to
> > do multiplications before additions!
> >
> >
> >
> > My only beef is that the dictionary doesn't have better documentation of
> > <. and | for complex numbers.  Perhaps something for the community to do!
> >
> >
> >
> > Ian
> >
> > Ian Shannon
> >
> > Landscape Modelling & Decision Support
> >
> > Scientific Services
> >
> > Office of Environment and Heritage
> >
> > Department of Premier and Cabinet
> >
> > PO Box A290
> >
> > Sydney South
> >
> > NSW      1232
> >
> > T: +61 2 99 955 490
> >
> > E =: {~&:>`(i.&.:>)/
> >
> > E'.@aeghimnorstuvw
> > ';'0123456789abcdef';'6280b528898138e6a98738c08bf049e02d'
> >
> > NB.  Nub_of_email     index_alphabet      index_into_sorted_nub_of_email
> >
> >
> >
> > Date: Sun, 22 Jan 2012 13:26:20 -0500
> >
> > From: Marshall Lochbaum <mwlochb...@gmail.com>
> >
> > Subject: Re: [Jprogramming] 5|0 1 2 3 4 is not equal to 5|0 1 2 3 4
> >
> >       j.0
> >
> > To: Programming forum <programming@jsoftware.com>
> >
> > Well, if we can agree that (-<.) -: 1&| , then these rules are already
> >
> > proving inconsistent.
> >
> >
> >
> >   1 | 0.6j0.6
> >
> > _0.4j_0.4
> >
> >   (-<.) 0.6j0.6
> >
> > _0.4j0.6
> >
> >
> >
> > Here is the model I'm currently aiming for:
> >
> > 1&| for reals is defined as the function which shifts by an integer such
> >
> > that (0<:1&|) and (1>1&|)
> >
> > 1&|  -:  1&|&.+.
> >
> > b&|  -:  1&|&.(%&b)
> >
> > <.  -:  (- 1&|)
> >
> > ($0)&#:  -:  ($0)"_
> >
> > (bs,b)&#:  -:  ((bs #: <.@%&b),b&|)    NB. bs a list, b a scalar
> >
> >
> >
> > These definitions are consistent with current definitions for real
> numbers
> >
> > and provide a very natural extension to complex numbers. Furthermore they
> >
> > have the desirable property that <.@:(-&0.5j0.5) gives the nearest
> complex
> >
> > number to the argument. However, they're still up for revision if someone
> >
> > can convince me either that the current definition of <. makes sense or
> >
> > that the current definitions are used in important code that would break
> >
> > under this remodeling.
> >
> >
> >
> > Marshall
> >
> >
> >
> >
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
> > This email is intended for the addressee(s) named and may contain
> > confidential and/or privileged information.
> > If you are not the intended recipient, please notify the sender and then
> > delete it immediately.
> > Any views expressed in this email are those of the individual sender
> > except where the sender expressly and with authority states them to be
> the
> > views of the Office of Environment and Heritage, NSW Department of
> Premier
> > and Cabinet.
> >
> > PLEASE CONSIDER THE ENVIRONMENT BEFORE PRINTING THIS EMAIL
> > ----------------------------------------------------------------------
> > 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