FloatVector
Graham Miller
After applying the patch:
cd $GOROOT/src/pkg/container/vector
make generate
cd $GOROOT/src
./all.bash
All tests should pass, including new floatvector_test.go
graham
David Roundy
is usually a bad idea? It seems sort of sad to me that go calls a
float32 a float, rather than a float64. There are certainly uses for
float32, but it's pretty darn limited. e.g. modern machines have
sufficient memory that adding up a moderately large array of float32
in the ordinary way (one element at a time) is a bad idea. The extra
precision of float64 isn't a panacea, but it sure helps a lot!
And perhaps having FloatVector, Float64Vector, Float32Vector,
ComplexVector, Complex64Vector, Complex128Vector, UintVector,
Uint8Vector, Uint16Vector,. Uint32Vector etc seemed like a bit much?
David
--
David Roundy
Graham Miller
It is a good point about float32 vs float64. I just think that if the standard library is going to provide 'vector' functionality for any types, some type of floating point number needs to be one of them.
Would a Float64Vector be better received? I can certainly produce one of those in short order.
graham
Russ Cox
<rou...@physics.oregonstate.edu> wrote:
> Perhaps it's because unlike, int, using floats (rather than float64)
> is usually a bad idea? It seems sort of sad to me that go calls a
> float32 a float, rather than a float64.
We have mooted the idea of making float be 64 bits
and the idea of dropping it entirely. I don't remember
what the end result was other than that nothing happened.
We don't use floating point very much.
Russ
David Roundy
Actually, dropping float entirely sounds nice to me. It is nice to be
explicit, and (unlike int) I don't think there is ever a use where one
just wants a "reasonable" float type. On the other hand, it doesn't
greatly bother me either, even though I do use a lot of floating point
(albeit not all that much in go, so far).
--
David Roundy
David Roundy
math package has only float64 functions, so there's definitely
precedent.
David
--
David Roundy
Sonia Keys
>
> We have mooted the idea of making float be 64 bits
> and the idea of dropping it entirely. I don't remember
> what the end result was other than that nothing happened.
> We don't use floating point very much.
short declarations, for example
a := 6.02
Defaulting to float64 would be more often more convenient than
float32, I think. One program I wrote used float32 to save space in
large arrays, but was compelled by the math package to do the actual
number crunching in float64. Even in this program that had a use for
float32s, it still would have been a little more convenient if short
declarations would have defaulted to float64.
Sonia
ron minnich
<rou...@physics.oregonstate.edu> wrote:
> Actually, dropping float entirely sounds nice to me. It is nice to be
> explicit, and (unlike int) I don't think there is ever a use where one
> just wants a "reasonable" float type. On the other hand, it doesn't
> greatly bother me either, even though I do use a lot of floating point
> (albeit not all that much in go, so far).
If you're really wanting to let people achieve what they want in
numerical accuracy, it may be best to drop it entirely. It's not just
for the usual assume tradeoff of storage vs. accuracy: for some
algorithms. float64 is *less* accurate (yep) than float32. Yes, it's
counterintuitive, but it is a real effect.
OTOH, maybe people who care about that level of accuracy should not be using go?
ron
David Roundy
> If you're really wanting to let people achieve what they want in
> numerical accuracy, it may be best to drop it entirely. It's not just
> for the usual assume tradeoff of storage vs. accuracy: for some
> algorithms. float64 is *less* accurate (yep) than float32. Yes, it's
> counterintuitive, but it is a real effect.
You've piqued my curiosity: in what sort of algorithm will float32 be
more accurate?
--
David Roundy
ron minnich
I'm trying to find the paper, and slides, but failing. It was
presented at the LACSI 2006 symposium in a workshop.
I'll try to get it.
ron
Norman Yarvin
As someone who does, I ask that you please go ahead and do one or the
other. It doesn't matter very much which, so long as the type isn't left
up to the implementation. Keeping 'float' as implementation-defined
means that people will run into the situation where person A writes a
program expecting float to be 64 bits, and person B runs it in 32-bit
arithmetic and gets wrong answers, which in many cases will be wrong
enough to matter but not wrong enough to be obviously wrong. That's a
bad type of bug to deal with -- much worse than with integers, where
overflowing a 32-bit integer generally gets you into obviously-wrong
behavior.
Complete removal of 'float' would be my preference, but keeping it as an
alias for float64 would also be acceptable. (As an alias for float32,
less so; people who choose 'float' because they don't know what they want
probably should be given the higher precision, as they're less likely to
hurt themselves that way.)
--
Norman Yarvin http://yarchive.net
arrow
you're describing is this workshop.
http://www.c3.lanl.gov/lacsi-wpp/#Jack
It described using 32 bit operations in order to increase the
performance of an algorithm, the calculate a residual error using 64
bits (or more). With the residual you can iterate the 32 bit operation
and get a greater precision result without the performance penalty of
using 64 bits. I'm not sure if this is what you're thinking about
though since it is slightly different.
This presentation did get me thinking about HPC though. Given that
HPC's are getting to be much more parallel, go would fit naturally
with development in this area. Especially for scientists and engineers
who are more concerned about the physical processes they are
simulating than the finer aspects of the language, it seems that go
(with the right set of HPC libraries) could be very successful in this
area (I'm guessing scientific computing in general too).
On Sep 10, 10:28 am, ron minnich <rminn...@gmail.com> wrote:
> On Fri, Sep 10, 2010 at 4:45 AM, David Roundy
>
Scott Lawrence
> I took a look at the workshops. The closest that I could find to what
> you're describing is this workshop.
>
> http://www.c3.lanl.gov/lacsi-wpp/#Jack
>
> It described using 32 bit operations in order to increase the
> performance of an algorithm, the calculate a residual error using 64
> bits (or more). With the residual you can iterate the 32 bit operation
> and get a greater precision result without the performance penalty of
> using 64 bits. I'm not sure if this is what you're thinking about
> though since it is slightly different.
>
> This presentation did get me thinking about HPC though. Given that
> HPC's are getting to be much more parallel, go would fit naturally
> with development in this area. Especially for scientists and engineers
> who are more concerned about the physical processes they are
> simulating than the finer aspects of the language, it seems that go
> (with the right set of HPC libraries) could be very successful in this
> area (I'm guessing scientific computing in general too).
the consensus was, go is /not/ suited for HPC or scientific computing,
and won't be without some pretty major changes. (Proper matrices,
garbage collection, a couple other examples.) This isn't really a
library issue so much as the fact that some parts of the language just
don't match.
Not against go taking the HPC route, just saying that it doesn't seem to
be doing so.
arrow
scientific computing.
http://groups.google.com/group/golang-nuts/browse_thread/thread/fd5a197e78814d91/97bf58fea00d2297?q=HPC&lnk=ol&
I skimmed it quite quickly but I don't think a "consensus" was arrived
at (some thought it would work, some didn't). The main reason I think
go is promising in HPC is that it's ability to be expressive with a
simple uncomplicated syntax would appeal to those doing HPC (who want
to concentrate more on what they are modelling than how they are
writing the code.
I agree that go doesn't seem to moving towards HPC, however I think
most of it is the lack of a larger community wanting to do HPC in go.
There are some aspects of go that could be improved, but I think most
of these issues could be solved with either libraries or some form of
preprocessor (something which go makes easy). The only thing that I
see being a problem is the GC issues, and even these seem to be in
very specific cases. They are also likely to improve as the GC
improves (although granted that might not solve all the issues for
HPC).
As a side not, I've started a project that may be interesting. Please
take a look and comment if you can. I'm hoping to attract more go
programmers through this project since the field has been attracting
lots of attention by armchair scientists.
http://gogcm.blogspot.com/
ron minnich
<kristian...@gmail.com> wrote:
> I think Go is very well-suited to HPC and scientific/mathematical
> programming, actually.
I think it might be, but is has a ways to go. Let us not forget Java Grande.
ron
kem
On Sep 11, 12:27 pm, ron minnich <rminn...@gmail.com> wrote:
> On Sat, Sep 11, 2010 at 10:21 AM, Kristian Markon
>
> > I think Go is very well-suited to HPC and scientific/mathematical
> > programming, actually.
>
> I think it might be, but is has a ways to go. Let us not forget Java Grande.
difficulty setting up my account and whatnot.
I agree with you that Go has a way to go (I wish I could avoid that
pun), but think it's very promising for where it's at. It would be
extremely nice if there were features (e.g., native matrices, generics-
like functionality) added to facilitate its use with numerical
computing, but I'm not sure it will be necessary--only time will tell.
Java certainly is a major player in this area, although I think the
JVM's memory consumption is an issue that's not acknowledged quite
enough. I also personally find type hierarchies particularly
frustrating with numerical programming--that's one of the things I
like about Go in that regard--but that's more my personal preference
probably.
ron minnich
> Java certainly is a major player in this area, although I think the
> JVM's memory consumption is an issue that's not acknowledged quite
> enough. I also personally find type hierarchies particularly
> frustrating with numerical programming--that's one of the things I
> like about Go in that regard--but that's more my personal preference
> probably.
What i was really trying to say -- I can't believe I was too subtle
:-) -- was that just because a language is wonderful, does not
necessarily mean it is wonderful for everything. Lots of cash got
thrown at Java to make it work for HPC as part of Java Grande, and the
conclusion in the end was that it did not represent any real
improvement over what was there, quite the contrary, it was a dog, in
part because some of those things that made it work well for its
intended use were not a good thing for HPC.
So, while Go is great, that does not imply that it is great for FPGAs
and HPC and whatever else happens to cross people's minds. Anytime a
new good language comes out there is a tendency to want to use it for
EVERYTHING, which can be detrimental to making it work well for its
intended uses.
ron
kem
> What i was really trying to say -- I can't believe I was too subtle
> :-) -- was that just because a language is wonderful, does not
> necessarily mean it is wonderful for everything.
still a lot of development of the Java framework for HPC--although I
agree with you.
>
> So, while Go is great, that does not imply that it is great for FPGAs
> and HPC and whatever else happens to cross people's minds. Anytime a
> new good language comes out there is a tendency to want to use it for
> EVERYTHING, which can be detrimental to making it work well for its
> intended uses.
>
pushing its boundaries, seeing where it will go and where it won't.
Jonathan Amsterdam
i.Less(j) meant i < j for int, string, float, etc., then the vector
package would become much simpler, with a single class working for
everything.
> 4KViewDownload
Eleanor McHugh
> This whole thread is an argument for methods for built-in types. If
> i.Less(j) meant i < j for int, string, float, etc., then the vector
> package would become much simpler, with a single class working for
> everything.
Which would then make operators a bit redundant...
Ellie
Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
raise ArgumentError unless @reality.responds_to? :reason
Steven
> This whole thread is an argument for methods for built-in types. If
> i.Less(j) meant i < j for int, string, float, etc., then the vector
> package would become much simpler, with a single class working for
> everything.
>
>> Is there any reason why container/vector would have IntVector and
>> StringVector but not FloatVector? If not, could it be added? I have
>> attached a patch that I believe should do the trick (also can be viewed herehttp://pastie.org/1148633)
>>
>> After applying the patch:
>>
>> cd $GOROOT/src/pkg/container/vector
>> make generate
>> cd $GOROOT/src
>> ./all.bash
>>
>> All tests should pass, including new floatvector_test.go
>>
>> graham
>>
>> floatvector.patch
>> 4KViewDownload
What happens when you override an int? Does the new type magically
have these built-in methods unless overridden? Or do you need to
define these for every type derived from a built-in that you don't
want to be at a disadvantage?
Also, this would be less efficient than the current implementation,
since it would require dynamic dispatch where no dispatch was
originally necessary.
PS - Go doesn't have classes. This may sound pedantic, but it isn't. I
find when people call types or structs "classes" in Go, even if
informally, they tend to unconciously introduce incorrect assumptions
into their reasoning about them.
Jonathan Amsterdam
Jonathan Amsterdam
> > i.Less(j) meant i < j for int, string, float, etc., then the vector
> > package would become much simpler, with a single class working for
> > everything.
>
>
> have these built-in methods unless overridden? Or do you need to
> define these for every type derived from a built-in that you don't
> want to be at a disadvantage?
> Also, this would be less efficient than the current implementation,
> since it would require dynamic dispatch where no dispatch was
> originally necessary.
code. It's only when they are interfaces that you get dynamic
dispatch. No difference in efficiency.
Eleanor McHugh
>> Which would then make operators a bit redundant...
>
> As they should be -- syntactic sugar for something more uniform.
I tend to agree, although I'd probably ditch the syntactic sugar altogether - parsing operators is an ugly wart on most language designs :)
Ostsol
wrote:
>
> >> Which would then make operators a bit redundant...
>
> > As they should be -- syntactic sugar for something more uniform.
>
> I tend to agree, although I'd probably ditch the syntactic sugar altogether - parsing operators is an ugly wart on most language designs :)
>
> Ellie
-Daniel
Eleanor McHugh
I know, shocking isn't it ;)
Graham Miller
be a bit better rationale for separate float32 and float64 vectors, so
I wanted to provide my patch, in case anyone else wanted it.
graham