Question about parser implementation details

I'd appreciate any hints on how to tackle this serious concern.
You should launch a new thread to tackle them. You could then buy
foreign slaves to schedule them on their cores.

Btw, in the spirit of x for hex and b for binary I thought about using
this syntax:

<?php
$a = 0spqrMMXII; //set $a to 2012
?>

unless anyone has any better suggestions?
Romans didn't have 0 in their keyboards. You should use a different
approach which didn't need such character.

Also, date extension needs to be extended to support ab urbe condita
dates. I think that's a more pressing concern.

Hey there,
due to the widespread acceptance of binary number format (0b1010101) and
the growing demand for backwards compatibility I've started to work on
support for Roman Numerals (I, II, III, ...)

As you might know, this format cannot be strictly parsed from left to
right or right to left, as several number values need a look-ahead
before being able to compute them (like IV), so my naive first
implementation splits the string into tokens (like in 1990 = MCMXC =>
M,CM,XC => 1000,900,90) then simplifying those 3 on their own, then
adding the results, but I'm not sure this could kill performance if
calculated inside zend_language_scanner.l.
Thanks for the work on it. I really appreciated and would love
to see roman numberes finally get implemented.

I think a fair asusmption is that there is a certain ordering.
First add numbers unless you encouter a higher or lower number:

(1) in case current number == previous number, add it to your temp buffer
(2) in case current number < previous number, add it to your temp buffer
(3) in case current number > previous number, substract it from temp buffer

Obviously you need to check if hte number is valid too: IIVM is obviously wrong
But i think this is a good start.

hi,

due to the widespread acceptance of binary number format (0b1010101) and
the growing demand for backwards compatibility I've started to work on
support for Roman Numerals (I, II, III, ...)

I am really really not sure we want that as part of the php scripts
like hex or binary. (Read: I do not want to have that :).

As you might know, this format cannot be strictly parsed from left to
right or right to left, as several number values need a look-ahead
before being able to compute them (like IV), so my naive first
implementation splits the string into tokens (like in 1990 = MCMXC =>
M,CM,XC => 1000,900,90) then simplifying those 3 on their own, then
adding the results, but I'm not sure this could kill performance if
calculated inside zend_language_scanner.l.

I'd appreciate any hints on how to tackle this serious concern.

Btw, it may be possible to parse roman number using ICU, using the
number parsing API. It is also possible to generate Roman numbers
using ICU as well, using numberFormat and some extra rules. The docs
have some examples.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

I'd appreciate any hints on how to tackle this serious concern.

If this actually wasn't an April Fool's joke...

Never ignore the user contributed notes after doing a search like:

http://php.net/roman

http://us3.php.net/manual/en/function.base-convert.php#105414

Those notes may be 90% [bleep], but there are always hidden gems in
some of them :-)

Actually, even if it WAS an April Fool's joke, my second sentence
still has merit.

Sorry to reply so late, but nobody who took it seriously pointed this
one out...

PS No idea what spqr is, but 0r would probably be more appropriate.

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE