text:
## Why Object-Oriented Languages Need Tail Calls

The Fortress blog has a recent post, Why Object-Oriented Languages Need Tail Calls, where Guy Steele argues for the necessity of proper tail call implementations without rehashing two of the classic arguments: state machines and the continuation passing style. It starts by mentioning William Cook's On Understanding Data Abstraction, Revisited:

In this blog post we extend one of his examples in order to make a completely different point: object-oriented programming languages need tail calls correctly implemented, not just as a "trivial and optional" optimization of the use of stack space that could be achieved by using iteration statements, but in order to preserve object-oriented abstractions.

The post also mentions other papers previously discussed on LtU: Automata as Macros, and A Tail-Recursive Machine with Stack Inspection.

## Comment viewing options

### So apparently they don't

So apparently they don't think TCO is a red herring...

### haha

apparently not. ;-)

### Similar

Matthias Felleisen gave a presentation in 2004 titled Functional Objects in which he argued something similar. Slide 59: "Object-oriented programming in languages that don't require tail-call optimizations makes no sense". He then quotes an email correspondence with Guy Steele and concludes that Scheme was led to require TCO by studying OO examples.

### What does Tail Call Optimization mean to you?

I'm a bit curious as to how different minds understand 'Tail Call Optimization' (TCO).

Consider a few cases:

• In what I'll call 'traditional TCO', activation records are allocated on a stack and under certain conditions (tail-calls) one will reuse the activation record. Thus the stack doesn't actually grow (except perhaps if the new activation record is larger than the prior one).
• As an alternative to the stack the activation records are created on the heap. For performance, this is usually in a clean nursery-region of the heap where one can increment a pointer to perform an allocation. One typically compiles into continuation-passing style, and each continuation therefore serves as a thread. A copying garbage collector ensures there is always clean space for a new nursery. For lack of a better name, I'll call this the 'generic no-stack' design.
• From the generic no-stack design, one might express a 'generic TCO' which simply reuses the same activation-record - no matter where it is allocated (i.e. on the stack or the heap). However, with CPS this isn't very useful (excepting to avoid a simple allocation) since the continuation is no longer implicit to the stack.
• In Chicken Scheme, the 'no-stack' approach is adapted to work with C as a target language. The data uses automatic allocation on the C stack, which will grow with each function call... but at a certain size (default 64 kB, IIRC, checked via a pointer comparison) a small copying-GC moves the important items from the C stack to the heap, then a longjump resets the stack with the new continuation. The C stack serves as a nursery, and the C language also implements the various compiled functions.
• Another variation on the no-stack design is Stallman's 'Phantom Stacks'. Unlike the generic (CPS) variation, one will occasionally return to an older activation record before continuing the computation, thus old activation records represent both history and futures - as per the traditional 'stack'. If a dangerous reference is created (a pointer from heap to stack, or a pointer from earlier in stack to later in stack as per upfunarg) a copying collection is performed immediately and a new stack is created. ... IIRC, Baker also produced something similar, using particular arrangements of pointers - critically, with the stack growing away from the heap - to reduce to a simple comparison the detection of dangerous references.

There are probably many more alternatives sitting in the collective brains of the LtU community.

I'm a rather pedantic guy, so I don't consider any of these excepting 'traditional TCO' - and perhaps I'd grant the 'generic TCO' variation - to actually be TCO.

That is, I see TCO as a particular mechanism to support a useful performance property: partial decoupling of the space-performance from the time-performance of an activity.

I'm somewhat curious as to how other people would call it. In my view, TCO isn't necessary... because there are other approaches to achieving the same, useful property. But I suspect others might say, 'meh, don't be so pedantic - you're getting TCO by another name...'.

But there are some other differences in the practical implementation properties. The no-stack approach with CPS can in some cases collect more space than does TCO on a stack, especially when working with conditional branches. Avoiding use of a stack also keeps the overhead for new continuations very small - i.e. a single activation record, added to the scheduler's queue - which is excellent for fine-grained task-parallelism.

Further, with the generic no-stack approach, true history can be kept as a simple list of earlier activation records... i.e. the records are not serving many duties or much reuse, and one can even remove mutable state from them.

Use of 'generic TCO' might save a bit on allocations and collections, and still might serve as a useful optimization... but is not nearly so useful as 'traditional TCO', and may be a bit difficult to reconcile with other advanced features (such as generational garbage collection, debugger histories, or persistent memory).

### Good question

In fact, I think this is a great question. I would actually prefer a different definition, which I will call "semantic TCO":

A language has TCO if all storage allocated in the course of a function call can be reclaimed as soon as it becomes unreachable according to the language semantics. (A language fails to have TCO exactly when there is some such storage that cannot be reclaimed even though there is no way to reach it in any subsequent execution trace.) The mechanism by which this is achieved is irrelevant.

Note that this definition is fundamentally connected with garbage collection. This doesn't rule out its application to C-like languages, because I believe that C's stack discipline is indeed an extremely limited form of GC.

Languages like Java are interesting under this definition, because they do allow for various ways of accessing stack frames (security checks, reifying stack traces during exception handling, etc.), even though the according to the language semantics per se, everything in those stack frames is garbage. So are these stack frames garbage according to the language semantics or not? As far as I know, this question is basically the big sticking point for TCO on the JVM.

### Semantic TCO FTW

"semantic TCO" ... The mechanism by which this is achieved is irrelevant.

I'm 100% with Matt on this one.

I've long argued that TCO is a legitimate language definition issue and not merely an implementational one.

### Quite. But my feeling is

Quite. But my feeling is that this (semantic perspective) is clear to most of those arguing for TCO, even if not for the opposition.

### Yet more pluralism

this (semantic perspective) is clear to most of those arguing for TCO, even if not for the opposition

I'm not sure that I interpret Tim Bray's comment as opposition to TCO as much as acceptance that its absence is a practical limitation that can be worked around.

He seems to be arguing (even in his comment on Guy's post) that, given the limitations of the JVM, Clojure (and a similar argument can be made for Scala) has made do pretty well without the world ending as some might predict.

Steele, Felleisen and Cook are presenting a "hard-line" definition of OO that isn't adhered to by most who practice it, and it feels like a bit of a straw-man to me, even if I may agree with them that the PL world might be a better place if their perspective was a adopted as canonical.

We all have to do the best that we can in the world we actually live in, and whereas I would consider rejecting the superiority of semantic TCO outright to be a sin, being prepared to work around not having it the best you can is not. ;-)

### I can accept this. I don't

I can accept this. I don't see what you wrote as contradicting the quote you started your post with, though.

### LtU's Most Wanted

I don't see what you wrote as contradicting the quote you started your post with, though.

It depends on who you meant as the "opposition" in that quote. ;-)

### That's what I figured...

That's what I figured...

(more here)

### Semantic TCO

Well, that's a position I can understand and find rather agreeable, Matt.

That said, I don't believe 'semantic TCO' has ever been implemented, at least not as you define it. In the general case, we cannot know exactly when storage will become unreachable according to language semantics... all sorts of neat little mathematical theorems (Rice's theorem, Halting problem, etc.) tell us we cannot know.

And that makes semantic TCO 'idealistic' - which is probably why I find it agreeable. ;-)

### Re: don't believe 'semantic TCO' has ever been implemented

Shao and Appel came close in Efficient and Safe-for-Space Closure Conversion with their definition of "safe for space complexity" and related heuristics for the SML/NJ compiler.

Clinger also describes safe-for-space in Proper Tail Recursion and Space Efficiency

### Clinger

Thanks for the references. I'll note that Clinger's article makes a distinction between 'Proper Tail Recursion' and 'Tail Call Optimization'. From the abstract:

Scheme requires implementations to be properly tail recursive. This ensures that portable code can rely upon the space efficiency of continuation-passing style and other idioms. On its face, proper tail recursion concerns the efficiency of procedure calls that occur within a tail context. When examined closely, proper tail recursion also depends upon the fact that garbage collection can be asymptotically more space-efficient than Algol-like stack allocation. Proper tail recursion is not the same as ad hoc tail call optimization in stack-based languages. Proper tail recursion often precludes stack allocation of variables, but yields a well-defined asymptotic space complexity that can be relied upon by portable programs.

I think it quite legit to distinguish a guarantee on the space-efficiency of certain expressions from a particular peephole optimization. But, in this light, my initial question was a bit misleading. I asked about TCO, whereas the OP is almost certainly aimed at "[Proper] Tail Calls".

### I'm a bit confused

I'm not sure I agree with this. Language semantics typically make it clear precisely which storage is reachable at any given time. Of course not all of that storage will be accessed in all possible executions, and of course we can't know which is which. But at any time, the potentially reachable storage is well-defined. (This is why the generic no-stack design works, isn't it?)

(Obviously this does not apply if the program does funny stuff like casting ints to pointers, but if the semantics allows such tricks, then all storage is always trivially reachable and no GC is ever safe.)

But I could be missing something, or misunderstanding you. And anyway this just puts it in the same boat as the rest of GC, which certainly works well enough for most purposes.

### Not so obvious...

Language semantics typically make it clear precisely which storage is reachable at any given time.

Not quite. Language semantics are generally small-step, which considerably obfuscates exactly when storage cannot possibly be accessed.

This should be something you know trivially. Indeed, we can reduce a question of whether storage "cannot be reclaimed even though there is no way to reach it in any subsequent execution trace" to the Halting Problem. Quite easily, too:

 { X = new Storage(); NobodyKnowsWhetherIHalt(); DoSomethingWith(X); }

The storage above (allocated over the course of the function call) includes both X and the stack-frame containing space for a reference to X. In general, neither can be collected, even if they are unreachable.

The generic no-stack approach isn't so ambitious as your definition requires for semantic TCO.

Interestingly, your definition of semantic TCO doesn't mention anything about 'tail calls' and whatnot. I'll display your words again, with emphasis by an admitted pedant:

A language has [semantic] TCO if all storage allocated in the course of a function call can be reclaimed as soon as it becomes unreachable according to the language semantics. (A language fails to have TCO exactly when there is some such storage that cannot be reclaimed even though there is no way to reach it in any subsequent execution trace.)

This definition, in a quick summary, is: "Semantic TCO is perfect GC that also solves the halting problem." Can't get much more idealistic than that. ;-)

### "live" vs "reachable"

I think this disagreement might just be over terminology. I've seen articles on garbage collection that use the term "live" to describe data that will be accessed in the future (i.e. an algorithm to determine if something is live would essentially be solving the halting problem).

The notion of reachability is then defined in some simple way (i.e. there is a path of pointers from the root set to this object) such that "live" is a subset.

### This is what I meant

I may not have said it right, but the second paragraph of Kannan's post is indeed what I had in mind. (Not that it necessarily has to be defined in terms of following pointers. The language semantics could define it in terms of visible names, or some other way.)

"Semantic TCO is perfect GC that also solves the halting problem."

I think you are attributing too large a scope to Matt's statement.
If you add the obvious qualification:

"even though there is provably no way to reach it in any subsequent execution trace"

it is clear it is a much more modest and practical claim than you are suggesting.

### Granted.

Granted. But, of course, that raises the question: provable by which prover?

### Example

{
X = new Storage();
NobodyKnowsWhetherIHalt();
DoSomethingWith(X);
}

This is a good example. In this case, the language semantics presumably say that a function call may (a) return, (b) terminate through an unconditional control transfer (e.g., throw an exception) or (c) fail to terminate. So we have a number of possible executions to consider. In one of these executions, X is used, so X is still reachable and is not garbage.

That's all I meant.

Interestingly, though, sometimes language semantics are enough to restrict this. For instance, Java uses this same set of properties to determine when dead code must be removed: the compiler will reject:

  int x;
return;
println(x);

And in Scala, a method returning type Nothing is known never to return. Therefore any subsequent code is dead, the stack frame is garbage and the call could be compiled as a tail call. This is a nice example of the semantics determining the reachability property.

Anyway, I didn't have in mind anything as powerful as what you suggest. Sorry if I was unclear. Although as you mention it, this would be the perfect ideal definition of TCO, just as one could imagine a perfect oracular GC that retains only storage that will eventually be used.

### Question begging

Language semantics typically make it clear precisely which storage is reachable at any given time.

What if a language defines entries on the stack to be reachable until the stack frame is popped, as C does? Does C do TCO under this definition?

### Good point.

Good point. C is a funny case, because all storage is always reachable. So I suppose you could say that C has perfect GC as well, in a trivial sense, although I agree that this feels extremely unsatisfying.

But actually, I'm not sure if C really says this as part of the language semantics. Certainly there is no syntax to access that storage, although you can do things like this:

void test(int x) {
void *back = (&x - 1);
int outer_int = *back;
...
}

But I'm pretty sure that the outcome of that is actually undefined.

Come to think of it, I don't even think C says whether the stack grows up or down, and I definitely don't think the standard prescribes a layout for activation records... So I'm not really sure whether this is such a problem.

### Not exactly my point

My point doesn't rely on sneaky pointer casting C code. It was that passing the buck to a language defined notion of "reachability" doesn't seem to accomplish much. If you start with a definition of reachability such that:

void foo() {
SomeStruct s;
bar();
} /* s becomes unreachable here, by definition */

then C is doing TCO in this situation. To fix this we must add the requirement that any definition of reachability should respect tail calls. And then we're back where we started.

### I see what you mean

I see what you mean, but it feels like cheating. I would expect that reachability should be a property derived from the meanings of the actual language constructs, not something explicitly bolted onto the side.

Like, you can say that "s is reachable until here," but you don't actually provide any way to observe that. I'm not sure how to make the notion of observation precise in terms of denotations or whatever, because I am far from knowledgeable about formal semantics. But I hope you see what I mean.

But anyway, yes, I see what you're saying and I agree that it's a little weaselly to define TCO in this way. But I still like it, as a fuzzy notion, because it captures the idea that implementations without TCO are, in some sense, doing something extra, while implementations with TCO are, again in some sense, simply collecting all the garbage. Most other definitions make TCO seem like something extra, which is a crucial difference in viewpoint between advocates and detractors.

### One more poke

I'm not sure that there's an easy way to formalize this, since reachability is a more or less ad hoc approximation to liveness. Here's another potential problem: does this definition require more than we normally expect out of TCO?

In a strict language, with a function definition such as,

foo x = let s = buildBigStruct x in foo (bar (baz s))

I'd expect TCO to only require freeing 's' before transferring control to 'foo'. But under your definition, we might expect TCO to require freeing it before the call to 'bar'.

### Yes, it sets the bar higher.

Yes, it sets the bar higher than some of the other definitions. But I think some of the program transformations to implement TCO may already achieve this. The generic no-stack design with CPS, for example, might already consider s garbage before the call to bar. I haven't thought about it in detail.

I'm not sure that there's an easy way to formalize this, since reachability is a more or less ad hoc approximation to liveness.

I'm not sure... I mean, how is this different from GC in general? I'm looking through R5RS and I don't see any explicit definition of storage reachability, yet people do manage to correctly implement garbage-collected Schemes.

I'm genuinely surprised by your point of view. It has never occurred to me that the notion of what was/wasn't garbage was ill-defined or an approximation of anything. It's a superset, sure, of "stuff the program will actually use," but I wouldn't say it's an approximation. I still wonder if we're using "reachable" in the same way.

(Except in the case of conservative GC, but that's a different story. That only happens when you can't tell what is or isn't a pointer.)

### Clinger's Paper

This discussion would be well-served by reading Will Clinger's paper "Proper tail recursion and space efficiency", which answers all of these questions in a simple way. Also, Morisset, Felleisen and Harper's paper "Abstract Models of Memory Management" is on point as well.

### Good references

I've seen both of those, but admit that it's been awhile. Thanks for reminding me that speculation is the poor cousin of study. ;)

### How is this different from GC in general?

The simplest explanation for when something is no longer reachable is when there is no way to reach it from the symbols that are in scope. This definition is not sufficient to explain TCO. You're arguing for garbage to be identified in some situations where symbols, though still in scope, are provably no longer be used.

Edit: My use of 'in scope' is probably confusing here. I just mean that in e.g. Java symbols 'go out of scope' when the block they are in is exited.

### I see what you mean.

I see what you mean.

### Early GC

The generic no-stack design with CPS, for example, might already consider s garbage before the call to bar.

It certainly would.

Indeed, the generic no-stack design with CPS might consider part or all of s to be garbage long before completing the call to 'baz'. The ability to collect just the unused parts of s is especially impressive relative to normal TCO, though one could combine TCO with something like invalidating references that won't be used anymore to achieve similar effects.

The generic no-stack CPS approach can often collect far more than could traditional TCO.

The main problem with the no-stack approach: it is usually difficult to achieve equal performance to the stack-based design - due largely to CPU caching and locality of reference issues. One would need some way to GC just the nursery when it gets full, without tracing very much else, or alternatively GC the nursery whenever a reference is created from outside the nursery.

### Right.

This whole issue has always seemed to me to be mostly about tradeoffs between the stackless CPS approach (which AFAICS has pretty much ideal semantics) and the traditional contiguous stack, which is almost forced on you by modern hardware.

Alternatively, you could separate return addresses from everything else like Forth... There's a price to pay for that, too, but it would be a shame not to mention it in this context. Forth continues to be worthy of study.

### Reachability and Scoping Related?

But the value s could not be accessed by bar(). Reachable at a point means to me that the value can be referred to by an expression at the point being discussed. Of course a pointer to s being passed to bar complicates the matter. Does this somehow hint scoping and reachability are related?

### Reachability

I'm not aware of a formal or universal definition of reachability. My informal understanding is that it's an implementation property that answers whether you can get to a certain value by pointer chasing from the stack. This is why I see a circularity in defining TCO in terms of reachability - TCO is supposed to place restrictions on what can be on the stack.

### Semantic TCO trouble

A language has TCO if all storage allocated in the course of a function call can be reclaimed as soon as it becomes unreachable according to the language semantics.

Careful with that "all"! Consider a closure that contains the sites binding variables i and j. Both are used in the lifetime of the closure, but the semantics of the language shows that the lifetime of i is short while the lifetime of j is long. Does semantic TCO require that i be freed while the closure is still needed? It sounds like more trouble than it could ever be worth.

### Sometimes

Sometimes variables must be cleared to preserve the "Safe-for-Space" property, which is stronger than the "Properly tail recursive" property. There are a variety of complexity classes defined in Clinger's paper - I recommend it.

### I understand it as ensuring

I understand it as ensuring that a call in tail position always consumes asymptotically no space, i.e. an arbitrary number of tail calls
can be executed sequentially. This is a slight weakening of how Scheme defines it.

### Goto Start

From Tim Bray's blog:

Why I Hate Tail Call Recursion Optimization Â· It feels like a big fat lie. It looks like a subroutine call, but in the case where it occurs as the last thing in the routine, it magically, silently, and automatically gets turned into, now how did I put it? â€œA highly controlled and structured GOTO.â€

If thatâ€™s what the programmer wants, then thatâ€™s what the programmer should bloody well ask for. Iâ€™ve always been irritated by the explanations, in the Erlang and Lisp introductory books, about how you must be careful to ensure that your recursive calls are the last thing executed, and Iâ€™ve observed this leading sometimes to some gnarly unintuitive if/else branch placement. Call me old-fashioned, but it just seems wrong when the semantics of two identical function invocations vary wildly as a function of whether thereâ€™s an executable statement between the invocation and the function exit.

So the discussion boils down to: 1) Should a language support TCO? 2) Should TCs be made explicit in the language?

My take on (1): put it in the language specification. My take on (2): Yeah, well, if you feel like it, but why not support "goto" then?

Why I hate TCO discussions: TCO is a minor compiler optimization in languages which use a stack to implement calls. That's it. The discussion should have been dropped around three centuries ago.

[Edit: Guy Steele makes an interesting point, but it seems to boil down to: Recursion is intuitively the best answer.]

### Making TCO explicit

If you are a tenant of the "TCO is just an optimisation" camp, then there is no incentive to make it explicit.

On the other hand, if you believe that TCO is necessary for the semantics of the language (as argued in the original post), then it would make a lot of sense to make it explicit. If nothing else, it would allow the compiler/runtime to tell you "that call is marked as tail-call, but there is no way it could be so go and rewrite this code properly".

The recursive call syntax is so convenient though. I would not trade it for goto.

### Explicit where?

Or the approach of Scheme could be taken where tail position is very precisely defined and that is exactly what must be optimized. Checking annotations for tail position should not be what compilers are doing because it's redundant. If someone doesn't know what is and what isn't tail position, rewriting the code correctly to make it tail recursive is probably beyond their abilities. The optimization is explicit in the
language definition, and so the code doesn't need to mention.

### The optimization is explicit

The optimization is explicit in the language definition, and so the code doesn't need to mention.

The annotation should be there because it makes the code more robust to refactoring.

### Two sides

As a property to be checked, I agree. As a pragma for optimization, I expect it would have the same future as inline.

### Yes, I believe such an

Yes, I believe such an annotation is useful for documenting and ensuring the expected space usage of a call and maintaining this property in the presence of refactoring.

### Disagree with your first point

If you are a tenant of the "TCO is just an optimisation" camp, then there is no incentive to make it explicit.

I disagree: as it is a very fragile optimisation, if you don't put the operation in the 'right order' you'll blow the stack..
An optimisation is only useful if it is a 'stable' optimisation.

So a keyword is useful for the compiler (as you said) *and* useful for documentation: when the next maintainer will ask himself 'Why is this code unreadable?' he can see that this was because the original developer wanted to have TCO.

### RE: Why not Goto?

Should TCs be made explicit in the language? Yeah, well, if you feel like it, but why not support "goto" then?

Unless you had something akin to 'goto funcName(ArgumentA,ArgumentB,...)', where the return-value from funcName becomes the return-value for the current procedure, gotos simply aren't as expressive as tail-calls. And, at that point, you might as well dodge a lot of confused C/C++ programmers and call it an explicit 'tail-call'.

A typical use of 'goto' in structured languages cannot be argumented, cannot leave a certain scope. This severely limits their utility... i.e. you cannot use gotos for mutual recursion between first-class functions.

Using goto, for, or while for looping requires violating single-assignment for anything non-trivial. But violating single-assignment discipline on the stack harms other features - especially support for task-parallelism (i.e. spawning off an expression), lazy or delayed evaluations, and first-class closures. You are cut off from these other powerful features before you even discover you want them.

The explicit tail-calls do not suffer these problems.

Guy Steele proposed exactly the syntax in your first line for explicit proper tail calls in Java, in 1996. (This according to his comment here -- first comment to Bray's blog post.)

### I would love to see this kind of syntax

Having spent a long time trying to shoehorn coroutines into C-style stack-oriented languages, I would love to see more languages support a function call mechanism that replaces the current stack frame with another one. Why didn't it make it into Java, I wonder?

### Implicit v Explicit Tail Calls

Honestly, I'm somewhat agnostic regarding implicit versus explicit tail calls, although I lean towards implicit. I can certainly live with explicit tail calls in the case of a Python or Java-like syntax, which already require a "return" statement. However, having to explicitly mark my tail calls in Scheme or ML would drive me absolutely batty.

Tim Bray, GvR, and others have argued against proper handling of implicit tail calls because it's a "magical" compiler optimization that might not work when you need it. I really don't see how this part of the argument holds much water, because for me personally, 99% of the time it takes absolutely no effort to determine whether or not any given call is a tail call, and in 99% of the remaining 1%, it is still easy.

So I think that this aspect of the argument really stems from either 1) a lack of understanding of tail calls, 2) a language implementation, such as Scala or Kawa, whose object code targets an environment hostile to proper tail calls, such as the JVM, and as a result proper tail call handling is fragile, 3) language features, such as post-increment operators, that interact with tail calls in subtle ways, and/or 4) growing up around less than reliable compilers.

But of course, there are languages, such as ML and Scheme, where it's really pretty easy to see whether or not a call is a tail call, with compilers that handle tail calls robustly.

### tail or fail?

OK, assume these forms are in tail position. Which of the f* are tail calls in Clojure?

(if (g a) (f1 a) (f2 a))

(when (g a) (f3 a) (f4 a))

(whenever (g a) (f5 a))

Hint: whenever is not defined in Clojure core.

### Macros and tail position

f1, f2, and f4 are tail calls, but f3 is not. The first two lines take no effort at all.

I don't know about f5, because I don't know what the "whenever" macro does. But if I knew, then it would almost certainly be easy.

I do define and use macros in my own code, but I tend to do so rather sparingly. I admit that one can construct pathological macros, but that doesn't mean that one should use them in production code. :-)

### OO does not need TCO

Steele's argument bugs me. I don't think it is quite right: We can construct a Cooke style OO language that does not have TCO yet which can solve the integer set problem Steele poses.

One way to do that is with some notions of types, indefinitely delayed values, and automatic coercions. This amounts to a way to add explicit trampolines to the OO language:

Given a type T (an object providing the interface T) we can derive a second, recursive type: Delayed[T]. A delayed value can be produced by supplying an object, method, and parameters. An operator we can use is ForceStep which takes a delayed value and invokes the method. The method may return either a value of type T or of type Delayed[T]. The operator Force iterates the operator ForceStep until a value of type T is produced (and then returns that value).

We can add a rule of implicit coercion: if a value of type Delayed[T] is produced in a context that demands a value of type T, the Force operator is implicitly applied. Thus, for example, if my program says:

Boolean x = someset.member(y);

the "member" method of "someset" might include, as one branch of a conditional:

return delayed otherset.member(y);

and the effect of TCO is achieved but without TCO.

The effect of TCO is thus achieved, basically, by a trampoline. We have not added TCO to the language. Instead, we've added delayed values. Delayed values are interesting in so far as they are useful for more than just optimizing tail calls.

I think that points to the weakness of even trying to make the argument Steele is trying to make: Cooke's notion of OO is about what high-level, abstract concepts should be present in a language in order to use a certain programming style; TCO is about the low-level operational characteristics of implementations of function calls or method invocations. It would be surprising if the high level concepts so constrained implementations that any language offering those high level concepts simply *had* to include TCO. In the end, I think Steele is left with a circular argument that if you have an OO language that requires TCO as the only reasonable solution to the integer set problem, then it requires TCO.

One could counter-argue that delayed values are "ugly" where as optimized tail calls are "elegant". In that sense, perhaps, OO "needs" TCO as in "makes programmers wish for it". That seems like a far less interesting claim, though, especially since delayed values strike me as not ugly and more general.

What the alternatives of TCO and delayed values suggest, however, is that in any event, if your language includes the concept of activation records, there should be some mechanism by which code can create a new activation record invoked after the current activation record is destroyed, yet whose activation produces the value expected to be returned and continues the computation expected of the current activation record. It's just not necessarily the case that this has to involve a compiler or interpreter recognizing tail calls and treating them specially.

### It's the same

But if I then specify each tail call as being delayed, I achieve TCO. Meanwhile we need to dynamically check for Delay[T] and take care of it.
To optimize this dynamic check out of the way, I would introduce a tail call primitive and have the Delay[T] use that when coercion is immediate. What's more, Delay[T] only has an effect in the semantics you gave when it is used in a tail call. In a fictitious typed Scheme
 x:[a] y:Delay a z=(cons y x)
y is forced at the cons. So what we have is a very restricted kind of lazy that is weaker then tail calls.

### delayed vals != TCO

But if I then specify each tail call as being delayed, I achieve TCO.

Not so, I think. Consider a call:

    Any x = s.member(y);

If the Any type includes delayed values, there is no implicit coercion by Force, hence adding a delayed to a return statement in a member method is not the same as TCO.

Meanwhile we need to dynamically check for Delay[T] and take care of it.

Hmm. Well, not necessarily. A "return address" could be regarded as an array of code addresses, indexed by permissible types. If the callee statically knows what type it is returning, it simply returns to that particular piece of code - there is no run-time type check involved. Such a facility would indeed be an optimization, but not quite a TCO.

I would introduce a tail call primitive and have the Delay[T] use that when coercion is immediate.

In the system I've sketched, consider this code:

    return delayed otherset.member(y);

For some callers, otherset.member(y) must be immediately forced. For other callers, it is appropriate to return the delayed value (perhaps to be forced much later). Therefore, a "tail call primitive" would not do the trick here.

Indeed, in the system I've sketched there is nothing particularly special about tail position calls at all - which is perhaps why it is hard to see through TCO-colored goggles :-)

In a fictitious typed Scheme

x:[a]
y:Delay a
z=(cons y x)

y is forced at the cons. So what we have is a very restricted kind of lazy that is weaker then tail calls.

I see no good reason why cons should force the value of y here. If we're talking about something Schemish, I would expect cons to take two arguments of some Any type, where that type includes all delayed values.

It's true that delayed and forcing (implicit or otherwise) are about lazy computation - but I don't see how they are weaker than tail calls.

I do admit that there is a real question there. You could be right and I don't see it. I'm certainly handwaving about my type system, making up details as I go along to support my argument. I don't think I've made up any details that lead to an inconsistent type system. I'd say the burden of proof one way or the other is "shared" in the face of what I'm willing to call my "hypothesized" type system.

### A flaw

You talk about objects of Delayed[T] having operators ForceStep and Force. Exposing ForceStep, though, qualitatively changes the interface. It allows you to ask encapsulation-breaking questions such as "Do I have a value after 5 iterations of ForceStep on the .member return value?"

So maybe you try to hide ForceStep and expose only Force. You could use the type system to hide ForceStep ADT-style, but then we're not using only pure objects in accordance with the rules of the exercise. So we really need to return an object that only supports Force, and not ForceStep, which is easily done ... with TCO :).

### flaw?

Being paranoid that I'm just not "getting the joke" I half-suspect you are just being silly but, if not.... would it also be encapsulation-breaking if I allowed programs to reflect on the amount of measured CPU time a given method call takes? Does it break encapsulation if a method invoker can figure out if a method invoked has any side effects? With delayed values I haven't exposed any of the "slot structure" internal to any objects so I think I pass Cooke's exercise.

Would it also be encapsulation-breaking if I allowed programs to reflect on the amount of measured CPU time a given method call takes?

Yes. This breach of encapsulation is a common source of security vulnerabilities, too, though it is admittedly difficult to prevent in practice. One foolproof method that's occasionally practical: don't give the program a clock.

Does it break encapsulation if a method invoker can figure out if a method invoked has any side effects?

This presumes there are side-effecting functions to begin with. Or should I say, "with which to begin"?

It sounds like we're approaching this in different ways, but I wasn't joking or just being silly. I do consider this a theoretical flaw with your encoding. But if you're happy with it as a practical matter, who am I to judge? I agree it's pretty close :)

### Proper Implementation of Tail Calls is a Semantic Property

You have just re-invented the trampoline, a method for implementing proper tail calls, along with an explicit notation for invoking them.

The fact that it uses a different implementation is irrelevant - proper implementation of tail calls is a property of the space usage of programs, not of stack layouts.

### Wrong

TCO is there to reduce stack consumption on (recursive) calls. There's no need for TCO if your language translates to, for example, hypercombinators since there is no -or need not be a- stack since it is unnecessary to push local contexts.

### This is not correct

First, proper implementation of tail calls has no essential connection to recursion - consider CPS.

Second, the property is about the asymptotic space consumption of programs, not about stacks, contexts, or calls. See Will Clinger's paper on this, which I cited up-thread, which is explicitly cited by the RnRS as the definition of this property. A hypercombinator-based implementation strategy may or may not meet this requirement, regardless of stacks.

First, proper implementation of tail calls has no essential connection to recursion - consider CPS.

I agree, hence the parentheses.

Second, the property is about the asymptotic space consumption of programs, not about stacks, contexts, or calls. See Will Clinger's paper on this, which I cited up-thread, which is explicitly cited by the RnRS as the definition of this property. A hypercombinator-based implementation strategy may or may not meet this requirement, regardless of stacks.

I guess the asymptotic space consumption you refer to is with regard to local contexts build up? In that regard, I guess I agree with the other poster, it depends on our definitions - we are both right.

I will argue however that TCO should be defined as just a technique on stack machines (replacing a call with a goto when the local context can be discarded), and your definition is, well, something else?

### I agree with Sam, and besides...

"What is the right definition of TCO?" is pretty much the whole point of this discussion. So it's not really fair to say "wrong" by simply appealing to a different definition. It's sort of begging the question...

### "reinventing" trampolines?

I don't think it fair to accuse me saying "You have just re-invented the trampoline [....]" given that I started my explanation by saying "This amounts to a way to add explicit trampolines to the OO language:"

A fair question is to ask what distinction I am making between delayed values, with coercion by forcing, and TCO. There are multiple ways to answer, including: (1) TCO implies an interpreter (or compiler) treating calls in the tail position specially - not so with delayed values; (2) TCO means something along the lines of Clinger's definition whereas delayed values can be defined without reference to tail expressions at all; also, a language with delayed values is not required to be "properly tail recursive" (yet it solves the challenge problem Steele poses); (3) delayed values are useful elsewhere besides tail positions and otherwise besides being immediately forced when returned by a procedure - they are more general.

Thus, TCO and delayed values are very different language features. The demonstration that delayed values can conveniently solve the problem Steele poses is an existence proof that he is mistaken to say that "OO requires TCO".

### Microsoft not interested for C#

Microsoft aren't planning to do this for C# and don't see why they should.

I'd like to be able to have recursive methods TCO'd (explicitly would be fine) simply to have the compiler do the work of making them iterative and allowing my code to remain readable.

There are few real C# methods where it would be legal to emit tail calls (other languages encourage coding patterns which have more tail recursion, and many that rely heavily on tail call optimization actually do global re-writing (such as Continuation Passing transformations) to increase the amount of tail recursion).

This strikes me as a Blub Paradox argument against supporting a feature: Why would I need it? Where am I using it?

If C# programmers knew they could count upon a tail-call optimization, I suspect you'd see a lot more real methods where it's legal to emit tail-calls. The reason you don't see it as necessary? perhaps because programmers are doing the extra labor of working around not having it.

C/C++ programmers often make a similar argument against garbage-collection, and do so even as they struggle to properly identify and collect garbage while integrating various forms of concurrency and callbacks from different frameworks. From the outside, this struggle is reason enough for the feature. From the inside, the programmers involved see the final victories of the struggle as proof they do not need it.

That isn't to say there aren't other decent arguments against emitting .tail from C#. The implementation is, as they note, often non-trivial in its overhead.

### Mirror of the article

The original URL for the article seems to no longer be responding. I've managed to dig out an Internet Archive copy, however, and have put up a mirror of it here: http://www.eighty-twenty.org/index.cgi/tech/oo-tail-calls-20111001.html.


text:
Having the eigenvalues how to find the eigenvectors?

This is a more practical question. In Pari/GP I have difficulties to use mateigen for some real matrices because of extreme long computation time and frequently "missing eigenspace" due to too low float precision. Say, the (real) matrix M is $48x48$ (a modified Vandermonde matrix), float precision of $1200$ decimal digits, then mateigen quits after some minutes, calling for more initial accuracy for the float computations.

However, using charpoly, polsturm (to check whether I've indeed 48 real eigenvalues) and then polroots I can get the eigenvalues with that parameters (they come out to be real, which is what I've expected). Now I thought I can proceed with some application of the much simpler method of matrix-solve or the like, for instance solve $(M-\lambda I)*X = \text{<nullvector>}$ (or something very near) to compute the eigenvectors too. I don't have it just at hand but I vaguely recall that something in this line was possible. How can I proceed here? (Quick&dirty were sufficient at the moment, I can take a deeper look at this tomorrow)

 In the comment to Pedro's answer I mentioned a procedure which I just found in my own old scripts. Unfortunately it seems to be the same way numerically insufficient as the original mateigen-procedure of Pari/GP with that problem constellation. The method works as follows:

1. Construct a list matrix L containing of the first rows of the consecutive powers of M $\text{for }k=1,dim, L[k,]=M^k[1,]$
2. Construct a vandermondematrix V containing the powers of the eigenvalues $\lambda_k$
$\text{for }r=1,dim, \text{for }c=1,dim V[r,c]=\lambda_c^r$
3. Then the matrix of eigenvectors is $W = L^{-1}*V$

In the current configuration with accuracy of 1200 digits I can solve this correctly for instance for $dim \le 16$ or the like.
But for $dim=48$ the error is inacceptable and may require to increase the accuracy the same way as the Pari/GP-inherent routine - so this does not help for my case now. The biggest dimension solvable with the standard mateigen-procedure with accuracy=1200 was $dim=32$ so far, maybe the accuracy requirement increases quadratically with the dimension. For $dim=48$ accuracy=1600 was not yet enough. The condition of the matrix (ratio of biggest to smallest eigenvalue) is $\approx {1.0 e16 \over 1.0 e-13 }$ for $dim=32$ and $\approx {1.0 e26 \over 1.0 e-19 }$ for $dim=48$ (it increases with the size of the testmatrix M)

So if there were another possibly relatively simple method I would be happy to try it.

-

If you only need a few eigenvectors (e.g. first few smallest or first few largest), I presume inverse iteration might be of service. Just make sure that the LU decomposition routine you would use for implementing inverse iteration is the kind that replaces zero pivots with tiny (near machine epsilon) quantities.

On the other hand, as I recall there are now special methods for eigendecomposing Vandermonde matrices which exploit the inherent structure; you might want to look into them.

-
thanks! No, I need the whole set of eigenvectors. I just found one method which I'd implemented some years ago but forgot the details. It worked by collecting the first columns of all consecutive powers of M, the inverse of this listmatrix and a matrix containing the according powers of the eigenvalues. Unfortunately a check of the result with my example does not come out correctly - maybe the accuracy of the 1200 digits is now too small for the correct inversion of the list-matrix (The method works for smaller dimension of M here) – Gottfried Helms Mar 29 '11 at 6:21
(accept) I'll "accept" this answer to close the case. My hope was to get a hint to a simple q&d-method, which however works/helps in my problem. After I could not overcome the numerical difficulties and had to put the problem at side for later review. I think such a q&d-method is not available and I've now time to scan the huge number of available literature and encyclopedia-entries myself (which are even accessible online). So that question needs no more attention here. – Gottfried Helms May 4 '11 at 8:03

format: plain


text:
New interface

# The Higgs boson mass as fundamental parameter of the minimal supersymmetric standard model

Abstract : In the Minimal Supersymmetric Standard Model (MSSM) the mass of the lightest neutral Higgs boson is determined by the supersymmetric parameters. In the $m_h$MSSM the precisely measured Higgs boson replaces the trilinear coupling $A_t$ as input parameter. Expressions are derived to extract $A_t$ in a semi-analytical form as a function of the light Higgs boson (pole) mass. An algorithm is developed and implemented at two--loop precision, generalizable to higher orders, to perform this inversion consistently. The result of the algorithm, implemented in the SuSpect spectrum calculator, is illustrated on a parameter set compatible with LHC measurements.
Document type :
Journal articles

https://hal.archives-ouvertes.fr/hal-03574108
Contributor : Gilbert Moultaka Connect in order to contact the contributor
Submitted on : Tuesday, August 2, 2022 - 12:47:13 PM
Last modification on : Tuesday, October 25, 2022 - 4:39:58 PM

### File

2202.06919.pdf
Files produced by the author(s)

### Citation

Rima El-Kosseifi, Jean-Loïc Kneur, Gilbert Moultaka, Dirk Zerwas. The Higgs boson mass as fundamental parameter of the minimal supersymmetric standard model. European Physical Journal C: Particles and Fields, 2022, 82 (7), pp.657. ⟨10.1140/epjc/s10052-022-10606-4⟩. ⟨hal-03574108⟩

Record views


text:
# Change Object's Location on local Z-Axis using Slider

I have a problem with moving the object on its local z axis.

import bpy, mathutils
from bpy.types import Panel, Operator
from bpy.props import FloatProperty
from mathutils import Matrix, Vector

#get, set methods of the floatproperty
def get_locationZ(self):
return self['locationZ']

def set_locationZ(self, value):
obj = bpy.context.object
loc = Matrix.Translation((0.0, 0.0, value))
obj.matrix_basis *= loc
self['locationZ'] = value

class ToolPanel(Panel):
bl_space_type='VIEW_3D'
bl_region_type='TOOLS'
bl_label='Cylinder'
bl_context='objectmode'
bl_category='Cylinder'

#floatproperty
bpy.types.Object.myFloat = FloatProperty(
name = "locationZ",
description = "Set the location on local z axis",
min = -100,
max = 100,
get = get_locationZ,
set = set_locationZ)

def draw(self, context):
layout = self.layout
obj = context.object

row = layout.row()
row.template_ID(context.scene.objects, "active")

split=layout.split()
col=split.column(align=True)

if obj is not None:
col.prop(obj, 'myFloat')

#Register
def register():
bpy.utils.register_class(ToolPanel)
#Unregister
def unregister():
bpy.utils.unregister_class(ToolPanel)

if __name__== '__main__':
register()

The problem is: If I increase the value of the slider, the cylinder moves in positive direction on the local Z axis.

But when I start to reduce the value, the cylinder moves in positive direction until the value reaches zero.

And then it turns and moves in negative directon. I want to move it to negavite direction immediately I start to reduce the value of the slider.

• Quick way to paste codeblock. If you have code in blender, text editor ctrl-A select all, hit tab, copy, paste here, shift tab in blender. You are applying a translation, like pressing g1 g0.9 g0.8 will move 2.7 . Need to set an absolute value. Pretty much want same as col.prop(obj, "location", index=2, slider=True) ie set obj.location.z = value wheras even with the matrix math you are simply obj.location.z += value – batFINGER Mar 31 at 10:49
• Thats not what i want, because thats moves the object on the global z axis. So if i change for example the rotation X and then i want to move the object on the LOCAL Z axis, not on the global/or ont the parentobject's. So obj.location.z += value dont do what i'd like to. – aura Mar 31 at 10:54

Applying rotation accumulates

As I was poorly trying to point out in comment applying the translation matrix from value will have a cumulative effect. (no matter what direction)

Use the delta value calculated from previous value.

Other minor changes, use self in the setter getter, rather than relying on bpy.context.object is self If you want context possibly better to use an update method instead.

Using ob.get("propname", default) gives a default value even when the property hasn't been set.

EDIT. Changed this to moving "locally globally" this way our slider value is global and won't be affected by local scale. (Move 1 unit globally in local z, akin to translate operator)

Example below working in 2.8. (Minor change @ to * or back).

import bpy, mathutils
from bpy.types import Panel, Operator
from bpy.props import FloatProperty
from mathutils import Matrix, Vector

#get, set methods of the floatproperty
def get_locationZ(self):
return self.get('locationZ', 0)

def set_locationZ(self, value):
z_axis = Vector((0, 0, 1))
delta = value - self.get('locationZ', 0)
v = (self.matrix_world.to_3x3() @ z_axis).normalized()

self.matrix_world.translation += delta * v
self['locationZ'] = value

class VIEW3D_PT_ToolPanel(Panel):
bl_space_type='VIEW_3D'
bl_region_type='TOOLS'
bl_label='Cylinder'
bl_context='objectmode'

def draw(self, context):
layout = self.layout
obj = context.object

row = layout.row()
row.template_ID(context.view_layer.objects, "active") # context.scene.objects (2.7x)

split=layout.split()
col=split.column(align=True)

if obj is not None:
col.prop(obj, 'myFloat', slider=True)

#floatproperty
bpy.types.Object.myFloat = FloatProperty(
name = "locationZ",
description = "Set the location on local z axis",
min = -100,
max = 100,
soft_min=-10,
soft_max=10,
step=1,
subtype='DISTANCE',
get = get_locationZ,
set = set_locationZ)

#Register
def register():
bpy.utils.register_class(VIEW3D_PT_ToolPanel)
#Unregister
def unregister():
bpy.utils.unregister_class(VIEW3D_PT_ToolPanel)

if __name__== '__main__':
register()

As a side note the new elementwise @ multiplier works as expected for M @= T For 2.7x found using M = T * M a more reliable option.

• This is what i want. Thank you so much!!! – aura Mar 31 at 12:18
• Thankyou. Changed it up a bit such that a global value can be used on value to move value times a unit global vector in the z local axis direction. See revisions for older version blender.stackexchange.com/posts/135801/revisions Good questions are appreciated too! – batFINGER Mar 31 at 12:47


text:
# Find The Mode

Computer Science Level 2

Finding the mode of a few numbers isn't too hard, but if you have a very long list, you'll probably need some code!

To find the mode, you use the following:

  1 2 3 4 5 6 7 8 9 10 11 12 current_count = 0 mode_count = 0 for position in range(len(array)): if array[position] == array[position-1]: current_count += 1 if array[position] != array[position-1] \ or position == len(array)-1: if current_count > mode_count: mode = array[position-1] mode_count = current_count current_count = 1 print mode

For this approach to be successful, which of the following must be true about your array?

I. It is sorted.

II. It is unimodal.

Details

• The mode is defined as the element which appears most often in a set. If more than one element appears most often, the mode is that set of elements which appear most often.
×

Problem Loading...

Note Loading...

Set Loading...


text:
# I Just Hold His Hand lyrics

When I don’t know how, and I don’t know why.
When the mountain’s so tall I can’t see the other side.
When there seems to be no way, and I don’t understand,
I just hold His hand, I just hold His hand.
Chorus:
He will lead me and guide me along my way,
He will keep me and hide me, safe in His grace.
When I can’t thank God He still can.
I just hold His hand, I just hold His hand.
When the nights are so long, and the valley is low,
When the going gets rough, traveling this road.
When I’m searching for strength, and I need help to stand,
I just hold His hand.
Bridge:
Precious Jesus hold my hand, I need thee every hour.
Precious Jesus help me stand, keep me by your power.
Chorus

Oh Lord lead me and guide me along my way,
Keep me and hide me, safe in Your grace.
When I can’t, I know you still can,
So I’ll just hold your hand,


text:
# Article

Full entry | PDF   (0.2 MB)
Keywords:
blow-up; global existence; asymptotic behavior; maximum principle
Summary:
We obtain some sufficient conditions under which solutions to a nonlinear parabolic equation of second order with nonlinear boundary conditions tend to zero or blow up in a finite time. We also give the asymptotic behavior of solutions which tend to zero as $t\rightarrow\infty$. Finally, we obtain the asymptotic behavior near the blow-up time of certain blow-up solutions and describe their blow-up set.
References:
[1] Boni T.K.: Sur l'explosion et le comportement asymptotique de la solution d'une équation parabolique semi-linéaire du second ordre. C.R. Acad. Paris, t. 326, Série I, 1 (1998), 317-322. MR 1648453 | Zbl 0913.35069
[2] Chipot M., Fila M., Quittner P.: Stationary solutions, blow-up and convergence to stationary solutions for semilinear parabolic equations with nonlinear boundary conditions. Acta Math. Univ. Comenianae, Vol. LX, 1 (1991), 35-103. MR 1120596 | Zbl 0743.35038
[3] Egorov Yu.V., Kondratiev V.A.: On blow-up solutions for parabolic equations of second order. in `Differential Equations, Asymptotic Analysis and Mathematical Physics', Berlin, Academie Verlag, 1997, pp.77-84. MR 1456179 | Zbl 0879.35081
[4] Friedman A., McLeod B.: Blow-up of positive solutions of semilinear heat equations. Indiana Univ. Math. J. 34 (1985), 425-447. MR 0783924 | Zbl 0576.35068
[5] Protter M.H., Weinberger H.F.: Maximum Principles in Differential Equations. Prentice Hall, Englewood Cliffs, NJ, 1967. MR 0219861 | Zbl 0549.35002
[6] Rossi J.D.: The blow-up rate for a semilinear parabolic equation with a nonlinear boundary condition. Acta Math. Univ. Comenianae, Vol. LXVII, 2 (1998), 343-350. MR 1739446 | Zbl 0924.35017
[7] Walter W.: Differential-und Integral-Ungleichungen. Springer, Berlin, 1964. MR 0172076 | Zbl 0119.12205

Partner of


text:
Math. physics

1. Dec 5, 2011

matematikuvol

1. The problem statement, all variables and given/known data

Prove

$$\sqrt{\frac{2}{\pi}}\int^{\infty}_0x^{-\frac{1}{2}}\cos (xt)dx=t^{-\frac{1}{2}}$$

and use that to solve

$$\int^{\infty}_0\cos y^2dy$$

Is this good way to try to prove?

2. Relevant equations

3. The attempt at a solution
1. The problem statement, all variables and given/known data
Multiplicate both sides with $$\cos x'tdt$$ and integrate from zero to $$\infty$$

$$\sqrt{\frac{2}{\pi}}\int^{\infty}_0dt\cos (x't)\int^{\infty}_0x^{-\frac{1}{2}}\cos (xt)dx=\int^{\infty}_0dt\cos (x't)t^{-\frac{1}{2}}=\sqrt{\frac{2}{\pi}}\int^{\infty}_0dxx^{-\frac{1}{2}}\int^{\infty}_0dt\cos (x't)\cos (xt)dx$$
1. The problem statement, all variables and given/known data

2. Relevant equations

3. The attempt at a solution

2. Dec 5, 2011

matematikuvol

Suppose that we know

$$\sqrt{\frac{2}{\pi}}\int^{\infty}_0\cos(xt)x^{-\frac{1}{2}}dx=t^{-\frac{1}{2}}$$

without proving. How to calculate then

$$\int^{\infty}_0\cos x^2dx$$

Last edited: Dec 5, 2011
3. Dec 5, 2011

crimsonidol

you need to use residue calculus.
if you can go to library look at hildebrand advanced calculus for applications, under the intended contours you will see how to use cauchy's principle and then you'll get gamma functions.

4. Dec 5, 2011

matematikuvol

For which part of problem. This is problem from Arfken, Weber.

5. Dec 5, 2011

crimsonidol

you can do the proof and also find part b when you understand the first part I assume.look hildebrand page 561 to be exact

6. Dec 5, 2011

matematikuvol

$$\int^{\infty}_0\frac{\cos x}{x^{1-m}}dx=\Gamma(m)\cos (\frac{m\pi}{2})$$

$$\int^{\infty}_0\frac{\cos x}{x^{1-\frac{1}{2}}}dx=\Gamma(\frac{1}{2})\cos (\frac{\frac{1}{2}\pi}{2})=\sqrt{\pi}\frac{\sqrt{2}}{2}=\sqrt{\frac{\pi}{2}}$$

I don't see solution :(

7. Dec 5, 2011

crimsonidol

you need to look at contour integration and use xt instead of x there. By using residue and appropriate contour you'll be able to find t^-1/2

8. Dec 5, 2011

matematikuvol

Ok. Thanks. And what then. When I prove first part, how can I calculate integral $$\int^{\infty}_0\cos x^2dx$$?

9. Dec 5, 2011

crimsonidol

10. Dec 5, 2011

dextercioby

Take t=1 in what you have proven already then do a simple substitution to get rid of the sqrt.

11. Dec 6, 2011

matematikuvol

Thanks a lot! :)


text:
# Do I need to keep a 64-bit version number secret?

Assume the following structure:

version | iv | ciphertext | HMAC(version | iv | ciphertext | ..., key)

The version starts out to be a "random" 64-bit number. It identifies the key used to encrypt the ciphertext for the purpose of key rotation (version is not, nor does it contain any part of the key). For every message encrypted by the same key, version is the same. The rest of the text, starting with a random iv, is always different.

Is there any reason I need to protect version? If an attacker knows the version the most they can do is identify a group of ciphertext that was encrypted with the same key.

The ciphertext itself has validity period of it's own. The data should be updated around the same time as the key is rotated. The rational behind version is to allow the ciphertext to be updated gradually as-needed.

Would obscuring the version in some way add any benefit, even small? Something like this:

$Version_n \oplus Hash(iv)_n$

I know this adds no real security benefit. If version doesn't need to be protected, the most I'm going for is to make it appear random.

-
If your IV is out in the open, anyone can XOR its hash with the XORed Version number – rath May 21 '13 at 8:07
If the receiver already knows version, then you can use version as the associated data in SIV mode. – Ricky Demer May 21 '13 at 9:01
The proposal $Version_n \oplus Hash(iv_n)$ (notice the fix) is security by obscurity: security lies in the method, not a key. Hiding the key version, as well as including it in the HMAC, looks pointless to me. If its desirable for some reason to hide the key version, what about replacing $Version_n$ by $Version_n \oplus HMAC(HMAC(version | iv | ciphertext | ..., key_{version_n}), longtermkey)$? – fgrieu May 21 '13 at 11:46
The question is: Does exposing said information cause any security-loss in your application? If no, then there is no reason to try hiding it. If yes, then security by obscurity is definitely not the solution. – Maeher May 21 '13 at 15:13
To answer that we would need to know what exactly your security goal is and what exactly the application is. For the confidentiality it shouldn't matter. But if your application needs some kind of unlinkability or something like that it could be a problem. We simply do not have enough information to judge the security of what you are trying to do. – Maeher May 21 '13 at 20:24


text:
# principal bundle

Let $E$ be a topological space on which a topological group $G$ acts continuously and freely. The map $\pi:E\to E/G=B$ is called a principal bundle (or principal $G$-bundle) if the projection map $\pi:E\to B$ is a locally trivial bundle.

Any principal bundle with a section $\sigma:B\to E$ is trivial, since the map $\phi:B\times G\to E$ given by $\phi(b,g)=g\cdot\sigma(b)$ is an isomorphism. In particular, any $G$-bundle which is topologically trivial is also isomorphic to $B\times G$ as a $G$-space. Thus any local trivialization of $\pi:E\to B$ as a topological bundle is an equivariant trivialization.

Title principal bundle PrincipalBundle 2013-03-22 13:07:18 2013-03-22 13:07:18 rmilson (146) rmilson (146) 8 rmilson (146) Definition msc 55R10 principal G-bundle


text:
# Identity, Equation or Formula?

##### Level 1Level 2Level 3Exam-StyleDescriptionHelpMore Algebra

Drag the given statements to the correct set.

## Formula

$$9x^2-16=(3x+4)(3x-4)$$

$$\sin x \div \cos x = \tan x$$

$$a=\sin A \times b \div \sin B$$

$$\sin x = x$$

$$A= \frac12 ab \sin C$$

$$10x^3+5x=5x(2x^2+1)$$

$$\sqrt{x+1}=x^3$$

$$a^2=b^2+c^2-2bc \cos A$$

This is Identity, Equation or Formula? level 3. You can also try:
Level 1 Level 2

## Transum.org

This web site contains over a thousand free mathematical activities for teachers and pupils. Click here to go to the main page which links to all of the resources available.

## More Activities:

Mathematicians are not the people who find Maths easy; they are the people who enjoy how mystifying, puzzling and hard it is. Are you a mathematician?

Comment recorded on the 18 September 'Starter of the Day' page by Mrs. Peacock, Downe House School and Kennet School:

"My year 8's absolutely loved the "Separated Twins" starter. I set it as an optional piece of work for my year 11's over a weekend and one girl came up with 3 independant solutions."

Comment recorded on the 19 June 'Starter of the Day' page by Nikki Jordan, Braunton School, Devon:

"Excellent. Thank you very much for a fabulous set of starters. I use the 'weekenders' if the daily ones are not quite what I want. Brilliant and much appreciated."

Each month a newsletter is published containing details of the new additions to the Transum website and a new puzzle of the month.

The newsletter is then duplicated as a podcast which is available on the major delivery networks. You can listen to the podcast while you are commuting, exercising or relaxing.

Transum breaking news is available on Twitter @Transum and if that's not enough there is also a Transum Facebook page.

#### Three Ways

Can you get to the target number by multiplying together four different one digit numbers? Can you do it in three different ways? There are nine levels to this online challenge and a virtual Transum Trophy available for each level.

## Numeracy

"Numeracy is a proficiency which is developed mainly in Mathematics but also in other subjects. It is more than an ability to do basic arithmetic. It involves developing confidence and competence with numbers and measures. It requires understanding of the number system, a repertoire of mathematical techniques, and an inclination and ability to solve quantitative or spatial problems in a range of contexts. Numeracy also demands understanding of the ways in which data are gathered by counting and measuring, and presented in graphs, diagrams, charts and tables."

Secondary National Strategy, Mathematics at key stage 3

## Go Maths

Learning and understanding Mathematics, at every level, requires learner engagement. Mathematics is not a spectator sport. Sometimes traditional teaching fails to actively involve students. One way to address the problem is through the use of interactive activities and this web site provides many of those. The Go Maths main page links to more activities designed for students in upper Secondary/High school.

## Teachers

If you found this activity useful don't forget to record it in your scheme of work or learning management system. The short URL, ready to be copied and pasted, is as follows:

Do you have any comments? It is always useful to receive feedback and helps make this free resource even more useful for those learning Mathematics anywhere in the world. Click here to enter your comments.

For Students:

For All:

## Description of Levels

Close

Level 1 - Easy Peasy

Level 2 - Middle for Diddle

Level 3 - U Gotta B Kiddin

Exam Style questions are in the style of GCSE or IB/A-level exam paper questions and worked solutions are available for Transum subscribers.

More on this topic including lesson Starters, visual aids and investigations.

Answers to this exercise are available lower down this page when you are logged in to your Transum account. If you don’t yet have a Transum subscription one can be very quickly set up if you are a teacher, tutor or parent.

## Curriculum Reference

See the National Curriculum page for links to related online activities and resources.

## Example

This video is from the wonderful Mr Barton Maths.

Answers to this exercise are available lower down this page when you are logged in to your Transum account. If you don’t yet have a Transum subscription one can be very quickly set up if you are a teacher, tutor or parent.

Close