Re: [boost] [PQS] simplifying the type signature?

From: Janek Kozicki (janek_listy_at_[hidden])
Date: 2006-06-14 17:41:33

Andy Little said:     (by the date of Wed, 14 Jun 2006 21:43:51 +0100)

> >> I think the ability to distinguish quantity types is important for other
> >> purposes.

> I think you chopped the quote :-)

more than once ;)

>  I think I said that some reviewers had said that the t1_quantity/fixed_quantity 
> was over complicated.
> The context I said it was about adding yet more functionality, this time to 
> distinguish different unit systems.
> In case of distinguishing torque and energy, reciprocal time and frequency etc, 
> I think its useful functionality.
> It would be useful to add the other too FWIW, but practically a huge job IMO, 
> which I dont see as realistic for me to take on. That needs someone with more 
> experience in physics AFAIKS.

If it's a huge job, then why not make things simpler and discard this?
Especially when it turns out that the real purpose is serialization
only? And the side purpose is to boast about extra functionality. I have
no bad intentions, it's just how I perceive this.

Do not make things more complicated than they are.
http://en.wikipedia.org/wiki/Ockhams_razor

Do something smaller and simpler first, but complete.

> > Can you give examples of where ability to distiguish is useful? With
> > exception of serialization examples because it is listed below (printing
> > unit correctly).
> 
> The only example is serialisation or standard output, but I think that is 
> enough.

ditto.

<snip>
> > I have difficulties understanding this paragraph. You say that PQS
> > should be able to print "N*m" or print "J" depending on the context,
> > because it is a very helpfull feedback. Right?

> Yes. Its for completeness, but the serialisation is modular and can easily be 
> left out . The kind of place it might be useful is for students homework, short 
> demos (<libs/pqs/examples>) exporting to a spreadsheet etc. (I am guessing here. 
> It may not be suitable at all for students homework. I am not a lecturer),

So in fact decision whether to print torque or energy can be an option
for serializing function. Especially when we start talking about
exporting data to spreasheets - a fairly sophisticated task.
Serialization should not affect the underlying design. Currently I have
impression that serialization has forced you to add
abstarct_quantity_id to underlying design.

But I'm really interested in opinions from other people - do we need the
ability to distinguish torque/energy, or not?

It's just my opinion. We are looking for the best design of units
library (pqs), and everyone's opinion matters (not just mine).
(reminder: it's Andy who did tons of work)

Matthias Troyer in his review raised a concern about clashing id numbers
between different custom quantities:
<quote>
> The immediate problem with the current design that I can see is that  
> you recommend programmers to use the first available id for their new  
> unit. If now two programmers define a new unit, these will have the  
> same abstract id, and cannot be used together without changing the  
> code. Using the scale factor as part of the abstract id would make  
> such clashes much less likely.
</quote>

> but for more serious use as in yade, if the distinction is not important
> ( as is the case for dimensional analysis checking) then the type could
> referred to strictly as an anonymous-quantity which could then be
> representing torque or energy(which are so-called named-quantities
> in PQS definitions section) but without the distinction being
> important for the current use.

Yes, anonymous quantity will work in yade. I'm just wondering if the
extra burden of abstract_quantity_id is worth the gains. Especially if
making this extra functionality is "huge job" as you called it.

PS: it's getting lenghty, and it's all about one design decision :)

-- 
Janek Kozicki                                                         |