If you declare a function taking a float and an unsigned int parameter in 
C#, you can't just call it as
   xyz(0.3, 12)

You have to actually say
   xyz(0.3f, 12u)
because doubles don't silently cast to floats and ints don't silently cast 
to unsigned ints.  Even tho these are literals the compiler can see cast 
without losing precision.  Feh.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> If you declare a function taking a float and an unsigned int parameter in 
> C#, you can't just call it as
>    xyz(0.3, 12)

> You have to actually say
>    xyz(0.3f, 12u)
> because doubles don't silently cast to floats and ints don't silently cast 
> to unsigned ints.  Even tho these are literals the compiler can see cast 
> without losing precision.  Feh.

  12 yes, but are you sure 0.3 can be converted from double to float without
losing precision? (Not that it really matters with literals, though...)

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> If you declare a function taking a float and an unsigned int parameter 
> in C#, you can't just call it as
>   xyz(0.3, 12)
> 
> You have to actually say
>   xyz(0.3f, 12u)
> because doubles don't silently cast to floats and ints don't silently 
> cast to unsigned ints.  Even tho these are literals the compiler can see 
> cast without losing precision.  Feh.

Isn't this the case with Java too?

Now of course, in Haskell, "3" can represent any numeric type. That 
includes complex numbers, for example. So if you write "print 3", the 
compiler moans at you because it's not sure which of the possible 
numeric types you meant. (Should it print out as "3" or "3.0" or "3 :+: 
0" or "3.0 :+: 0.0" or "3/1" or...)

"3.0", on the other hand, has to be one of the fractional types. But 
that's still a fairly long list.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   12 yes, but are you sure 0.3 can be converted from double to float without
> losing precision? (Not that it really matters with literals, though...)

  Answering my own question, the bit pattern for 0.3 is:

0 01111111101 0011001100110011001100110011001100110011001100110011

(see http://en.wikipedia.org/wiki/Double_precision_floating-point_format
for the meaning.)

  This makes be believe that 0.3 is actually not accurately representable
with base-2 floating point numbers, and hence converting from double to
float does lose precision, technically speaking.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Answering my own question, the bit pattern for 0.3 is:
> 
> 0 01111111101 0011001100110011001100110011001100110011001100110011
> 
>   This makes be believe that 0.3 is actually not accurately representable
> with base-2 floating point numbers, and hence converting from double to
> float does lose precision, technically speaking.

test :: Double -> Bool
test x =
   let y = realToFrac x :: Float
   in  x == (realToFrac y)

 > test 0
True

 > test 1
True

 > test 0.3
False

 > test 0.1
False

 > test 0.25
True

1/10 is a recurring binary fraction. This is the source of all the 
trouble. (As you know, 10 = 2 * 5. 1/2 is no problem, 1/5 is.)

Post a reply to this message

Invisible wrote:

> 1/10 is a recurring binary fraction. This is the source of all the 
> trouble. (As you know, 10 = 2 * 5. 1/2 is no problem, 1/5 is.)

http://www.wolframalpha.com/input/?i=1%2F2+binary
http://www.wolframalpha.com/input/?i=1%2F5+binary
http://www.wolframalpha.com/input/?i=1%2F10+binary

Post a reply to this message

Warp wrote:
>   12 yes, but are you sure 0.3 can be converted from double to float without
> losing precision? (Not that it really matters with literals, though...)

Yes, *because* it's a literal. The compiler can tell me it'll fail in the 
case where I lose precision with the literal.  But sure, that's a decent point.

In other words, it complains the same for passing 0.5.  :-)  It's a generic 
result of the rules of casting in the language. It should not hold for literals.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

Warp wrote:
>> You have to actually say
>>    xyz(0.3f, 12u)
>> because doubles don't silently cast to floats and ints don't silently cast 

>   12 yes, but are you sure 0.3 can be converted from double to float without
> losing precision? 

Actually, the annoyance isn't the lack of precision. It's that a literal 
without a marking saying what kind of literal it is is assumed to be a 
specific type even when the compiler can trivially determine that that type 
is the wrong type.

Of course, that kind of goes along with not being able to overload on the 
return type of a function, so I guess it isn't too unexpected. Better would 
be to have a tag letter for every type of literal (e.g., f for float, d for 
double, etc) and if the tag isn't there, the literal is whatever type is 
needed for that expression. I think that would cause annoyance less often, 
with the down side that you might wind up with ambiguous expressions that 
are combinations of literals that you'd need to disambiguate on occasion. 
(Sort of like if you had { print("Hello") } and print() had an ASCII 
overload and a UTF-8 overload or something.)

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

Darren New wrote:

> Actually, the annoyance isn't the lack of precision. It's that a literal 
> without a marking saying what kind of literal it is is assumed to be a 
> specific type even when the compiler can trivially determine that that 
> type is the wrong type.

I could repeat myself and once again mention that Haskell allows a 
numeric literal to represent any possible number type, and automatically 
deduces which one you intended without you having to do anything 
special. And you can extend this to custom numeric types you invent 
yourself. But since nobody here uses Haskell, I guess it's still moot. ;-)

Then again, Haskell is a language which automatically deduces types all 
over the place anyway, so I guess it's not that surprising.

Unfortunately, while Haskell does this for numbers, it does *not* do it 
for strings. (I believe there's a little-known GHC pragma which allows 
you to do this...) If you write a string literal, it's type is "list of 
characters". Which is kind of annoying if you actually wanted "array of 
characters" or something else.

More irritating still is the fact that Haskell has a special notation 
for writing lists, but it only works for lists. If you want to 
initialise an array, you have to write the initialiser as a list; how 
dumb is that?

Also: I've just finished The Milkman Conspiracy level from Psychonauts, 
and as I type this my computer screen literally seems to be bending. 
Which is really freaky, by the way...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> I could repeat myself and once again mention that Haskell allows a 
> numeric literal to represent any possible number type,

Yeah. Lots of languages do that.  Just not C#.


Altho I was amused when I tried a header like

   public void xyz(float a, float b, float c = 0.25) { ... }

and the error message pointed at the = and said "default values not allowed."

Not just "syntax error" or ") expected" or something, but a special case for 
the syntax error being an "=" followed by a literal.

> More irritating still is the fact that Haskell has a special notation 
> for writing lists, but it only works for lists. If you want to 
> initialise an array, you have to write the initialiser as a list; how 
> dumb is that?

It's hard to do a good job without the equivalent of read macros.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message