[M3devel] AND (…, 16_ff)… Not serious - or so I hope!

[Daniel Alejandro Benavides D.]

Hi all:
Well you have created a chicken and egg problem/opportunity you can create your theory and move forward.
I guess history has shown that big chunks of memory won't make higher speed execution programs, but distributed machines with less memory.
The problem is I could set a theory that explains how computers could actually evolve and so on, based on family of computers, you know like Stack Computers, and it turns out that in reality it doesn't work like that, and by the reality it's not true (also I don't consider the "reality" to be that, I don't think tablets and stuff will be takers of tomorrow as today, it's very very useful, as were Micros in their time but can't come back and do that again, Micros are gone). I don't think or hate devices or people who uses it (perhaps I'm old for that) but this things are mostly used to send messages to set up quickly a web page (an every day task which I still consider for talented people)
Frankly we can say many thing sin theory again but just good people and companies can make a standard way of doing things.
Thanks in advance

--- El mar, 26/6/12, Mika Nystrom <mika at async.caltech.edu> escribió:

De: Mika Nystrom <mika at async.caltech.edu>
Asunto: Re: [M3devel] AND (…, 16_ff)… Not serious - or so I hope!
Para: "Dirk Muysers" <dmuysers at hotmail.com>
CC: m3devel at elegosoft.com
Fecha: martes, 26 de junio, 2012 20:54

Memory is always potentially a problem!!!!

One of the main reasons my group was slow at switching from PM3 to CM3
was because we were processing node names for chip designs as TEXTs.

Chip designs tend to be deeply hierarchical and you wind up printing a
lot of strings such as

a.b.c.d.e.f.g.h

to files.

That's when you run into problems with Text.Cat.

And memory will always be a problem since you are always designing the
next generation of computers with the current generation of computers.

Also even if memory weren't a problem, speed is always a problem, and
speed isn't entirely unrelated to memory.  The Text.Hash I was alluding
to earlier hashes eight characters per iteration on a 64-bit machine,
as long as characters are 8 bits...  If you go to 16 bits it'll take
at least twice as long.  Furthermore if there is more than one way
(bit pattern) to represent a single CHAR it becomes difficult to use
algorithms that take more than one at a time.

    Mika

"Dirk Muysers" writes:
>So let them hate it. Memory is not a problem anymore.
>
>--------------------------------------------------
>From: "Hendrik Boom" <hendrik at topoi.pooq.com>
>Sent: Tuesday, June 26, 2012 8:19 PM
>To: <m3devel at elegosoft.com>
>Subject: Re: [M3devel]AND (…, 16_ff)… Not serious - or so I hope!
>
>> On Tue, Jun 26, 2012 at 12:18:41PM +0200, Dragiša Durić wrote:
>>> This piece of code, from TextClass.m3, disturbs me… a lot.
>>>
>>> If we are to use WIDECHAR, I think we must be a lot more serious than 
>>> this.
>>>
>>> Probably, text pieces are limited to 128 bytes by design, somewhere. 
>>> But - whose idea was to "narrow" by ignoring everything except 8 LSB's? 
>>> By mapping set of 2^20 elements to set of 2^8 elements.
>>>
>>> Probably by someone whose mother tongue is fully writeable with ASCII :).
>>
>> I'm told the Japanese hate UTF-8, because it expands  their characters
>> from two bytes to three.
>>
>> -- hendrik
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120627/0ebb53eb/attachment-0002.html>