freenode/#lisp - IRC Chatlog
Search
3:52:38
Zhivago
Above, you are printing one edge of that interval at some precision and assuming that it corresponds with the identity of the inteval, which is not true.
3:59:11
pierpa
try (decode-float 0.00002), (decode-float 0.00003), etc, then check references to understand what the results mean.
4:15:37
beach
fourroot: It is not that floating-point arithmetic is inexact. It isn't. At least not with IEEE floating point numbers. But, for a decimal fraction like the ones you give as examples, there is no exact binary floating point value for them, so you typically get the closest available one.
5:19:38
stacksmith
Your question makes no sense. '(+ 2 2) is a list. You could compile it, make a function, and run it - is that what you mean?
5:22:43
Digit
hi. (presumably) quick question, why does (- 9000 (* (round 9000 100) 99.99)) return 0.9003906, instead of just 0.9? ( same behaviour with s/round/floor|truncate|ceiling/ ) ~ poking around in ghci (which i'm similarly incompetent in), and i get the likes of "9000-8999.1" giving 0.8999999999996362. !? why's this madness not corrected? or is it correct, and i'm the one who's gone mad? srsly tho, there's a word for this, right? (to
5:23:59
stacksmith
floats don't always have an exact representation, so you get the nearest one. It is not a Lisp issue.
5:30:31
beach
It is interesting that people discover this problem only when they start using Common Lisp, having used floating point numbers with other languages for many years, without knowing how they work. This is very scary to me, because who knows how many professional developers have made software that is relied upon, but that is buggy?
5:33:02
beach
Most people never get to use Common Lisp, so they never discover the problem like this.
5:34:25
beach
My point is that people seem not to notice those problems with other languages, presumably because of the way those numbers are printed, with a limited precision.
5:35:19
beach
So, while, as I pointed out, the problems exists everywhere, it goes unnoticed even by professional developers using floating-point numbers in the software they write.
5:46:15
aeth
Other languages tend to default to double-float instead of single-float. The issues with floating point are more obvious in single-float.
5:49:24
aeth
(Combine that *with* rounding when printing, of course. The example still fails with double float, just more decimal points down.)
6:20:28
aeth
If you think in terms of counting cells: | 1 | 2 | 3 | 4 | 5 | (first, second, third, etc.), but if you think in terms of *offsets* from the start: | 0 | 1 | 2 | 3 | 4 | (i.e. add 0 to get to the first one, add 1 to get to the second, etc.)
6:22:19
Zhivago
Now imagine that you're transforming from two dimensional to one dimensional coordinates.
6:41:26
aeth
To translate what I think the article is saying into CL terms, compare the 1-based (let ((end 10)) (loop for i from 1 to end collect i)) to the 0-based (let ((end 10)) (loop for i from 0 below end collect i)) and they seem fairly equivalent, but how do you get an empty one? You set end to 0. Going "from 0 below 0" seems more intuitive than going "from 1 to 0".
6:44:50
aeth
i.e. dealing with the range "start <= i < end" instead of "start <= i <= end" makes more sense when it's empty
6:48:56
stylewarning
beach: The other 1/2 hopefully I'll be granted an additional evening to add to. :)
6:55:11
Zhivago
Just describe the end of the range in terms of the start of the following partition -- e.g., 1~3 contains 1 and 2. Now 1~1 contains nothing.
7:07:44
krwq
trying to define following c function with cffi: int utimens(const char *, const struct timespec tv[2]); - I've tried defining tv[2] as a struct with two fields but defcfun doesn't let me use (:struct mytype) as a type
7:09:12
phoe
krwq: I am not *too* sure but I remember this might be a CFFI limitation that doesn't let you address struct arrays directly but only indirectly via a pointer.
7:10:21
krwq
phoe: do you think splitting args in some way would be equivalent? what i mean that they end up on the stack either way - I'd rather avoid such hacks but on the other hand don't want to write C-wrapper for that
7:11:13
phoe
krwq: I'd avoid hacks completely when interacting with the C layer. But that's just my paranoia.
7:12:48
stylewarning
krwq: fwiw, there's this: https://www.quicklisp.org/beta/UNOFFICIAL/docs/fsbv/doc/index.html
7:13:17
stylewarning
I think it was merged into CFFI. I ran into it when trying to deal with complex numbers.
7:13:35
flip214
fourroot1: Dijkstra's article explains it, http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF
7:46:23
krwq
actually seems like c passes foo[2] as a pointer and not as sizeof(foo) * 2 bytes which makes it easier in my case
8:13:55
leedleLoo
Hi, I was wondering how read-line is buffered. When the read-line function is called, is only one line read from the stream, or are potentially multiple lines read and stored (up to 4096 bytes, for example)?
8:19:17
krwq
p_l: i see that now - I previously thought that when you have fixed size arrays they are treated as large struct (n*sizeof(struct)) but seems that's not the case
8:20:30
jackdaniel
leedleLoo: if you are interested in bigger reads, take a look at library alexandria
8:24:00
leedleLoo
jackdaniel: Thanks, that function is actually similar to what I was going to do: use read-sequence and then pass into read-line
8:29:04
leedleLoo
krwq: To define an array of structs, I think you'll have to pass in a pointer and the number of elements in that pointer: int utimens(const char *c, const struct timespec *tv, int n)
8:29:52
krwq
leedleLoo: that's what I did already, I didn't realize that C was passing pointers for fixed-size arrays
8:43:07
jackdaniel
if you hadn't left I'd tell you, that usually you may pass array as a pointer and vice versa, but it is not conforming C code
9:10:53
dim
I think they call it “flexibility”, used to say it's a very good portability feature of the standard, all those non-conforming areas, and now they brag about optimisation opportunities
9:14:49
flip214
dim: only if you use(d) something you can really discuss pro and contra. Else you're just repeating hear-say.
9:20:33
rme
I was making a joke by alluding to an old paper Brian Kernighan wrote, titled "Why Pascal is not my favorite programming language".
9:26:25
dim
and I picked the “not my favorite” phrase because I knew it was charged with some history, only I don't know nearly enough about it
11:03:45
borodust
Xach: sorry for bothering: a couple of libraries are fail to build for a few days straight because the system i mentioned later in a comment is still not added. Are there any problems with this particular system (`cl-muth`)?
11:04:23
borodust
Xach: link to the failing build: http://report.quicklisp.org/2018-02-26/failure-report/cl-flow.html#cl-flow_tests
11:05:01
borodust
Xach: link to the comment https://github.com/quicklisp/quicklisp-projects/issues/1445#issuecomment-367437114
11:16:03
pjb
jackdaniel: read-line doesn't always read a line: when it reaches end-of-file, it may read a partial-line (a line without a newline), or nothing, returning the eof-value.
11:16:56
pjb
Very few CL functions are specified to always return something! (In general, they can make non-local exits, in case of errors or otherwise).
11:17:46
jackdaniel
reads as in "performs read, which may fail or whatever, but it doesn't try to read a character, or to read multiple number of lines". given context I think that above answer was perfectly fine
11:18:22
jackdaniel
without adding, that if you put integer in place of a function it will signal an error. if you put vector in place of a list it will signal an error. etc
11:19:14
pjb
Yes, but I would like programmers to be more unbiased vs. the various possibilities. We have to take into account all the cases.
11:20:30
jackdaniel
pjb: mentioning all the cases (including irrevelant ones) just clouds the message and makes it not understandable, so I strongly disagree
11:21:34
loke
I like checked exceptions, and I feel that cases where they programmer is not in control _should_ be documented. I.e. READ failing is something the developer always have to take into consideration. There is no way you can program in such a way as to not have to deal with it.
11:21:45
jackdaniel
you do not consider the very special case of explaning things: the reason why you do explain
11:36:43
pjb
unix (and then posix) is not civilised. Multics tried to. But unix recognized that there were "The facts of life."