[boost] Re: runtime unit-modifiablephysical-quantitiesusingpqs1-00-01

From: Dan W. (danw_at_[hidden])
Date: 2004-01-05 18:09:42

Andy Little wrote:
> "Dan W." <danw_at_[hidden]> wrote in message
> news:btc7ff$min$1_at_sea.gmane.org...
>>>Yep... or come out of the physical_quantities system for things it cant
>>>handle and use a good ole double,
>>>Works a charm  :-)
>>No it doesn't!  :-)
> A value_type will always fulfill the role, but it is weakly typed.
> I assume you are alluding to my use of ints for the
> abstract-physical-quantity part of the physical-quantities type.
> e.g
> p_quantity<abstract_pq<1,0,0,0,0,0,0>,0,0> length;

I'd say, ints is fine, but you need numerator and denominator, I 
suppose. But if someone tomorrow needs a non-fractional power you're 
toast. How about making the type of the power a template parameter? Is 
that doable?
And the value type has to absolutely be a template type. Someone will 
want a 7-bit type to make prinatble ascii characters a dimension... you 
never know.
And I'd forget the number 7 if I were you, just do the abstraction for 
one dimension, completely abstract: Abstract unit, template power type, 
template value type, and maybe even a template scaler constant, so that 
if I want to use long long for distance, meter as the basic unit, but I 
want 1 meter to be represented as 2^16 I can do so.

> I find that simple and expressive... but limiting.
> Maybe  named powers-of-dimension would be a better bet. I could start using
> enums and then maybe use types.
> Of course I shot that idea down pretty quickly saying it was a bit ugly.
> maybe I was wrong.

That wouldn't work.

> The favoured boost solution is 'use a rational type'.  Maybe .. but rational
> fractions are a limited set.

Template type for now. Don't even bother with such details.

> So some time down the road someone will want to use pi().
> Use a fixed type... maybe too... but accuracy is limited.

Exactly!

> Use a floating type... but bang goes the compile time aspect.
> After this there will be further math requirements.

A float type loses accuracy on accumulation, has 3 or four states that 
mean zero depending on perspective... If you're prepared to deal with 
all that in representing fractionals with it, fine. I would just 
procrastinate the descision, or even defer it to the user.

> The abstract type is used in type comparisons so if compile time math is
> limited to integer.
> 
> Of course all this sounds great in theory, trivial on the page.. 'it only
> needs implementing'.

I know, I wish I could give you a hand, but I'm not at 1% the caliber of 
yourself or most programmers around here. I've yet to come to grips with 
"traits", never mind meta-programming... But you've done all this 7 
times already!  :)  Could have the one dimension done by tomorrow, I'm sure.

> I will bear all that in mind (A working demo of other peoples ideas is a lot
> more useful to me than just suggestions)...and follow events... meanwhile my
> solution, workaround call it what you will is as previously.

As someone just mentioned in another post, you may not even need 
"length", only "meter"; --i.e.: Length is an abstraction that might 
serve no purpose. Abstracting further, you only need an (abstract) 
"unit_t", "power_t", "val_t", and "const_val_t_scaling_factor" or 
whatever, template params.

> I have been presented with various objection on this thread. I assume that
> when the tail goes quiet the problem has been solved.
> Either that or it was just a passing jab by someone who is not very
> interested

5 years ago or so I downloaded SI units library, and worked on trying to 
understand it for maybe a week straigh, and finally gave up.  I had the 
plan to try and do it myself but didn't know where to start.  And my 
vision was same as your 7-dim implementation; --i.e.: I would have made 
the same mistake, except, unlike you, I wouldn't have finished it...

> My current solution for my pqs type is:  Where the physical-quantities type
> cant fulfill what you want fall back on old style inbuilts.
> The resulting code may be full of holes but may give a flavour of coding
> with strongly typed physical-quantities.

Ahhh! Yup, this is a conondrum; because I don't want to mix apples and 
bananas, and if I do I can cast them to fruits; but how does one prevent 
zero-power-units types from inter-converting? How about treating them 
specially? For all non-zero power dimension types, conversions could be 
template-instantiated as required; but zero power ones are typed as per 
the name the user gives them, and if two names don't match you need a 
cast or explicit conversion. Could this work? This could prevent taking 
the arc-cosine of Federal tax by accident.

> Alternatively if you have better ideas on physical-quantities... build your
> own working code, which I can run and use and I will be happy to evaluate
> your version.

I don't have what it takes, man. Honestly, I managed to program a 3D 
engine of sorts in OpenGL from scratch, but I just look at 
metaprogramming and I choke. I'm a low level guy; if you ever need MMX 
assembly code acceleration, count on me.

> As I have said before... show me the better implementation with all the
> problems solved and I shall delete my type from the collective
> consciousness.
> After all the talk of a type that will fulfill every need for every user ...
> it had better be PDG.
> Meanwhile I am waiting.

No idea what PDG means.

> Try out my examples as they are ... (gcc 3.2, VC7.1 ... I hope will work on
> close conforming compilers.... feedback on compile run would be very
> helpful).
> http://www.servocomm.freeserve.co.uk/Cpp/pqs-1-00-01/download.html

I'm also using the Digital Mars compiler, for which there's no boost 
support yet. I tried to compile an example with Matthias sample and it 
blew on my face. Haven't tried your library, but I found the syntax a 
bit daunting, not that I found Matthias' any less daunting.  But I 
didn't really spend even an hour on either.  I just figured, if it's not 
plainly obvious how to do it, few people will use it anyways; and like I 
said, what I *needed* it for, in my present project, was to count bytes 
with a short, and things like that;  which I would rather use a typed 
type, but one that doesn't impose on me that I use double, etc.

> Whether you dont like the syntax, the lack of boostisms, the implicit
> conversions or anything else , They will give you some basic flavour of
> coding with physical-quantities.You may decide in practise that there is no
> advantage over inbuilts. That in itself would be useful feedback... then we
> could all pack up and go home

Great advantage over inbuits;  but they must not restrict. If I want a 
"color intensity" whose unit is "full" meaning 255, and using unsigned 
char storage, so that I can put four of them in a struct and call it 
RGBA, I should be able to do it; and not have to pay penalties in terms 
of space or alignment or initialization or assignment. Then we're 
talking.  If you can meet such requirement, I will NEVER use a basic 
type again.