I'm just starting to learn Lisp and was wondering how to display a rational as a decimal number with lots of digits.
If I use (float x), where x is a rational then it displays about 8 digits or so. But I want to display hundreds of digits.
You will have to implement an algorithm to basically do the long division and calculate the digits yourself. There is no native datatype capable of holding hundreds of decimal digits.
You can use CLISP, an implementation of Common Lisp. As an extension it provides floats with settable precision. See: http://clisp.cons.org/beta/impnotes/num-concepts.html#lfd
There are also systems like Maxima and Axiom that run on top of Common Lisp. These also can compute with high precision reals.
The Common Lisp standard though doesn't provide that.
There may be implementations on which (format nil "~,100F" x) does what you want. But on most this first converts to a float, then computes digits, which loses precision.
It's not too hard to program your own. The idea is to compute the parts before and after the decimal point as integers separately. Here's my proposal:
(defun number->string-with-fixed-decimal-places (x width &optional stream)
"Print an approximation of <x> with <width> digits after the decimal point."
(multiple-value-bind (int dec) (truncate x)
(let ((dec-shifted (truncate (* (abs dec) (expt 10 width)))))
(format stream "~d.~v,vd" int width #\0 dec-shifted))))
Related
I am working on a Scheme program, where I need at some place a pair of a floatingpoint counter and the same counter as formated string. I am having issues with the number to string conversion.
Can someone explain me these inaccuracies in this code ?
(letrec ((ground-loop (lambda (times count step)
(if (= times 250)
(begin
(display "exit")
(newline)
)
(begin
(display (* times step)) (newline)
(display (number->string (* times step)))(newline)
(newline)
(newline)
(ground-loop (+ times 1) (* times step) step)
)
)
)
))
(ground-loop 0 0 0.05)
)
Part of the output looks like that
7.25
7.25
7.3
7.300000000000001
7.35
7.350000000000001
7.4
7.4
7.45
7.45
7.5
7.5
7.55
7.550000000000001
7.6
7.600000000000001
7.65
7.65
I am aware of floating point inaccuracies and tried several forms of increasing the counter but the issue is in the conversion itself.
Any ideas for an easy fix? Tried a bit with explicitly rounded numbers but this did not do the job. The results even vary from IDE and environment to environment. Do I really have to do string manipulation after conversion?
The very weird thing in my case is having an exact numeric result but the string is off.
Thank you
It looks to me as if:
the native float type (the type you get by reading 1.0) of your implementation is IEEE double float;
the display of your Scheme is not printing such floats 'correctly' (see below, I'm no sure this means it's buggy);
your number->string is doing the right thing.
By 'correctly' above I mean 'in a way so that reading what display printed returns an equivalent number'. I am not at all sure that display is required to be correct in this restrictive sense however, so I am not sure whether it's a bug. Someone who understands the Scheme standards better than I do might be able to comment on that.
In particular if the native float type of the languageis an IEEE double float, then, for instance:
(= (* 0.05 3) 0.15)
is false, as is
(= (* 0.05 146) 7.3)
Which is the example you have in the first line of your output.
So you certainly should not assume that your program will ever produce a number equal to the number you get by reading 7.3 for instance, because it won't.
In the above I have carefully avoided printing the numbers out, and that's because I'm not sure display is reliable on this, and in particular I'm not sure your display is reliable or that it is required to be.
Well, I have a Lisp implementation to hand which is reliable about this. In this system the default float format is a single-precision IEEE float, and I can get the reader to read double floats with, for instance 1.0d0. So, in this implementation you can see the results:
> (* 0.05d0 3)
0.15000000000000002D0
> (* 0.05d0 146)
7.300000000000001D0
And you'll see that these are exactly (up to the double-precision indicator) what number->string is giving you and not what display is giving you.
If what you want to do is to get a representation of the number in such a way that reading it will return an equivalent number, then number->string is what you should trust. In particular R5RS says in section 6.2.6 that:
(let ((number number)
(radix radix))
(eqv? number
(string->number (number->string number
radix)
radix)))
is true, and 'it is an error if no possible result makes this expression true'.
You can check the behaviour of number->float & float->number over a range of numbers by, for instance (this may assume a more recent or featurefull Scheme than you have):
(define (verify-float-conversion base times)
(define (good? f)
(eqv? (string->number (number->string f)) f))
(let loop ([i 0]
[bads '()])
(let ([c (* base i)])
(if (>= i times)
(values (null? bads) (reverse bads))
(loop (+ i 1) (if (good? c) bads (cons c bads)))))))
Then you should get
> (verify-float-conversion 0.05 10000)
#t
()
More generally using floats, still more floats that are the result of some computation more complicated than reading them some input source, as unique indices into any kind of tabular structure is fraught with danger to put it rather mildly: floating-point errors mean that it's just really dangerous to assume that (= a b) is true for floats even when it mathematically should be.
If you want such indices do exact arithmetic instead, and convert the results of that arithmetic to floats at the point you need to do computations. I believe (but am not sure) that Scheme implementations are nowadays required to support exact rational arithmetic (certainly this seems to be true for R6RS), so if you want to count 20ths (say) you can do so by counting in units of 1/20, which is exact, and then constructing floats when you need them.
It's probably safe to compare floats in the case that if you are for instance comparing a float you got by taking some initial float value and multiplying it by a machine integer and comparing it with some earlier version of itself which you have read by string->number. But if the calculation your doing is more complicated than that you need to be quite careful.
Section 4.7.2 of the MIT/GNU Scheme Reference Manual states that
The IEEE floating-point number specification supports three special ‘numbers’: positive infinity (+inf), negative infinity (-inf), and not-a-number (NaN).
These constants, in addition to being well-defined IEEE floating-point values, are also useful for range arithmetic. However, I’m unable to use them in my programs:
1 ]=> +inf
;Unbound variable: +inf
Generating these values isn’t easy, either: expressions which seem like they ought to evaluate to floating-point infinities simply don’t:
1 ]=> (flo:/ 1. 0.)
;Floating-point division by zero
How can I input or generate infinite floating-point constants in MIT Scheme?
tests/runtime/test-arith.scm suggests using flo:with-exceptions-untrapped:
;;; XXX The nonsense about IDENTITY-PROCEDURE here serves to fake
;;; out bogus constant-folding which needs to be fixed in SF (and
;;; probably LIAR too).
(define (zero)
(identity-procedure 0.))
(define (nan)
(flo:with-exceptions-untrapped (flo:exception:invalid-operation)
(lambda ()
(flo:/ (zero) (zero)))))
(define (inf+)
(flo:with-exceptions-untrapped (flo:exception:divide-by-zero)
(lambda ()
(flo:/ +1. (zero)))))
(define (inf-)
(flo:with-exceptions-untrapped (flo:exception:divide-by-zero)
(lambda ()
(flo:/ -1. (zero)))))
The results display as #[NaN], #[+inf], #[-inf] but cannot be input that way.
I am reading a Gentle Introduction to Symbolic Computation and it asks this question. Basically, the previous content deals with making up bigger functions with small ones. (Like 2- will be made of two 1- (decrement operators for lisp))
So one of the questions is what are the two different ways to define a function HALF which returns one half of its input. I have been able to come up with the obvious one (dividing number by 2) but then get stuck. I was thinking of subtracting HALF of the number from itself to get half but then the first half also has to be calculated...(I don't think the author intended to introduce recursion so soon in the book, so I am most probably wrong).
So my question is what is the other way? And are there only two ways?
EDIT : Example HALF(5) gives 2.5
P.S - the book deals with teaching LISP of which I know nothing about but apparently has a specific bent towards using smaller blocks to build bigger ones, so please try to answer using that approach.
P.P.S - I found this so far, but it is on a completely different topic - How to define that float is half of the number?
Pdf of book available here - http://www.cs.cmu.edu/~dst/LispBook/book.pdf (ctrl+f "two different ways")
It's seems to be you are describing peano arithmetic. In practice it works the same way as doing computation with fluids using cups and buckets.
You add by taking cups from the source(s) to a target bucket until the source(s) is empty. Multiplication and division is just advanced adding and substraction. To halve you take from source to two buckets in alterations until the source is empty. Of course this will either do ceil or floor depending on what bucket you choose to use as answer.
(defun halve (x)
;; make an auxillary procedure to do the job
(labels ((loop (x even acc)
(if (zerop x)
(if even (+ acc 0.5) acc)
(loop (- x 1) (not even) (if even (+ acc 1) acc)))))
;; use the auxillary procedure
(loop x nil 0)))
Originally i provided a Scheme version (since you just tagged lisp)
(define (halve x)
(let loop ((x x) (even #f) (acc 0))
(if (zero? x)
(if even (+ acc 0.5) acc)
(loop (- x 1) (not even) (if even (+ acc 1) acc)))))
Edit: Okay, lets see if I can describe this step by step. I'll break the function into multiple lines also.
(defun half (n)
;Takes integer n, returns half of n
(+
(ash n -1) ;Line A
(if (= (mod n 2) 1) .5 0))) ;Line B
So this whole function is an addition problem. It is simply adding two numbers, but to calculate the values of those two numbers requires additional function calls within the "+" function.
Line A: This performs a bit-shift on n. The -1 tells the function to shift n to the right one bit. To explain this we'll have to look at bit strings.
Suppose we have the number 8, represented in binary. Then we shift it one to the right.
1000| --> 100|0
The vertical bar is the end of the number. When we shift one to the right, the rightmost bit pops off and is not part of the number, leaving us with 100. This is the binary for 4.
We get the same value, however if we perform the shift on nine:
1001| --> 100|1
Once, again we get the value 4. We can see from this example that bit-shifting truncates the value and we need some way to account for the lost .5 on odd numbers, which is where Line B comes in.
Line B: First this line tests to see if n is even or odd. It does this by using the modulus operation, which returns the remainder of a division problem. In our case, the function call is (mod n 2), which returns the remainder of n divided by 2. If n is even, this will return 0, if it is odd, it will return 1.
Something that might be tripping you up is the lisp "=" function. It takes a conditional as its first parameter. The next parameter is the value the "=" function returns if the conditional is true, and the final parameter is what to return if the conditional is false.
So, in this case, we test to see if (mod n 2) is equal to one, which means we are testing to see if n is odd. If it is odd, we add .5 to our value from Line A, if it is not odd, we add nothing (0) to our value from Line A.
I eval a lisp expression in scratch
(+ (/ 1 2) (/ 1 2))
I got a 0.
normally it should be 1.
As Oleg points out, operators usually default to integer arithmetic unless you include floating point arguments (like 1.0).
With respect to your question about rational number support, emacs-calc (which is part of emacs) supports many number types including fractions (i.e. rational numbers), complex numbers, infinite precision integers, etc. Your code must call emacs-calc functions (instead of /, etc.) in order to use calc's arithmetic.
GNU Emacs Calc Manual:
Fractions
Index of Lisp Math Functions
Try this way
(+ (/ 1.0 2) (/ 1.0 2))
According to emacs doc
Function: / dividend divisor &rest divisors
if all the arguments are integers, then the result is an integer too.
You can read all about numbers in elisp here:
C-hig (elisp) Numbers RET
As already indicated by tripleee, it is apparent that the answer is "no".
Emacs calc has rational data type: use colon, like 1:2 == 0.5 or 5:3 == 1 + 2:3 == 1:2:3.
This way Emacs calc simplifies expressions, for example if you deal with display resolutions for 1920:1080 it prints 16:9! If you want 1440p with the 16:9 ratio: 1440 * 16:9 ⇒ 2560.
I'm looking for the standard way to represent negative infinity in Lisp. Is there a symblic value which is recognised by Lisp's arithmetic functions as less than all other numbers?
Specifically, I'm looking for an elegant way to write the following:
(defun largest (lst)
"Evaluates to the largest number in lst"
(if (null lst)
***negative-inifinity***
(max (car lst) (largest (cdr lst)))))
ANSI Common Lisp has bignum, which can used to represent arbitrarily large numbers as long as you have enough space, but it doesn't specify an "infinity" value. Some implementations may, but that's not part of the standard.
In your case, I think you've got to rethink your approach based on the purpose of your function: finding the largest number in a list. Trying to find the largest number in an empty list is invalid/nonsense, though, so you want to provide for that case. So you can define a precondition, and if it's not met, return nil or raise an error. Which in fact is what the built-in function max does.
(apply #'max '(1 2 3 4)) => 4
(apply #'max nil) => error
EDIT: As pointed by Rainer Joswig, Common Lisp doesn't allow arbitrarily long argument lists, thus it is best to use reduce instead of apply.
(reduce #'max '(1 2 3 4))
There is nothing like that in ANSI Common Lisp. Common Lisp implementations (and even math applications) differ in their representation of negative infinity.
For example in LispWorks for double floats:
CL-USER 23 > (* MOST-NEGATIVE-DOUBLE-FLOAT 10)
-1D++0