Re: Parsing of numeric values

Daniel Dekany wrote:
> 
> Tuesday, September 15, 2009, 11:45:54 PM, wkbutler wrote:
> 
>> Daniel Dekany wrote:
>>> 
>>> Tuesday, September 15, 2009, 3:46:17 PM, wkbutler wrote:
>>> I don't know... it's not enough concrete for me to form an opinion.
>>> The part that is a bit suspicious for me, that if the numerical output
>>> generated by the 1st order macros meant to be treated as numbers by
>>> the 2nd order macros, then why are they in human-audience format? I
>>> mean, FM can output in computer-audience numerical format as well.
>>> 
>>
>> Good question - consider the case of subtotals and grand totals. Grand
>> totals operate on subtotals, subtotals operate on 'raw' data. Both are
>> products for the user.  You allude to another possible solution though,
>> which is to store both formats; I would rather avoid that, but it may be
>> the
>> easiest approach.
> 
> In principle you don't generate the grand totals from the formatted
> output of the subtotals. You just generate them from the
> presentation-independent data that represents the subtotals.
> Extracting data from formatted output is quite difficult in general
> (since that output is optimized for human brains, not for computer
> programs), and thus avoided whenever possible.
> 
> Of course, building presentation-independent data structures is not
> something FM is often used for, since it generates text, not Java
> objects and like. But, there are some exceptions, when FM generates
> XML or JSON, which are not about presentation but describing
> structured "data", and still are text.
> 

Yep I'd agree completely, ordinarily. But the way this system is designed,
the raw data is actually unknown to the system. The user is in control of
the raw data content and all macros. Hence only the user knows which data
points are numeric (string representation of numerics of course), and how he
wants to use the data.  

I guess that means the user should be responsible for setting up two
versions of each numeric macro. I may fall back to that solution, it
probably is the safest for the reasons you mention. But for maintenance
concerns on near-duplicate macros, I press on...

The raw data is presentation-independent. So solution #1 would be be to make
the 2nd order macros reference only the raw data. But then they wouldn't be
2nd order macros; and would lead to other technical, usability and
maintenance issues.

Another option is for the processor to attempt to identify numeric results
of 1st order macros, and store a raw format for 2nd order macros to
reference. I don't like this solution much for a couple reasons.

That more or less leaves the solution that I'm going for at the moment -
putting a tool in the hands of the user. Any 2nd order mathematical macro
would need to scrub numeric args (which are macro results) before using
them.  

And here I'm glad for FM's ability to inject code references.  At the moment
anyway, the server will only support two i18n formats, so the parser does
not have to cover all possible cases.



-- 
View this message in context: http://www.nabble.com/Parsing-of-numeric-values-tp25446898p25473421.html
Sent from the freemarker-user mailing list archive at Nabble.com.


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf