20 Apr
1999
20 Apr
'99
5:13 p.m.
And again, more questions:
If I'm right at Megans description, she just include the next lower
digit when it comes to these subtraction rules, and your Algo seams
to be weak at the same point. Let me give an example:
49 would be normaly coded as IL (always remember, it
was kind of a
system to reduce writing as much as possible - there are even examples
where the number 248 is written CIIL) while Megan seams to code it as
XXXXIX - basicly wrong - or did I miss something ? I'm not realy
what one can call a DEC-Geek.
My code would produce XLIX, not XXXXIX...
I guess I'm unclear as to whether any numeral can be used to reduce
the value of a higher, subsequent numeral.
Using your explanation, 1999 would be MIM, instead of the more
standard (as I have seen it) MCMXCIX. Also, what's to stop
someone from writing it in a form employing the vinculum:
__
III
So do we only have to supporte the one-less rule, or
the rule
of one subtraction numeral - or the full possibility with the
goal to reduce writing to a max ?
So long as someone can clearly explain the rules to what can
be subtracted from what, I'll implement it... (kind of like
requiring a spec). Without it, I can only go on what I can
find documented in the encyclopedia...
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
21 Apr
21 Apr
6:48 a.m.
>And again, more questions:
>If I'm right at Megans description, she just include the next lower
>digit when it comes to these subtraction rules, and your Algo seams
>to be weak at the same point. Let me give an example:
>49 would be normaly coded as IL (always remember,
it was kind of a
>system to reduce writing as much as possible - there are even examples
>where the number 248 is written CIIL) while Megan seams to code it as
>XXXXIX - basicly wrong - or did I miss something ? I'm not realy
>what one can call a DEC-Geek.
My code would produce XLIX, not XXXXIX...
Sorry, you're right I did only take one loop ...
I guess I'm unclear as to whether any numeral can
be used to reduce
the value of a higher, subsequent numeral.
Using your explanation, 1999 would be MIM, instead of
the more
standard (as I have seen it) MCMXCIX.
Back, when the system was developed (and almost until recent
days) Writing was a time consuming thing - and cost a lot of
resources (space on coins and seals, paper, ink, etc), so
the whole system was designed to save resources - call it a
kind of compression algorythm - instead of writing 5 strokes,
just write two, different placed and further, 4 strokes could
be replaced by 3 when using the subtraction rule.
Today we are most exopsed to roman numerals from movies (and
newer productions) where a) space is no longer a consiferation,
b) Numbers with _more_ Numerals look more impressive and
c) correct writing isn't exactly the main goal.
Also, what's to stop
someone from writing it in a form employing the vinculum:
__
III
For classic Roman Numerals, noone, but within this contest the
Numerals have been restricted :)
(BTW: this x1000 rule is the orign why we put a '.' (or ',' in
the US) between each 3 digits)
>So do we only have to supporte the one-less rule,
or the rule
>of one subtraction numeral - or the full possibility with the
>goal to reduce writing to a max ?
So long as someone can clearly explain the rules to
what can
be subtracted from what, I'll implement it... (kind of like
requiring a spec). Without it, I can only go on what I can
find documented in the encyclopedia...
THats exactly my point - tofulfill the contest we needan exact
description of the result - it's the usual thing - the customer
gives an unclear description, besed on a lot of 'you-know' termns
and when we do the software he is shocked by the result :)
Gruss
H.
--
Stimm gegen SPAM: http://www.politik-digital.de/spam/de/
Vote against SPAM: http://www.politik-digital.de/spam/en/
Votez contre le SPAM: http://www.politik-digital.de/spam/fr/
Ich denke, also bin ich, also gut
HRK
9:03 a.m.
> >And again, more questions:
> >If I'm right at Megans description, she just include the next lower
> >digit when it comes to these subtraction rules, and your Algo seams
> >to be weak at the same point. Let me give an example:
> >49 would be normaly coded as IL (always remember, it was kind of a
> >system to reduce writing as much as possible - there are even examples
> >where the number 248 is written CIIL) while Megan seams to code it as
> >XXXXIX - basicly wrong - or did I miss something ? I'm not realy
> >what one can call a DEC-Geek.
> I guess I'm unclear as to whether any numeral can be used to reduce
> the value of a higher, subsequent numeral.
> Using your explanation, 1999 would be MIM,
instead of the more
> standard (as I have seen it) MCMXCIX.
[...compression ideas of Roman Numerals...]
While out for lunch, I've seen a light ... erh ... I've seen
where Megan took the impression that the Roman system is kind
of a BCD like system (or better RCD :) - each decimal digit is
encoded using Roman Numerals (with an inclusion of the digit
position) - but that was never the system - position dependant
coding (like our arabic/indic system) was alien to the Numeral
system. Maybe some decimal adjusted (DAA) persons where building
the examples she is refering.
Gruss
H.
--
Stimm gegen SPAM: http://www.politik-digital.de/spam/de/
Vote against SPAM: http://www.politik-digital.de/spam/en/
Votez contre le SPAM: http://www.politik-digital.de/spam/fr/
Ich denke, also bin ich, also gut
HRK
11:30 a.m.
It would seem that we need further clarification of the fine points of the
variant of "Roman Numerals" that we are to work with.
For example, would ANY form of 1999 be acceptable, or is there one form
that is required? MIM, MXMIX, MCMIC, . . .
If there ISN"T a rule limiting the number of occurences of consecutive
digits, then 6 could be expressed as IIIIII, etc. That gives rise to
another flippant entry:
; data segment is composed of 3999 I's followed by a null
MOV DX, 3999 ; DX now points to the null
SUB DX, AX ; for a value X in AX, DX now points to a location
: from which there are X I's and a null.
12:46 p.m.
If there ISN"T a rule limiting the number of
occurences of consecutive
digits, then 6 could be expressed as IIIIII, etc. That gives rise to
another flippant entry:
; data segment is composed of 3999 I's followed by a null
MOV DX, 3999 ; DX now points to the null
SUB DX, AX ; for a value X in AX, DX now points to a location
: from which there are X I's and a null.
You might win the speed contest, assuming there's no upper bound on
memory usage. But you won't win the size contest.
The earlier roman numeral competition I brought up that inspired this mess
was only a memory usage competition, although apparently the motivation of
the current one is speed.
If I were setting the rules, I'd say that you only got 256 consecutive
8-bit bytes for total memory usage (code, tables, output buffer, etc.), and
were not allowed to reference any memory outside this area. For machines
not organized with 8-bit bytes, the equivalent amount of contiguous memory
is permitted (i.e., 2048 bits). For some machines it may be necessary to
relax the rules to allow access to architecturally specified memory areas
such as the PDP-8's auto-index locations. However, those locations would
count against the total memory usage.
But fortunately for me, I'm not running this contest. :-)
9383
days inactive
9384
days old
4 comments
4 participants
participants (4)
-
cisin＠xenosoft.com -
eric＠brouhaha.com -
Hans.Franke＠mch20.sbs.de -
mbg＠world.std.com