ralt has quit [Quit: Connection closed for inactivity]
orivej has joined #lisp
lucasb has quit [Quit: Connection closed for inactivity]
fragamus has joined #lisp
igemnace has quit [Quit: WeeChat 2.6]
sjl has joined #lisp
<remexre>
Is there a way w/ CFFI to reload a shared library?
<remexre>
(I'm developing a native-code library alongside a Lisp application, and don't wanna have to restart the REPL every change)
X-Scale` has joined #lisp
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
<Bike>
if you call load-foreign-library again it will reload, says the manual
<remexre>
ah, didn't see that
<remexre>
thx
slyrus has joined #lisp
davr0s has quit [Ping timeout: 276 seconds]
davr0s_ has quit [Ping timeout: 276 seconds]
slyrus has quit [Remote host closed the connection]
notzmv has quit [Ping timeout: 246 seconds]
milanj has quit [Quit: This computer has gone to sleep]
asarch has quit [Remote host closed the connection]
bitmapper has quit [Ping timeout: 245 seconds]
akoana has left #lisp ["Leaving"]
fragamus has quit [Ping timeout: 240 seconds]
semz has quit [Ping timeout: 264 seconds]
iovec has quit [Quit: Connection closed for inactivity]
nirved has quit [Quit: Leaving]
jao has quit [Ping timeout: 245 seconds]
semz has joined #lisp
anewuser has joined #lisp
karlosz has joined #lisp
jdz has quit [Ping timeout: 268 seconds]
jdz has joined #lisp
fragamus has joined #lisp
karlosz has quit [Quit: karlosz]
dale has quit [Quit: My computer has gone to sleep]
fragamus has quit [Ping timeout: 268 seconds]
fragamus has joined #lisp
eSVG has joined #lisp
karlosz has joined #lisp
lxbarbosa has quit [Ping timeout: 245 seconds]
prite has joined #lisp
ahungry has joined #lisp
ebrasca has quit [Remote host closed the connection]
rople has joined #lisp
abhixec has quit [Quit: leaving]
notzmv has joined #lisp
davr0s_ has joined #lisp
davr0s has joined #lisp
xristos has joined #lisp
p9s has joined #lisp
caltelt has quit [Ping timeout: 245 seconds]
bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #lisp
prite has quit [Ping timeout: 245 seconds]
igemnace has joined #lisp
igemnace has quit [Read error: Connection reset by peer]
paul0 has quit [Remote host closed the connection]
Bike has quit [Quit: Lost terminal]
paul0 has joined #lisp
Ricchi has quit [Remote host closed the connection]
Kevslinger has quit [Quit: Connection closed for inactivity]
p9s has quit [Ping timeout: 246 seconds]
<beach>
Good morning everyone!
libertyprime has quit [Ping timeout: 245 seconds]
torbo has quit [Remote host closed the connection]
dddddd has quit [Remote host closed the connection]
igemnace has joined #lisp
_whitelogger has joined #lisp
igemnace has quit [Remote host closed the connection]
igemnace has joined #lisp
nicdev` has quit [Ping timeout: 245 seconds]
gravicappa has joined #lisp
dale has joined #lisp
anewuser has quit [Quit: anewuser]
Lord_of_Life has quit [Ping timeout: 265 seconds]
Lord_of_Life has joined #lisp
FreeBirdLjj has joined #lisp
isBEKaml has joined #lisp
igemnace has quit [Remote host closed the connection]
igemnace has joined #lisp
Ricchi has joined #lisp
sellout-1 has quit [Read error: Connection reset by peer]
Inline has quit [Quit: Leaving]
sellout- has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
MrBismuth has quit [Ping timeout: 245 seconds]
igemnace has quit [Remote host closed the connection]
flamebeard has joined #lisp
dale has quit [Quit: My computer has gone to sleep]
igemnace has joined #lisp
MrBismuth has joined #lisp
Cymew has quit [Quit: Konversation terminated!]
varjag has joined #lisp
isBEKaml has quit [Ping timeout: 265 seconds]
libertyprime has joined #lisp
davr0s has quit [Ping timeout: 276 seconds]
davr0s_ has quit [Ping timeout: 276 seconds]
igemnace has quit [Read error: Connection reset by peer]
prite has joined #lisp
ahungry has quit [Remote host closed the connection]
vlatkoB has joined #lisp
varjag has quit [Ping timeout: 245 seconds]
ozzloy has joined #lisp
ozzloy has joined #lisp
ozzloy has quit [Client Quit]
adip has joined #lisp
ozzloy has joined #lisp
ozzloy has joined #lisp
frgo has quit [Ping timeout: 240 seconds]
hiroaki has quit [Ping timeout: 245 seconds]
JohnMS_WORK has joined #lisp
niceplace has quit [Read error: Connection reset by peer]
scymtym has quit [Ping timeout: 245 seconds]
niceplace has joined #lisp
Ricchi has quit [Remote host closed the connection]
jprajzne has joined #lisp
varjag has joined #lisp
Ricchi has joined #lisp
slyrus__ has joined #lisp
fragamus has quit [Ping timeout: 276 seconds]
slyrus_ has quit [Ping timeout: 245 seconds]
shrdlu68 has joined #lisp
Ricchi has quit [Remote host closed the connection]
<shrdlu68>
Good morning #lisp
<shrdlu68>
beach: What inspired the name "metamodular"?
Josh_2 has quit [Remote host closed the connection]
Josh_2 has joined #lisp
ralt has joined #lisp
<ralt>
So, hm. I've been thinking about how lisp is all great to have programs running forever, with the image based things, and the live update facilities. I really like that. But servers die. Things need reboots. So it's just not a viable model these days.
<ralt>
So I've been thinking: is there a way to have programs that can run forever? Say, something that "distributes" the process on several machines, so that you _can_ have an application running "forever".
<aeth>
yes
<aeth>
I was about to propose that
<ralt>
I know it's very much like erlang.
<shrdlu68>
What do you mean "these days"?
<jackdaniel>
ralt: there is lparallel
<aeth>
Some would say to come up with a way to serialize it to the disk periodically, but that's no fun, just to be able to restore from a snapshot.
<ralt>
jackdaniel: lparallel supports running across machines?
<aeth>
Having 10 redundant systems so that you can rebuild when some go down, now that's more with the spirit of things
<jackdaniel>
ralt: yes, it is Common Lisp library for distributed computing
<ralt>
That said, I know one of the hard problems in my use case is earmuffs variables. I'm just not sure how to solve that.
<no-defun-allowed>
Well, lfarm does across machines, but it's a worker-manager model and not really distributed.
<aeth>
lfarm even has pmap-reduce
<jackdaniel>
ralt: having persistent memory for program (where ram is only a small cache to it) is something what beach proposed years ago
<jackdaniel>
ah, right, lfarm, sorry
<jackdaniel>
I've meant it
<ralt>
Like, if your program is really logically a single entity, then things like `(setf *foo* "bar")` can work, and you don't even need a database, ever
<jackdaniel>
no-defun-allowed: it takes only a little imagination to think about workers as both managers and workers, and data distributed is the actual application state
manualcrank has quit [Quit: WeeChat 1.9.1]
<no-defun-allowed>
jackdaniel: sorry, not the imaginative type
<jackdaniel>
databases are highly optimized for things for which lisp image is not meant for (i.e querying for a particular kind of data)
<ralt>
I also don't mean it should be running across several machines, it's still a single entity that runs single-threaded (and if you make threads, who knows where they run), but somehow it can work across machines.
<aeth>
(okay, they wouldn't phrase it like that, but it has a built-in pre-SQL no-SQL)
frgo has joined #lisp
<ralt>
A bit like NUMA
<ralt>
aeth: uh, MUMPS sounds fun
<ralt>
Ah, and that's exactly what I'd use manardb for ;)
<ralt>
Maybe it should be a kernel feature... like NUMA, instead of memory being the clustered thing, it's other kernels
<ralt>
Naturally the applications can then follow the normal model of being normal applications
<ralt>
jackdaniel: most of the databases use cases are solved with hash tables, though (e.g. select by id)
fragamus has joined #lisp
<ralt>
Well, s/most/a lot of/
<ralt>
Ok, so the ecosystem is mostly lfarm as I understand it?
<jackdaniel>
I'd start with lfarm, yes
<ralt>
It's not magic enough :P
vaporatorius has quit [Read error: Connection reset by peer]
cartwright has quit [Remote host closed the connection]
<ralt>
Maybe I'm just too demanding
vaporatorius has joined #lisp
vaporatorius has quit [Read error: Connection reset by peer]
cartwright has joined #lisp
fragamus has quit [Ping timeout: 268 seconds]
<beach>
shrdlu68: At the time, soft sounds like M were fashionable.
<White_Flame>
there have been an OO language or two like that, with transparent persistence and distribution. They're pretty slow, though, and can have nonobvious interactions
<White_Flame>
I've been searching, but can't find direct references
<ralt>
Maybe you mean erlang?
<beach>
ralt: Servers that die are buggy.
<White_Flame>
ralt: no, erlang is not transparently persistent
<White_Flame>
nor transparently distributed
<ralt>
beach: not sure what your point is
<ralt>
That's also an arguable point of view, because kernels need to be upgraded, hardware rots, etc etc. So, sure, if you want, servers that die are buggy, but bugs are part of life :)
<ralt>
Unless you mean things like mainframe?
<ralt>
White_Flame: yes, the transparently persistence is clearly lacking
ltriant has quit [Quit: leaving]
<no-defun-allowed>
Maybe a UPS is a simpler solution to a small section of your problems.
<no-defun-allowed>
And if things crash and burn pretty hard, I don't see how having multiple servers running the same crashing and burning program is going to help the situation.
scymtym has joined #lisp
<ralt>
have you ever upgraded a kernel?
<beach>
ralt: It is not important. I don't have a solution for the case when the hardware breaks. But we shouldn't have to restart our computers when the operating system needs to be updated.
<aeth>
ralt: re "so the ecosystem is mostly lfarm" I'm not sure there's a big demand for this at all so... maybe?
<ralt>
beach: ah, I see, you're advocating for a lisp-like kernel with live upgradeable objects
<jackdaniel>
ralt: even linux kernel experiments with the hotswap kernel update and persistency
<ralt>
aeth: I don't know
<beach>
ralt: Sort of. Except I don't want a "kernel" at all.
<ralt>
jackdaniel: that's ksplice and friends, and it's, uh, fragile?
<ralt>
It's only recommended for small upgrades
<jackdaniel>
new features tend to be fragile, yes
<White_Flame>
ralt: linux is trying to include what other OSes have had years ago, in that regard
<ralt>
if by new you mean ">10 years"...
<jackdaniel>
all I'm saying is that bringing: kernel update requires restart is a hoax argument
<jackdaniel>
if you have operating center distributing all over the world with a single application, magnetic bomb can take it down by turning off electricity
<jackdaniel>
distributed ,)
<ralt>
I just really like the concept of an application running forever
<ralt>
and all the simplicity that comes with it
<aeth>
oh, ouch, that line of products was essentially killed by Itanium, if that Wikipedia article is accurate
<aeth>
s/by/by choosing/
<aeth>
essentially nothing of note there after migrating to x86 from Itanium
<aeth>
Essentially, every piece of hardware has to be redundant and hot-swappable.
<aeth>
(And then you probably still have to run the program on multiple copies of those computers very far away from each other.)
<thijso>
"and all the simplicity that comes with it"... I don't think that word means what you think it means, ralt
<aeth>
ralt: And if you want to know why (almost) no one uses fault tolerant systems, the answer is, of course, money!
<White_Flame>
simplicity of use != simplicity of implementation
<guaqua>
it's to date always proved to be prohibitively expensive to have programs running forever (whatever your definition of a program is, but probably something like a memory space or object graph). applications and systems consisting of smaller redundant subsystems do work, however
<thijso>
White_Flame: well, that, and a host of other orthonogal 'simplicities'
<guaqua>
you can make those run virtually forever
Cymew has joined #lisp
<aeth>
guaqua: Yes, you need redundant software and redundant hardware. So I'm guessing if something takes p computing power, then it probably is, idk, maybe consuming 5p or 10p in the end...
<aeth>
Not to mention being harder to program.
<White_Flame>
every operation has a chance to fail
<White_Flame>
and might have issued external effects during that failure or not
<aeth>
White_Flame: Yes, after all of this, there's always a chance that it doesn't work anyway.
<White_Flame>
I simply mean that in terms of creating the error handling and robustness code, there's a massive onslaught of failure conditions to consider
<guaqua>
luckily not every line of business is as critical to odd failure. and in my experience many of the things tend to fail somewhat rarely. but this is just one system at one company with one quality culture
<White_Flame>
many of which do not have an obvious cleanup, mitigation, or retry
<guaqua>
theoretical and practical considerations are a bit different :)
<guaqua>
for some things you need to do the painful engineering to handle all errors, make it 100% robust. for some others a simple manual retry triggered by hand the next morning might be enough
notzmv has quit [Remote host closed the connection]
<aeth>
"retry... the next morning" is the best kind of engineering
milanj has joined #lisp
Josh_2 has quit [Remote host closed the connection]
Josh_2 has joined #lisp
hiroaki has joined #lisp
<shrdlu68>
ralt: Don't the "container orchestration" tools meet your need for high availability?
<ralt>
they don't usually handle data all that well
<ralt>
Maybe I'm just looking at the wrong problem, i.e. trying to reconcile "let's use lisp live upgrade facilities" and "real world cloud servers die all the time"
<shrdlu68>
I don't understand. You mean that CAP theorem stuff?
<White_Flame>
then maybe you do actaully want erlang
<White_Flame>
as its live update has specific staging points and is less ad hoc
<ralt>
but I like lisp :(
<White_Flame>
well, then build the OTP features in lisp
<ralt>
I guess that's the only way out :)
fragamus has joined #lisp
<White_Flame>
but again, live update reduces the need for scheduled maintenance style downtime but doesn't eliminate downtime
jonatack has quit [Ping timeout: 245 seconds]
<ralt>
it doesn't?
<ralt>
isn't the function replacement atomic?
<White_Flame>
no, but even if it were, it doesn't eliminate downtime due to crashes, bugs, user error, hardware failure, etc
<shrdlu68>
ralt: I'm not convinced there is any advantage to live upgrades versus, for example, rolling upgrades in something like Kubernetes.
<jdz>
ralt: It's very rare that a single function can be updated independently.
<jdz>
If a function has changed, it probably uses other functions that also have changed.
<ralt>
ah, right
<ralt>
way to shatter my dreams
<jdz>
So basically what is needed is to replace all the code, and then move the data to the new codebase (probably fixing it). Exactly what OTP in Erlang does, as far as I know.
<White_Flame>
what erlang does is continue calling your old code when it's inside a module, and external calls to it call the new version
<White_Flame>
so a single stack stays in a unified version
<White_Flame>
and things shoudl "eventually" unroll and reenter, with the new version
shka_ has joined #lisp
<shrdlu68>
Exactly what happens in the stateless "container orchestration" world, only it's a whole "ecosystem" working together rather than a single language's model.
niceplace has quit [Read error: Connection reset by peer]
niceplace has joined #lisp
fragamus has quit [Ping timeout: 252 seconds]
<shrdlu68>
They tackled the same problem at the network layer, essentially.
<jdz>
Except the Erlang model is not stateless.
<jdz>
The state is maintained.
<shrdlu68>
You still have to deal with the problem at the network layer if you want rolling upgrades and high availability.
hhdave has joined #lisp
gxt has joined #lisp
hhdave has quit [Client Quit]
__jrjsmrtn__ has joined #lisp
<shrdlu68>
lfarm looks interesting at first blush, but I suspect if one attempted to hack together a "distributed computing" platform based on it on would end up with an ad-hoc, informally-specified...
devon has joined #lisp
<devon>
Anybody there?
_jrjsmrtn has quit [Ping timeout: 265 seconds]
<White_Flame>
nope
<no-defun-allowed>
no
<devon>
LOL what's the best way to make a programmatic input stream, e.g., one that produces all the digits of π?
<no-defun-allowed>
Well, Gray streams are the standard for programmatic streams, but producing the digits of π is still your problem.
<shrdlu68>
devon: What's one way?
<White_Flame>
just use an iterator
<White_Flame>
or if you want better throughput, fill a buffer with results, and keep a double buffer full
<White_Flame>
keeping a pipeline of filled buffers, depending on your tuning parameters
FreeBirdLjj has quit [Remote host closed the connection]
bnmcgn has quit [Remote host closed the connection]
shrdlu68 has joined #lisp
FreeBirdLjj has joined #lisp
shangul has joined #lisp
karlosz has quit [Quit: karlosz]
EvW has quit [Ping timeout: 245 seconds]
FreeBirdLjj has quit [Ping timeout: 240 seconds]
amerlyq has quit [Ping timeout: 268 seconds]
LiamH has joined #lisp
Oladon has joined #lisp
retropikzel has joined #lisp
makomo_ has joined #lisp
makomo has quit [Ping timeout: 268 seconds]
isBEKaml has joined #lisp
jxy has quit [Quit: leaving]
shangul has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 240 seconds]
shangul has joined #lisp
beach has quit [Read error: Connection reset by peer]
FreeBirdLjj has joined #lisp
jao has quit [Ping timeout: 252 seconds]
Oladon1 has joined #lisp
gxt has quit [Ping timeout: 260 seconds]
jxy has joined #lisp
Oladon has quit [Ping timeout: 265 seconds]
shrdlu68 has quit [Quit: WeeChat 2.5]
adom` has joined #lisp
Cymew has joined #lisp
isBEKaml has quit [Quit: leaving]
gareppa has joined #lisp
rippa has joined #lisp
makomo_ is now known as makomo
liberiga has quit [Ping timeout: 260 seconds]
shangul has quit [Ping timeout: 240 seconds]
hhdave has quit [Quit: hhdave]
gareppa has quit [Remote host closed the connection]
vaporatorius has joined #lisp
vaporatorius has joined #lisp
shangul has joined #lisp
knicklux has joined #lisp
frgo_ has quit [Remote host closed the connection]
frgo has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
Lord_of_Life_ has joined #lisp
frgo_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 268 seconds]
frgo has quit [Ping timeout: 245 seconds]
Lord_of_Life_ is now known as Lord_of_Life
FreeBirdLjj has joined #lisp
FreeBirdLjj has quit [Ping timeout: 240 seconds]
FreeBirdLjj has joined #lisp
duuqnd has quit [Ping timeout: 265 seconds]
Oladon1 has quit [Quit: Leaving.]
duuqnd has joined #lisp
beach has joined #lisp
ggole has quit [Ping timeout: 245 seconds]
ggole has joined #lisp
ym has quit [Read error: Connection reset by peer]
gareppa has joined #lisp
zaquest has quit [Remote host closed the connection]
fragamus has quit [Ping timeout: 265 seconds]
zaquest has joined #lisp
cosimone has quit [Quit: Quit.]
t58 has joined #lisp
jao has joined #lisp
gxt has joined #lisp
karlosz has joined #lisp
m00natic has quit [Remote host closed the connection]
matijja has joined #lisp
nika_ has quit []
igemnace has quit [Ping timeout: 245 seconds]
fragamus has joined #lisp
retropikzel has quit [Remote host closed the connection]
Oladon_work has joined #lisp
fragamus has quit [Ping timeout: 245 seconds]
prite has quit [Ping timeout: 265 seconds]
gareppa has quit [Quit: Leaving]
igemnace has joined #lisp
karlosz has quit [Quit: karlosz]
Cymew has quit [Ping timeout: 240 seconds]
yoeljacobsen has quit [Ping timeout: 245 seconds]
EvW has joined #lisp
<jasom>
does the lisp standard define what combinations 2-ary multiplies (* A B C D) is equal to, or is any algebraically equivalent calculation valid?
<jasom>
obv. it only matters for inexact numeric representations.
edgar-rft has joined #lisp
<pjb>
jasom: the arguments are evaluated from left to right, but the standard doesn't impose an order of association or commutation for the evaluation of the operation per se.
<jasom>
pjb: that's what I thought; so there is no guarantee e.g. that (= (* A B C D) (* (* (* A B) C) D))
<pjb>
jasom: so an implementation could do (* (* (* a b) c) d) or (* a (* b (* c d))) or (* (* a d) (* b c)) or anything else.
<jasom>
right
<pjb>
Indeed, you may obtain different results, notably when using floating point numbers.
* jasom
hates floating point
<pjb>
You can use ratios!
<pjb>
Or if you want consistent results, you may sort your arguments yourself.
<jasom>
at least with log-scaled numbers addition and subtraction are so difficult that you avoid it.
ralt has quit [Quit: Connection closed for inactivity]
<jasom>
pjb: oh, does the standard forbid reordering (* (* (* A B) C) D)?
<pjb>
the implementation can re-order as it wishes.
<jasom>
interestingly enough, without the IEEE addendum, C permits algebraic rewriting of floating point operations (though most compilers with FP support implement the IEEE addendum).
Necktwi has quit [Quit: leaving]
<pjb>
That said, I don't know any implementation doing much reordering or sorting the arguments by type. Usually they'll just left associate.
<jasom>
The nice thing is that good support of ratios allows me to treat FP as an optimization rather than the easiest way to perform fractional calculations.
<jasom>
hmm, looking in scrollback, devon might be interested in computable-reals which has an arbitrary precision pi.
<Bike>
and parent are the explicit statement if you want that
<Bike>
phrased in terms of conversions instead, but still
akoana has joined #lisp
<jasom>
but optimizing across function-call boundaries when the results would differ is disallowed
<jasom>
e.g. rewriting (* A (+ B C)) to be (+ (* A B) (* A C))
<jasom>
(or the reverse of what I said which would actually be an optimization)
sauvin has quit [Read error: Connection reset by peer]
fragamus has quit [Ping timeout: 276 seconds]
gareppa has joined #lisp
prite has joined #lisp
ym has joined #lisp
varjag has joined #lisp
logicmoo is now known as dmiles
bjorkintosh has quit [Quit: Leaving]
ggole has quit [Quit: Leaving]
bjorkintosh has joined #lisp
<aeth>
pjb, jasom: There is sort of a guarantee... that a quality floating point implementation won't mess with floating point order. I see no reason to use ratios instead of floating point. If an implementation chooses to mess with floating point algorithms, that's on them.
<aeth>
Bike, jasom: I don't think SBCL does mess with constant for floating point. I remember seeing that they didn't even optimize away multiplication by 0.0f0 in their generated assembly.
<aeth>
s/constant/constants/
<jasom>
aeth: multiplying NAN or INF by 0.0f0 results in a non-zero value
<aeth>
I'm unsure about mixed operations like (* 4 x 1/2) though
adom` has quit [Remote host closed the connection]
<aeth>
jasom: yes, that's probably why, you can disable floating point traps in most implementations to get the underlying IEEE float with the NANs and INFs
<aeth>
(instead of an exception)
<jasom>
aeth: the biggest problem with floting point is addition/subtraction are dangerous. That's why I use ratios by default.
<aeth>
jasom: floating point has many issues, I'd restrict its use in general to implementing known numerical algorithms that other people came up with, if you care about accuracy.
<aeth>
fortunately, there's a lot of them.
<White_Flame>
dangerous how? in that a large + small number might effectively be a no-op?
<White_Flame>
or fear of overflow/nan/inf operations?
<jasom>
White_Flame: ~1.0 + ~(-1.0) = some small number
yoeljacobsen has joined #lisp
<jasom>
White_Flame: multiplicative operations will lose at most 1ULP of accuracy, additive operations can leave you with complete garbage.
<White_Flame>
hmm, that part doesn't seem specifically "dangerous" to me
<jasom>
White_Flame: e.g. there are multiple FP implementations for the quadradic equation depending on the signedess of the b, 4ac parts.
<Bike>
the different parts, not just the discriminant?
cosimone has joined #lisp
<jasom>
sorry, the disciminant (and B, depending on your thoughts of having the sgn function in your equation).
<Bike>
ah. still, interesting
<jasom>
It's the most well known function that involves catastrophic loss of precision, so it's the canonical example.
<jasom>
The pythagorean theorum can show some oddities when you are far from the origin as well, which is yet another argument for not using floats for coordinates.
<White_Flame>
yeah, and I've done some 3d graphics stuff far away from the origin which starts aliasing badly as well
<jasom>
There are approximately zero cases in which it makes more sense to use a double float than a 64-bit integer for a coordinate system. (doubles made some sense when it was faster to add 2 doubles than 2 64-bit integers).
<aeth>
jasom: eh, depends
<aeth>
If you want performance over accuracy and it's for a game and you're going to be converting to float dozens of times a second...
<aeth>
You'd probably only be forced to use integers on star-system-scale maps
<jasom>
yeah, if your hardware requires floats, then you are stuck.
<White_Flame>
also, you'll be dealing with fixed point multiplication & reducing from 128-bit results
<White_Flame>
(which of course is fine in Lisp, can be a pain elsewhere)
<aeth>
jasom: the thing is, in games you want performance, not precision, and in scientific calculations, you can just use a fancier algorithm to get your error small enough since it's inexact anyway
<aeth>
so float is a lot more useful than you make it sound
<Bike>
i think most scientists' engagement with numeric algorithms is ignoring matlab warnings that a matrix is near singular
maxxcan has joined #lisp
<aeth>
(and many of the issues with float are the issues with not using hardware decimal float, which is the fault of hardware makers, not float)
<jasom>
Bike: lol
maxxcan has quit [Client Quit]
cosimone has quit [Quit: Terminated!]
stepnem has joined #lisp
bitmapper has quit []
<jasom>
Bike: more seriously the field is split between those super familiar with the limitations of the computational hardware, and the rest of the field, where the best you can hope is that they use libraries written by the former.
<aeth>
Bike: well, most of this thought should be moved to a library and not thought about at each use, e.g. a CL implementation of BLAS
<Bike>
i mean, i've generally been impressed by matlab's treatment. documentation with citations is pretty nice
<Bike>
maybe it's different in physics, but i have my doubts
stepnem has quit [Ping timeout: 245 seconds]
Oladon_work has quit [Quit: Ping timeout (120 seconds)]
stepnem has joined #lisp
jonatack_ has joined #lisp
elimik31 has quit [Ping timeout: 276 seconds]
jonatack has quit [Ping timeout: 250 seconds]
notzmv has joined #lisp
jonatack_ has quit [Ping timeout: 240 seconds]
vlatkoB has quit [Remote host closed the connection]
jonatack_ has joined #lisp
scymtym has quit [Ping timeout: 245 seconds]
orivej has joined #lisp
shangul has quit [Ping timeout: 276 seconds]
lavaflow has quit [Ping timeout: 240 seconds]
EvW has quit [Ping timeout: 264 seconds]
jonatack_ has quit [Quit: jonatack_]
jonatack has joined #lisp
cosimone has joined #lisp
raghavgururajan has quit [Remote host closed the connection]
karlosz has joined #lisp
FreeBirdLjj has quit [Read error: Connection reset by peer]
Oladon_work has joined #lisp
FreeBirdLjj has joined #lisp
Jesin has quit [Quit: Leaving]
yoeljacobsen has quit [Ping timeout: 240 seconds]
lavaflow has joined #lisp
EvW1 has joined #lisp
asdf_asdf_asdf has joined #lisp
duuqnd has quit [Ping timeout: 240 seconds]
Jesin has joined #lisp
sjl has quit [Quit: WeeChat 2.2-dev]
gravicappa has quit [Ping timeout: 268 seconds]
xrash has joined #lisp
abhixec has joined #lisp
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
adeht is now known as _death
karlosz has quit [Quit: karlosz]
fragamus has joined #lisp
scymtym has joined #lisp
fragamus has quit [Ping timeout: 268 seconds]
raghavgururajan has joined #lisp
nanoz has quit [Quit: Leaving]
jao has quit [Ping timeout: 265 seconds]
bitmapper has joined #lisp
matijja has quit [Ping timeout: 265 seconds]
mindCrime_ has quit [Ping timeout: 246 seconds]
lavaflow has quit [Ping timeout: 245 seconds]
Jesin has quit [Quit: Leaving]
remexre has quit [Quit: WeeChat 2.4]
remexre has joined #lisp
gareppa has quit [Quit: Leaving]
sunwukong has joined #lisp
jao has joined #lisp
raghavgururajan has quit [Read error: Connection reset by peer]
<jasom>
Hmm, CLISP's long-float pi value is off by more than one ULP for very large precision values
<jasom>
nevermind, the first hit in google for "100000 digits of pi" was wrong.
moldybits has quit [Ping timeout: 268 seconds]
Jesin has joined #lisp
invergo has joined #lisp
invergo has quit [Changing host]
invergo has joined #lisp
shka_ has quit [Ping timeout: 268 seconds]
lavaflow has joined #lisp
invergo has quit [Remote host closed the connection]
<pjb>
Bike: it's different in physics. For example, you will find that the circumference of the Earth is not 2πr, but it's smaller. Because of relativity.
varjag has quit [Ping timeout: 240 seconds]
invergo has joined #lisp
invergo has quit [Changing host]
invergo has joined #lisp
<Xach>
ha
<no-defun-allowed>
Hopefully you aren't using your program at 0.9c then.
<clothespin>
How many hours a week do people here program?
<pjb>
Theorically 100% of the time. Including dream time…
<pjb>
In practice a little less.
<no-defun-allowed>
I try to program about 12 hours a week, but I'd say I'm only productive for 4 to 6 hours.
<clothespin>
I go bonkers if i program more than 30 or so
<pjb>
I'm going bonker when I program less than that…
<clothespin>
i'm around 20 to 24
<clothespin>
are you able to get something good done when you only have an hour or so before you have to go somewhere?
<clothespin>
i have to have at least 2 hours to zone-in
<Oladon_work>
Depends on how well I've scoped out next steps
<jasom>
clothespin: that takes practice
<jasom>
clothespin: also, keep notes *somewhere* about what needs to be done next before you leave; that means stopping work 5 minutes earlier than you would otherwise, but if it saves you an hour of time to zone-in on the otherside, it's easily worth it.
<Oladon_work>
It's a fallacy that you have to be "zoned in" in order to be productive — to maximize productivity, perhaps, but if you've scoped out the project (or part of the project) well and appropriately, you can pick up one piece much more easily.
<Oladon_work>
Also, what jasom said.
<clothespin>
i keep a journal with a detailed todo list in evernote
<Oladon_work>
"detailed todo list" says nothing about the quality of the scoping :)
<jasom>
clothespin: I'm more thinking a brain-dump; I tried X, Y, and Z, they didn't work because Q, so I'm going to change directions and investigate W next.
<jasom>
enough touchstones to get your brain back to where it was the last time you were working.
<clothespin>
the state of my emacs buffers does that for me
<jasom>
I would argue it doesn't if it takes you 2 hours to start being productive :P
<clothespin>
i think it's more of an issue of relaxing my mind
invergo has quit [Quit: rcirc on GNU Emacs 26.3]
<clothespin>
i have to put on music, maybe get a cup of coffee, finish email
<jasom>
That's partly practice, and partly self-introspection. You will get better at getting in the flow with practice, but you'll also want to analyze why can't you do so without (for example) checking your e-mail?
<clothespin>
i just see these folks with macbooks hacking every opportune second of the day
Oladon_work has quit [Ping timeout: 260 seconds]
<clothespin>
i could get back in the flow easier when i was younger
<jasom>
IMO that's partly due to them having poor time management skills ;) but also some types of coding are more routine than others. I can speed up a poorly performing program with my brain half-off, and similar for porting code. For debugging something (particularly something hard to reproduce), I need maximum focus.
raghavgururajan has joined #lisp
<clothespin>
yes, i agree. when i was running test scripts ob builds i could hack for 5 minutes
<clothespin>
now that i'm doing more architecture and i want elegant solutions i have to slow down
igemnace has quit [Quit: WeeChat 2.6]
caltelt has joined #lisp
<clothespin>
i was just curious as to what other programmer's habits are
<jasom>
clothespin: for that, it can help to invert things a bit; collect problems and whenever you learn a new elegant solution, try each problem against it.
<clothespin>
another weird thing is that i only scratch the surface using emacs keybindings
<clothespin>
i need to spend a couple of days getting my hadns used to more
bitmapper has quit []
sunwukong has quit [Remote host closed the connection]
<clothespin>
jasom: what do you mean exactly? I code crap until i see the elegant solution, then i rewrite until the crap goes away and repeat
<jasom>
clothespin: basically
<clothespin>
coding even crap in lisp basically helps you devise the solution faster
<clothespin>
i haven't written a flowchart since 1992
lavaflow has quit [Ping timeout: 240 seconds]
<clothespin>
I literally dreamed of a solution to avoid extra destinations for coordinates in generating vertex buffers
<clothespin>
at the expense of a little more gpu memory
<clothespin>
but it was like 3 am running through my brain over and over
<clothespin>
supposedly the dude who discovered benzene did so in his sleep
lavaflow has joined #lisp
bitmapper has joined #lisp
asdf_asdf_asdf has quit [Quit: asdf_asdf_asdf]
<clothespin>
well thanks for making me feel normal peeps, those guys with the macbooks on the train had me worried i was a less productive hacker
<pjb>
clothespin: ask fade, he does that.
<pjb>
s/fade/fare/
<clothespin>
I think Andreas Fuchs and Carl Shapiro doe that too but those guys are just exceptional
ltriant has joined #lisp
zbrown has quit [Ping timeout: 246 seconds]
fragamus has joined #lisp
abhixec has quit [Quit: leaving]
zbrown has joined #lisp
igemnace has joined #lisp
hdasch has quit [Ping timeout: 246 seconds]
hdasch has joined #lisp
Bike has quit [Quit: Bike]
zmt00 has joined #lisp
raghavgururajan has quit [Read error: Connection reset by peer]
igemnace has quit [Quit: WeeChat 2.6]
cosimone has quit [Ping timeout: 245 seconds]
prite has quit [Ping timeout: 268 seconds]
dreamcompiler has joined #lisp
xrash has quit [Ping timeout: 240 seconds]
permagreen has quit [Remote host closed the connection]
akoana has left #lisp ["Leaving"]
karlosz has joined #lisp
fragamus has quit [Ping timeout: 276 seconds]
Oladon has joined #lisp
LiamH has quit [Quit: Leaving.]
t58 has quit [Quit: Leaving]
karlosz has quit [Quit: karlosz]
karlosz has joined #lisp
karlosz has quit [Remote host closed the connection]
karlosz has joined #lisp
karlosz has quit [Remote host closed the connection]
karlosz has joined #lisp
karlosz has quit [Remote host closed the connection]
karlosz has joined #lisp
karlosz has quit [Remote host closed the connection]