| Thread overview | ||||||||
|---|---|---|---|---|---|---|---|---|
|
February 25, 2009 Re: Old problem with performance | ||||
|---|---|---|---|---|
| ||||
Daniel Keep Wrote:
> > You probably don't want D, you want ATS: http://www.ats-lang.org/
> >
> > Bye,
> > bearophile
>
> http://www.ats-lang.org/EXAMPLE/MISC/listquicksort.dats
>
> Dear god. I think... I think I'm going to go cry in the corner...
Is it common for functional languages to love 1-letter identifiers, I wonder?
| ||||
February 26, 2009 Re: Old problem with performance | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Kagamin | Kagamin wrote:
> Daniel Keep Wrote:
>
>>> You probably don't want D, you want ATS:
>>> http://www.ats-lang.org/
>>>
>>> Bye,
>>> bearophile
>> http://www.ats-lang.org/EXAMPLE/MISC/listquicksort.dats
>>
>> Dear god. I think... I think I'm going to go cry in the corner...
>
> Is it common for functional languages to love 1-letter identifiers, I wonder?
Probably. Mathematicians use "ab" to mean "a multiplied by b", so they tend toward single-character identifiers with subscripts. And functional languages seem to cater more toward mathematicians.
I tend to find most examples of the remarkable efficiency of functional languages entirely unreadable, partly because of this, and partly because they seem fond of using many operators, some in ways that I find bizarre.
| |||
February 26, 2009 Re: Old problem with performance | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Christopher Wright | == Quote from Christopher Wright (dhasenan@gmail.com)'s article
> Kagamin wrote:
> > Daniel Keep Wrote:
> >
> >>> You probably don't want D, you want ATS: http://www.ats-lang.org/
> >>>
> >>> Bye,
> >>> bearophile
> >> http://www.ats-lang.org/EXAMPLE/MISC/listquicksort.dats
> >>
> >> Dear god. I think... I think I'm going to go cry in the corner...
> >
> > Is it common for functional languages to love 1-letter identifiers, I wonder?
> Probably. Mathematicians use "ab" to mean "a multiplied by b", so they
> tend toward single-character identifiers with subscripts. And functional
> languages seem to cater more toward mathematicians.
> I tend to find most examples of the remarkable efficiency of functional
> languages entirely unreadable, partly because of this, and partly
> because they seem fond of using many operators, some in ways that I find
> bizarre.
<Rant>
True. Conversely, whenever I read something mathy, it always drives me crazy how
hard it is to read something expressed in math notation that is actually quite
intuitive to express in code in a sane language like D (or Python, etc). If
mathematicians applied their unreadable "style" to mainstream code, they'd be shot
because people would believe they were obfuscating it on purpose. Single letter
variable names drive me crazy because when I read equations I constantly lose
track of what the variables represent. Worse yet, when mathematicians run out of
good variable names, they use Greek letters that look almost the same as English
letters, just to make it easier to confuse variable names. When I do math myself,
my programming side kicks in and I often find myself trying to name variables
descriptively like I would if coding, rather than using one letter like a
mathematician.
Similarly, I find linear algebra impossible to grok largely because some genius mathematician decided to overload a bunch of operators to mean completely different things when dealing with matrices than when dealing with scalars. Heck, the multiplication operator isn't even commutative.
Frankly, yes, programming/comp sci may arguably be a branch of mathematics, but if it is, programmers have invented better notation than mathematicians. The mathematicians should stay the heck out of all programming notation discussions. </Rant>
| |||
February 26, 2009 Re: Old problem with performance | ||||
|---|---|---|---|---|
| ||||
Posted in reply to dsimcha | dsimcha <dsimcha@yahoo.com> wrote:
> I find linear algebra impossible to grok largely because some genius
> mathematician decided to overload a bunch of operators to mean completely
> different things when dealing with matrices than when dealing with scalars. Heck, the multiplication operator isn't even commutative.
In the schools I've been to (in Norway), multiplication of scalars
has always been indicated by the middle-dot operator (·, U+00B7), as
has componentwise multiplication of matrices. The multiplication
sign (x, ×, U+00D7) was used for cross-product of vectors, as well
as ordinary matrix multiplication. This has given me the impression
(which seems to hold true in the Norwegian school system) that
middle-dot is commutative, multiplication sign is not. I do however
know it does not hold true in all context, which is unfortunate.
--
Simen
| |||
February 26, 2009 Re: Old problem with performance | ||||
|---|---|---|---|---|
| ||||
Posted in reply to dsimcha | dsimcha wrote: > == Quote from Christopher Wright (dhasenan@gmail.com)'s article >> Kagamin wrote: >>> Daniel Keep Wrote: >>> >>>>> You probably don't want D, you want ATS: >>>>> http://www.ats-lang.org/ >>>>> >>>>> Bye, >>>>> bearophile >>>> http://www.ats-lang.org/EXAMPLE/MISC/listquicksort.dats >>>> >>>> Dear god. I think... I think I'm going to go cry in the corner... >>> Is it common for functional languages to love 1-letter identifiers, I wonder? >> Probably. Mathematicians use "ab" to mean "a multiplied by b", so they >> tend toward single-character identifiers with subscripts. And functional >> languages seem to cater more toward mathematicians. >> I tend to find most examples of the remarkable efficiency of functional >> languages entirely unreadable, partly because of this, and partly >> because they seem fond of using many operators, some in ways that I find >> bizarre. > > <Rant> > True. Conversely, whenever I read something mathy, it always drives me crazy how > hard it is to read something expressed in math notation that is actually quite > intuitive to express in code in a sane language like D (or Python, etc). If > mathematicians applied their unreadable "style" to mainstream code, they'd be shot > because people would believe they were obfuscating it on purpose. Single letter > variable names drive me crazy because when I read equations I constantly lose > track of what the variables represent. Worse yet, when mathematicians run out of > good variable names, they use Greek letters that look almost the same as English > letters, just to make it easier to confuse variable names. When I do math myself, > my programming side kicks in and I often find myself trying to name variables > descriptively like I would if coding, rather than using one letter like a > mathematician. > > Similarly, I find linear algebra impossible to grok largely because some genius > mathematician decided to overload a bunch of operators to mean completely > different things when dealing with matrices than when dealing with scalars. Heck, > the multiplication operator isn't even commutative. > > Frankly, yes, programming/comp sci may arguably be a branch of mathematics, but if > it is, programmers have invented better notation than mathematicians. The > mathematicians should stay the heck out of all programming notation discussions. > </Rant> You're in good company. http://www.cs.utexas.edu/~EWD/ewd13xx/EWD1300.PDF Andrei | |||
February 26, 2009 Re: Old problem with performance | ||||
|---|---|---|---|---|
| ||||
Posted in reply to dsimcha | dsimcha wrote:
> Similarly, I find linear algebra impossible to grok largely because some genius mathematician decided to overload a bunch of operators to mean completely different things when dealing with matrices than when dealing with scalars. Heck, the multiplication operator isn't even commutative.
You’ve got W.R. Hamilton to thank for that last; he found it impossible to extend multiplication past 1- and 2-tuples (real and complex numbers) without dropping commutativity for quaternion multiplication. Give mathematicians a new toy…
Another part of the trouble is that there’s a perfectly good operator
for functional composition, U+2218 RING OPERATOR, i.e.:
[f∘g](x) ≡ f(g(x)).
Treating matrices as linear operators on vectors, you *could* write
[A∘B](v),
but that ignores the fact that matrix “composition” and matrix-vector
“application” have the same form, so we prefer to use the same operator
for both:
ABv ≡ A*B*v.
(The “”, if you can see them, are U+2062 INVISIBLE TIMES.)
I’m playing with Geometric Algebra now, and the problem is *much* worse.
At various times, there are at least 7 different “products” defined:
• AB: the “geometric product”;
• A⋅B: the inner product, defined in two different ways;
• A^B: the outer product, related to the vector cross product;
• A⨼B & A⨽B: the left- and right-contractions, two more “inner products”
(sometimes denoted like A⌋B & A⌊B); and just for extra fun,
• A×B: *not* the familiar cross product, but the “commutator product”
A×B = ½(AB−BA).
(Fortunately, this last is pretty rare in the literature I’ve seen.)
There may also be a defined meaning for A*B, but I can’t recall its meaning.
Lurking on these lists, I’ve seen requests for user-definable infix operators. This example “forms some sort of argument in that debate, but I’m not sure whether it’s for or against.”
—Joel Salomon
| |||
Copyright © 1999-2021 by the D Language Foundation
Permalink
Reply