On 28-mar-10, at 22:46, Don wrote:
so wrote:
Hello Don, finally!
It is hard to explain yourself when you don't know the people you
talk have numeric coding background.
Since we know you have done much numeric and generic coding, it
will be enough for me if you understand what i mean/ask/want,
and say what i am talking is ridiculous, or think that i am
trolling, just say so and i shut up! :)
You're definitely not trolling! I'm not 100% sure of which issue
you're referring too, but I'm aware of a few, for example:
ok if you have a real message, I am sorry to have been so harsh, I was
a bit hard due to other trolls going on...
sorry if I did not really catch your message, but next time try to
actually bring an actual example of what the compiler does wrong, it
will help understand your problem.
(1) Converting a floating point literal into a double literal is
usually not lossless.
0.5f, 0.5, and 0.5L are all exactly the same number, since they are
exactly representable.
But 0.1 is not the same as 0.1L.
So it's a bit odd that this silent lossless conversion is taking
place.
It does have a very strong precedent from C, however.
well the correct thing to do (I thought that was what was done
possibly CTFE excluded) is to always do constant folding with the
maximum precision available (maybe even more than real), and only at
the end convert to the type.
so that one could write
cast(real)0.555_555_555_555_555_555
and that is equivalent to
0.555_555_555_555_555_555L
and thus basically cast(T)xxx is the generic way to write a float
literal of type T.
If this is not like that, then it should indeed be changed...
I still argue that using integers if possible often a better choice.
The language that that solved the problem of floating points, integers
& co most cleanly is probably aldor (http://www.aldor.org/) but it is
a dead language.
(2) The interaction between implicit casting and template parameters
is quite poor. Eg, the fact that '0' is an int, not a floating point
type, means that something simple like:
add(T)(T x) if (isFloatingPoint!(T))
doesn't work properly. It is not the same as:
add(real x)
since it won't allow add(0).
Which is pretty annoying. Why can't 0 just mean zero???
and maybe 1 the identity?
the aldor solution is probably a bit too challenging but allowed both
things...
Integer were arbitrary length integrals converted to the final type
with implict cast (fromInteger), floats were converted to Rationals
and then to the correct type with implicit cast (fromRational).
0 and 1 could be implicitly casted separately to allow things like
vectors and matrixes to use them without defining a full fromInteger
cast.
I find that for integers D normally does the correct thing, and for
floats I thought it was closer that what it might be (i.e. arbitrary
precision calculations and cast to the final type).
about the isFloatingPoint one can still one can easily write
add(T)(T x) if(is(T:real)) or something like that, and probably solve
the problem.
what would be nice is to have templates to find types with a given
precision and so like one does in fortran.
also i use templates to get the complex type or real type of a given
type and so on. These things should probably be in the library...
so with some extra templates probably these things could be solved.
