I am trying to understand the difference between defined and undefined values of recursive functions. Is it similar to programming a loop in an imperative language, like Java, but there is an unseen mistake in the loop structure which causes variables to not contain the values that you were expecting them to contain?
Related
I'm working with some large objects in R and going out of memory is a concern. I want to save on memory by defining them once as global variables, rather than passing them as arguments to functions where they'd be defined twice, once outside the function and once as an argument.
Will this really save memory? If so, is there any "weird" behaviour using global variables this way that I should be aware of?
I am working on a meta-interpreter for a language fragment that needs to be rich enough to support higher-order functions, and running into a problem with closures.
Specifically, I need all values to be representable as finite terms; no infinite recurrence, no objects pointing to each other. This is fine for most kinds of values, numbers, finite lists, maps, abstract syntax trees representing program code. The problem is closures; they contain a reference to their containing environment, but if a closure is stored in a local variable, then that containing environment also contains a reference to the closure. This is fine if you are working with mutable pointers, but it's an infinite recurrence if you are trying to work with finite terms.
Is there a known technique for representing closures as finite terms, or some technique I am missing that bypasses the problem?
I once had a similar problem when I wrote a functional language that used reference counting GC, and therefore had to avoid any cyclic references.
My solution was that the environment didn't actually include a pointer to the closure. Instead, it stored a function that would produce the closure when you pass it a pointer to the environment.
The process of looking up a value from the environment would include calling that function to produce the closure if necessary. That function, of course, doesn't need a cyclic pointer to the environment, because the environment will be passed in.
This trick is basically making recursive data structures in the same way that the Y combinator is used to make recursive functions.
I would like to define a slightly more general version of a complex number in R. This should be a vector that has more than one component, accessible in a similar manner to using Re() and Im() for complex numbers. Is there a way to do this using S3/S4 classes?
I have read through the OO field guide among other resources, but most solutions seem focused around the use of lists as fundamental building objects. However, I need vectors for use in data.frames and matrices. I was hoping to use complex numbers as a template, but they seem to be implemented largely in C. At this point, I don't even know where to start.
Can someone give me explanation for the below sentence highlighted in Bold.
"Primitive functions are only found in the base package, and since they operate at a low level, they can be more efficient (primitive replacement functions don’t have to make copies), and can have different rules for argument matching (e.g., switch and call). This, however, comes at a cost of behaving differently from all other functions in R. Hence the R core team generally avoids creating them unless there is no other option.
Source Link:http://adv-r.had.co.nz/Functions.html#lexical-scoping
I have to write an Excel addin in F#, it does some pretty heavy computations in order to calibrate some curves as a first step in some User Defined Functions.
As a second step, I need re-use the representation of the universe (the curves calibrated in the first step) as an argument for other functions.
When I was doing this in a procedural language with states, I would just return a string handle on the universe which would be an object that I would store in memory. If I am doing this in F#, am I breaking the functional language paradigm ?
Is there an elegant way to do a similar thing without having to do the recalibration in the first step ? Here I am using Excel, but this is a more general question.
Do you mean that if you have user-defined function A and UDF B both of them require calling another function to calibrate? If that's the case, then it sounds like you should memoize the calibration function and have A and B use the memoized function.
As a side note, you should consider disregarding typical academic implementations of memoization and consider one with limits on the upper bound of inputs.
As a side, side note - Excel is one of the most widely used function programming paradigms.