Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Are arrays functions?

futhark-lang.org

Post reply on HN
Print view View original

81–90 of 145 posts

Re: Are arrays functions?

#81

Post by geocar »

psychoslave wrote: post #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) 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 "monograph game" as you put it, is not for mere funsies: We say x+y instead of plus(x,y) because the former is obviously better.

Re: Are arrays functions?

#82

Post by diimdeep »

> Arrays are functions whose domains are isomorphic to contiguous subsets of the integers

Yes. And a sandwich is "a stack-based heterogeneous data structure with edible semantics." This is not insight. It is taxonomy cosplay.

Look, arrays and functions share some mathematical structure! - Irrelevant. We do not unify them because representation matters.

When a language makes arrays "feel like functions," what it usually means is: "You no longer know when something is cheap." That is not abstraction. That is obscurity.

Industry programmers do not struggle because arrays lack ontological clarity. They struggle because memory hierarchies exist, cache lines exist, branch predictors exist, GPUs exist, deadlines exist.

> the correspondence between arrays and functions [...] is alluring, for one of the best ways to improve a language is to make it smaller

No. The best way to improve a language is to make it faster, simpler to reason about, and less painful to debug.

> I imagine a language that allows shared abstractions that work for both arrays and appropriate functions

What if we invented increasingly abstract our own words so we don’t have to say ‘for loop’, map, SIMD, kernels?

Making arrays pretend to be functions achieves exactly none of those things. It achieves conference papers that end with “future work”.

Why is this academic slop keep happening ? - Professors are rewarded for novel perspectives, not usable ones.

Re: Are arrays functions?

#83

Post by riazrizvi »

gf000 wrote: post #72
riazrizvi wrote: post #61

No, 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.

No, not when you're designing processes based on a Von Neumann (sequential RAM) architecture. This is the characteristic feature of what the 'array tool' represents.

Re: Are arrays functions?

#84

Post by Athas »

riazrizvi wrote: post #83
gf000 wrote: post #72

Earlier quoted context omitted.

> arrays are a notation for address offsetting That's an implementation detail, though.

No, not when you're designing processes based on a Von Neumann (sequential RAM) architecture. This is the characteristic feature of what the 'array tool' represents.

That depends on the language. I have used (and implemented) languages where arrays are modeled as a function from an index space to some expression. During compilation, this is used to drive various optimisations. For those arrays that need a run-time representation, they may be stored in the classic way (a dense region of memory accessed with offsets computed from indexes), but also in more complicated ways, such as some kind of tree structure. These are still, semantically, arrays at the language level.

Re: Are arrays functions?

#85

Post by lioeters »

sethev wrote: post #28

In Clojure, vectors literally are functions. You can supply a vector (~= array) or map any place that a single parameter function is expected. So for example: (map v [4 5 7]) Would return you a list of the items at index 4, 5, and 7 in the vector v.

That'a great example that demonstrates the idea in the article. And it concisely shows a functional insight in the language design of Clojure. I'm not a daily Lisp user yet, but as I learn more about it, I'm drawn to its many charms.

Re: Are arrays functions?

#86

Post by volemo »

geocar wrote: post #81
psychoslave wrote: post #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) 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 "monograph game" as you put it, is not for mere funsies: We say x+y instead of plus(x,y) because the former is obviously better.

I say (+ x y). :P

Re: Are arrays functions?

#87

Post by noelwelsh »

eru wrote: post #36
tombert wrote: post #5

I 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".…

> 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…

It's a classic space / time trade-off. The special relativity of programming, if you like.

Re: Are arrays functions?

#88

Post by VorpalWay »

tombert wrote: post #73
VorpalWay wrote: post #68

Earlier quoted context omitted.

> 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.

I haven't looked into N64, but the speed of CPUs has been growing faster than the speed of RAM for decades. I'm not sure when exactly that started, probably some time in the late 80s or early 90s, since that is about when PCs started getting cache memory I believe.

Re: Are arrays functions?

#89

Post by lejalv »

This reminds me of funsors in the Pyro probabilistic programming language. From the design document (https://docs.google.com/document/d/1NVlfQnNQ0Aebg8vfIGcJKsnS...)

    Functions are first class objects. Funsors generalize the tensor interface to also cover arbitrary functions of multiple variables ("dims"), where variables may be integers, real numbers or themselves tensors. Function evaluation / substitution is the basic operation, generalizing tensor indexing. This allows probability distributions to be first-class Funsors and make use of existing tensor machinery, for example we can generalize tensor contraction to computing analytic integrals in conjugate probabilistic models.
More in the paper: https://arxiv.org/abs/1910.10775

Re: Are arrays functions?

#90

Post by galaxyLogic »

lioeters wrote: post #78
galaxyLogic wrote: post #66

I 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 Then we can see arrays as a limited type of object/function that only accepts a number (index) as key. type FunkyList = (index: number) => Maybe We can even consider any variable as a f…

Yes, and as you point out even conditional statements.

In Smalltalk constructs like

   b ifTrue: [ ... ]
mean that the boolean value 'b' has its method (-function) ifTrue: called with the argument [...] which is a "closure" meaning it is a free-standing function (as opposed to bound functions which are the methods).

There are similarly library methods in class Boolean for whileTrue: etc. Functions all the way.

What would be the point of implementing conditional statements as methods/functions? It makes it posssible to extend the set of conditional statements to for instance 3-valued logic by adding a method #ifTrue:ifFalse:ifUnknown: . And of course it makes the syntax of the language very simple.

Post reply on HN