caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Daniel Andor" <danielandor@gmail.com>
To: Andrej.Bauer@andrej.com
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Operator overloading
Date: Sat, 10 Mar 2007 00:08:16 -0500	[thread overview]
Message-ID: <4d5f7bec0703092108x78de8ca0s2e79451265281b61@mail.gmail.com> (raw)
In-Reply-To: <45F14E4E.6040200@fmf.uni-lj.si>

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]

On 3/9/07, Andrej Bauer <Andrej.Bauer@fmf.uni-lj.si> wrote:
>
> To all who like overloading, I dearly suggest that they explain to
> themselves the following bit of Mathematica:
>
> In[1]:= f[v_] = {{1,0}, {1,1}} . (v + {0,1});
>
> In[2]:= f[{0,0}]
>
> Out[2]= {{0, 0}, {1, 1}}


If you define the function f as most people would expect a function to work,
and the way you would be taught in Mathematica to define a function, and the
way you define 95% of your functions, you get the expected answer:

In[1]:= f[v_] := {{1,0}, {1,1}} . (v + {0,1});

In[2]:= f[{0,0}]

Out[2]= {0, 1}

So I think you are a little disingenuous in your example... ;)

Lots of interesting and sophisticated reasons have been given for the pros
and cons of overloading.  As someone who programs numerical code on a daily
basis, I would just like to make a practical comment:

A reason to appreciate strong typing (and inference that makes it brief) is
that it catches a good number of bugs.  When programming mathematical
algorithms, not having overloading increases the complexity of the code and
hence introduces bugs.  Why?  Most mathematicians I know syntax highlight
with their eyes.  Complexity thwarts this process.  (Until you have a
programming language that checks the algorithm as well as computes it, this
human syntax highlighter is the best (well, only) thing you've got.)

I do occasionally get caught by the kind of error that Andrej mentions.  But
nonetheless I still reach for Mathematica, because algorithmic correctness
(which depends on my interaction with the computer) is at least as important
to me as type safety.

You know, if efficiency didn't matter, then we could all still prove our
programs with pencil and paper and then program it in assembler (or
punchcards).

Can't there be a systematic way of doing this overloading that will not
upset people while allow me (and Jon?) to `see' clearly?  There's got to be
a way!  :)

$0.0314,
Daniel.

[-- Attachment #2: Type: text/html, Size: 2394 bytes --]

  parent reply	other threads:[~2007-03-10  5:08 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-08 20:02 Robert Fischer
2007-03-08 20:15 ` Michael Hicks
2007-03-08 20:50   ` Brian Hurt
2007-03-08 21:05 ` Tom
2007-03-08 21:31   ` Brian Hurt
2007-03-08 22:09     ` Michael Vanier
2007-03-08 22:34     ` Till Varoquaux
2007-03-09 16:02       ` Brian Hurt
2007-03-10  3:23         ` skaller
2007-03-08 22:14   ` Ian Zimmerman
2007-03-09 10:29     ` Jon Harrop
2007-03-09 16:28       ` Ian Zimmerman
2007-03-08 23:51 ` skaller
2007-03-09  7:23   ` Tom
2007-03-09  9:24     ` skaller
2007-03-09  9:32       ` Tom
2007-03-09 10:00         ` skaller
2007-03-09 10:14         ` Jon Harrop
2007-03-09 10:38   ` Jon Harrop
2007-03-09 10:20 ` Jon Harrop
2007-03-09 12:08 ` Andrej Bauer
2007-03-09 12:48   ` Jacques Carette
2007-03-09 13:24   ` Andreas Rossberg
2007-03-10  5:08   ` Daniel Andor [this message]
2007-03-10  5:33     ` David Thomas
  -- strict thread matches above, loose matches on Subject: below --
2007-03-09 16:40 Robert Fischer
2007-03-09 17:25 ` Jon Harrop
2007-03-09  7:36 oleg
2007-03-09 11:09 ` [Caml-list] " skaller
2007-03-09 13:52   ` Andreas Rossberg
2007-03-09 15:07     ` skaller
2007-03-09 16:28       ` Andreas Rossberg
2007-03-10  3:13         ` skaller
2007-03-08 23:20 Robert Fischer
2007-03-09 10:31 ` Jon Harrop
2007-03-08 14:41 [Caml-list] F# Robert Fischer
2007-03-08 17:30 ` Roland Zumkeller
2007-03-08 17:54   ` Brian Hurt
2007-03-08 19:40     ` [Caml-list] Operator overloading Jon Harrop
2007-03-08 20:44       ` Brian Hurt
2007-03-08 22:24       ` Fernando Alegre
2002-04-15 17:05 [Caml-list] operator overloading Issac Trotts
2002-04-14  4:15 Issac Trotts
2002-04-13  8:43 forsyth
2002-04-13  5:26 Issac Trotts
2002-04-13  1:32 Gurr, David (MED, self)
2002-04-12 19:08 Issac Trotts
2002-04-13  8:48 ` William Chesters
2002-04-13 13:58   ` Brian Rogoff
2002-04-13 15:31     ` William Chesters
2002-04-14  3:10       ` Brian Rogoff
2002-04-13  9:00 ` Daniel de Rauglaudre
2002-04-13 21:35 ` Johan Georg Granström
2002-04-14  1:50   ` Jacques Garrigue
2002-04-15 16:22 ` Jun P.FURUSE

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4d5f7bec0703092108x78de8ca0s2e79451265281b61@mail.gmail.com \
    --to=danielandor@gmail.com \
    --cc=Andrej.Bauer@andrej.com \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).