Re: What atoms ought to be!

new topic     » goto parent     » topic index » view thread      » older message » newer message

Rolf,

I think this would be a way cool feature!

It would put Euphoria on par with languages like Fortran that have
extensive mathematical capabilities built in.  It would even take a step
past them due to Euphoria's automatic type conversions.

It seems like this could be implemented without much penalty by using an
extra bit in the internal type field.  Another option that would probably
cost a little more in performance would be to allow overloading the
standard operators.  This would probably be a little more awkward though.
 What do you think Rob?

Joe

-----Original Message-----
From:   Rolf Schroeder [SMTP:r.schroeder at BERGEDORF.DE]
Sent:   Thursday, July 01, 1999 12:12 PM
To:     EUPHORIA at LISTSERV.MUOHIO.EDU
Subject:        What atoms ought to be!

To Rob and all of the Eu-comunity, number freaks!

I thought some time about why and who is using Eu and for what reasons.
I switched to Eu for its simplicity to sove numerical problems like data
reduction including the easy implementation of graphical representations
(like function plots) on screen.  It is also an interesting and easy to
use alternative for engineers and physicists!

The elegance of Eu is due to the easy and uncomplicated way writing
programms with an minimum of elements but allmost all possibilities.

The two data objects, atom and sequence, are the central part off all.
Especially that atoms switch quietly between integer and real numbers
is very practical.
Example:  (pseudo code)

      atom a
      a = 3.1
      atom(a)                 -- TRUE
      integer(a)              -- FALSE
      a = floor(a)
      atom(a)                 -- TRUE
      integer(a)              -- TRUE now

The importand point here is the internal type conversion (forward and
backwards) which took place.

However, one importand feature I'm mising here:  that is the necessity
solving in an easy way numerical problems where complex numbers are
involved.
It would be very handy for handling matters like:

      electrical engineering,
      Fourier computations like transforms,
      solving algebraic equations,
      quantum mechanics,
      fractals (for fun at least),
      graphic calculations in certain cases,

      and many more.... .

Ok, every complex computation may be solved by splitting the problem in
real and imaginary part and solve each in real number computation as far
as you have only additions/substractions.  For multiplications and
divisions as well as for all functions - like power() - you must write a
set of 'complex' functions.

But it would be much easier (and much more elegant in the sence of
Euphoria) to have the type atom switching quitely between integer, real,
and compelx - forward and backward - if necessary.

      Example:

      atom a, b, c, r, i, radius, angle
      sequence s

      c= (7.5, 10)      -- definition: complex in parenthesis
      r = c(1)          -- definition: c(1) is the real part of c
      i = c(2)          -- definition: c(2) is the imaginary part of c,
                        -- which is here integer now

      a(1) = 3          -- a is real if not initialized complex before
      a(2) = 1          -- now a is complex: a = (3,1)
      b(2) = -1         -- b is complex: b = (0,-1)
      a(1) = -2         -- a = (-2, 1) , real part of a replaced
      c = a + b         -- c = (-2, 0) = -2 (switched to integer!!)
      c = a - b         -- c = (-2, 2)
      c = a * b         -- c = ( 1, 2)
      c = a / b         -- c = (-1,-2)

      atom(c)           -- TRUE   is c an atom?
      real(c)           -- FALSE  definition: real() analog to integer()
      integer(c)        -- FALSE  is c integer?
      atom(r)           -- TRUE   is c(1) an atom?
      atom(i)           -- TRUE   is c(2) an atom?
      integer(r)        -- FALSE  is c(1) integer?
      integer(i)        -- TRUE   is c(2) integer?

One could think of defining a sequence of length 2 to use it as an
complex number. For adding and subdtracting of sequences is defined,
it would be true for this type of complex operations too!  However,
there is no multiplication and division, and from here on it becomes
crumbly.  You have to write functions even for this elementary
operations!  (I started and wrote functions as:  csqrt(), cpower(),
cexp(), and clog() as well as cmul() and cdiv().  But I gave up.)

In case that atoms could switch quietly to complex you would
be able to write:

        c = (7.5, 10)
        a = sqrt(c)             -- a will be a complex atom now
        a = 2 * sqrt(c(1)*c(1) + c(2)*c(2)) -- a is an integer!

All internal numerical functions should be able to handle also the
complex atom:

        sqrt(),
        sin(),
        cos(),
        tan(),
        arctan(),
        log(),
        power(),
        floor(),       -- floor(c) := (floor(c(1)),floor(c(2)))
        remainder().   -- (in the same way like floor())
  and new:
        exp() .        -- exp(c) := (cos(c(1)),sin(c(2)))

Additionaly there could be functions like:

     1) a = polar(c)    -- a is complex : a = (radius, angle), so that:
        radius = a(1)   -- radius of c im polar coordinates, (= abs(c)!)
        angle  = a(2)   -- corresponding angle.

        Instead of polar() one could introduce an arctan2() function:
          phi = arctan2(c(2),c(1))
        but now the radius has to be computed separately:
         radius = sqrt( c(1)*c(1) + c(2)*c(2) ) ,
        also arctan2() is not generaly able to handle complex input.

     2) a = conjugate(c)         -- the conjugate complex of c
                                 -- ( a(1) = c(1)  a(2) = -c(2)  )

More examples, you may write:

        a = sqrt(-1)    -- a is (0,-1), the imaginary unity.
                        -- The sqrt() would never fail again!

        c(1) = 3        -- c would stay real as long as imaginary part
                        -- is not initialised.
        c(2) = 4        -- c is now: (3,4). (If the real part of c was
not
                        -- initialised before it would be 0 now.)

        s = {a,c}       -- a sequence of length 2 with (complex) atoms!
        s *= s          -- s = {-1,(-7,24)}, the atoms a,c are squared
now,
                        -- note: first atom is integer now!

        printf(1,"(%d,%d)\n",{c}) -- should print: (3,4)  .

        . . . and so on.

I know, this means a larger change of Euphoria, and I'm not sure
how the impact on speed for allready existing (real) programms would
be. As far as I see this enhancement would be allmost (if not at all)
compatible to existing programms.

I would appreciate your oppinion about this 'complex' enhancement
of type 'atom' and the numerical internal functions.

Especially I would appreciate the opinion of people who could use
the introduction of complex numbers into EUPHORIA!


Thanks a lot for your patience to read this long posting, Rolf

(I hope it will not overseen due to the LINUX-euphoria just starting!)
________________________________________________________
NetZero - We believe in a FREE Internet.  Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu