libera/commonlisp - IRC Chatlog
Search
19:55:47
lisp123
stacksmith: Thanks. An alternative I found is (do-symbols (s (find-package "my-package")) (shadowing-import (find-symbol (symbol-name s) "my-package")))
19:56:08
lisp123
(If anybody thinks thats a bad idea for importing all internal symbols, let me know)
20:11:42
_death
you could have an implementation package that exports both symbols for external use and internally used symbols that you want to refer to in your tests.. then an external interface package can use it and export only the former symbols
20:12:32
lisp123
_death: Thank you!! That is genius (and solves a problem I was facing with a brute force shadowing-import)
20:14:07
White_Flame
personally, I think it's reasonable for tests to invasively use foo::bar to get at the internals of what it's testing
20:15:36
lisp123
White_Flame: Yeah, I have the same view. And I got tired of typing foo:: for every test
20:15:37
_death
I think it's ok (and not just for testing, as long as you've control of both ends), but may get a bit verbose
20:33:59
Nilby
It turns out I mostly test the external interface, but if not, it's foo:: and the essential multiple-cursors!
20:35:46
shka
lisp123: i write my tests in the same package and i think that this is fine, but you gonna need separate asdf system for tests
20:36:57
lisp123
shka: Thanks, yes I have that. I've ended up keeping the test package separate and doing the above trick to import all the symbols into it
20:37:19
_death
Nilby: indeed.. I often use package inferred systems style, so I can test functionality of internal modules since they export their symbols as external interface for internal use
20:39:18
_death
Nilby: but I did use foo::bar recently, as I have a module for visualization that needs to specialize on some classes and obtain information from their instances, and I didn't want to export those symbols
20:40:07
stacksmith
I try to keep things separate, but when it takes too much effort I remind myself that it is likely that no one else will ever see the crap I am making.
20:43:56
_death
they work very well for some (most) of my use cases.. though I did have one or two projects where a more coarse approach would've been better
20:49:38
Nilby
Many package and systems 1-to-1, but some package and systems relationship status has to be: "It's complicated."
21:31:13
kagevf
it was here: https://tfeb.github.io/ look under "Conduit packages for Common Lisp" .... might be useful for handling packages
21:38:14
papertanuki
Hi everyone! I have a quick CFFI question that I could't find on the documentation.
21:39:11
papertanuki
How do you translate a C struct that contains an array (really a pointer, and a counter) of other structs?
21:41:44
Bike
if you have a defcstruct for BoneInfo or whatnot, you can specify (:pointer bone-info) if you want, but i think cffi ignores the underlying types of pointers
21:45:37
papertanuki
So when translating using `translate-from-foreign`, is there a way to get all of the bones in a lisp array?
21:56:02
Nilby
papertanuki: You can use mem-aref in a loop on "bones" and then with-foreign-slots or foreign-slot-value of the struct pointer get the data out. The CFFI manual has decent examples.
0:06:30
jasom
papertanuki: FWIW Model doesnt' contain an array, only pointers (the two are not always the same in C).
0:22:33
papertanuki
jasom: I know, but in this case Model has "dynamic arrays" in the sense that it stores the length and the pointer to the start of the array.
2:59:27
jeosol
I am not sure how updated the github one is. But last time, I had to clone from the gitlab repo
4:08:40
opcode
anyone here familiar with the parse-float library? I'm hitting what I assume is an IEEE 754 bug, where the string "8.78" parses to 8.7799997, but the string "9.78" parses correctly to the number 9.78. I'm on SBCL 2.1.9 on MacOS
4:10:50
White_Flame
in sbcl linux x64, with read-default-float-format as single, I get that discrepancy. With it as double-float, it prints 7.78
4:10:51
opcode
beach: I would assume that a string-to-number parsing library should faithfully reproduce the number represented in the string
4:12:03
White_Flame
obviously, typing in 7.78 at the repl parses it as a single-float and prints it in the same 7.78 representation, so it's not a ieee 754 problem
4:12:30
beach
opcode: I haven't checked this particular case, but floats are not represented in decimal, so it is entirely possible that there is not an exact decimal representation for the input you are giving.
4:13:12
White_Flame
parse-float has a COERCE operation into the returned type, which is probably where the imprecision lies
4:13:27
opcode
look beach I can't tell if you're just trying to be irritating but I think you know what I meant. If you feed a parsing library a string with a number, it should give you that number. Not a different number. Unless you're suggesting SBCL can't represent the number "7.78"
4:14:02
opcode
White_Flame: thanks for actually helping, I was not aware of the read-default-float-format variable
4:14:35
beach
opcode: That's exactly what I am suggesting. Did you check that your input has an exact representation in IEEE?
4:14:45
beach
opcode: http://pages.cs.wisc.edu/~david/courses/cs552/S12/handouts/goldberg-floating-point.pdf
4:15:12
White_Flame
however, most FP systems try to ensure that the rounding involved makes the read input match the output print
4:15:59
opcode
but my point is that the result I get from the parse operation should be 7.78 because that's the string I fed in
4:17:02
opcode
beach: I don't know who you are but you've been profoundly unhelpful so I'm going to add you to ignore. Go troll someone else.
4:23:18
White_Flame
SBCL's reader appears to keep it as perfect rational, then coerces it into the final format
4:27:37
White_Flame
and COERCE goes through a lot of detail in the fp construction, with biases and whatnot, which matches its printer
4:31:45
opcode
I set read-default-float-format to 'double-float but it's still outputting the wrong number. Interestingly read-from-string does it correctly irrespective of float format
4:33:35
White_Flame
I don't think you're using the right terms in the right places, hence beach's objections
4:34:44
opcode
I'm well aware of the limitations of representing infinitely many numbers in a finite number of binary digits
4:35:14
beach
I think opcode had better adjust those expectations, but since I am being ignored, it doesn't matter much what I think.
4:35:53
White_Flame
different implementations' floating point storage (which might change with tagging strategies) and their printers could vary. Which one is "right"?
4:36:30
opcode
I don't think it's an extreme position to suggest that the "right" result is the one that common sense would indicate is correct
4:38:35
White_Flame
and again, 3rd party reader + 3 different implementations' printers, which should it match?
4:39:38
White_Flame
but even if it did, it doesn't know the implementation representation. It's only using toplevel math functions, not anything to do with the actual bit representation, as the implementation would do in its platform specific code
4:40:20
White_Flame
now, there's lots of work out there in terms of carefully matchign input to output, if you control both ends, but I'm not sure if those have a singular solution
4:43:42
opcode
Well, I have the most experience in C#/dotnet and in that ecosystem Double.Parse() will give you consistent results across the two platforms I've had time to try while we've been debating this
4:45:20
opcode
right but again, and this is just me personally, if I released a library that dealt with implementation-specific code and there was divergent behavior, irrespective of whether it's sockets or floats or what have you, I'd still consider that a bug
4:45:53
White_Flame
but this falls within reasonable realms of floating point issues, again because it's not targetting (and cannot target) a specific storage precision & printer
4:46:00
opcode
so when I came here asking about it, to be met with smug superiority from beach, it really rubs me the wrong way you know?
4:48:06
opcode
cmon man. 7.78 is not the same number (in the mathematical sense, not the binary representation sense) as 7.7799997
4:50:02
White_Flame
and as a library, as it really can't technically be done as such, has precision decisions that the printer doesn't expect
4:51:51
White_Flame
but still, this is veering really off topic for a pretty strictly on topic channel
5:18:31
beach
White_Flame: Since I am ignored, I can say that I don't think opcode was requesting matching input and output functions. I just think that opcode thinks that the input number has an exact representation in floating point and expect that exact representation to be output.
5:47:16
beach
If I am doing this right, the SBCL reader turns 7.78 into a number that is greater than 778/100, and I think SBCL has a good input algorithm, i.e. it creates the closest float possible. That would indicate that the parse-float library does not.
6:03:17
beach
This discussion reminds me of several incidents when we used Common Lisp in our teaching, and the students discovered that typing something like (+ 0.4 0.3) to the REPL doesn't give the answer 0.7. They were then very happy to announce that they had found a "bug in Common Lisp".
6:11:18
White_Flame
beach: yeah, parse-float coerces portions of the number to the target float type, then combines them with adds and multiplies. this compounds precision issues