This is one of those rare times when I read something coming out of the FP community and go "oh, you mean iterators, we've had those for decades over here in imperative-programming land"
Are arrays functions?
71–80 of 145 posts
Re: Are arrays functions?
#72No, not in a programming language sense, because arrays are a notation for address offsetting, whereas functions change the execution context of the machine, which is critical to processing performance (think Horner's method). Not even in a functional sense because, even though functions are input-output maps we define, the inputs are dimensionally rich, it's nowhere close to equivalent to jerry rig a contiguous inpu…
> arrays are a notation for address offsetting
That's an implementation detail, though.
Re: Are arrays functions?
#73Earlier quoted context omitted.
> It was odd to me, because it hadn't really occurred to me before that, given infinite memory (and within a mathematical framework), there's fundamentally not necessarily a difference between a "list" and a "function". You don't even need infinite memory. If your function is over a limited domain like bool or u8 or an enum, very limited memory is enough. However the big difference (in most languages) is that functio…
> However the big difference (in most languages) is that functions can take arbitrarily long. Array access either succeeds or fails quickly. For some definition of quick. Modern CPUs are usually bottlenecked by memory bandwidth and cache size. So a function that recomputes the value can often be quicker than a look up table, at least outside of microbenchmarks (since in microbenchmarks you won't have to compete with…
I've been watching those Kaze Emanuar videos on his N64 development, and it's always so weird to me when "doing the expensive computation again" is cheaper than "using the precomputed value". I'm not disputing it, he seems to have done a lot of research and testing confirming the results and I have no reason to think he's lying, but it's so utterly counter-intuitive to me.
Re: Are arrays functions?
#74I remember I got a little confused when I was first learning TLA+, because what you normally call "functions" are "operators" [1], and what you'd normally call "maps" or "lists" are called "functions". It was odd to me, because it hadn't really occurred to me before that, given infinite memory (and within a mathematical framework), there's fundamentally not necessarily a difference between a "list" and a "function".…
I remember having a similar sort of realization early in my career when trying to implement some horribly convoluted business logic in SQL (I no longer remember the actual details of what I was trying to do, just the epiphany which resulted; I think it had something to do with proration of insurance premiums and commissions): I realized that if I simply pre-computed the value of the function in question and shoved it…
I've seen this as a "solution" to implementing a function for fibbonacci numbers. The array of all of the fibbonacci numbers that can fit into a 32-bit integer is not particularly large, so sticking it into a static local variable is easy to do.
Re: Are arrays functions?
#75>Futhark supports a fairly conventional Python-like notation for array slices, namely a[i:j]. This does not have such a simple correspondence with function application syntax.
I don't get it. How is that not trivial with something like
array·slice(from: initial, to: juncture)
Re: Are arrays functions?
#76>Futhark supports a fairly conventional Python-like notation for array slices, namely a[i:j]. This does not have such a simple correspondence with function application syntax. I don't get it. How is that not trivial with something like array·slice(from: initial, to: juncture) Which is not much different from a·/(i,j) when one want to play the monograph game instead. It can be further reduced to a/(i,j) taking from gr…
The post explains that 'a[i]' can easily enough be written as 'a i'. Your suggestions do not resemble the current function application syntax in the language discussed in the post. The question is not whether a terse slice syntax can exist (clearly it can), but whether a syntactic similarity between indexing and application can also be extended to a syntactic similarity between slicing and application.
Re: Are arrays functions?
#77From a mathematical point of view, a real vector of length n is a function from Z_n to R.
When I was learning programming, I was surprised that in most programming languages we write f(k), but vec[k].
However, we do have syntax vec.at(k) or vec.get(k) in quite a few languages.
Re: Are arrays functions?
#78I think a more interesting extension would be to see objects as functions. An object maps a set of keys to values. In most languages those keys must be strings. But I don't see why they couldn't be anything. For instance a key could be a function, and to access the value of such a key you would need to pass in exactly that function like this: let v = myObject [ myFunk ]; Like with arrays-as-functions, the domain of t…
Yes, we can look at an object as a function that accepts a key and returns a value (or null). Depends on language, it's called a set, map, or associative list.
type AnObject = {
[key: any]: any
}
type FunkyObject = (key: any) => Maybe
type FunkyList = (index: number) => Maybe
type FunkyVariable = (name: string) => Maybe
type FunkyOperator = (name: string, ...values: any) => any
FunkyOperator('+', 1, 2) // => 3
So we approach some kind of functional language land where all data structures are modeled using functions.
Re: Are arrays functions?
#79> Composition is like applying a permutation array to another
Composing injective functions is like applying a permutation array to another.
Re: Are arrays functions?
#80This is one of those rare times when I read something coming out of the FP community and go "oh, you mean iterators, we've had those for decades over here in imperative-programming land"
Traditional FP has had functional equivalents to iterators since before most imperative languages existed. LISP had a map function (MAPCAR) in its earliest versions, in the 1950s. Later that was generalized to folds, and the underlying structures were generalized from linked lists to arbitrary “traversable” types, including unbounded streams.
The language in the OP is a special-purpose language for data parallelism, targeting GPUs, and explicitly described as “not intended to replace existing general-purpose languages” (quote from the language’s home page.) As such, it has requirements and constraints that most languages don’t have. Looking at its design through a general-purpose languages lens doesn’t necessarily make sense.