Can anyone write this recursion for simple regexp more beautifullyand clearly than the braggarts

[Flash Gordon]

Most cell phones are pretty aggressive over power use. I believe that
that most shuts down their receivers for a significant percentage of
the time. They periodically wake up and check for data packets.

Also it is a low power transceiver, with the power adjusted dynamically
to be as low as it can get away with I believe, so the power used by the
transceiver is probably not all that high when running anyway.

I am pretty sure of the numbers.

I find them believable.

 

[Ben Bacarisse]

bring_radio_to_full_power();
do_something_cpu_intensive();
reduce_radio_to_partial_power();

Ah right. If this is the predominant pattern, and the ratio of the
power levels is very high, than this would explain the numbers.

 

[Ben Bacarisse]

Well, that's sort of the point -- most of the time, it's not using significant
power. (Note the HUGE gap between talk time and standby time...) So reducing
the power consumption of the times when it is using power is very close to
reducing overall power consumption by a comparable amount...

What I was missing was the tight linkage between all the power uses.
In another post you suggested the radio power can be tightly coupled to
CPU time. I did not know this was possible.

 

[Seebs]

Clearly you don't have a teenage daughter.

No. Worse yet, people won't even sell me one!

-s

 

[Keith H Duggar]

Also it is a low power transceiver, with the power adjusted dynamically
to be as low as it can get away with I believe, so the power used by the
transceiver is probably not all that high when running anyway.


I find them believable.

It's always amusing when someone with actual real-world experience
(in this case Walter) stops by and presents some empirical facts
that contradict the same-old tired "computers are so fast these days
....", "the next Intel chip will do an infinite loop in 2 minutes"
"my home computer has enough RAM to archive Google" blah that people
use to advocate whatever resource intensive product they fan-boy.

Then we can watch the inevitable spectacle of the advocates trying to
discredit the empirical evidence and claims with the same of tired
yada: "yeah but *most* computers ..." "those chips are not as common
as ..." "those are very old systems ..." "this thread is about
general purpose CPUs not ..." "but *modern* processors" "I don't see
how (even though I'm entirely ignorant of the field) that can be the
case" etc etc etc *yawn*. It happens so often as to be truly sad.

KHD

 

[luserXtrog]

To be painfully precise, it's not quite "Any C expression with a
value of 0" that's treated as false, it's any C expression whose
value *compares equal* to 0.

0, which is syntactically an octal (yes, octal) integer constant,

that suggests: !7

yields the value zero of type int.  0.0 yields the value zero of type
double; it's really a different value, since it's of a different
type.  But the comparison (0.0 == 0) yields a true result because
of the conversion rules, so in "if (0.0)" it's treated as false.

So rather than "Any C expression with a value of 0", it's any C
expression whose value, when compared to 0 using "==", after any
conversions imposed by the "==" operator to force both operands to
be of the same type.




'-'-'-'

~(unsigned)-1

 

[Nick Keighley]

[...] Also, writing a
sandbox in Common Lisp is not hard at all, although afaik no one has
published one as a library. If only I had infinite time... *sigh*

http://www.ccs.neu.edu/scheme/pubs/icfp99-ffkf.pdf

 

[James Kuyper]

luserXtrog wrote:
....

~(unsigned)-1

I meant to restrict my comment to constants, rather than constant
expressions, but I see that I've already violated that rule with my last
example. There's already far too many ways to write constants which
compare equal to 0, the variety of ways of writing constant expressions
which compare equal to 0 is just mind-numbing.

 

[luserXtrog]

luserXtrog wrote:

...



I meant to restrict my comment to constants, rather than constant
expressions, but I see that I've already violated that rule with my last
example. There's already far too many ways to write constants which
compare equal to 0, the variety of ways of writing constant expressions
which compare equal to 0 is just mind-numbing.

Roger that; reining it in. Had to share the funny ones.

 

[Phil Carmody]

Definitely. In combination with lowering the core clock frequency
and voltage too, even more may be possible.

If you tell me you know about this stuff I'll just take your word for
it (because I don't) but I would otherwise have thought that a fair
proportion of the power use during talk goes on the radios and the
screen.

When in handset mode, the screen will be blank, presuming your device
has a proximity sensor. Radios, however, do suck a lot of juice. Most
phones do not spend most of the time in calls, though.

During standby, everything is in a low-power nearly-off mode
for more than 95% of a 24hr day. Could the CPU being able to shut
down in half the time really have a dramatic effect?

Yes. If standby time is 9 days, and movie-playing time is 3 hours,
then playing a 2 hour movie will decrease your remaining standby
time to 3 days. If you double the efficiency of the movie decoder,
then your standby time may well only be decreased to 6 days.

Guess who's been running powertop all day...
Phil

 

[Phil Carmody]

Presumably when its running and doing something that uses the CPU? I
can't see how my phone could use 40% less battery since only a gross
programming error could account for it using an significant amount
power for the CPU for most of the day.

The implementation of one of the underlying library calls may have
been fundamentally different, using a polling scheme rather than a
poll()ing scheme, for example. That can account for massive wastage.

Phil

 

[Phil Carmody]

We can't. Ale is a kind of beer. You're thinking of ale vs. lager, or
even more correctly, of top-fermented vs. bottom-fermented beers. But
since I've just finished a Belgian trappist and am halfway through a
Dutch white beer, I'd much prefer to opine that I really, really like
both (*hic*).

The Dutch wit was probably top-fermented, most wheat beers are.

And what your distinction gains in pedantic correctness, it loses
in pedantic correctness. You can make something most lager-like by
brewing using ale yeast in lager-like conditions, such as a Kolsch,
and you can brew something most ale-like by using a lager yeast in
ale-like conditions, such as a steam beer.

For a perfect local example of what is technically a lager, but
tastes far more ale-like, try a Christoffel Nobel or Blond. Full
refund guaranteed if you don't like at least one of them. (Cracked
Kettle normally stocks them, I'd have thought Bierkonig would too.)

Phil

 

[Tim Rentsch]

I believe it was another famous Lisp hacker, David Moon, who said that
no language can prevent a bad programmer from writing bad code. [snip]

The name you're looking for may be Larry Flon.

 

[Richard Tobin]

I believe it was another famous Lisp hacker, David Moon, who said that
no language can prevent a bad programmer from writing bad code. [snip]

[/QUOTE]

The name you're looking for may be Larry Flon.

Possibly. Quite likely several people have said something similar.
This page attributes it to Moon in the form "No language can prevent
the bad programmer from writing bad programs unless it prevents him
from writing any at all":

http://marvin.cs.uidaho.edu/~heckendo/quotes.html

-- Richard

 

[Tim Rentsch]

I believe it was another famous Lisp hacker, David Moon, who said that
no language can prevent a bad programmer from writing bad code. [snip]

The name you're looking for may be Larry Flon.

Possibly. Quite likely several people have said something similar.
This page attributes it to Moon in the form "No language can prevent
the bad programmer from writing bad programs unless it prevents him
from writing any at all":

http://marvin.cs.uidaho.edu/~heckendo/quotes.html[/QUOTE]

Excellent, thank you for the reference.

 

[Robert Maas, http://tinyurl.com/uh3t]

The reason that part of the runtime of many language
implementations, including CL, is written in C is because the
environment (OS, system libraries, etc.) is written in C, and at
some point we need to interface with them. The simplest way to
interface with C is using C, wouldn't you think?

No, I don't think so. A typical API (Application Program Interface
(to the OS)) is by loading registers and/or pushing parameters on a
stack, the executing a special machine instruction that traps to
the OS, then upon return copying data out of the registers and/or
popping return values off the stack. That doesn't sound at all like
the way any C program works. Not even function calls are like that,
maybe the stack parameters is like that but the caller executes a
subroutine call, specifying a function entry address somewhere
within the address space controlled by the calling program. But
with the API, the special instruction traps into a place within the
OS which is *not* within the address space of the application
(caller). It sounds to me like assembly language (or even machine
language), or Forth, is more likely to directly talk that API.

People have found creative ways to minimize the amount of code
that needs to be written in C;

Or none at all. Assemblers don't need to be written in C. They
could be written in their own assembly language. And Forth could be
cross-compiled from an earlier version of Forth, or built in
assembly language, again no C needed.

 

[Nick Keighley]

No, I don't think so. A typical API (Application Program Interface
(to the OS)) is by loading registers and/or pushing parameters on a
stack, the executing a special machine instruction that traps to
the OS, then upon return copying data out of the registers and/or
popping return values off the stack.

that's the OS bit. Now what about the libraries? There usually *is* a
C interface into the OS.

That doesn't sound at all like
the way any C program works. Not even function calls are like that,
maybe the stack parameters is like that but the caller executes a
subroutine call, specifying a function entry address somewhere
within the address space controlled by the calling program. But
with the API, the special instruction traps into a place within the
OS which is *not* within the address space of the application
(caller). It sounds to me like assembly language (or even machine
language), or Forth, is more likely to directly talk that API.

and a C interface is nearly always provided

Or none at all. Assemblers don't need to be written in C. They
could be written in their own assembly language. And Forth could be
cross-compiled from an earlier version of Forth, or built in
assembly language, again no C needed.

why use assembler when you have C?

 

[Robert Maas, http://tinyurl.com/uh3t]

Keep in mind that we're talking about a language that's extremely
Indeed when the human time needed to do a one-of task, such as
one-time data conversion or always-changing code in support of
scientific research, is a hundred times the computer time, and the
computer time is "dirt cheap" ($20/month for computer time compared
to $50/hr for human professional software-engineer time), so that
99.9% of the cost of a project is human professional labor while
only 0.1% of the cost is the computer time, shaving the computer
time by a factor of two, or even ten, is an utter waste of time.

Only software that is utterly stable for a long time, used billions
of times between software upgrades, where the CPU cost is a
signficant fraction of the total system cost, would benefit from
bumming code at the expense of extra human labor to tweak it that
factor of two faster. I'm thinking MS-Windows may be the only
software in the world that could truly benefit from spending lots
of human time to make it run faster, because of the extremely large
user base, except that MS-Windows typically sits idle 99% of the
time, running in short burts to refresh the screen whenever the
user moves something, so actually maybe even MS-Windows doesn't
qualify for being worth the human-labor cost to tweak it a little
bit faster.

From: Bart <[email protected]>
... I'm working on a dynamic language now which at present is
some 3 to 10 times as slow as optimised C (although there's some
way to go yet...). ... But that's measured for tight integer code.
When you throw in some string processing, higher level datatypes,
and calls into the runtime, then they can be comparable, say
between 1 and 2 times as slow, for a language considerably more
expressive (ie. increase in apparent runtime of 0 to 100%). In
theory...

If it's expressive enough to cut human time by a factor of two in
designing new algorithms and getting them working, then I'd say the
CPU time lost (compared to C) is not worth crying over.

And ultimately, for programs with a short runtime, it really
doesn't matter if it takes 100ms or 200ms.

Actually in some cases it *does* matter. A case in point: I'm
currently building TinyURL.Com/NewEco. TinyURL.Com/Portl1 links to
the portal into what I have so far, running in PHP/MySQL on a free
hosting service. From the start I planned to charge users for how
long scripts take to run, paid by their labor contributing to the
project. From my experience with CGI/CMUCL, I expected typical
scripts to take a second or two. Well, I installed start+end
clock-checks, subtract to get time of script, and typical times are
less than one millisecond for short scripts and up to maybe 20
milliseconds for longer scripts. So this means if one of my users
performs a mere ten seconds of labor to earn ten seconds of credit
that's good for hundreds of script-runs, maybe thousands. But if
something took an extra 100ms suddenly, that would be **noticed**,
for sure. If I eventually have millions of simultaneous users, each
executing one script every ten seconds, that's hundreds of
thousands of script-runs per second, even the small number of
milliseconds each script-run now takes might be too slow, and I
might need to distribute the load onto multiple servers.

There's a difference between a program that takes 200ms to run to
completion on a single-user system, with most of the CPU time
sitting there waiting for the user to issue the next command, and a
CGI or PHP server application that has millions of simultaneous
active users, where even a few milliseconds per user's script-run
is putting a heavy load on the server/CPU. Deeper into a serverside
appliation, if different components of the appliation are using
SOAP to communicate with each other, there may be millions of SOAP
transactions per second, and a few extra milliseconds each may be a
killer.

I think it's time to go into Monty Python mode, no not "SPAM",
instead "profile". If your application is too slow, find out what
exactly is making it slow, don't guess, run a profiler or something
equivalent. It may be the user interface is too hard for users to
grasp, so they take longer to react. Or it may be some part of the
computer code that is too slow and is run so very often that it
becomes critical. You can't just guess on principles, although
principles can guide you what to measure first in the hope of
finding the answer quickly.

Going deeper into that side topic, for anyone who is curious about
NewEco: After I finished rescuing my 59 megabytes of GeoCities files
last weekend, I've been spending the past several days making tweaks
to the core accounting parts of NewEco/Portl1, namely:
- Create account;
- Login;
- Spend 4-10 seconds to fill in missing word in randomly chosen
sentence/phrase to prove you're not spambot and thereby earn
4-10 seconds of CPU time, i.e. 4000-10000 milliseconds of CPU
time, i.e. hundreds to thousands of script-runs;
- Logout;
and as of earlier tonight I have it in good enough shape that I'm
now seriously planning the next core feature, namely surveys. I'm
too tired to start actual coding tonight, so that's why I'm
responding to newsgroup articles instead. The basic way these
surveys will work is that any user can *invest* any portion of
his/her current account in any particular item in any particular
survey. This is not a payment, it's an *investment*, because like a
bank account it can be withdrawn at any time, but like investment
in a business it accrues productive value during the whole time
it's deposited before withdrawn.

So what surveys? I'll start off with two:

* What survey would you most like to invest in?
- Survey of what survey you'd like to invest in (i.e. this self);
- Survey of what NewEco features you'd like me to work on next;
- Fill in blank: ___________________________________________________

* What NewEco feature would you prefer that I implement next?
- FilJob = Filtering job ads to eliminate the ones you don't qualify for;
- TruFut = Truth-futures market, estimating truth of claims;
- Contract work: Post RequestForBids, lowest bidder does work and gets paid;
- PAlert = Priority-alert notification system;
- Fill in blank: ___________________________________________________
(Suggestion: Look at TinyURL.Com/NewEco and
http://www.rawbw.com/~rem/WAP/projectIdeas.html
for ideas of online services I'm eager to implement if you show interest.)

My current idea for design is 3 tables:
- List of surveys
- List of items in surveys
- List of investments by users in items in surveys

 

[Robert Maas, http://tinyurl.com/uh3t]

And then there are those horribly objective people who will let the
task govern the language choice. What are we to do with *them*?

<MaynardGKrebs>You rang?</MaynardGKrebs>

Depending on the application, I program in CMUCL, PowerLisp, PHP,
HyperTalk (scripting langauge in HyperCard), Forth, and
occasionally several other languages. I'm also sometime maybe soon
going to implement a whole new way to develop software without
using any programming language at all, no syntax, only
intententional datatypes and sub-classed by implementational
datatype plus search-engine to find appropriate utilities that are
already programmed for these datatypes. (If I were to give this new
system a name I'd probably have to call it "Dijkstra", because
it'll be heavily oriented towards his three primitives for building
a function-body, plus function definitions per se, or maybe I'll
call it "Agile" because of the way it'll unit-test each line of
code on real data.)

You have a string. What would you like next?
Integer.
Would you like the length of the string, or a parse of digits in
the string per some radix, or the UniCode numbers for one or more
of the characters, or the index of some character or sub-string
within that string, or a count of characters or sub-strings that
appear within that string, or the number of non-empty "words" per
some delimiter, or ...?

 

[Richard Tobin]

No, I don't think so. A typical API (Application Program Interface
(to the OS)) is by loading registers and/or pushing parameters on a
stack, the executing a special machine instruction that traps to
the OS, then upon return copying data out of the registers and/or
popping return values off the stack.

That's an ABI (Application Binary Interface), not a typical API.

-- Richard