http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #20 from Andrei Alexandrescu <andrei@metalanguage.com> 2012-02-01 00:58:00 PST ---
Focus, that's what we lose.

1. There's no real request for cent and ucent.

2. This "let's add a filler doing nothing, discuss it ad nauseam, and consider implement later" is an utter waste of time. If someone really wants they can implement it, don't add this useless filler for hypothetical future-proof libraries that don't exist. This breaks a lot of good principles so badly it hurts.

3. We're better off implementing FixedInt!size for large integers of statically-allocated size. Granted, those don't benefit of all possible optimizations but there's more flexibility.

Please close this and let's leave it closed. Thanks much.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #21 from yebblies <yebblies@gmail.com> 2012-02-01 20:12:24 EST ---
With respect, Andrei, it's my time to waste.

A lot more time has been wasted on arguing about it than the 5 minutes it took for me to make a patch that fixed it.

128 bit integer types have been considered possible enough for D that keywords were reserved for them.  I fully intend to see them implemented if possible.

It seems lately you're frustrated that development effort isn't always directed where you want it, but this is unavoidable in open source projects - people will work on what they want to work on.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #22 from Andrei Alexandrescu <andrei@metalanguage.com> 2012-02-01 01:17:09 PST ---
It's great you want to work on this. It's this particular patch that I have difficulty backing: it future proofs code that doesn't exist, for a feature that doesn't exist either, on account of an assumed need. No matter how I frame it it doesn't make any sense.

No response needed - proceed as you wish.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #23 from Stewart Gordon <smjg@iname.com> 2012-02-01 04:21:17 PST ---
(In reply to comment #20)
> 2. This "let's add a filler doing nothing, discuss it ad nauseam, and consider implement later" is an utter waste of time. If someone really wants they can implement it, don't add this useless filler for hypothetical future-proof libraries that don't exist.

So you're waiting for somebody to write a library, built on my first point in comment 9, that doesn't compile because current DMD flags a syntax error?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #24 from Stewart Gordon <smjg@iname.com> 2012-02-01 04:36:09 PST ---
Moreover, when we finally get the types, there will still be users on older compilers (DM or third-party, possibly commercial), even some on platforms for which an up-to-date compiler is not yet available, who can't compile other people's code because it uses syntax that is still illegal in the version they have.  The sooner this issue is dealt with, the less risk of this happening.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #25 from yebblies <yebblies@gmail.com> 2012-02-01 23:44:50 EST ---
(In reply to comment #24)
> Moreover, when we finally get the types, there will still be users on older compilers (DM or third-party, possibly commercial), even some on platforms for which an up-to-date compiler is not yet available, who can't compile other people's code because it uses syntax that is still illegal in the version they have.  The sooner this issue is dealt with, the less risk of this happening.

This is unlikely to ever be a problem.  D2 compilers break enough code (wrong or not) between versions that using one a couple of releases old probably won't compile your code anyway.  Of course, this will hopefully change in the future.

The bigger issue that makes this less of a waste of time is that D compiler with different backends, or running on different backends, may choose not to implement cent/ucent, and if they do this in the parser then the code will be non-portable.  The proposed patch is a much more correct solution to this problem.

Regardless, there is a patch for this issue already out there which is waiting for review.  I don't think discussing it further at this point will achieve anything.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=785


Witold Baryluk <baryluk@smp.if.uj.edu.pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |baryluk@smp.if.uj.edu.pl


--- Comment #26 from Witold Baryluk <baryluk@smp.if.uj.edu.pl> 2012-02-03 01:01:05 PST ---
Hi,

I was waiting for support of this mainly to write generic and more future proof library. As stated I cannot even try conditional compilation using cent/ucent now. Also some platforms allows doing 64bit * 64bit -> full 128bit product, so it could be possible represented in the future as u/cent, which can have some basic arithmetic imlemented (like bitshifting, extracing upper/lower 64-bits). I'm also starting to do some research on FPGAs (with D!) and was wondering if FPGA can augment some functions to main CPU, to add biger arithmetic on demand. Would be good to have this as transparent as possible, so at least I can do:


    static if(is(cent)){
         ...
    }

in my library, or something very similar.

Also it would be good to have in Phobos, a something similar to existing BigInt, but to behave more like normal arithmetic in terms of overflows and integer promotions. For example WideUInt!(32) will be equivalent to uint, WideUInt!(128) will be equivalent to ucent, or emulated using 2xulong, but WideUInt!(256) will probably by just something like BigInt, but with truncation or results (so multiplication, substraction or addition, powers, like WideUInt!(256) *  WideUInt!(256) will return always  WideUInt!(256), never less or more). It sometimes may be wastefull (when value is actually small), but is usefull especially in cryptography (when one wants to treat this 32-bytes of memory as unsigned integer, and also want to be sure time of operation is constant independend of the range or value of operands), like hash, symetric or asymetric encryption. It just makes it easier to use general WideUInt template, which will use hardware support or fallback to the software. Addition and bitwise logic can be easly translated to the SIMD and potential loops statically unrolled at compile time. Also things like multiplication emulation in such software can be done faster, even for big sizes, because library can determine which algorithm (simple, Karatsuba, FFT) is best for particular width at compile time (it also make it possible to depend this choice on size of left and right operand), statically without any runtime checks (big win). Similary for Karatsuba and FFT, optimal structure of recurences can be calculated at compile time by library, removing many conditionals for runtime code and allowing agressive inlineing. I know many of this things can be solved by good JIT compiler and VM (like HotSpot - by specializing code and loops based on runtime constants, and then agressivly optimizing it including unrolling, vectorizing and inlineing calls), but I like to relay more on deterministic behaviour of compiler and statically do as much as possible at compile time.

Is this something a Phobos would like to have? Cryptographer will probably would like to implement own one even if Phobos provides such functionality because I guess Phobos will aim at maximum performance, but Cryptographers will aim at security and lack of side-channel attacks, and this may be contradicting aims (however Crypgrapher can use Phobos WideUInt!(K), and implement own fast and safe powmod(a,b,n), with n=2^K (const, so rather powmod!(K)(a,b)). I think given existing BigInt presence in Phobos it should be relativly easy to add WideInt/WideUInt.

When we are at long types, I have another question/problem about language.

I was wondering if in case of float with quad-preceission, one should use 'real' keyword or something else? I think we should add quadprecision floats (+complex ones) as possibility to the language, to the existing float, and double, for three reasons: they are commonly used in PowerPC (long double, probably not in hardware, but done by most compilers in software), there are some speculations about hardware support for them, and they can be cheply emulated in software using double-double scheme (which isn't exactly equivalent to 128-bit IEEE-754 arithmetic, but have guaranted 107-bits of precision compared to 113-bits of precisions in IEEE-754 quad precision, range is also limited to about 10^308, instead of 10^4932, but this is not a practical limitation in any real application). Some SPARC ISA have reserved bits for quad precission in FPU, also I know on PowerPC some C/Fortran compiler interpretes 'long double' as quad precission, but actually does double-double calculations. Same does probably Sun Studio Compiler on SPARC. I also know that Intel compiler FORTRAN and C does this on Itanium. So one can argue that there is almost no hardware support for quad precission, so this should be leaved in library, using structs and software implementation. But as reality also shows there is demand for quad precission. On the other hand, somebody can say that it is easly possible to syntethize such hardware in FPGA copouled with CPU (ARM) on demand. Just was going to ask, theoretically if some compiler (most probably modified LDC + own LLVM backend) would want to support quad precission, do it need to use new keyword (sic!), like 'quad' and 'cquad', or just use 'real' and 'creal' ?

Sorry for messing with bug report, but was thinking this is discussion is essentially equivalent to 'cent' discussion - future proofing language and libraries.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #27 from Witold Baryluk <baryluk@smp.if.uj.edu.pl> 2012-02-03 01:09:31 PST ---
Just to add some additional context.

I think many CUDA and OpenCL compilers, as well some tools which uses OpenGL/Cg, whetever, when asked to do double calculations actually uses float-float (2x single precission) to have almost same precission of double (49 bits compared to 52 bit of mantisa, which is big win compared to 23 bigs of single precission floats). So it is common to use float-float or double-double schemes actually to boost precission. I know software and library will need much more testing by developer to make sure lack of IEEE-754 comppilance is not a problem in given library or application, but I think D should in theory allow some compiler to diverge from IEEE-754 compilance if user really wants to.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=785


ponce <aliloko@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aliloko@gmail.com


--- Comment #28 from ponce <aliloko@gmail.com> 2012-04-23 13:15:23 PDT ---
I have a mostly working software implementation for cent and ucent. https://github.com/p0nce/gfm/blob/master/math/softcent.d

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #29 from github-bugzilla@puremagic.com 2012-10-28 06:49:27 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/2e70bcac262e879769f3236a05ce9bc46483a429 Issue 785 - Make 'cent' and 'ucent' syntactically valid pending implementation

This adds just enough of cent and ucent to parse, but fail at the semantic stage.  This allows cent and ucent to be used inside version and static if blocks.

https://github.com/D-Programming-Language/dmd/commit/effb4c0885c90158807aa2de98aab0ff92c69a37 Merge pull request #672 from yebblies/issue785

Issue 785 - Make 'cent' and 'ucent' syntactically valid pending implementation

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------