Is there any way in Racket to take the integer closest to an inexact value? For example, if I have #i13.0 as the input, I want 13 as the output. I'm not quite sure where to look for solutions. I attempted using floor but that left it as an inexact value, and a simple google search for "racket convert inexact number to exact number" didn't yield any results.
Yep, exact-round
#lang racket
(exact-round #i13.0)
;; 13
You can use round.
(round #i13.0)
Related
In my code we are using a multiplication as (180.00*60.00).
Ideally since both the numbers are of decimal type I'm expecting my answer to be also in decimal. But in redshift I observed that this equation is resulting only to Integer.
Basically when this multiplication happens I want the answer as 10800.0000 and not 10800.
how to achieve this in Redshift. I tried putting the cast to whole expression and also even to individual expression but still I'm getting the answer only in Integer.
any help here?
If I understand your question correctly you are asking why Redshift isn't inferring that the string "180.00*60.00" as being the multiplication of 2 values in decimal type, yes? If correct you just need to cast the input values for the multiplication. For example:
select 180.00::decimal(6,2) * 60.00::decimal(6,2) ;
It also looks like you want the result to have 4 significant digits so you may want to cast to decimal(8,4).
If I've missed the point of your question please clarify.
It looks like I can hack floor and ceiling into a meta function for an arbitrary round, but is there a standard way to do:
round[3.1415;2] = 3.14
from the core functions?
Edit: This is problem I'm trying to solve:
I have unadjusted daily stock data, and I'm trying to identify splits and filter them out. It's further complicated by decimalisation artefacts (a split might not be perfectly 2:1 because prices have minimum tick sizes).
This is possible via the use of .Q.f, this does however return the output as a string.
Using this we can round 3.14159 to 2 decimal places like so:
q) .Q.f[2;] 3.14
"3.14"
q)round:{"F"$.Q.f[y]x}
q)round[3.1415;2]
3.14
There's no standard way because in kdb you shouldn't ever really need to round floats. What's the reason to round floats? If it's just for pretty-printing displays then you can use a method like Matthew suggests, but underlying kdb logic shouldn't need it.
If you must, you can use floor/ceiling as you've already figured out or you can use the built-in nearest-rounding that casting to interger/long achieves. E.g.
q)d:{("j"$x*y)%x}
q)d2:d[100]
q)d3:d[1000]
q)
q)a:5?10.0
q)
q)d2 a
3.92 0.81 9.37 2.78 2.39
q)d3 a
3.915 0.812 9.368 2.782 2.392
But even here you should be aware that this is completely fictional rounding because you're still using floats and still subject to floating point fuzziness. If I increase the precision value those same results above are:
q)\P 18
q)
q)d2 a
3.9199999999999999 0.81000000000000005 9.3699999999999992 2.7799999999999998 ..
q)d3 a
3.915 0.81200000000000006 9.3680000000000003 2.782 2.3919999999999999
The only way to have a truly concrete number of decimal places is to store the whole numbers as ints/longs and separately store the decimals as ints/longs
I am working on a calculator in Swift, but I have a small problem:
when multiplying two numbers, I don't have the same results as a regular calculator.
For example:
In Swift :
0.333328247070312 * 16 = 5.33325195312499
In a regular calculator:
0.333328247070312 * 16 = 5.333251953
What should I do to get the same results as a regular calculator in Swift?
Your "regular calculator" seems wrong or weird in result printing, so, you should not rely on it. I've rechecked your calculation in Python3 which is known to calculate all in binary64 double and print the most exact decimal form:
>>> 0.333328247070312 * 16
5.333251953124992
it's even more detailed (by one digit) than Swift output. Your output also can't be verified as binary32 calculation, because the latter has ~7 correct decimal digits, and usually isn't printed with more digits. What this calculator is? I'd suppose some Pascal-based tool due to its custom 6-byte float.
Try to ask your calculator to print the most detailed form. If it fails, throw it away and use a most exact tool to verify, or, if your task is really to get the same result, figure out more details about its processing.
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 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))))