When we speak of separating meaning from optimization, I get the impression
we want to automate the optimization. In that case, we should validate the
optimizer(s). But you seem to be assuming hand-optimized code with a
(simplified) reference implementation. That's a pretty good pattern for
On Wed, Jul 31, 2013 at 4:26 PM, David Barbour dmbarb...@gmail.com wrote:
When we speak of separating meaning from optimization, I get the
impression we want to automate the optimization. In that case, we should
validate the optimizer(s). But you seem to be assuming hand-optimized code
with a
On 30 July 2013 16:22, Casey Ransberger casey.obrie...@gmail.com wrote:
I was thinking: if a system happens to be running an optimized version of
some algorithm, and hit a crash bug, what if it could fall back to the
suboptimal but conceptually simpler Occam's explanation?
This is something
Fundamentals means the fundamentals, not existing programming languages and
paradigms.
Fundamentals means the fundamentals, not your troubleshooting for your
current job.
Use the list for what it's said to be for.
On Tue, Jul 30, 2013 at 1:43 PM, Tony Garnock-Jones
tonygarnockjo...@gmail.com
John - that discussion strikes me as perfectly suitable for this list.
And your comment doesn't.
- Original Message -
From: Fundamentals of New Computing
To:Fundamentals of New Computing
Cc:
Sent:Tue, 30 Jul 2013 14:49:35 -0700
Subject:Re: [fonc] Deoptimization as fallback
This is how Smalltalk has always treated its primitives, etc.
Cheers,
Alan
From: Casey Ransberger casey.obrie...@gmail.com
To: Fundamentals of New Computing fonc@vpri.org
Sent: Tuesday, July 30, 2013 1:22 PM
Subject: [fonc] Deoptimization as fallback
: Tuesday, July 30, 2013 1:22 PM
Subject: [fonc] Deoptimization as fallback
Thought I had: when a program hits an unhandled exception, we crash, often
there's a hook to log the crash somewhere.
I was thinking: if a system happens to be running an optimized version of
some algorithm, and hit
From: Casey Ransberger casey.obrie...@gmail.com
To: Fundamentals of New Computing fonc@vpri.org
Sent: Tuesday, July 30, 2013 1:22 PM
Subject: [fonc] Deoptimization as fallback
Thought I had: when a program hits an unhandled exception, we crash, often
there's a hook to log the crash
.
Cheers,
Alan
From: Casey Ransberger casey.obrie...@gmail.com
To: Fundamentals of New Computing fonc@vpri.org
Sent: Tuesday, July 30, 2013 1:22 PM
Subject: [fonc] Deoptimization as fallback
Thought I had: when a program hits an unhandled exception, we crash, often
there's a hook
John, I really don't think this list is for you.
Jason
On Tue, Jul 30, 2013 at 4:51 PM, John Pratt jpra...@gmail.com wrote:
The problem is that Alan Kay is a passive-aggressive twerp
who can't reply directly to people.
On Jul 30, 2013, at 3:49 PM, Casey Ransberger wrote:
Below.
It's true, I actually do things.
On Jul 30, 2013, at 4:53 PM, Jason Ives wrote:
John, I really don't think this list is for you.
Jason
On Tue, Jul 30, 2013 at 4:51 PM, John Pratt jpra...@gmail.com wrote:
The problem is that Alan Kay is a passive-aggressive twerp
who can't reply
I'm confused about what you're asking. If you apply an optimizer to an
algorithm, it absolutely shouldn't affect the output. When we debug or
report errors, it should always be in reference to the original source code.
Or do you mean some other form of 'optimized'? I might rephrase your
question
On Tue, Jul 30, 2013 at 1:22 PM, Casey Ransberger
casey.obrie...@gmail.comwrote:
Thought I had: when a program hits an unhandled exception, we crash, often
there's a hook to log the crash somewhere.
I was thinking: if a system happens to be running an optimized version of
some algorithm, and
13 matches
Mail list logo
