Re: constant `e'

Re: constant `e'

[djh]

From: Jay Belanger <belanger@truman.edu>
>David Hansen <david.hansen@gmx.net> writes:
>> Despite being a maths graduate, I can't think of any other such constants
>> with anything like the universality of e and pi.
>
> 42

>Perhaps we should introduce the constant `math-42'.
>Jay

42 is just the answer as I recall.
I'm not convinced that it needs to have a contant definition.

Darel Henman

Re: constant `e'

[Werner LEMBERG]

> >> Despite being a maths graduate, I can't think of any other such
> >> constants with anything like the universality of e and pi.
> >
> > 42
>
> >Perhaps we should introduce the constant `math-42'.
>
> 42 is just the answer as I recall.
> I'm not convinced that it needs to have a contant definition.

Maybe it's possible that not all people know that this is a joke...

There are high chances that some of the list members haven't read the
`Hitchhiker's guide to the galaxy'.


    Werner

constant `e'

[Drew Adams]

A minor whine - ignore if you don't agree.

Single-character global variables are generally not such a great idea. In
particular, they can easily occur as typographical errors and not be
detected for a while.

The variable `e', defined in `float-sup.el', has been around for a long
time, but I wonder if it wouldn't be better to give it a different name in
Emacs, because of the possibility of `e' occurring as a typo.

[In fact, I wonder if much is gained in speed by defining it as a variable
at all, instead of just using its definition of (exp 1) whenever its value
is needed (or caching the value locally, when appropriate). I also wonder
why `pi' is a defconst but `e' is a defvar.]

`t' is similar, of course, but `t' as a typo is less surprising for anyone
at all used to Lisp. `e' as a numerical constant is not used in most
Emacs-Lisp code, so it is more likely that someone might be surprised by the
effect of an `e' typo (once discovered).

The position of `e' on many keyboards also makes it easy to hit when you
mean to hit a numeral key such as `3', and, unlike `t', the type of `e' is
numeric, so the value mismatch won't always lead to a type mismatch that
might make the error more apparent.

There are many other one-letter physical and mathematical constants.
Fortunately, their names are not used as the names of Emacs constants and
variables. `e' seems to be the exception. Even a two-letter name, such as
`pi', is much, much less error prone than a one-letter name.

Obviously, renaming `e' now would break existing code, but if others agreed,
then we might plan to deprecate `e' over time, in favor of a longer name.

Another possibility would be to change `e' to a function or macro, and
deprecate the variable over time. In that case too I'd prefer a longer name
than one character, but a one-character function or macro name is generally
less error-prone than a variable name. As mentioned above, another approach
(which I prefer, actually) would be to just drop `e' altogether and advise
people to use (exp 1). Anyone needing to use `e' would be likely to know
this definition, in any case.

BTW, this comment in `float-sup.el' is ironic.  It argues, itself, against
the library's defining `e':

 ;; Careful when editing this file ... typos here will be hard to spot.
 ;; (defconst pi       3.14159265358979323846264338327
 ;;  "The value of Pi (3.14159265358979323846264338327...)")

Perhaps that comment dated from some time (?) pre-Emacs 20 when `pi' was
defined using explicit decimal notation, as in the line that follows it, and
perhaps only mistyping numerals was meant, but I find it amusing when
thinking about the possibility of `e' typos. Unfortunately, the effect is
not confined to this library ("typos here") - `e' is a global name, and
`float-sup.el' is preloaded.

The best joke is not that self-referencing comment, but the fun someone
would have trying to find all occurrences of variable `e' in the existing
code, to rename them (and debugging missed or inappropriate renamings).
Undefining it and seeing what happens would be one approach... Obviously not
something to attempt before the release, in any case. ;-)

Re: constant `e'

[Juanma Barranquero]

On 2/9/07, Drew Adams <drew.adams@oracle.com> wrote:

> Obviously, renaming `e' now would break existing code, but if others agreed,
> then we might plan to deprecate `e' over time, in favor of a longer name.

I think that would be a good idea, if anything because the risk of
shadowing `e' with a local (unrelated) binding is quite high, and that
could be a difficult bug to spot.

>  ;; Careful when editing this file ... typos here will be hard to spot.
>  ;; (defconst pi       3.14159265358979323846264338327
>  ;;  "The value of Pi (3.14159265358979323846264338327...)")
>
> Perhaps that comment dated from some time (?) pre-Emacs 20 when `pi' was
> defined using explicit decimal notation

That's the only reasonable explanation. These comments should be deleted.

> Undefining it and seeing what happens would be one approach... Obviously not
> something to attempt before the release, in any case. ;-)

No :)

I find very curious this change by Stefan:

;; It's too inconvenient to make `e' a constant because it's used as
;; a temporary variable all the time.
(defvar e (exp 1) "The value of e (2.7182818...).")

But

  (let ((pi 3.2)) pi) => 3.2

so there's no problem with constants and temporary variables. I think
that must be related to some local patches he mentioned a while ago
for allowing real constants...

Am I right, Stefan, or did I misunderstand this comment in the code?

                    /L/e/k/t/u

Re: constant `e'

[Kim F. Storm]

"Juanma Barranquero" <lekktu@gmail.com> writes:

>>  ;; Careful when editing this file ... typos here will be hard to spot.
>>  ;; (defconst pi       3.14159265358979323846264338327
>>  ;;  "The value of Pi (3.14159265358979323846264338327...)")
>>
>> Perhaps that comment dated from some time (?) pre-Emacs 20 when `pi' was
>> defined using explicit decimal notation
>
> That's the only reasonable explanation. These comments should be deleted.

Done.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: constant `e'

[Stefan Monnier]

> I find very curious this change by Stefan:

> ;; It's too inconvenient to make `e' a constant because it's used as
> ;; a temporary variable all the time.
> (defvar e (exp 1) "The value of e (2.7182818...).")

> But

>  (let ((pi 3.2)) pi) => 3.2

> so there's no problem with constants and temporary variables. I think
> that must be related to some local patches he mentioned a while ago
> for allowing real constants...

> Am I right, Stefan, or did I misunderstand this comment in the code?

Not quite.  I discovered the problem thanks to my local hack that makes
`defconst' into immutable variables, but the reason why I propagated this to
the repository is that even tho the current implementation of `defconst'
does not currently make variables immutable, it is its intention.

In any case I completely agree that `e' should be renamed, maybe to
something like `math-e'.


        Stefan

Re: constant `e'

[Juanma Barranquero]

On 2/9/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I discovered the problem thanks to my local hack that makes
> `defconst' into immutable variables

Aha! :)

> but the reason why I propagated this to
> the repository is that even tho the current implementation of `defconst'
> does not currently make variables immutable, it is its intention.

Curious; I was under the idea that having immutable variables in elisp
was considered unnecessary.

> In any case I completely agree that `e' should be renamed, maybe to
> something like `math-e'.

Yes. I like this one better than exp1.

                    /L/e/k/t/u

Re: constant `e'

[Stefan Monnier]

>> but the reason why I propagated this to the repository is that even tho
>> the current implementation of `defconst' does not currently make
>> variables immutable, it is its intention.

> Curious; I was under the idea that having immutable variables in elisp
> was considered unnecessary.

It's of course not necessary.  Whether it would be good or not is also
debatable.  But the intention of "defconst" is obviously to define
a constant (hence the name), whether or not that it enforced by
the implementation.

>> In any case I completely agree that `e' should be renamed, maybe to
>> something like `math-e'.

> Yes. I like this one better than exp1.

Of course `pi' would want to be renamed similarly.


        Stefan

Re: constant `e'

[Richard Stallman]

math-e might be ok.
Anything longer is too long.

Re: constant `e'

[Jay Belanger]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
...
> In any case I completely agree that `e' should be renamed, maybe to
> something like `math-e'.

While the variables math-e and math-pi are not used, Calc has
functions defined with those names.  (Not that it necessarily
matters.)  Also, Calc uses the "math-" prefix extensively (under the
hood). 

Jay

Re: constant `e'

[Stefan Monnier]

>> In any case I completely agree that `e' should be renamed, maybe to
>> something like `math-e'.

> While the variables math-e and math-pi are not used, Calc has
> functions defined with those names.  (Not that it necessarily
> matters.)  Also, Calc uses the "math-" prefix extensively (under the
> hood).

Well, it was kind of the idea: move these things closer to Calc.


        Stefan


PS: BTW, Eli, when you do trig in Emacs, do you use C-x C-e, M-:, ielm, M-x
calculator, M-x calc, or yet something else?

Re: constant `e'

[Richard Stallman]

I could consider renaming it (later) if someone suggests a good new
name.

Re: constant `e'

[Leo]

On 2007-02-09, Richard Stallman said:

> I could consider renaming it (later) if someone suggests a good new
> name.

MAXIMA is using %e %pi etc. for those constants.

-- 
Leo <sdl.web AT gmail.com>                         (GPG Key: 9283AA3F)

Re: constant `e'

[Kim F. Storm]

Leo <sdl.web@gmail.com> writes:

> On 2007-02-09, Richard Stallman said:
>
>> I could consider renaming it (later) if someone suggests a good new
>> name.
>
> MAXIMA is using %e %pi etc. for those constants.

What about E and PI ?


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

RE: constant `e'

[Drew Adams]

> >> I could consider renaming it (later) if someone suggests a good new
> >> name.
> >
> > MAXIMA is using %e %pi etc. for those constants.
>
> What about E and PI ?

1. Some users sometimes use mixed-case symbols in Lisp. I sometimes do.

2. `E' is still one character. With caps-lock on accidentally, hitting `e'
would have the same effect as now.

What's wrong with reasonale-length names?

RE: constant `e'

[Stuart D. Herring]

>> >> I could consider renaming it (later) if someone suggests a good new
>> >> name.
>> >
>> > MAXIMA is using %e %pi etc. for those constants.
>>
>> What about E and PI ?
>
> 1. Some users sometimes use mixed-case symbols in Lisp. I sometimes do.

`E' and `PI' are not mixed-case, obviously.  And why would you use them? 
They're not reasonable names for temporary variables (like perhaps `e'
is), and they aren't long enough to be a meaningful "type name" or
"package name" or so.  And the naming conventions suggest using a
package-prefix for all but the temporaries anyway.

> 2. `E' is still one character. With caps-lock on accidentally, hitting `e'
> would have the same effect as now.
>
> What's wrong with reasonale-length names?

wITH cAPS lOCK ON, ...yeah.  I think you would notice that.  As well as
get lots of (void-function CAR) errors to tip you off.

There is nothing wrong with names of reasonable length, but there should
be good reasons to lengthen names that are used any more frequently than
`normal-erase-is-backspace-mode' in code.  I'm not saying that the current
names are sacred, but these two reasons in particular are unimportant IMO.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: constant `e'

[Richard Stallman]

    MAXIMA is using %e %pi etc. for those constants.

Maxima is not very directly relevant to Lisp, but it is not out of the
question to use % in those names.

Re: constant `e'

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> I could consider renaming it (later) if someone suggests a good new
> name.

Maybe `exp1'.

-- 
David Kastrup

Re: constant `e'

[Richard Stallman]

    > I could consider renaming it (later) if someone suggests a good new
    > name.

    Maybe `exp1'.

That seems really ugly.

RE: constant `e'

[Drew Adams]

> I could consider renaming it (later) if someone suggests a good new
> name.


`numeric-constant-e', and adopt that (or similar) as the convention for
numeric constants: `numeric-constant-pi', etc.

However, I still prefer, in descending order or preference:

1. (exp 1) ; that is, drop the variable altogether
2. (e); that is, make it a function that does (exp 1) or picks up the
memoized value after doing (exp 1 once).

Re: constant `e'

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 9 Feb 2007 07:33:38 -0800
> Cc: emacs-devel@gnu.org
> 
> `numeric-constant-e', and adopt that (or similar) as the convention for
> numeric constants: `numeric-constant-pi', etc.

Please don't: I frequently use Emacs to calculate trigonometric
expression; typing these monster names would make it very hard for me
to do that.

RE: constant `e'

[Drew Adams]

> > `numeric-constant-e', and adopt that (or similar) as the convention for
> > numeric constants: `numeric-constant-pi', etc.
>
> Please don't: I frequently use Emacs to calculate trigonometric
> expression; typing these monster names would make it very hard for me
> to do that.

Very hard for you? Make a local binding. If you need a short name for
interactive or local program use, define one. I see no reason to dedicate
`e' and `pi' for this uncommon use (uncommon in both Emacs-Lisp files and
interactive Emacs use).

Anyway, I won't argue strongly for renaming `e' or `pi'. But I'm pleased to
see that some people already agree that it's not such a bad idea.

Re: constant `e'

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 9 Feb 2007 08:50:15 -0800
> >
> > Please don't: I frequently use Emacs to calculate trigonometric
> > expression; typing these monster names would make it very hard for me
> > to do that.
> 
> Very hard for you? Make a local binding. If you need a short name for
> interactive or local program use, define one. I see no reason to dedicate
> `e' and `pi' for this uncommon use (uncommon in both Emacs-Lisp files and
> interactive Emacs use).

I don't see this as uncommon: I do most of my work in Emacs, and
having an expression interpreter ready at your fingertip is very handy
when I type math-related text.

Re: constant `e'

[Dieter Wilhelm]

Richard Stallman <rms@gnu.org> writes:

> I could consider renaming it (later) if someone suggests a good new
> name.

I've never seen capital letters in Elisp code.  So wouldn't it be
appropriate to end a convention for "unconventional" Elisp objects and
to finally use an inherent, for my taste, neglected language feature?

e -> E
pi -> Pi

(This is also the traditional form in the Math program Mathematica.)

other approaches not mentioned so far:

pi -> P (Keybinding from Emacs Calc)

e -> ee (borrowed from Mathematica's input form of the complex unit ii
 and  exp[1] as ee)

pi -> pi() (borrowed from MySQL and Excel)
e -> e()

But python uses also the constants e and pi.  

The Math program Matlab uses the constant pi and i but not e (exp[1]).

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: constant `e'

[Richard Stallman]

    e -> ee (borrowed from Mathematica's input form of the complex unit ii
     and  exp[1] as ee)

That might be a good idea.
It doesn't seem unlispy, and it will not be totally unfamiliar,

Re: constant `e'

[Slawomir Nowaczyk]

On Sat, 10 Feb 2007 00:07:24 +0100
Dieter Wilhelm <dieter@duenenhof-wilhelm.de> wrote:

#> But python uses also the constants e and pi.  

except in Python you need:

>>> import math
>>> math.e
2.7182818284590451
>>> math.pi
3.1415926535897931

i.e. "e" and "pi" are not global.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

Isn't vi that text editor with two modes...
 one that beeps and one that corrupts your file?

Re: constant `e'

[Dieter Wilhelm]

Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> writes:

> #> But python uses also the constants e and pi.  
>
> except in Python you need:
>
>>>> import math
>>>> math.e
> 2.7182818284590451
...
> i.e. "e" and "pi" are not global.

Not in general, I did an `import math *'
and then e and pi became global.

    Dieter

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: constant `e'

[Kevin Rodgers]

Richard Stallman wrote:
> I could consider renaming it (later) if someone suggests a good new
> name.

Their names are fine, but perhaps they should be interned in a different
package (as soon as Emacs Lisp provides a structred namespace for 
symbols :-)

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: constant `e'

[Stefan Monnier]

>> I could consider renaming it (later) if someone suggests a good new
>> name.

> Their names are fine, but perhaps they should be interned in a different
> package (as soon as Emacs Lisp provides a structred namespace for
> symbols :-)

The closest we have (and there's no change on the horizon, AFAIK) is
prefixes, which is why I suggested "math-e".


        Stefan

Re: constant `e'

[Lennart Borgman (gmail)]

Stefan Monnier wrote:

>> Their names are fine, but perhaps they should be interned in a different
>> package (as soon as Emacs Lisp provides a structred namespace for
>> symbols :-)
> 
> The closest we have (and there's no change on the horizon, AFAIK) is
> prefixes, which is why I suggested "math-e".


math-e is short and understandable, fits well with a maybe-future 
structured namespace. No one has suggested a shorter name (expect for e 
of course ...). Those who want can easily define e themselves.

I see no reason not to change e to math-e. Except that it may be rather 
hard to find and replace the current uses of e ... ;-)

Re: constant `e'

[Stefan Monnier]

> I see no reason not to change e to math-e.  Except that it may be rather
> hard to find and replace the current uses of e ... ;-)

Shouldn't be that hard: remove it, recompile, and look for messages about use
of undeclared variable "e".


        Stefan

Re: constant `e'

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>> I see no reason not to change e to math-e.  Except that it may be rather
>> hard to find and replace the current uses of e ... ;-)
> 
> Shouldn't be that hard: remove it, recompile, and look for messages about use
> of undeclared variable "e".

Ah, thanks. I seldom byte-compile my elisp files and did not realize it 
was that easy.

Re: constant `e'

[Kevin Rodgers]

Lennart Borgman (gmail) wrote:
> Stefan Monnier wrote:
>>> I see no reason not to change e to math-e.  Except that it may be rather
>>> hard to find and replace the current uses of e ... ;-)
>>
>> Shouldn't be that hard: remove it, recompile, and look for messages 
>> about use
>> of undeclared variable "e".
> 
> Ah, thanks. I seldom byte-compile my elisp files and did not realize it 
> was that easy.

I always byte-compile my .el files: it dramatically improves performance
and it often reveals invalid assumptions in the code.

-- 
Kevin Rodgers
Denver, Colorado, USA

RE: constant `e'

[Drew Adams]

> I always byte-compile my .el files: it dramatically improves performance
> and it often reveals invalid assumptions in the code.

Amen, especially to the last part. And for code that should work in
different Emacs versions, I byte-compile in the different versions.

Re: constant `e'

[Daniel Brockman]

`natural-logarithm-base'

`circle-circumference-diameter-ratio'

`canonical-true-value'

Seriously, though, I'd really like to see an `otherwise'
constant (defined to `t', of course).  That would make
catch-all clauses of `cond' look much better.

Please?

-- 
Daniel Brockman <daniel@brockman.se>

Re: constant `e'

[David Kastrup]

Daniel Brockman <daniel@brockman.se> writes:

> `natural-logarithm-base'
>
> `circle-circumference-diameter-ratio'
>
> `canonical-true-value'
>
> Seriously, though, I'd really like to see an `otherwise'
> constant (defined to `t', of course).  That would make
> catch-all clauses of `cond' look much better.

Disagree, that's an idiom.  Anyway, you can do

(cond ((eq x 'yellow) "yellow")
      ((eq x 'green) "green")
      ("other"))

and avoid the t altogether.  Not that it is prettier to my eyes.

> Please?

There is no point in Elisp diverging from Lisp without more compelling
reasons.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: constant `e'

[Daniel Brockman]

David Kastrup <dak@gnu.org> writes:

> Daniel Brockman <daniel@brockman.se> writes:
>
>> Seriously, though, I'd really like to see an `otherwise'
>> constant (defined to `t', of course).  That would make
>> catch-all clauses of `cond' look much better.
>
> Disagree, that's an idiom.

Of course it's an idiom.  That doesn't mean it looks good.
I, as a speaker of Emacs Lisp, would prefer not to use this
idiom if `otherwise' became an accepted alternative.

Why?  Because I simply think this looks ugly:

  (cond ((not (null n))
         (bongo-mark-line-forward (prefix-numeric-value n)))
        ((bongo-region-active-p)
         (bongo-mark-region (region-beginning) (region-end)))
        (t
         (bongo-mark-line-forward)))

It looks as if the last arm is about to break and fall off.
I think this looks better:

  (cond ((not (null n))
         (bongo-mark-line-forward (prefix-numeric-value n)))
        ((bongo-region-active-p)
         (bongo-mark-region (region-beginning) (region-end)))
        (otherwise
         (bongo-mark-line-forward)))

Incidentally, I also think `(not (null n))' looks better
than `n' --- as do, I believe, most Emacs Lisp programmers.
Take a look at this code:

  (cond (n
         (bongo-mark-line-forward (prefix-numeric-value n)))
        ((bongo-region-active-p)
         (bongo-mark-region (region-beginning) (region-end)))
        (t
         (bongo-mark-line-forward)))

It's ugly, isn't it?  It's not just that `(not (null n))' is
semantically clearer than a lone `n'; it's also more beautiful.

> Anyway, you can do
>
> (cond ((eq x 'yellow) "yellow")
>       ((eq x 'green) "green")
>       ("other"))
>
> and avoid the t altogether.  Not that it is prettier to
> my eyes.

Interesting.  I think I'll try that for a while.

  (cond ((not (null n))
         (bongo-mark-line-forward (prefix-numeric-value n)))
        ((bongo-region-active-p)
         (bongo-mark-region (region-beginning) (region-end)))
        ((bongo-mark-line-forward)))

It looks a little weird, but maybe I'll get used to it.
It certainly is prettier to my eyes.  Thanks.

>> Please?
>
> There is no point in Elisp diverging from Lisp without
> more compelling reasons.

The `case' macro already allows `otherwise'.  That's a
pretty compelling reason to allow it in `cond' as well.
(Yes, I know `case' is in the `cl' library, but lots of
people use that library --- at least its macros.)

-- 
Daniel Brockman <daniel@brockman.se>

Re: constant `e'

[David Kastrup]

Daniel Brockman <daniel@brockman.se> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Daniel Brockman <daniel@brockman.se> writes:
>>
>>> Seriously, though, I'd really like to see an `otherwise'
>>> constant (defined to `t', of course).  That would make
>>> catch-all clauses of `cond' look much better.
>>
>> Disagree, that's an idiom.
>
> Of course it's an idiom.  That doesn't mean it looks good.

Lisp is not designed to look good.

> I, as a speaker of Emacs Lisp, would prefer not to use this idiom if
> `otherwise' became an accepted alternative.

It didn't.  Try getting it into Common Lisp first.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: constant `e'

[Daniel Brockman]

David Kastrup <dak@gnu.org> writes:

>> Of course it's an idiom.  That doesn't mean it looks good.
>
> Lisp is not designed to look good.

That doesn't mean it looks bad.  S-expressions won.
They weren't meant to be beautiful, but they are.

Apparently you are saying Lisp is so ugly that there is no
point in attempting to make it look nicer.  Is that right?

Then explain why we have aliases such as `not'.

>> I, as a speaker of Emacs Lisp, would prefer not to use
>> this idiom if `otherwise' became an accepted alternative.
>
> It didn't.  Try getting it into Common Lisp first.

It's already there, and I already mentioned it (`case').

Scheme has `else'.  Dylan has `otherwise'.  Those are both
modern lisps in which this has become an accepted alternative.

I'm not going to try to get `otherwise' into CL's `cond',
simply because I don't use CL and I don't care about it.
(Even if I did, I wouldn't hope to be able to change it.)

-- 
Daniel Brockman <daniel@brockman.se>

Re: constant `e'

[Alan Mackenzie]

Hi, Daniel

On Sat, Feb 10, 2007 at 12:35:30PM +0100, Daniel Brockman wrote:

[ .... ]

> Incidentally, I also think `(not (null n))' looks better than `n' ---
> as do, I believe, most Emacs Lisp programmers.

I disagree with you on both counts.  When I see `(not (null n))', it
takes extra effort mentally to filter out what, to me, is just noise.

> Take a look at this code:

>   (cond (n
>          (bongo-mark-line-forward (prefix-numeric-value n)))
>         ((bongo-region-active-p)
>          (bongo-mark-region (region-beginning) (region-end)))
>         (t
>          (bongo-mark-line-forward)))

> It's ugly, isn't it?  It's not just that `(not (null n))' is
> semantically clearer than a lone `n'; it's also more beautiful.

It's more alliterative, perhaps.  But it feels like I'm being talked down
to - the programmer is saying, in effect "you probably don't understand
Lisp very well, so I'll make it very very clear".

[ .... ]

> -- 
> Daniel Brockman <daniel@brockman.se>

-- 
Alan Mackenzie (Ittersbach, Germany).

Re: constant `e'

[Daniel Brockman]

Alan Mackenzie <acm@muc.de> writes:

>> Incidentally, I also think `(not (null n))' looks better than `n' ---
>> as do, I believe, most Emacs Lisp programmers.
>
> I disagree with you on both counts.  When I see `(not (null n))', it
> takes extra effort mentally to filter out what, to me, is just noise.

Hm!  That's interesting.

The concept of `non-nil' is very basic to me, so I do not
have to filter anything out of `(not (null ...))', because
it is already phrased the way I think about it.

>> Take a look at this code:
>
>>   (cond (n
>>          (bongo-mark-line-forward (prefix-numeric-value n)))
>>         ((bongo-region-active-p)
>>          (bongo-mark-region (region-beginning) (region-end)))
>>         (t
>>          (bongo-mark-line-forward)))
>
>> It's ugly, isn't it?  It's not just that `(not (null n))' is
>> semantically clearer than a lone `n'; it's also more beautiful.
>
> It's more alliterative, perhaps.  But it feels like I'm being talked
> down to - the programmer is saying, in effect "you probably don't
> understand Lisp very well, so I'll make it very very clear".

I had no idea some people read it like that.

Do you feel similarily talked down to when you see C code
like the following?

   for (node = list->first; node != NULL; node = node->next)
     process (node);

-- 
Daniel Brockman <daniel@brockman.se>

Re: constant `e'

[Alan Mackenzie]

Hi, Daniel!

On Sat, Feb 10, 2007 at 03:33:54PM +0100, Daniel Brockman wrote:
> Alan Mackenzie <acm@muc.de> writes:

[ .... ]

> > When I see `(not (null n))', it takes extra effort mentally to filter
> > out what, to me, is just noise.

> Hm!  That's interesting.

It's amazing how differently different hackers see things, even here on
emacs-devel.

> The concept of `non-nil' is very basic to me, so I do not have to
> filter anything out of `(not (null ...))', because it is already
> phrased the way I think about it.

The concept of `non-nil' is so basic to me that I don't see any need to
express it explicitly.  ;-)  

> >> Take a look at this code:

[ .... ]

> > But it feels like I'm being talked down to - the programmer is
> > saying, in effect "you probably don't understand Lisp very well, so
> > I'll make it very very clear".

> I had no idea some people read it like that.

> Do you feel similarily talked down to when you see C code
> like the following?

>    for (node = list->first; node != NULL; node = node->next)
>      process (node);

A little, but not that much.  What gets my goat up is when natural
idiomatic C, something like this:

    while (i--)
       <statement>

has to be recoded, at the behest of company "coding standards", like
this:

    while (CurrentFooIndex > 0)
    {
        CurrentFooIndex-- ;
	<statement>
    }

, supposedly to make it "more readable" and "more maintainable".  Such
coding standards give remarkably little justification for their rules.
They are pretty much always ignored anyway, so they don't do too much
harm.  [By contrast, the GNU coding rules are pretty sensible, if not to
everybody's taste.]

However, I rarely change anything "long-winded" in anybody else's code.
It creates bad feeling for no objective benefit.

> -- 
> Daniel Brockman <daniel@brockman.se>

-- 
Alan Mackenzie (Ittersbach, Germany).

Re: constant `e'

[Daniel Brockman]

Alan,

>> The concept of `non-nil' is very basic to me, so I do not have to
>> filter anything out of `(not (null ...))', because it is already
>> phrased the way I think about it.
>
> The concept of `non-nil' is so basic to me that I don't
> see any need to express it explicitly.  ;-)

That might actually be it. :-)

> What gets my goat up is when natural idiomatic C,
> something like this:
>
>     while (i--)
>        <statement>
>
> has to be recoded [...]

Yes, I agree.  That is completely stupid --- I think
the idiomatic style both looks better and is clearer.

> However, I rarely change anything "long-winded" in anybody else's code.
> It creates bad feeling for no objective benefit.

So maybe it's a good thing we don't have `otherwise'.
Having just one standard way avoids that bad feeling.

-- 
Daniel Brockman <daniel@brockman.se>

Re: constant `e'

[Stuart D. Herring]

> Hm!  That's interesting.
>
> The concept of `non-nil' is very basic to me, so I do not
> have to filter anything out of `(not (null ...))', because
> it is already phrased the way I think about it.

I have addressed this point more extensively in another mail, but let me
add in response to this particular sentence that the concept of `non-nil'
is so very basic to me that I do not need to see `(not (null ...))' to
know that it is applied by such forms as `cond'.

> I had no idea some people read it like that.
>
> Do you feel similarily talked down to when you see C code
> like the following?
>
>    for (node = list->first; node != NULL; node = node->next)
>      process (node);

I don't feel talked-down-to as much as I feel inconvenienced by (if you'll
pardon the exaggeration) the ineffective prose of a novice.  The use of
NULL when even the compiler merely sees 0 in its stead serves no purpose
in terms of type-safety, and after resolving that mentally I also waste
more time noting that `!=0' does not affect the conditional value of an
integer or pointer.

Although it would be clumsy here, I would even recommend, since the loop
is so simple, that a trivial loop over argv be written as

for(ptr=argv;*ptr;process(*ptr++));

Some would say that this is appropriate only for the IOCCC, but I tend to
consider it actually clearer: the use of the construct *ptr++ can only
have the meaning of "use and advance past an element", and the test *ptr
can only mean "this is a null-terminated array".  So, without any further
contemplation, I can assume that this must be a loop to process -- once --
each element of a null-terminated array.

If it is really so cryptic, adding /* process() each argument */ will
alleviate any confusion without, as more verbose code might, causing
anyone who "got it" the first time to have to doubt themselves and
re-read.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: constant `e'

[Daniel Brockman]

"Stuart D. Herring" <herring@lanl.gov> writes:

>> Hm!  That's interesting.
>>
>> The concept of `non-nil' is very basic to me, so I do not
>> have to filter anything out of `(not (null ...))', because
>> it is already phrased the way I think about it.
>
> I have addressed this point more extensively in another mail, but let me
> add in response to this particular sentence that the concept of `non-nil'
> is so very basic to me that I do not need to see `(not (null ...))' to
> know that it is applied by such forms as `cond'.

fine

i really don't need to see most punctuation or
capitalization to understand english sentences

the thing is that i _want_ to see it because i think it
makes the prose look better

it's like

i know there should be a question mark after this sentence,
so why not add one

it won't be distacting because not only am i used to seing
question marks --- i add missing ones mentally when i read

>> I had no idea some people read it like that.
>>
>> Do you feel similarily talked down to when you see C code
>> like the following?
>>
>>    for (node = list->first; node != NULL; node = node->next)
>>      process (node);
>
> I don't feel talked-down-to as much as I feel inconvenienced by (if you'll
> pardon the exaggeration) the ineffective prose of a novice.

I compared `!= NULL' and `(not (null ...))' to punctuation.
I guess, in a way, punctuation makes prose "ineffective".

> The use of NULL when even the compiler merely sees 0 in
> its stead serves no purpose in terms of type-safety,

I never claimed it did.

> and after resolving that mentally I also waste more time
> noting that `!=0' does not affect the conditional value of
> an integer or pointer.

That's ridiculous.  If you have to spend many brain cycles
figuring out what `node != NULL' means, I would hesitate to
say that you are fluent in common idiomatic C.

It's sort of comparable to stopping every time you see the
word `but' and noting that, in fact, it just means `and'.

> Although it would be clumsy here, I would even recommend, since the loop
> is so simple, that a trivial loop over argv be written as
>
> for(ptr=argv;*ptr;process(*ptr++));

Well, I guess we'll just have to agree to disagree,
because I think that's very hard to read.

I would write it as follows:

   for (current = argv; *current != NULL; ++current)
     process (*current);

Maybe we just speak different dialects of C or something.

I speak "verbose" and you speak "cryptic". :-)

-- 
Daniel Brockman <daniel@brockman.se>

Re: constant `e'

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Hi, Daniel
>
> On Sat, Feb 10, 2007 at 12:35:30PM +0100, Daniel Brockman wrote:
>
> [ .... ]
>
>> Incidentally, I also think `(not (null n))' looks better than `n' ---
>> as do, I believe, most Emacs Lisp programmers.
>
> I disagree with you on both counts.  When I see `(not (null n))', it
> takes extra effort mentally to filter out what, to me, is just
> noise.

Agreed.

>> Take a look at this code:
>
>>   (cond (n
>>          (bongo-mark-line-forward (prefix-numeric-value n)))
>>         ((bongo-region-active-p)
>>          (bongo-mark-region (region-beginning) (region-end)))
>>         (t
>>          (bongo-mark-line-forward)))
>
>> It's ugly, isn't it?  It's not just that `(not (null n))' is
>> semantically clearer than a lone `n'; it's also more beautiful.

Uh what?  You want meaningless clutter for lining things up?  Then
write

   (cond (n ;;;;;;;;;;;;;;;;;;;;
          (bongo-mark-line-forward (prefix-numeric-value n)))
         ((bongo-region-active-p)
          (bongo-mark-region (region-beginning) (region-end)))
         (t ;;;;;;;;;;;;;;;;;;;;
          (bongo-mark-line-forward)))


> It's more alliterative, perhaps.  But it feels like I'm being talked
> down to - the programmer is saying, in effect "you probably don't
> understand Lisp very well, so I'll make it very very clear".

Disagree.  That is not at all clearer.  It is merely occupying a
different amount of space.

Rather than "I'll make it very very clear", it is "I'll try to give
you a nice wallpaper that won't startle you out of your sleep".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: constant `e'

[Daniel Brockman]

David Kastrup <dak@gnu.org> writes:

> Disagree.  That is not at all clearer.  It is merely
> occupying a different amount of space.

Yes, I admit that much.  The `t' vs `otherwise' thing is as
simple as the latter occupying more space than the former ---
and, I guess, being a real word.

So, I guess that shows how superficial I am.  I can't deny it.

> Rather than "I'll make it very very clear", it is "I'll try to give
> you a nice wallpaper that won't startle you out of your sleep".

Haha!

Anyway, I'm sorry I brought this up.  I know now is the
worst time for making crazy suggestions like this.

If I had a tail, I'd walk off with it between my legs.

Please carry on with the release.

-- 
Daniel Brockman <daniel@brockman.se>

Re: constant `e'

[Stuart D. Herring]

>>> Incidentally, I also think `(not (null n))' looks better than `n' ---
>>> as do, I believe, most Emacs Lisp programmers.
>>
>> I disagree with you on both counts.  When I see `(not (null n))', it
>> takes extra effort mentally to filter out what, to me, is just
>> noise.
>
> Agreed.

More than agreement from me: if I see `(not (null n))' I immediately want
to know what weird magic is going on that caused the author to need to add
the extra function calls.  I feel there must be something I don't
understand about the code if the obvious approach was avoided.

After all, would I be wrong in supposing that it is of some extraneous
difficulty for you to understand (after reading) a sentence of words
chosen in what is really a manner with excessive verbosity constructed
without regard or consideration for either of brevity or the avoidance of
redundant descriptions and clarifications?

(Of course 'you' are understanding; of course "after reading", of course
it's "of words"; why "regard" and "consideration", why "brevity" and
"redundancy", why "descriptions" and "clarifications"?  Why not "Isn't it
harder to understand wordy, redundant sentences?")  It's not just because
there are many words to parse, but because they by their number and
specificity suggest a complexity of meaning that simply isn't there.

>>> Take a look at this code:
>>
>>>   (cond (n
>>>          (bongo-mark-line-forward (prefix-numeric-value n)))
>>>         ((bongo-region-active-p)
>>>          (bongo-mark-region (region-beginning) (region-end)))
>>>         (t
>>>          (bongo-mark-line-forward)))
>>
>>> It's ugly, isn't it?  It's not just that `(not (null n))' is
>>> semantically clearer than a lone `n'; it's also more beautiful.

All sorts of operations discard some of the information given them, such
that the importance of that information is some subset of its normal
meaning.  Here, n is simplified to "nil or not nil", and you (Daniel) are
suggesting that we should explicitly strip it down to that information
before using it.

If I were to write (< i 256), which discards i's lowest byte entirely,
would you suggest that I write (zerop (lsh i -8)) just to make absolutely
certain that I understood that I was discarding those bits?  (And in so
doing risk the sort of bug that has arisen here for negative i?)

>> It's more alliterative, perhaps.  But it feels like I'm being talked
>> down to - the programmer is saying, in effect "you probably don't
>> understand Lisp very well, so I'll make it very very clear".
>
> Disagree.  That is not at all clearer.  It is merely occupying a
> different amount of space.
>
> Rather than "I'll make it very very clear", it is "I'll try to give
> you a nice wallpaper that won't startle you out of your sleep".

That may be true, but it also has an effect on the wakeful: it destroys
the distinction that one of the conditions is a variable test, another is
a function call, and the third is a special case.  The visual information
about the differences in complexity between the different branches is
actually quite valuable; if I want contextual hints as to how to interpret
them, I need only look at the `cond' word, which in my Emacs is nicely
highlighted in (a low-key, non-bold) red to put beyond trivial determining
the importance of the clauses.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: constant `e'

[Stefan Monnier]

> Incidentally, I also think `(not (null n))' looks better than `n'

Please, it's not the same thing: (not (null 2)) != 2
Code is a way to communicate, so if you write (not (null N)) instead of N,
the reader will have to wonder:
- is this a beginner who doesn't realize who could/should have just used N?
- or is it an experienced programmer who just wants to tell me something
  about his intention?
- or is it really that the code needs the value converted to a nil/t "boolean"?
Also, the compiler will have to work extra hard to try and figure out
whether it is safe to optimize it away or not.  If it's more work for the
compiler, it's probably more work for the human reader as well.


        Stefan

Re: constant `e'

[Daniel Brockman]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Incidentally, I also think `(not (null n))' looks better than `n'
>
> Please, it's not the same thing: (not (null 2)) != 2

But this is exactly why `(not (null n))' is clearer:
It makes it immediately clear that the value of `n' is
not used for anything (other than testing for nil).

> Code is a way to communicate, so if you write (not (null N)) instead of N,
> the reader will have to wonder:
> - is this a beginner who doesn't realize who could/should have just used N?
> - or is it an experienced programmer who just wants to tell me something
>   about his intention?
> - or is it really that the code needs the value converted
>   to a nil/t "boolean"?

One can ask many interesting questions about the author of a
piece of code.  Other examples include,

 - Did a lazy programmer who couldn't be bothered to put
   `(not (null ...))' around this expression write this?

 - Was it an experienced programmer who left it out on
   purpose because the value is really used in some way?

 - Is is probable that the author likes coffee?

Another thing one can do with code is to forget about the
author for a minute and focus on reading the code instead.

Reading `(not (null n))', its meaning is obvious ---
for crying out loud, it's almost an English phrase.

> Also, the compiler will have to work extra hard to try and figure out
> whether it is safe to optimize it away or not.  If it's more work for the
> compiler, it's probably more work for the human reader as well.

I doubt the valitidy of that.  The purpose of high-level
languages is to make code easier for humans to read at the
expense of making it harder for computers to execute.
This seems to fundamentally contradict your statement.

-- 
Daniel Brockman <daniel@brockman.se>

Re: constant `e'

[Stefan Monnier]

>> Also, the compiler will have to work extra hard to try and figure out
>> whether it is safe to optimize it away or not.  If it's more work for the
>> compiler, it's probably more work for the human reader as well.

> I doubt the valitidy of that.  The purpose of high-level
> languages is to make code easier for humans to read at the
> expense of making it harder for computers to execute.
> This seems to fundamentally contradict your statement.

Being difficult to execute is very different from being difficult to
understand.  I wrote "more work for the compiler", in a paragraph that talks
about optimizing, so I was referring to the effort needed to "understand"
rather than "execute" a piece of code.

Note that the higher-level languages are always more constraining than
lower-level ones (try to write GC in elisp, for example).  Those constraints
make it easier for people and compilers to understand what the code does,
because they can assume they hold without having to check.


        Stefan

Re: constant `e'

[David Kastrup]

Daniel Brockman <daniel@brockman.se> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> Incidentally, I also think `(not (null n))' looks better than `n'
>>
>> Please, it's not the same thing: (not (null 2)) != 2
>
> But this is exactly why `(not (null n))' is clearer:
> It makes it immediately clear that the value of `n' is
> not used for anything (other than testing for nil).

Instead of wasting everybody's time on this list for minor cosmetics,
how about exerting your energy for language aesthetics on the
lexical-bind branch?  That is actually something which _does_ affect
code cleanliness.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: constant `e'

[Daniel Brockman]

David Kastrup <dak@gnu.org> writes:

> Instead of wasting everybody's time on this list for minor
> cosmetics, how about exerting your energy for language
> aesthetics on the lexical-bind branch?  That is actually
> something which _does_ affect code cleanliness.

I didn't know such a thing existed, but I will check it out.
Thanks for the tip.

I apologize again for mentioning `otherwise'.  I shouldn't
have started this thread, and especially not right now.

I guess I got carried away when trying to come up with silly
names for `e', `pi' and `t'.  It's all Drew Adams's fault.

-- 
Daniel Brockman <daniel@brockman.se>

Re: constant `e'

[Edward O'Connor]

Daniel Brockman wrote:

> Incidentally, I also think `(not (null n))' looks better
> than `n' --- as do, I believe, most Emacs Lisp programmers.

I think you mean Scheme programmers...

    So I went back to the master and appealed once again
    I said, pardon me, but now I'm really insane
    He said, no you're not really going out of your head
    Instead of just VAL, you must use NOT NULL instead

>From "A Short Ballad Dedicated to the Growth of Programs" by Ashwin
Ram, which you can find here:

             http://www.lisp.org/humor/large-programs.html

-- 
Edward O'Connor
hober0@gmail.com

Ense petit placidam sub libertate quietem.

Re: constant `e'

[Stuart D. Herring]

> The `case' macro already allows `otherwise'.  That's a
> pretty compelling reason to allow it in `cond' as well.
> (Yes, I know `case' is in the `cl' library, but lots of
> people use that library --- at least its macros.)

The `case' macro allows it because t is already a special case there (case
clauses are not conditions), and so giving it an unusual name reduces the
surprise.  In `cond', each clause by definition begins with an expression
evaluated as a condition.  Any problems whatsoever in immediately and
fully understanding the function of t in such a circumstance are so
fundamental that they -should- be called out by the syntax and addressed
rather than allowed to continue by an English-like special case.  (Imagine
what would happen if someone, perhaps to shush the byte-compiler, set
`otherwise' to nil, and how much worse if the person debugging thought
that `case' treated that symbol specially!)

I am sure that not everyone agrees with my thoughts on the matter, and
that there are good arguments against them, but it is my general
contention that programmers would do well spending more time learning
their languages and tools and less time divising clever tricks in an
attempt to make such learning unnecessary for others.  The tricks
typically succeed in preventing the learning but not in transcending it.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: constant `e'

[Daniel Brockman]

"Stuart D. Herring" <herring@lanl.gov> writes:

>> The `case' macro already allows `otherwise'.  That's a
>> pretty compelling reason to allow it in `cond' as well.
>> (Yes, I know `case' is in the `cl' library, but lots of
>> people use that library --- at least its macros.)
>
> The `case' macro allows it because t is already a special case there (case
> clauses are not conditions), and so giving it an unusual name reduces the
> surprise.  In `cond', each clause by definition begins with an expression
> evaluated as a condition.  Any problems whatsoever in immediately and
> fully understanding the function of t in such a circumstance are so
> fundamental that they -should- be called out by the syntax and addressed
> rather than allowed to continue by an English-like special case.

That is a straw man.  Nobody is confused about what `t'
means in a `cond' clause and nobody would be if `otherwise'
were introduced.  Come on, this is basic stuff.

> (Imagine what would happen if someone, perhaps to shush
> the byte-compiler, set `otherwise' to nil, and how much
> worse if the person debugging thought that `case' treated
> that symbol specially!)

Yes, wouldn't that be a crazy idea!

Now imagine what would happen if 1 + 5 were equal to 12.
That's right.  Mixing juice would get you twice as much.

There's no reason why `otherwise' couldn't be a special case
in the `cond' macro, as it is in `case'.

> I am sure that not everyone agrees with my thoughts on the matter, and
> that there are good arguments against them, but it is my general
> contention that programmers would do well spending more time learning
> their languages and tools and less time divising clever tricks in an
> attempt to make such learning unnecessary for others.  The tricks
> typically succeed in preventing the learning but not in transcending it.

I don't aim to make learning unnecessary for others.

The simple and embarrasing truth is that I think `otherwise'
looks pretty.  It makes me feel warm and fuzzy inside.

Everyone else disagrees.  I shut up.  End of thread.

-- 
Daniel Brockman <daniel@brockman.se>

Re: constant `e'

[David Kastrup]

Daniel Brockman <daniel@brockman.se> writes:

[...]

Could you please take this elsewhere?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: constant `e'

[Richard Stallman]

    Seriously, though, I'd really like to see an `otherwise'
    constant (defined to `t', of course).  That would make
    catch-all clauses of `cond' look much better.

We won't do this, so please let's not spend time discussing it.

Re: constant `e'

[Alan Mackenzie]

Hi, Drew!

On Thu, Feb 08, 2007 at 11:37:36PM -0800, Drew Adams wrote:
> A minor whine - ignore if you don't agree.

No such luck!

> Single-character global variables are generally not such a great idea.
> In particular, they can easily occur as typographical errors and not be
> detected for a while.

Has this happened to you?

> The variable `e', defined in `float-sup.el', has been around for a long
> time, but I wonder if it wouldn't be better to give it a different name
> in Emacs, because of the possibility of `e' occurring as a typo.

e has been around for several hundred years.  It is known by that name
universally in European language cultures.  Anybody who understands its
concept instantly recognises its one-letter name, just as any hacker
recognises the name C.  Has e ever been known to mathematicians by any
other name?  So no, in my humble opinion, it would not be a good idea to
give it a new name.

> `t' is similar, of course, but `t' as a typo is less surprising for
> anyone at all used to Lisp. `e' as a numerical constant is not used in
> most Emacs-Lisp code, so it is more likely that someone might be
> surprised by the effect of an `e' typo (once discovered).

If e were to be renamed, how would anybody find out it exists?  Who would
remember the new name?

> The position of `e' on many keyboards also makes it easy to hit when
> you mean to hit a numeral key such as `3', and, unlike `t', the type of
> `e' is numeric, so the value mismatch won't always lead to a type
> mismatch that might make the error more apparent.

Come on, Drew - post the error you made or came across, please!

> There are many other one-letter physical and mathematical constants.
> Fortunately, their names are not used as the names of Emacs constants
> and variables. `e' seems to be the exception. Even a two-letter name,
> such as `pi', is much, much less error prone than a one-letter name.

Despite being a maths graduate, I can't think of any other such constants
with anything like the universality of e and pi.

[ .... ]

> The best joke is not that self-referencing comment, but the fun someone
> would have trying to find all occurrences of variable `e' in the
> existing code, ....

Something like
"^\([^e;\]\|\\.\|[a-zA-Z_-]e\|e[a-zA-Z_-]\)*e\([^a-zA-Z_-]\|$\)"
(fully untested), would find them easily enough.

> .... to rename them (and debugging missed or inappropriate renamings).
> Undefining it and seeing what happens would be one approach...
> Obviously not something to attempt before the release, in any case. ;-)

I don't think there would be that many to find.

-- 
Alan Mackenzie (Ittersbach, Germany)

Re: constant `e'

[Jason Rumney]

Alan Mackenzie wrote:
>
> Despite being a maths graduate, I can't think of any other such constants
> with anything like the universality of e and pi.
>   
c. I don't think we have that defined in Emacs though, maybe physicists 
don't use Emacs for calculations as much as mathematicians.

Re: constant `e'

[Stuart D. Herring]

>> Despite being a maths graduate, I can't think of any other such
>> constants
>> with anything like the universality of e and pi.
>>
> c. I don't think we have that defined in Emacs though, maybe physicists
> don't use Emacs for calculations as much as mathematicians.

Or maybe they use geometrized units
(http://en.wikipedia.org/wiki/Geometrized_units).  The universality,
expected precision (a 2% error in c or in Boltzmann's constant is
typically not much of an issue), and unique values (being independent of
units) of e and pi are the reason for their inclusion.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: constant `e'

[Juanma Barranquero]

On 10 Feb 2007 10:02:38 +0100, Alan Mackenzie <acm@muc.de> wrote:

> Has e ever been known to mathematicians by any other name?

Yes. "b" and "c".

http://en.wikipedia.org/wiki/E_%28mathematical_constant%29#History

                    /L/e/k/t/u

Re: constant `e'

[Stefan Monnier]

> recognises the name C.  Has e ever been known to mathematicians by any
> other name?  So no, in my humble opinion, it would not be a good idea to

That's the wrong question.  Within a "math" package/module/namespace, yes,
you're probably right.  But the question is "should the symbol e be globally
associated with the 2.718... numerical constant, even in contexts that have
nothing whatsoever to do with mathematics?"

I can't remember the last time that I've used the 2.718... constant, but
I do use "e" many times a day to refer to an "expression" (and "t" or "τ"
for a type, incidentally).


        Stefan

Re: constant `e'

[David Hansen]

On 10 Feb 2007 10:02:38 +0100 Alan Mackenzie wrote:

> Despite being a maths graduate, I can't think of any other such constants
> with anything like the universality of e and pi.

42

David

Re: constant `e'

[Jay Belanger]

David Hansen <david.hansen@gmx.net> writes:

> On 10 Feb 2007 10:02:38 +0100 Alan Mackenzie wrote:
>
>> Despite being a maths graduate, I can't think of any other such constants
>> with anything like the universality of e and pi.
>
> 42

Perhaps we should introduce the constant `math-42'.

Jay

RE: constant `e'

[Drew Adams]

To `e' or not to `e', that is the question.

> > The variable `e', defined in `float-sup.el', has been around for a long
> > time, but I wonder if it wouldn't be better to give it a different name
> > in Emacs, because of the possibility of `e' occurring as a typo.
>
> e has been around for several hundred years.  It is known by that name
> universally in European language cultures.

That `e' as a name for a mathematical constant has been around since before
Napier departed his bones goes without saying, and is irrelevant here (yes).
What I said was that the Emacs "_variable_ `e', defined in `float-sup.el'
has been around for a long time."  So it has, if not quite as long.

And I was careful to say "give it another name _in Emacs_", expecting that
without that proviso there would be some (the nefarious Naysaying Napier
Notaries, for instance) who would get hot and bothered that I was attempting
to rename the math constant in the namespace of Math.

I might be heretical at times, but I am capable of choosing my own heresy -
no need to lend me any. No need to defend the universality of `e' in Math -
from me or from non-european-language cultures. `e' is quite safe from all,
with the single exception of Georges Perec (aka Gorgs Prc).

(I used to think that suggesting changes to emacs-devel was like pulling
teeth, but I've grown to learn that dentistry is nowhere near as difficult
as I once imagined, at least not as a relative measure.)

> If e were to be renamed, how would anybody find out it exists?

How did you find out that a variable named `e' exists with the value it has?
How do you find out that any variable exists?

> Who would remember the new name?

Do you generally have trouble remembering names longer than one character?
If so, do you think Emacs should cater to that disability? If so, how?

;-) Just attempted humor, folks. No need to donate to emacs-abuse@gnu.org
yet.

Anyway, as I said, I won't fight this one. If people want `e', `e' it shall
`b'.

Re: constant `e'

[Chong Yidong]

"Drew Adams" <drew.adams@Oracle.com> writes:

> Single-character global variables are generally not such a great idea. In
> particular, they can easily occur as typographical errors and not be
> detected for a while.
>
> The variable `e', defined in `float-sup.el', has been around for a long
> time, but I wonder if it wouldn't be better to give it a different name in
> Emacs, because of the possibility of `e' occurring as a typo.

I vote for keeping `e' the way it is.  If it ain't broke, don't fix
it.