Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #123045 > unrolled thread

High level programming in C

Back to article view | Back to comp.lang.c

Contents

  High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-20 12:14 +0100
    Re: High level programming in C David Brown <david.brown@hesbynett.no> - 2017-11-20 12:52 +0100
      Re: High level programming in C Robert Wessel <robertwessel2@yahoo.com> - 2017-11-20 06:07 -0600
        Re: High level programming in C David Brown <david.brown@hesbynett.no> - 2017-11-20 13:38 +0100
          Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-20 14:23 +0100
            Re: High level programming in C David Brown <david.brown@hesbynett.no> - 2017-11-20 16:56 +0100
            Re: High level programming in C Spiros Bousbouras <spibou@gmail.com> - 2017-11-20 17:14 +0000
              Re: High level programming in C Spiros Bousbouras <spibou@gmail.com> - 2017-11-20 17:21 +0000
    Re: High level programming in C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-11-20 22:45 +0800
    Re: High level programming in C Ian Collins <ian-news@hotmail.com> - 2017-11-21 07:30 +1300
      Re: High level programming in C gazelle@shell.xmission.com (Kenny McCormack) - 2017-11-20 18:32 +0000
        Re: High level programming in C jameskuyper@verizon.net - 2017-11-20 11:05 -0800
          Re: High level programming in C Öö Tiib <ootiib@hot.ee> - 2017-11-20 12:59 -0800
            Re: High level programming in C BGB <cr88192@hotmail.com> - 2017-11-22 10:47 -0600
    Re: High level programming in C fir <profesor.fir@gmail.com> - 2017-11-20 13:17 -0800
      Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 03:26 -0800
        Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-21 14:54 +0100
          Re: High level programming in C scott@slp53.sl.home (Scott Lurndal) - 2017-11-21 14:51 +0000
            Re: High level programming in C David Brown <david.brown@hesbynett.no> - 2017-11-21 16:43 +0100
              Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 07:58 -0800
                Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-21 17:35 +0100
                Re: High level programming in C Spiros Bousbouras <spibou@gmail.com> - 2017-11-21 16:38 +0000
                  Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 08:47 -0800
                    Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-21 17:55 +0100
                      Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 09:06 -0800
                      Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 09:13 -0800
                        Re: High level programming in C Keith Thompson <kst-u@mib.org> - 2017-11-21 11:29 -0800
                          Re: High level programming in C supercat@casperkitty.com - 2017-11-21 11:59 -0800
                            Re: High level programming in C Keith Thompson <kst-u@mib.org> - 2017-11-21 12:52 -0800
                              Re: High level programming in C supercat@casperkitty.com - 2017-11-21 13:43 -0800
                                Re: High level programming in C Keith Thompson <kst-u@mib.org> - 2017-11-21 14:17 -0800
                                  Re: High level programming in C supercat@casperkitty.com - 2017-11-21 15:00 -0800
                              Re: High level programming in C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-11-21 15:17 -0700
                                Re: High level programming in C supercat@casperkitty.com - 2017-11-21 15:09 -0800
                                  Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-22 00:55 +0100
                                Re: High level programming in C "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-21 18:58 -0500
                                  Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-22 01:19 +0100
                                    Re: High level programming in C Spiros Bousbouras <spibou@gmail.com> - 2017-11-22 01:47 +0000
                                  Re: High level programming in C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-11-21 21:48 -0700
                                    Re: High level programming in C Spiros Bousbouras <spibou@gmail.com> - 2017-11-22 07:36 +0000
                                    Re: High level programming in C "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-22 12:45 -0500
                                      Re: High level programming in C supercat@casperkitty.com - 2017-11-22 14:00 -0800
                                        Re: High level programming in C Keith Thompson <kst-u@mib.org> - 2017-11-22 14:25 -0800
                                          Re: High level programming in C supercat@casperkitty.com - 2017-11-22 15:14 -0800
                                            Re: High level programming in C Keith Thompson <kst-u@mib.org> - 2017-11-22 16:08 -0800
                                              Re: High level programming in C supercat@casperkitty.com - 2017-11-23 16:42 -0800
                                                Re: High level programming in C bartc <bc@freeuk.com> - 2017-11-24 01:37 +0000
                                                  Re: High level programming in C supercat@casperkitty.com - 2017-11-24 14:33 -0800
                          Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 16:20 -0800
                          Re: High level programming in C David Brown <david.brown@hesbynett.no> - 2017-11-22 10:39 +0100
                            Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-23 02:59 -0800
                              Re: High level programming in C David Brown <david.brown@hesbynett.no> - 2017-11-23 12:24 +0100
                                Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-23 04:49 -0800
                          Re: High level programming in C scott@slp53.sl.home (Scott Lurndal) - 2017-11-22 15:42 +0000
                            Re: High level programming in C Keith Thompson <kst-u@mib.org> - 2017-11-22 08:57 -0800
                    Re: High level programming in C Keith Thompson <kst-u@mib.org> - 2017-11-21 09:19 -0800
                      Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 09:28 -0800
                    Re: High level programming in C supercat@casperkitty.com - 2017-11-21 09:22 -0800
              Re: High level programming in C scott@slp53.sl.home (Scott Lurndal) - 2017-11-21 16:29 +0000
                Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-21 17:43 +0100
            Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-21 17:40 +0100
              Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 08:52 -0800
                Re: High level programming in C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-11-21 09:28 -0800
                  Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 09:34 -0800
          Re: High level programming in C Robert Wessel <robertwessel2@yahoo.com> - 2017-11-21 11:37 -0600
            Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-21 20:28 +0100
              Re: High level programming in C Spiros Bousbouras <spibou@gmail.com> - 2017-11-21 19:45 +0000
                Re: High level programming in C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-21 11:51 -0800
                Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-21 20:55 +0100
                  Re: High level programming in C Spiros Bousbouras <spibou@gmail.com> - 2017-11-21 20:07 +0000
                    Re: High level programming in C Ian Collins <ian-news@hotmail.com> - 2017-11-22 09:13 +1300
                      Re: High level programming in C scott@slp53.sl.home (Scott Lurndal) - 2017-11-22 15:38 +0000
                    Re: High level programming in C Robert Wessel <robertwessel2@yahoo.com> - 2017-11-21 15:17 -0600
                      Re: High level programming in C Ian Collins <ian-news@hotmail.com> - 2017-11-22 10:25 +1300
                        Re: High level programming in C Robert Wessel <robertwessel2@yahoo.com> - 2017-11-21 15:41 -0600
                    Re: High level programming in C gordonb.fqrzr@burditt.org (Gordon Burditt) - 2017-12-10 21:24 -0600
                      Re: High level programming in C David Kleinecke <dkleinecke@gmail.com> - 2017-12-10 20:03 -0800
                        Re: High level programming in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-11 17:49 +0000
                          Re: High level programming in C David Kleinecke <dkleinecke@gmail.com> - 2017-12-11 10:32 -0800
                            Re: High level programming in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-12 01:33 +0000
                              Re: High level programming in C David Kleinecke <dkleinecke@gmail.com> - 2017-12-11 18:34 -0800
                        Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-12-11 20:09 +0100
                          Re: High level programming in C Keith Thompson <kst-u@mib.org> - 2017-12-11 11:23 -0800
                  Re: High level programming in C David Brown <david.brown@hesbynett.no> - 2017-11-22 11:01 +0100
                Re: High level programming in C antispam@math.uni.wroc.pl - 2017-11-21 20:11 +0000
                Re: High level programming in C David Brown <david.brown@hesbynett.no> - 2017-11-22 10:58 +0100

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#123179

Le 21/11/2017 à 15:51, Scott Lurndal a écrit :
> And two potential cache misses instead of one.   Up to 200 ns
> additional latency.  That's a four-hundred-instruction potential
> bubble in the pipeline.

Terrible.

Should I commit suicide?

Before taking any such measure, I will keep in mind that:

1) The interface object is likely to be in the cache since it is being 
used all the time.

2) This overhead will be there the first time you use the interface 
object. As any object it must be loaded from RAM into the cache. But 
that happens with ALL objects, C++ interface objects also!

So, considering that, my suicide projects were highly exaggerated

:-)

[toc] | [prev] | [next] | [standalone]

#123182

On Tuesday, November 21, 2017 at 2:40:24 PM UTC-2, jacobnavia wrote:
> Le 21/11/2017 à 15:51, Scott Lurndal a écrit :
> > And two potential cache misses instead of one.   Up to 200 ns
> > additional latency.  That's a four-hundred-instruction potential
> > bubble in the pipeline.
> 
> Terrible.
> 
> Should I commit suicide?
> 
> Before taking any such measure, I will keep in mind that:
> 
> 1) The interface object is likely to be in the cache since it is being 
> used all the time.
> 
> 2) This overhead will be there the first time you use the interface 
> object. As any object it must be loaded from RAM into the cache. But 
> that happens with ALL objects, C++ interface objects also!
> 
> So, considering that, my suicide projects were highly exaggerated
> 

The point is why someone is going to use this instead of C++ STL?

If someone ask the same question for me today
"why are you using C instead of C++?" 
I will say..
Yes I know..it's hard to create containers in C. I have created
a tool to do this repetitive job for me.
In C, on the other hand I have a lot of control and I can create 
good containers even faster than STL. 

[toc] | [prev] | [next] | [standalone]

#123188

On Tuesday, November 21, 2017 at 4:52:59 PM UTC, Thiago Adams wrote:
> 
> If someone ask the same question for me today
> "why are you using C instead of C++?" 
> I will say..
> Yes I know..it's hard to create containers in C. I have created
> a tool to do this repetitive job for me.
> In C, on the other hand I have a lot of control and I can create 
> good containers even faster than STL.
>
I've got  a red black tree I wrote for my books "Basic Algorithms"
and still use. But it's a nuisance. Red black trees are too difficult to 
just knock up as the need arises.
A standard or de-facto standard, like C++ STL "set" has a lot of
advantages.

[toc] | [prev] | [next] | [standalone]

#123190

On Tuesday, November 21, 2017 at 3:28:27 PM UTC-2, Malcolm McLean wrote:
> On Tuesday, November 21, 2017 at 4:52:59 PM UTC, Thiago Adams wrote:
> > 
> > If someone ask the same question for me today
> > "why are you using C instead of C++?" 
> > I will say..
> > Yes I know..it's hard to create containers in C. I have created
> > a tool to do this repetitive job for me.
> > In C, on the other hand I have a lot of control and I can create 
> > good containers even faster than STL.
> >
> I've got  a red black tree I wrote for my books "Basic Algorithms"
> and still use. But it's a nuisance. Red black trees are too difficult to 
> just knock up as the need arises.
> A standard or de-facto standard, like C++ STL "set" has a lot of
> advantages.

I consider the container creation an open issue in C programming.
It is one of the first things I try to solve with my generator.

[toc] | [prev] | [next] | [standalone]

#123191

On Tue, 21 Nov 2017 14:54:08 +0100, jacobnavia
<jacob@jacob.remcomp.fr> wrote:

>Le 21/11/2017 à 12:26, Thiago Adams a écrit :
>> However, the reason I don't want to use this library is because of
>> the design that uses function pointers instead of direct function calls
>> and this probably causes some performance problem compared with C++ STL.
>> One reason, (not the only reason) I use C instead of C++ is performance.
>
>This is completely bogus. The difference betweeen a direct call and an 
>indirect call is just a single memory read.
>
>There is a bit of pipelnine turbulence since indirect calls can't be 
>forecasted by the speculative execution hardware.
>`
>In a modern PC this isn't even measurable.


Most modern, large, CPUs do predict indirect branches.  If successful,
the overhead is, indeed, low.  If not, they tend to be quite
expensive.  Which it's going to be is rather dependent on the code. As
is how much practical impact that extra cost has.

One of the advantages the STL has is that much of that code can be
inlined.  Eliminating any sort of call, as well as allowing the
compiler to optimize across the call boundaries.  Now theoretically a
C compiler can do so as well, at least with static calls and indirect
calls that can be specialized at compile time, even across module
boundaries if it supports LTCG, and has access to the source (or
semi-compiled form) of the library.  We've discussed that before.

https://groups.google.com/d/msg/comp.lang.c/6n8kh4Z2mMo/kIhh8xBrBQAJ

As a practical matter, C++ STL-like things do seem to actually get
inlined rather more frequently.

[toc] | [prev] | [next] | [standalone]

#123193

Le 21/11/2017 à 18:37, Robert Wessel a écrit :
>   We've discussed that before.

Of course, a thousand times.

In another matter, I am implementing ARM64 128 bit maths. It is quite 
difficult, since there aren't any 128 bit ops, except multiply, that 
gives you the higher 64 bits. It is still very embryonary but I have 
managed the four operations (division and modulous call assembler routines)

I am running at 76% of fully optimized gcc in normal code.

[toc] | [prev] | [next] | [standalone]

#123195

On Tue, 21 Nov 2017 20:28:32 +0100
jacobnavia <jacob@jacob.remcomp.fr> wrote:
> In another matter, I am implementing ARM64 128 bit maths. It is quite 
> difficult, since there aren't any 128 bit ops, except multiply, that 
> gives you the higher 64 bits. It is still very embryonary but I have 
> managed the four operations (division and modulous call assembler routines)

If one wants 128 bit (or above) maths why wouldn't they use the GNU
multiprecision library ?

> I am running at 76% of fully optimized gcc in normal code.

What are you measuring and what mathematical operation between the two
gives 76% ?

[toc] | [prev] | [next] | [standalone]

#123197

On Tuesday, November 21, 2017 at 2:45:13 PM UTC-5, Spiros Bousbouras wrote:
> On Tue, 21 Nov 2017 20:28:32 +0100
> jacobnavia <jacob@jacob.remcomp.fr> wrote:
> > In another matter, I am implementing ARM64 128 bit maths. It is quite 
> > difficult, since there aren't any 128 bit ops, except multiply, that 
> > gives you the higher 64 bits. It is still very embryonary but I have 
> > managed the four operations (division and modulous call assembler routines)
> 
> If one wants 128 bit (or above) maths why wouldn't they use the GNU
> multiprecision library ?

There's an alternative library that uses 128-bit and 256-bit on real
FPU hardware.  It's called the quad-double library:

    See the QD section:
    http://crd-legacy.lbl.gov/~dhbailey/mpdist/

> > I am running at 76% of fully optimized gcc in normal code.
> 
> What are you measuring and what mathematical operation between the two
> gives 76% ?

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#123199

Le 21/11/2017 à 20:45, Spiros Bousbouras a écrit :
> On Tue, 21 Nov 2017 20:28:32 +0100
> jacobnavia <jacob@jacob.remcomp.fr> wrote:
>> In another matter, I am implementing ARM64 128 bit maths. It is quite
>> difficult, since there aren't any 128 bit ops, except multiply, that
>> gives you the higher 64 bits. It is still very embryonary but I have
>> managed the four operations (division and modulous call assembler routines)
> 
> If one wants 128 bit (or above) maths why wouldn't they use the GNU
> multiprecision library ?
> 

Because GNU multiple precision library is a multiple precision library 
and my 128 bit maths are fixed, so MUCH faster than a multi precision 
library.

A second reason is that they could like lcc rather than gcc, but I do 
not want to offense your religious feelings

:-)

>> I am running at 76% of fully optimized gcc in normal code.
> 
> What are you measuring and what mathematical operation between the two
> gives 76% ?
> 

All of them, I posted the results about a month ago in this group. The 
test bed is the code of the lcc compiler itself.

I compile the lcc compiler with gnu, then I use the generated compiler 
to compile the source code of lcc two times.

The first one is using the compiler generated with gcc, the second is 
using the compiler generated by lcc itself.

That gives around 75% for lcc. I am trying to improve that, but it is 
very difficult. Gcc is a very good compiler.

jacob

[toc] | [prev] | [next] | [standalone]

#123202

On Tue, 21 Nov 2017 20:55:19 +0100
jacobnavia <jacob@jacob.remcomp.fr> wrote:
> Le 21/11/2017 à 20:45, Spiros Bousbouras a écrit :
> > On Tue, 21 Nov 2017 20:28:32 +0100
> > jacobnavia <jacob@jacob.remcomp.fr> wrote:
> >> In another matter, I am implementing ARM64 128 bit maths. It is quite
> >> difficult, since there aren't any 128 bit ops, except multiply, that
> >> gives you the higher 64 bits. It is still very embryonary but I have
> >> managed the four operations (division and modulous call assembler routines)
> > 
> > If one wants 128 bit (or above) maths why wouldn't they use the GNU
> > multiprecision library ?
> > 
> 
> Because GNU multiple precision library is a multiple precision library 
> and my 128 bit maths are fixed, so MUCH faster than a multi precision 
> library.

Are there applications where one wants 128 bit (integer ?) mathematics
but not above ?

> A second reason is that they could like lcc rather than gcc, but I do 
> not want to offense your religious feelings

Doesn't  lcc  work with GNU multiprecision library ?

> >> I am running at 76% of fully optimized gcc in normal code.
> > 
> > What are you measuring and what mathematical operation between the two
> > gives 76% ?
> > 
> 
> All of them, I posted the results about a month ago in this group. The 
> test bed is the code of the lcc compiler itself.
> 
> I compile the lcc compiler with gnu, then I use the generated compiler 
> to compile the source code of lcc two times.
> 
> The first one is using the compiler generated with gcc, the second is 
> using the compiler generated by lcc itself.
> 
> That gives around 75% for lcc. I am trying to improve that, but it is 
> very difficult. Gcc is a very good compiler.

So if X is the time  lcc  compiled with  gcc  takes to compile  lcc
and   Y is the time  lcc  compiled with  lcc  takes to compile  lcc
then  X = 76/100 * Y , is that what you're saying ?

[toc] | [prev] | [next] | [standalone]

#123204

On 11/22/2017 09:07 AM, Spiros Bousbouras wrote:
> 
> Are there applications where one wants 128 bit (integer ?) mathematics
> but not above ?

Crypto? Hash generation?

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#123303

Ian Collins <ian-news@hotmail.com> writes:
>On 11/22/2017 09:07 AM, Spiros Bousbouras wrote:
>> 
>> Are there applications where one wants 128 bit (integer ?) mathematics
>> but not above ?
>
>Crypto? Hash generation?

Both of which have direct instructions on both x86 (32/64) and ARM (32/64).

[toc] | [prev] | [next] | [standalone]

#123215

On Tue, 21 Nov 2017 20:07:45 GMT, Spiros Bousbouras <spibou@gmail.com>
wrote:

>On Tue, 21 Nov 2017 20:55:19 +0100
>jacobnavia <jacob@jacob.remcomp.fr> wrote:
>> Le 21/11/2017 à 20:45, Spiros Bousbouras a écrit :
>> > On Tue, 21 Nov 2017 20:28:32 +0100
>> > jacobnavia <jacob@jacob.remcomp.fr> wrote:
>> >> In another matter, I am implementing ARM64 128 bit maths. It is quite
>> >> difficult, since there aren't any 128 bit ops, except multiply, that
>> >> gives you the higher 64 bits. It is still very embryonary but I have
>> >> managed the four operations (division and modulous call assembler routines)
>> > 
>> > If one wants 128 bit (or above) maths why wouldn't they use the GNU
>> > multiprecision library ?
>> > 
>> 
>> Because GNU multiple precision library is a multiple precision library 
>> and my 128 bit maths are fixed, so MUCH faster than a multi precision 
>> library.
>
>Are there applications where one wants 128 bit (integer ?) mathematics
>but not above ?


Computations involving currency.  While 64-bits is sufficient in
almost all cases to *store* currency values, it's distressingly easy
to overflow 64-bit intermediate results.

Cobol pre-2002* required 18-digit storage formats (typically
implemented as 64-bit, if the representation is binary), with larger,
as necessary, intermediates.  IOW:

  COMPUTE A = B * C * D.

where all the fields have several decimal places (say a
dollar-and-cents value multiplied by a couple of percentages), doesn't
overflow unless the scaled result won't fit in A (even if the
intermediate results would overflow a 64-bit field).

Even then, 128-bit intermediates don't handle all the cases, but
they're rare enough that you could use 128-bit support as a generally
useful form for dealing with currency.


*They decided to require 36-digits after that, and operations
involving those can require intermediate results larger than that
(somewhat simplified).


>> A second reason is that they could like lcc rather than gcc, but I do 
>> not want to offense your religious feelings
>
>Doesn't  lcc  work with GNU multiprecision library ?


If it doesn't, I'm sure the required changes would be small.  But
using GMP from C requires doing arithmetic via function calls, not the
usual operators.  In the case of lcc, where operator overloading is an
extension, I'd expect that you could write overloads for the GMP
functions.


>> >> I am running at 76% of fully optimized gcc in normal code.
>> > 
>> > What are you measuring and what mathematical operation between the two
>> > gives 76% ?
>> > 
>> 
>> All of them, I posted the results about a month ago in this group. The 
>> test bed is the code of the lcc compiler itself.
>> 
>> I compile the lcc compiler with gnu, then I use the generated compiler 
>> to compile the source code of lcc two times.
>> 
>> The first one is using the compiler generated with gcc, the second is 
>> using the compiler generated by lcc itself.
>> 
>> That gives around 75% for lcc. I am trying to improve that, but it is 
>> very difficult. Gcc is a very good compiler.
>
>So if X is the time  lcc  compiled with  gcc  takes to compile  lcc
>and   Y is the time  lcc  compiled with  lcc  takes to compile  lcc
>then  X = 76/100 * Y , is that what you're saying ?

[toc] | [prev] | [next] | [standalone]

#123218

On 11/22/2017 10:17 AM, Robert Wessel wrote:
> On Tue, 21 Nov 2017 20:07:45 GMT, Spiros Bousbouras <spibou@gmail.com>
> wrote:
> 
>> On Tue, 21 Nov 2017 20:55:19 +0100
>> jacobnavia <jacob@jacob.remcomp.fr> wrote:
>>> Le 21/11/2017 à 20:45, Spiros Bousbouras a écrit :
>>>> On Tue, 21 Nov 2017 20:28:32 +0100
>>>> jacobnavia <jacob@jacob.remcomp.fr> wrote:
>>>>> In another matter, I am implementing ARM64 128 bit maths. It is quite
>>>>> difficult, since there aren't any 128 bit ops, except multiply, that
>>>>> gives you the higher 64 bits. It is still very embryonary but I have
>>>>> managed the four operations (division and modulous call assembler routines)
>>>>
>>>> If one wants 128 bit (or above) maths why wouldn't they use the GNU
>>>> multiprecision library ?
>>>>
>>>
>>> Because GNU multiple precision library is a multiple precision library
>>> and my 128 bit maths are fixed, so MUCH faster than a multi precision
>>> library.
>>
>> Are there applications where one wants 128 bit (integer ?) mathematics
>> but not above ?
> 
> 
> Computations involving currency.  While 64-bits is sufficient in
> almost all cases to *store* currency values, it's distressingly easy
> to overflow 64-bit intermediate results.

Especially if you ware dealing with Zimbabwe dollars!

:)

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#123221

On Wed, 22 Nov 2017 10:25:36 +1300, Ian Collins <ian-news@hotmail.com>
wrote:

>On 11/22/2017 10:17 AM, Robert Wessel wrote:
>> On Tue, 21 Nov 2017 20:07:45 GMT, Spiros Bousbouras <spibou@gmail.com>
>> wrote:
>> 
>>> On Tue, 21 Nov 2017 20:55:19 +0100
>>> jacobnavia <jacob@jacob.remcomp.fr> wrote:
>>>> Le 21/11/2017 à 20:45, Spiros Bousbouras a écrit :
>>>>> On Tue, 21 Nov 2017 20:28:32 +0100
>>>>> jacobnavia <jacob@jacob.remcomp.fr> wrote:
>>>>>> In another matter, I am implementing ARM64 128 bit maths. It is quite
>>>>>> difficult, since there aren't any 128 bit ops, except multiply, that
>>>>>> gives you the higher 64 bits. It is still very embryonary but I have
>>>>>> managed the four operations (division and modulous call assembler routines)
>>>>>
>>>>> If one wants 128 bit (or above) maths why wouldn't they use the GNU
>>>>> multiprecision library ?
>>>>>
>>>>
>>>> Because GNU multiple precision library is a multiple precision library
>>>> and my 128 bit maths are fixed, so MUCH faster than a multi precision
>>>> library.
>>>
>>> Are there applications where one wants 128 bit (integer ?) mathematics
>>> but not above ?
>> 
>> 
>> Computations involving currency.  While 64-bits is sufficient in
>> almost all cases to *store* currency values, it's distressingly easy
>> to overflow 64-bit intermediate results.
>
>Especially if you ware dealing with Zimbabwe dollars!
>
>:)


Assuming we're not talking about (the new-ish) Zimbabwean Bond Notes,
rather the now demonetized third or fourth Zimbabwean dollars... In
that case 64-bits was insufficient even as a storage format.  Cobol
does actually have a reverse scaling feature for dealing with things
like that, though.  So you could define a field as:

  PIC 9(9)P(12)

And you'd get nine digits (~32 bits) and twelve implied zeros, all
storable in a 32 bit binary number.

[toc] | [prev] | [next] | [standalone]

#124121

> Are there applications where one wants 128 bit (integer ?) mathematics
> but not above ?

Maybe.  Most of the math might fit in integers fine (e.g. currency
transaction amounts, which for the USA might be in integer quantities
of cents), but some of it needs additional percentages to do accurate
rounding (e.g.  sales tax calculations, where the sales tax might
be 7.625% = 7625 / 100000, or interest on loans ).

For this it helps to have a function (or inline code pattern for
the compiler) which multiplies two 64-bit numbers and divides by a
64-bit number to give a 64-bit result with correct rounding.  (Note
using different numbers (likely powers of 10) in the denominator,
adjusting the numerator accordingly, may give different rounding,
and which you need to use is probably determined by law).  You need
128 bits for the intermediate result.  This allows for the possibility
that you might have to compute sales taxes (or real estate taxes)
on large areas of real estate, say, Earth, or very expensive military
weapons systems.

This might not cover *all* of the math you need for handling currency,
but it might cover enough for some applications.

[toc] | [prev] | [next] | [standalone]

#124123

On Sunday, December 10, 2017 at 7:24:21 PM UTC-8, Gordon Burditt wrote:
> > Are there applications where one wants 128 bit (integer ?) mathematics
> > but not above ?
> 
> Maybe.  Most of the math might fit in integers fine (e.g. currency
> transaction amounts, which for the USA might be in integer quantities
> of cents), but some of it needs additional percentages to do accurate
> rounding (e.g.  sales tax calculations, where the sales tax might
> be 7.625% = 7625 / 100000, or interest on loans ).
> 
> For this it helps to have a function (or inline code pattern for
> the compiler) which multiplies two 64-bit numbers and divides by a
> 64-bit number to give a 64-bit result with correct rounding.  (Note
> using different numbers (likely powers of 10) in the denominator,
> adjusting the numerator accordingly, may give different rounding,
> and which you need to use is probably determined by law).  You need
> 128 bits for the intermediate result.  This allows for the possibility
> that you might have to compute sales taxes (or real estate taxes)
> on large areas of real estate, say, Earth, or very expensive military
> weapons systems.
> 
> This might not cover *all* of the math you need for handling currency,
> but it might cover enough for some applications.

One way to get involved with large integers is to try to
build an API for rational numbers. So far as I know there
is none readily available. But conceptually the job is
rather easy. I know of no "practical" problems that require
a solution in rationals and that probably explains why they
get no attention from programmers.

[toc] | [prev] | [next] | [standalone]

#124149

David Kleinecke <dkleinecke@gmail.com> writes:

> On Sunday, December 10, 2017 at 7:24:21 PM UTC-8, Gordon Burditt wrote:
>> > Are there applications where one wants 128 bit (integer ?) mathematics
>> > but not above ?
>> 
>> Maybe.  Most of the math might fit in integers fine (e.g. currency
>> transaction amounts, which for the USA might be in integer quantities
>> of cents), but some of it needs additional percentages to do accurate
>> rounding (e.g.  sales tax calculations, where the sales tax might
>> be 7.625% = 7625 / 100000, or interest on loans ).
>> 
>> For this it helps to have a function (or inline code pattern for
>> the compiler) which multiplies two 64-bit numbers and divides by a
>> 64-bit number to give a 64-bit result with correct rounding.  (Note
>> using different numbers (likely powers of 10) in the denominator,
>> adjusting the numerator accordingly, may give different rounding,
>> and which you need to use is probably determined by law).  You need
>> 128 bits for the intermediate result.  This allows for the possibility
>> that you might have to compute sales taxes (or real estate taxes)
>> on large areas of real estate, say, Earth, or very expensive military
>> weapons systems.
>> 
>> This might not cover *all* of the math you need for handling currency,
>> but it might cover enough for some applications.
>
> One way to get involved with large integers is to try to
> build an API for rational numbers. So far as I know there
> is none readily available.

Maybe you mean something else, but I think are a quite a few.  GMP is
widely used but there are others.  And they are built into some
programming languages.

> But conceptually the job is
> rather easy. I know of no "practical" problems that require
> a solution in rationals and that probably explains why they
> get no attention from programmers.

Computer algebra systems need them.

For general numerical work, they suffer from the fact that they can grow
to use a lot of storage quite quickly (even when the rational value
remains small).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#124157

On Monday, December 11, 2017 at 9:49:46 AM UTC-8, Ben Bacarisse wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> 
> > On Sunday, December 10, 2017 at 7:24:21 PM UTC-8, Gordon Burditt wrote:
> >> > Are there applications where one wants 128 bit (integer ?) mathematics
> >> > but not above ?
> >> 
> >> Maybe.  Most of the math might fit in integers fine (e.g. currency
> >> transaction amounts, which for the USA might be in integer quantities
> >> of cents), but some of it needs additional percentages to do accurate
> >> rounding (e.g.  sales tax calculations, where the sales tax might
> >> be 7.625% = 7625 / 100000, or interest on loans ).
> >> 
> >> For this it helps to have a function (or inline code pattern for
> >> the compiler) which multiplies two 64-bit numbers and divides by a
> >> 64-bit number to give a 64-bit result with correct rounding.  (Note
> >> using different numbers (likely powers of 10) in the denominator,
> >> adjusting the numerator accordingly, may give different rounding,
> >> and which you need to use is probably determined by law).  You need
> >> 128 bits for the intermediate result.  This allows for the possibility
> >> that you might have to compute sales taxes (or real estate taxes)
> >> on large areas of real estate, say, Earth, or very expensive military
> >> weapons systems.
> >> 
> >> This might not cover *all* of the math you need for handling currency,
> >> but it might cover enough for some applications.
> >
> > One way to get involved with large integers is to try to
> > build an API for rational numbers. So far as I know there
> > is none readily available.
> 
> Maybe you mean something else, but I think are a quite a few.  GMP is
> widely used but there are others.  And they are built into some
> programming languages.
> 
> > But conceptually the job is
> > rather easy. I know of no "practical" problems that require
> > a solution in rationals and that probably explains why they
> > get no attention from programmers.
> 
> Computer algebra systems need them.
> 
> For general numerical work, they suffer from the fact that they can grow
> to use a lot of storage quite quickly (even when the rational value
> remains small).

Serves me right for not researching a "fact" before asserting it.
My bad.

But per your last paragraph my point remains valid.

[toc] | [prev] | [next] | [standalone]

#124201

David Kleinecke <dkleinecke@gmail.com> writes:

> On Monday, December 11, 2017 at 9:49:46 AM UTC-8, Ben Bacarisse wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
<snip>
>> > One way to get involved with large integers is to try to
>> > build an API for rational numbers. So far as I know there
>> > is none readily available.
<snip>
>> > But conceptually the job is
>> > rather easy. I know of no "practical" problems that require
>> > a solution in rationals and that probably explains why they
>> > get no attention from programmers.
>> 
>> Computer algebra systems need them.
>> 
>> For general numerical work, they suffer from the fact that they can grow
>> to use a lot of storage quite quickly (even when the rational value
>> remains small).
<snip>
> But per your last paragraph my point remains valid.

Then I don't think I get what your point is.  I don't see how the fact
that they are not generally the right solution relates to them getting
no attention from programmers.  (I admit I'm guessing, but can't see how
my last paragraph relates to the other point at all.)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web