![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Darren New
Subject: That's got to be one of the stupider design choices I've seen
Date: 18 Feb 2010 23:54:09
Message: <4b7e1971$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Warp
Subject: Re: That's got to be one of the stupider design choices I've seen
Date: 19 Feb 2010 04:44:50
Message: <4b7e5d92@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Invisible
Subject: Re: That's got to be one of the stupider design choices I've seen
Date: 19 Feb 2010 04:55:45
Message: <4b7e6021$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Warp
Subject: Re: That's got to be one of the stupider design choices I've seen
Date: 19 Feb 2010 04:58:06
Message: <4b7e60ae@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp <war### [at] tag povray org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Invisible
Subject: Re: That's got to be one of the stupider design choices I've seen
Date: 19 Feb 2010 05:20:48
Message: <4b7e6600$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Invisible
Subject: Re: That's got to be one of the stupider design choices I've seen
Date: 19 Feb 2010 05:25:41
Message: <4b7e6725@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Darren New
Subject: Re: That's got to be one of the stupider design choices I've seen
Date: 19 Feb 2010 11:36:08
Message: <4b7ebdf8$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Darren New
Subject: Re: That's got to be one of the stupider design choices I've seen
Date: 21 Feb 2010 13:43:58
Message: <4b817eee$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Orchid XP v8
Subject: Re: That's got to be one of the stupider design choices I've seen
Date: 21 Feb 2010 15:42:28
Message: <4b819ab4$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Darren New
Subject: Re: That's got to be one of the stupider design choices I've seen
Date: 21 Feb 2010 16:04:45
Message: <4b819fed$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |