
12

Hello,
Is it possible to show results of the calculator (Mx calculator)
without the exponent but instead the full number with all digits ?
Cheers.


jonetsu wrote:
> Is it possible to show results of the
> calculator (Mx calculator) without the
> exponent but instead the full number with all
> digits ?
I don't think so from browsing the variables,
but I might be wrong, so I CC this to
Eli Barzilay who wrote it  see the source [1]
for his email.
He wrote it way back in 1998 tho
(20y 11m 20d (7659d) ago if we assume
19980615) ...
[1] /usr/share/emacs/25.1/lisp/calculator.el.gz

underground experts united
http://user.it.uu.se/~embe8573https://dataswamp.org/~incal


On 20190604, at 21:43, jonetsu < [hidden email]> wrote:
> Hello,
>
> Is it possible to show results of the calculator (Mx calculator)
> without the exponent but instead the full number with all digits ?
Is using calc possible in your usecase? If yes, that would probably
help a lot.
Hth,

Marcin Borkowski
http://mbork.pl


Marcin Borkowski wrote:
>> Is it possible to show results of the
>> calculator (Mx calculator) without the
>> exponent but instead the full number with
>> all digits ?
>
> Is using calc possible in your usecase?
> If yes, that would probably help a lot.
Or use Lisp, create a file and just type Lisp.
With `format', you can get the result look
anyway you want.

underground experts united
http://user.it.uu.se/~embe8573https://dataswamp.org/~incal


In reply to this post by Emacs  Help mailing list
> I don't think so from browsing the variables,
> but I might be wrong, so I CC this to Eli
> Barzilay [...]
I got an answer to my private mail! I don't
know if it reached the list tho. Anyway here it
is:
++ Is it possible to show results of the
++ calculator (Mx calculator) without the
++ exponent but instead the full number
++ with all digits ?
+
+ I don't think so from browsing the
+ variables, but I might be wrong, so I CC
+ this to Eli Barzilay who wrote it  see
+ the source [...] for his email.
I dug into the code, and there's
a hardwired 1e8 there which makes it
decide to use `format` with "%e" instead of
"%f". I obviously don't remember why
I hardwired it without making it
customizable (maybe it made more sense in
a 32bit world), so a cheap way to make it
possible is to turn it into a variable.
A better way would be to make it
interactively changeable.
BTW, without any modifications, you can hit
' (quote) until it says that it's using the
Emacs printer, and that will do what Emacs
does. (Again, that's obviously different
now than what it did 20y ago.)
(Yet another possibility is to set
`calculatorcopydisplayer` to "%S" so when
you copy values out you get whatever
Emacs does.)
+ He wrote it way back in 1998 tho (20y 11m
+ 20d (7659d) ago if we assume 19980615)
+ ...
Actually, I wrote it about 12 years before
I thought it could be useful publicly...

underground experts united
http://user.it.uu.se/~embe8573https://dataswamp.org/~incal


On Wed, 05 Jun 2019 06:11:28 +0200
Marcin Borkowski < [hidden email]> wrote:
> Is using calc possible in your usecase? If yes, that would probably
> help a lot.
Thanks. I have totally forgotten about calc. I'm used to calculator
somehow. calc does exactly what I need.
In that light, it might not be worthwhile to modify calculator when
calc already offers additional formats and features. My question was
misguided by having forgotten about calc.
Emmanuel Berg: "Or use Lisp, create a file and just type Lisp.
With `format', you can get the result look anyway you want."
I must say that I do not know anything about Lisp and I don't consider
that modifying a .emacs file is any knowledge of Lisp. Maybe one
day ... Just saw a presentation yesterday about a compiler for quantum
processors written in Lisp, quil.
Cheers.


jonetsu wrote:
> Emmanuel Berg: "Or use Lisp, create a file
> and just type Lisp. With `format', you can
> get the result look anyway you want."
>
> I must say that I do not know anything about
> Lisp [...]
If you want to do math with Lisp, it is much
better to be good with math and bad at Lisp,
than the other way around.
Because it is very easy. Just understand the
"fully parenthesized prefix notation" [1] and
that will be it.
So, the operator comes first:
(+ 1 2 3 4) ; is 1 + 2 + 3 + 4 = 10
And, the priority of operators is never an
issue as _everything_ is parenthesized.
That's it!
For more advanced math, you'll probably need to
find a math library with additional operators
and constants, perhaps in on of the
[M]ELPA packs, but for the basic stuff, it is
as simple as it can be.
Here, have a look:
(defun hypotenuse (c1 c2)
(sqrt (+ (* c1 c1) (* c2 c2))) )
or, a little bit more advanced, involving
a list and a set function:
(defun meanvalue (vs)
(let*((sum (apply #'+ vs))
(mean (/ sum (length vs) 1.0)) )
mean) ) ; [2]
Eval me: (meanvalue '(1 2 3 4 5.5)) ; 3.1
One of the advantages with this Lispfile
method is that you have every data item in the
file. Nothing gets lost in the history of the
calculator, and what you have you can change
and instantly have the whole thing
computed anew.
[1] https://en.wikipedia.org/wiki/Lisp_(programming_language)
[2] https://dataswamp.org/~incal/emacsinit/mymath.el
underground experts united
http://user.it.uu.se/~embe8573https://dataswamp.org/~incal


Emanuel Berg via helpgnuemacs < [hidden email]> writes:
> jonetsu wrote:
>
>> Emmanuel Berg: "Or use Lisp, create a file
>> and just type Lisp. With `format', you can
>> get the result look anyway you want."
>>
>> I must say that I do not know anything about
>> Lisp [...]
>
> If you want to do math with Lisp, it is much
> better to be good with math and bad at Lisp,
> than the other way around.
>
> Because it is very easy. Just understand the
> "fully parenthesized prefix notation" [1] and
> that will be it.
>
> So, the operator comes first:
> (+ 1 2 3 4) ; is 1 + 2 + 3 + 4 = 10
>
> And, the priority of operators is never an
> issue as _everything_ is parenthesized.
>
> That's it!
>
> For more advanced math, you'll probably need to
> find a math library with additional operators
> and constants, perhaps in on of the
> [M]ELPA packs, but for the basic stuff, it is
> as simple as it can be.
>
> Here, have a look:
>
>
> (defun hypotenuse (c1 c2)
> (sqrt (+ (* c1 c1) (* c2 c2))) )
>
>
> or, a little bit more advanced, involving
> a list and a set function:
>
>
> (defun meanvalue (vs)
> (let*((sum (apply #'+ vs))
> (mean (/ sum (length vs) 1.0)) )
> mean) ) ; [2]
>
>
> Eval me: (meanvalue '(1 2 3 4 5.5)) ; 3.1
>
>
> One of the advantages with this Lispfile
> method is that you have every data item in the
> file. Nothing gets lost in the history of the
> calculator, and what you have you can change
> and instantly have the whole thing
> computed anew.
>
>
> [1] https://en.wikipedia.org/wiki/Lisp_(programming_language)
> [2] https://dataswamp.org/~incal/emacsinit/mymath.elI'd like to put in a plug for Dave Gillespie's calc, that's part
of emacs. Just say
Mx calc
type `h i', read the manual (as much of it as you can possibly take:
it's big) and go calculate.

Nick
"There are only two hard problems in computer science: cache
invalidation, naming things, and offbyone errors." Martin Fowler


In reply to this post by Emacs  Help mailing list
On 20190606, at 01:47, Emanuel Berg via helpgnuemacs < [hidden email]> wrote:
> (defun hypotenuse (c1 c2)
> (sqrt (+ (* c1 c1) (* c2 c2))) )
Just for the fun, let me mention that this is not a very good algorithm
for computing the Pythagorean sum  it may happen that both the operands
and the result lie within the bounds for the given type, but this
calculation blows up because of large squares overflowing. Also, it is
slow because of the need to compute square roots.
Interestingly, there exists a clever algorithm that does not have these
problems. It is used (among others) in Donald Knuth's METAFONT. The
algorithm is described in the paper (using Emanuel's favorite
format;)):
@ARTICLE{5390405,
author={C. {Moler} and D. {Morrison}},
journal={IBM Journal of Research and Development},
title={Replacing Square Roots by Pythagorean Sums},
year={1983},
volume={27},
number={6},
pages={577581},
keywords={},
doi={10.1147/rd.276.0577},
ISSN={00188646},
month={Nov},
}
Best,

Marcin Borkowski
http://mbork.pl


Marcin Borkowski wrote:
>> (defun hypotenuse (c1 c2)
>> (sqrt (+ (* c1 c1) (* c2 c2))) )
>
> Just for the fun, let me mention that this is
> not a very good algorithm for computing the
> Pythagorean sum  it may happen that both the
> operands and the result lie within the bounds
> for the given type but this calculation blows
> up because of large squares overflowing.
Well, first let it be known that Marcin is
a professional mathematician, famous for his
remarkable calculations. That said, the above
comment is on the computer side of things,
right? In the math world, what would happen is
just a very large triangle, again  right?
Assuming integers, how large can they be in
Emacs Lisp? Eval us:
mostpositivefixnum ; 536870911
"Typical values are 2**29 − 1 on 32bit and
2**61 − 1 on 64bit platforms." [1]
mostnegativefixnum ; 536870912
"Typical values are −2**29 on 32bit
and −2**61 on 64bit platforms." [1]
How do you know if your "platform"
(i.e. kernel?) is 32 or 64bit?
Tricky, but here is an incomplete guide from
the systems I have access to:
Debian Intel: uname m; i686 > 32bit, x86_64 > 64
OpenBSD: uname m; amd64 > 64 (same type as x8664 BTW)
RPi3 Raspbian: uname m; armv7l > 32
SunOS/Solaris: 'isainfo kv' tells you
Also remember that you can have 64 HW but still
a 32 Linux kernel  but probably not the other
way around :)) (?)
Otherwise you can use Emacs to find out!
mostpositivefixnum ; 536870911
then compute 2**29  1:
# /bin/zsh
$ echo $(( 2**29 − 1 ))
536870911
so yes, it checks out for my RPi3 :)
> Also, it is slow because of the need to
> compute square roots. Interestingly, there
> exists a clever algorithm that does not have
> these problems.
Why don't you post it in Elisp to prove my
point one can use Elisp for math, even advanced
math! <3
> It is used (among others) in Donald Knuth's
> METAFONT. The algorithm is described in the
> paper (using Emanuel's favorite format;)):
That's true, I frekking *love* Biblatex! [2]
> @ARTICLE{5390405,
> author={C. {Moler} and D. {Morrison}},
> journal={IBM Journal of Research and Development},
> title={Replacing Square Roots by Pythagorean Sums},
> year={1983},
> volume={27},
> number={6},
> pages={577581},
> keywords={},
> doi={10.1147/rd.276.0577},
> ISSN={00188646},
> month={Nov},
> }
Only I keep mine much neater :)
@book{landoflisp,
author = {Conrad Barski},
isbn = 1593272812,
publisher = {No Starch},
title = {Land of Lisp},
year = 2010
}
@book{lispcraft,
author = {Robert Wilensky},
isbn = 0393954420,
publisher = {Norton},
title = {LISPcraft},
year = 1984
}
%% [3]
[1] (info "(elisp) Integer Basics")
[2] https://dataswamp.org/~incal/emacsinit/mybibtex.el[3] https://dataswamp.org/~incal//books/books.bib
underground experts united
http://user.it.uu.se/~embe8573https://dataswamp.org/~incal


On Thu, Jun 06, 2019 at 06:50:55PM +0200, Emanuel Berg via helpgnuemacs wrote:
> Marcin Borkowski wrote:
>
> >> (defun hypotenuse (c1 c2)
> >> (sqrt (+ (* c1 c1) (* c2 c2))) )
> >
> > Just for the fun, let me mention that this is
> > not a very good algorithm for computing the
> > Pythagorean sum  it may happen that both the
> > operands and the result lie within the bounds
> > for the given type but this calculation blows
> > up because of large squares overflowing.
>
> Well, first let it be known that Marcin is
> a professional mathematician, famous for his
> remarkable calculations. That said, the above
> comment is on the computer side of things,
> right? In the math world, what would happen is
> just a very large triangle, again  right?
>
> Assuming integers, how large can they be in
> Emacs Lisp? Eval us:
>
> mostpositivefixnum ; 536870911
> "Typical values are 2**29 − 1 on 32bit and
> 2**61 − 1 on 64bit platforms." [1]
[...]
Newer Emacsen support bignums:
(expt 71 71) => 275006373483461607657434076627252658495183350017755660813753981774508905998081919405140568848353397233796618192645698819765129996471
That said, calc itself supports bignums since
long.
Cheers
 t


tomas wrote:
> Newer Emacsen support bignums:
>
> (expt 71 71) =>
> 275006373483461607657434076627252658495183350017755660813753981774508905998081919405140568848353397233796618192645698819765129996471
(expt 71 71) ; 141793097
> That said, calc itself supports bignums
> since long.
OK, but how could it, if Emacs didn't?

underground experts united
http://user.it.uu.se/~embe8573https://dataswamp.org/~incal


On Thu, Jun 06, 2019 at 07:11:12PM +0200, Emanuel Berg via helpgnuemacs wrote:
> tomas wrote:
>
> > Newer Emacsen support bignums:
> >
> > (expt 71 71) =>
> > 275006373483461607657434076627252658495183350017755660813753981774508905998081919405140568848353397233796618192645698819765129996471
>
> (expt 71 71) ; 141793097
>
> > That said, calc itself supports bignums
> > since long.
>
> OK, but how could it, if Emacs didn't?
Well, it can do fractions too. And symbolic expressions. Although they
arent native to elisp. Magic :)
See calc.el, especially below this comment:
;;;; Arithmetic routines.
for a beginning of a long and exciting journey.
Cheers
 t


> From: Emanuel Berg via helpgnuemacs
> Sent: 6 June, 2019 1:11 PM
>tomas wrote:
>> Newer Emacsen support bignums:
. . .
>> That said, calc itself supports bignums
>> since long.
>OK, but how could it, if Emacs didn't?
By implementing its own number representations and arithmetic library in Elisp.
From nearly 30 years ago.
See calcarith.el by David Gillespie. A _very_ impressive piece of work.
I don't understand it at all.
The content of this message is APPLIED MATERIALS CONFIDENTIAL. If you are not the intended recipient, please notify me, delete this email and do not use or distribute this email.


In reply to this post by Emacs  Help mailing list
On 20190606, at 18:50, Emanuel Berg via helpgnuemacs < [hidden email]> wrote:
> Marcin Borkowski wrote:
>
>>> (defun hypotenuse (c1 c2)
>>> (sqrt (+ (* c1 c1) (* c2 c2))) )
>>
>> Just for the fun, let me mention that this is
>> not a very good algorithm for computing the
>> Pythagorean sum  it may happen that both the
>> operands and the result lie within the bounds
>> for the given type but this calculation blows
>> up because of large squares overflowing.
>
> Well, first let it be known that Marcin is
> a professional mathematician, famous for his
Professional  maybe, famous  luckily not.
> remarkable calculations. That said, the above
> comment is on the computer side of things,
> right? In the math world, what would happen is
> just a very large triangle, again  right?
Of course. There is no overflow in maths;).
>> Also, it is slow because of the need to
>> compute square roots. Interestingly, there
>> exists a clever algorithm that does not have
>> these problems.
>
> Why don't you post it in Elisp to prove my
> point one can use Elisp for math, even advanced
> math! <3
Not enough time... Maybe in the future...
>> It is used (among others) in Donald Knuth's
>> METAFONT. The algorithm is described in the
>> paper (using Emanuel's favorite format;)):
>
> That's true, I frekking *love* Biblatex! [2]
>
>> @ARTICLE{5390405,
>> author={C. {Moler} and D. {Morrison}},
>> journal={IBM Journal of Research and Development},
>> title={Replacing Square Roots by Pythagorean Sums},
>> year={1983},
>> volume={27},
>> number={6},
>> pages={577581},
>> keywords={},
>> doi={10.1147/rd.276.0577},
>> ISSN={00188646},
>> month={Nov},
>> }
>
> Only I keep mine much neater :)
"Mine" was autogenerated by some service on the web.
Best,

Marcin Borkowski
http://mbork.pl


Marcin Borkowski < [hidden email]> writes:
> On 20190604, at 21:43, jonetsu < [hidden email]> wrote:
>
>> Is it possible to show results of the calculator (Mx calculator)
>> without the exponent but instead the full number with all digits ?
>
> Is using calc possible in your usecase? If yes, that would probably
> help a lot.
Emacs27's calc does bignum.

© 2019 Van L
gpg using EEF2 37E9 3840 0D5D 9183 251E 9830 384E 9683 B835
"you have to be Albert Einstein to figure it out"  Donald J. Trump


>>>>> On Fri, 14 Jun 2019 22:20:11 +1000, Van L < [hidden email]> said:
Van> Marcin Borkowski < [hidden email]> writes:
>> On 20190604, at 21:43, jonetsu < [hidden email]> wrote:
>>
>>> Is it possible to show results of the calculator (Mx calculator)
>>> without the exponent but instead the full number with all digits ?
>>
>> Is using calc possible in your usecase? If yes, that would probably
>> help a lot.
Van> Emacs27's calc does bignum.
Not just emacs27's, thatʼs been in there since basically
forever. emacs27 *also* has gmpbased bignums, but calc does not
(yet) use those.
Robert


> Not just emacs27's, thatʼs been in there since basically forever.
Indeed.
> emacs27 *also* has gmpbased bignums, but calc does not
> (yet) use those.
Doesn't it?
Stefan


In reply to this post by Emacs  Help mailing list
Emanuel Berg via helpgnuemacs < [hidden email]> writes:
> Van L wrote:
>
>> Emacs27's calc does bignum.
>
> Is there a paleotechnoscientific definition
> of "bignum" or is it just short for
> a big numbers?
It is a shorthand or contraction or
telescopecollapsingfold like calc is to calculation or
calculator, saving time and space.

© 2019 VanL
gpg using EEF2 37E9 3840 0D5D 9183 251E 9830 384E 9683 B835
'The mouth is the dirtiest part on the human body.'  Bill Wallace

12
