Last Gasp Call for Native Decimal Support
Vincent Callanan
the lack of native support for Decimal Types troubles me greatly. It
troubles me all the more because GO is such a breath of fresh air in
most other respects. Yet when I see that GO already has native support
for complex numbers, I wonder who or what is setting priorities here.
This subject has already been beaten to death on many other language
forums and flared up briefly on this forum at:
http://groups.google.com/group/golang-nuts/browse_thread/thread/d70f5d69e4f05de3/32e966f929fe20ef?lnk=gst&q=decimal#32e966f929fe20ef
However, I am still left with a queasy feeling about the dangers of
GROUPTHINK.
Let me try to express my worries with a random list of personal
observations:
- The general fixation on floats (if you excuse the pun) appears to be
a historical quirk due to the early ties between programming languages
and the physical sciences.
- If it were not for the painfully slow introduction of native decimal
types and the preponderance of legacy botches in the global code base,
fixed-point decimal usage would far exceed floats.
- All other things being equal, floats should in fact be the exception
to the rule and fixed-point decimals the norm (in the broader
application space).
- Using floats is generally painful except where they are specifically
required.
- Using ints to represent fixed point decimals (e.g. cents or
microcents) can be no less frustrating and error-prone.
- Using custom decimal classes or libraries is inefficient in number-
crunching applications.
- With the move to the cloud, web apps are increasingly required to do
number-crunching.
- GO is a highly-efficient web language (see GAE) and is ideal for
number-crunching.
- Why cripple GO in one key area of number-crunching
- Having native decimal types would also mean seemless debugging.
- The evolution of standard library functions (e.g. fmt, printf) would
also benefit from native decimal support at the outset.
- Efficient and error-free data exchange with third-party apps and
back-end databases also demands native support for decimals,
especially where on-the-fly calculations are required on large data
sets such as queries.
- As things stand, decimals will probably be bolted on later á la
Python. In the meantime, the usual botches will infect the GO code
base and emerging libraries remaining a poisonous legacy for years to
come.
- If lack of underlying native C support was not an issue for complex
numbers, it should not be an issue for fixed-point decimals.
- This is not about Wall Street or esoteric financial apps. This is
about the "real" world.
- This is a good example of where people need to think outside the
box.
- The inventors of GO have stuck their necks out and shown leadership
on many other issues.
- It is not good enough to say that "GO does not need to show
leadership" on this issue.
- Native dec16, dec32 and dec64 types would be a major selling point
for GO.
- More users and more interest increases the chance of the language
gaining traction.
- This is the last chance to get this right.
I stress that I write these words not as a criticism but out of
concern.
Thank you for your patience.
Ian Lance Taylor
> I am delighted that Version 1 of GO is about to be released. However,
> the lack of native support for Decimal Types troubles me greatly. It
> troubles me all the more because GO is such a breath of fresh air in
> most other respects. Yet when I see that GO already has native support
> for complex numbers, I wonder who or what is setting priorities here.
The Go team is setting priorities.
It is far too late to add fixed point decimal support to Go 1. Sorry.
> - The general fixation on floats (if you excuse the pun) appears to be
> a historical quirk due to the early ties between programming languages
> and the physical sciences.
That could be historically true. Today I think it's simply that
processors have well-standardized hardward support for floating point
values. Hardware support for fixed point decimal types is much less
advanced. As far as I know none of the Go targets currently support it.
> - Using custom decimal classes or libraries is inefficient in number-
> crunching applications.
But it is no less efficient than adding a fixed point decimal type to
the language which is not supported in processor hardware.
> - If lack of underlying native C support was not an issue for complex
> numbers, it should not be an issue for fixed-point decimals.
The C language has supported complex numbers since the C99 standard over
10 years ago.
> - It is not good enough to say that "GO does not need to show
> leadership" on this issue.
On the other hand, it would be a drastic mistake for Go to add the wrong
sort of fixed point decimal type. Can we be confident about the exact
characteristics of future hardware implementations of fixed point
decimal?
Ian
Vincent Callanan
I stand corrected on C support for complex numbers. I assumed from
memory that it was a library because of the need to include a header
file.
I appreciate the time pressure for 1.0 but is it at least possible to
allow for a *native* decimal type to be introduced in the "near"
future on the basis that it is better "a little late" than never.
Perhaps as early as 1.1 or 1.2 if no inadvertent backward
compatibility issues are introduced in 1.0.
In terms of choosing a format, I believe that IEEE has already
published a standard.
I also feel that the issue of hardware support is a red herring as
long as a decimal standard has been agreed. I recall that native
floats were used in programming languages long before floating-point
CPUs came on the scene -- and they were notoriously inefficient. Later
compilers had a switch to enable hardware support when FP co-
processors became available. Even without hardware support, low-level
software emulation is still more efficient than user-defined classes
or add-on libraries. And when hardware support does eventually reach
critical mass, GO apps that support native decimals will be ready to
take advantage. Its the old chicken and egg thing that often arises
between HW and SW. This is less about ultra-efficiency right now and
more about future-proofing the language while there is still time.
I recall that Visual Basic 6 (launched about 15 years ago!!!!!) had
native currency/decimal support and this was already a desirable
feature even though it was predictably inefficient. As it happens, VB6
also compiled to native code and remains one of the more positive
legacies of Bill Gates as borne out by Microsoft's futile efforts to
kill it off.
Ian Lance Taylor
> I appreciate the time pressure for 1.0 but is it at least possible to
> allow for a *native* decimal type to be introduced in the "near"
> future on the basis that it is better "a little late" than never.
> Perhaps as early as 1.1 or 1.2 if no inadvertent backward
> compatibility issues are introduced in 1.0.
Fortunately no change in Go 1 is required in order to introduce a native
decimal type at a later date. The predeclared types (int, float64,
etc.) are not keywords. New predeclared types can be introduced at any
time without breaking any existing working Go 1 programs. (Not that we
have any current plans to introduce new predeclared types, but nothing
precludes it.)
> In terms of choosing a format, I believe that IEEE has already
> published a standard.
True, but a published standard is one thing, and actual implementations
are another. I'm only aware of a single hardware implementation of that
standard, for PowerPC. (Intel ships a software implementation, and so
does the gcc compiler.)
> I also feel that the issue of hardware support is a red herring as
> long as a decimal standard has been agreed. I recall that native
> floats were used in programming languages long before floating-point
> CPUs came on the scene -- and they were notoriously inefficient.
Of course, but those formats varied considerably. A language like C can
get away with defining float and double very loosely, so that it can
adapt to different standards. A language like Go wants to be more
precise in describing behaviour. It would be a real mess if Go
specified a fixed point decimal type, and it turned out that hardware
wound up supporting a somewhat different fixed point decimal type.
> Even without hardware support, low-level
> software emulation is still more efficient than user-defined classes
> or add-on libraries.
That is not true in Go, at least not if you mean runtime efficiency.
Ian
Gustavo Niemeyer
> allow for a *native* decimal type to be introduced in the "near"
> future on the basis that it is better "a little late" than never.
> Perhaps as early as 1.1 or 1.2 if no inadvertent backward
> compatibility issues are introduced in 1.0.
I suggest introducing it in version 1.2000000000000002.
--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog
-- I'm not absolutely sure of anything.
Vincent Callanan
Thanks for taking the time to clarify my questions.
I am however surprised at your remark that low-level emulation of
native decimal types would make little difference to GO's run-time
efficiency compared to user-defined classes or add-on libraries. Does
the GO compiler not have the ability to encapsulate decimal operations
in machine code optimised for Intel/AMD/ARM architectures?
Let me sign off with the observation that native decimal support is
already well-established (and valued) in the .NET world.
Recalling your assertion that priorities are set by the "GO Team", I
hope you can at least recognise that this is a desirable feature
because, all too often, requests of this nature receive little more
than lip service from those who are most influential in language
development.
Keep up the good work.
Rémy Oudompheng
> Okay Ian,
>
> Thanks for taking the time to clarify my questions.
>
> I am however surprised at your remark that low-level emulation of
> native decimal types would make little difference to GO's run-time
> efficiency compared to user-defined classes or add-on libraries. Does
> the GO compiler not have the ability to encapsulate decimal operations
> in machine code optimised for Intel/AMD/ARM architectures?
It seems natural to imagine that a package can be created defining the
approriate data type and operations, using assembly if necessary when
relevant. It doesn't really make a difference, except maybe for the
fact that the operations will not be inlined.
Rémy.
Ian Lance Taylor
> I am however surprised at your remark that low-level emulation of
> native decimal types would make little difference to GO's run-time
> efficiency compared to user-defined classes or add-on libraries. Does
> the GO compiler not have the ability to encapsulate decimal operations
> in machine code optimised for Intel/AMD/ARM architectures?
Yes, but in effect all the operations would turn into function calls to
that optimized machine code. And that can be done for an external
package as well--that is, you can write a Go package in assembly code if
you so choose, though it's obviously painful.
(I guess there would be one noticeable difference with compiler support:
the compiler would translate string literals to fixed point at compile
time, whereas any straightforward package support would do it at
runtime.)
Ian
spir
> That could be historically true. Today I think it's simply that
> processors have well-standardized hardward support for floating point
> values. Hardware support for fixed point decimal types is much less
> advanced. As far as I know none of the Go targets currently support it.
type, thus creating no demand for hardware support? justifying their
choice by the lack of hardware support...
Denis
Peter Weinberger (温博格)
>> and so forth.
spir
> - Native dec16, dec32 and dec64 types would be a major selling point
> for GO.
Yes!
And think that, by sole inertia, if Go version 1 is not sufficiently
_different_, then people will stay by C, C++ (or even C# or Java). The
whole project would be a failure (just like D, despite all its
qualities) because of its conformism, Google's marketing power may not
be enough to compensate. It needs to open right track precisely where
historical weight stand on the wrong ones. (And there are many, or all
kinds, even syntactic like the use of '=' for assignment instead of
equality ,-)
Denis (newcomer)
Michael Jones
Paul Borman
Jessta
> It needs to open right track precisely where historical weight stand on the
> wrong ones. (And there are many, or all kinds, even syntactic like the use
> of '=' for assignment instead of equality ,-)
In mathematics notation '=' doesn't mean equality in the same way that
'==' means equality in Go.
In maths, '=' means 'is the same as' , it's a statement of fact not a question.
Which makes it far closer to the assignment operation that 'Go' uses it for.
A test for equality isn't something very useful in mathematics since
it doesn't often deal with user input or things changing value during
a calculation. Thing aren't equal or inequal, they either have a
relationship or don't. Which is why programming languages had to
create their own symbol for the "are these the same value?" semantics.
- jessta
--
=====================
http://jessta.id.au
Vincent Callanan
All the more reason for native/built-in support.
Perhaps a future GCC extension will have the ability to produce inline
machine code optimised for standards-based decimal operations. I
wonder if something like this is not already in the works.
BTW, the lack of operator overloading in GO is also a good reason for
a native implementation.
On Jan 31, 11:52 pm, Ian Lance Taylor <i...@google.com> wrote:
Vincent Callanan
> I suggest introducing it in version 1.2000000000000002.
But are you sure you don't mean 1.20000000000000019999999999999999999?
I advise that you enclose that version number with fmt......just in
case!!!!!
Paulo Pinto
now and then
to see how the language evolves.
What attracted me to Go was the similarities it shares with Oberon,
and the
initial message of being a safe systems language. I even tried to do
some initial
contribution to os.user in Windows.
For someone with my CS background I feel that Go lacks a few things
and some
of the features being sold as Go only are actually available in many
other languages,
even if they are not mainstream.
Regarding your point about Java, Python, Go. To which implementations
are you referring
to? The last time I checked implementations can be compiled or
interpreted, languages not.
Go is surely simpler than C++, but more efficient? I have my doubts.
Again, which implementations?
Anyway I just wanted to call the attention that "Try it, you'll like
it!" does not always hold.
--
Paulo
Vincent Callanan
...whatever about emulation optimisation and inlining, one can safely
say that a native implementation will never be LESS efficient than
libs or custom classes.
Once the format is standardised, the implementations will follow.
The key questions right now are:
1. Is there general agreement that built-in decimal support is a very
desirable feature in the near future (this is not obvious yet).
2. Is it necessary to reserve any keywords for backward compatibility?
3. Has the IEEE standard received sufficient support from key players
(I am thinking of Intel, AMD, ARM, IBM, etc)?
4. Would adding Google to that list not give the emerging standard
some critical mass (leadership?)
5. What better way to set the cat among the pigeons than by supporting
built-in decimals in GO?
I note also that Intel has developed decimal libraries based on the
IEEE standard.
I assume this is with an eye to a seemless shift to hardware
emulation.
Peter Bourgon
> desirable feature in the near future (this is not obvious yet).
We've had (AFAIK) two threads on the mailing list on decimal support,
this being the second. Are there any third-party decimal packages
available, eg. on the Projects Dashboard[1] or cat-v.org[2]? Something
which could serve as a basis for a standardized implementation? This
to me seems like the bare minimum criteria to qualify a feature as
even "moderately desirable".
[1] http://godashboard.appspot.com/project
[2] http://go-lang.cat-v.org/pure-go-libs
> 2. Is it necessary to reserve any keywords for backward compatibility?
> 3. Has the IEEE standard received sufficient support from key players
> (I am thinking of Intel, AMD, ARM, IBM, etc)?
> 4. Would adding Google to that list not give the emerging standard
> some critical mass (leadership?)
> 5. What better way to set the cat among the pigeons than by supporting
> built-in decimals in GO?
Based on the above, all of these questions appear to be putting the
cart before the horse.
Vincent Callanan
> Based on the above, all of these questions appear to be putting the
> cart before the horse.
Hardware support is always driven by software need in these
situations.
Just look at the history of floating point.
The standard seems to have already gained critical mass.
And that is all that matters now.
It is a question of people seeing the need in the target app space.
I would have thought that GO's sweet spot would make this totally
obvious.
This is one of those features that programmers never appreciate until
they have it.
And when they have it, they wonder how they ever lived without it.
Aram Hăvărneanu
base 7 numbers. Oh, and base 13.
--
Aram Hăvărneanu
roger peppe
>
> ...whatever about emulation optimisation and inlining, one can safely
> say that a native implementation will never be LESS efficient than
> libs or custom classes.
i'm not sure you can.
if Go adopts a particular standard that turns out not to
be the standard adopted by hardware manufacturers, then
the Go runtime would have to use software emulation.
a package that directly uses the hardware implementation
may then be faster.
Ian Lance Taylor
> 1. Is there general agreement that built-in decimal support is a very
> desirable feature in the near future (this is not obvious yet).
I have not seen general agreement. Certainly nothing is going to happen
before the Go 1 release.
> 2. Is it necessary to reserve any keywords for backward compatibility?
No.
> 3. Has the IEEE standard received sufficient support from key players
> (I am thinking of Intel, AMD, ARM, IBM, etc)?
Has Intel supported the standard other than by providing a software
library? What have AMD and ARM done?
> 4. Would adding Google to that list not give the emerging standard
> some critical mass (leadership?)
The small Go team, which works on an open source project, does not
represent Google. In any case the other companies you list are hardware
vendors, unlike Google.
> 5. What better way to set the cat among the pigeons than by supporting
> built-in decimals in GO?
Since you ask, I think a better way would be writing a popular software
package which uses fixed point decimal and would run faster with
hardware support.
Ian
Vincent Callanan
> Since you ask, I think a better way would be writing a popular software
> package which uses fixed point decimal and would run faster with
> hardware support.
killer apps of the past such as CAD and spreadsheets which drove the
mass market for
floating point co-processors. I recall buying one of those devices in
a beautiful retail box, inserting it in a blank socket on my PC's
mainboard and drooling over the performance gains.
This is not going to happen for fixed-point decimal apart altogether
from the fact that, with web apps, there is little control over
hardware for the end user.
This is about programming convenience.
This is about quality code.
This is about consistent interfaces.
This is about avoiding the usual botches.
This is about "acceptable" perfomance initially and incremental
efficiency gains over time as hardware support comes on stream.
What is going to drive this?
- Hardware Support (without a ready software application base)?
- Software App Demand (without proper program language primitives)?
- Or program language primitives?
I think the answer is obvious.
But that's just me.
Gustavo Niemeyer
> - Hardware Support (without a ready software application base)?
> - Software App Demand (without proper program language primitives)?
> - Or program language primitives?
>
> I think the answer is obvious.
Me too. What will drive it is use. To make your point, you're driving
a dichotomy that either it is a native type or it doesn't matter. This
is a false dichotomy.
chris dollin
> On Wed, Feb 1, 2012 at 14:01, Vincent Callanan <vin...@callanan.ie> wrote:
>> - Hardware Support (without a ready software application base)?
>> - Software App Demand (without proper program language primitives)?
>> - Or program language primitives?
>>
>> I think the answer is obvious.
>
> Me too. What will drive it is use. To make your point, you're driving
> a dichotomy that either it is a native type or it doesn't matter. This
> is a false dichotomy.
What "native types" give you that packages don't is convenient syntax
for using things which are, after all, just numbers. Otherwise I can't
see a problem with trying decimals out with a package and perhaps
eventually picking the best offering to go native with.
Chris
--
Chris "allusive" Dollin
Vincent Callanan
But I believe the logic is there.
David Roundy
> The key questions right now are:
>
> 1. Is there general agreement that built-in decimal support is a very
> desirable feature in the near future (this is not obvious yet).
I don't think there is. What I don't see is the use case for built-in
decimal support. Is there a use case other than dollar quantities? If
it's only useful for a given field of endeavor, then it's hard to see
it belonging in the language.
--
David Roundy
Vincent Callanan
> it's only useful for a given field of endeavor, then it's hard to see
> it belonging in the language.
attention to the rigid mindset that even thinks of posing such a
question. Other comments that treat decimals like some kind of an
alien quantity are equally frustrating. For example, putting decimals
on a par with rarely used radixes (e.g. 3,5,7).
The first thing we need to accept is that we are all products of our
experience and sometimes we need to stand back and think outside the
box. I am no less culpable of this than anyone else. I don't think it
is presumptuous of me to say that those who are involved in
programming language design are strongly influenced by the physical
sciences and related math disciplines. Even when this is not the case,
the history of language development and its legacies (including
hardware) are difficult to shake off. The generally "uncool" or even
"boring" image attached to financial applications will also tend to
push these issues down the list of priorities within the "hacker
community". It also seems obvious to me that the instinctive aversion
to "bean counters" has a psychological effect in many quarters.
The fact is that human beings have 10 fingers. Decimals are ingrained
in so many aspects of life. It is not just about "dollars", cents,
microcents and esoteric currency exchange requirements. There are so
many other areas where values (and intermediate values) need to be
defined as *fixed-precision* quantities. For example, measurements in
many practical real-world applications are best represented using
fixed-point decimals. It pains me, in this day and age, that I still
have to use on-the-fly rounding, formatting, conversions, string
representations and other tricks to cover up for this glaring
deficiency in so-called modern programming languages. Worse still, I
know that "the guy at the other end" will be doing exactly the same
botches in reverse. Apart altogether from the inefficiencies, there is
the issue of quality, readability and, yes, development time.
The fact that Microsoft happens to use a gigantic built-in decimal
type only adds insult to injury because, apart from being
unnecessarily inefficient for the majority of use cases, the 128-bit
size almost implies that decimals are esoteric. Python seems to have a
more standards-based approach although I don't actually know much
about the language apart from the fact that it is not strongly typed
and values can expand or contract indefinitely. The fact that Python
supports operator overloading also makes a library implementation
acceptable even if there remain a few ugly constructs. I appreciate
that GO has far more constraints to consider than Python.
Nevertheless, there is a useful preliminary discussion about decimals
at http://docs.python.org/py3k/library/decimal.html?highlight=decimal#module-decimal.
A key quality in any programmer, designer or design team is "empathy"
for the end-user. This does not mean that "the customer is always
right" or that too much "noise" has to be added to a language to
satisfy every need. In fact, as the venerable Steve Jobs has shown, it
is often necessary to disabuse customers of certain notions for the
greater good. Perhaps I am one such customer. Perhaps not. But let me
try to explain my position by putting the shoe on the other foot.
Let us imagine that, by some quirk of history, the early impetus for
program design was driven by one-dimensional 10-fingered accountants
who had tired of using their fountain pens and abacuses. Let us
suppose that when C was launched, it supported ints and decimals
rather than ints and floats and everything followed logically from
that: Decimal co-processors came along only to be eventually
integrated onto CPU chips; GO arose out of that legacy with built-in
dec32 and dec64 types. Then some unfortunate fool came along and
started clamoring for built-in floats in a world where programmers who
needed these types had become used to botches, thus giving the lie to
the latent demand for such functionality. If you read back over this
thread and apply to floats the same arguments used against decimals,
you might begin to understand where I am coming from.
I believe that GO is in a unique position to take leadership on this
issue.
I would wager that it would be a major selling point for the language
down the road.
I realise that I have lost the argument for now.
All I hope is that this issue receives fresh consideration in the near
future.
David Roundy
David
--
David Roundy
Gustavo Niemeyer
<rou...@physics.oregonstate.edu> wrote:
> So you're saying you don't know of any use cases, but imagine there are some?
You're helping Vincent's point. There are very well known use cases
for using decimals. I even feel funny saying that.
It's not even worth debating this issue further. Go will have support
for decimals. Whether they will be native at some point is up for
debate, but it's just a matter of time until a good package supporting
that is available. Also, even if it does become known by the compiler
at some point, having a package is a great first step.
groupie
I agree totally, its funny this discussion is happening. And sad, very
sad at the same time. There are programmers out there who actually need
to ask for use cases on this? And make comments like it could even be
there weren't any? Uhh, shaking. Disgusting :))
Actually, finding out that go had no support for decimals was what was
setting me off from it on the first glance - it took a while to come
back. That the very cautious presented and well-considered call for a
build-in type leads to a discussion instead of simply a line added to
the milestones document upsets me in a disturbing way.
My full support for Vincent's call and my wish, that very soon this
little missing brick will be added. With the release of version one a
lot of potential users will get attracted, and I fear some of them will
keep the lack of decimals in mind for a long time to talk down every
approach within their premises to use go for anything.
In another thread these days I read the FUD word used pretty
questionable. I think lack of decimals is what FUD is about - find a
little weakness in the fabric, try to stick your finger into it until
the thing looks like a bulky waste to everyone.
Its a pity that such a good effort like go will suffer from the fuddies.
I dont want it to, so lets get the decimal on the list, even if it does
not make it into number one.
Cheers,
C.
ron minnich
go back to the 50s when things such as base were very much in flux,
you can find at least one book that advocates for non-base-2 hardware.
One author we found argued that with the advent of vacuum tubes, we
were not stuck with the relay-based binary restrictions, and (memory
is not exact here) said something like "the use of base 2 will fade
away and in future non-base-10 computers will be seen as a short
interlude driven by our limitations."
Well, that did not quite pan out ... although the Burroughs 3500
series was a decimal architecture IIRC and was used for quite some
time. They were a very interesting architecture.
All of which is to say, don't take too much for granted.
At the same time, if you open up the doors to base 10, how soon do the
base 12 guys come in and demand that too :-)
ron
Paddy Foran
Botched the reply on my phone, sorry.
"I feel like a very important point is being missed here:
Writing a package > proposing an addition to the spec, this close to a major milestone at the very least.
Code speaks louder than email."
Typed on glass
Ian Lance Taylor
> Actually, finding out that go had no support for decimals was what was
> setting me off from it on the first glance - it took a while to come
> back. That the very cautious presented and well-considered call for a
> build-in type leads to a discussion instead of simply a line added to
> the milestones document upsets me in a disturbing way.
The most serious issue at hand is when Go should commit to a specific
standard for fixed-size decimal numbers. Keeping decimal support in a
package makes it relatively easy to change the supported standard, at
the cost of having convenient operator syntax and convenient literals
(it is important to note that there is no other cost). Adding a
specific decimal standard to the language proper makes it very hard to
change.
I think the strongest argument in favor of Go adopting decimals in the
language proper would be a hardware implementation in a processor that
Go actually supports, a hardware implementation which matches the
existing PowerPC implementation.
Vincent has argued that Go should lead in this area, implying that if Go
commits to a standard the addition of the types to the language will
help encourage adoption by other lanugages. I am far less confident.
Also, I simply do not believe that Go adding decimals to the language
will have any effect whatsoever on whether a processor manufacturer will
add them to their hardware.
Ian
ron minnich
> Also, I simply do not believe that Go adding decimals to the language
> will have any effect whatsoever on whether a processor manufacturer will
> add them to their hardware.
BCD instructions have been in architectures for at least a
half-century. The 8086 (and hence everything that followed) had them.
I just ran across a usage recently of them in fact. A video bios used
an 8086 bcd instruction in some weird invalid way. The purpose? To
ensure an 'invalid instruction trap' and fault out of the bios, i.e.
to terminate it --- in other words, the use was not exactly what was
intended
:-)
It's not like base 10 instructions have not been there. I believe
they're used in COBOL. I have not seen people running to emulate that
support in other places.
But, hey, the source to the compiler is there -- is there anything
stopping you from adding it to see if people like it?
It's a plan 9 style compiler, not gcc. You would be delighted, I
think, to see how beautiful these are inside -- and how easily you can
tinker with them.
ron
Daniel Theophanes
Robert Johnstone
further. If Go is successful, it will eventually have packages for
vectors, matrices, arbitrary precision floats, and more. All of this
on top of big.Int and big.Rat.
I don't think that Go should have native decimal support, because I'm
not certain that of all the possibilities, decimal support would help
the most users. There is a large scientific community growing around
Python at the moment because of NumPy and SciPy. A fully functional n-
dimensional library is a huge undertaking, so I'm not advocating
native vectors and matrices in Go. I am pointing out that there are
significant communities of programmers that will stay away from Go
unless requests like Chris Dollin's can be met with libraries.
Once Go 1 is complete, Go could benefit from a proposal for letting
user types use operators.
Robert
On Feb 3, 10:02 am, Gustavo Niemeyer <gust...@niemeyer.net> wrote:
> On Fri, Feb 3, 2012 at 12:46, David Roundy
Kyle Lemons
Once Go 1 is complete, Go could benefit from a proposal for letting
user types use operators.
Robert Johnstone
overloading and operator overloading together, they have important
differences. Still, the argument against boils down to, and I quote,
"things are simpler without it." While things are simpler for the
language designers and implementers, things are more complicated for
the language users, at least those users who do a lot of mathematical
programming.
Perhaps Go is not the right tool for those users, but hopefully you
can see how "life's simpler without it" might sound dismissive.
Kyle Lemons
Perhaps Go is not the right tool for those users, but hopefully you
can see how "life's simpler without it" might sound dismissive.
Robert Johnstone
community of scientific programmers (numpy and scipy). It does not
make a good example of the perils of operator overloading.
Your python example is just an example, not an argument. All men are
mortal. Shakespeare is mortal. Therefore, all men are Shakespeare...
Finally, the python example was a non sequitur. How exactly does it
relate to being dismissive of a user's concern?
Make your response to the group if you like, but I believe that you
are trolling.
John Asmuth
Make your response to the group if you like, but I believe that you
are trolling.
Michael Jones
Gustavo Niemeyer
> Python is a great example of how operator overloading can be (and often is)
> used to obscure what is happening. In Go, everything that's going on is
> clear simply by looking at the code. "a + b" can mean one of two very
FWIW, decimal numbers is the wrong context to argue that a + b is confusing.
Kyle Lemons
FWIW, decimal numbers is the wrong context to argue that a + b is confusing.
spir
I fully share your views and support your request. [See also other post
to come.]
Think at this: if we had reasonably efficient decimals, why use binary
nums *at all*? Binary nums originally are an artifact of HW leaking into
language design, later propagated from lang to lang without any
reasonable reason ;-)
The only case for binaries may be number-crunching apps extremely
demandingin UC cycles _and_ which do not require decimal exactness;
precisely because, since the HW is binary, there may always remain a
slight diff in performance in their favor --everything else beeing
equal. (But if decimals were to become a de facto standard, diffs in
design investment would certainly by far compensate this: everything
else would _not_ be equal.)
Denis
spir
mixes the question of decimal vs binary with the one of floating vs
fixed point. I find the latter hard to think. I mean: why, how, when use
one or the other? Advantages, drawback, and use cases of each. Would
someone introduce the topic? What do you think personly? Do you know of
any good (clear, complete, multi-sided) study of the issue?
I'm mainly thinking at decimals and/or relation of computing with humans
(thinking in decimals). But some info about the same debate for binary
nums would also be welcome.
Thank you,
Denis
Vincent Callanan
The problem about creating a "fantastic decimal library" is that,
without operator overloading and formatting support, it will be used
reluctantly and only in the most compelling applications, creating
little impetus "from the masses" for a built-in type. While operator
overloading might be desirable in this particular case, I can also
empathise with those who see this feature as "the thin end of the
wedge".
Your suggestion regarding a Go-to-Go compiler is very promising, not
only for this but for a lot of other features "on the backburner". I
am new to GO and did not realise that the parsing scaffolding was
already in place to do this. An "intelligent" front-end (as distinct
from a simple preprocessor) could have many other advantages, e.g.
absorbing gofmt and other housekeeping functions such as converting
aligned braces, stripping comments and compressing/obfuscating code. I
can imagine that this would be a perfect solution for GAE which is
well placed to leverage the concurrency features of GO but gives the
programmer no control over final compilation. (It is interesting that
the GAE datastore does not yet support decimals to the consternation
of many and some of the workarounds suggested are worth reading just
to add weight to my argument).
I think at this point, the IEEE standard for 32, 64 and 128-bit
decimals is well established. It is well thought out with a view to
eventual hardware optimisations and low-level libraries have already
been written. No other standard is likely to emerge. I am given to
understand that the hard work has already been done in GCC to which GO
is closely aligned (with IBM and Intel being the main contributors).
Yes, I realise that Microsoft and Java use proprietary big decimals
and SQL back-ends have also muddied the waters but such
incompatibilities are inevitable no matter what the outcome and can be
addressed using trivial conversions at the relevant interfaces.
It seems to me that the whole industry has been stuck in a circular
argument on this issue for some time. But there are signs of a break-
out triggered, as usual, by the emergence of a solid standard. One
could say that the confluence of events is actually quite auspicious
for a new language that is about to emerge from the labs and carries
no historical baggage.
Kyle Lemons
The problem about creating a "fantastic decimal library" is that,
without operator overloading and formatting support, it will be used
reluctantly and only in the most compelling applications, creating
little impetus "from the masses" for a built-in type. While operator
overloading might be desirable in this particular case, I can also
empathise with those who see this feature as "the thin end of the
wedge".
Confuncitonist
Alex Shinn
> On Fri, Feb 3, 2012 at 12:46, David Roundy
> <rou...@physics.oregonstate.edu> wrote:
>> So you're saying you don't know of any use cases, but imagine there are some?
>
> You're helping Vincent's point. There are very well known use cases
> for using decimals. I even feel funny saying that.
And yet neither you nor Vincent have given any.
David asked a valid question, and no one has
answered it. I read the linked discussions and
searched around and couldn't find any other
examples myself.
The very strong claim is being made that fixed
point should be the default and floating point
the exception, but I haven't seen strong enough
evidence to even justify fixed point in the core
language.
--
Alex
Gustavo Niemeyer
> David asked a valid question, and no one has
> answered it. I read the linked discussions and
> searched around and couldn't find any other
> examples myself.
http://c2.com/cgi/wiki?FloatingPointCurrency
chris dollin
> On Sat, Feb 4, 2012 at 12:02 AM, Gustavo Niemeyer <gus...@niemeyer.net> wrote:
>> On Fri, Feb 3, 2012 at 12:46, David Roundy
>> <rou...@physics.oregonstate.edu> wrote:
>>> So you're saying you don't know of any use cases, but imagine there are some?
>>
>> You're helping Vincent's point. There are very well known use cases
>> for using decimals. I even feel funny saying that.
>
> And yet neither you nor Vincent have given any.
> David asked a valid question, and no one has
> answered it.
In a previous post I said:
Concur. (Money and measurements, neither of which is uncommon or
obscure, come to mind.)
Chris
--
Chris "allusive" Dollin
Vincent Callanan
> The very strong claim is being made that fixed
> point should be the default and floating point
> the exception, but I haven't seen strong enough
> evidence to even justify fixed point in the core
> language.
you to give me a use case for integers. You would rightly feel that I
was being disingenuous because it is so obvious. Fixed precision
decimals are a natural choice for so many apps. The gradual transition
from imperial to metric measurements shows that this is more than just
a dying legacy. But since you insist, here are some use cases that
come immediately to mind but they are only the tip of the iceberg:
- Financial apps are the obvious use case and account for a broad
spectrum of apps these days, especially on the web. But many non-
financial applications must also deal with fixed-precision currencies
and quantities on an everyday basis, e.g. billing related data.
- Measurements and tolerances in telemetry/process apps (also seeing a
big move to the cloud) are often defined as fixed-point e.g. 10.345V,
2.56A, 45.5 degrees, 12.42mm, 0.01mm, etc, etc
- Percentages (as app parameters) are often defined as fixed-point
decimals, e.g. 21.5%, 12.25%, 0.1% etc.
I stand by my point that, outside of the physical sciences and related
math disciplines, decimals are far more useful than floats (all other
things being equal). Certainly, in the broader app space, there are
far more use cases for decimals than complex numbers (which GO
supports as a built-in type). I foresee a day when a programmer will
be dragged out and shot for using a float when he should in fact be
using a decimal type :-)
Getting hung up on hardware support is a recipe for paralysis. There
is no incentive for Intel/AMD/ARM to put decimal proocessing into
mainstream CPUs when it will take at least 5 years for the benefits to
percolate into software by which time said CPUs will be obsolete.
Market realities mean that CPU vendors are inclined to use any spare
silicon to give immediate end-user benefits such as increasing cache
size or adding specialist graphic processing that can be leveraged
immediately by video drivers that are developed simultaneously by the
CPU vendor. Decimal processing will only be compelling for CPU vendors
when there is enough software out there to reap *immediate* benefits.
This is no different than the history of floating point co-processors
alluded to earlier in this thread. And demand for decimal hardware
will follow in the same way. Just like with floats, it will be driven
by the availability of built-in decimal types with "acceptable"
efficiency both in terms of bits and operations. That is not likely to
happen with libraries even if libraries are a good starting point.
Imagine trying to express the following using a decimal library:
y = c1 * (d1 + d2 + d3) / (d4 + d5)
GO is destined to become a serious number-crunching language for the
web. Built-in decimal support is paramount. The IEEE standard is well-
established, the low-level GCC libraries have already been developed
and no other standard is on the horizon. I hope we can soon step out
of the circular argument and start thinking about implementation.
Vincent Callanan
chris dollin
> Imagine trying to express the following using a decimal library:
>
> y = c1 * (d1 + d2 + d3) / (d4 + d5)
y = c1.Times(d1.Add(d1).Add(d2).Add(d3)).Div(d4.Add(d5))
Sure, it's more clumsy, but it's straightforward.
Vincent Callanan
Imagine asking the "float guys" or the "integer guys" to write code
like that over and over again?
I'd prefer to go back to assembler mnemomics :-)
This is precisely why a decimal library would be avoided like the
plague, thus giving the lie to the latent demand for built-in decimal
types.
On Feb 7, 1:33 pm, chris dollin <ehog.he...@googlemail.com> wrote:
Russel Winder
> On 7 February 2012 13:27, Vincent Callanan <vin...@callanan.ie> wrote:
>
> > Imagine trying to express the following using a decimal library:
> >
> > y = c1 * (d1 + d2 + d3) / (d4 + d5)
>
> y = c1.Times(d1.Add(d1).Add(d2).Add(d3)).Div(d4.Add(d5))
>
> Sure, it's more clumsy, but it's straightforward.
Which argument leads directly to C++ and Python reigning supreme as the
programming languages in areas like finance where fixed point is needed.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
chris dollin
> On Tue, 2012-02-07 at 13:33 +0000, chris dollin wrote:
>> On 7 February 2012 13:27, Vincent Callanan <vin...@callanan.ie> wrote:
>>
>> > Imagine trying to express the following using a decimal library:
>> >
>> > y = c1 * (d1 + d2 + d3) / (d4 + d5)
>>
>> y = c1.Times(d1.Add(d1).Add(d2).Add(d3)).Div(d4.Add(d5))
>>
>> Sure, it's more clumsy, but it's straightforward.
>
> Which argument leads directly to C++ and Python reigning supreme as the
> programming languages in areas like finance where fixed point is needed.
I was responding to the tone of the previous message which seemed to
suggest that using methods to express the y= expression would be unthinkably
horrible. It isn't. It's just clumsy.
I too would prefer to be able to write arithmetic operations (for some sane
notion of "arithmetic") using infix operator syntax or a close
facsimile. I don't
think you're going to get that into Go for decimals without previous production
of a decent decimal library as a minimum, /unless/ a more general solution
to the "nice infix syntax for methods" issue turns up.
spir
> I stand by my point that, outside of the physical sciences and related
> math disciplines, decimals are far more useful than floats (all other
> things being equal).
decimal vs binary base --both for internal representation?
The only decimal standard I know of (3 formats out of 7 in IEEE 754, see
http://en.wikipedia.org/wiki/IEEE_754-2008) is a floating-point one. See
also and the site on general decimal arithmetic that talks of floating
point only: http://speleotrove.com/decimal/.
Finally, why do these decimal _floating-point_ formats standards
recommand using decimal also for the mantissa (significand)? As far as I
understand, the problem is with the exponent only. Constantly converting
the mantissa to & from binary seems useless to me.
Denis
spir
> On 7 February 2012 13:27, Vincent Callanan<vin...@callanan.ie> wrote:
>
>> Imagine trying to express the following using a decimal library:
>>
>> y = c1 * (d1 + d2 + d3) / (d4 + d5)
> y = c1.Times(d1.Add(d1).Add(d2).Add(d3)).Div(d4.Add(d5))
>
prod(c1, div(sum(d1, d2, d3), sum(d4, d5)))
;-)
Denis
Brandon Peters
Slap a comment with the 'clean' representation over the actual code and call it good:
// y = c1 * (d1 + d2 + d3) / (d4 + d5)
y = c1.Times(d1.Add(d1).Add(d2).Add(d3)).Div(d4.Add(d5))
You guys have sold me on your overall argument but your insistence on "all or nothing" is dooming you to failure. You are complaining about code that hasn't even been written and claiming with utter certainty that it will be too painful to endure. If you really want to prove your point, write the package and then write an application that uses it. Since it will be in Go, it won't take very long. Then come back and show us what was so horrible.
Rob's blog post is incredibly appropriate here.
http://commandcenter.blogspot.com/2011/12/esmereldas-imagination.html
Vincent Callanan
> I agree, indeed. But are you talking of fixed vs floating point, or of
> decimal vs binary base --both for internal representation?
> The only decimal standard I know of (3 formats out of 7 in IEEE 754, see http://en.wikipedia.org/wiki/IEEE_754-2008) is a floating-point one.
have been misleading. Sorry for that and thanks for clearing this up.
I believe ISO/IEC TR 18037[5] is the accepted standard for fixed
precision and, as you say, IEEE 754-2008 relates to floating point
(binary and decimal). Both standards have been implemented in GCC and
hardware support has also been implemented in the microcode of CPUs
used in high end mainframes. This is not rocket science -- the reason
mainstream CPUs do not support these standards is because of the
absence of mainstream software that can take immediate advantage --
not because of the lack of use cases.
The key point I would like to emphasise is that the lack of agreed
standards and underlying compiler support is not an issue for either
fixed or floating point decimals.
Vincent Callanan
arguments about floats or ints?
I don't think so. And what about GO's built-in support for complex
numbers? Is that not a complete contradiciton? Yes, built-in complex
numbers are supported in the C99 standard so it was sort of logical to
include them. But standards-based decimals are also supported in GCC,
so most of the donkey work has already been done for decimals.
As for number crunching, yes, I believe GO will invariably be a very
attractive language in this regard, especially in the cloud where C++
is only really an option for companies who operate their own
infrastructure. While Python is to be commended for its decimal
library, it is a dynamic interpreted language and does not do
concurrency very well.
I confess that I am very biased towards the GO run-time for GAE where
I see huge possibilities for number-crunching compared to the Java and
Python implementations. One only has to consider the possibilities
when using the GAE datastore or SQL back-ends. GO's efficiency can
deliver exceptional response times and enormous cost savings in data
intensive applications.
Paul Borman
But I ask you again, would you or Rob find yourself making the same
arguments about floats or ints?
I don't think so.
And what about GO's built-in support for complex
numbers? Is that not a complete contradiciton?
Robert Johnstone
imagine* that the majority of the code would be mathematical, and then
you end with an allegory about someone with a lack of imagination!
Having written a fair amount of scientific code, the number crunching
is a lot more of 5% of the total (financial applications may be
different).
You are correct that it is certainly possible to write these
applications without operator overloading. By that measure, these
applications can be written in Fortran, Visual Basic, etc.
Notation does have an impact on readability. Unfortunately, we don't
have an objective measure of readability. It is also very difficult
to compare the cost of extending the Go language to the complexity of
the programs users will write. Without these measures, I suspect this
argument will go around and around. In the meantime, the Go
developers are prioritizing those tasks that are important to them,
which is perfectly acceptable.
P.S. Go is not a magic bullet. Just because it is in Go, does not
mean it will be trivial to write.
Vincent Callanan
> Why? A complex number is simply a pair of float32 or float64. It is not a
> new standard per-say.
integers, but I digress :-)
> If you eventually have decimal32 and decimal64 or
> what ever there can be new complex types defined as well (after all, money
> is an imaginary concept :-)
were built-in types :-)
But its not all down to money. There are just some things that money
can't buy. I'm thinking of volts, amps, percentages, metres,
kilograms, degrees, decibels, etc, etc (or to be more "precise", the
way humans and man-made machines usually prefers to define these
quantities).
Gabor
full-hearted support
>
> - Show quoted text -
Guillaume Lescure
Hmm. Go does not have class hierarchies. It has very fast and cheap goroutines (not available in C/C++). It has powerful interfaces. Go gives you the ability to reflect.I think there are many differentiating factors between Go and C/C++. Same with Java and Python (and Go is compiled!) I believe Go is the first language to be able to properly say it is the next generation "C" language (small, simple, easy to understand, efficient (all things C++ is not)).As they say "Try it, you'll like it!"-Paul
I usually said "Sometimes you really need to destroy everything and redo it from scratch to do t better".
I really hope that language will be adopted by a lot of people to continue evolution with a modern fast compiled cross-platform language that is the Go :)
Brandon Peters
Your post is quite ironic. You start off by saying it is *hard to
imagine* that the majority of the code would be mathematical, and then
you end with an allegory about someone with a lack of imagination!
Having written a fair amount of scientific code, the number crunching
is a lot more of 5% of the total (financial applications may be
different).
You are correct that it is certainly possible to write these
applications without operator overloading. By that measure, these
applications can be written in Fortran, Visual Basic, etc.
Notation does have an impact on readability. Unfortunately, we don't
have an objective measure of readability. It is also very difficult
to compare the cost of extending the Go language to the complexity of
the programs users will write. Without these measures, I suspect this
argument will go around and around. In the meantime, the Go
developers are prioritizing those tasks that are important to them,
which is perfectly acceptable.
P.S. Go is not a magic bullet. Just because it is in Go, does not
mean it will be trivial to write.
Ha, you're right, that is pretty funny!
I realize that Go isn't a magic bullet, I was merely trying to point out that Go is far more productive and powerful for all the scaffolding that makes an application usable and robust when compared to C++. Regardless of language, packages and functions that are heavily mathematical are less likely to require change after being written. If applications that use them are anything besides barebones command-line apps, Go is better suited for handling changes in requirements.
As an example, I'm using Go for a 3D CAD visualizer and I therefore rely heavily on linear algebra, both for the data being worked with (the CAD stuff) and the visual representation in OpenGL. My application code still dwarfs the math code, shaders and all (all of which probably accounts for more than 5%). If I have to make sweeping changes to user input or networking, guess which code doesn't have to change? So if I suddenly lost all my builtin operators, the overall impact on my codebase would be negligible.
As you say, notation does have an impact on readability. That is why I care about my main logic being readable and maintainable and not the internals of the packages I use. I have yet to read any of the internals of the math package, a lot of which is done in assembly. Similarly, I do not care how readable the Compound Interest function is in the Money package that John posted earlier in this thread.
Florian Weimer
> - Native dec16, dec32 and dec64 types would be a major selling point
> for GO.
Uhm, doesn't the most widely used decimal type use a sign, a 96-bit
mantissa, and an exponent for the scaling factor (10^0 to 10^-28)?
That would make it dec102 or something like that. It's not exactly
fixed-point, either.
If decimal fixed-point is so important, why are both Excel and
OpenOffice Calc using binary floating-point instead? This is
especially strange since Excel's predecessor, Multiplan, used decimal
floating-point.
Alex Shinn
David's original question had asked "anything other than dollar quantities."
I can understand the argument in that case, because fractional
pennies don't actually exist. This is not true of general measurements,
for which scientific and engineering purposes typically require as
much precision as possible.
--
Alex
Vincent Callanan
decimal and fixed-point decimal, as I clarified in response to a
similar comment on this thread.
As for spreadsheets, I believe that, just like with so much else, we
are prisoners of history/legacy.
For example, with LibreOffice/OpenOffice, decimal precision may be
defined up to twenty places but that is for formatting/input purposes
only because the underlying number appears to be stored as a float.
The general rule-of-thumb is to use an "overly-precise" float and
round it when you need to work with known decimal precision.
Vincent Callanan
On Feb 8, 1:48 am, Alex Shinn <ash...@google.com> wrote:
> David's original question had asked "anything other than dollar quantities."
> I can understand the argument in that case, because fractional
> pennies don't actually exist. This is not true of general measurements,
> for which scientific and engineering purposes typically require as
> much precision as possible.
scientific (and related) apps.
But I would not say exclusively so. I'm sure that built-in decimals
would be a welcome addition to floats even in this domain.
While floats are ideal for modelling inter-planetary systems,
electrical networks or control systems, there are many real world
science/engineering apps where inputs and outputs are specified with
decimal precision and it is desirable to maintain this precision in
many intermediate calculations. For example, voltage thresholds, dc
offsets, input gains, etc may be defined with decimal precision (often
betrayed by the fact that they have string representations) e.g.
"4.50" (V), "2.50" (V), "0.01" (v), "2.5" (dB), etc.
These difficulties arise all the time in software instrumentation and
control. And this extends into medical systems and such like.
Yes, people have found ways of working around this problem but the
fact that they have should not be an indication that all is well.
But I accept your point
Sebastien Binet
> So there I am working on my first Golang project: a clustered data
> processing network service. I've been wanting to get into Golang for a while
> - I just needed a useful project.
>
> And then I get to the part where I need a decimal type. I'm not doing any
> number crunching in this data type. It's just used in some places in the
> output.
>
> Golang is a great language but I'm really disappointed that it doesn't have
> a native decimal type or an arbitrary precision decimal library.
>
> Sure I can use fixed point arithmetic or use floats and be damn careful with
> the rounding but I'd prefer the easy path. You shouldn't have to do stuff
> the hard way unless there's a very good reason.
>
> Are there any plans to do something along these lines?
you mean, having a rational number with arbitrary precision of some sort ?
like this ?
http://golang.org/pkg/math/big/#Rat
:}
-s
a.mat...@ra-micro.de
No!
Mandolyte
Michael Jones
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
michae...@gmail.com
Daniel Theophanes
In one of the many threads about this (five years ago!) I mentioned Mike Colinshaw's excellent work:This is an excellent and correct library. I can be inspiration for a native Go implementation.On Wed, Apr 5, 2017 at 4:51 PM, Mandolyte <ceci...@gmail.com> wrote:Doesn't help with operators, but noticed this:https://www.cockroachlabs.com/blog/apd-arbitrary-precision-decimal-package/
On Wednesday, March 29, 2017 at 1:27:22 PM UTC-4, a.mat...@ra-micro.de wrote:No!We want to use operators like + , - , * and / with decimal values. This is actualy a "No Go" !
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/YczDW-4QMtE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.