On Nov 25, 8:31 am, "Thomas F. Burdick" <tburd> wrote:
> On 25 nov, 16:43, Xah Lee <xah> wrote:
>
> > Native support of complex numbers in a general purpose language of
> > today, is absolutely necessary!
>
> How do you figure? It seems more like native support for complex
> numbers were more valued 20-30 years ago. The GP languages with such
> support date from then ... off the top of my head, I can't think of a
> single such language "of today".

On Nov 25, 9:54 am, Rock <roccoro> wrote:
> > > C99?
>
> > Python?
>
> And let me add that it's not just a matter of supporting complex
> floats. CL and Scheme have always been able to support a full numeric
> tower. You've got complex rationals and gaussian integers just as much
> as you have complex floats. That is really cool, I believe. I think
> it's a big mistake on Clojure's part to underestimate this fact.

Adding to what has been said in this thread ...

lisp dialects always supported the complex numbers as well as rational
numbers. Clojure being lispy, not supporting these will not please its
main audience.

also, functional langs are in general strong in math and AI fields.
Full support of complex numbers in necessary.

Sure, 3rd party can always write one. To have full complex number
support to the level of industrial use, is not trivial. Even with the
existing 3rd party open source complex number packages for java... it
makes user to wonder to what degree they are robust... this means lots
of time spent to test it out, and there's the arbitrary choice of
syntax made by the 3rd party. Two 3rd party complex number libs will
likely not be compatible, etc.

as mentioned, C99, Python support it natively. In python, as far as
i've seen, it's support is minimal... just allowing to add and
multiply with it, possbly also taking the phase/degree, length, but
not necessarily allowing other functions such as square root or trig
to work with complex numbers. So, here we see that full support is not
trivial. Also, if we implement complex numbers on top of a lang that
doesn't natively support it, then making it work fast for industrial
use such as scientific computing is also not trivial.

Java is rather a low level lang as opposed to scripting lang such as
perl, python, ruby, etc. Also it is a large lang with heavy
architecture that does almost anything, as opposed to C. As such, lack
of native complex number support is problematic.

Sure, most programing tasks don't involve complex numbers. But with
the proliferation of langs, esp in the past 5 years, you have so many
languages coming out, and so many functional languages too even ... as
time matches goes on, lang are just getting higher and higher level,
and that basically means it can do a lot more things out of the box,
lacking complex numbers will mean your lang loses a edge. I doubt any
general purpose lang as heavy weight as java from today on will not
have complex num support.

i don't think we are seeing the end of proliferation. I think there
will be more and more. Even today it's hard to keep track what's
coming into the scene.

These new langs are not just random toys by random student of some
random proof of concept or weird idea. Each is sufficient robust in
some way to be usable in some industry or academia or niche.

Look at this list:

• Proliferation of Computing Languages
http://xahlee.org/UnixResource_dir/writ/new_langs.html

and go read Wikipedia on the rest tens of langs you never heard of
even for us tech geekers who keep our heads in tech and lang news. If
you spend few hours reading, you'll find that how each is rather
extensive ... not something some nobody curios university compiler
student made as is the situation say before 2000.

In anycase, it'd be fruitful if we can have a list of lang today and
whether they support complex numbers. Here i'll start:

Mathematica yes
Common Lisp yes
Scheme Lisps yes

NewLisp ?
Arc yes?
Qi yes?
Scala ?
Dylan ?
Coq ?

Sleep ?
Groovy ?

ObjectiveC ?
C# ?
D ?

Java no
Erlang ?
Haskell ?
Concurrent Clean ?
Mercury ?
Q ?
Qz ?
OCaml ?
Alice ?
F# ?
SmallTalk ?

Scratch ?
ActionScript no?
Processing ?

Python yes
Lua no?
Tcl no?
Ruby ?
Perl6 ?
Javascript no?
AppleScript no?

APL
Forth
Logo
Pascal

Xah
∑ http://xahlee.org/

☄

Bakul Shah wrote:
> Thomas F. Burdick wrote:
>> On 25 nov, 16:43, Xah Lee <xah> wrote:
>>
>>> Native support of complex numbers in a general purpose language of
>>> today, is absolutely necessary!
>>
>> How do you figure? It seems more like native support for complex
>> numbers were more valued 20-30 years ago. The GP languages with such
>> support date from then ... off the top of my head, I can't think of a
>> single such language "of today".
>
> C99?

Today != 1999

On Nov 25, 10:54 pm, Xah Lee <xah> wrote:
[..]
>
> APL
> Forth
> Logo
> Pascal
>
>   Xah
> ∑[..]
>
> ☄

In Python there's no problem with applying mathematical functions to
complex numbers (sin, atan, sqrt, etc...). Fully supported. Not as
extensively as CL or Scheme of course (no complex rationals for
instance), yet supported to a fair extent.

Rock

Xah Lee wrote:
> In anycase, it'd be fruitful if we can have a list of lang today and
> whether they support complex numbers. Here i'll start:
> ...
> C# ?

No.

> OCaml ?

Yes.

> F# ?

Yes.

On 25 nov, 18:20, Bakul Shah <bakul+use> wrote:
> Thomas F. Burdick wrote:
> > On 25 nov, 16:43, Xah Lee <xah> wrote:
>
> >> Native support of complex numbers in a general purpose language of
> >> today, is absolutely necessary!
>
> > How do you figure? It seems more like native support for complex
> > numbers were more valued 20-30 years ago. The GP languages with such
> > support date from then ... off the top of my head, I can't think of a
> > single such language "of today".
>
> C99?

Right, this whole thread exposed a blind spot in my reasoning: I was
working under the unstated assumption that *useful* complex numbers
require rationals, which in turn pretty much require bignums to be
useful. Which pretty much leaves ... various Lisps, some Smalltalks,
mathematical languages (which is pushing the "GP" thing a bit),
and ... ?

The blind spot is of course because complex numbers are a useful
addition to rationals. Not having rationals is appalling, but common,
and it seems only older languages care about them.

On Nov 26, 9:46 am, "Thomas F. Burdick" <tburd> wrote:
>
> Right, this whole thread exposed a blind spot in my reasoning: I was
> working under the unstated assumption that *useful* complex numbers
> require rationals, which in turn pretty much require bignums to be
> useful. Which pretty much leaves ... various Lisps, some Smalltalks,
> mathematical languages (which is pushing the "GP" thing a bit),
> and ... ?
>
> Not having rationals is appalling, but common,
> and it seems only older languages care about them.

I agree that any language worth it's salt for scientific purposes
should have complex numbers, but the reason most of us don't care
about rationals is because we have to do things with transcendental
functions... I don't need an array of rational numbers when the first
thing I'm going to do with that array is take an FFT (which multiplies
the elements by sines and cosines...). As such, arbitrary precision
rational numbers are *useless* to me.

On Nov 25, 2:57 am, Jon Harrop <j> wrote:
> Mirko wrote:
>>
> This is just another shortcoming of the JVM. No tail calls is my pet peeve.
>> Right.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.[..]

That from the tail calls is one of the things that puzzles me the
most. I mean, the lambda papers date from the mid 70's and a little
bit later, and in them, Steele and Sussman show how languages can be
built, and then about 20 years later, Java is created without
(seemingly) any of the lessons that Steele and Sussman have provided,
despite Steele also working on Java, together with Gabriel (any other
people from the 70's/80's Lisp community?).

On 26 Nov., 17:46, "Thomas F. Burdick" <tburd> wrote:
> On 25 nov, 18:20, Bakul Shah <bakul+use> wrote:
>>
>> Right, this whole thread exposed a blind spot in my reasoning: I was
> working under the unstated assumption that *useful* complex numbers
> require rationals, which in turn pretty much require bignums to be
> useful. Which pretty much leaves ... various Lisps, some Smalltalks,
> mathematical languages (which is pushing the "GP" thing a bit),
> and ... ?
>
> The blind spot is of course because complex numbers are a useful
> addition to rationals. Not having rationals is appalling, but common,
> and it seems only older languages care about them.

Steele said in a Fortress presentation that complex numbers are
important. But they should not be part of the core language. The
language should instead be extensible that it is possible to add them
via a library. So in Fortress complex numbers are provided via
library.

jurgen_defurne wrote:


> That from the tail calls is one of the things that puzzles me the
> most. I mean, the lambda papers date from the mid 70's and a little
> bit later, and in them, Steele and Sussman show how languages can be
> built, and then about 20 years later, Java is created without
> (seemingly) any of the lessons that Steele and Sussman have provided,
> despite Steele also working on Java, together with Gabriel (any other
> people from the 70's/80's Lisp community?).


It was a security thing, though things have moved on a bit:

"A Tail Recursive Machine with Stack Inspection", Clements and
Felleisen, 2004
http://users.csc.calpoly.edu/~clemen...f-toplas04.pdf
http://lambda-the-ultimate.org/node/1333

| Security folklore holds that a security mechanism based on stack
| inspection is incompatible with a global tail call optimization
| policy. [...] In this article we prove this widely held belief
| wrong. [...] The Java design team, for example, chose not to
| provice a TCO implementation in part because of the perceived in-
| compatibility between tail call optimizations and stack inspection.
| The .NET effort at Micrsoft provides a runtime system that is
| properly TCO - except in the presence of security primitives, which
| disable it.

On Nov 26, 9:54 am, "jos...@corporate-world.lisp.de" <jos...@corporate-
world.lisp.de> wrote:
> Steele said in a Fortress presentation that complex numbers are
> important. But they should not be part of the core language. The
> language should instead be extensible that it is possible to add them
> via a library. So in Fortress complex numbers are provided via
> library.

Interesting.

That remark can be considered the most stupid depending on what the
author means by “part of the language�.

To clarify the issue in this thread, what i personaly mean by “wanting
complex number buildin in the lang�, is in the sense that that a user
of the lang can use complex numbers out of the box. In other words,
it's bundled.

Let me give some detail. For example, regex. Perl has the regex as
part of the lang. Python has it as a lib. Namely, you have to “import�
it before you can use it. In Java, as far as i know, it's not present.
These 3 models illustrate the issue. With regard to this discussion, i
consider both perl and python having regex “buildin�, whilejava does
not. (note: java 5 or java 6 might have added regex in the past few
years but i haven't kept up)

Many geekers would go into great length of debate the pros and cons of
perl's part-of-lang regex vs python's regex-as-library. Often terms
like “core�, “primitive�, “native� are also used to debate about
whether some lang has some feature or facility. I think most of these
debates are stupid.

The far more important question is whether certain feature or
facility, is available, “out of the box� with the language.A
language's utility, and popularity, depends on this “out of the box�
nature of feature much more so then some tech geeking concept like
“core�, “native�, “primitive�.

So, i think Java should've had complex numbers out of the box, and
Clojure should have it now. And, if Steele thinks that complex numbers
shouldn't be available out of the box of whatever lang he's designing,
that'd be super stupid.

Xah
∑ http://xahlee.org/

☄

Xah Lee <xahlee> writes:

[...]

> To clarify the issue in this thread, what i personaly mean by “wanting
> complex number buildin in the lang�, is in the sense that that a user
> of the lang can use complex numbers out of the box. In other words,
> it's bundled.

Quite. Whether it fits into an implementation's notion of "language"
or "library" is of no consequence, and might reasonably differ between
implementations.

C++ has complex, and I guess it's usually in a library (or inline in a
header), but it might not be---all the standard says is that if you
have "#include <complex>" then you get to use the std::complex type.

[...]

Xah Lee <xahlee> writes:

Hi,

> Let me give some detail. For example, regex. Perl has the regex as
> part of the lang. Python has it as a lib. Namely, you have to “import�
> it before you can use it. In Java, as far as i know, it's not present.

Java has java.util.regex since 1.4.

Bye,
Tassilo

On Wed, 26 Nov 2008 08:46:37 -0800, Thomas F. Burdick wrote:

> working under the unstated assumption that *useful* complex numbers
> require rationals, which in turn pretty much require bignums to be

I don't agree. Complex numbers do not have to be rational/exact to be
handy - think about a Schur decomposition for instance.

Best,

Tamas

> Indeed. Microsoft did this 7 years ago. Moreover, they did it deliberately
> because they knew languages like F# were on the books.

You say this, as if you were part of that process. Anything to back what
are you saying? Blog quote from one of the creators would be fine...

I always thought .NET simply was made to replace Java more or less, but
I can't say what were the original reasons.

jurgen_defurne wrote:
> That from the tail calls is one of the things that puzzles me the
> most. I mean, the lambda papers date from the mid 70's and a little
> bit later, and in them, Steele and Sussman show how languages can be
> built, and then about 20 years later, Java is created without
> (seemingly) any of the lessons that Steele and Sussman have provided,
> despite Steele also working on Java, together with Gabriel (any other
> people from the 70's/80's Lisp community?).

Indeed. Microsoft did this 7 years ago. Moreover, they did it deliberately
because they knew languages like F# were on the books.

But the thing that really scares me is that Sun were focussing entirely on
hugely inefficient dynamic languages (Groovy etc.), at least before they
suffered a meltdown and fired thousands of people (again).