> > > Convert a binary value to Roman, using ASCII characters (or
> > > the native character set if applicable) into a string
> > > with a termination character (if ASCII, use the NUL (0)
> > > character).
> > Is a length terminated record valid ?
> Hmmmm ... I might be inclinded to say yes, but is there any reason it
> can't be NUL terminated (or terminated with the appropriate termination
> character for the character set)?
Just since it is the usual way within the OS I'm trying to code.
NUL is like any other caracter valid within a string. Also, it
gieve me an disadvantage - instead of just adding '\0' I have
to calculate the string.
> > > The valid Roman characters used are IVXLCDM
> > Is Space valid ? Romans did include them at will.
> I did not know that, but for this program no, spaces are not allowed.
Ok.
> > > > There are a few details which have been left out of the specification for
> > > > this task.
> > > > Does it require input validation?
> > > I think I specified that. The valid range of Roman numerals is 1 through
> > > 3,999 inclusive. The routine does have to check that and construct a
> > > special string ( "*" ) if the input is not in that range.
> > > > Is the binary input pure binary, or is it BCD?
> > > Okay, that might be a valid point, but it's pure binary, not BCD.
> > Fine, you stated max input 3999, but to be checked, and you
> > stated binary, but in what format ? Half Word (16 Bit),
> > Word (32) or Double Word (64) ?
> Uh, I was unaware that halfwords had a specific size (on the DEC Alpha, a
> half word would be 32 bits in size).
Like Words, they are just machine dependant ... in a given 32 Bit CPU
a halfword is just 16 - so whats the input ? (in fact, I'll assume 32 Bit)
> > To be transfered at a given location, or via a pointer,
> > or via register (attention, might again be processor specific).
> Appropriate to the CPU or the situation. Obviously, a 6502 can't pass it
> in a single register, but there are other options. That's why I didn't
> specify how to pass the data in.
:))) And why specifying a '\0' byte ?
> > > I liked Sam's suggestion of ``printing to memory'' as a way to avoid the
> > > complications of I/O in this, and if I didn't make this clear that the
> > > conversion was to be stored in memory, I'm sorry.
>
> > Output, to a given location (pointer) or static buffer ?
> > Check for buffer length or asumption of an buffer, always big
> > enough ? (if you check the binary number you also have to check
> > the buffer (if given).)
> Again, it's up to the programmer. But be prepared to justify your answers
> 8-)
:))
> -spc (Welcome to the world of programming 8-)
All simple, all the same, isn't it ?
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.
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 ?
Gruss
H.
Oh, BTW: this contest is exacty into the direction where we didn't
want to go - we are comparing algorythms and not CPUs - for a more
CPU dependant contest we need to fix the algo to use, so the difference
will reflect the differences in processor design and not into algo
design (of course there's more sex appeal in the my-algo-is-bether-
than-yours, than in the my-(what-ever-algo)-implementation-is-better).
So I still go for the idea of implementing one algo as good as possible
for the different CPUs - more on Friday (I'm not full time available
until then).
--
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
Received on Tue Apr 20 1999 - 17:54:49 BST