🚀 go-pugleaf

Richard Pitre wrote:
>Why leave out complex numbers and complex
>transcendental functions?

Because Oberon is a systems programming language, not a number-crunching
language.

If you wanna crunch complex numbers with complex transcendental functions,
and you don't want to code it yourself, you need to be coding in FORTRAN. 
This is what FORTRAN was designed to do.

Use the right tool for the right job.

John Strohm wrote:
> 
> Richard Pitre wrote:
> >Why leave out complex numbers and complex
> >transcendental functions?
> 
> Because Oberon is a systems programming language, not a number-crunching
> language.
> 
> If you wanna crunch complex numbers with complex transcendental functions,
> and you don't want to code it yourself, you need to be coding in FORTRAN.
> This is what FORTRAN was designed to do.
> 
> Use the right tool for the right job.

Yes, and FORTRAN was also designed to read punch-cards just
like the Jacquard loom.

I find that distinguishing systems programming from numeric
programming is not so helpful these days. In order to
run a big job one often has to coordinate the actions of
several to several tens (hundreds ?) of machines. Even if
one is not programming a parallel computer one often finds
that one machine handles the batch queue, another handles
the mass storage, another does the visualization, while yet
another actually runs the numeric code.  The whole process
is tied together with shell scripts, and non-standard system
calls from FORTRAN. At least from a users point of view. :)

One might argue that one should use the correct tool for 
the job in each of these cases: batch-script for the batch-queue,
shell-scripts for the shells and file transfers, FORTRAN
for the numerics, C for systems work and graphics. 

Unfortunately, this process seems error prone,
and the interfaces between the various tools are not well
defined. It all seems managable, though limiting, and I wonder 
what a unified approach might bring about.

-- 
Mike Rilee NASA/GSFC Mailstop 930.0 Greenbelt, MD 20771
mrilee@cicero.gsfc.nasa.gov Ph. (301)286-9867 Fx. (301)286-1777

Hello!

Richard Pitre wrote:
> 
> Why leave out complex numbers and complex
> transcendental functions? Maybe Oberon is slightly simpler without this
> but any programs that use complex arithmetic are automatically more complicated
> and less efficient without language support.
> I see no good argument for leaving complex arithmetic out of Oberon
> if you've already gone to the trouble to include  floating point numbers.
> Why alienate so many people who desparately need good tools like this?
> If you don't think its a problem then its because you've never tried
> to do it. The readability goes to hell.
> 
> richard

As far as we (here in xTech) know Oakwood Guidelines propose to 
implement complex arithmetics and we have implemented it in XDS.

Regards,
Andrew Khapugin (hady@iis.nsk.su),
xTech Ltd.

Richard Pitre wrote:
> 
> Why leave out complex numbers and complex
> transcendental functions? Maybe Oberon is slightly simpler without this
> but any programs that use complex arithmetic are automatically more complicated
> and less efficient without language support.
> I see no good argument for leaving complex arithmetic out of Oberon
> if you've already gone to the trouble to include  floating point numbers.
> Why alienate so many people who desparately need good tools like this?
> If you don't think its a problem then its because you've never tried
> to do it. The readability goes to hell.
> 
> richard
Have you ever wondered why complex numbers are not a part of C, C++, Ada, or
Smalltalk?  If every extension that someone thought was important was
incorporated into every language then we would have a bunch of PL/1 compilers
floating around that no one could use.  Yes, complex numbers are important to
some scientific calculations, but the answer would be to develop a standard
class module called Complex.  In fact, the whole reason for object-oriented
languages is to be able to make extensions such as that.  Unfortunately, 
while there are many standard modules for handling fancy GUI designs for 
both Oberon/F and System 3, some of the simple but practical modules have
been overlooked.  Oberon/F just recently added a string library, but it's
done almost exclusively from a procedural instead of an OO point of view.
The procedure call interfaces are bulky and unintuitive.  I'm still looking
for a string library in any language that will let me handle strings as 
easily as I can handle them in BASIC.

Mike Rilee (mrilee@cicero.gsfc.nasa.gov) wrote:
: John Strohm wrote:
: > 
: > Richard Pitre wrote:
: > >Why leave out complex numbers and complex
: > >transcendental functions?
: > 
: > Because Oberon is a systems programming language, not a number-crunching
: > language.
: > 
: > If you wanna crunch complex numbers with complex transcendental functions,
: > and you don't want to code it yourself, you need to be coding in FORTRAN.
: > This is what FORTRAN was designed to do.
: > 
: > Use the right tool for the right job.

: Yes, and FORTRAN was also designed to read punch-cards just
: like the Jacquard loom.

: I find that distinguishing systems programming from numeric
: programming is not so helpful these days. In order to
: run a big job one often has to coordinate the actions of
: several to several tens (hundreds ?) of machines. Even if
: one is not programming a parallel computer one often finds
: that one machine handles the batch queue, another handles
: the mass storage, another does the visualization, while yet
: another actually runs the numeric code.  The whole process
: is tied together with shell scripts, and non-standard system
: calls from FORTRAN. At least from a users point of view. :)


: -- 
: Mike Rilee NASA/GSFC Mailstop 930.0 Greenbelt, MD 20771
: mrilee@cicero.gsfc.nasa.gov Ph. (301)286-9867 Fx. (301)286-1777


If you're interested in a modern object oriented langauge which is
well suited for scientific programming (and lots of other things)
I urge you to try Sather.  I have been successfully using it on 
my own research programs for a long time. 

http://www.icsi.berkeley.edu/~sather

Personally, I think its language design surpasses oberon substantially.


Ada95 might be another practical option. 

For systems programming, what does O give you over Modula-3, whose runtime
gives you *now* portable distributed objects?

Richard Pitre (pitre@n5160d.nrl.navy.mil) wrote:
> Why leave out complex numbers and complex
> transcendental functions? 

For a very simple reason: there are two equally viable implementations
Do you want an angle/radius or real/imaginary representation?
Please consider the consequences of a choice. If you don't show 
(explicit) what choice you made, you won't have any idea of the 
run-time consequences of what you write.

Stephan

> If you don't think its a problem then its because you've never tried
> to do it. The readability goes to hell. 

If you think it is a problem you have never tried it ;-)

Hi!

On Fr 29.03.1996 around 21:04:09 mbk@caffeine.engr.utk.edu (Matt Kennel) wrote
in message "Why no Complex Arithmetic ?":

> I urge you to try Sather.
> [...]
> Personally, I think its language design surpasses oberon substantially.
> [...]
> Ada95 might be another practical option. 
> [...]
> For systems programming, what does O give you over Modula-3, whose runtime
> gives you *now* portable distributed objects?

   I  see  a  lot  of  features  that Oberon-2 is missing compared to these
languages,  but  (for  me)  Oberon-2  is the only alternative.  It's widely
availiable  (even  for  my  "exotic"  platform),  well  designed  and (most
important) easy to read.

   I had a look at Sather and Modula-3 and just can't understand the syntax
involved.   Of  course that might be caused by my limited intelligence.  To
be  provocative:   It's easier to read a properly written C++ fragment than
an  equivalent  Sather fragment (slight exaggeration intended).  So I stick
to Oberon-2.
                  _
By(T)e...   /| _ //3000 /\ People who use Pascal for serious programming |\
   Peter... \| \X/\miga \/ fall into a fatal trap.  (Brian W. Kernighan) |/