1. 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!)
2. Re: What atoms ought to be!
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
3. Re: What atoms ought to be!
Lucius Hilley wrote:
>
> I haven't noticed a language that supports imaginary numbers in any way.
> However, Switching from a single value to a set of values is called an
> object.
>
> object x
> x = 42 -- atom
> x = {4, 2}--sequence
>
> snip
Lucius, the languages I know at least are: FORTRAN (all versions)
and XBASIC.
A complex number is an element of a field (mathematically spoken).
Therefor, the same rules are applicable as those for real numbers.
However, this is not true for sequences! Example:
sequence s, p, q, m
q = { 2, 3}
p = {-1, 4}
s = p + q -- = { 1, 7}
m = p * q -- = {-2,12}
If q and p would represent complex numbers like:
{real part, imag. part}, then s would indeed be
the sum of p and q, but m would not be the result
of the multiplication p*q, which is {-14, 5} != {-2,12}.
Complex atoms are therefor meaningful and would have
to be distinguished from sequences!
Have a nice day, Rolf
4. Re: What atoms ought to be!
- Posted by Rolf Schroeder <r.schroeder at BERGEDORF.DE>
Jul 03, 1999
-
Last edited Jul 04, 1999
Nick wrote:
>
> Hi, Rolf
> There are most of the complex number functions you mention, namely:
>
> C, D = complex number, E = either complex or real.
>
> C = c_mod(C) -- modulus value, |C|
...
<snip>
...
> C = c_cotanh(C) -- hyperbolic cotangent of C
>
> in the complex number math library available from the Fractal Factory
> home page, http://www.alphalink.com.au/~metcalfn/ in the downloads
> section.
>
> All functions in the library are also sequence-capable, with sequences
> of complex numbers being kept in the form {{Ar, Ai}, {Br, Bi}, {Cr,
> Ci}...} and so on.
>
> Euphoria is already well-suited to the task of manipulating complex
> numbers way more easily than other languages. Building complex numbers
> into Euphoria proper could confuse the (reasonably?) clear concept of
^^^^^^^
> objects for new users and such, and would only be of use to the smallest
^^^^^^^^^^^^^^^^^^ ^^^^^^^^
> proportion of programmers.
...
^^^^^^^^^^
Beginners might run into the famous "sqrt(-1)" error, it would be
no more an error! To restrict atoms only to real numbers one could
introduce one of the following switches:
"with complex" -- to use all capabilities, or instead
"without complex" -- to restrict to real atoms as it's now.
How small the portion of programmers might be I just want to find
out by my posting: "What atoms ought to be!"
> .... I personally would be delighted by such an
^^^^^^^^^
> addition, but not suprised if Rob dismisses the idea out of hand.
>
Rob is now totally fixed to get the Linus version running. He needs
some time to think about this. We will see.
Nick, I looked into your c_xxx-functions. Except a few
(then easy to write) functions it would have been much easier with
complex atoms!! So, as you mentioned: It would be really a delightful
feature, and an 'euphorian' too!
Have a nice day, Rolf
5. Re: What atoms ought to be!
What is your reason for needing to use complex and imaginary numbers
in Euphoria ?? What real world application do you use them in ??
The average user does not need to use the square-root of -1
or need to solve quadratic equations. Please explain to me why I
need complex numbers.
Thanks Bernie
6. Re: What atoms ought to be!
- Posted by JJProg at CYBERBURY.NET
Jul 03, 1999
EU>What is your reason for needing to use complex and imaginary numbers
EU>in Euphoria ?? What real world application do you use them in ??
EU>The average user does not need to use the square-root of -1
EU>or need to solve quadratic equations. Please explain to me why I
EU>need complex numbers.
EU>Thanks Bernie
I have two things to add to this thread:
First, the need for complex numbers:
Complex and imaginary numbers are very useful in many applications.
Solving some quadratic equations and factoring some polynomials require
complex numbers. I am almost certain, that complex numbers are used in
physics, though I don't know any examples.
Since I (the square root of -1) is a number (an imaginary one, but a
number), there can be mathematical expressions that use it. Let's see if
I can find an example in my notes...
Ok, here's an equation:
V = ZI
V = Voltage (Volts)
Z = Impedence (Ohms)
I = Current (amps)
Somehow, though I don't know how (I only know a little about
electronics), V, Z, and I can be complex numbers. So probably someone
designing an electronics program (who knew how to use this equation)
would need to use complex numbers.
Sorry if my explination of the need for complex numbers is lacking, but
my point is that they are useful.
Now, my suggestion for implementing complex numbers:
i (sqrt(-1)) is like any other variable, so I suggest that someone (perhaps
I'll beable to after I learn a little more math - I'd be glad to help if
anyone undertakes this project) write an algebraic library
(perhaps calculus too, but I don't know what I'm talking about here - I
just finished Algebra II). This could greatly simplify some tasks, and
would be in my opinion much more elegant and useful than just a complex
number library. It would also be optional, so it wouldn't add complexity
to most Euphoria programs that will never have use for such a library,
but it would be incredibly valuable for those programs that do need it.
Jeffrey Fielding
JJProg at cyberbury.net
http://members.tripod.com/~JJProg/
7. Re: What atoms ought to be!
Yes complex numbers are used in the analysis of alternating current
circuits. Mathematicians use letter i to represent the value of the sqrt -1
In electronics we use the letter j because i is used to represent current.
But, My whole point is this.
Euphoria is not a universal langauge. There is no universal computer
langauge. Ada was suppose to be a universal language but I think
any Ada expert will tell you that there things that are not supported.
The Euphoria computer langauge was designed to be easy to learn and
easy to use for certain applications but it can't have features added
unless they benifit the majority of the users.
The Application should dictate which computer language to use not
how can I change a computer langauge to fit my application.
If you have an application that needs to use complex numbers then
you should be using Fortran ( a formula tranlation language ).
That is why there are many languages with so many different features.
If your writing a application the secret is to select the computer lanaguge
designed to perform the job.
If someone really wants to use complex numbers in Euphoria then maybe one
of the Mathematicians on the list can write a library for complex numbers
using assembler in an include file because it would be easier
than having Rob rewrite the language. The Mathematicians could work on it
just like the EE editor or any other project, but how many users will use
it.
Thanks Bernie
8. Re: What atoms ought to be!
For the Euphoria Fractal program to end all Euphoria Fractal programs,
read on....
Bernie Ryan wrote:
.......<snip>
> If someone really wants to use complex numbers in Euphoria then maybe one
> of the Mathematicians on the list can write a library for complex numbers
> using assembler in an include file because it would be easier
> than having Rob rewrite the language. The Mathematicians could work on it
> just like the EE editor or any other project, but how many users will use
> it.
<snip>......
This is precisely what I intend to do eventually, although it may not be
quite as simple as just math functions.
I have found that having the math functions in assembler and the formula
in Euphoria is actually _slower_ than using all Euphoria math. This is
due to the overhead imposed by having to poke, peek and translate large
floating point numbers with every call to a function. This easily
swamps any benefit to using assembler in the first place.
To get real speed, I intend to make something that dynamically assembles
routines from entire complex number formulas. This will be used purely
for fractals, so the iterator will probably be a part of it too. I
cannot say how useful this will be to anybody but me, really.
Anyway, complex number affectionados are probably better off with my
c_math.e library as it stands. Though lots of benchmarking, I
understand it to be more or less the fastest, if not the prettiest
arrangement of each function.
Fractal lovers also take note: my long-promised program Fractal Factory
alpha version v0.9a should have been made available by the time you read
this. It's a reasonably complete fractal explorer with animations, 3D,
online help and more. Download it from the Fractal Factory home page,
http://www.alphalink.com.au/~metcalfn in the downloads section. I would
appreciate feedback or questions of most any kind at this stage.
As alpha software you should realize that it probably still has some
whopper bugs! It shouldn't break anything except perhaps itself,
though.
Fractal Factory makes extensive use of the complex number library and
generates all it's fractals using native Euphoria math. It is
consequently nowhere near as fast as Fractint or others, but it has many
unique features and still makes some pretty "wow" images.
Euphoria fractal programmers may be interested to note that Fractal
Factory can write fractal code in Euphoria. The "External" drawing
methods write the current fractal and all parameters as a simple program
with all the procedure calls, generic conditionals and so forth taken
out, then executes it in a shell. This program, with minimum library
support, could be taken and used for any other purpose...?
The formula parser uses the Euphoria language syntax, and new formulas
can be typed in, debugged and then added into the code of the program
itself permanently. Lists of additional plug-in fractal types can be
created or downloaded as they become available and easily added into the
code as if they were already there.
If you want to assist me with the alpha testing, downloaders please send
me your opinions, any bug reports and a quick description of your system
configuration.
Thanks all,
--Nick
9. Re: What atoms ought to be!
- Posted by Rolf Schroeder <r.schroeder at BERGEDORF.DE>
Jul 04, 1999
-
Last edited Jul 05, 1999
Bernie Ryan wrote:
>
> Yes complex numbers are used in the analysis of alternating current
> circuits. Mathematicians use letter i to represent the value of the sqrt -1
> In electronics we use the letter j because i is used to represent current.
> But, My whole point is this.
> Euphoria is not a universal langauge. There is no universal computer
Only if atoms would be algebraically closed!
> langauge. Ada was suppose to be a universal language but I think
> any Ada expert will tell you that there things that are not supported.
> The Euphoria computer langauge was designed to be easy to learn and
> easy to use for certain applications but it can't have features added
> unless they benifit the majority of the users.
Hwo knows the majority? One has to offer interesting features!
> The Application should dictate which computer language to use not
> how can I change a computer langauge to fit my application.
> If you have an application that needs to use complex numbers then
> you should be using Fortran ( a formula tranlation language ).
> That is why there are many languages with so many different features.
> If your writing a application the secret is to select the computer lanaguge
> designed to perform the job.
Indeed: why I need Euphoria if a lot of things could be done with
existing
languages? What is for you so 'euphorian' that could not be solved with
other labguages?
>
> If someone really wants to use complex numbers in Euphoria then maybe one
> of the Mathematicians on the list can write a library for complex numbers
> using assembler in an include file because it would be easier
> than having Rob rewrite the language. The Mathematicians could work on it
> just like the EE editor or any other project, but how many users will use
> it.
>
> Thanks Bernie
Bernie: I guess you would even be happy with integer atoms only. Real
number handling could be supplied by a mathematician writing
a real number library!
Here I wrote an example from the real world:
Calculate reactance and phase shift of the parallel resonance curcit.
-- unproofed (and impossible) code ahead!
-----------------------------------------
with complex -- if necessary at all
include misc.e -- PI
constant R = 100 -- [ohm]
constant L = 0.001 -- [Henry]
constant C = 0.001 -- [Farad]
constant lf = 10 -- [Hz]
constant uf = 1000 -- [Hz]
constant np = 1000 -- number of values to calculate/plot
atom omega -- angular frequency
atom gR, gL, gC -- reverse of R, L, C
atom Z -- complex reactance of curcit
sequence z_array -- Absolute value of reactance
sequence p_array -- angle (phase) of reactance
sequence x_points -- x-coordinats for plotting
gR = 1.0 / R -- reverse resistance [moh]
z_array = {} -- to keep ans. value of reactance
p_array = {} -- to keep phase
for f = lf to uf by (uf - lf)/(np-1)
omega = 2.0 * PI * f
gL = 1/( 0, omega*L) -- complex reverse inductive reactance
gC = ( 0, omega*C) -- complex reverse capacitive reactance
Z = 1/(gR + gL + gL) -- reactance of whole curcit
Z = polar(Z) -- (abs(Z),angle(Z)), a most important
function!
z_array &= real(Z) -- the real part of Z = abs(Z)
p_array &= imag(Z) -- the imaginary part of Z = angle(Z)
x_points &= f -- plot-points
end for
plot(z_array, x_poinnts) -- plot abs. value of reactance
plot(p_array, x_poinnts) -- plot phase shift of reactance
------------------------------------------------------------------
I would like to ask you, Bernie, what you are using any computer
language for? I hope it's a real world application! Please let me know.
There are many other applications from science and engineering, not only
handling of alternate currents. One needs complex numbers to compute the
'real' world, the real numbers are not sufficient!
By the way: the scientific pocket calculators of HP even are capable of
calculating with complex numbers!
Also, there are possibly more people handling algebraic equations then
you might think off!
If you exclude all scientists/engineers who need complex numbers, they
would not be much interested in Euphoria. So you may indeed conclude
that
they are a minority in the world of Euphoria and therefor there would be
no necessity of complex atoms in Euphoria ..... .
Have a nice day, Rolf
10. Re: What atoms ought to be!
I am sorry I did not mean to offend anyone on the list.
Euphoria users are alway asking for new features ( including myself )
but the users don't always explain what they need to use them for.
They always say I want this feature but no explaination of why it's
needed. Everyone on the list is not a Mathematician or Electronic Engineer
so sometimes the explaination has to be at a level that the majority
will understand. That is why I was asking for someone to explain what real
world application they needed them for.
Again, I am very sorry if I offended you.
Thanks Bernie
