Re: [boost] [review] pqs

From: Janek Kozicki (janek_listy_at_[hidden])
Date: 2006-06-07 15:55:10

Beth Jacobson said:     (by the date of Wed, 07 Jun 2006 15:13:05 -0400)

> I find m_per_s much more readable than m_div_s, but as a native English 
> speaker, both 'per' and 'div' make sense to me. Before stating 
> categorically that 'per' is preferable, I'd like like to hear from 
> non-native speakers. They might be comfortable with 'div' but completely 
> confused by 'per'.

Even in my native language, polish, it is possible to use both versions
"div" and "per" (in polish it's "metr przez sekunde" ("div") and "metr
na sekunde" ("per") ). The "div" version sounds kind of more
mathematical (in polish), while the "per" version is more widely used.

As non-native speaker I'd prefer "per". BUT we must understand
implications of this: more complicated units are weird to express using
"per", so this notation makes sense only to apply to the simple division
with single numerator component and single denominator.

OTOH having typedefs with "per" only for few selected variants makes
them _special_ and you have to list them in the docs, or somewhere. Much
hassle, small gain.

Maybe it's better to do one of following:

- use only "div"

or

- use "div" and "per" fully interchangeably. Make typedefs for
everything. Then in manual write: "Internal notation uses 'div' as a
divisor word, but typedefs are additionally defined for all of them with
'per' as a divisor word, so the user can choose whichever one is
preferred". The hassle here is just one extra sentence in the manual.

Personally I'd prefer the second option.

----------------------------------------------------- 
> kg.m2_div_s2
> 
> it would be much clearer.

I've been wondering why not use * like this:

kg*m^2*s^-2

or this:

kg*m^2/s^2

Are * and / restricted, being ,,special'' characters?
 

-----------------------------------------------------
> "Basic Useage", (shouldn't that be "Usage"?)

I was wondering that maybe it's some variant of english... maybe
canadian english? I don't know. But I'm sure that the word 'useage' is
for me weird - and maybe it'd be better to use more popular variants of
english, and write 'usage' and 'using'. (I'm sorry about being a bit offtopic here)

> why not just use SI and non-SI, in place of coherent, and incoherent?

good point.

> I'd much rather see something like the 'Description' 
> section of Fred Bertsch's review announcement post:
> 
> "PQS (Physical Quantities System) is designed to replace the use of
> floating point types for modelling physical quantities in C++
> programs. Advantages include automated dimensional analysis checking,
> automatic unit conversions, self documentation of code and uniform
> mechanisms for dealing with physical quantities overall, allowing
> better interoperability, accuracy and repeatability among engineering,
> physics and trade applications."
> 
>  From just that one paragraph I've already got a pretty good idea about 
> whether pqs is going to be useful to me.

I second that.

 
> A tutorial with a simplified real-world example of a pqs-enabled program 
> would also be very helpful. The "Getting started" page contains a lot of 
> code snippets but most of them illustrate only declarations and simple 
> operations. I realize that encompasses most of what pqs does, but it 
> would still be nice to see them in different contexts, e.g. std 
> containers of physical quantities, functions with physical quantities as 
> parameters, etc. I'd particularly like to see an example of pqs 
> interoperating with boost.date_time. They'll be a natural combination 
> for many applications, so it would be nice to see code that converts 
> between them.

good idea. Also few short examples that you could just copy'n'paste from
the manual to the editor and compile them, whould be nice. Even though
there are many files in the examples directory - people first look into
docs, later they browse directory structure to find examples (and its
more tiresome - copy'n'paste from the documentation is plain easier.

-- 
Janek Kozicki                                                         |