RE: Unit Prefixes in CONVERT

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I think you're right that this means what can be said in the formula and
what evaluators do with it.  I took these statements to mean that if an
evaluator supports conversion on distances,

such as CONVERT(N;"ly";"m"),

Then it shall also support CONVERT(n;"nly";"km").

That is, the prefixes are on the unit symbols.

We should not have anything about cell scaling in OpenFormula.  For one
thing, the CONVERT function specifies what the understood units of the value
are to be in terms of with the "from" parameter. For another, we must not be
in a situation where we confuse how a cell's value is *presented* in
particular units (as part of formatting for presentation of the cell and
acceptance values for the cell) and how a cell's value is *retained* as a
dimensionless Number value, at least when that cell is reference in an
OpenFormula expression.  

If cells are not retained as dimensionless values we have a real problem
with what formula =1.0 for the cell delivers to a subsequent
CONVERT(n;from;to).  Perhaps, in that case, we would need something like
CONVERT(N;;"km") which works if N is a dimensioned distance value and fails
if it isn't?  

I don't think we want to go down that road at all.  For OFFICE-500 I believe
we have deferred all treatment and assumption of unit-system tracking as a
characteristic of values (and hence data types).

This ambiguity calls for a JIRA issue.  It is OFFICE-2629

This is also an interesting case for a codefest exercise.

 - Dennis

Of course, there is limited capability of explicit unit tracking.  For
example, in

   CONVERT(N;[A17];"km") where it happens that the value of [A17] is the
text given by formula ="nly".
(My apologies if I should be using ' instead of " here.)

-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net] 
Sent: Friday, April 09, 2010 07:37
To: office-formula@lists.oasis-open.org
Subject: Re: Fwd: Re: [office-formula] Straw poll - slug (and lightyear)

[ ... ]

BTW, the "*" made me look for the explanation and I find:



	Unit symbols in cells marked with * shall support decimal prefixes,
and unit symbols in cells marked with † shall support binary prefixes;
evaluators should not support prefixes for other unit symbols. 


I am not going to post a JIRA issue but clearly unit symbols don't support
any sort of prefixes. Evaluators might.

Re-writing to say:

Evaluators shall support decimal prefixes for unit symbols marked with * and
binary prefixes for unit symbols marked with †. Evaluators should not
support prefixes for other unit symbols.

I am not happy with the final sentence but will try to think of a better way
to say that. 

Hope you are having a great day!

Patrick





	WARNING: Technical nitpick ahead:
	The distance light travels in a year, in a vacuum, *is* exact; the
meter is actually defined
	in terms of speed of light in a vacuum. And while an Earth year
isn't exactly 365.25 days, for purposes of a
	light-year, that's the exact value of the "year". It's not
well-documented, but astronomers
	use this "standard year approximation" of 365.25 days when stating
light-years.
	And since a day is exactly 24*60*60 seconds, this has an exact
value.
	I actually had to track that down, and I'm pretty sure I posted my
citations
	(though I can't remember where they are right now).  If anyone knows
differently,
	please let us know now.
	
	--- David A. Wheeler
	
	
---------------------------------------------------------------------
	To unsubscribe from this mail list, you must leave the OASIS TC that
	generates this mail.  Follow this link to all your TCs in OASIS at:
	
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
	
	
	  


-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)