Xach changed the topic of #commonlisp to: Common Lisp, the #1=(programmable . #1#) programming language | Wiki: <https://www.cliki.net> | IRC Logs: <https://irclog.tymoon.eu/libera/%23commonlisp> | Cookbook: <https://lispcookbook.github.io/cl-cookbook>
pve has quit [Quit: leaving]
taiju has joined #commonlisp
gaqwas has quit [Ping timeout: 264 seconds]
Guest7482 has joined #commonlisp
Inline has quit [Quit: Leaving]
taiju has quit [Ping timeout: 268 seconds]
rgherdt has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 260 seconds]
Lord_of_Life has joined #commonlisp
Inline has joined #commonlisp
Devon has quit [Read error: Connection reset by peer]
random-nick has quit [Ping timeout: 256 seconds]
igemnace has quit [Quit: WeeChat 3.3]
alvaro121 has joined #commonlisp
waleee has quit [Ping timeout: 268 seconds]
asen has joined #commonlisp
waleee has joined #commonlisp
asen has quit [Read error: Connection reset by peer]
asen has joined #commonlisp
jealousmonk has quit [Quit: ERC (IRC client for Emacs 27.1)]
rgherdt has quit [Remote host closed the connection]
rgherdt has joined #commonlisp
Devon has joined #commonlisp
gigamonkey has quit [Ping timeout: 268 seconds]
Inline has quit [Remote host closed the connection]
Inline has joined #commonlisp
Inline has quit [Remote host closed the connection]
rgherdt has quit [Ping timeout: 264 seconds]
asen has quit [Remote host closed the connection]
asen has joined #commonlisp
taiju has joined #commonlisp
asen has quit [Read error: Connection reset by peer]
asen has joined #commonlisp
ec has quit [Ping timeout: 276 seconds]
notzmv has quit [Ping timeout: 265 seconds]
notzmv has joined #commonlisp
gigamonkey has joined #commonlisp
gigamonkey has quit [Ping timeout: 256 seconds]
taiju has quit [Ping timeout: 260 seconds]
s-liao has joined #commonlisp
Devon has quit [Read error: Connection reset by peer]
ec has joined #commonlisp
Devon has joined #commonlisp
karlosz has quit [Quit: karlosz]
gigamonkey has joined #commonlisp
_73 has joined #commonlisp
alvaro121 has quit [Quit: Leaving]
_73 has left #commonlisp [#commonlisp]
gigamonkey has quit [Ping timeout: 260 seconds]
ad-absurdum has quit [Quit: Leaving]
Inline has joined #commonlisp
lisp123 has joined #commonlisp
ec has quit [Remote host closed the connection]
s-liao has quit [Quit: Ping timeout (120 seconds)]
ec has joined #commonlisp
s-liao has joined #commonlisp
gigamonkey has joined #commonlisp
ec has quit [Quit: ec]
Oladon has quit [Quit: Leaving.]
nature has quit [Ping timeout: 260 seconds]
<beach> Good morning everyone!
<lisp123> (print 'good-morning-beach)
lisp123 has quit [Quit: Leaving...]
s-liao has quit [Ping timeout: 256 seconds]
Oladon has joined #commonlisp
Devon has quit [Ping timeout: 260 seconds]
nature has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
nature has quit [Ping timeout: 260 seconds]
waleee has quit [Quit: WeeChat 3.3]
semz has quit [Ping timeout: 246 seconds]
<susam> Good morning!
<susam> Hello beach!
<susam> Hello lisp123!
semz has joined #commonlisp
bcasiello has quit [Ping timeout: 256 seconds]
taiju has joined #commonlisp
gigamonkey has quit [Ping timeout: 256 seconds]
Bike has quit [Quit: leaving]
Guest7482 has quit [Ping timeout: 260 seconds]
Inline has quit [Ping timeout: 264 seconds]
gigamonkey has joined #commonlisp
akoana has quit [Quit: leaving]
karlosz has joined #commonlisp
aartaka has joined #commonlisp
gigamonkey has quit [Ping timeout: 268 seconds]
ym has joined #commonlisp
VincentVega has joined #commonlisp
karlosz has quit [Quit: karlosz]
gigamonkey has joined #commonlisp
karlosz has joined #commonlisp
Posterdati has quit [Ping timeout: 250 seconds]
gigamonkey has quit [Ping timeout: 245 seconds]
gigamonkey has joined #commonlisp
pve has joined #commonlisp
gigamonkey has quit [Ping timeout: 260 seconds]
Posterdati has joined #commonlisp
gigamonkey has joined #commonlisp
s-liao has joined #commonlisp
rain3 has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
Oladon has quit [Quit: Leaving.]
Oladon has joined #commonlisp
d4ryus has quit [Quit: WeeChat 3.2]
gigamonkey has quit [Ping timeout: 256 seconds]
d4ryus has joined #commonlisp
gaqwas has joined #commonlisp
asen has quit [Remote host closed the connection]
asen has joined #commonlisp
Oladon has quit [Read error: Connection reset by peer]
gigamonkey has joined #commonlisp
rain3 has quit [Ping timeout: 245 seconds]
s-liao has joined #commonlisp
gigamonkey has quit [Ping timeout: 245 seconds]
gigamonkey has joined #commonlisp
Everything has joined #commonlisp
gigamonkey has quit [Ping timeout: 260 seconds]
attila_lendvai has joined #commonlisp
gigamonkey has joined #commonlisp
edgar-rft has quit [Quit: Leaving]
gigamonkey has quit [Ping timeout: 256 seconds]
asen has quit [Quit: Leaving]
gigamonkey has joined #commonlisp
shka has joined #commonlisp
gigamonkey has quit [Ping timeout: 245 seconds]
karlosz has quit [Quit: karlosz]
gigamonkey has joined #commonlisp
ullbeking has quit [Ping timeout: 256 seconds]
Devon has joined #commonlisp
gendl has quit [Ping timeout: 256 seconds]
ullbeking has joined #commonlisp
victor_ has quit [Read error: Connection reset by peer]
pl has quit [Ping timeout: 264 seconds]
jsatk has quit [Ping timeout: 264 seconds]
travv0 has quit [Ping timeout: 256 seconds]
gigamonkey has quit [Ping timeout: 265 seconds]
victor_ has joined #commonlisp
gendl has joined #commonlisp
travv0 has joined #commonlisp
pl has joined #commonlisp
jsatk has joined #commonlisp
ullbeking has quit [Max SendQ exceeded]
sgithens has quit [Ping timeout: 264 seconds]
sgithens has joined #commonlisp
ullbeking has joined #commonlisp
karlosz has joined #commonlisp
rgherdt has joined #commonlisp
gigamonkey has joined #commonlisp
gigamonkey has quit [Ping timeout: 264 seconds]
rain3 has joined #commonlisp
gigamonkey has joined #commonlisp
gigamonkey has quit [Ping timeout: 245 seconds]
notzmv has quit [Ping timeout: 245 seconds]
aartaka has quit [Read error: Connection reset by peer]
aartaka has joined #commonlisp
cosimone has joined #commonlisp
gigamonkey has joined #commonlisp
rgherdt has quit [Remote host closed the connection]
dre has quit [Ping timeout: 240 seconds]
gigamonkey has quit [Ping timeout: 264 seconds]
cosimone has quit [Quit: ERC (IRC client for Emacs 27.1)]
cosimone has joined #commonlisp
lottaquestions has quit [Remote host closed the connection]
lottaquestions has joined #commonlisp
rain3 has quit [Ping timeout: 268 seconds]
gigamonkey has joined #commonlisp
gigamonkey has quit [Ping timeout: 260 seconds]
s-liao has quit [Ping timeout: 256 seconds]
gigamonkey has joined #commonlisp
taiju has quit [Ping timeout: 264 seconds]
gigamonkey has quit [Ping timeout: 245 seconds]
taiju has joined #commonlisp
s-liao has joined #commonlisp
s-liao21 has joined #commonlisp
s-liao has quit [Quit: Client closed]
resttime has joined #commonlisp
gxt has quit [Remote host closed the connection]
gxt has joined #commonlisp
rgherdt has joined #commonlisp
resttime has quit [Quit: resttime]
cage has joined #commonlisp
frgo has quit [Ping timeout: 246 seconds]
karlosz has quit [Quit: karlosz]
gigamonkey has joined #commonlisp
VincentVega has quit [Read error: Connection reset by peer]
Inline has joined #commonlisp
gigamonkey has quit [Ping timeout: 256 seconds]
s-liao21 has quit [Quit: Client closed]
random-nick has joined #commonlisp
s-liao has joined #commonlisp
igemnace has joined #commonlisp
tyson2 has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
ebrasca has joined #commonlisp
edgar-rft has joined #commonlisp
Krystof has quit [Ping timeout: 240 seconds]
edgar-rft has quit [Quit: Leaving]
edgar-rft has joined #commonlisp
aartaka has quit [Ping timeout: 256 seconds]
aartaka has joined #commonlisp
s-liao has joined #commonlisp
Guest74 has joined #commonlisp
vats has joined #commonlisp
aartaka has quit [Ping timeout: 256 seconds]
aartaka has joined #commonlisp
gigamonkey has joined #commonlisp
Krystof has joined #commonlisp
aartaka has quit [Ping timeout: 245 seconds]
gigamonkey has quit [Ping timeout: 260 seconds]
aartaka has joined #commonlisp
nature has joined #commonlisp
_73 has joined #commonlisp
Inline has quit [Quit: Leaving]
s-liao has quit [Quit: Client closed]
<_73> I copied code directly from the book `on lisp (page 19)` but I am getting a compiler warning for `undefined variable`. I would like help understanding what the problem is - http://dpaste.com/B76NZ6D8G
<_73> I am using SBCL
<beach> You are not allowed to use SETQ on a variable that has not been defined.
<beach> Use DEFPARAMETER instead.
<_73> ok that works thanks
<beach> Or, rather, using SETQ on an undefined variable is undefined behavior.
<beach> Sure.
Inline has joined #commonlisp
_73 has left #commonlisp [ERC (IRC client for Emacs 27.2)]
VincentVega has joined #commonlisp
<VincentVega> Heyall. Suppose there's two libraries, A and B. They define they same functions in different ways (same lambda lists, though maybe different declared types/etc). There's library C that relies on the functions. There's application D from which I want to control whether C loads and uses (e.g. imports from) A or B. I have control over all these libraries. How can I do this? I don't want to use CLOS for this. I guess what I am looking for a
<VincentVega> conditional dependency mechanism. Any better ideas than try to wrap my defpackage/defsystem into a let and set a dynamic variable and use it in package C?
tyson2 has quit [Remote host closed the connection]
<Demosthenex> so i was looking at the trivia pattern matching library. it's pretty slick, and i was curious if i missed it, or does it have an option to ignore "one or more" items? (trivia:match '(1 2 3 4 ) ((list 1 _ _ a ) a)) resolves to 4, but i'd rather not repeat the _, like (trivia:match '(1 2 3 4 ) ((list 1 _* a ) a))
<Guest74> vincentvega: apparently asdf has an :if-feature option that can do stuff depending if something is in *features*. Unfortunately you cannot set this with the asd itself. so maybe if You have the user/yourself set the feature before loading D then you can load a or b appropriately.
<Guest74> s/with/within/
<VincentVega> Guest74: I will look into it, thanks for the pointer!
<Guest74> np, I was looking for the same thing, haven't used it yet though.
<beach> VincentVega: If you don't import at all, and instead use package-local nicknames, you can just prefix all the symbols from the external libraries with a prefix of your choice and change it according to which external library you want.
<beach> VincentVega: In fact, it is not recommended to :USE packages other than the COMMON-LISP package, because of the risk of conflicts; even future ones.
<Guest74> heh, that's what I currently do, but didn't know if it was frowned upon.
Everything has quit [Quit: leaving]
<beach> Package-local nicknames? No, they are great!
<VincentVega> beach: Hmmm, yeah, I am not too keen on importing, so that sounds fine, but could you please elaborate on the "change it according to which external library you want." You mean conditionally set up the package local nicknames using :if-feature?
<Guest74> well, actually I have a generic protocol and then implementations follow the protocol semantics in their own packages and then wrap those up for the protocol. So you can develop using the generics and simply use a pln to swtich to a fast path if needed.
<beach> I just meant that you can modify the package definition of C.
<Guest74> but it seemed unusual to do that as I haven't really seen anybody else do that.
<beach> But I guess then you may have to use an implementation-specific programmatic interface.
<VincentVega> beach: Oh, I see. I was wondering if I could do that without the user modifying C at all, hopefully, only setting up the option in D.
<beach> Guest74: Why not just compile and load one of the interface packages as you please, without changing the protocol package?
<beach> VincentVega: I see. Well, maybe another solution would be to have C refer to some entirely different package, and have C create that package with symbols imported from either A or B.
<beach> You can do this using only standard functions.
<Guest74> I might not have explained properly, or I misunderstood. Usual me. it's just so you can have draw:line in your code that will draw to any surface, and then if you want to package for only the framebuffer you can just use a pln for draw-frame-buffer to draw.
<VincentVega> beach: Huh, that's an interesting direction to think about I guess. I could maybe define that middle-man package in before quickloading D or even in D, maybe that could actually work.
<VincentVega> Guest74: is pln the package you are developing?
<Guest74> package-local-nickname
<VincentVega> oh
<VincentVega> But is your package open source yet? I am also working on some drawing stuff here : D
<beach> Guest74: I am notorious for not understanding the point, so I'll let someone else figure it out.
<Guest74> so instead of draw:line referencing the generic protocol, it directly uses draw-frame-buffer:line
<Guest74> it can make quite a difference when drawing pixels millions of times a second, otherwise I'm not sure it's worth the trouble.
tyson2 has joined #commonlisp
Lycurgus has joined #commonlisp
waleee has joined #commonlisp
<pjb> VincentVega: I think you're confusing functions with their names. You cannot define the same function with different declared types. But once you have the same signature (lambda-list) and source and image types, you can indeed define a function in different ways. As long as they're really the same function (compute the same results), it doesn't matter.
<pjb> VincentVega: You can use one implementation or the other, by using a wrapper for example: (defun d:factorial (x) (if d:*use-c* (a:fact x) (b:! x)))
<VincentVega> pjb: But I don't want to define the same function twice, I either load A or B, but not both at the same time.
<pjb> Then you can use the backend pattern, where you edfine the D:factorial API, and load d-a.lisp and d-b.lisp backends to forward the call to right function.
<pjb> you can have a d-a and a d-b system, d-a depends on a and loads d-a.lisp, while d-b depends on b and loads d-b.lisp
<pjb> and of course, if the name of the functions are also the same, you can define the d package by using a or b, and re-exporting the symbol naming that function.
<VincentVega> pjb: I hear you, and I would probably be ok even with CLOS otherwise, but I want this to be as performant as possible. Actually, I am trying out the middle-man package idea (thanks beach!), and it seems to be working, but I am still testing it.
<pjb> VincentVega: packages are just collections of symbols. Those symbols aren't necessarily interned in that package.
<pjb> VincentVega: (defpackage "SIMPLE-LISP" (:use "CL") (:export "DEFUN" "COND" "NULL" "CAR" "CDR" "CONS" "EQL" "QUOTE"))
<pjb> VincentVega: then you can write your programs in simple-lisp instead of in common-lisp.
<pjb> (defpackage "YOUR-PROGRAM" (:use "SIMPLE-LISP")) (in-package "YOUR-PROGRAM") …
Lycurgus has quit [Quit: Exeunt]
<VincentVega> pjb: ok, gotcha
gigamonkey has joined #commonlisp
vats has quit [Ping timeout: 268 seconds]
gigamonkey has quit [Remote host closed the connection]
gigamonkey has joined #commonlisp
gigamonkey has quit [Ping timeout: 245 seconds]
gigamonkey has joined #commonlisp
<phantomics> Interesting data point: in ABCL, (log 2.0d0 2.0d0) will produce 1.0d0, but (log 2 2.0d0) and (log 2.0 2.0d0) will produce 1.0000000027478353d0
gigamonkey has quit [Ping timeout: 256 seconds]
<Guest74> is FINDing something in an array faster than finding it in a list?
Guest91 has joined #commonlisp
<phantomics> Guest74: no, in each case you iterate over each element
<Guest74> just wondering if there's less indirection with an array.
<phantomics> Arrays are faster when you want to get something at an arbitrary location, but when you're scanning over each element in turn both are equally as fast
<phantomics> Now, if you're searching for something where the search involves some kind of sorting, an array would be faster
<phantomics> Like searching for a name in an alphabetical list
<Guest74> sorting an array is faster than sorting a list?
<phantomics> Yes, because you need to access arbitrary elements
tyson2 has quit [Remote host closed the connection]
<jcowan> There is also better locality with an array.
<pjb> A list might take twice the memory, since it needs to store cdr pointers. So it's possible that for big sequences, searching in vector be fster than in lists.
<Guest74> trying to figure out what's the best structures to handle all these adjacency rules for wave function collapse. Anything to speed it up would be nice.
<pjb> On the other hand, on big vectors, with modern memory systems, accesses are not O(1).
<phantomics> Say you're doing a quicksort, you choose an index as the pivot point and access the elements at either side of it, you have to access specific numbered elements
<jcowan> CDR coding was an attempt to mitigate these issues while keeping the semantics of lists.
<jcowan> An attempt was made to keep list cells contiguous whenever possible, each cell containing a 2-bit flag representing the following cases:
tyson2 has joined #commonlisp
<Guest74> now if i'm constantly removing members I'm guessing a list would be better? I need to also constantly update a list of possible neighbours.
Nselm has joined #commonlisp
<pjb> Of course.
<Guest74> and impossible neighbours
<jcowan> (a) the cdr is the next cell; b) the cdr is (); c) the cdr *pointer* is in the next cell; d) this cell is a cdr pointer
<pjb> On the other hand, you may also prefer to use a doubly-linked list.
<jcowan> then (a b c d) occupies the same amount of storage as #(a b c d), and you can determine in O(n) time whether a list is in fact contiguous.
<Guest74> but nobody does that anymore right?
<phantomics> Guest74: Is there any existing work in other languages to solve this problem? That could be helpful
<Guest74> plenty
<phantomics> For the possible/impossible neighbor lists, you could use two matrices
<Guest74> i just don't understand other languages.
<phantomics> Say you have elements (a b c d e)
<Guest74> and i'm guessing they each have differences in performance.
<phantomics> You would create a 5x5 binary matrix
<jcowan> Guest74: In the 16-bit and 32-bit eras, there were no flag bits to spare. In the 64-bit era it might be worth reviving.
<Alfr> Arrays are also expensive if you have to insert things at random positions (same goes for lists if it's not the current position).
<phantomics> Actually, just one matrix, not binary
<Guest74> I guess I could use a bitmask and just flip bits
<jcowan> Arrays are more expensive than lists because of the repeated memory allocations. Inserting/deleting on lists is O(n), the same as retrieving.
<phantomics> Or yes binary, each value would be 0 (impossible neighbor) or 1 (possible neighbor)
<Guest74> though i'm guessing that could be a problem depending on the size.
<jcowan> Note that mutable boolean arrays may be more time-efficient as bytevectors than as bitvectors if you are okay with the space cost.
<phantomics> Only thing to remember with bitmasks is that there are issues with flipping bits and multithreading
<phantomics> Is this job parallelizable at all?
<jcowan> Such matrixes assume uniqueness.
<phantomics> Like jcowan said, the matrix could have 8-bit integers of 1 or 0 since those are faster to flip
<Guest74> not sure. i guess while propagating it could be, but there might be multiple access to each possibility
<phantomics> Ok, if you can run parts in parallel those could get a big speedup
vollcheck has joined #commonlisp
<jcowan> an extension flag :reptype to make-array might be helpful here
<Guest74> but if you propagate up and to left of a cell, those will both propage to the nw diagonal of the starting cell.
<Guest74> s/propage/propagate
<jcowan> (English is whimsical about the -ate suffix. There is simply no reason except historical accident that we use prepare and separate instead of *separe and/or *preparate.)
<Guest74> those would end up being quite large matrices.
<phantomics> So in one "cycle" propagation could move in multiple directions for a diagonal movement and that may not be doable in parallel? I don't know much about your use case, granted
<phantomics> How many elements are you typically working with?
<Guest74> depends on the image being sampled.
<jcowan> What is a good data structure that balances the big-O time for traversing, adding at an arbitrary position, and removing ditto?
<jcowan> Mutable is fine, I don't need persistence here.
<Guest74> say I've got a 23x23 image here, that gives me 400 samples without including any rotations or reflections.
<Guest74> how many of those samples are unique depends on the image.
<jcowan> Presumably users will be willing to wait longer for bigger images, though.
<beach> jcowan: A balanced tree.
<beach> jcowan: You get O(log n) for every operation.
<beach> Well, traversing everything is O(n) obviously.
<phantomics> 400x400? That's not too big
<Guest74> for a 23x23 input without rotations/reflections which most people want.
<jcowan> Okay, and what is the most balanced way to keep the tree balanced?
<beach> Doesn't matter much. 2-3 tree, red-black tree, AVL tree.
<beach> Red-black trees are notoriously hard to implement right, but then you might find some in an existing library.
<beach> jcowan: Most implementations perhaps use the dictionary model where you store keys and values, but you want to store the size of a subtree in the root of that subtree, and branch based on some accumulated number of items to your left or to your right.
<jcowan> How about skip lists? They are also O(log n) and are said to be less fiddly.
Devon has quit [Ping timeout: 265 seconds]
<jcowan> (I have no experience implementing any of them.)
<phantomics> Quick question: is there an accepted way to do GCD/LCM of floats? My current method is to (rationalize) them, do the operation and then convert them back to floats, but I'm having some problems with (rationalize)
amb007 has quit [Ping timeout: 256 seconds]
frgo has joined #commonlisp
amb007 has joined #commonlisp
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
frgo has quit [Client Quit]
LoopMacro has joined #commonlisp
<Guest74> that's an interesting question. What are you using it for?
McParen has joined #commonlisp
gigamonkey has joined #commonlisp
<pjb> phantomics: given that / has always a result for any couple of float (but (x 0)), the (GCD x y) = most-positive-long-float
tyson2 has quit [Remote host closed the connection]
amb007 has quit [Ping timeout: 264 seconds]
<pjb> phantomics: going thru rationalize or any other transformation intended to map reals to ratio is rather nonsensical. You can get any result, since you can use any mapping.
amb007 has joined #commonlisp
<pjb> phantomics: the problem is that 1.0 represents any number between 1.0-ε and 1.0+ε (an infinite number of reals in there), therefore there are n infinite number of ratio that could be mapped from that 1.0 float.
frgo has joined #commonlisp
<phantomics> pjb: Hmm, ok, APLs have GCD and LCM for floats so they clearly have some idea of how to approach it
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
<phantomics> ABCL has trouble with (rationalize) I'm sure because of the details with Java, try (rationalize -2.3) and (rationalize -2.3d0) to see the zany results
Guest91 has quit [Quit: Client closed]
<edgar-rft> An IEEE floating-point number n represents a *range* of n+/-ε numbers, where I have no idea howto find the GDD or LCM of a range of numbers in a meaningful way, but maybe some math experts know that better than me.
<Guest74> I'm still wondering what the use case is.
<phantomics> For use case, see: http://dfns.dyalog.com/n_cfract.htm
<phantomics> This is an APL function that can use a float GCD (the 1÷1∨⍵ part) in the source code here: http://dfns.dyalog.com/c_cfract.htm
<Guest74> oh are you one of the guys with an apl implementation?
<phantomics> Yes, I wrote the April compiler: https://github.com/phantomics/april
<phantomics> It could be handy for your image processing case, you mention permuting things in different ways, rotation, reflection, etc.
<Guest74> ah, my brain sees gobbledygook when looking at apl. we're not compatible.
<phantomics> Reflecting an array A is literally just ⌽A
<Guest74> well, it's just (reflect a) in lisp...
<phantomics> And the library you're using handles reflecting any rank array on any axis?
Catie has quit [Quit: rcirc on GNU Emacs 27.2]
Catie has joined #commonlisp
<Guest74> nope, haven't written all cases yet :)
<phantomics> Another option for you could be to use the functions in here: https://github.com/phantomics/april/blob/master/aplesque/aplesque.lisp
<Guest74> but at least I can read it, and not try and figure out why phi is reflect or how am I going to type it.
<phantomics> The aplesque package holds all the array operations that power APL, including rotation and reflection, so you can use them in CL
<phantomics> See the (turn) function in there for rotation
<phantomics> They're all parallelized too
<Guest74> interesting. but all my arrays are 1d
<Alfr> edgar-rft, I don't think there is, for a, b rationals consider: gcd(a,b) = gcd(x/q, y/q) = gcd(x,y)/q for q a common denominator of a and b; thus when you're free to choose a or b you can make gcd(a,b) arbitrarily small by forcing q to be sufficiently large.
<Alfr> ^ q s.t. x, y are integers.
igemnace has quit [Ping timeout: 264 seconds]
Nselm has quit [Ping timeout: 256 seconds]
vats has joined #commonlisp
<edgar-rft> Alfr: that's very nice but I haven't understood a word of it, can you explain it in normal english?
<phantomics> You just need to find a common denominator for the args a and b he says
<phantomics> Divide them by it to make whole numbers, then GCD those numbers and divide the result by q
<phantomics> Right?
<edgar-rft> but an IEEE float is *not* a rational
<Alfr> edgar-rft, you said you'd like to have a gcd(a,b) where a and/or b represent intervals of values, what I'm saying is that you can choose rationals in those intervals such that gcd(a',b') is arbitrarily small.
gigamonkey has quit [Ping timeout: 260 seconds]
<Alfr> edgar-rft, I use rationals because, becaus I'm not sure how to compute the gcd for two arbitrary reals and as the rationals are dense in the reals it's possible to choose appropriate ones for the argument in any open interval.
<edgar-rft> yes, a common "practical" algorithm (that is mathematically incorrect) is defining a "precisision" of the result (e.g. three digits after the dot) and use rationals that are in the "precision" range of the result
<semz> What prompted this problem in the first place?
thmprover has joined #commonlisp
<phantomics> semz: APL allows you to take the GCD/LCM of floats, and it's used in some functions like this one: http://dfns.dyalog.com/c_cfract.htm
<phantomics> I'm implementing an APL compiler so working to find the best way to do this
gigamonkey has joined #commonlisp
attila_lendvai has quit [Ping timeout: 268 seconds]
gigamonkey has quit [Ping timeout: 256 seconds]
peterhil_ has joined #commonlisp
tyson2 has joined #commonlisp
<semz> phantomics: There's a general notion of GCD that can be specialized to rationals, but it's only unique up to units and therefore trivial for ℚ because every non-zero element of ℚ is a unit (the units of ℤ are 1 and -1, so you'd get uniqueness up to sign there). From what I can tell, APL seems to refer to something very specific from doi:10.1145/800117.803810 ("A Notation for the GCD and LCM Functions", McDonnell) when it talks about the GCD of rationals.
<Alfr> phantomics, maybe don't use rational_ize_? Instead use rational, it returns a rational that's equal to the value the float represents.
<semz> APL Code will probably rely on the intricacies of this (non-standard as far as math goes afaik) definition.
<semz> multiplication by units*, sorry
<phantomics> In ABCL (rational -2.3) and (rationalize -2.3) give the same wacky result
<phantomics> Interesting, thanks semz
<Guest74> clhs says rational is implementation dependent.
<Guest74> interesting difference between the two, didn't know that.
<semz> It must be implementation-dependent because the floating-point formats are.
<phantomics> Yeah, there's some weirdness in ABCL's floats
<semz> I'm surprised that rationalize isn't required to return the simplest rational though. I guess many implementations just happen to do that and ABCL is not one of them.
<semz> Or _a_ simplest rational, since the formats are implementation-defined and all.
<phantomics> Must be some kind of oversight, I'd think Java's floats would be fairly robust
<Guest74> how do you clear everything in the slime repl and hopefully not clear the history?
<Catie> Guest74: You kill the repl buffer, then run slime-repl to get a new one
<_death> C-c M-o?
<Guest74> thanks death:
<phantomics> C-x C-k to kill the buffer
<Guest74> i hate having to try to find the start of some long output.
<Guest74> wouldn't killing the buffer kill the repl and the history?
<Catie> Your SLIME history is saved in a file, I don't think you get rid of your history unless you delete it
<phantomics> The history stays
<Guest74> lol, I should know that since I use it all the time after restarting the lisp.
<Alfr> phantomics, what's that wacky result you get? -9646899/4194304
<phantomics> same: -9646899/4194304
<_death> you can borrow the code from say sbcl and submit to abcl
<Alfr> phantomics, I think that one is fine. Remember that binary floats are of the form (-1)^sign*2^exponent*sum-of-powers-of-two, and I suspect there's no exact representation for -2.3.
<_death> I'm assuming we're talking about rationalize, which is supposed to give a more "human friendly" approximation
<phantomics> Unfortunately it causes a problem here in ABCL: (april-f "{⌊⎕CT+⍵ 1÷1∨⍵} ¯2.3") => #(-2589569785738035 1125899906842624)
<phantomics> In other impls the result is #(-23 10)
<phantomics> _death: I would think their (rationalize) is implemented in Java
<Alfr> phantomics, I see.
<_death> phantomics: you can also borrow it for your own code, so that your results will be portable across implementations
gigamonkey has joined #commonlisp
VincentV` has joined #commonlisp
<Alfr> phantomics, problem is that I don't think that's bug in abcl. As the standard only guarantees (float (rationalize x) x) == x, and the part pertaining to rationalize "only to the precision of the floating-point representation" doesn't prescribe how to choose the rational.
VincentVega has quit [Ping timeout: 256 seconds]
gigamonkey has quit [Ping timeout: 260 seconds]
aartaka has quit [Ping timeout: 260 seconds]
<jackdaniel> the fact that floats are not rational tells it all.. them irrational numbers
<phantomics> Alfr: I see, I'm looking at importing SBCL's implementation but it relies on a bunch of different functions
vats has quit [Ping timeout: 256 seconds]
<phantomics> jackdaniel I've been getting segfaults with ECL just loading my quicklisp setup file, does it use an extremely small heap by default?
gigamonkey has joined #commonlisp
amb007 has quit [Ping timeout: 256 seconds]
<jackdaniel> no, I don't think so. also when heap is exhausted ecl should signal a condition (it has specially reserved space for that)
<jackdaniel> so you are hitting probably some other issue
<jackdaniel> if you narrow it down please let me know
<phantomics> Hmm ok, I just built it from source
<phantomics> Here's what happens;
<phantomics> (load "~/quicklisp/setup.lisp") → Condition of type: STACK-OVERFLOW, BINDING-STACK overflow at size 10240. Stack can probably be resized.
<phantomics> I enter :r1 to continue and expand the stack, then: ;;; Detected access to protected memory, also known as 'bus or segmentation fault'. Jumping to the outermost toplevel prompt
gigamonkey has quit [Ping timeout: 264 seconds]
<phantomics> This is repeated several times, then it crashes with a Segmentation fault
<jackdaniel> stack is not a heap. as of why you can't expand it - perhaps an rlimit?
<phantomics> If the rlimit is so low as to make loading QL impossible, I don't see why any other Lisp would work work on my system
<phantomics> It it something that can be set specifically for ECL?
<jackdaniel> what can I say - it works here
<jackdaniel> you may set the stack size, but if it overflows at default values perhaps you have some tail call recurrency that ecl doesn't pick up?
<jackdaniel> what ecl version do you use?
<phantomics> Perhaps, I'm not loading anything of my own yet though, just QL so it's confusing
<phantomics> 21.2.1
<Catie> I've got a working ECL built from source, version 21.2.1
amb007 has joined #commonlisp
<phantomics> Must be something in my system, I've run ECL successfully in the past
<phantomics> I'll try on another machine
<jackdaniel> phantomics: try gdb to see what blows the stack
VincentV` has quit [Read error: Connection reset by peer]
lotuseater has joined #commonlisp
lotuseater has quit [Remote host closed the connection]
akoana has joined #commonlisp
gigamonkey has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 27.1]
karlosz has joined #commonlisp
rogersm has quit [Quit: Leaving...]
gigamonkey has quit [Ping timeout: 245 seconds]
<phantomics> jackdaniel: talk soon, I'll let you know what I find out
amb007 has quit [Ping timeout: 260 seconds]
amb007 has joined #commonlisp
<jackdaniel> great, thanks (and good luck)
McParen has left #commonlisp [#commonlisp]
shka has quit [Ping timeout: 264 seconds]
gxt has quit [Remote host closed the connection]
gxt has joined #commonlisp
X-Scale` has joined #commonlisp
X-Scale has quit [Ping timeout: 260 seconds]
srhm has joined #commonlisp
X-Scale` is now known as X-Scale
karlosz has quit [Quit: karlosz]
ym has quit [Ping timeout: 264 seconds]
tyson2 has quit [Remote host closed the connection]
<jcowan> Floats are perfectly rational (modulo infs and NaN); it's just that the mapping is not unique.
<jcowan> You get to pick, within a certain range, which rational number corresponds to a given float (obvs you do not want one that breaks ordering)
gigamonkey has joined #commonlisp
azimut_ has quit [Ping timeout: 276 seconds]
vollcheck has quit [Quit: Leaving]
srhm has quit [Ping timeout: 268 seconds]
<jcowan> Scheme has IMO a better (though not drop-in) definition of rationalize: "The (rationalize x y) procedure returns the simplest rational number differing from x by no more than y. A rational number r1 is simpler than another rational number r2 if r1 = p1/q1 and r2 = p2/q2 (in lowest terms) and |p1| ≤ |p2| and |q1| ≤ |q2|.
azimut has joined #commonlisp
X-Scale` has joined #commonlisp
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale has joined #commonlisp
Devon has joined #commonlisp
z3t0 has quit [Ping timeout: 240 seconds]
z3t0 has joined #commonlisp
ec has joined #commonlisp
gaqwas has quit [Ping timeout: 264 seconds]
<lagash> Anyone use lake? This thing: https://github.com/takagi/lake Anyone know any alternatives? I think it's interesting it includes SSH remote execution ability..
thmprover has quit [Remote host closed the connection]
tfeb has joined #commonlisp
tfeb is now known as tfb
tfb has quit [Quit: died]
kadir has joined #commonlisp
sjl has quit [Quit: WeeChat 2.2-dev]
igemnace has joined #commonlisp
peterhil_ has quit [Quit: Leaving]
peterhil has joined #commonlisp
kadir has quit [Quit: WeeChat 3.3]
Krystof has quit [Ping timeout: 260 seconds]
cosimone has quit [Quit: ERC (IRC client for Emacs 27.1)]
asen has joined #commonlisp
asen has quit [Read error: Connection reset by peer]
asen has joined #commonlisp
tyson2 has joined #commonlisp
Jing has quit [Remote host closed the connection]
Jing has joined #commonlisp
pve has quit [Quit: leaving]