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 |