point-at-final-line

point-at-final-line

[Emanuel Berg]

Did anyone do

(defun point-at-final-line ()
  (let ((line (line-number-at-pos)))
    (save-excursion
      (forward-line 1)
      (= line (line-number-at-pos)) )))

?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: point-at-final-line

[Ben Bacarisse]

Emanuel Berg <moasen@zoho.com> writes:

> Did anyone do
>
> (defun point-at-final-line ()
>   (let ((line (line-number-at-pos)))
>     (save-excursion
>       (forward-line 1)
>       (= line (line-number-at-pos)) )))
>
> ?

Maybe something like

  (= (line-number-at-pos) (line-number-at-pos (point-max)))

though the details depend on how you interpret the final line.

-- 
Ben.

Re: point-at-final-line

[John Mastro]

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Emanuel Berg <moasen@zoho.com> writes:
> > Did anyone do
> >
> > (defun point-at-final-line ()
> >   (let ((line (line-number-at-pos)))
> >     (save-excursion
> >       (forward-line 1)
> >       (= line (line-number-at-pos)) )))
> >
> > ?
>
> Maybe something like
>
>   (= (line-number-at-pos) (line-number-at-pos (point-max)))
>
> though the details depend on how you interpret the final line.

This should do it too, without needing line-number-at-pos:

(defun point-at-final-line ()
  (save-excursion
    (end-of-line)
    (= (forward-line 1) 1)))

Since forward-line returns "the count of lines left to move".

The end-of-line call is because of this bit, from the docstring:

    Exception: With positive N, a non-empty line at the end of the
    buffer, or of its accessible portion, counts as one line
    successfully moved (for the return value). This means that the
    function will move point to the end of such a line and will count it
    as a line moved across, even though there is no next line to go to
    its beginning.

It seems ambiguous to me whether (based on that description) moving to
the end of the line should get us the result we're looking for, but it
seems to in practice. You could use (or (eobp) (= (forward-line 1) 1))
to be safe.

        John

Re: point-at-final-line

[Emanuel Berg]

Ben Bacarisse wrote:

>> Did anyone do
>> (defun point-at-final-line () (let ((line (line-number-at-pos))) (save-excursion (forward-line 1) (= line (line-number-at-pos)) )))
>> ?
>
> Maybe something like
>
>   (= (line-number-at-pos) (line-number-at-pos
> (point-max)))
>
> though the details depend on how you
> interpret the final line.

No, that's much better, thank you.

No one ever did this since 1976, ey? In a while
I'll show you the use case but I can tell you
right now it isn't anything radical to motivate
the delay...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: point-at-final-line

[Emanuel Berg]

John Mastro wrote:

> This should do it too, without needing
> line-number-at-pos

Right, what is better to not have?
`line-number-at-pos' or `save-excursion'?
Normally, I'd say `save-excursion' is better to
not have than most other functions. But here,
`line-number-at-pos' is implemented with
`save-excursion'! But at least it doesn't
show...

> (defun point-at-final-line ()
>  (save-excursion
>    (end-of-line)
>    (= (forward-line 1) 1)))
>
> Since forward-line returns "the count of
> lines left to move".

Indeed, I thought about it this, but the code
sure looks cryptic, especially for such
a trivial task. Again, this won't show when
"point-at-final-line" is called!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: point-at-final-line

[Emanuel Berg]

Seems to be virtually no difference
in performance.

So I'll go with the best-looking code, which is
"point-at-final-line".

Unless there are new facts to the case brought
to the courts attention...

(defmacro measure-time (&rest body)
  "Measure and return the running time of the code block.
Not mine: http://nullprogram.com/blog/2009/05/28/"
  (declare (indent defun))
  (let ((start (make-symbol "start")))
    `(let ((,start (float-time)))
       ,@body
       (- (float-time) ,start))))

(defun point-at-final-line ()
  (= (line-number-at-pos)
     (line-number-at-pos (point-max)) ))
;; (insert (format "\n;; %f" (measure-time #'point-at-final-line)))
;; 0.000005

(defun point-at-final-line-2 ()
  (save-excursion
    (end-of-line)
    (= 1 (forward-line 1)) ))
;; (insert (format "\n;; %f" (measure-time #'point-at-final-line-2)))
;; 0.000006

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: point-at-final-line

[Marcin Borkowski]

On 2018-01-27, at 04:02, Emanuel Berg <moasen@zoho.com> wrote:

> (defmacro measure-time (&rest body)
>   "Measure and return the running time of the code block.
> Not mine: http://nullprogram.com/blog/2009/05/28/"
>   (declare (indent defun))
>   (let ((start (make-symbol "start")))
>     `(let ((,start (float-time)))
>        ,@body
>        (- (float-time) ,start))))

Why not use benchmark.el?

Best,

-- 
Marcin Borkowski

Re: point-at-final-line

[Emanuel Berg]

Marcin Borkowski wrote:

>> (defmacro measure-time (&rest body) "Measure
>> and return the running time of the code
>> block. Not mine:
>> http://nullprogram.com/blog/2009/05/28/"
>> (declare (indent defun)) (let ((start
>> (make-symbol "start"))) `(let ((,start
>> (float-time))) ,@body (- (float-time)
>> ,start))))
>
> Why not use benchmark.el?

My bench has enough marks as it is.
My favorite is when I carved "NO FATE" while
watching Terminator 2. Actually everything
I ever learned how it works socially in life
I got from that movie.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: point-at-final-line

[Stefan Monnier]

> Seems to be virtually no difference
> in performance.

Try them in a very large buffer.


        Stefan

Re: point-at-final-line

[Emanuel Berg]

Stefan Monnier wrote:

>> Seems to be virtually no difference
>> in performance.
>
> Try them in a very large buffer.

How large is very large? I wrote the below zsh
to create large files that look like this:

    1f6920fd18f25904026c59ee560f53c815dde2f854e21e40ceb3f3d58fa55ab9
    593bc90bcecd16dada33273deb2a79e593703844ccc65a2139928124357c7755
    d43d005aeb2bd1b68e264918f99e41aa175b7a9354a171631db0038c68c59f46
    09eab885d64735c3fcd49d650cf1d237025faf9e40ae356017c07fab9db2005c

With 10 000 lines there was still no
difference. With 100 000 lines and a file size
of 6.2M, the results were... identical.

create-bogus-file () {
    local file=$1
    local lines=$2
    rm -r $file
    for l in {0..$lines}; do
        dd if=/dev/urandom count=1 2> /dev/null |
            sha256sum |
            ( read rnd _; echo $rnd >> $file )
    done
}

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: point-at-final-line

[Eli Zaretskii]

> From: Emanuel Berg <moasen@zoho.com>
> Date: Sun, 28 Jan 2018 19:59:14 +0100
> 
> Stefan Monnier wrote:
> 
> >> Seems to be virtually no difference
> >> in performance.
> >
> > Try them in a very large buffer.
> 
> How large is very large? I wrote the below zsh
> to create large files that look like this:
> 
>     1f6920fd18f25904026c59ee560f53c815dde2f854e21e40ceb3f3d58fa55ab9
>     593bc90bcecd16dada33273deb2a79e593703844ccc65a2139928124357c7755
>     d43d005aeb2bd1b68e264918f99e41aa175b7a9354a171631db0038c68c59f46
>     09eab885d64735c3fcd49d650cf1d237025faf9e40ae356017c07fab9db2005c
> 
> With 10 000 lines there was still no
> difference. With 100 000 lines and a file size
> of 6.2M, the results were... identical.

Yes, counting lines is fast.  But not counting lines is even faster.

You don't need to compute the number of the current line, you just
need to establish whether the line current ends at EOB.  Right?  And
the line's end is given by line-end-position, right?

Re: point-at-final-line

[Emanuel Berg]

Eli Zaretskii wrote:

> Yes, counting lines is fast. But not counting
> lines is even faster.
>
> You don't need to compute the number of the
> current line, you just need to establish
> whether the line current ends at EOB. Right?
> And the line's end is given by
> line-end-position, right?

If you mean like this

(defun point-at-final-line-3 ()
  (= (line-end-position) (point-max)) )

I agree it looks the best thus far, however
with 100 000 lines it is still 0.000005 just
like the others. Anyone else feel free to
create an even bigger file

create-bogus-file () {
    local file=$1
    local lines=$2
    rm -r $file
    for l in {0..$lines}; do
        dd if=/dev/urandom count=1 2> /dev/null |
            sha256sum |
            ( read rnd _; echo $rnd >> $file )
    done
}
alias cbf=create-bogus-file

(defmacro measure-time (&rest body)
  "Measure and return the running time of the code block.
Not mine: http://nullprogram.com/blog/2009/05/28/"
  (declare (indent defun))
  (let ((start (make-symbol "start")))
    `(let ((,start (float-time)))
       ,@body
       (- (float-time) ,start))))

(defun point-at-final-line ()
  (= (line-number-at-pos)
     (line-number-at-pos (point-max)) ))
;; (insert (format "\n;; %f" (measure-time #'point-at-final-line)))
;; 0.000005

(defun point-at-final-line-2 ()
  (save-excursion
    (end-of-line) (= 1 (forward-line 1)) ))
;; (insert (format "\n;; %f" (measure-time #'point-at-final-line-2)))
;; 0.000006

(defun point-at-final-line-3 ()
  (= (line-end-position) (point-max)) )
;; (insert (format "\n;; %f" (measure-time #'point-at-final-line-3)))
;; 0.000006

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: point-at-final-line

[Eli Zaretskii]

> From: Emanuel Berg <moasen@zoho.com>
> Date: Mon, 29 Jan 2018 16:03:10 +0100
> 
> Eli Zaretskii wrote:
> 
> > Yes, counting lines is fast. But not counting
> > lines is even faster.
> >
> > You don't need to compute the number of the
> > current line, you just need to establish
> > whether the line current ends at EOB. Right?
> > And the line's end is given by
> > line-end-position, right?
> 
> If you mean like this
> 
> (defun point-at-final-line-3 ()
>   (= (line-end-position) (point-max)) )
> 
> I agree it looks the best thus far, however
> with 100 000 lines it is still 0.000005 just
> like the others.

Good engineering which leads to elegant solutions should be preferable
even when it has no tangible performance advantages.

(But I'm sure that if you run each function many times in a loop, you
will see some differences in timing.  Right now, I think the times are
below your system clock resolution, so you are measuring quantization
noise.)

Re: point-at-final-line

[Emanuel Berg]

Eli Zaretskii wrote:

> (But I'm sure that if you run each function
> many times in a loop, you will see some
> differences in timing. Right now, I think the
> times are below your system clock resolution,
> so you are measuring quantization noise.)

Well, you know what they say, what you can't
measure, you cannot control. That is why the
Americans keep track of what NHL defenseman has
scored the most shorthanded goals in the third
period while not having the home field
advantage...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: point-at-final-line

[Eli Zaretskii]

> From: Emanuel Berg <moasen@zoho.com>
> Date: Mon, 29 Jan 2018 17:40:38 +0100
> 
> Eli Zaretskii wrote:
> 
> > (But I'm sure that if you run each function
> > many times in a loop, you will see some
> > differences in timing. Right now, I think the
> > times are below your system clock resolution,
> > so you are measuring quantization noise.)
> 
> Well, you know what they say, what you can't
> measure, you cannot control.

I'm saying that you _can_ measure this: just run each function many
times in a loop, and then divide the time by the number of iterations.
This is a standard method of timing short code fragments.

Re: point-at-final-line

[Emanuel Berg]

Eli Zaretskii wrote:

> I'm saying that you _can_ measure this: just
> run each function many times in a loop, and
> then divide the time by the number of
> iterations. This is a standard method of
> timing short code fragments.

I don't know about that method. The reason is
it seems to favor your suggestion. And not by
a little! Here are the results in seconds for
10 000 runs in a buffer of 55 lines:

    ;; point-at-final-line-3   0.08
    ;; point-at-final-line-2   0.38
    ;; point-at-final-line-1   0.55

The entire code yanked:

;; This file: http://user.it.uu.se/~embe8573/emacs-init/measure.el

(require 'cl-lib)

(defun point-at-final-line-1 ()
  (= (line-number-at-pos)
     (line-number-at-pos (point-max) )))

(defun point-at-final-line-2 ()
  (save-excursion
    (end-of-line) (= 1 (forward-line 1)) ))

(defun point-at-final-line-3 ()
  (= (line-end-position) (point-max)) )

(defmacro measure-time (&rest body)
  "Measure and return the running time of the code block.
Not mine: http://nullprogram.com/blog/2009/05/28/"
  (declare (indent defun))
  (let ((start (make-symbol "start")))
    `(let ((,start (float-time)))
       ,@body
       (- (float-time) ,start))))

(defun create-random-list (max len)
  (let ((l ()))
    (cl-loop repeat len do
      (push (random max) l))
    l) )

(defun test-final-line-f (fun pos-list)
  (cl-loop for p in pos-list do
    (goto-char p)
    (apply fun nil) ))

(defun test-final-line (its)
  (let*((max      (point-max))
        (pos-list (create-random-list max its))
        (funs     (list #'point-at-final-line-1
                        #'point-at-final-line-2
                        #'point-at-final-line-3) )
        (times    ()) )
    (cl-loop for f in funs do
      (push (list f (measure-time (test-final-line-f f pos-list))) times) )
    (goto-char (point-max))
    (let ((sorted-times (cl-sort times #'< :key #'cadr)))
      (cl-loop for time in sorted-times do
        (insert (format "\n;; %s   %0.2f" (car time) (cadr time)))
        ))))
;; (test-final-line 10000)

;; point-at-final-line-3   0.08
;; point-at-final-line-2   0.38
;; point-at-final-line-1   0.55

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: point-at-final-line

[Eli Zaretskii]

> From: Emanuel Berg <moasen@zoho.com>
> Date: Tue, 30 Jan 2018 03:18:18 +0100
> 
> I don't know about that method. The reason is
> it seems to favor your suggestion. And not by
> a little! Here are the results in seconds for
> 10 000 runs in a buffer of 55 lines:
> 
>     ;; point-at-final-line-3   0.08
>     ;; point-at-final-line-2   0.38
>     ;; point-at-final-line-1   0.55

That's expected, but you should also make sure none of the methods
does some caching behind the scenes, because if some do, the cache
needs to be disabled or flushed between iterations.

Re: point-at-final-line

[Stefan Monnier]

> (defmacro measure-time (&rest body)
>   "Measure and return the running time of the code block.
> Not mine: http://nullprogram.com/blog/2009/05/28/"
>   (declare (indent defun))
>   (let ((start (make-symbol "start")))
>     `(let ((,start (float-time)))
>        ,@body
>        (- (float-time) ,start))))
[...]
> ;; (insert (format "\n;; %f" (measure-time #'point-at-final-line)))

This doesn't actually call the function, so no wonder it will take the
same amount of time no matter which function you pass to it.


        Stefan

Re: point-at-final-line

[Emanuel Berg]

Stefan Monnier wrote:

>> (insert (format "\n;; %f" (measure-time
>> #'point-at-final-line)))
>
> This doesn't actually call the function, so
> no wonder it will take the same amount of
> time no matter which function you pass to it.

And if you do it the right way, you don't need
a buffer of 100 000 lines or 10 000 iterations:

;; (insert (format "\n;; %f" (measure-time (point-at-final-line-1))))
;; 0.000154
;; (insert (format "\n;; %f" (measure-time (point-at-final-line-2))))
;; 0.000045
;; (insert (format "\n;; %f" (measure-time (point-at-final-line-3))))
;; 0.000014

-- 
underground experts united
http://user.it.uu.se/~embe8573