freenode/lisp - IRC Chatlog
Search
2:03:13
kinope
I stopped by yesterday under the name Decs. I program just as a hobby. I hope it's cool if I can pop by in the future if I have questions, not sure if I personally have much to offer others just yet in that capacity though.
2:17:37
kinope
I do have a question about closures. I'm working on a project where I made my object classes from closures (experimenting with material from Let Over Lambda). I was informed that it's unusual to do that, and to use the standard class facilities presest in Common Lisp. Is this a matter of aesthetics or is it rooted in practicality or performance considerations. I'm genuinelly curious as I don't understand the parts at play
2:50:51
beach
kinope: The language has no particular tools for inspecting closures, whereas there is a rich set of tools for standard objects. Dispatch is slow/sequential with closures, and you have to do it manually. with generic functions, dispatch is fast and built in. With a closure, all "method" must appear in the same source code, whereas with standard classes, they can be spread out. Generic functions have features such as auxiliary
3:19:32
kinope
beach: Thanks for that information, it's very helpful. Now I'm interested to see if the runtime overhead of my project can be reduced by making the switch.
3:26:00
kinope
I run a test that queues up 10 million messages and then dispatches them all sequentially right after usually takes between 2-2.5 minutes. I would totally switch out those components just to satisfy my curiosity. But don't worry the other features are not lost on me either.
3:30:07
kinope
beach: Although right now I am a bit partial to having the methods all heaped together visually, I can see that as the classes get bigger they will get unwieldy.
3:33:53
kinope
I have considered blowing the dust of my laptop to see it running on sbcl but right now I am constrained to use the implementation that will run inside termux on my android phone.
3:35:09
kinope
I'm not super concerned over performance right now though, it's just a toy framework at this stage.
3:45:57
kinope
I have yet to use the facilities provided by CLOS, so in the interest of growing my knowledge and also in the interest of not taking pride in being unorthodox without reason, I'm going to rewrite my closure classes as standard ones. Any performance improvements will be a bonus.
7:42:29
beach
True. But radians are not real units. It is sometimes convenient to think of them as such, but they really aren't.
7:55:39
beach
Posterdati: But if you multiply a value by 2*pi, does it change the unit? Like if you have a distance of 2km and multiply it by 2*pi, do you now have km*rad/cycle?
7:56:19
no-defun-allowed
Posterdati: Read the backlog. I did, and I got 6.283... rad/s, or 2π rad/s, or 1 cycle/s
7:58:16
Posterdati
beach: you always have a 2pi constant which is not the case, look for example at the formula for the eddy current loss there is f not omega!
8:36:44
easye
Is there a defined "rounding-mode" for internal operations in ANSI? I seeminly need to choose among <https://docs.oracle.com/javase/8/docs/api/java/math/RoundingMode.html> for ABCL.
8:37:17
Posterdati
no-defun-allowed: again 1 hertz != 6.28... rad/s, frequency is not angular velocity
8:38:46
easye
Guess I will go with HALF_EVEN Rounding mode to round towards the "nearest neighbor" unless both neighbors are equidistant, in which case, round towards the even neighbor.
8:47:01
easye
I'm try to the code that gives a double-float from a ratio for values between least-positive-normalized-double-float and least-positive-double-float in java. Need to pick a rounding algorithim.
8:54:14
easye
Upon further rubber ducking of my question, I don't think it would be covered in ANSI Common Lisp.
9:19:40
edgar-rft
easye: CLHS ROUND says: round and fround produce a quotient that has been rounded to the nearest mathematical integer; if the mathematical quotient is exactly halfway between two integers, (that is, it has the form integer+1/2), then the quotient has been rounded to the even (divisible by two) integer.
10:45:42
phoe
Online Lisp Meeting #2 starts in 15 minutes. Speaker: Michael Raskin, "Integrating with UNIX from Common Lisp via FS API" - https://www.twitch.tv/TwitchPlaysCommonLisp
10:49:28
phoe
Michael said that now is the best time for him, plus the times are fluid to suit the presenter the best
10:50:26
phoe
Plus, 13:00 CEST seems like a time that can suit the eveningpeople from Australia, afternoon people from Asia, midday people from Europe, and all the poor souls from Americas who need to wake up early
10:51:39
phoe
but, I don't want to stick to a single time - whenever the author says they would like the meeting to be held, I will attempt to hold it
11:47:06
MichaelRaskin
Technically I did not say it is better than Tue 18:00, just the same — but indeed it covers well the people overseas for whom 18:00 CEST was bad.