What is 0.01 here not 0.01 here 0.009999999999999?

What is 0.01 here not 0.01 here 0.009999999999999?

[Jean Louis]

I would like to get a number increased for 0.01:

(defun rcd-vc-increase-decimal-revision-number (nn.nn)
  (let* ((nn.nn (format "%s" nn.nn))
	 (nn.nn (format "%.2f" (string-to-number nn.nn)))
	 (nn.nn (string-to-number nn.nn)))
    (+ nn.nn 0.01)))

But result is not what I want, as I want to get 10.13, though it is
tiny loss:

(rcd-vc-increase-decimal-revision-number "10.12") → 10.129999999999999

I found how to solve it, but maybe there is better way to round the
decimals behind the dot?

(defun rcd-vc-increase-decimal-revision-number (nn.nn)
  (let* ((nn.nn (format "%s" nn.nn))
	 (nn.nn (format "%.2f" (string-to-number nn.nn)))
	 (nn.nn (string-to-number nn.nn)))
    (string-to-number (format "%.2f" (+ nn.nn 0.01)))))

(rcd-vc-increase-decimal-revision-number "10.12") → 10.13


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Stefan Monnier]

> I would like to get a number increased for 0.01:

Are you aware that in most programming languages (including ELisp) there
is no floating point number whose value is exactly 0.01?

If not, I suggest you either avoid floating point numbers, accept that
floating point numbers always are inexact, or read up on floating point
numbers (e.g. https://en.wikipedia.org/wiki/Floating-point_arithmetic)


        Stefan

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2021-04-02 16:56]:
> > I would like to get a number increased for 0.01:
> 
> Are you aware that in most programming languages (including ELisp) there
> is no floating point number whose value is exactly 0.01?
> 
> If not, I suggest you either avoid floating point numbers, accept that
> floating point numbers always are inexact, or read up on floating point
> numbers (e.g. https://en.wikipedia.org/wiki/Floating-point_arithmetic)

Thank you. I did browse it, did not yet understand it.

Not that I need the absolute internally, just the practical
result as we learned it in school like that 10.11 plus 0.01
results with 10.12 and not something else. Results are used for
automated version numbers (in some cases).

Sometimes result is just as expected:

(+ 10.01 0.01) → 10.02

(defun rcd-vc-increase-decimal-revision-number (nn.nn)
  (let* ((nn.nn (format "%s" nn.nn))
         (nn.nn (format "%.2f" (string-to-number nn.nn)))
         (nn.nn (string-to-number nn.nn)))
    (+ nn.nn 0.01)))

It does not happen always:

(rcd-vc-increase-decimal-revision-number "10.01") → 10.02
(rcd-vc-increase-decimal-revision-number 10.01) → 10.02
(rcd-vc-increase-decimal-revision-number "10.12") → 10.129999999999999

Perl also says it is "about" or ~10.13

$ perl 
print 10.12+0.01;
10.13~

Guile also:

scheme@(guile-user)> (+ 10.12 0.01)
$1 = 10.129999999999999

So it is not always, it is weird, without reading scientific
papers. Thank you Eli. But I have solved it for my specific need
for RCD Version Control System this way:

(defun string-is-number-p (s)
  (let ((s (string-trim s)))
    (cond ((seq-empty-p s) nil)
	  ((string-match "[^0123456789\\.]" s) nil)
	  ((numberp (string-to-number s)) (string-to-number s)))))

(defun rcd-vc-revision-is-floating-number-p (revision)
  "Return T if REVISION is possibly floating number."
  (if (string-is-number-p (format "%s" revision))
      (let* ((nnnn (split-string (format "%.2f" (string-to-number (format "%s" revision))) "\\."))
	     (two (length nnnn)))
	(when (= two 2)
	  (let* ((first-is-number (string-is-number-p (car nnnn)))
		 (second-is-number (string-is-number-p (cadr nnnn))))
	    (when (and first-is-number second-is-number)
	      t))))
    nil))

(defun rcd-vc-increase-decimal-revision-number (nn.nn)
  "Increase the floating number NN.NN provided either as number or
string for 0.01."
  (if (rcd-vc-revision-is-floating-number-p nn.nn)
      (let* ((nn.nn (format "%s" nn.nn))
	     (nn.nn (format "%.2f" (string-to-number nn.nn)))
	     (nn.nn (string-to-number nn.nn)))
	(format "%.2f" (+ nn.nn 0.01)))
    nn.nn))

This I want to work as here:
(rcd-vc-increase-decimal-revision-number "Version 1.0") → "Version 1.0"

But this I want to get incremented, converted into string, even
if string given:

(rcd-vc-increase-decimal-revision-number "0") → "0.01"
(rcd-vc-increase-decimal-revision-number "1") → "1.01"
(rcd-vc-increase-decimal-revision-number "11.12") → "11.13"
(rcd-vc-increase-decimal-revision-number 11.12) → "11.13"


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Teemu Likonen]

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

* 2021-04-02 20:03:54+0300, Jean Louis wrote:

> Not that I need the absolute internally, just the practical
> result as we learned it in school like that 10.11 plus 0.01
> results with 10.12 and not something else. Results are used for
> automated version numbers (in some cases).

As you have learned, floating point numbers are not decimal numbers even
if they are read and printed as such. For decimal mathematics you can
use calc-eval function. Some comparison:

    ELISP> (+ 10.12 0.01)
    10.129999999999999

    ELISP> (calc-eval "10.12 + 0.01")
    "10.13"

    ELISP> (* 3 0.1)
    0.30000000000000004

    ELISP> (calc-eval "3 * 0.1")
    "0.3"

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Jean Louis]

* Teemu Likonen <tlikonen@iki.fi> [2021-04-02 20:42]:
> * 2021-04-02 20:03:54+0300, Jean Louis wrote:
> 
> > Not that I need the absolute internally, just the practical
> > result as we learned it in school like that 10.11 plus 0.01
> > results with 10.12 and not something else. Results are used for
> > automated version numbers (in some cases).
> 
> As you have learned, floating point numbers are not decimal numbers even
> if they are read and printed as such. For decimal mathematics you can
> use calc-eval function. Some comparison:
> 
>     ELISP> (+ 10.12 0.01)
>     10.129999999999999
> 
>     ELISP> (calc-eval "10.12 + 0.01")
>     "10.13"
> 
>     ELISP> (* 3 0.1)
>     0.30000000000000004
> 
>     ELISP> (calc-eval "3 * 0.1")
>     "0.3"

Hey, that is good to know, it spares me efforts. 

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[John Yates]

On Fri, Apr 2, 2021 at 1:07 PM Jean Louis <bugs@gnu.support> wrote:
> Thank you. I did browse it, did not yet understand it.

And so, having made no progress towards understanding
computer-based floating point arithmetic, you press on
arguing from a position of ignorance.

Put most simply, on a machine in which floating point
numbers encode the significand (sometimes erroneously
termed the 'mantissa') using a binary representation,
there is no way to encode, and hence express, a fraction
whose divisor is not a power of 2.  So you can encode
precisely 1/2, 1/4, 1/128, etc.  But you will never have a
precise encoding of 1/3, 1/5, 1/10, etc.

Much effort has gone into optimizing "round tripping",
the conversion of decimal numbers into the nearest
floating point number and getting it back out again.

But you are asking for more.  You want arithmetic on
imprecise representations of your perfect decimal
numbers to deliver precisely the same result as your
mental model.  That is never going to happen.

I am not going to try to explain normalization, rounding,
rounding modes, etc.  Suffice it to say that this is the
realm of numerical analysis, a rich field that traces its
roots straight back to Alen Turing.

In closing, let me recommend David Goldberg's classic
'What every computer scientist should know about
<http://pages.cs.wisc.edu/~david/courses/cs552/S12/handouts/goldberg-floating-point.pdf>
floating-poing arithmetic
<http://pages.cs.wisc.edu/~david/courses/cs552/S12/handouts/goldberg-floating-point.pdf>
'.

/john

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Jean Louis]

* John Yates <john@yates-sheets.org> [2021-04-02 23:48]:
> On Fri, Apr 2, 2021 at 1:07 PM Jean Louis <bugs@gnu.support> wrote:
> > Thank you. I did browse it, did not yet understand it.
> 
> And so, having made no progress towards understanding
> computer-based floating point arithmetic, you press on
> arguing from a position of ignorance.

Oh John, not so harsh on me. I did understand the principle and thank
you for presenting it simpler. Before few years I got it
already. Understanding principle does not mean that I understand full
documents, they have many references and mathematical terms that I
cannot understand. There is no ignorance, and why assume so, when I
need the feature? Person who does not need feature is not
interested. But don't ask me to get as interested as mathematics
professor, as I am not. All what I need is to increase the versio
number in format NN.NN. There was solution with `calc-eval' that I did
not know about.

> Put most simply, on a machine in which floating point
> numbers encode the significand (sometimes erroneously
> termed the 'mantissa') using a binary representation,
> there is no way to encode, and hence express, a fraction
> whose divisor is not a power of 2.  So you can encode
> precisely 1/2, 1/4, 1/128, etc.  But you will never have a
> precise encoding of 1/3, 1/5, 1/10, etc.

Nicely explained, I do understand it, it is clear, I have been playing
with pocket calculators. Yet understanding the principle may not lead to
comprehension of the whole subject.

That word mantissa is in Wordnet as:

* Overview of noun mantissa

The noun mantissa has 1 sense (no senses from tagged texts)
1. mantissa, fixed-point part -- (the positive fractional part of the
representation of a logarithm; in the expression log 643 = 2.808 the
mantissa is .808)

I did not find the word "significand", but I think you mean that above
definition. 

> Much effort has gone into optimizing "round tripping",
> the conversion of decimal numbers into the nearest
> floating point number and getting it back out again.
> 
> But you are asking for more.  You want arithmetic on
> imprecise representations of your perfect decimal
> numbers to deliver precisely the same result as your
> mental model.  That is never going to happen.

Actually, I am asking for less... how you did not see it?

Yes, I need arithmetic on imprecise representations... to deliver what
I want, and it is doing what I want. `calc-eval' is doing it, and my
function is delivering me string that is increased for 0.01 -- well
that is what I wanted, and is happening... several times per hour
those numbers are increasing, function is working ;-p

> I am not going to try to explain normalization, rounding,
> rounding modes, etc.  Suffice it to say that this is the
> realm of numerical analysis, a rich field that traces its
> roots straight back to Alen Turing.

Excellent, but if function goes that deep, it would take a while to
give me 10.11 increase for 0.01.

> In closing, let me recommend David Goldberg's classic
> 'What every computer scientist should know about
> <http://pages.cs.wisc.edu/~david/courses/cs552/S12/handouts/goldberg-floating-point.pdf>
> floating-poing arithmetic
> <http://pages.cs.wisc.edu/~david/courses/cs552/S12/handouts/goldberg-floating-point.pdf>

Thank you. I will browse it, to get the concept, not read it to get
comprehension.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[John Yates]

> I did not find the word "significand", but I think you mean that above
> definition.

https://en.wikipedia.org/wiki/Significand

> Yes, I need arithmetic on imprecise representations... to deliver what
> I want, and it is doing what I want. `calc-eval' is doing it, and my
> function is delivering me string that is increased for 0.01 -- well
> that is what I wanted, and is happening... several times per hour
> those numbers are increasing, function is working ;-p

This will probably work because each time you increment by an
approximation of 0.01 you convert back to a decimal representation
via a path that applies a number of heuristics to guess what value
you want to see.  Having rendered your incremented value as a
decimal string, when you read it back in you _do not_ recreate
a bit for bit copy of the earlier sum, but rather a floating point
number that is the closest approximation possible to the decimal
number being presented.  Put another way, each output / input
iteration prevents you from accumulating errors.

If you wanted to support more general arithmetic on your version
numbers I would advise using scaled integer arithmetic.  Assuming
that you can guarantee the granularity of your version numbers will
always be 0.01 then you can represent 0.01 as 1 and 11.07 as
1107.  Then to recover the major version you just divide by 100 and
to recover the minor version you mod by 100.

Using 100 is necessary if you want 10.99 + 0.01 to return 11.00.
If you never expect to handle a carry from your minor version field
into your major version field then you could scale by a power of
two (e.g. 128).  Then division reduces to right shifting and mod
to masking (e.g. for 128 that means anding with 127).

/john

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Jean Louis]

* John Yates <john@yates-sheets.org> [2021-04-03 01:05]:
> > Yes, I need arithmetic on imprecise representations... to deliver what
> > I want, and it is doing what I want. `calc-eval' is doing it, and my
> > function is delivering me string that is increased for 0.01 -- well
> > that is what I wanted, and is happening... several times per hour
> > those numbers are increasing, function is working ;-p
> 
> This will probably work because each time you increment by an
> approximation of 0.01 you convert back to a decimal representation
> via a path that applies a number of heuristics to guess what value
> you want to see.  Having rendered your incremented value as a
> decimal string, when you read it back in you _do not_ recreate
> a bit for bit copy of the earlier sum, but rather a floating point
> number that is the closest approximation possible to the decimal
> number being presented.  Put another way, each output / input
> iteration prevents you from accumulating errors.

That is right. I keep the revision number as a string, rather than a
number, as some revisions may have various abbreviations, including
letters or combinations with numbers. But those that are only a number
are or can be automatically increased each time. Though there exists
the unique ID in the database as well to access revisions in order
that are associated to a file.

> If you wanted to support more general arithmetic on your version
> numbers I would advise using scaled integer arithmetic.  Assuming
> that you can guarantee the granularity of your version numbers will
> always be 0.01 then you can represent 0.01 as 1 and 11.07 as
> 1107.  Then to recover the major version you just divide by 100 and
> to recover the minor version you mod by 100.

From those ideas...

(+ 10.12 0.01) → 10.129999999999999
(/ (1+ 1012) 100.0) → 10.13
(/ (1+ (round (* 10.10 100))) 100.0) → 10.11
(/ (1+ (round (* 10.11 100))) 100.0) → 10.12
(/ (1+ (round (* 10.12 100))) 100.0) → 10.13
   
Then instead of this:

(defun rcd-vc-increase-decimal-revision-number (nn.nn)
  "Increase the floating number NN.NN provided either as number or
string for 0.01."
  (if (rcd-vc-revision-is-floating-number-p nn.nn)
      (let* ((nn.nn (format "%s" nn.nn))
	     (nn.nn (format "%.2f" (string-to-number nn.nn)))
	     (nn.nn (string-to-number nn.nn)))
	(format "%.2f" (+ nn.nn 0.01)))
    nn.nn))

(defun rcd-vc-increase-decimal-revision-number (nn.nn)
  "Increase the floating number NN.NN provided either as number or
string for 0.01."
  (if (rcd-vc-revision-is-floating-number-p nn.nn)
      (format "%.2f" (/ (1+ (round (* (string-to-number nn.nn) 100))) 100.0))))

Without %.2f this would be:

(rcd-vc-increase-decimal-revision-number "10.09") → "10.1" which
is not what I want.

(rcd-vc-increase-decimal-revision-number "10.00") → "10.01"
(rcd-vc-increase-decimal-revision-number "10.01") → "10.02"
(rcd-vc-increase-decimal-revision-number "10.02") → "10.03"
(rcd-vc-increase-decimal-revision-number "10.03") → "10.04"
(rcd-vc-increase-decimal-revision-number "10.04") → "10.05"
(rcd-vc-increase-decimal-revision-number "10.05") → "10.06"
(rcd-vc-increase-decimal-revision-number "10.06") → "10.07"
(rcd-vc-increase-decimal-revision-number "10.07") → "10.08"
(rcd-vc-increase-decimal-revision-number "10.08") → "10.09"
(rcd-vc-increase-decimal-revision-number "10.09") → "10.10"
(rcd-vc-increase-decimal-revision-number "10.10") → "10.11"
(rcd-vc-increase-decimal-revision-number "10.11") → "10.12"
(rcd-vc-increase-decimal-revision-number "10.12") → "10.13"
(rcd-vc-increase-decimal-revision-number "10.13") → "10.14"
(rcd-vc-increase-decimal-revision-number "10.14") → "10.15"
(rcd-vc-increase-decimal-revision-number "10.15") → "10.16"
(rcd-vc-increase-decimal-revision-number "10.16") → "10.17"
(rcd-vc-increase-decimal-revision-number "10.17") → "10.18"
(rcd-vc-increase-decimal-revision-number "10.18") → "10.19"
(rcd-vc-increase-decimal-revision-number "10.19") → "10.20"
(rcd-vc-increase-decimal-revision-number "10.20") → "10.21"
(rcd-vc-increase-decimal-revision-number "10.21") → "10.22"
(rcd-vc-increase-decimal-revision-number "10.22") → "10.23"
(rcd-vc-increase-decimal-revision-number "10.23") → "10.24"
(rcd-vc-increase-decimal-revision-number "10.24") → "10.25"
(rcd-vc-increase-decimal-revision-number "10.25") → "10.26"
(rcd-vc-increase-decimal-revision-number "10.26") → "10.27"
(rcd-vc-increase-decimal-revision-number "10.27") → "10.28"
(rcd-vc-increase-decimal-revision-number "10.28") → "10.29"
(rcd-vc-increase-decimal-revision-number "10.29") → "10.30"
(rcd-vc-increase-decimal-revision-number "10.30") → "10.31"
(rcd-vc-increase-decimal-revision-number "10.31") → "10.32"
(rcd-vc-increase-decimal-revision-number "10.32") → "10.33"
(rcd-vc-increase-decimal-revision-number "10.33") → "10.34"
(rcd-vc-increase-decimal-revision-number "10.34") → "10.35"
(rcd-vc-increase-decimal-revision-number "10.35") → "10.36"
(rcd-vc-increase-decimal-revision-number "10.36") → "10.37"
(rcd-vc-increase-decimal-revision-number "10.37") → "10.38"
(rcd-vc-increase-decimal-revision-number "10.38") → "10.39"
(rcd-vc-increase-decimal-revision-number "10.39") → "10.40"
(rcd-vc-increase-decimal-revision-number "10.40") → "10.41"
(rcd-vc-increase-decimal-revision-number "10.41") → "10.42"
(rcd-vc-increase-decimal-revision-number "10.42") → "10.43"
(rcd-vc-increase-decimal-revision-number "10.43") → "10.44"
(rcd-vc-increase-decimal-revision-number "10.44") → "10.45"
(rcd-vc-increase-decimal-revision-number "10.45") → "10.46"
(rcd-vc-increase-decimal-revision-number "10.46") → "10.47"
(rcd-vc-increase-decimal-revision-number "10.47") → "10.48"
(rcd-vc-increase-decimal-revision-number "10.48") → "10.49"
(rcd-vc-increase-decimal-revision-number "10.49") → "10.50"
(rcd-vc-increase-decimal-revision-number "10.50") → "10.51"
(rcd-vc-increase-decimal-revision-number "10.51") → "10.52"
(rcd-vc-increase-decimal-revision-number "10.52") → "10.53"
(rcd-vc-increase-decimal-revision-number "10.53") → "10.54"
(rcd-vc-increase-decimal-revision-number "10.54") → "10.55"
(rcd-vc-increase-decimal-revision-number "10.55") → "10.56"
(rcd-vc-increase-decimal-revision-number "10.56") → "10.57"
(rcd-vc-increase-decimal-revision-number "10.57") → "10.58"
(rcd-vc-increase-decimal-revision-number "10.58") → "10.59"
(rcd-vc-increase-decimal-revision-number "10.59") → "10.60"
(rcd-vc-increase-decimal-revision-number "10.60") → "10.61"
(rcd-vc-increase-decimal-revision-number "10.61") → "10.62"
(rcd-vc-increase-decimal-revision-number "10.62") → "10.63"
(rcd-vc-increase-decimal-revision-number "10.63") → "10.64"
(rcd-vc-increase-decimal-revision-number "10.64") → "10.65"
(rcd-vc-increase-decimal-revision-number "10.65") → "10.66"
(rcd-vc-increase-decimal-revision-number "10.66") → "10.67"
(rcd-vc-increase-decimal-revision-number "10.67") → "10.68"
(rcd-vc-increase-decimal-revision-number "10.68") → "10.69"
(rcd-vc-increase-decimal-revision-number "10.69") → "10.70"
(rcd-vc-increase-decimal-revision-number "10.70") → "10.71"
(rcd-vc-increase-decimal-revision-number "10.71") → "10.72"
(rcd-vc-increase-decimal-revision-number "10.71") → "10.72"

> Using 100 is necessary if you want 10.99 + 0.01 to return 11.00.
> If you never expect to handle a carry from your minor version field
> into your major version field then you could scale by a power of
> two (e.g. 128).  Then division reduces to right shifting and mod
> to masking (e.g. for 128 that means anding with 127).

Principle is interesting.

Just that I need to keep it as a string in the database, so that
export makes sense without any Lisp, and that shell or `psql' can
export it straight without external formulas, for example, file
can be exported into file system with its revision number without
using calculation of a version number. That is why "10.01" should
be stored in the database as string. Somebody could also
designate it as "v10.01" but that one would not be automatically
incremented. Revision numbers are by free will, and user could
decide if they would be automatically incremented.

Because it is database backed, minimum interaction with the
system is possible. In general, registered files are recorded in
the database on each kill or save of the buffer, or by single
key. I find it handy without any interactions.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> * John Yates <john@yates-sheets.org> [2021-04-03 01:05]:
>> > Yes, I need arithmetic on imprecise representations... to deliver what
>> > I want, and it is doing what I want. `calc-eval' is doing it, and my
>> > function is delivering me string that is increased for 0.01 -- well
>> > that is what I wanted, and is happening... several times per hour
>> > those numbers are increasing, function is working ;-p
>> 
>> This will probably work because each time you increment by an
>> approximation of 0.01 you convert back to a decimal representation
>> via a path that applies a number of heuristics to guess what value
>> you want to see.  Having rendered your incremented value as a
>> decimal string, when you read it back in you _do not_ recreate
>> a bit for bit copy of the earlier sum, but rather a floating point
>> number that is the closest approximation possible to the decimal
>> number being presented.  Put another way, each output / input
>> iteration prevents you from accumulating errors.
>
> That is right. I keep the revision number as a string, rather than a
> number, as some revisions may have various abbreviations, including
> letters or combinations with numbers. But those that are only a number
> are or can be automatically increased each time. Though there exists
> the unique ID in the database as well to access revisions in order
> that are associated to a file.
>
>> If you wanted to support more general arithmetic on your version
>> numbers I would advise using scaled integer arithmetic.  Assuming
>> that you can guarantee the granularity of your version numbers will
>> always be 0.01 then you can represent 0.01 as 1 and 11.07 as
>> 1107.  Then to recover the major version you just divide by 100 and
>> to recover the minor version you mod by 100.
>
> From those ideas...
>
> (+ 10.12 0.01) → 10.129999999999999
> (/ (1+ 1012) 100.0) → 10.13
> (/ (1+ (round (* 10.10 100))) 100.0) → 10.11
> (/ (1+ (round (* 10.11 100))) 100.0) → 10.12
> (/ (1+ (round (* 10.12 100))) 100.0) → 10.13
>    
> Then instead of this:
>
> (defun rcd-vc-increase-decimal-revision-number (nn.nn)
>   "Increase the floating number NN.NN provided either as number or
> string for 0.01."
>   (if (rcd-vc-revision-is-floating-number-p nn.nn)
>       (let* ((nn.nn (format "%s" nn.nn))
> 	     (nn.nn (format "%.2f" (string-to-number nn.nn)))
> 	     (nn.nn (string-to-number nn.nn)))
> 	(format "%.2f" (+ nn.nn 0.01)))
>     nn.nn))
>
> (defun rcd-vc-increase-decimal-revision-number (nn.nn)
>   "Increase the floating number NN.NN provided either as number or
> string for 0.01."
>   (if (rcd-vc-revision-is-floating-number-p nn.nn)
>       (format "%.2f" (/ (1+ (round (* (string-to-number nn.nn) 100))) 100.0))))
>
> Without %.2f this would be:
>
> (rcd-vc-increase-decimal-revision-number "10.09") → "10.1" which
> is not what I want.
>
> (rcd-vc-increase-decimal-revision-number "10.00") → "10.01"
> (rcd-vc-increase-decimal-revision-number "10.01") → "10.02"
> (rcd-vc-increase-decimal-revision-number "10.02") → "10.03"
> (rcd-vc-increase-decimal-revision-number "10.03") → "10.04"
> (rcd-vc-increase-decimal-revision-number "10.04") → "10.05"
> (rcd-vc-increase-decimal-revision-number "10.05") → "10.06"
> (rcd-vc-increase-decimal-revision-number "10.06") → "10.07"
> (rcd-vc-increase-decimal-revision-number "10.07") → "10.08"
> (rcd-vc-increase-decimal-revision-number "10.08") → "10.09"
> (rcd-vc-increase-decimal-revision-number "10.09") → "10.10"
> (rcd-vc-increase-decimal-revision-number "10.10") → "10.11"
> (rcd-vc-increase-decimal-revision-number "10.11") → "10.12"
> (rcd-vc-increase-decimal-revision-number "10.12") → "10.13"
> (rcd-vc-increase-decimal-revision-number "10.13") → "10.14"
> (rcd-vc-increase-decimal-revision-number "10.14") → "10.15"
> (rcd-vc-increase-decimal-revision-number "10.15") → "10.16"
> (rcd-vc-increase-decimal-revision-number "10.16") → "10.17"
> (rcd-vc-increase-decimal-revision-number "10.17") → "10.18"
> (rcd-vc-increase-decimal-revision-number "10.18") → "10.19"
> (rcd-vc-increase-decimal-revision-number "10.19") → "10.20"
> (rcd-vc-increase-decimal-revision-number "10.20") → "10.21"
> (rcd-vc-increase-decimal-revision-number "10.21") → "10.22"
> (rcd-vc-increase-decimal-revision-number "10.22") → "10.23"
> (rcd-vc-increase-decimal-revision-number "10.23") → "10.24"
> (rcd-vc-increase-decimal-revision-number "10.24") → "10.25"
> (rcd-vc-increase-decimal-revision-number "10.25") → "10.26"
> (rcd-vc-increase-decimal-revision-number "10.26") → "10.27"
> (rcd-vc-increase-decimal-revision-number "10.27") → "10.28"
> (rcd-vc-increase-decimal-revision-number "10.28") → "10.29"
> (rcd-vc-increase-decimal-revision-number "10.29") → "10.30"
> (rcd-vc-increase-decimal-revision-number "10.30") → "10.31"
> (rcd-vc-increase-decimal-revision-number "10.31") → "10.32"
> (rcd-vc-increase-decimal-revision-number "10.32") → "10.33"
> (rcd-vc-increase-decimal-revision-number "10.33") → "10.34"
> (rcd-vc-increase-decimal-revision-number "10.34") → "10.35"
> (rcd-vc-increase-decimal-revision-number "10.35") → "10.36"
> (rcd-vc-increase-decimal-revision-number "10.36") → "10.37"
> (rcd-vc-increase-decimal-revision-number "10.37") → "10.38"
> (rcd-vc-increase-decimal-revision-number "10.38") → "10.39"
> (rcd-vc-increase-decimal-revision-number "10.39") → "10.40"
> (rcd-vc-increase-decimal-revision-number "10.40") → "10.41"
> (rcd-vc-increase-decimal-revision-number "10.41") → "10.42"
> (rcd-vc-increase-decimal-revision-number "10.42") → "10.43"
> (rcd-vc-increase-decimal-revision-number "10.43") → "10.44"
> (rcd-vc-increase-decimal-revision-number "10.44") → "10.45"
> (rcd-vc-increase-decimal-revision-number "10.45") → "10.46"
> (rcd-vc-increase-decimal-revision-number "10.46") → "10.47"
> (rcd-vc-increase-decimal-revision-number "10.47") → "10.48"
> (rcd-vc-increase-decimal-revision-number "10.48") → "10.49"
> (rcd-vc-increase-decimal-revision-number "10.49") → "10.50"
> (rcd-vc-increase-decimal-revision-number "10.50") → "10.51"
> (rcd-vc-increase-decimal-revision-number "10.51") → "10.52"
> (rcd-vc-increase-decimal-revision-number "10.52") → "10.53"
> (rcd-vc-increase-decimal-revision-number "10.53") → "10.54"
> (rcd-vc-increase-decimal-revision-number "10.54") → "10.55"
> (rcd-vc-increase-decimal-revision-number "10.55") → "10.56"
> (rcd-vc-increase-decimal-revision-number "10.56") → "10.57"
> (rcd-vc-increase-decimal-revision-number "10.57") → "10.58"
> (rcd-vc-increase-decimal-revision-number "10.58") → "10.59"
> (rcd-vc-increase-decimal-revision-number "10.59") → "10.60"
> (rcd-vc-increase-decimal-revision-number "10.60") → "10.61"
> (rcd-vc-increase-decimal-revision-number "10.61") → "10.62"
> (rcd-vc-increase-decimal-revision-number "10.62") → "10.63"
> (rcd-vc-increase-decimal-revision-number "10.63") → "10.64"
> (rcd-vc-increase-decimal-revision-number "10.64") → "10.65"
> (rcd-vc-increase-decimal-revision-number "10.65") → "10.66"
> (rcd-vc-increase-decimal-revision-number "10.66") → "10.67"
> (rcd-vc-increase-decimal-revision-number "10.67") → "10.68"
> (rcd-vc-increase-decimal-revision-number "10.68") → "10.69"
> (rcd-vc-increase-decimal-revision-number "10.69") → "10.70"
> (rcd-vc-increase-decimal-revision-number "10.70") → "10.71"
> (rcd-vc-increase-decimal-revision-number "10.71") → "10.72"
> (rcd-vc-increase-decimal-revision-number "10.71") → "10.72"
>
>> Using 100 is necessary if you want 10.99 + 0.01 to return 11.00.
>> If you never expect to handle a carry from your minor version field
>> into your major version field then you could scale by a power of
>> two (e.g. 128).  Then division reduces to right shifting and mod
>> to masking (e.g. for 128 that means anding with 127).
>
> Principle is interesting.
>
> Just that I need to keep it as a string in the database, so that
> export makes sense without any Lisp, and that shell or `psql' can
> export it straight without external formulas, for example, file
> can be exported into file system with its revision number without
> using calculation of a version number. That is why "10.01" should
> be stored in the database as string. Somebody could also
> designate it as "v10.01" but that one would not be automatically
> incremented. Revision numbers are by free will, and user could
> decide if they would be automatically incremented.
>
> Because it is database backed, minimum interaction with the
> system is possible. In general, registered files are recorded in
> the database on each kill or save of the buffer, or by single
> key. I find it handy without any interactions.

Two different ways, each part on it's own, or as one macro. Much simpler
than your decimal handling. I suggest to change your database scheme and
store those as integers there too so you don't need to convert back and
forth. Even better, skip the database and keep version number directly
in your paper which you hopefully write in an org file ;-).

(defun rcd-vc-increase-major-number (version)
  (aset version 0 (1+ (aref version 0))))

(defun rcd-vc-increase-minor-number (version)
  (aset version 1 (1+ (aref version 1))))

(defun rcd-vc-increase-revision-number (version)
       (aset version 2 (1+ (aref version 2))))

(defmacro incr-version (version-part version)
  `(cond ((equal ,version-part 'major)
         (aset ,version 0 (1+ (aref ,version 0))))
        ((equal ,version-part 'minor)
         (aset ,version 1 (1+ (aref ,version 1))))
        ((equal ,version-part 'revision)
         (aset ,version 2 (1+ (aref ,version 2))))))

(defun version-string (version)
  (format "%s.%s.%s" (aref version 0) (aref version 1) (aref version 2)))

Eaxmple of usage:

(defvar my-version [0 0 0])

(rcd-vc-increase-revision-number my-version)
(version-string my-version)

(incr-version 'major my-version)
(incr-version 'minor my-version)
(incr-version 'revision my-version)
(version-string my-version)

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2021-04-03 07:41]:
> > Because it is database backed, minimum interaction with the
> > system is possible. In general, registered files are recorded in
> > the database on each kill or save of the buffer, or by single
> > key. I find it handy without any interactions.
> 
> Two different ways, each part on it's own, or as one macro. Much simpler
> than your decimal handling. I suggest to change your database scheme and
> store those as integers there too so you don't need to convert back and
> forth. Even better, skip the database and keep version number directly
> in your paper which you hopefully write in an org file ;-).

You know how version numbers may contain letters? That is why it is
string. Those which do appear as `numeric' type, I can easily "cast":

SELECT DISTINCT vc_revision::numeric FROM vc;
 vc_revision 
-------------
            
        1.23
           1
        1.19
        0.02

Then I could also use PostgreSQL mathematics to increase the `numeric'
cast:

SELECT DISTINCT trunc(vc_revision::numeric, 2) FROM vc WHERE vc_id = 6826;
 trunc 
-------
  0.50
(1 row)

rcdbusiness=# SELECT DISTINCT trunc(vc_revision::numeric + 0.01, 2) FROM vc WHERE vc_id = 6826;

 trunc 
-------
  0.51

Thus I could replace the function which I made in Emacs Lisp with
PostgreSQL combination.

These functions are insightful. I have to keep it a a note for
later. As they need to be decided by author. Maybe some intelligence
can be increased for computer to ask for a revision to be increased,
depending on the quantity of text changed.

> (defun rcd-vc-increase-major-number (version)
>   (aset version 0 (1+ (aref version 0))))
> 
> (defun rcd-vc-increase-minor-number (version)
>   (aset version 1 (1+ (aref version 1))))
> 
> (defun rcd-vc-increase-revision-number (version)
>        (aset version 2 (1+ (aref version 2))))
> 
> (defmacro incr-version (version-part version)
>   `(cond ((equal ,version-part 'major)
>          (aset ,version 0 (1+ (aref ,version 0))))
>         ((equal ,version-part 'minor)
>          (aset ,version 1 (1+ (aref ,version 1))))
>         ((equal ,version-part 'revision)
>          (aset ,version 2 (1+ (aref ,version 2))))))
> 
> (defun version-string (version)
>   (format "%s.%s.%s" (aref version 0) (aref version 1) (aref version 2)))
> 
> Eaxmple of usage:
> 
> (defvar my-version [0 0 0])
> 
> (rcd-vc-increase-revision-number my-version)
> (version-string my-version)
> 
> (incr-version 'major my-version)
> (incr-version 'minor my-version)
> (incr-version 'revision my-version)
> (version-string my-version)

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:


> results with 10.12 and not something else. Results are used for
> automated version numbers (in some cases).

Don't use floating points for version number. Use integers, One for each
number: major, minor and revision. You can either defvar them each or
use a vector or a list. You can them just simply increment the part you
need in your revision control and use (format "%s.%s.%s" major minor
revions) to print them to a string.

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2021-04-03 07:12]:
> Jean Louis <bugs@gnu.support> writes:
> 
> 
> > results with 10.12 and not something else. Results are used for
> > automated version numbers (in some cases).
> 
> Don't use floating points for version number. Use integers, One for each
> number: major, minor and revision. You can either defvar them each or
> use a vector or a list. You can them just simply increment the part you
> need in your revision control and use (format "%s.%s.%s" major minor
> revions) to print them to a string.

You mentioned one good way of defining revision versions. There is a
column in the table named `vc_revision' which is meant for author to
designate revision number. Some author may follow your advise
and enter revision version manually. Decision will not be
automatic. Somebody has to decide for major about major, minor and
revision, and is then free to enter it. Prompt may show how previous
version number looks like, and user may modify it.

Incrementing floating point is a feature for future user (who knows if
anybody), it will not increment in case of %s.%s.%s formatting.

Personally I do not need version numbers, but Emacs package needs
it. Presentation as floating point is I think, but not so sure, one of
possibilities.

My function is not quite compatible with `version-to-list'. 

(version-to-list "10.02") → (10 2)
(version-to-list "10.11") → (10 11)
(version-to-list "10.2.8") → (10 2 8)
(version-to-list "10.02.08") → (10 2 8)

I don't think automatic incrementing is necessary, it will remain just
for the one floating presentation.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Stefan Monnier]

> Personally I do not need version numbers, but Emacs package needs
> it. Presentation as floating point is I think, but not so sure, one
> of possibilities.
>
> My function is not quite compatible with `version-to-list'. 

I haven't followed what you're doing (so I have no idea if your "Emacs
packages" are ELPA packages), but I'll point out that ELPA package
version numbers *have to* be compatible with `version-to-list`.


        Stefan

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Eli Zaretskii]

> Date: Fri, 02 Apr 2021 16:42:42 +0300
> From: Jean Louis <bugs@gnu.support>
> 
> I would like to get a number increased for 0.01:
> 
> (defun rcd-vc-increase-decimal-revision-number (nn.nn)
>   (let* ((nn.nn (format "%s" nn.nn))
> 	 (nn.nn (format "%.2f" (string-to-number nn.nn)))
> 	 (nn.nn (string-to-number nn.nn)))
>     (+ nn.nn 0.01)))
> 
> But result is not what I want, as I want to get 10.13, though it is
> tiny loss:
> 
> (rcd-vc-increase-decimal-revision-number "10.12") → 10.129999999999999

Welcome to floating-point computations.  0.01 doesn't have an exact
binary representation, which is why you get what you get.

Suggested reading:

  https://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-04-02 17:03]:
> Suggested reading:
> 
>   https://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf

Thank you, I will read. From:
https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems

It seem that floating point arithmetic is killer at certain
situations, so I will just make sure not to fiddle with missiles.

Incidents

    On 25 February 1991, a loss of significance in a MIM-104 Patriot
    missile battery prevented it from intercepting an incoming Scud
    missile in Dhahran, Saudi Arabia, contributing to the death of 28
    soldiers from the U.S. Army's 14th Quartermaster Detachment.
    

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> * Eli Zaretskii <eliz@gnu.org> [2021-04-02 17:03]:
>> Suggested reading:
>> 
>>   https://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf
>
> Thank you, I will read. From:
> https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems
>
> It seem that floating point arithmetic is killer at certain
> situations, so I will just make sure not to fiddle with missiles.

So could be integers as well, these were (fortunately) not killers:

https://hownot2code.com/2016/09/02/a-space-error-370-million-for-an-integer-overflow/

https://medium.com/@jollyfish/integer-overflow-underflow-and-floating-point-imprecision-6ba869a99033

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> I would like to get a number increased for 0.01:
>
> (defun rcd-vc-increase-decimal-revision-number (nn.nn)
>   (let* ((nn.nn (format "%s" nn.nn))
> 	 (nn.nn (format "%.2f" (string-to-number nn.nn)))
> 	 (nn.nn (string-to-number nn.nn)))
>     (+ nn.nn 0.01)))
>
> But result is not what I want, as I want to get 10.13,
> though it is tiny loss:
>
> (rcd-vc-increase-decimal-revision-number "10.12") ; 10.129999999999999

Indeed, good question...

It is a binary thing, how floats are implemented.

Conventional wisdom is, it doesn't matter, don't worry
about it.

In your case, if you want a version number that is
MAJOR.MINOR.PATCH what you can do is have them integer
integer integer and then a separate function to output them

  (format "%d.%d.%d" major minor patch)

I prefer to use the time of change for versions, but that's
just me - and what a horrible world it would be, if everyone
was the same - and for larger/join projects it should/could
be extended, but still, check out:

  https://dataswamp.org/~incal/emacs-init/time-insert.el

-- 
underground experts united
https://dataswamp.org/~incal

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-04-16 23:42]> > (rcd-vc-increase-decimal-revision-number "10.12") ; 10.129999999999999
> 
> Indeed, good question...
> 
> It is a binary thing, how floats are implemented.

That is solved, it increases now, but that is just one way for
versioning. We do not know if it will be versioning for Emacs Lisp, it
just small feature, insignificant. I rather think of changing also the
Version: line inside of Emacs Lisp automatically with the update.

> In your case, if you want a version number that is
> MAJOR.MINOR.PATCH what you can do is have them integer
> integer integer and then a separate function to output them
> 
>   (format "%d.%d.%d" major minor patch)

Not that I personally want it at this moment.

> I prefer to use the time of change for versions, but that's
> just me - and what a horrible world it would be, if everyone
> was the same - and for larger/join projects it should/could
> be extended, but still, check out:

You see, I have that, for now new versions of a file are stored in a
database, and the database table has its column named
`vc_datemodified', more important there is also the automated unique
ID or sequence in the database that always increases. It just does not
have adjacent order, but has increasing order of numbers.

The completion candidates then look as this:

Click on a completion to select it.
In this buffer, type RET to select the completion near point.

Possible completions are:
/home/data1/protected/Programming/emacs-lisp/rcd-cf.el ID: 06899 [6899]
/home/data1/protected/Programming/emacs-lisp/rcd-cf.el ID: 06900 [6900]
/home/data1/protected/Programming/emacs-lisp/rcd-cf.el ID: 06909 [6909]
/home/data1/protected/Programming/emacs-lisp/rcd-cf.el ID: 06913 [6913]

The ID is enough, but it is possible to list completion candidates by
date, it would be trivial to get that function. SQL is helping in many
ways.

What I would like now to do as next is finding the previous revisions
of particular function by its name no matter where it is located in a
file. I would find that useful. Interaction would be to just press a
key and get previous versions of the same function for comparison.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://stallmansupport.org/
https://rms-support-letter.github.io/

Re: What is 0.01 here not 0.01 here 0.009999999999999?

[Eric S Fraga]

On Friday, 16 Apr 2021 at 22:41, Emanuel Berg wrote:
> I prefer to use the time of change for versions, but that's
> just me - and what a horrible world it would be, if everyone
> was the same - and for larger/join projects it should/could
> be extended, but still, check out:

time-stamp.el (comes with Emacs) works very well for this.

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.4.4 on Debian bullseye/sid