Re: beginning-of-buffer computations

Re: beginning-of-buffer computations

[Barry Margolin]

In article <mailman.18932.1422563201.1147.help-gnu-emacs@gnu.org>,
 Marcin Borkowski <mbork@wmi.amu.edu.pl> wrote:

> Hello people,
> 
> I'm continuing my journey through simple.el, and I've just found
> something strange.  Apparently, a PhD in maths is not enough to grok the
> arithmetic operations in beginning-of-buffer...;-)
> 
> (goto-char (if (and arg (not (consp arg)))
> 		   (+ (point-min)
> 		      (if (> size 10000)
> 			  ;; Avoid overflow for large buffer sizes!
> 			  (* (prefix-numeric-value arg)
> 			     (/ size 10))
> 			(/ (+ 10 (* size (prefix-numeric-value arg))) 10)))
> 		 (point-min)))
> 
> Now I pretty much see what is going on for "large buffers".  For smaller
> ones, I'm wondering what is the rationale behind the `+ 10' part?  It
> approximately adds one to the result (of course, the result is truncated
> to the next-lower-integer, so it's not that, ekhm, simple) - but why?

Good question. I don't think there's any difference between that and

(+ 1 (/ (* size (prefix-numeric-value arg)) 10))

It would make more sense if it were adding 5, which would be the way to 
round up.

> 
> (Not to mention the next line - not shown here - which `forward-line's
> by 1.  Why not just (beginning-of-line) instead?)

forward-line ignores field boundaries, beginning-of-line doesn't.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

beginning-of-buffer computations

[Marcin Borkowski]

Hello people,

I'm continuing my journey through simple.el, and I've just found
something strange.  Apparently, a PhD in maths is not enough to grok the
arithmetic operations in beginning-of-buffer...;-)

(goto-char (if (and arg (not (consp arg)))
		   (+ (point-min)
		      (if (> size 10000)
			  ;; Avoid overflow for large buffer sizes!
			  (* (prefix-numeric-value arg)
			     (/ size 10))
			(/ (+ 10 (* size (prefix-numeric-value arg))) 10)))
		 (point-min)))

Now I pretty much see what is going on for "large buffers".  For smaller
ones, I'm wondering what is the rationale behind the `+ 10' part?  It
approximately adds one to the result (of course, the result is truncated
to the next-lower-integer, so it's not that, ekhm, simple) - but why?

(Not to mention the next line - not shown here - which `forward-line's
by 1.  Why not just (beginning-of-line) instead?)

TIA,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: beginning-of-buffer computations

[Michael Heerdegen]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> Now I pretty much see what is going on for "large buffers".  For
> smaller ones, I'm wondering what is the rationale behind the `+ 10'
> part?  It approximately adds one to the result (of course, the result
> is truncated to the next-lower-integer, so it's not that, ekhm,
> simple) - but why?

As had been said, that +10 part effectively adds 1 to the result.

I guess that's because buffer positions start counting from 1, not from
0.  If you want to go to 0/10 of the buffer, you want to land on
(point-min) = 1, etc.


Michael.

Re: beginning-of-buffer computations

[Robert Thorpe]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> 			(/ (+ 10 (* size (prefix-numeric-value arg))) 10)))

This line was in the first version of simple.el put into revision
control in 1991.  I think the aim was to prevent a calculation like (/ 0
10).  On some platforms it's an error to divide zero by anything, and it
triggers an interrupt.  Perhaps that was a problem at the time.

That leaves the question: why is the calculation done this way?  I think
that's because not all Emacs version supported floating point at the
time.  I think in that case numbers described by ratios were used
instead, e.g. 5/6.

I'm not sure on either of these things though.

> (Not to mention the next line - not shown here - which `forward-line's
> by 1.  Why not just (beginning-of-line) instead?)

I think that's because of "field text motion".  See the help for
beginning-of-line.

BR,
Robert Thorpe

Re: beginning-of-buffer computations

[Robert Thorpe]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
>
>> 			(/ (+ 10 (* size (prefix-numeric-value arg))) 10)))
>
> This line was in the first version of simple.el put into revision
> control in 1991.

Michael Heerdegen is write about this, the 1 is needed because
beginning-of-buffer is character 1, not 0.

BR,
Robert Thorpe

Re: beginning-of-buffer computations

[Stefan Monnier]

> Michael Heerdegen is write about this, the 1 is needed because
> beginning-of-buffer is character 1, not 0.

No: the result is added to point-min already.


        Stefan

Re: beginning-of-buffer computations

[Michael Heerdegen]

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

> No: the result is added to point-min already.

Indeed!

An worst case example: in this buffer:

--8<---------------cut here---------------start------------->8---

texttexttexttexttexttexttexttexttexttexttext

--8<---------------cut here---------------end--------------->8---

(first and last line empty), M-0 beginning-of-buffer RET actually jumps
to the end of the buffer.

In large buffers, adding one rather makes a big difference to the
result.  So there doesn't seem to be so much witness in adding that
summand...


Michael.