Friday, December 04, 2009

SimpleSort

This is an algorithm to compete with the current slowest sorting algorithms.

1. We're given our list to sort, L
2. Create a list of length 0, M
3. Randomly, either append a random* value to the end of M, or remove the last value. If M has length 0 then we do not remove the last non-existent value.
4. Check if all elements of M are in L.**
5. If yes, check if all elements of L are in M.
6. If yes, check if M is in order.***
7. If no, repeat from Step 3. If yes, we've sorted it.

* this could be problematic.
if it's an int of size 32 for example, we can just add a number from -2^31 to 2^31-1.
if it's a float, we could do something similar for the 80-bit or 64-bit floating point value.
if it's a bignum, we can apply step 3 to the number itself as a string of digits.
if it's a string, we could also apply step 3 here.
if it's some arbitrary object, we can randomize every primitive type it's composed of in the above manners

** something like:
for x in M:
if not x in L:
break
else:
it's in there.
and vice versa for Line 5.

*** something like:
M += [+inf]
for i in 0...len(M):
if M[i] > M[i+1]:
break
else:
it's sorted
RJavaScript

theteofscuba: it would be veryu cool if html provided support for the same idea behind silverlight and allow people to use javascript to script it instead of using actionscript in flash or .net in silverlight
theteofscuba: and providing support for an xml format of 3d models so javascript could be the basis for a 3d engine
theteofscuba is offline (3:59:46 AM)

Your IM will be delivered when the buddy goes online.
inhahe: i agree
inhahe: that javascript should be integrated with something like silverlight
inhahe: so that you use teh same language for everything
inhahe: there is one problem wit hthat though
inhahe: silverlight/flash apps might be more cpu intensive in some case because they're more graphics involved
inhahe: and javascript, even the next-gen js engines, is very slow compared to .net
inhahe: not sure about flash, i would imagine actionscript is faster too
inhahe: this is a fundamental limitation given by the afct that javascript is a more dynamic language
inhahe: one interesting prospect would be to provide something syntactically similar to javascript but that is really just a subset of the language, so operations requiring teh particular dynamicism of javascript won't work within a restricted javascript block
inhahe: so that they can be compiled into faster code and used for things that need more speed
inhahe: ideally you would be able to define a restricted javascript block whether or not you're doing graphics-speciifc thinsg and you should be able to do graphics-specific things whether or not you're using restricted jaovascript
theteofscuba's offline IM storage is full.

RJavaScript would be to JavaScript what RPython is to Python.

Thursday, December 03, 2009

Hash Table Sort

For a given input list of size n, make a hash table of size n*2.

Run through the list once to determine its maximum and minimum values.

Create a hash function that puts an item in a slot depending on where it lies in between the minimum and maximum values. For example, if there are 50 slots, the minimum value is 10, and the maximum value is 20, then a value of 12 would go into the 10th slot. (A comparable formula *can* be used for strings.)

After placing all the items, go through the hash table and sort each individual linked list, using the sorting method most efficient for its size (probably always an insertion sort where the input list is randomly distributed). Concatenate all the sorted lists end-to-end.

This algorithm is less particularly advantageous the less unevenly distributed the input list, but we can always mitigate that problem by using an n*n hash table or just a larger hash table to any degree. Even an n*(n/x) hash table where each secondary table is a table of linked lists.

This algorithm could also use a histogram to determine individual slot ranges and secondary table sizes.

Where the range of values is smaller than the length of the list, you don't actually need a hash table of size n*2. It can be of size range*2.

I think this whole idea is just reinventing the bucket sort. Oh well.

Sunday, October 18, 2009

Category-key-words

Keywords are superior to directory hierarchies because things often fit into more than one category and there's more than one way of categorizing things.

But categories are kind of easier to browse without having to think too much.

Solution: each entry is entered using keywords, but the category system is generated automatically

-a top-level category for each key word
-the second level of each category has a sub-category for each other keyword existing in all its elements
-and so on

for example

object a, keywords b, c, e
object b, keywords d, e
object c, keywords q

hierarchy:

b (object a)
c (object a)
e (object a)
e (object a)
c (object a)
c (object a)
b (object a)
e (object a)
e (object a)
b (object a)
d (object b)
e (object b)
e (object a, object b)
d (object b)
c (object a)
b (object a)
b (object a)
c (object a)
q (object c)

it might look like a really complicated hierarchy, but my theory is that it's not so complicated when you're collapsing and expanding branches at will from the top down.

Thursday, October 15, 2009

Efficient searching for substrings

I don't know if this idea's ever been done before, so I'll post it.

It's a way to search for substrings within a large dataset. Google's code, for example, I'm sure is very efficient, but doesn't do substrings. It just indexes words. The same method wouldn't work for substrings, because the sentence "I heard it through the grape vine" has 561, give or take, possible substrings.

So here's my way. It uses SQL, but obviously using hash tables or binary trees directly would also work. It's just easier to implement it in SQL, and possibly even more efficient on account of the DBE's query optimizer and so forth.

So I'm indexing the string "I heard it through the grape vine", say it's in Record 1.

my fields are (autonumber id, int nextid, char letter, int record)
we'll call the table t, just because it's convenient.

here's what i index:

(0, 1, 'I', 1) //or normalize it to lower-case so we can do non-case-sensitive searches
(1, 2, ' ', 1)
(2, 3, 'h', 1)
(3, 4, 'e', 1)
(4, 5, 'a', 1)
(5, 6, 'r', 1)
(6, 7, 'd', 1)
(7, 8, ' ', 1)
(8, 9, 'i', 1)
(9, 10, 't', 1)
(10, 11, ' ', 1)
(11, 12, 't', 1)
(12, 13, 'h', 1)
(13, 14, 'r', 1)
(14, 15, 'o', 1)
(15, 16, 'u', 1)
(16, 17, 'g', 1)
(17, 18, 'h', 1)
(18, 19, ' ', 1)
(19, 20, 't', 1)
(20, 21, 'h', 1)
(21, 22, 'e', 1)
(22, 23, ' ', 1)
(23, 24, 'g', 1)
(24, 25, 'r', 1)
(25, 26, 'a', 1)
(26, 27, 'p', 1)
(27, 28, 'e', 1)
(28, 29, ' ', 1)
(29, 30, 'v', 1)
(30, 31, 'i', 1)
(31, 32, 'n', 1)
(32, null, 'e', 1)

now i'll search for "rape".

Now here's my search query.

select a.record from t a, t b, t c, t d on a.nextid = b.id inner join b.nextid = c.id inner join c.nextid = d.id inner join a.letter = "r" inner join b.letter = "a" inner join c.letter = "p" inner join d.letter = "e"

Or something like that. I'm actually not that experienced with SQL. But you know what I'm getting at here.

The result of that search (after it's turned into sql that will actually work) will be 1, because "rape" occurs in record 1.

---

Another thing we can do is this

(0, 1, 'I', 1, 0)
(1, 2, ' ', 1, 1)
(2, 3, 'h', 1, 2)
(3, 4, 'e', 1, 3)
(4, 5, 'a', 1, 4)
(5, 6, 'r', 1, 5)
(6, 7, 'd', 1, 6)
(7, 8, ' ', 1, 7)
(8, 9, 'i', 1, 8)

etc.

where the last field is the index within the record at which that letter occurs.
it just happens to match id and nextid-1 in this example, but it wouldn't necessarily, because the same table would include many records.

that way if I searched for "rape" i would instantly know that it occurs in Record 1, at index 24, without having to do a string search through record 1's text (which is stored as a normal sting in some other table).

Also, we might want to use ints instead of chars for the letters to speed it up.

Also, for unicode you might have to do it a little differently. The same principle still applies.

It might also be safe to forgo the "nextid" field and do "...a.id = b.id-1 inner join a.id = c.id-2 inner join a.id = d.id-3...", but i don't know which way is more efficient. i suspect this way would be much less optimized.

oh, one other thing: obviously index the "nextid" and "letter" fields.

Saturday, October 10, 2009

*Possibly* Crack-Pot Idea

Have millions of users take random photos of the night sky with their digital cameras. Let them send them in to a central server. The server uses software to automatically align/rotate them with each other and group by time of year. It averages them out in order to get a very precise image of the entire night sky. It would probably want to use this precision to be able to remove the effect of light pollution from the result.
Consider this an anti-idea..

The Virtual Species: Post-Modernism Gets Physical
or Humanity's Launch into Hyper-Reality.. Next Stop: Oblivion

It's an interesting phenomenon whereby some people actually infiltrate home computers to install programs like SETI@home or Folding@home on them without their owners' permissions. It would invoke mixed feelings in me if it happened to me: it has all the nuisance of a trojan, but the intention behind it is different. It's something like, "I COMMAND that your computer work to serve humanity (and without your knowledge or consent)." Add to that the fact that I don't even agree with the Folding@home-and-ilk initiative, and I almost want to roll my eyes at such a person's choice to boldly get on that kind of a high horse.

I don't run Folding@home, and not because I want to save electricity, but because I don't believe in it. It's just a bunch of fucking manipulation. Einstein said, "the significant problems we have cannot be solved at the same level of thinking with which we created them," and I think that maxim really applies here. Forget the Power of Creation. Forget the Heart. Forget even all the modern causes of disease. Just solve the problem with manipulation. And not even physical manpilation, just some sort of abstract conceptual manipulation. But don't use human thought to do this, use computers. But don't use *one* computer, use hundreds of thousands of these silicone machines, not even individually created by humans but rather mass-produced in factories, solving our health problems by searching for virtual solutions in some ridiculously huge abstract mathematical possibility space. If the Greys really exist, and if they actually are infertile and hence creating human-Grey hybrids in order to continue their species, then this is why: they went down the same road we're going down now a long time ago.

Fuck Folding@home, Fuck Rosetta@home, Fuck Predictor@home, Fuck Foldit, and Fuck Robetta.

Fuck It Fuck It Fuck It Fuck It Fuck It!

I can feel the healing already..

Friday, October 02, 2009

More efficient color-adjusted bulbs

Give incandescent lights a better color temperature by using phosphors on the glass, instead of the typical way of using neodymium.
If Bank Robbers Were Smart..
Bank robbers should wear all black with horizontal orange or red stripes going all the way around the body. Orange and red are 'danger' colors in nature, and this would trigger the same unconscious response in the employees and customers. The robbers would be less likely to be challenged.

Tuesday, September 29, 2009

The Expanding Homeless Utility

I've had this idea for a while, but I decided I won't be the one to implement it, or at least not any time soon. So I'm sharing it with you.

The idea is for something like a homeless shelter, only it also provides opportunity for homeless persons to get back into the job market. It actually wouldn't be one homeless shelter, but many across the nation, handled by a single not-for-profit organization.

Any given center should provide:
-food
-clothing (including professional attire to borrow)
-shelter
-bathing
-transportation
-a usable address
-computers with internet
-help with resumes by someone competent in resume-making
-training in certain job skills
-a small library (with books pertaining to those skillsets, and on landing jobs)

But that's not all.
Every homeless person who enters into this program must sign a contract. The contract states that, if they get a job using this service, they must pay a certain percentage of their wages to the organization for as long as they're working. That means until retirement. This is how the organization would be able to afford all these services; without this, it might be impractical, or at least it wouldn't have the ability to expand into something very large.
It might seem harsh to garnish someone's wages for the rest of their working life. Some people think it's exploitation. But it's the only way to provide an opportunity for *mass* numbers of homeless people to get off the streets (with enough money, the program could afford also to take care of some homeless people who have no interest and/or no capability to get a job..), and for those working, I'm sure they'd rather be working and paying gratuities than still being on the streets. One could even consider it like any other tax and its accompanying social service, applicable only to a certain sub-economy within the United States. The US, as it is, has the lowest taxes of almost any developed nation, and in some of the richer countries, like Switzerland, those without jobs can collect unemployment benefits indefinitely; so rather than exploitation, the program can be considered a step in the direction of other developed nations.

Of course, it would be cruel to demand money of people who are just barely making it by as it is: consider someone who's just gotten off the streets, has 3 kids, one in college, and has some chronic medical condition.. while "expenses rise to meet income" and therefore we need to be careful with providing breaks to those "barely making it" by their own standards, in some situations we really should provide breaks. This should be a part of the contract, with the general rules laid out, though specific cases would, of course, be handled by third-party arbiters (or at least would be in the cases in which the person denied a break files an appeal).

Another option to explore, would be to require payback only during the first year (or two years, or three years or whatever) of employment directly after use of the services. This would seem less heavy-handed to would-be objectors, but it would provide only a *small fraction* of the funding otherwise available, so the program might be able to help only a small fraction of homeless persons that it otherwise might -- particularly among those who simply can't (or won't) enter into the workforce.

Monday, September 28, 2009

Duh. Benchmarks

Why does everyone struggle with unrealistic benchmarks?
Just do some logging of key presses and mouse strokes as users do normal activities within certain usage categories. Play them back within the system/language/application being benchmarked and see what the total time is. Do this for a number of different common tasks for each usage category, run them all and average the times

Saturday, September 26, 2009

Maze-in-a-pocket (A Mazing Idea!)

A hand-held device with either accelerometers or a GPS receiver (probably the latter), that can randomly generate mazes that it stores in memory. You walk around holding this device, and when you hit a wall it does one visual/sound, and when you find the exit it does another visual/sound. So you basically navigate this invisible maze until you make it out.

(it won't let you walk through walls -- if you try it'll just keep giving you the ugly noise until you get back to within eyeshot (within the maze) of the point at which you transgressed. or alternatively, it'll scrap the maze and you'll have to try a new one.)

Should be able to specify dimensions (in feet) of the maze and maze complexity (which determines thinness of the corridors).

i've changed my mind. don't just generate a random maze. take one from a database, or seed from a random number in a database (that implies you don't change the generation formula). also, perhaps have a way of networking maze entries among your friends, etc. what i'm aiming toward here is Sheldrake's morphic resonance.

this can most easily be issued as an iPhone app.
but you'd better hurry. i purchased my first iphone today.
Cheap, Tiny Computers

You know how they sell old-style gaming systems in little boxes nowadays?
Well, just do the same thing with the PC

-Use the Atom processor, so you don't need a cooling system, and you can run normal x86 apps.
-Make the whole thing a little box like no more than 3"3
-TV out instead of monitor out, so you just connect it to your TV (or, in alternative models, DVI or VGA output). simple graphics, about 2mb, no hardware 3d support
-ethernet port (and/or WiFi in alternative models)
-SSD harddrive, size depending on model - can go down to very small because you might want to use an OS for mobile devices
-DC-in and includes an adapter
-6 or so USB ports, for all your peripherals, keyboard, and mouse. (just forgo the ps/2 ports and any other ports.)
-RAM? Nowadays 1 GB goes for $10, at least for PC RAM. On the downside, for cost, PC RAM is more mass-produced, but on the upside this RAM doesn't have to be nearly as fast.
-main board? *shrug* make something up. this device is meant to be *functional*, it doesn't necessarily have to be super-fast.
-OS? Linux geeks might get a kick out of these, so make a version with linux. Also, maybe one with XP. Maybe even Windows 7, it's pretty efficient. Other considerations: Windows CE, Windows XP Embedded, Google Chrome OS, FreeBSD, ReactOS? (probably not finished enough), Xandros, PCLinuxOS, Mandriva, Aurox (all easy linux distributions)

Night Vision Without Electronics

a way to have night vision goggles
-in full color
-not requiring any electronics
-perfect resolution

Use BINOCULARS except having a magnification of exactly 1x.
if your front lenses are, say, twice as wide as your viewing lenses, your view will be gathering 4x as much light. if they're three times as wide your view will be gathering 8 times as much light, etc.

Tuesday, September 15, 2009

Grey WHAT!?

The most frustrating thing in today's software that's common to all applications, by design, and unnecessary, is greyed-out menu choices. I mean I understand the need for greying out choices, but the frustrating thing is that apps don't tell you /why/ a given choice is greyed out at a given time, and it's not at all clear in the majority of cases.

My idea is simple: provide tooltips when you hover over a greyed-out choice that give a brief mention of why the option is greyed out, and/or what you can do to rectify it. Applications could do this manually, but it would be easier if provided as a feature of the Windows (and/or even Linux) API, and that would also encourage the use of this new GUI feature.

Tuesday, September 08, 2009

Tailored Search Results

Google should adapt the primacy of its search results for the individual based on their past clicking history for related searches. They already have a program to do this on a global scale, but not for the individual, afaik. This way subsequent searches for the same or a related thing will get you faster to your results.
For Internet Persistence

A standard for a transport-layer internet protocol that will automatically and try to re-connect to a host indefinitely on unexpected connection loss or ping timeout, and not break the connection for the application layer in the meantime. Also it should try to reconnect based on domain name instead of IP, because IPs can change -- except where the host doesn't have a domain name or DNS fails. I guess it should also send the host a Session ID so that it knows which connection is being attempted to reestablish. One other possibility would be to also allow the host to simultaneously try to reconnect to the client, via a standard listening port for the protocol, though that may be superfluous.

I think this capability would almost automatically make a lot of internet things refreshingly simpler and even more reliable..
Enough with the Gay Plastic Halloween Periphenelia

For halloween - get a stunt dummy, that approximates human flexibility, dress him all up, but use lifecasting with makeup for the hands and face. you should probably carve his head smaller before you add the face so that the result isn't unnaturally large. give him a normal-looking wig too. set up some sort of large hook, which goes all the way through him from the back and out his chest, which he hangs from. make him wear a white t-shirt, and inject a cup or so of fake blood at the puncture point to let it saturate the t-shirt in a realistic pattern. also inject some into his mouth until it oozes down his face. set up the whole contraption in your front yard, perhaps as an addition to your garden. as an added touch, you could put a (slow) pump inside him and a reservoir of fake blood that makes sure blood is constantly, but verry slowly, flowing from his mouth and down his face, hopefully dripping off at some point. also, just to give it a bit more context, hang a sheet of paper on him with the words "Trick-or-Treaters Be Warned".

oh, and you might want to let the police in on it ahead-of-time because if you've done it right somebody's going to end up calling them. :)

oh, i guess you'll need lifecasted arms too with seemless integration with the hands, unless you use a long-sleeved shirt. but if you use a long-sleeved *white* shirt i think it'll look a bit hackneyed.

Sunday, August 30, 2009

Sleeker Cruise Control

for cars: A speedometer that's closer up, or a secondary pseudo-speedometer, that you can just touch a particular mph on it and the car will gradually speed up to that mph and stay there. it'll be just like regular cruise control, but with a cooler and more convenient interface.
Chocolate Coconut Milk

Three Words: Chocolate Coconut Milk

Friday, July 24, 2009

JITting native code

Although arguably it hasn't happened yet, JIT technology can theoretically exceed statically compiled C code, as far as I know.

What if there were a way to take execution of a normal (perhaps compiled from C) native program, trace its execution paths, and then do in-lining and whatever else JIT functions upon it? Perhaps just treat the x86 like any other bytecode and emulate it, except or the JIT'd parts which are more-or-less directly copied?

Although the problem with that is that emulating x86 (even on x86) is probably way slower than emulating normal language bytecodes, because x86 instructions are a lot more primitive and involve the architecture's peculiarities of register usage, etc. But I wonder if there's a way to trace paths without emulating it? It seems that somehow V8 does that, because they claim that it never executes bytecode. I don't really understand it myself.

*update*
idea:
modify the compiler to include calls in the (originally statically compiled) code that update an object by telling it that it execution passed through that code. then another thread can analyze this data and based on waht's there, and perhaps based on other meta-data included in the compiled program such as function boundaries and so on (if not even a complete or semi-complete bytecode, that's never executed), can take those paths and do things like in-lining, condition guards, moving variables to registers, and so on by creating new code sections in memory.

Friday, July 10, 2009

Better LEDs?

I heard that one of the things making LEDs inefficient is the fact that, since they're encased in plastic, half the light is refracted back in off the edges of the plastic. That's a 50% reduction in efficiency..

Why can't we just put LEDs inside glass bulbs (or, for that matter, plastic bulbs) like we do incandescent lights? That is, nothing contacting the surface of the diode.

Another idea: why are we using many small conventional-sized LEDs to make up light sources that actually put out a decent amount of light? Why don't we just make single LEDs with longer and/or wider diodes to put out more light? Maybe put them in larger zig-zag patterns?

Not that I would buy LED lighting anyway, until the QLEDs come out.

I also heard something about using salmon sperm to intensify LED light, something about trapping photons within the polymers or whatever. I'm not sure how I feel about us sexually violating salmon for our energy-efficient lighting purposes, but I don't see a reason why we can't synthesize the critical, uhh, ingredient in our labs. Once I mixed a bunch of soap with a little bit of hot water and let it cool for a while. ..That stuff was pretty damned gooey.

So here's the ideal solution:

* Quantum Dot LEDs
* Encased in a vacuum
* Widened/elongated actual diodes
* Synthesized polymers or, alternatively, a lot of soap, water and time.

There, ridiculously energy-efficient natural light at the color temperature of your choice.

I suspect that what would be even better, though, is thermally isolated, adjustable-temperature, actual blackbodies..

Thursday, July 09, 2009

Idea for a nutrition website

The website has a database of foods and which nutrients they contain (not just on the vitamin and mineral level, but also proteins, enzymes, glyconutrients, etc. etc.), and knows in what proportions the body needs all these nutrients

Then the user can put in things they definitely want to eat, and how much of them, and
the website can fill in for them what the rest of their diet needs to consist of to get the full gamut of nutrients. Then from those suggested foods they can also exclude certain things and/or choose between options and maybe specify how much of what they want to eat, which it then reacts to with further suggestions, and so on.

A wide variety of foods is really needed for good health, and hopefully the website's flow of suggestions would reflect that fact.

The person should probably be able to, or maybe have to, put in certain parameters regarding their body, such as weight, height, gender, age, fat index, blood pressure, cholesterol, etc.

Perhaps they can also put in specific areas they want to improve, such as "hair, skin and nails"

Allegedly nutrition isn't as simple as just ingesting this or that nutrient, in that certain nutrients and together and one might not be effective without the other. The site should also be aware of these interdependencies.

The user should be able to specify whether they want only natural foods, only vegetarian, only vegan, no red meat, only live foods, etc.

They might also should be able to include allergies to specific substances, lactose intolerance, etc., although maybe the same effect would be just as easily or easilier achieved through the exclusion of specific suggested foods.

It would be nice if this website didn't just have a database of staple foods, but also a vast database of specific products. And that should also come with the ability to exclude certain substances like polyunsaturated fats, aspartame, partially hydrogenated oils, high fructose corn syrup, sucralose, etc. — although the website could also exclude all such things, or least the really bad ones like what I just mentioned, by nature.

Though the specific products idea carries the problem of certain products only being available in certain areas and certain grocery store chains.

Another consideration is that, while certain substances (like sodium) are listed in terms of specific quantities, most of the ingredients, even though they're listed in order of quantity, don't specify their actual amounts. So to really effectively be able do the products idea, the website's owners would have to "rock the boat", in a sense, and get manufacturers to release specific ingredient amounts, by making the deal with them that, in exchange for releasing that data, their products can be suggested within, and thus promoted by, the world's most useful dietary website.

Thursday, June 18, 2009

for faster programming

to eliminate a lot of needless typing, the F-keys could be mapped to the most common key words and symbols for the given language. of course, symbols that don't require the shift key would be left out.

intellisense helps but it's not the same. it's easier just to type 'new', for example, than to try to let intellisense complete it for you. with this system typing 'new' would be one keypress.

this could also support binding to any arbitrary words/symbols you want.

the ide could even optionally track what you're using most and bind those things and have a display at the top of the screen constantly showing you the current bindings.

the only problem is that the F-keys are so far up on the keyboard that it may defeat the purpose -- having to shift your entire hand every time you use one. one solution could be to have a second key below the spacebar. it would be like another ctrl, shift, or alt, but more easily accessible. perhaps call it Func. whenever the Func key is pressed, the entire keyboard is mapped to symbols/keywords/whatevers.
the only problem with that is (besides the fact that it requires somebody to manufacture a new kind of keyboard), it's radical enough that probably only extreme programmers (not to be confused with eXtreme Programmers) would be interested in it.

Monday, June 15, 2009

Easier Integration for Programming Languages

inhahe (9:59:43 PM): you know what would be neat
inhahe (10:00:16 PM): a scripting language like python, supported in .net (ironpython already is this), but with the ability to arbitrarily create functions and classes in c# or msil
inhahe (10:00:24 PM): within the same source file

I mentioned it in the context of .net, but the idea doesn't have to be limited to .net. For example it could be just Python (or any other scripting language) intermixed with, say, C++, just without having to use external modules. However that kind of requires hacking two different languages together, but in the .net case both IronPython and C# compile to .net so it's not such a hack. The point of doing it is that Python (or some other scripting language) is higher-level than, say, C++ or even C#. (I believe that even though IronPython compiles to CLI, it's slower than C#, VB.net, etc. because of its higher level of dynamicism.) So by being able to include different levels of languages within the same source (hey, how about being able to in-line direct CLI, too?) it makes it easier for people to take advantage of both RAD languages and high-performance languages at the same time by writing the most CPU-intensive loops in a lower level language.

Thursday, June 11, 2009

share

new wiki for sharing ideas for my possible OS: inhahe.kicks-ass.net:8000
Per-function memory protection

There should be a way for the CPU to support confining a function's memory access without putting that function in another thread. By modularizing something in that way you incur the overheads of context switching and IPC, but without it a module carries the risk of corrupting the memory for the whole process and making the caller unstable. What's needed is for the CPU to support memory segments that apply only for a particular function call, so that if it segfaults we can catch that and have the function return a failure. So how do we do this?

* We could provide an opcode for switching only the segment registers
* We could set up associations for the MMU beteen certain EIP ranges and certain segments
* We could create a second "call" opcode that takes a second parameter which is an index to a segment context

Would this actually save any time, or does switching segments actually imply most of the overhead you'd get from a complete context-switch anyway?

If it works, this would allow us to have the benefits of a monolithic kernel and a microkernel at the same time.

Thursday, April 23, 2009

there should be an OLE function to drag and drop colors.

so when configuring something, just drag a color from anywhere - another application that you're trying to make it look like, a color picker, a theme palette on the web, whatever.
efficient hashtable

i've never seen a hashtable implementation, but i don't see how it could be more efficient than what i've come up with. according to the chart at http://burtleburtle.net/bob/hash/doobs.html , the 'generalized' crc algorithm has by far the best uniformity, and is one of the faster ones on the list (depending on how long your keys are, i guess). most, almost all, of those functions like to have table sizes in powers of two. so here's the algorithm, in unoptimized quasi-psuedo-code:
def init(orig_size): # must be power of two!
table_size = orig_size
table = malloc(table_size*whatever)
current_hash_bitmask = table_size-1

def add_key(key, value):
if table_size < (num_keys+1)*2:
double_table_size()
_add_key(table, hash_function(key), key, value)
num_keys++

def del_key(key):
_del_key(key)
num_keys--
if table_size/2 > num_keys:
halve_table()

def double_table():
table_size *= 2
current_hash_bitmask = table_size-1
new_table = malloc(table_size)
for 32_bit_hash, key, value in table:
_add_key(new_table, 32_bit_hash & current_hash_bitmask, key, value)
table = new_table

def halve_table():
table_size /= 2
current_hash_bitmask = table_size-1
new_table = malloc(table_size)
for 32_bit_hash, key, value in table:
_add_key(new_table, 32_bit_hash & current_hash_bitmask, key, value)
table = new_table

def _add_key(table, 32_bit_hash, key, value);
insert 32_bit_hash, key and value into the linked list at
table[32_bit_hash & current_hash_bitmask]

def del_key(key):
should be obvious

def get_key(key):
should be obvious


---

i started making a very efficient asm version of this, but i haven't finished because i don't have a memory allocation function yet, and i'm really tired right now, so i'll put something up later. here's what i have so far:

gencrctab:
dd 0x46d1e192, 0x66edf9aa, 0x927fc9e5, 0xa53baacc, 0x29b47658, 0x5a411a01
dd 0x0e66d5bd, 0x0dd5b1db, 0xcb38340e, 0x04d4ebb6, 0x98bc4f54, 0x36f20f2c
dd 0x4a3047ed, 0x1ec1e0eb, 0x568c0c1f, 0x6a731432, 0x81367fc6, 0xe3e25237
dd 0xe7f64884, 0x0fa59f64, 0x4f3109de, 0xf02d61f5, 0x5daec03b, 0x7f740e83
dd 0x056ff2d8, 0x2026cc0a, 0x7ac2112d, 0x82c55605, 0xb0911ef2, 0xa7b88e4c
dd 0x89dca282, 0x4b254d27, 0x7694a6d3, 0xd229eadd, 0x8e8f3738, 0x5bee7a55
dd 0x012eb6ab, 0x08dd28c8, 0xb5abc274, 0xbc7931f0, 0xf2396ed5, 0xe4e43d97
dd 0x943f4b7f, 0x85d0293d, 0xaed83a88, 0xc8f932fc, 0xc5496f20, 0xe9228173
dd 0x9b465b7d, 0xfda26680, 0x1ddeab35, 0x0c4f25cb, 0x86e32faf, 0xe59fa13a
dd 0xe192e2c4, 0xf147da1a, 0x67620a8d, 0x5c9a24c5, 0xfe6afde2, 0xacad0250
dd 0xd359730b, 0xf35203b3, 0x96a4b44d, 0xfbcacea6, 0x41a165ec, 0xd71e53ac
dd 0x835f39bf, 0x6b6bde7e, 0xd07085ba, 0x79064e07, 0xee5b20c3, 0x3b90bd65
dd 0x5827aef4, 0x4d12d31c, 0x9143496e, 0x6c485976, 0xd9552733, 0x220f6895
dd 0xe69def19, 0xeb89cd70, 0xc9bb9644, 0x93ec7e0d, 0x2ace3842, 0x2b6158da
dd 0x039e9178, 0xbb5367d7, 0x55682285, 0x4315d891, 0x19fd8906, 0x7d8d4448
dd 0xb4168a03, 0x40b56a53, 0xaa3e69e0, 0xa25182fe, 0xad34d16c, 0x720c4171
dd 0x9dc3b961, 0x321db563, 0x8b801b9e, 0xf5971893, 0x14cc1251, 0x8f4ae962
dd 0xf65aff1e, 0x13bd9dee, 0x5e7c78c7, 0xddb61731, 0x73832c15, 0xefebdd5b
dd 0x1f959aca, 0xe801fb22, 0xa89826ce, 0x30b7165d, 0x458a4077, 0x24fec52a
dd 0x849b065f, 0x3c6930cd, 0xa199a81d, 0xdb768f30, 0x2e45c64a, 0xff2f0d94
dd 0x4ea97917, 0x6f572acf, 0x653a195c, 0x17a88c5a, 0x27e11fb5, 0x3f09c4c1
dd 0x2f87e71b, 0xea1493e4, 0xd4b3a55e, 0xbe6090be, 0xaf6cd9d9, 0xda58ca00
dd 0x612b7034, 0x31711dad, 0x6d7db041, 0x8ca786b7, 0x09e8bf7a, 0xc3c4d7ea
dd 0xa3cd77a8, 0x7700f608, 0xdf3de559, 0x71c9353f, 0x9fd236fb, 0x1675d43e
dd 0x390d9e9a, 0x21ba4c6b, 0xbd1371e8, 0x90338440, 0xd5f163d2, 0xb140fef9
dd 0x52f50b57, 0x3710cf67, 0x4c11a79c, 0xc6d6624e, 0x3dc7afa9, 0x34a69969
dd 0x70544a26, 0xf7d9ec98, 0x7c027496, 0x1bfb3ba3, 0xb3b1dc8f, 0x9a241039
dd 0xf993f5a4, 0x15786b99, 0x26e704f7, 0x51503c04, 0x028bb3b8, 0xede5600c
dd 0x9cb22b29, 0xb6ff339b, 0x7e771c43, 0xc71c05f1, 0x604ca924, 0x695eed60
dd 0x688ed0bc, 0x3e0b232f, 0xf8a39c11, 0xbae6e67c, 0xb8cf75e1, 0x970321a7
dd 0x5328922b, 0xdef3df2e, 0x8d0443b0, 0x2885e3ae, 0x6435eed1, 0xcc375e81
dd 0xa98495f6, 0xe0bff114, 0xb2da3e4f, 0xc01b5adf, 0x507e0721, 0x6267a36a
dd 0x181a6df8, 0x7baff0c0, 0xfa6d6c13, 0x427250b2, 0xe2f742d6, 0xcd5cc723
dd 0x2d218be7, 0xb91fbbb1, 0x9eb946d0, 0x1c180810, 0xfc81d602, 0x0b9c3f52
dd 0xc2ea456f, 0x1165b2c9, 0xabf4ad75, 0x0a56fc8c, 0x12e0f818, 0xcadbcba1
dd 0x2586be56, 0x952c9b46, 0x07c6a43c, 0x78967df3, 0x477b2e49, 0x2c5d7b6d
dd 0x8a637272, 0x59acbcb4, 0x74a0e447, 0xc1f8800f, 0x35c015dc, 0x230794c2
dd 0x4405f328, 0xec2adba5, 0xd832b845, 0x6e4ed287, 0x48e9f7a2, 0xa44be89f
dd 0x38cbb725, 0xbf6ef4e6, 0xdc0e83fa, 0x54238d12, 0xf4f0c1e3, 0xa60857fd
dd 0xc43c64b9, 0x00c851ef, 0x33d75f36, 0x5fd39866, 0xd1efa08a, 0xa0640089
dd 0x877a978b, 0x99175d86, 0x57dfacbb, 0xceb02de9, 0xcf4d5c09, 0x3a8813d4
dd 0xb7448816, 0x63fa5568, 0x06be014b, 0xd642fa7b, 0x10aa7c90, 0x8082c88e
dd 0x1afcba79, 0x7519549d, 0x490a87ff, 0x8820c3a0

gencrc :
pop edi ; string object
mov ecx, [edi] ; str len
add edi, 4 ; start of str
pop eax ; hash function
gencrcloop:
mov ebx, eax
shr ebx, 8
xor al, [edi+ecx-1]
mov eax, [eax+gencrctab]
xor eax, ebx
loop gencrcloop

tablesize:
pop ecx ; number of entries
bsr ebx, ecx ; bsr == expensive
mov eax, 4
shl eax, ebx ; this should be the smallest power of 2 that's at least twice eax.
ret

addkey:
pop eax ; table object
pop edi ; string object
pop ebx ; value
mov ecx, [eax+4] ; number of keys
mov edx, [eax] ; table size
inc ecx
Efficient Malloc

So say you have some flat memory space and you're making a memory manager for it. It's not involved in page tables. This is something in the same vein as the "buddy block" system, only better.

Have an array of doubly-linked lists, the indexes to the array being steps of minimum amounts of memory to allocate. For example, the first linked list pointed to could be for chunks of at least 4 bytes, the second could be for chunks of at least 8, the third for chunks of at least 16, etc. Perhaps after a certain point we would stop doubling it, though, for example, 1024, 2048, 3072, 4096.., although we may still increase our granularity at certain points (while still making it possible to, via a formula, look directly to the right index without a search).

Each linked list is a linked list of available chunks of memory of a size in between its minimum size and the next-highest minimum size in the array. The end of the linked list simply runs off to the beginning of the next linked list, so that if all memory is taken for that chunk size then it automatically resorts to the next higher chunk size.

Of course, when a chunk is allocated it's removed from the linked list. When the chunk is freed it's inserted into the linked list. We can keep a hashtable of memory locations that remembers their sizes and locations of their list elements, or we can just return a memory object that contains more than just a pointer to the free memory.

Now, here's the method for consolidating otherwise adjacent blocks of free memory: when memory is freed, the addresses just before the beginning and just after the end of the chunk can be looked up in the hashtable. If the hashtable says that the memory chunk whose last byte is pointed to by the former is a free one, then the one we've just freed is conjoined with it (the exact location of the linked list item for the other block being stored within the hashtable value), and the same goes for if the memory chunk whose first memory location is pointed to by the latter is recorded as being free. Obviously we update the hashtable whenever we conjoin or split up some free memory, with both the chunk's first and last memory locations.

Oh, I forgot to mention: there is never any searching of these linked lists, because you always pop an item from the beginning of one to allocate a chunk, and insert one somewhere (for example, at the beginning of the appropriate linked list) to free one. (Obviously collisions can and will occur within the hashtable, but that only requires searching 2 or 3 elements now and then, by comparing ints.)

Tuesday, April 21, 2009

'Nother sort idea: Hash Sort

so if a hash function can distribute keys uniformly in slot space, then all we have to do is make a hash function that distributes uniformly and guarantees that the slots are in alphabetical order, then we can iterate over the slots and do compares for the ones with multiple entries in one slot. a hash function to distribute alphabetically for strings would be something like: num_slots*s[0]/256 + num_slots*s[1]/512 + num_slots*s[2]/1024 etc. of course this doesn't work very well if your strings actually have some sort of pattern to them, like for example they're readable. :p

since it's probably impossible to guarantee uniformity this way, you may want to use an n*n hash table. or perhaps an n*n*n. etc.

i guess you could say this algorithm is approximately O(n*log_256 k) where k is average element length in bytes? assuming you're not using unicode..

Monday, March 30, 2009

So I just tried this experiment
<html><body>
<div>
<div style="height: 100%; background-color: red; float:left">
this<br/>
is<br/>
a<br/>
test
</div>
<div style="background-color: blue; float:left">
hi
</div>
<div style="height: 100%; background-color: green; float:left">
foobar
</div>
</div>
</body></html>
If only the outer container would auto-adjust its height (or width) according to the max height or width of its inner containers, alignment wouldn't be such a pita.

Friday, March 27, 2009

CSS Ideas

So I'm working with CSS, and for once I'm going to try to separate content from presentation from the outset, since that's such an in thing to do these days.

Immediately a pretty big limitation of CSS came to mind in regards to doing that, exactly what they're always beating you over the head with that you're suppposed to be using CSS for. I've already written a little bit about how CSS should have been different before, but here are some of the thoughts that came to mind now and some that have been brewing for a couple of weeks, ensuing my more recent work with Ecography.com..

So what tags do we have for containing content, other than div? Span would be nice, except that it has strange limitations: it can't contain certain other HTML tags, and apparently it can't even contain line breaks. So we just have div, and then whenever we don't want a damn margin, because all we want to do is demarcate data, we have to write CSS code to specify that. Divs also by default come below each other in sequence, unlike normal information which flows left to right, so that's another thing you sometimes have go out of your way to change in CSS.

So clearly we're missing something here, something in between div and span, or at least a span that likes people.

I've also seen ul's used with CSS, for menus. You have to modify them extensively to get rid of the bullets and margins, maybe make them go left-to-right, etc. It seems like they're being used in cases like these for something other than their intended purpose, and I tried doing the same thing in some other way than using ul's, and it didn't work. So that implies that ul's are being used to fill in for some other shortcoming.

What I really was thinking right now, though, is that the degree of separation of content from separation in CSS is very limited. Basically you can specify sequences of information-elements and in specific hierarchies, and then display those elements and hierarchies in any way you want, but if the way you want to display it involves changing the order of the information (without using absolute positioning) that's a no-go. That can only be done by editing the HTML or the scripting code. Since a CSS file is designed to define only attributes of classes/tags on a syntactic level, there really isn't remotely a way for it to specify order of information. It would have to be changed dramatically.

To preserve backward compatibility, and its ease of specifying attributes, a new kind of syntactical entity should probably just be introduced that can specify sequences and hierarchies of information. The content itself, which would be found in the HTML code, would simply be referred to by id attributes. In the interest of the XML movement and consistency with HTML, the new syntax should probably be HTML-like, perhaps a subset of HTML. But then again in the interest of consistency/simplicity, why limit the HTML? Just make it full HTML, the only difference being the referring to of information by id attribute. And what if the HTML itself contains id attributes? Just allow it to refer to those too, I think..

But this just begs for a much simpler and somewhat more generalized and versatile solution: a) allow *all* HTML to convey other parts of the HTML, referred to by their id attributes, and b) allow HTML to include other HTML files. B) isn't so radical, since HTML can already include .css, .js, and image files. We're only making it more consistent here.

Now the only problem is that there's the possibility for circular references. It's only a philosophical problem, though, since they can easily be detected and ignored. Meaning that the simple solution here is: Don't Code Circular References.

Admittingly, it is a little awkward to have to specify that the content be hidden so that it can be shown in the correct place. But there is a solution: relegate all such content to <content> tags, which are automatically hidden. Actually "content" is a rather ironic name for things that will be automatically hidden, but you get the picture: the tag can be called anything.

Another shortcoming, and this is really the one that bugs me most often, is alignment.

There's a *big* issue in CSS where all the CSS gurus yell DON'T USE TABLES, not for layout purposes. Now here's the rub: people use tables for a reason. It's *easy*. In HTML, and in almost every other area of computer technology and life itself, simple things should be able to be done simply. Doing the same things you can do with a table with CSS is a real P.I.T.A. It's not at all obvious how to do it (to understate the problem), it's not quick and easy, and even a highly paid web front-end guru admitted to me that CSS has shortcomings in this area, when I asked him if there should perhaps be a CSS-equivalent to tables.

Is there a way to create a feature something like tables, per se, for CSS? I don't know, because I don't know precisely what the contention is with using tables; i.e., in exactly what ways does using tables prevent one from customizing layout in CSS? Tables provide alignment. What do they disprovide, and would this same limitation apply to adding, per se, a table-like feature to CSS? How would we do that anyway, on a semantic level?

I think a more generalized/flexible solution would be to provide some kind of alignment tokenization. Like you insert a token A at point B, then at point C say align this edge or that edge of this element with token A. Since you don't really have a place *in* HTML *at* the right/bottom/etc edge of a layout element, then either Token A has to specify which edge of the padding, margin or border it's binding to, or Token A can simply bind to a layout element and Token B would specify which edge and such of Token A to align to.

It can be much simpler than that, though. You'll almost always want to align a left edge with a left edge, a right edge with a right edge, a border with a border, a content edge with a content edge, etc. This symmetry can be the only thing allowed, or it can be assumed by default allowing a simpler syntax in the most common usage, probably just by leaving out extra parameters: for example, you could align B's left border with "A" (implying A's left border), "A/content" (implying the left edge of A's content), "A/right" (implying A's right border), or "A/right/content".

There should probably be even further shortcuts: for aligning both the top and bottom with another element, both the left and the right, or the content, margin and border all at once. To align B's top and bottom with A's top and bottom, at all three box layers, we could just align "B/horiz" with "A". To align only the top and bottom borders, align "B/horiz/border" with "A".

Then of course, we could also use relative positioning via the normal syntax to shift Element B's left or right content, margin, or border left or right of A's, if we so wanted.

I've decided the only way to specify tokens we need is the id attribute. So A is called A because that element's id="A". This simplifies things.

Exactly how to specify the alignment remains in question. Associating somehow "B/left/border" with "A/margin" doesn't really fall into either CSS's or HTML's syntax. There are just no conventions for associating two relatively arbitrary values. We could just say, within B's definition, align-top-border: A/bottom, but then that would combinatorily create 12 to 24 new CSS key words. If CSS's syntax were a little more flexible, we could say align {top-border}: A/bottom, or better, something like position: relative; top-border: {align: A/bottom; whatever: 2px} (to align B's top border with A's bottom border and shift it down 2 pixels).

And perhaps it should be. Then we could even then do this, for example:
top-margin: {position: absolute; whatever: 100px}
bottom-margin: {position: relative; whatever: 2px}

Or perhaps it would be
top-margin: {position: absolute; 100px};
bottom-margin: {position: relative; 2px}


Of course another idea would be to simply have a completely separate alignment table:
align 
{
B/horiz/border: A/content;
C/horiz: D;
}
That syntax would have to exist alongside one of the other formulations if at all, though, because it allows no cascading definitions, it's not object/class-oriented, and it can't be done in-line.

This idea so far can't do everything tables do. It can't size a bunch of cells (divs) according to the widest or highest automatic size. Do we *really* need to do that for content layout, though? (Actually, i think we do.) And what if we wanted to align two or more left or top margins where they would naturally go if it were one long margin? So in these cases we're not specifically aligning A after B, nor B after A, but we want those margins all in the same alignment class. What could we do? Probably the best solution is just to align them to an arbitrary common name, the same way in which we would otherwise use an id. This name would never be followed by /top, /horiz/content, etc., though, because that would be meaningless.

*Now* our alignment can do everything tables can do (I think?).

But this behavior should not be an automatic fall-back when no object happens to have the given name as its id, because it's doing a rather different thing. But instead of inventing new key words to align this way, we probably should just precede the name with a special symbol, like a %.
<div style="align-top: %hitop; align-bottom: %hibot; float:left">
This div's<br/>
height adjusts<br/>
to the height<br/>
of its text.
</div>
<div style="align-top: %hitop; float:left">
This div is smaller.
</div>
<div style="align-top: %hitop; align-bottom: %hibot; float:left>
This div goes down just as far as the first div does.
</div>
That was just an example to summarize and to show how simple it can all be, but it also raises a minor issue I hadn't thought of: how can we do a "horiz" or "vertical" align (implying left & right or top & bottom) with a %-preceded name? Well I can't think of a sound and consistent way, so we may have to do it just as coded above. We *could* just have the right or bottom margin be a second value that's used only for "horiz" or "vertical" alignments, while anything else referring to that name simply uses the top or the left value, and if only *one* element does a horiz or vertical align with it, but other elements do single aligns, then said element would only align its left or its top side. But that's if CSS has a "tolerant" coding philosophy, which I know browsers do but I don't know if the w3c does.

Thursday, March 26, 2009

Wheels that Won't Kill You?

How to make car wheels NOT poppable?

First of all, unless you can find some utterly indestructible elastic material to contain it, don't fill them with any kind of liquid or gas.

So...
  Make them out of some sort of solid rubber?
would this cause too much energy loss or melting due to internal friction?
Just put a bunch of radially oriented springs inside?
would need multiple parts of springs with different tensile strengths to
absorb shocks/vibrations at various frequencies/amplitudes?
Just have a hollow metal drum or perhaps a solid really hard rubber, and perhaps
with a thin layer of (softer?) rubber outside, with a sensitive suspension that
absorbs all the small stuff?

Or, maybe they can be gas-filled, but compartmentalized, much like with the
hugely successful Titanic.
Fill them with some sort of rubber or otherwise elastic aerogel substance?
Use normal tire rubber, but organized in rather large 3-d cells? 'Rather large'
might be 1-8 cubic inches.. just enough to mitigate damages while the tire can
remain flexible, not melt due to internal friction, and not be too heavy

Some of these options could call for an inner core that rarely needs replaced, but an outer rubber covering that could be replaced as needed (for treading and other wear-down) by the auto mechanic.
Just a Retarded Theory

Electrical transformers (such as wall adapters) are pretty clunky and inefficient and emit harmful EMF radiation. What if there's a better way?

You obviously can't just stick a component into the middle of the circuit that increases the voltage or the amperage. If it increases the voltage at the expense of amperage, where do all those extra electrons holes go? If it increases the amperage, where do all the extra electron holes come from? So obviously you need a completely separate closed circuit, somehow powered by the original, which is exactly what a transformer is but in an inefficient way. Is there a more direct way for Circuit A to pump Circuit B? Perhaps there is. Perhaps there are two.

In a battery voltage is multiplied by hooking them up in series, amperage by hooking them up in parallel. I would imagine this is true for charging, too, in an opposite sense. So..
a) charge the battery in series (this does not need a transformer; charge-pump capacitors, rectifiers, resistors, etc. can be used), while simultaneously draining the battery in parallel, or vice versa.
b) Don't optimize the chemicals for storage capacity; optimize them to efficiently immediately transfer ions or whatever on a constant basis.

..But wait! if we could just capture electrical energy for a second, say in the form of a static charge, in parallel, via Circuit A, and then release it in series, via Circuit B, or vice versa, then couldn't we have Circuit A pumping Circuit B with a V<->A conversion ratio? And wouldn't capacitors be exactly what we need to do this? Just use some more capacitors to alternate between charge and discharge, smooth out the output voltage, etc.

I don't know.. I never really understood electronics.
Washer/Drier Combos

*Why* don't people sell washers and driers as one unit? Not one unit for washing, one unit for drying, stacked on top of each other, but one unit the size of one that does both?

That would *so* save resources, to say nothing of money and space.

It's not that difficult. You just need a mechanism for pumping hot air into that drum that is impervious to the water when it's washing. Here are some ways to do that:

(this is the style of washing machine that opens from the side.)
have two layers of drum. washing machines must have this anyway so that all the water can escape out the holes and be captured by the larger drum during the spin cycle.
Have a tube that delivers hot air come up and back down right over the top of the inner drum. hot air can push in through the holes in the drum. this can be optimized by making very loong (but thin) holes at that distance around the whole cylinder. the tube can have a valve on the end of it, which for simplicity's sake automatically opens whenever hot air coming out pushes it open; when it's closed it's water-tight. that way no water will get into the tube.
or
have this tube come into a back part that doesn't spin (like with a dryer), but right near the top. equal anti-water advantage, no inner drum to block it. as the back part would be part of the outer drum, the inner drum is free to turn without having a back to it. just put the inner drum pretty close to the back so clothes don't fall through.
for the outgoing air, just have a large intake portal in the top of the larger drum. water shouldn't get that high, but if it does, the whole passage from there to the outside can be water-compatible, so it would just end up coming out the outside vent. we don't really want water constantly splashing into it and drizzling out, though, so have that passageway go a few inches up over the top of the drum, before it goes back down. or, just put something under it like what goes over chimneys to keep the water out.
or
just have an electrically opened/closed flap for the outtake passage that's relatively water-tight.
this could also apply to the hot air opening, of course.
btw, the hot air pipe should also go up a little after the drum before coming back down, in case the valve fails so water doesn't splash into it.
don't worry about water overflowing into it because there can be protections for that
1) electronic sensing to stop water from filling if it overflows
2) a drain near the top of the drum, just like in a bathroom sink. the drain leads into the pipe that drains used wash water.
You don't really need a flap for the air outtake vent because it can be put above the level of the overflow drain and then also rise further up before it goes back down. the same pretty much applies to the hot air input passageway.
although you don't really want your outtake vent getting the hot air back that was just put in there because it's next to the hot air input. so you could
1) have the hot air input deflect the hot air to the right or the left like a jet--the same direction the clothes spin in, and have the air outtake vent receive air from the opposite direction
2) have the hot air input in the back of the drum and the hot air outtake vent near the front (by the door). also should try 1) in conjunction with this.

that sounded complex, it's all really very simple.

now you can program the washing/drying cycle as one sequence, controllable from one single interface.
-clothes don't get left in the washer undried
-users don't have to take the clothes out of one drum and put them into another
-obviously, saves double the space, money, resources, manufacturing pollution, transportation pollution, time and effort.
Car Impending Collision Detection

Cars should have RF transponders in them that communicate with all other cars near them instantaneously. GPS wouldn't be sufficent to gather each other's immediate positions and velocities, but radio triangulation might. This data can be used to avoid potential collisions: if two cars detect that they're on a collision path, they can together make an avoidance plan and execute it (with automatic steering and/or breaking). This must be last-second (calculated based on speed, traction, weight of car, direction, etc.) because sometimes cars can appear to be on a collision course but it's just due to the shape of a road, traffic lights, etc.

I don't think attenuation-based or pulse-based radio triangulation would work, but maybe phase-based triangulation could?
How to triangulate several cars at once, though?
--they can coordinate to time their output signals to not happen simultaneously
--there can be a whole matrix of tiny antennas and an algorithm sorts it all out.
--each car can operate on a different frequency. the circuitry then either separates the frequencies and then take the phase info (or does it have to use interferometry to get the phases shifts?), or there can be a grid of independent sets of triangulation antennas each working on a different frequency.

or instead of radio, could use ultrasonic location signals? but windspeed must be known?
this could be hell on animals' ears, but perhaps that will keep them away from the roads. not good for pets living very near said roads, though..

Also, a car could have a camera or two (fast FPS) and a computer to in real-time deduce positions and velocities of objects nearby that stand out, then avoid anything that's too big or matches a certain profile (last-second, of course).
this has the following advantages:
-planning collision avoidance can take the environment besides other cars into
account
-it can avoid collisions with other things than just cars.
-it can be used instead of a radio/ultrasonic (relative) positioning system if those are impractical
-it doesn't require other cars to support the same technology.
although it would still help if these cars, independently sensing each others' positions via cameras, could communicate via radio to coordinate their avoidance plans.

perhaps the avoidance algorithm should have some heuristics for dealing with failed tires.

maybe also alternative avoidance branches for people wearing their seatbelt vs. people not wearing their seatbelt. for a person wearing their seatbelt, a head-on collision is better than a collision from their side? and better than a roll? which may not be true of persons without seatbelts on? actually a head-on or rear collision is probably always better now because cars are required to have airbags.
Econo-automobile
for people who can barely afford some transportation (and can boldly 'live simply') and for saving resources.
  no auto door locks
no power windows
windows don't crank, just have something to slide them up and down with and lock
in place.
some windows are plastic or acrylic?
no a/c or heating
no radio
dials: odometer, spedometer, fuel
buy battery separately, you might have one laying around.
manual trans.
no power steering
rudimentary shock absorbers - just fancy enough that it won't kill you.
make cylinders fire on both sides, so each one is a double cylinder?
rotary engine?
but shoudl probably use a completely different engine with better efficiency anyway
like those new ones in PopSci.
no back doors
no inside light - bring a flashlight if you need it.
no glove compartment - bring a box if you need it.
instruments are lit just by shining an LED on them
crank to start car?
have model without back seats
seats are cheap.
just a hard surface with some type of gel/water/air-filled sack
(compartmentalized into cells) over it? (this should probably help with the
shock-absorber issue better than a normal, expensive seat would, too.)
can't slide forward/backward, but can adjust tilt of back. just lock and unlock
with notches? (no springs, turning things, or continuously variable positions)
no microchip, those things are a pita anyway.
no paint job, or just something to make the surface legal if it's metal. in
which case, the paint has to stay on but it doesn't have to be consistent or
smooth or be a nice color.
no trunk?
really simple door handles? just push something left or right to latch / unlatch
which also serves as a handle to pull it open? the lock and key mechanism
would just block that sliding thing. or is it cheap enough already to do
it the normal way
can we do away with windshield wipers in lieu of anti-water windshield coating?
contracts with junkyards to use used parts?
could make several different types of fittings for some things to accomodate
different models
maybe could even use used engines, transmissions, bodies
small form
have no back of the car, except for support for the rear wheels, lights and
license plate?

don't skimp on safety
airbags
abs

Wednesday, March 25, 2009

Automatic Translation

All language translators out there currently on the web suck.

One idea for a very effective translator would be to feed a self-teaching AI program tons and tons of documents that already have existing translations, and have it automatically generate rules for proper translation. This would *automatically* accommodate for correct grammar, loose grammar, idioms, jargon, etc. This would require *a lot* of computing power, but it only has to be done *once*. Training documents can be found in existing corpora, or translated by hand specifically for the project. Two possible ways to generate rules would be: genetic algorithms, or some sort of exhaustion of many possible rule formulations (this could be bootstrapped with various types of data, for example, a word-sense->part-of-speech key, and a word-sense->popularity-of-use key.). Incidentally a week after I had this idea I heard a couple of people were working on just such a project, but I've yet to see the fruits of their results anywhere..

Rather than determining rules for translating to and from each possible combination of two languages, it's probably best to come up with *one* language that all languages can be translated to/from with no loss. Just making a collation of linguistic categories for words and clauses in each known language, and using these in an X-bar kinda structure, should be enough. Then any given language would be translated to this intermediate language, and then from that to the target language.

This greatly reduces the costs of furnishing texts for the learning algorithm and of the running it. This intermediate language's lexicon should be the superset of all the senses of all the words of the input languages, but with words identical in grammatical function and alike in meaning grouped into synsets, where each word in a synset is linked to each other word in the synset with a particular weight, which is their level of similarity (this may have to be done by hand). A word in a source text would, via a table, point to a word in some synset (if the word has any synonyms), and then the closest word to that (weight-wise), or the word itself, that some word in the target language points to, would be used.

A problem arises when a language possessing a certain tense/aspect/modality is translated to a language not possessing that. Possible solutions are: compromise and translate to a similar tense/aspect/modality that gets the point across, or totally rearrange the semantics of the sentence in the resultant text. This should not be too difficult given that the algorithm fully groks the grammatical structure of the sentence in the first place. Similarly some words won't exist in all languages. They can be handled by: using a similar-enough word that won't cause too much misunderstanding, or substituting the given word with a phrase (or, in some languages, possibly using agglutination).

Obviously I'm not implying that the semantic rearranging or phrase substitution would be wholly "figured out" by the translator; it would rely on a pre-programmed (or self-learned, via particular patterns found in the training texts) ruleset for such rearrangements.

"Similar-enough" words could be implemented using a weight mechanism just like the one used within a synset, but applying cross-synset/non-synonym. (In fact, we might as well just do away with a categorical consideration of synonym sets altogether.. unless lack of a bona fide synonym is used as a cue to look for a phrasal substitute?) Just enough vague linkages have to be drawn to accomodate all combinations of source/target languages. In fact for the sake of laziness, perhaps unlimited-length chains of weight-linkages could be used, when necessary. I suppose this requires a function for generating an overall priority value based on X number of Y-valued weights. For example, would we favor an a--(1)-->b--(2)-->c link, or an a--(3)-->d link? (1 means highest priority, because there is no bottom limit.) In this case, it would do to specify weights in arbitrary decimals rather than simply orders of priority.

We could effectively have myriad already-made translation texts available for training in this one-language approach, by creating a pretty darn good English<->the-one-language translator, and then using texts translated to and from English (it probably being the most widely translated language), with the English part being converted to/from the one language for the purposes of training. It remains in question how much trouble we should go through, if any, to make the program aware of whether a given training pair was actively translated from X to Y or from Y to X. This goes for the non-one-language approach also.

Machine learning may not be necessary: humans could perhaps construct perfectly comprehensive BNF notations (including idioms) and use a GLR parser, but I don't know how well this will work for (not-so-atypical) taking of grammatical liberties. If this approach is taken, the machine should obviously be programmed to understand affixes so that base words and inflections can be deduced for inflected words that aren't specifically in any dictionary. Another possible adaptation could be Damerau–Levenshtein distance or similar, to account for typos, misspellings, spelling variants, and OCR miscalculations. Also, a list of commonly misused words might also be helpful, though maybe not.

One trick to this translating could be to resolve ambiguous meanings, or connotations, of words in a sentence based on surrounding sentences. Meaning that if the word is used in such a way in a surrounding sentence that it definitely, or probably, means this or that, then we can induce that it probably means this in the given sentence, too. It could even be determined (by the given sentence or by a surrounding sentence) based on some pattern recognitions afforded by the training process. (These may even include subtle and holistic inferences.)

Meaning and grammar resolution can go both ways: grammar can help determine the sense of a word, and a known word sense could help determine the grammar of a sentence.

Connotation inferences (whether being done as-such, or effectively for consideration purposes but not internally tokenized on that level, per se) can even help determine the most germane translation synonym.

We *may* want to even layer our conferencing of meaning-resolution amongst sentences according to paragraph, chapter, document, author/source, and/or genre, but that's probably overkill, beyond just having a sentence-level tier and a document-level tier. Actually genre and source seem to be good too, since they're categories where you'd find words used in particular ways. Oh, I guess a sub-sentence-level tier could be relevant too (because the word could be used twice in the same sentence), but this layer would be treated a little differently of course, since self-contained syntax trees (mostly) start and end at the sentence level.

People can arbitrarily create new words on-the-fly in an agglutinating language. This would be hard for a translator to automatically substitute with defining phrases..but it would be easy to simply use a form of pseudo-agglutination in the given target language; for example, if poltergeist weren't already a well-known and established word, it would be translated into English as "rumble-ghost" or "rumble-spirit." Perhaps a little awkward, but I think it's pretty effective for getting a point across.

Monday, March 23, 2009

Better Home Networking

Any time an application tries to listen on a port, and the firewall allows it and has the option set to do this, the OS should send a special control signal (such as uPnP port forwarding) to the router for it to forward that port to the listening PC. When the port is no longer being listened on the OS can tell the router to un-forward that port. If that port is already being forwarded to another PC on the LAN, then the socket listen command could return an error.

This way multiple PCs on a LAN can occasionally use the same port numbers without having to explicitly set up/change port forwarding in the router setup, or one PC can always use that port without the user having to manually set anything up.
I don't think I posted this one yet..

Universal Programming Syntax

Any programming language syntax can basically be decomposed into nested lists. Something like XML. The lists would include parameters, keywords, function calls, whatever. It's essentially taking every structure and ordering its terms in the same way and conveying every operator to hierarchical structure or keywords. The idea is that if we could make a generalized language grammar, somewhat like XML but easier to type/read and perhaps more rich with structures, we could express any programming language is this form. That way learning a new language would be much easier, because you don't have to learn a new syntax or grammar--merely its constructs and functions--and also you wouldn't have to put up with really ugly syntax.

It isn't necessarily that every new language would have to use this specification, but that people could write front-ends that can convert from this specification to given languages and back, preferably as IDE plugins.

How exactly this language should be designed is hypothetical--I could take a shot at it, but that doesn't mean that my suggestion for a universal language is inextricably linked to my particular idea of an implementation of it.

One thing that comes to mind is that, although every nested structure in the program could be nested in the universal language in the same way, that could make it much less readable.
take, for example: for(int x=0;x<=255 && !y;x++) {do_this(exp((x+1),2)+3); }
you could write it as

for:
initial:
declare int x 0
compare:
and:
le x 255
not: y
action:
inc x
do:
function do_this:
sum:
exponent:
sum: x 1
2
3


and the above works okay for control structures, but is horrible for and's and or's and math--basically any operators.

and on the other hand, you could do it like this:

for(int(x,0), and(le(x,255),not(y)), inc x, function(do_this, sum(exp(sum(x,1), 2), 3))))

which is a little better for operators, but isn't so good for control structures.
and, of course, you could simply allow arbitrary line breaks and do it like this


for(
int x 0,
and(le(x,255),not y),
inc x,
function(do_this, sum(exp(sum(x,1), 2), 3))
)


but that still could be made a little bit more elegant, by allowing two forms of nesting:


for:
int x 0
and(le(x,255),not y)
inc x
function(do_this, sum(exp(sum(x,1), 2), 3))


(there indentation is being used as a grouping mechanism.)
and even futher, we could be more kind to operators, and technically we wouldn't even be changing the definition of the universal language:


for:
int x 0
((x le 255) and not y)
inc x
function(do_this, ((x plus 1) exp 2) plus 3)


although it might do to make some standards about how things in lists are ordered, so for example, you can't have the function/operator name be the 4th element in the list unless there are only three elements in which case it's the first element but only on tuesdays and depending on the price of beans as declared earlier in the source.

one thing we should not allow, though, is inexplicit priority of operators. all nesting should be explicit, that way you don't have to worry about learning the order of precedence for the particular language or thinking about it when you interpret some source code. exceptions maybe should be made, though, for basic numerical operators. i.e., everyone learns in elementary school or junior high that it goes: explicit grouping, then ^, then * and /, then + and -. although it's still on the table whether or not symbolic operators should be allowed in the specification. in some cases it makes it more readable, in other cases words would make their meaning more obvious. one solution would be to allow only >, <, <=, >=, *, /, +, -, . (namespaces), and either <> or !=. ^ shouldn't be allowed since it means exponent in some languages and XOR in others. and % can mean percent, modulus, string interpolation, etc. i'm being strict about it to make it easier for those who haven't done any learning of the language, although it could, perhaps, be made a language intended for people who do a little bit of studying. but that could make it a little more concise but a little less 'accessible'..

while it's up to whomever to specify how a particular language is translated into the universal language, there should probably be some guidelines set to foster consistency at little cost. for example, for loops exist in most every language, and we could dictate that for loops should start with the name 'for' as the first item. which they would probably do anyway, but perhaps there are other cases that are less normative. and more than just the 'for' would be specified.
common elements of a for loop include:

initialization
comparison
incrementation or whatever
variable name(s)
list you're selecting from
what to do

different languages would use different items of that list. each item could be given an official name, and a language uses whichever items are appropriate. it would be somewhat like the first example of code in this text, rather than the later examples where i just allowed positions in the list to determine meanings.

obviously mechanisms for literal strings and also comments need to be included. i'm a fan of Python's flexibility when it comes to literals. for comments i like C, I think they visually stand out well as being extraneous to the code. even moreso if it's all //'s but then you need an editor that can block comment and uncomment for convenience.

you may have noticed that i pulled some tricks with being able to use spaces to separate list items in some cases and commas in others. basically i tried to allow as much flexibility for the programmer in that as possible while maintaining that it can be interpreted determinately. so the three levels of separators/grouping would be spaces, commas and newlines, but they can be shifted up or down at whim. and parentheses can help too

i suppose other things that really demand symbols are dereferencers and subscripts. moreso dereferencers, because
a[10] can be handled as (a 10), a 10 or a(10), or even a sub 10, but dereferencers might be get tedious with having to type ptr ptr a, ptr ptr (ptr b), etc. however, instead of doing that we can do this: p2 a, p2(p b), etc. or _p _p (_p b) isn't too bad anyway. Should we have a mechanism for distinguishing language keywords from arbitrary names? this mechanism should probably be some non-enforced kind of Hungarian notation defined by the language translator. for example, key words could always be all caps.

another remaining issue is string literals. in what universal way should they be implemented? I would go for Python's syntax, with the possible exception that the 'u' modifier might become superfluous, as we could make everything always unicode, then translate to ascii or other encodings when necessary in the language translation. also we could add PHP's nowdoc syntax.

one other issue: the plain list vs. named sections formats, for example the way i did the 'for' command the first time vs. the subsequent times. should the language itself determine which one one uses, or should the user be able to use both styles for any given language? the parser could specify the components needed in a way similar to Python's defining function parameters, such that arguments may passed name, or just listed, and if particular grammar allows then names can even be passed that weren't pre-defined.

for those familiar with compiler technologies, yes, this is basically just a flexible, human-friendly way of specifying abstract syntax trees.

Tuesday, March 17, 2009

Many Little Turings FTW

The latest Intel chips (Xeon, I7 Core, etc.) have 700-800 million transistors. If one were to make the simplest logic-gate setup possible to run a Universal Turing Machine -- or not necessarily the simplest but making a few simplicity-vs.-efficacy trade-offs --, then parallel-scale it to around 800 million transistors, we could possibly have thousands, maybe even hundreds of thousands, of general-purpose CPU cores at once running in a single half-an-inch CPU.

Graphics cards, the current latest ones pushing 1 teraFLOPS, do something similar to this but their cores (or more accurately, stream processors) are not Turing-complete -- that is, they can't do general computing --, and they probably still take orders of magnitude more transistors per "core" (because they perform many sophisticated kinds of manipulations, such as floating-point instructions and specifically CGI-related functions, directly), thus meaning far fewer parallel units than this computer could have.

Multiplying two 16-bit numbers, for example, might take over 256 cycles, and adding two numbers could take at least 16, but with thousands/hundreds of thousands of cores it might all be worth it. (I come up with the values 256 and 16 because I'm thinking this machine would have no intrinsic conception of bytes and would process everything a bit at a time, but perhaps it wouldn't be that way.)

This idea is for a computer intended for very specialized applications, not general home computing as with a PC; average PC users have no use for thousands of simultaneous general-purpose cores.

It might be neat if we could actually make this self-programmable in a way, perhaps like a Turing machine with a self-modifiable state table. This kind of dynamicism would be very useful for a machine with such a limited instruction set. Maybe an AND could be re-written as an XOR, and so on. I'm not sure how that can be done in a way that doesn't incur so many extra transistors that they'd be better put to use by simply extending the instruction set andor adding more cores. Perhaps there can be intermediate router circuits that can re-route the flow of bits through the core's parts -- for example, through an AND gate instead of through an XOR gate. Or, perhaps there can be a number of different types of cores that have slightly different functionality, and the code determines which type of core a given thread goes to. Maybe a thread can even switch core-types mid-way through; its state information would be transferred to another core. (this could be effectively the same as reprogramming a core, but more limited.) The proportions of numbers of cores available for the various core-types would hopefully be determined by the most common use-case scenarios.

The Tile64 had a good idea for inter-core communication: each core has its own router, and a message passing from one core to another steps through each core in between to get there. This may be a reasonable way to do it, although it seems like it would be a rather complex thing for a system going for (per-core) minimalism. Perhaps the system could have very localized clouds of shared memory for X number of cores, and then those clouds of memory can themselves communicate with other clouds of memory. The CPU's scheduler would group tasks according to which tasks need to either communicate a lot with or share memory with which other tasks, or perhaps the operating system itself could. If the different-type-of-cores idea is used, then each localized core-cloud should probably contain a variety of different core-types. That way threads can more quickly switch core-type, and super-tasks involving different kinds of functions can more easily have their different functions inter-communicate -- though the second argument can go either way; perhaps some features should be locally grouped and some not.

Anyway, this is all on one chip. If we could have 100,000 cores on one chip, imagine how many petaFLOPS a supercomputer made up of these chips would do!

Sunday, February 15, 2009

...continued from previous post

Perhaps we could limit and specialize this idea somewhat for some purposes by, instead of simply trying to find optimal algorithms for any given purpose, considering it a domain of constraints, to make something analogous to a really, really complex calculus problem.

For example, take image compression. Your constraints could be that the resultant image be not necessarily the original but not differ from it more than a certain amount, either per pixel, something like per wavelet, or as an average over the whole pic, or some combination of those, in a number of separate dimensions. One dimension would be a rendered color's distance from the original color within a particular ergonomic color space, one could be the presence of specific distorting artifacts, some could get into theory of the qualitative differences between an artificially stochastic aspect of an image and data that the rendered image is based on which we consider to be virtually random in specific aspects. Another constraint could be how close to optimal the solution must be, or we could even look for an optimal balance between compressed size and the time it takes to compute the compressed image, and/or the time it would take to decompress it.

We obviously don't have the tools necessary to even begin to evaluate such a complex quasi-mathematical problem, but we could, perhaps, explore methods of evaluating such constraint or optimality problems using the principle of exploring methods of evaluating problems, and so forth and so on, recursively.

We don't have to work strictly by starting from an enormously complicated constraint & optimality problem expressed formally and trying to evaluate that, either. We could perhaps gain some tools that are useful for solving problems on *both* ends of the recursive progression by starting with evaluations of simpler systems, then gradually working our way up, thus adding a whole other dimension to the learning curve. Some tools we might use, BTW, other than the various analytical problem-solving methods we know of from all of maths, may be artificial neural networks, particle swarms, and genetic algorithms. We could even end up developing new alternatives or variants to all those methods, by means of our new methodology.

Ultimately, there is no knowing what we might be able to do for civilization in this manner, since we may apply what we discover to optimizing systems across the board, from data compression, to CPU design, to aerodynamics, to new kinds of gasoline engines, to manufacturing processes to economics.

Thursday, January 29, 2009

Optimal Optimizing Program

create a program that reads a program in machine language and does some periphery optimizations on it wherever it can, even if they're a little expensive

run the program on itself, then modify the program slightly so that, with its improved speed, it can afford to make some more serious optimizations

run the program on itself again, repeat cycle until your program completely refactors machine code to make it better.

the ideal goal would be to make a program that takes a program as input, and gives the most optimal possible program that does the exact same thing. that, per se, may not be practical, but it would be nice to see how far we can go with the idea.

once we have a pretty good optimizing program, we can run it once for a given program, even on a supercomputer if necessary, and then disseminate the result to all the end users.

there probably is not an optimal optimizing program that creates the best possible optimization in earthly time, because even if it had come up with clever ways to make specific kinds of optimizations, it could never *prove* that the result is the best possible optimization, in the most general case, without iterating through every possible program to verify. so a program that does *perfect*, per se, optimization, may not be a useful thing to aim for, that is by trying to optimize a program that originally *does* iterate through every possibility.
that same idea applies if we were to make the best sound compression software, etc.

Wednesday, January 14, 2009

Heisenberg Uncertainty

Consider a sympathetic resonator from which you take intensity samples 30 times every second. Now consider that its resonant frequency is 20 hertz. So at each sample you may get an exact number, which depends on all its previous activity, but yet, since a single wave itself is larger than the sampling period, the exact number doesn't have complete meaning. Or the time you sample it at doesn't have complete meaning. Either way you look at it.

This is reminiscent of the Heisenberg uncertainty principle, by which two variables like position or velocity can be individually known but their combined precision (multiplied) can't exceed h/2, and also since it's about waves it alludes to wave-particle duality.

So the two ways of looking at the amplitude/phase problem in the resonator example could correspond, somehow, to the two ways of sampling an object: position, or velocity. A different way of sampling it is a different way of looking at the object.

Saturday, January 10, 2009

The next level of HTTP tags

inhahe (6:12:28 PM): inhahe (5:46:22 PM): the idea is a simple mechanism to highlight a particular part of a webpage, which adds something to the url string
inhahe (5:46:41 PM): which you can then send to another person so they can see the webpage with the same thing highlighted, circled, whatever.
inhahe (5:47:01 PM): it would be an extension to the http syntax
inhahe (5:47:08 PM): /writes it
inhahe (5:47:32 PM): i see problems with the idea
inhahe (5:47:37 PM): hmm
inhahe (5:48:28 PM): nah i guess it works
phaldo (5:48:47 PM): why not just copy the text you want to highlight
inhahe (5:49:54 PM): that too but there are several reasonsyou might not want to. 1, if you copy the text, the formatting, font sizes colors, graphics etc. might not cross over depenidng on the medium your'e using to chat with
inhahe (5:50:01 PM): 2. a url is a lot shorter
inhahe (5:50:15 PM): 3. it's more useful to use as citations or references
inhahe (5:50:53 PM): i think the only problem with the idea is that if a document changes, the highlight information could become wrong or invalid
inhahe (5:50:58 PM): i just reaolized that
inhahe (5:51:07 PM): but we can just say too bad and let it become wrong or invalid in those cases