libera/#sicl - IRC Chatlog
Search
19:21:21
moon-child
mfiano: my understanding of 'type stability' as introduced by julia is that there is a strong correlation between a given function's parameter types and its result type. Which would seem to be the case here. No?
19:53:18
mfiano
In a more specific example than what was given, ASIN or ACOS can result in a different return type than either the inputs or the inferred types of intermediary calculations.
19:54:37
mfiano
The fact that there is only one function for the compiler to optimize, instead of several for different types, or using something like SBCL's defknown/deftransform introduces a problem
20:03:36
mfiano
If the compiler could infer the return type from the parametric values, it could dispatch at compile time to a more specialized function. Of course, this is not always possible with CL, and is subject to debate on whether it should be punted to the user to write such a compiler macro. The case I am talking about here is when they can return a compound object (of type COMPLEX). But this idea also
20:03:39
mfiano
extends to more specialized functions for the different floating point formats. But again, this is up to debate, for reasons of numerical stability for one, since it is often a good idea to perform intermediary calculations in a wider bit width like double-float for the added IEEE rounding bits.
20:05:25
moon-child
this is where dynamic analysis beats static analysis, imo. You may notice that asin _usually_ returns a non-complex number when given a non-complex number
20:06:17
moon-child
(doesn't have to be dynamic, even. Add a branch hint and you're off to the races)
20:09:18
mfiano
I overthink these things a lot. I have ran into issues where I had to introduce a bit array to get the rounding precision I needed for many chained double-float operations. Numerical stability compounds pretty fast in game development with lots of chained math.
20:09:54
mfiano
Implementing a subset IEEE whenever I need it is not my idea of fun, but sometimes I have to.
20:11:40
mfiano
Some older PC's atually did IEEE754 double calculations in 128bit FPU registers for the added rounding bits. I'm not sure if that is still the case today.
20:16:49
Bike
the glibc implementation of sine actually does like four different things depending on the magnitude of the argument
20:17:15
mfiano
Anyway, you can probably just ignore me. And yeah, I've been using Julia on and off for 7 years now, ever since Tomas Papp switched to it from CL.
20:20:33
mfiano
But maybe I did subconsciously? I did start a little Julia project about a week ago.
20:25:09
moon-child
Bike: it seems to me that it 'does' one thing, and just has a few minor variations on how it does range reduction
20:25:24
moon-child
(and also has a couple of paths where it doesn't do anything: very small, and very large)
20:27:06
moon-child
I am also a bit sceptical of code which relies heavily on lookup tables. They are difficult to benchmark; they may perform very well when you call them in a tight loop, but in a larger application, there are frequently knock-on effects and you can end up thrashing cache
20:27:30
Bike
all i'm thinking is that with a range analysis in the compiler that kind of thing could be avoided sometimes.
20:27:39
moon-child
(which is not to say they are universally bad, only a bit suspicious and to be treated with care)
20:28:13
moon-child
Bike: sounds like the sort of thing partial inlining would take care of. But I'm not sure how common it is to have bounds on floating-point numbers
20:29:06
Bike
sometimes they could be derived, like (sin (the real x)) is going to be between -1 and 1. though that's probably not going to be fed to sin again
21:34:41
moon-child
beach: have you seen https://arxiv.org/pdf/1403.2765.pdf ? I thought it looked interesting
21:35:30
moon-child
Bike: I guess there are a lot of cases where people normalise, or clamp to a unit range. I don't know how common it is to feed the results of such computation directly to a trig function, though
21:59:47
Bike
re generalizers, i kind of have wondered how they could work with beach's dispatch method. haven't thought through the details, but maybe if some kind of hashing protocol was added
22:02:49
Bike
guess what you'd really need is something analogous to class-of/stamp-of? like a partially evaluated generalize-of-using-class
22:11:16
moon-child
makes sense. I was honestly more interested in the interface than the implementation. It's a principled and modular approach to arbitrary-predicates-as-specialisers
22:45:16
Bike
yes, it seems solid. i'd just like to see an interface that supports efficient implementation like clos/mop generally
3:57:02
moon-child
beach: what is wrong with using the host sin to fill in the lookup table? It seems to me no different from using loop to implement loop
3:57:46
beach
Because the types of floating point supported by the host can be different from those supported by the target.
3:57:52
moon-child
I guess one issue is that the format of floating-point formats is unspecified...right
3:58:22
moon-child
I suppose the proper solution is to have a software fp implementation, as gcc does
3:58:46
beach
Krystof has given that issue a lot of thought actually. In the context of bootstrapping, that is.
4:00:59
beach
Krystof suggested something like that, yes, that there must be some full emulation of the target floating-point system in the host.
4:02:02
beach
But his conclusion was in the context of SBCL. The SICL bootstrapping technique is different.
4:45:46
beach
I suspect it is not material, but I am a slow thinker, so I need time in order to be certain.
4:49:54
moon-child
it seems to require custom hardware. In particular the fine-grained tracking of changes at the level of a single cache line. But if it makes its way into the mainstream, I imagine closos could certainly take advantage of it
4:51:42
beach
You seem to have a lot of ideas in several domains. Are you doing something about those ideas, like writing papers or code?
4:57:14
moon-child
discipline & executive function are very hard, for me. I am trying to make an apl compiler right now
4:58:49
moon-child
I worked out the most important details a couple of months ago, and started on some of the code again recently
5:00:07
moon-child
there is a halo of other things that I would like to get to 'eventually' ... fast sorting/searching (got a 2-4x speedup on one part of this recently), text rendering, natural language generation, probably others I am not thinking of