Stefan Viljoen wrote:
> Ever had something "saved" to an audio cassette, and you had to PLAY it back 
> to the computer? And if it played too softly or loudly it would be 
> scrambled?

Ah yes!  You get brinky-brinks on TRS-80 when tape is right! :-)

> I remember doubling them (they held 120KB if I remember right) by turning a 
> store-bought one over, and cutting another write-protect notch at the 
> opposite side, so I could write on the "backside" of the disc, storing 240KB 
> (wow, that's a LOT!) on one disc.

That too.

I remember when Myst came out on CD too and thought "Well, so much for 
pirating games. You've got like 20x the size of a hard drive on this thing, 
you could never copy it." :-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Stefan Viljoen <pov### [at] polardcom> wrote:
> Ever had something "saved" to an audio cassette, and you had to PLAY it back 
> to the computer? And if it played too softly or loudly it would be 
> scrambled?

  It was possible to recognize the type of data by the sound. For example,
the very first thing that the vast majority of Spectrum games did was to
load a loading screen (usually a depiction of the cover art, sometimes
something else), and that made a very distinctive sound which I could
instantly recognize even today.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> which I could instantly recognize even today.

That's hardcore. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > which I could instantly recognize even today.
>
> That's hardcore. :-)

Puts me in mind of the blind character in 'Sneakers' who could tell what sort of
wiring they were snooping by the buzz it made over his speaker.

Post a reply to this message

Darren New wrote:
> Warp wrote:
>> which I could instantly recognize even today.
> 
> That's hardcore. :-)

That's nothing.

I saved specially designed images to tape to try to reverse-engineer the 
algorithm for turning colours into tones. I figured out that if you save 
in image composed of horizontal bands of colour, the tape contained a 
series of long, continuous tones, and they changed order depending on 
which colours you used.

(Recall that the Spectrum stores scanlines in a weird order though...)

Post a reply to this message

> That's nothing.
>
> I saved specially designed images to tape to try to reverse-engineer the 
> algorithm for turning colours into tones. I figured out that if you save 
> in image composed of horizontal bands of colour, the tape contained a 
> series of long, continuous tones, and they changed order depending on 
> which colours you used.

Have you ever heard of sing-song?

This was a C64-program that played a tune on your floppy by repositioning 
the read/write head.

Post a reply to this message

TC wrote:
> This was a C64-program that played a tune on your floppy by repositioning 
> the read/write head.

I wrote a program once that you could set a radio on the console and it 
would play music with the interference from the bus lines.  You know, back 
in the days when instructions ran at roughly the speed of AM radio 
wavelengths. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New wrote:

> TC wrote:
>> This was a C64-program that played a tune on your floppy by repositioning
>> the read/write head.
> 
> I wrote a program once that you could set a radio on the console and it
> would play music with the interference from the bus lines.  You know, back
> in the days when instructions ran at roughly the speed of AM radio
> wavelengths. :-)
 
I consider THAT hardcore.

I remember how my dad cursed when he found out the Apple interfered 
precisely on his ham radio frequencies.

No, he never bother to try shielding it, we got a IBM PC next. As I remember 
it was still noisy in the ham bands but much less than the Apple was.
-- 
Stefan Viljoen

Post a reply to this message

Stefan Viljoen wrote:
> I consider THAT hardcore.

Hardcore would be still remembering which instruction loops made which 
tones. :-)

Someone else did a program that played the opening of the Fifth Symphony by 
controlling the hammer timing on the line printer while it printed out a 
2-page ascii-art picture of beethoven.  That's was pretty cool. :-)

Or playing taps with a program that fit in the 16 registers of the machine 
after you'd told it to power down and the memory was no longer online. :-)

-- 
   Darren New, San Diego CA, USA (PST)
     Is God willing to prevent phrogams, but not able?
       Then he is not omnipotent.
     Is he able, but not willing, to prevent phrogams?
       Then he is malevolent.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > which I could instantly recognize even today.

> That's hardcore. :-)

  Well, not really. Images are far from being as random as eg. machine
code or other game data. After all, images are not just noise, but have
tons of patterns in them.

  As someone commented, Spectrum used a rather weird ordering for the screen
pixels (for some reason I never understood; maybe they thought they were being
smart or something, but it really backfired; after all, I'm sure that when
they first designed the architecture they didn't even think that it would
actually be used to play full-fledged full-screen games):

  The first 32 bytes in the screen memory represented the first line of
pixels (256 of them). The next 32 bytes represented the *eigth* line of
pixels. The next 32 bytes represented the *sixteenth* line of pixels,
and so on, until you get to one third of the screen, ie. 8 such groups
of 32 bytes, after which the next 32 bytes represented the second line
of pixels, the next 32 bytes the ninth line, and so on. Then it went to
the second third of the screen, and then the third third, in the same way.
(Besides those being nice "round" numbers, otherwise that ordering makes
absolutely no sense, and I don't think there's a single person in existence
who understands why they chose such a weird ordering. It only made coding
games a lot harder than it had to be. Well, programmers learned to cope.)

  After those, the next 32x24 bytes had the color data.

  Anyways, both the fact that images contain regular patterns instead of
random pixels *and* that weird ordering made an image saved on casette to
have a rather distinctive sound which any Spectrum user would recognize
immediately. The color data itself also made a relatively distinctive
sound, especially coming immediately after the pixel data, which made it
immediately recognizable when the color data begun.

  (One nice thing about all that data being mapped to RAM into consecutive
memory locations is that you could load an image directly from a casette
to the screen, and watch it form while loading, in real-time.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   The first 32 bytes in the screen memory represented the first line of
> pixels (256 of them). The next 32 bytes represented the *eigth* line of
> pixels. The next 32 bytes represented the *sixteenth* line of pixels,
> and so on, until you get to one third of the screen, ie. 8 such groups
> of 32 bytes, after which the next 32 bytes represented the second line

Hmm didn't this have to do with it being quicker to multiply by powers of 
two to get the next address by shifting right instead of "actually" 
multiplying?

But why then not just put the memory in a contiguous arrangement, where 
incrementation would get you the next line?

> of pixels, the next 32 bytes the ninth line, and so on. Then it went to
> the second third of the screen, and then the third third, in the same way.
> (Besides those being nice "round" numbers, otherwise that ordering makes

I seem to remember that this same technique (shifting right instead of 
multiplying) was in the Turbo Assembler Bible by Gary Syck as a quick way to 
get the offset of an x and y location in 320x200 VGA.

> absolutely no sense, and I don't think there's a single person in
> existence who understands why they chose such a weird ordering. It only
> made coding games a lot harder than it had to be. Well, programmers
> learned to cope.)

From the far distant past... isn't this something that is vaguely similar to 
"mode-x" used for 320x200 VGA displays, especially by demo coders of the 
late 80's?
 
>   After those, the next 32x24 bytes had the color data.
> 
>   Anyways, both the fact that images contain regular patterns instead of
> random pixels *and* that weird ordering made an image saved on casette to
> have a rather distinctive sound which any Spectrum user would recognize
> immediately. The color data itself also made a relatively distinctive
> sound, especially coming immediately after the pixel data, which made it
> immediately recognizable when the color data begun.
> 
>   (One nice thing about all that data being mapped to RAM into consecutive
> memory locations is that you could load an image directly from a casette
> to the screen, and watch it form while loading, in real-time.)

You saw this on the Apple ][ as well - but then I guess it was just because 
it was so slow. (Even when loading from the Apple's floppydisk). 

-- 
Stefan Viljoen

Post a reply to this message

Stefan Viljoen <pov### [at] polardcom> wrote:
> Warp wrote:

> >   The first 32 bytes in the screen memory represented the first line of
> > pixels (256 of them). The next 32 bytes represented the *eigth* line of
> > pixels. The next 32 bytes represented the *sixteenth* line of pixels,
> > and so on, until you get to one third of the screen, ie. 8 such groups
> > of 32 bytes, after which the next 32 bytes represented the second line

> Hmm didn't this have to do with it being quicker to multiply by powers of 
> two to get the next address by shifting right instead of "actually" 
> multiplying?

  No. That doesn't explain why the screen is divided into 3 sections and
the horizontal lines jump around. It makes eg. drawing a sprite a whole lot
more complicated (and slower) than if all the pixels were just contiguous.

> > of pixels, the next 32 bytes the ninth line, and so on. Then it went to
> > the second third of the screen, and then the third third, in the same way.
> > (Besides those being nice "round" numbers, otherwise that ordering makes

> I seem to remember that this same technique (shifting right instead of 
> multiplying) was in the Turbo Assembler Bible by Gary Syck as a quick way to 
> get the offset of an x and y location in 320x200 VGA.

  It has nothing to do with shifting or multiplying.

> > absolutely no sense, and I don't think there's a single person in
> > existence who understands why they chose such a weird ordering. It only
> > made coding games a lot harder than it had to be. Well, programmers
> > learned to cope.)

> From the far distant past... isn't this something that is vaguely similar to 
> "mode-x" used for 320x200 VGA displays, especially by demo coders of the 
> late 80's?

  The pixel arrangment in the Spectrum was not to save memory or address
space, nor is it at all similar to that in geometry.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> which I could instantly recognize even today.
> 
>> That's hardcore. :-)
> 
>   Well, not really.

That you think you could still recognise it? *That* is the hardcore part. :-)

> (Besides those being nice "round" numbers, otherwise that ordering makes
> absolutely no sense, 

The only reason I could think of would be memory bandwidth issues. DMA was 
quite expensive at the time.

-- 
   Darren New, San Diego CA, USA (PST)
     Is God willing to prevent phrogams, but not able?
       Then he is not omnipotent.
     Is he able, but not willing, to prevent phrogams?
       Then he is malevolent.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> > (Besides those being nice "round" numbers, otherwise that ordering makes
> > absolutely no sense, 

> The only reason I could think of would be memory bandwidth issues. DMA was 
> quite expensive at the time.

  There might have been some technical reason for that odd pixel ordering,
but I have the gut feeling that they decided on that ordering for some
subjective (and ultimately stupid) reasons, like "it looks cool when an
image being loaded appears in sparse scanlines which get slowly filled"
or something along those lines.

  It might perhaps had even made some sense if the 8-pixel jumps from one
pixel row to the next would have been continuous from top to bottom, but
instead, as said, the screen was divided into three parts so that the upper
third of the screen would fill up first, and when it was completely full,
then the middle third, and then the lower third.

  (With a vertical resolution of 192 pixels one third makes a round amount
of 64 pixels, ie. 8 rows of 8x8 blocks. While all that sounds all round and
nice in binary, it's a real pain in the ass to draw anything, and you have
to waste precious clock cycles into jumping properly around inside the
screen buffer to draw something. In the Spectrum everything had to be done
with the CPU, as there were no auxiliary graphic chips of any kind.)

-- 
                                                          - Warp

Post a reply to this message

Bill Pragnell wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> which I could instantly recognize even today.
>> That's hardcore. :-)
> 
> Puts me in mind of the blind character in 'Sneakers' who could tell what sort of
> wiring they were snooping by the buzz it made over his speaker.

Yep, his name was Whistler.  They never stated why he was called that, 
but I always assumed he could whistle a perfect 2600 :)

...Chambers

Post a reply to this message

Darren New wrote:

> I wrote a program once that you could set a radio on the console and it 
> would play music with the interference from the bus lines.  You know, 
> back in the days when instructions ran at roughly the speed of AM radio 
> wavelengths. :-)

Dude, I thought this was just an urban legend! O_O

Post a reply to this message

On Tue, 17 Nov 2009 17:02:43 +0100, Darren New <dne### [at] sanrrcom> wrote:
>
> I wrote a program once that you could set a radio on the console and it  
> would play music with the interference from the bus lines.

http://hackedgadgets.com/2006/07/17/music-via-monitor-interference/



-- 
FE

Post a reply to this message

Warp wrote:

> Stefan Viljoen <pov### [at] polardcom> wrote:
>> Warp wrote:
> 
>> >   The first 32 bytes in the screen memory represented the first line of
>> > pixels (256 of them). The next 32 bytes represented the *eigth* line of
>> > pixels. The next 32 bytes represented the *sixteenth* line of pixels,
>> > and so on, until you get to one third of the screen, ie. 8 such groups
>> > of 32 bytes, after which the next 32 bytes represented the second line

Which ZX Spectrum video mode was this?

'pedia says there are / were lots and lots of them - what mode does this 
arrangement refer to? The lowest res one?

Or were all the modes arranged similarly to this way, only with longer lines 
and "quicker" jumps?
-- 
Stefan Viljoen

Post a reply to this message

Stefan Viljoen wrote:

> Warp wrote:
> 
>> Stefan Viljoen <pov### [at] polardcom> wrote:
>>> Warp wrote:
>> 
>>> >   The first 32 bytes in the screen memory represented the first line
>>> >   of
>>> > pixels (256 of them). The next 32 bytes represented the *eigth* line
>>> > of pixels. The next 32 bytes represented the *sixteenth* line of
>>> > pixels, and so on, until you get to one third of the screen, ie. 8
>>> > such groups of 32 bytes, after which the next 32 bytes represented the
>>> > second line
> 
> Which ZX Spectrum video mode was this?
> 
> 'pedia says there are / were lots and lots of them - what mode does this
> arrangement refer to? The lowest res one?
> 
> Or were all the modes arranged similarly to this way, only with longer
> lines and "quicker" jumps?

From http://www.worldofspectrum.org/faq/reference/sereference.htm:

---
Memory is paged in 8K banks from either the DOCK or the EX bank, but these 
banks are mutually exclusive - you cannot page in a bank from both 
simultaneously. Bit 7 of port 0xff determines which bank to use (0=DOCK, 
1=EX-ROM). Port 0xf4 determines which banks are to be paged in with each bit 
referring to the relevant bank (0-7 or 0'-7'). When memory is being paged, 
interrupts should be disabled and the stack should be in an area which is 
not going to change.

On a TC2048, BASIC is contained in the 16K ROM area and banks 0-7 and 0'-7' 
are not normally available, while on a TS2068 part of the BASIC is stored in 
an 8K ROM in bank 0' and cartridges plugged into the dock use banks 0-7. On 
the SE each of these banks is connected to 64K of RAM, providing an 
additional 128K in addition to the base RAM.

The contended memory timings for the SE are unknown but should be similar to 
that for the 48K machine, except that the pattern starts at a different 
number of T-states after the interrupt, than the usual 14335. Odd banks in 
the 128 scheme are contended.
---

"Memory is paged in 8K banks from either the DOCK or the EX bank, but these 
banks are mutually exclusive - you cannot page in a bank from both 
simultaneously."

and

"The contended memory timings for the SE are unknown but should be similar 
to that for the 48K machine, except that the pattern starts at a different 
number of T-states after the interrupt, than the usual 14335. Odd banks in 
the 128 scheme are contended."

What does that imply? It seems as if the reason for the knit-one-slip-one 
video RAM approach was the way the Speccy handled interrupts, and / or the 
hardware being incapable of paging more than 8K at a time? (8192 bytes / 256 
bytes per line = 32 ?)

I. e. on one interrupt tick you can get the first 32 columns of line one, on 
the next tick the first 32 columns of line sixteen, etch. - due to the 
limitations of the architecture's memory handling paradigm of "max 8k 
blocks" only?
-- 
Stefan Viljoen

Post a reply to this message

Stefan Viljoen <pov### [at] polardcom> wrote:
> Which ZX Spectrum video mode was this?

  The ZX Spectrum has exactly one video mode.

> 'pedia says there are / were lots and lots of them - what mode does this 
> arrangement refer to? The lowest res one?

  I don't know which article you are reading, but it's definitely not about
the ZX Spectrum.

-- 
                                                          - Warp

Post a reply to this message

Stefan Viljoen <pov### [at] polardcom> wrote:
> From http://www.worldofspectrum.org/faq/reference/sereference.htm:

> ---
> Memory is paged in 8K banks from either the DOCK or the EX bank

  This talks about the RAM, not the reason why the pixels are arranged as
they are.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

> Stefan Viljoen <pov### [at] polardcom> wrote:
>> Which ZX Spectrum video mode was this?
> 
>   The ZX Spectrum has exactly one video mode.
> 
>> 'pedia says there are / were lots and lots of them - what mode does this
>> arrangement refer to? The lowest res one?
> 
>   I don't know which article you are reading, but it's definitely not
>   about
> the ZX Spectrum.
>
 
http://en.wikipedia.org/wiki/ZX_Spectrum_graphic_modes

?
-- 
Stefan Viljoen

Post a reply to this message

Warp wrote:

> Stefan Viljoen <pov### [at] polardcom> wrote:
>> From http://www.worldofspectrum.org/faq/reference/sereference.htm:
> 
>> ---
>> Memory is paged in 8K banks from either the DOCK or the EX bank
> 
>   This talks about the RAM, not the reason why the pixels are arranged as
> they are.

Hmm. Wouldn't it make sense? The video display is just visible RAM by 
definition... isn't it? Or am I mistaken?

I. e. if you can only address an 8K page at a time, and access to memory is 
limited by the last-triggered interrupt, and the limitations / maximum word 
size of your architecture.

I. e. on one tick you can address even lines.

On the other you can address odd lines.

Given that 8K paging is your "chunk limit", wouldn't that explain why the 
video pixels are arranged in such a way as you describe? 

Everything fits if you assume you can only address 8192 bytes at a time 
during any given interrupt - you CANNOT address the whole screen, because 
your word size is too small.

Contrast with an IBM PC with a VGA card. You can comfortably get a linear 
address into the entire 320x200 screen (64000 bytes) with any of the CPU's 
16 bit address registers. With an 8 bit address register you can't? 

So you arrange your video RAM (which you can't all address at once with an 8 
bit address register) to "give" you alternating blocks on an interrupt which 
is acted upon by your memory controller, effective switching contexts with 
each tick?
-- 
Stefan Viljoen

Post a reply to this message

Stefan Viljoen <pov### [at] polardcom> wrote:
> http://en.wikipedia.org/wiki/ZX_Spectrum_graphic_modes

  The "ZX Spectrum clones" are not ZX Spectrum. The standard ZX Spectrum had
only single video mode.

-- 
                                                          - Warp

Post a reply to this message

Invisible wrote:
> Dude, I thought this was just an urban legend! O_O

Nope. When your clock speed is in the kilohertz range, it's pretty easy.

-- 
   Darren New, San Diego CA, USA (PST)
     Is God willing to prevent phrogams, but not able?
       Then he is not omnipotent.
     Is he able, but not willing, to prevent phrogams?
       Then he is malevolent.

Post a reply to this message

>> Dude, I thought this was just an urban legend! O_O
> 
> Nope. When your clock speed is in the kilohertz range, it's pretty easy.

Perhaps you mean "when your clock speed is in the kilohertz range and 
all opcodes take a deterministic number of clock cycles to fetch and 
execute"?

Even then, it seems highly unlikely to me that anybody would actually 
work out which opcodes yield which EM intensity and somehow produce a 
carrier wave of the exact right frequency and precisely modulate its 
intensity... This would surely be a vast engineering task.

Post a reply to this message

> Perhaps you mean "when your clock speed is in the kilohertz range and all 
> opcodes take a deterministic number of clock cycles to fetch and execute"?
>
> Even then, it seems highly unlikely to me that anybody would actually work 
> out which opcodes yield which EM intensity and somehow produce a carrier 
> wave of the exact right frequency and precisely modulate its intensity... 
> This would surely be a vast engineering task.

With the ARM processor it would be easy, as all the "standard" instructions 
take the same time and all are 32 bits.  You can easily look up how each 
part of each instruction maps to each of the 32 bits and then decide what 
patterns to send.  You could even probably keep 4 or 6 bits the same (eg to 
do an ADD instruction) and then just set the rest to whatever you want to 
make your pattern (it would just mean random registers got added and stored 
in other ones etc).

I would imagine after a bit of trial and error of different 00000111111 and 
000111 type patterns you could get it working.

Post a reply to this message

scott wrote:


>> intensity... This would surely be a vast engineering task.
> 
> With the ARM processor it would be easy, as all the "standard"
> instructions
> take the same time and all are 32 bits.  You can easily look up how each
> part of each instruction maps to each of the 32 bits and then decide what
> patterns to send.  You could even probably keep 4 or 6 bits the same (eg
> to do an ADD instruction) and then just set the rest to whatever you want
> to make your pattern (it would just mean random registers got added and
> stored in other ones etc).
> 
> I would imagine after a bit of trial and error of different 00000111111
> and 000111 type patterns you could get it working.

Granted, doing something like that would be technically brilliant in my 
book.

But to what end?

There are ways to waste time and then there are WAYS to waste time...! ;)

The only people you might impress with something like that would be your D & 
D buddy whose got skin like a mole and never leaves his basement and his PC 
except to DM your newest AD & D session or chair the local Warhammer club's 
meeting.

Most other people would probably just go "dude WTF!"
-- 
Stefan Viljoen

Post a reply to this message

Stefan Viljoen wrote:

> Granted, doing something like that would be technically brilliant in my 
> book.
> 
> But to what end?
> 
> There are ways to waste time and then there are WAYS to waste time...! ;)
> 
> The only people you might impress with something like that would be your D & 
> D buddy whose got skin like a mole and never leaves his basement and his PC 
> except to DM your newest AD & D session or chair the local Warhammer club's 
> meeting.
> 
> Most other people would probably just go "dude WTF!"

...I write computer programs in a non-strict purely-functional 
programming language with extended Miller-Hindley type inference, 
monadic effects and nested data parallelism.

I win?

Post a reply to this message

> Most other people would probably just go "dude WTF!"

Not if you got to play "never gonna give you up", made a video of it and 
uploaded it to youtube :-)

Post a reply to this message

>> Most other people would probably just go "dude WTF!"
> 
> Not if you got to play "never gonna give you up", made a video of it and 
> uploaded it to youtube :-)

Hahahaha!

Somebody *please* do this. :-D

Post a reply to this message

Invisible wrote:

> Stefan Viljoen wrote:
> 
>> Granted, doing something like that would be technically brilliant in my
>> book.
>> 
>> But to what end?
>> 
>> There are ways to waste time and then there are WAYS to waste time...! ;)
>> 
>> The only people you might impress with something like that would be your
>> D & D buddy whose got skin like a mole and never leaves his basement and
>> his PC except to DM your newest AD & D session or chair the local
>> Warhammer club's meeting.
>> 
>> Most other people would probably just go "dude WTF!"
> 
> ...I write computer programs in a non-strict purely-functional
> programming language with extended Miller-Hindley type inference,
> monadic effects and nested data parallelism.
> 
> I win?

You WIN!

That was a seriously impressive list of attributes.

Dude! WTF!
-- 
Stefan Viljoen

Post a reply to this message

scott wrote:

>> Most other people would probably just go "dude WTF!"
> 
> Not if you got to play "never gonna give you up", made a video of it and
> uploaded it to youtube :-)

Too true!
-- 
Stefan Viljoen

Post a reply to this message

>>> There are ways to waste time and then there are WAYS to waste time...! ;)
>>>
>>> The only people you might impress with something like that would be your
>>> D & D buddy whose got skin like a mole and never leaves his basement and
>>> his PC except to DM your newest AD & D session or chair the local
>>> Warhammer club's meeting.
>>>
>>> Most other people would probably just go "dude WTF!"
>> ...I write computer programs in a non-strict purely-functional
>> programming language with extended Miller-Hindley type inference,
>> monadic effects and nested data parallelism.
>>
>> I win?
> 
> You WIN!
> 
> That was a seriously impressive list of attributes.
> 
> Dude! WTF!

A monad is just a monoid in the category of endofunctors. What's the 
problem?

(Even more impressive is the fact that I'M NOT MAKING THIS STUFF UP!!)

Post a reply to this message

Invisible wrote:

> A monad is just a monoid in the category of endofunctors. What's the
> problem?

"endofunctor" sounds like something a doctor would use on someone's nether 
regions.

Or a form of insult "I'll endofunctor your monad, BITCH!" :) :)
 
> (Even more impressive is the fact that I'M NOT MAKING THIS STUFF UP!!)

Wait lemme guess... haskell?
-- 
Stefan Viljoen

Post a reply to this message

>> A monad is just a monoid in the category of endofunctors. What's the
>> problem?
> 
> "endofunctor" sounds like something a doctor would use on someone's nether 
> regions.
> 
> Or a form of insult "I'll endofunctor your monad, BITCH!" :) :)

(See attachment.)

>> (Even more impressive is the fact that I'M NOT MAKING THIS STUFF UP!!)
> 
> Wait lemme guess... haskell?

Well DUH. ;-)



In case anybody doubts my powers...

- Non-strict: There is some arcane technical distinction between 
"non-strict" and "lazy", but essentially it refers to the property of 
Haskell whereby code is not executed until/unless its result is actually 
"needed" for something.

- Purely-functional: Haskell is a "functional" programming language 
(i.e., a language that uses "functions"). The term *purely* functional 
indicates that it's not a hybrid-paradigm language (like, say, Lisp, 
Erlang, C++...)

- Extended Milner-Hindley type inference: The Haskell compiler can 
automatically work out what type things have without you having to 
manually tell it. The algorithm was invented by Mr Milner and Mr 
Hindley, but Haskell's type system is more complex / powerful, and hence 
requires a somewhat more complicated inference algorithm.

http://tinyurl.com/yby3zdt

- Monadic effects: Haskell uses "monads" to control special effects such 
as I/O, concurrency, transactions, nondeterminism, etc.

- Nested Data Parallelism: This is really a red herring. It's a Haskell 
library designed to accelerate the kind of things that GPUs are good at, 
but in a high-level, user-friendly way. Currently it's hopelessly 
unfinished.

Oh, and a monad really *is* a monoid on the category of endofunctors:

http://en.wikipedia.org/wiki/Monad_(category_theory)

Personally, I have no frickin' idea what the hell a category is or how a 
functor is different from an ordinary function. But what I do know is 
that an endofunctor takes values from one category and returns values in 
the same category (rather than some different category). And a monoid is 
a set of items that can be "added together" and possesses an identity 
element.

Why this is useful for computer programming is an entire *other* 
question alltogether...

Post a reply to this message

Attachments:
Download 'monad.jpg' (22 KB)

Preview of image 'monad.jpg'

Invisible wrote:

...

Ok, now I just feel dumb.

Good LOLCat btw!

-- 
Stefan Viljoen

Post a reply to this message

> ...
> 
> Ok, now I just feel dumb.
> 
> Good LOLCat btw!

It's all good assorted craziness. ;-)

Post a reply to this message

Attachments:
Download 'dumb.jpg' (120 KB)

Preview of image 'dumb.jpg'