Boost logo

Boost :

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$
>>>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.


> 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).

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at