OOT: In RPN calcs, the enter between a number and an operation is not needed. This is one of the reasons why RPN requires less keystrokes than algebraic entry.
France? Like, the country with the 2nd or 3rd largest military? Or "that other nuclear power"? France IS a big guy. Disregard propaganda. Do remember the fact that they were one of (if not the first) the first modern democratic countries, and have truly helped others (USA) become democratic. Sometimes, when a friend says "no", he's still a friend, not a whiny old bastard.
If the modules are binary, the point is moot. If they're not, remember that a DSL can often encode the same functionality in less space (interpreter+data) than machine language. As you pointed out ourself, cache hitrate are extremely important, so by having less data to cache (and less new instructions to decode), the interpreter can probably be very competitive, or maybe even better than a binary.
Who said this was for every kid? If only one kid benefits from the additional 900 K (including the very complete help file), then it's a win for everyone. I, for one, learned to program in basic (and with a decent enough style (i only discovered functions once i met the internet, though)) with only a couple "10 games in basic" books (i hate VIC and TRS-80 basic with a passion. The conversion to QB/GWBasic took as much time as the typing). You can learn a lot by typing out listings, running them, and making trivial (at the beginning, anyway) changes.
Oh, btw, QBasic has a really good IDE, definitely not your average blinking underscore.
If you are going to put compilers/interpreters (please put CLISP or GCL:D) on it, don't forget the books and tutorials!
standard headers? FFI? The thing is that the CL standard was designed in a machine independant way, so standardizing FFI might have been hard. Apart from that, i'd like to know whatever the hell you're smoking: the CL standard is incredibly big (google CLHS), since it covers every function in its standard library.
There's nothing stopping you from doing it, though. Theoretically, it's possible, thus enabling us to set an upper bound on the maximal compression ratio for a scene.
Does anyone know how it compares to QEmu (http://fabrice.bellard.free.fr/qemu/)?
"QEMU is a FAST! processor emulator using dynamic translation to achieve good emulation speed. "
"News (May 8, 2004) QEMU version 0.5.5 is out. (Changelog). Much improved Windows 98 support. VGA support in PowerPC PREP target.
(Apr 26, 2004) QEMU version 0.5.4 is out. (Changelog). This is the first version which is able to install and run Windows XP (experimental). This is also the first version which is able to boot a PowerPC PREP Linux kernel on a PC."
Every differentiable function is continuous. However, not every continuous function is differentiable. E.G., y=abs(x) is continuous, but not differentiable.
To nitpickers: y=abs(x-.5) if you want to stay within the [0..1] domain.
I know i'm late, but what kind of disinformation is that?
The 49g+ emulates a saturn (a 4/64 bit CPU) on an ARM. Parts of the kernel is actually pure ARM, and we now know how to build functions in direct ARM code.
Both definitions of factorial (recursive and non-recursive) are perfectly good (mathematically) ways of defining the function. However, in the Real World, there's a large difference: even in lazy languages, allocating the space for the list (stream? generator? i'm not very well-versed in Haskell) is going to take memory and computing time. In fact, i think that in this particular (trivial) example, allocation will take as much if not more resources than generating the data itself. The recursive definition, on the other hand, does not present this problem, since the numbers are generated on-the-fly (and the function is tail recursive).
So, while defining factorial as the multiplication of a list might be very elegant, it's not extremely efficient (in both languages that are lazy like Haskell and those that aren't like, say, Lisp), since data is generated and then immediately thrown away. The recursive function remains elegant while not being wasteful. In fact, a compiler that recognizes tail-recursion should make it as efficient as the iterative version.
Forth is a language that has often been put on extremely small and simple die. It seems to me it would be possible to implement it on TMTA technology, especially considering the number of available registers - enough to guarantee the stack won't have to be put in RAM more than 90% of the time, iirc.
It's been a while since i covered this in bio, but here's what i remember. Mitochondria actually replicate by themselves in our cells. They would therefore have all the machinery needed to replicate mitochondria (and thus proteins, membranes, et, ie a basic living cell), or virus.
The nucleus is only the part where DNA is stored in eukaryotes, and transcripted in RNA; all the translation into a polypeptide is made in the cytosol (inside the cell, but outside any organelle), by ribosomes. Mitochondria, eukaryotes and prokaryotes (OK, so mitochondria might be prokaryotes:) have these ribosomes, and they all obey the same encoding, afaik (very surprising, yes).
I can see a few problems with mitochondrial virus. The zone between the two membranes of mitochondria is very acid (relatively); there ARE two more membranes to go through before getting inside it; there are just as many membranes to go through to disperse and infect, making infecting mitochondria in a single cell this pretty hard, let alone other cells. So, i guess it might work with a virus that isn't too virulent. If it infected an egg cell, it would get an incredible free ride, though:) Spread through whole organisms for generations, while only having to infect, go through the immune system, etc of a single cell.
Keep in mind, IANAB(b=biologist; i'm just a student, and bio isn't my major or anything).
OOT: In RPN calcs, the enter between a number and an operation is not needed. This is one of the reasons why RPN requires less keystrokes than algebraic entry.
My guess? MS Windows. Some apostrophes are normal apostrophes, others are converted to their own weird character set, seemingly arbitrarily.
France? Like, the country with the 2nd or 3rd largest military? Or "that other nuclear power"? France IS a big guy. Disregard propaganda. Do remember the fact that they were one of (if not the first) the first modern democratic countries, and have truly helped others (USA) become democratic. Sometimes, when a friend says "no", he's still a friend, not a whiny old bastard.
I can't wait until a substantial portion of the USA is without power and the only source of electricity in the area is a nuclear-powered US carr....
Oh wait, things just don't work like that. I think I'll stick to The Incredible Machine.
Possible answer: Because it's a thin client. All it can do is not display/send what it should.
If the modules are binary, the point is moot. If they're not, remember that a DSL can often encode the same functionality in less space (interpreter+data) than machine language. As you pointed out ourself, cache hitrate are extremely important, so by having less data to cache (and less new instructions to decode), the interpreter can probably be very competitive, or maybe even better than a binary.
Who said this was for every kid? If only one kid benefits from the additional 900 K (including the very complete help file), then it's a win for everyone. I, for one, learned to program in basic (and with a decent enough style (i only discovered functions once i met the internet, though)) with only a couple "10 games in basic" books (i hate VIC and TRS-80 basic with a passion. The conversion to QB/GWBasic took as much time as the typing). You can learn a lot by typing out listings, running them, and making trivial (at the beginning, anyway) changes.
:D) on it, don't forget the books and tutorials!
Oh, btw, QBasic has a really good IDE, definitely not your average blinking underscore.
If you are going to put compilers/interpreters (please put CLISP or GCL
Which, ironically, is off by more than 5%.
standard headers? FFI? The thing is that the CL standard was designed in a machine independant way, so standardizing FFI might have been hard. Apart from that, i'd like to know whatever the hell you're smoking: the CL standard is incredibly big (google CLHS), since it covers every function in its standard library.
There's nothing stopping you from doing it, though. Theoretically, it's possible, thus enabling us to set an upper bound on the maximal compression ratio for a scene.
READ must be in any Lisp that is a Lisp, and Lisp has been ported to many, many architectures (including C ;).
You know, emacs + TTS (carnival?) + speech recognition could probably be your voice OS.
:)
3 lispy emacs
The "solution" uses a single chip, as opposed to many components. ZMAX != Opteron, mmk?
Does anyone know how it compares to QEmu (http://fabrice.bellard.free.fr/qemu/)?
"QEMU is a FAST! processor emulator using dynamic translation to achieve good emulation speed. "
"News
(May 8, 2004) QEMU version 0.5.5 is out. (Changelog). Much improved Windows 98 support. VGA support in PowerPC PREP target.
(Apr 26, 2004) QEMU version 0.5.4 is out. (Changelog). This is the first version which is able to install and run Windows XP (experimental). This is also the first version which is able to boot a PowerPC PREP Linux kernel on a PC."
Every differentiable function is continuous. However, not every continuous function is differentiable. E.G., y=abs(x) is continuous, but not differentiable.
To nitpickers: y=abs(x-.5) if you want to stay within the [0..1] domain.
I know i'm late, but what kind of disinformation is that?
The 49g+ emulates a saturn (a 4/64 bit CPU) on an ARM. Parts of the kernel is actually pure ARM, and we now know how to build functions in direct ARM code.
BTW:
Both definitions of factorial (recursive and non-recursive) are perfectly good (mathematically) ways of defining the function. However, in the Real World, there's a large difference: even in lazy languages, allocating the space for the list (stream? generator? i'm not very well-versed in Haskell) is going to take memory and computing time. In fact, i think that in this particular (trivial) example, allocation will take as much if not more resources than generating the data itself. The recursive definition, on the other hand, does not present this problem, since the numbers are generated on-the-fly (and the function is tail recursive).
So, while defining factorial as the multiplication of a list might be very elegant, it's not extremely efficient (in both languages that are lazy like Haskell and those that aren't like, say, Lisp), since data is generated and then immediately thrown away. The recursive function remains elegant while not being wasteful. In fact, a compiler that recognizes tail-recursion should make it as efficient as the iterative version.
(defun fact (n)
(* (iota n)))
Re optimisation: So does CL.
Being a Smug Lisp Weenie, i'd like to point out that only lower level languages don't have support for arbitrary-size integers :p
7 888 7017263688642639077590031542268 4292790697455984122 5 2176854255965356903506788725264 3218962642993652046 0 5322598077652127082243763944912 0128678675368305712 7 7165001851765464693401122260347 2972406633325858355 5 4910289126407157154830282284937 9526365801452352336 8 2060806223281238738388081704960 0000000000000000000 0 000000000000000000000000
[54]> (! 300)
[anti lameness filter]
306057512216440636035370461297 268629388588804173576999416776 74125947653317671686
746551529142247757334993914
25476930271954604008012215776
57644883038890975394348962543
22936819436499564604981664502
06870150169794168850353752137
15693648223343679925459409527
00000000000000000000000000000
That's on Clisp 2.31, btw.
google for Vogelmann, iirc. The bump *either ont he top or on the bottom) would create some weird turbulences that would then bring more lift.
Forth is a language that has often been put on extremely small and simple die. It seems to me it would be possible to implement it on TMTA technology, especially considering the number of available registers - enough to guarantee the stack won't have to be put in RAM more than 90% of the time, iirc.
:)
ANyone up for this?
Working is a bit of an exaggeration. IIRC, it could hover, but wasn't stable enough, so they only let it fly tethered to the ground.
Or build a computer! I'm sure we'll see MEMS-based logic one of these days; what's stopping us from using cells to make them?
It's been a while since i covered this in bio, but here's what i remember. Mitochondria actually replicate by themselves in our cells. They would therefore have all the machinery needed to replicate mitochondria (and thus proteins, membranes, et, ie a basic living cell), or virus.
:) have these ribosomes, and they all obey the same encoding, afaik (very surprising, yes).
:) Spread through whole organisms for generations, while only having to infect, go through the immune system, etc of a single cell.
The nucleus is only the part where DNA is stored in eukaryotes, and transcripted in RNA; all the translation into a polypeptide is made in the cytosol (inside the cell, but outside any organelle), by ribosomes. Mitochondria, eukaryotes and prokaryotes (OK, so mitochondria might be prokaryotes
I can see a few problems with mitochondrial virus. The zone between the two membranes of mitochondria is very acid (relatively); there ARE two more membranes to go through before getting inside it; there are just as many membranes to go through to disperse and infect, making infecting mitochondria in a single cell this pretty hard, let alone other cells. So, i guess it might work with a virus that isn't too virulent. If it infected an egg cell, it would get an incredible free ride, though
Keep in mind, IANAB(b=biologist; i'm just a student, and bio isn't my major or anything).