Delphi 64 Bit released just in time for Windows to be 128 Bit ...

Ok - the title is a little provocative - but it might be close ;)
This link is to an article the claims that the next Windows version
will be 128 Bit.  Which would be Win8 - and if not that version then
definitely Win 9.
http://arstechnica.com/microsoft/news/2009/10/microsoft-mulling-128-bit-versions-of-windows-8-windows-9.ars
I realize that Delphi 64 bit should be out this year (or so I hope!) -
and that the next windows is a few years away - but I hope the folks
at Emb. are already planning for the 128 version when they do the 64
bit version...

Bradley MacDonald
brad_AT_timeacct_DOT_com
0
Bradley
10/8/2009 1:58:27 PM
📁 embarcadero.delphi.non-tech
📃 5933 articles.
⭐ 1 followers.

💬 148 Replies
👁️‍🗨️ 1638 Views


"Bradley MacDonald" <bradsub@timeacct.com> wrote in message 
news:170569@forums.codegear.com...
> Ok - the title is a little provocative - but it might be close ;)
>
> This link is to an article the claims that the next Windows version
> will be 128 Bit.  Which would be Win8 - and if not that version then
> definitely Win 9.
> http://arstechnica.com/microsoft/news/2009/10/microsoft-mulling-128-bit-versions-of-windows-8-windows-9.ars
>
> I realize that Delphi 64 bit should be out this year (or so I hope!) -
> and that the next windows is a few years away - but I hope the folks
> at Emb. are already planning for the 128 version when they do the 64
> bit version...
Why? If Win128 runs Win32 and Win64 apps just fine, like the way Win64 runs 
32-bit apps justfine, and with up to 4MB of RAM, why would it make any 
difference to the majority of users or developers whether or not their apps 
were 128-bit? Especially since no consumers are currently even using 128-bit 
machines.
0
John
10/8/2009 2:52:37 PM
John Jacobson wrote:
> "Bradley MacDonald" <bradsub@timeacct.com> wrote in message 
> news:170569@forums.codegear.com...
>> Ok - the title is a little provocative - but it might be close ;)
>>
>> This link is to an article the claims that the next Windows version
>> will be 128 Bit.  Which would be Win8 - and if not that version then
>> definitely Win 9.
>> http://arstechnica.com/microsoft/news/2009/10/microsoft-mulling-128-bit-versions-of-windows-8-windows-9.ars
>>
>> I realize that Delphi 64 bit should be out this year (or so I hope!) -
>> and that the next windows is a few years away - but I hope the folks
>> at Emb. are already planning for the 128 version when they do the 64
>> bit version...
> 
> Why? If Win128 runs Win32 and Win64 apps just fine, like the way Win64 runs 
> 32-bit apps justfine, and with up to 4MB of RAM, why would it make any 
> difference to the majority of users or developers whether or not their apps 
> were 128-bit? Especially since no consumers are currently even using 128-bit 
> machines.
Is a 128-bit "end-user" processor available yet?
0
Olivier
10/8/2009 2:55:29 PM
>Is a 128-bit "end-user" processor available yet?
I think that the graphics processors these days are 128 bit, or maybe
more like 256?  There is no IA-128 as yet.
0
Paul
10/8/2009 3:24:25 PM
John,
>> This link is to an article the claims that the next Windows version
>> will be 128 Bit.  Which would be Win8 - and if not that version then
>> definitely Win 9.
>> http://arstechnica.com/microsoft/news/2009/10/microsoft-mulling-128-bit-versions-of-windows-8-windows-9.ars
>>
>> I realize that Delphi 64 bit should be out this year (or so I hope!) -
>> and that the next windows is a few years away - but I hope the folks
>> at Emb. are already planning for the 128 version when they do the 64
>> bit version...
>
> Why? If Win128 runs Win32 and Win64 apps just fine, like the way Win64 runs
> 32-bit apps justfine, and with up to 4MB of RAM, why would it make any
> difference to the majority of users or developers whether or not their apps
> were 128-bit?
if. Win64 does not run Win16 apps. so its entirely possible that Win128 
would drop support for Win32. (if only to avoid having a second 
SysWow128 folder and three versions of "Program Files" ;P).
But then, the whole x64 strategy on Windows is a mess(compared to, say, 
OS X), so who knows...
> Especially since no consumers are currently even using 128-bit
> machines.
True. i'd be surprised if 128-bit becomes relevant for anyone beyond 
high-end data centers, anytime soon. </famous last words ;->.
0
marc
10/8/2009 3:38:25 PM
> {quote:title=Bradley MacDonald wrote:}{quote}
> Ok - the title is a little provocative - but it might be close ;)
> 
> This link is to an article the claims that the next Windows version
> will be 128 Bit.  Which would be Win8 - and if not that version then
> definitely Win 9.
> http://arstechnica.com/microsoft/news/2009/10/microsoft-mulling-128-bit-versions-of-windows-8-windows-9.ars
> 
> I realize that Delphi 64 bit should be out this year (or so I hope!) -
> and that the next windows is a few years away - but I hope the folks
> at Emb. are already planning for the 128 version when they do the 64
> bit version...
I don't think that's going to go anywhere.  There's no need for 128-bit
architecture until we start hitting the limits of 64-bit, and most apps
these days don't even feel squeezed inside a 32-bit address space.
Plus, as a couple people already pointed out, we don't even have 128-bit
CPU yet.  And I haven't heard any talk about Intel or AMD creating
them.
We'll probably end up on 128 eventually, but it's at least a decade
away, probably further.
0
Mason
10/8/2009 3:41:26 PM
Reason #107 to never hire anyone who uses LinkedIn. :)
        [If you don't get it, read the article.]
        -Craig
-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
10/8/2009 3:54:03 PM
Mason Wheeler wrote:
> I don't think that's going to go anywhere.  There's no need for 128-bit
> architecture until we start hitting the limits of 64-bit, and most apps
> these days don't even feel squeezed inside a 32-bit address space.
> Plus, as a couple people already pointed out, we don't even have 128-bit
> CPU yet.  And I haven't heard any talk about Intel or AMD creating
> them.
I doubt the main reason for 128 bit CPUs at this point in time is the 
larger address space, but rather that it makes it possible to operate on 
larger chunks of data on wide bus architectures. There are already CPUs 
with 128 bit wide buses. On server computers that spend most of their 
time just copying data from one place to another (such as from file to 
socket), this would be a major advantage.
0
Utf
10/8/2009 4:07:33 PM
Bradley MacDonald wrote:
> Ok - the title is a little provocative - but it might be close ;)
> 
> This link is to an article the claims that the next Windows version
> will be 128 Bit.  Which would be Win8
I wonder where they will get all those 128 bit processor systems. I
haven't seen any mainstream ones yet.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"I didn't attend the funeral, but I sent a nice letter saying I 
approved of it." -- Mark Twain
0
Rudy
10/8/2009 5:23:37 PM
On 2009-10-08 11:38:25 -0400, marc hoffman <mh@spamobjects.com> said:
> But then, the whole x64 strategy on Windows is a mess(compared to, say,
> OS X), so who knows...
First to decry the OS X FANBOI!
Everything you say is now invalid.  Might as well stop posting now. ;-)
--
Kevin Powick
0
Kevin
10/8/2009 5:23:40 PM
>if. Win64 does not run Win16 apps. so its entirely possible that Win128 
>would drop support for Win32. 
Someday, yes, everything will be obsolete and someday Win32 will be
obsolete.  But, there is just NO CHANCE that any version of Windows
will drop Win32 support in anything less than 10 years.  It won't be
done until:
1.  The vast majority of the apps on the market are 64 bit.
2.  The amount of legacy 32 bit apps running has been reduced to a
manageable "niche", manageable enough that most people won't be hurt
by dropping it.
3.  Legacy 32 bit becomes a significant baggage, something is actually
detrimental to maintain.
When those things happen, let me know.
0
Paul
10/8/2009 5:34:05 PM
>I don't think that's going to go anywhere.  There's no need for 128-bit
>architecture until we start hitting the limits of 64-bit, and most apps
>these days don't even feel squeezed inside a 32-bit address space.
When people start thinking about 128 bit architecture, it will NOT be
for the address space.  It will be to make dealing with larger
operands a natural part of the OS.
0
Paul
10/8/2009 5:36:17 PM
Paul Doland wrote:
>> Is a 128-bit "end-user" processor available yet?
> 
> I think that the graphics processors these days are 128 bit, or maybe
> more like 256?  There is no IA-128 as yet.
Nope, they are 64 bit processors (their operand words are 64 bits) that 
can work on a data bus wider than their instructions.
0
Olivier
10/8/2009 5:43:55 PM
Paul Doland wrote:
> > I don't think that's going to go anywhere.  There's no need for
> > 128-bit architecture until we start hitting the limits of 64-bit,
> > and most apps these days don't even feel squeezed inside a 32-bit
> > address space.
> 
> When people start thinking about 128 bit architecture, it will NOT be
> for the address space.  It will be to make dealing with larger
> operands a natural part of the OS.
Which is probably only useful if you must shovel large sums of data
around. For normal integer algorithms, most of the time an Integer
(Int32) will suffice.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"If everything seems under control, you're just not going fast 
 enough." -- Mario Andretti
0
Rudy
10/8/2009 5:44:42 PM
Kevin,
>> But then, the whole x64 strategy on Windows is a mess(compared to, say,
>> OS X), so who knows...
>
> First to decry the OS X FANBOI!
>
> Everything you say is now invalid.  Might as well stop posting now. ;-)
Obviously ;P
0
marc
10/8/2009 6:52:10 PM
> This link is to an article the claims that the next Windows version
> will be 128 Bit.
No, it won't, at least not for the address space. With 64 bit pointers you can 
address up to 16 billion GB of RAM. Within the next years no personal computer 
will have that much RAM.
Of course more than 64 bits can be used for other things than addressing memory. 
But that doesn't require another platform. In fact even 32 bit CPUs can work 
with more than 32 bit at once (think of MMX and SSE), but not for addressing memory.
Also take a look at the development in the past, here is a table for the Intel CPUs:
year  CPU        bits time span
1974  8080       8    -
1978  8086       16   4 years
1986  80386      32   8 years
2003  Athlon 64  64   16 + 1 years
As you can see the time span doubles. So the first consumer 128 bit CPU will be 
released in 2034 :-)
Isn't that violating Moore's law? No. Doubling the pointer size doesn't just 
double the address space, in fact it's y = 2^2^n (where n is the processor 
generation). So it's quite naturally that new processor generations arrive 
slower and slower.
Eventually we will reach a limit. A 256 bit address space doesn't really make 
sense. With 256 bit you can address 1/10 of the number of atoms existing in our 
universe. Provided that we don't find a way to store bits in a subatomic way, we 
could only build 10 such computers. There wouldn't be enough matter to build more.
Ok, maybe we find a way to store more than one bit per atom. Still it doesn't 
really make sense. It's much better to parallelize. Clock frequencies used to 
get higher exponentially at the beginning, but haven't changed much during the 
last few years. Still CPUs get faster, using more intelligent designs 
(pipelining etc.) and more cores per CPU.
I think it will be similar with the address space. There will be other ways to 
make computers more powerful, for example connecting more of them. You can see 
this today, super computers are based on clusters of many small computers, and 
the internet is our biggest super computer. It holds a lot of information, but 
works with single 32 and 64 bit CPUs. Addressing works differently, URLs instead 
of traditional pointers. It's simply another abstraction layer to make computers 
more powerful. Increasing the address space it kind of archaic.
-- 
Jens Gruschel
http://www.pegtop.net
0
Jens
10/8/2009 7:00:23 PM
> {quote:title=marc hoffman wrote:}{quote}
> if. Win64 does not run Win16 apps. so its entirely possible that Win128 
> would drop support for Win32. (if only to avoid having a second 
> SysWow128 folder and three versions of "Program Files" ;P).
No chance. It took almost 15 years from the introduction of 32 bit Windows (Win95) to drop support for 16-bit apps, and they didn't do it across the board. Windows in 32-bit versions still run 16-bit apps just fine.
> But then, the whole x64 strategy on Windows is a mess(compared to, say, 
> OS X), so who knows...
How so? In what way is OS X better as far as 64-bit strategy?
> True. i'd be surprised if 128-bit becomes relevant for anyone beyond 
> high-end data centers, anytime soon. </famous last words ;->.
I'd change that to "I'd be surprised if 128-bit becomes relevant to more than a handful of users in the next decade or so." :-)
0
Ken
10/8/2009 7:43:28 PM
> around. For normal integer algorithms, most of the time an Integer
> (Int32) will suffice.
No - ever performed fixed-point financial calculations with enough decimals that do not allow losing precision? with an integer you have ten digits, use from four to six for decimals (required by some rules) and your left with six-four digits for the integer part. That's why some of us would like being able to use 64-bit integrer instructions, for example.
Strange, you're a dentist, you should work on numbers large enough... <g>
And there are many other situations that benefits from 64 bit integer arithmetic and would also welcome 128 bit one - look at graphics cards...
0
Luigi
10/8/2009 7:44:58 PM
> And there are many other situations that benefits from 64 bit integer arithmetic and would also welcome 128 bit one - look at graphics cards...
Modern graphic cards tend to use floating point arithmetic. And massive 
parallelization. But I agree, large integer arithmetic is useful to solve 
certain problems.
-- 
Jens Gruschel
http://www.pegtop.net
0
Jens
10/8/2009 7:56:04 PM
Luigi Sandon wrote:
> > around. For normal integer algorithms, most of the time an Integer
> > (Int32) will suffice.
> 
> No - ever performed fixed-point financial calculations with enough
> decimals that do not allow losing precision? with an integer you have
> ten digits, use from four to six for decimals (required by some
> rules) and your left with six-four digits for the integer part.
> That's why some of us would like being able to use 64-bit integrer
> instructions, for example.
        That's not really an integer algorithm, though. That's cramming a
fixed decimal into an integer. I don't think that's what Rudy meant.
-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
10/8/2009 8:01:14 PM
On Thu, 8 Oct 2009 10:44:42 -0700, Rudy Velthuis (TeamB)
<newsgroups@rvelthuis.de> wrote:
>Paul Doland wrote:
>
>> > I don't think that's going to go anywhere.  There's no need for
>> > 128-bit architecture until we start hitting the limits of 64-bit,
>> > and most apps these days don't even feel squeezed inside a 32-bit
>> > address space.
>> 
>> When people start thinking about 128 bit architecture, it will NOT be
>> for the address space.  It will be to make dealing with larger
>> operands a natural part of the OS.
>
>Which is probably only useful if you must shovel large sums of data
>around. For normal integer algorithms, most of the time an Integer
>(Int32) will suffice.
You need int64s for a lot of financial stuff.
int32 maxes out at 2 billion.  Seems like enough?
1)  That's two billion pennies.  20 million dollars.
2)  Now what happens when you need to multiply by a percentage?  It's
30% off--now you'll get overflows at 200 thousand dollars.
It's not hard for a large something to reach 200,000 dollars.
0
Loren
10/8/2009 10:12:59 PM
On Thu, 8 Oct 2009 12:43:28 -0700, Ken White <> wrote:
>> {quote:title=marc hoffman wrote:}{quote}
>> if. Win64 does not run Win16 apps. so its entirely possible that Win128 
>> would drop support for Win32. (if only to avoid having a second 
>> SysWow128 folder and three versions of "Program Files" ;P).
>
>No chance. It took almost 15 years from the introduction of 32 bit Windows (Win95) to drop support for 16-bit apps, and they didn't do it across the board. Windows in 32-bit versions still run 16-bit apps just fine.
Actually it doesn't.
Win9x can run a dos protected mode app with 64mb of memory under
Borland Pascal.  WinXP only gives you 16mb.
0
Loren
10/8/2009 10:12:59 PM
On Thu, 8 Oct 2009 12:00:23 -0700, Jens Gruschel
<jg@pegtopwantsnospam.net> wrote:
>Eventually we will reach a limit. A 256 bit address space doesn't really make 
>sense. With 256 bit you can address 1/10 of the number of atoms existing in our 
>universe. Provided that we don't find a way to store bits in a subatomic way, we 
>could only build 10 such computers. There wouldn't be enough matter to build more.
So?  In 100 years our computers will contain pocket universes! <G>
0
Loren
10/8/2009 10:13:00 PM
Ken,
>> But then, the whole x64 strategy on Windows is a mess(compared to, say,
>> OS X), so who knows...
>
> How so? In what way is OS X better as far as 64-bit strategy?
For one, it doesn't have the mess of Program Files, Program Files (x86), 
System32, SysWOW64 folders, WOW64 registry split for some portions (like 
HKLM\Software) but not others (like HKCU\Software), etc.
On Mac OS X there's one for everything, and thanx to universal binaries, 
any executable can seamlessly be 32bit, 64bit or both and in the latter 
case run in whatever mode fits best). There's no separate sets of 
configurations, or system files, or anything else.
For another, there's not even a need to decide whether to install a 
32bit or 64bit. You install the OS, and it;s as 64bit as it needs to be 
- which, contrary to the FUD being spread, can mean entirely 64bit from 
the kernel up. it can also mean using 32bit where nevcessary (for 
example with the 32bit kernel, if you need ro tun legacy drivers that 
aren't 64bit, without sacrificing the ability to run 64bit apps or 
address all of your 32GB of memory).
 From a developer's perspective, building 64bit apps meant, literally, 
setting the switch to start building for 64bit, in addition to 32bit.
Compare that to Windows, where 64bit is a pain to deal with, even when 
just doing 32bit development, on account of having to deal with all the 
split folders. You're not gonna guess how many man hours have been 
wasted on our side, dealing with something as stupid as having build 
scripts that run ok on both x86 and x64 systems, among other reasons 
because the 32bit Program Files and System folders are named differently 
(and, no, just relying on the proper e nvironment variables is NOT 
always a solution. For example, from MSBuild/x64, there's no way to get 
to 32bit Program Files (without hardcoding it as "C:\Program Files 
(x86)" - which in turn wont work on x86 systems).
>> True. i'd be surprised if 128-bit becomes relevant for anyone beyond
>> high-end data centers, anytime soon.</famous last words ;->.
>
> I'd change that to "I'd be surprised if 128-bit becomes relevant to more than a handful of users in the next decade or so." :-)
agreed.
0
marc
10/8/2009 10:13:29 PM
> So?  In 100 years our computers will contain pocket universes! <G>
I'd say in 100 years everyone in the universe will have a pocket full of 
computers, each having 64 bit :-)
-- 
Jens Gruschel
http://www.pegtop.net
0
Jens
10/8/2009 10:46:42 PM
"Jens Gruschel" wrote:
>> So?  In 100 years our computers will contain pocket universes! <G>
>
> I'd say in 100 years everyone in the universe will have a pocket full of
> computers, each having 64 bit :-)
Already there is one cell phone for each two people on the planet which 
works out to an estimated 3.3 billion cell phones. As computer like mobile 
devices, such as the iPhone, become ubiquitous, their bitness is of less 
concern. :)
0
John
10/8/2009 11:10:42 PM
> Already there is one cell phone for each two people on the planet which 
> works out to an estimated 3.3 billion cell phones. As computer like mobile 
> devices, such as the iPhone, become ubiquitous, their bitness is of less 
> concern. :)
IMO in the future there will be a lot more such devices. And, yes, bits don't 
matter much. Heck, microchips don't matter much, they won't be our last 
invention. What about a quantum computer cell phone?
Hey - Delphi for quantum computers, I like that :-)
P.S. Just kidding, quantum computers are cool, but probably not suitable for 
cell phones...
....which are 64 bit BTW :-)
-- 
Jens Gruschel
http://www.pegtop.net
0
Jens
10/8/2009 11:41:32 PM
Luigi Sandon wrote:
> > around. For normal integer algorithms, most of the time an Integer
> > (Int32) will suffice.
> 
> No - ever performed fixed-point financial calculations with enough
> decimals that do not allow losing precision?
No, but you might be interested in the Decimal type I just finished. 96
bit precision (~29 decimals), decimal floating point type, implemented
in hand-optimized assembler. Might be slow compared to FP, but much
more accurate. Ideal for financial calculations.
> with an integer you have
> ten digits, use from four to six for decimals (required by some
> rules) and your left with six-four digits for the integer part.
> That's why some of us would like being able to use 64-bit integrer
> instructions, for example.
I am not talking about financial fixed or floating point type
algorithms. I am talking about the fact that many calculations and
algorithms get around with integers (unscaled).
 
> Strange, you're a dentist, you should work on numbers large enough...
> <g>
Unfortunately, they all fit in a 32 bit integer. <g>
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"I'm all in favor of keeping dangerous weapons out of the hands 
 of fools. Let's start with typewriters."
-- Frank Lloyd Wright (1868-1959)
0
Rudy
10/9/2009 12:17:31 AM
Craig Stuntz wrote:
> Luigi Sandon wrote:
> 
> > > around. For normal integer algorithms, most of the time an Integer
> > > (Int32) will suffice.
> > 
> > No - ever performed fixed-point financial calculations with enough
> > decimals that do not allow losing precision? with an integer you
> > have ten digits, use from four to six for decimals (required by some
> > rules) and your left with six-four digits for the integer part.
> > That's why some of us would like being able to use 64-bit integrer
> > instructions, for example.
> 
>    That's not really an integer algorithm, though. That's cramming a
> fixed decimal into an integer. I don't think that's what Rudy meant.
No.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"The unavoidable price of reliability is simplicity." 
 -- C.A.R. Hoare
0
Rudy
10/9/2009 12:17:53 AM
"Jens Gruschel" wrote:\
>> Already there is one cell phone for each two people on the planet which
>> works out to an estimated 3.3 billion cell phones. As computer like 
>> mobile
>> devices, such as the iPhone, become ubiquitous, their bitness is of less
>> concern. :)
>
> IMO in the future there will be a lot more such devices. And, yes, bits 
> don't
> matter much.
The battle over who will provide the dominate operating system for these 
billions of new mobile devices is fun to watch. Apple, Google and Microsoft 
are already heavily invested and there is always a slim chance that some 
dark-horse will appear.
If I were the chief scientist for Delphi, I'd quit all this coquettish about 
64-bit and cross platform compilers and focus on grabbing a big share of the 
application development tools market for these new devices.
0
John
10/9/2009 3:04:27 AM
> If I were the chief scientist for Delphi, I'd quit all this coquettish about
> 64-bit and cross platform compilers and focus on grabbing a big share of the
> application development tools market for these new devices.
Delphi Prism and MonoTouch, anyone?
0
marc
10/9/2009 10:39:31 AM
> When people start thinking about 128 bit architecture, it will NOT be
> for the address space.  It will be to make dealing with larger
> operands a natural part of the OS.
Which is already possible with the SIMD processor extensions!
0
Michael
10/9/2009 12:15:24 PM
> Delphi Prism and MonoTouch, anyone?
No. IMHO they are just a waste of resources. Embarcadero should drop Prism and focus on delivery native compilers.
0
Luigi
10/9/2009 12:33:29 PM
>  That's not really an integer algorithm, though. That's cramming a
> fixed decimal into an integer. I don't think that's what Rudy meant.
You can't perform IEEE arithmetic without risks of losing precision - fixed point arithmetic can be done on scaled integers - you can do it in BCD data format, but it is much slower compared to perform it on intergers and scaling the results.
Before telling 32 bits are enough for everyone, I'd use a broader perspective.
0
Luigi
10/9/2009 12:39:47 PM
Hello,
Luigi Sandon wrote:
> IMHO they are just a waste of resources.
kinda hard to justify if Prism is actually profitable :)
-- 
Moritz
"Hey, it compiles! Ship it!"
0
Moritz
10/9/2009 12:46:59 PM
Luigi Sandon wrote:
> You can't perform IEEE arithmetic without risks of losing precision -
> fixed point arithmetic can be done on scaled integers - you can do it
> in BCD data format, but it is much slower compared to perform it on
> intergers and scaling the results.
        I know that, but I think you missed the point of what Rudy was saying.
Nobody's claiming that there's no place for fixed-place decimal
algorithms here, so this is a straw man.
> Before telling 32 bits are enough for everyone, I'd use a broader
> perspective.
        Again, nobody (even Rudy) actually /said/ that. I certainly don't
believe it, and I guess you don't, either, so no need for lectures on
the topic.
-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
10/9/2009 12:56:10 PM
"marc hoffman" wrote:
>> If I were the chief scientist for Delphi, I'd quit all this coquettish 
>> about
>> 64-bit and cross platform compilers and focus on grabbing a big share of 
>> the
>> application development tools market for these new devices.
>
> Delphi Prism and MonoTouch, anyone?
No thank you, I had in mind only development tools that deliver native 
applications for use on these new mobile devices.
BTW: Since I'm a C# programmer, why would I want to use Delphi Prism with 
Mono Touch? :)
0
John
10/9/2009 1:12:48 PM
Luigi Sandon wrote:
> >       That's not really an integer algorithm, though. That's cramming a
> > fixed decimal into an integer. I don't think that's what Rudy meant.
> 
> You can't perform IEEE arithmetic without risks of losing precision
Duh! I knew that:
http://rvelthuis.de/articles/articles-floats.html
What I meant is that for most code that uses integers (which is
probably most code in use), a 32 bit integer will do. There is no big
need for the standard integer to be 64 bit. That does not mean we don't
need 64 bit and perhaps even larger integers sometimes, but for most
code, 32 bit integers will do fine. I guess that is also why MS chose
for the LLP64 model, where integers are still 32 bit.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"The artist is nothing without the gift, but the gift is nothing 
 without work." -- Emile Zola (1840-1902)
0
Rudy
10/9/2009 1:29:38 PM
John,
> No thank you, I had in mind only development tools that deliver native
> applications for use on these new mobile devices.
MonoTouch is native, it produces native ARM code that runs on the device.
> BTW: Since I'm a C# programmer, why would I want to use Delphi Prism with
> Mono Touch? :)
Since you're a C# programmer, why would you wanna use *native* Delphi?
0
marc
10/9/2009 1:53:01 PM
Luigi,
> No. IMHO they are just a waste of resources. Embarcadero should drop Prism and focus on delivery native compilers.

ah, thanx for letting me know. i'll get right on getting the product 
discontinued...
0
marc
10/9/2009 1:53:56 PM
> probably most code in use), a 32 bit integer will do. There is no big
> need for the standard integer to be 64 bit. That does not mean we don't
We just need to define what *big* means.
> code, 32 bit integers will do fine. I guess that is also why MS chose
> for the LLP64 model, where integers are still 32 bit.
As many others, MS made a big mess defining data types - LONG, DWORD, etc, often mapping to same 32 bit data (see for example here: http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx) . AFAIK they choose LLP64 mostly for *compatibility* reasons. From an API perspective, it may make sense. And AFAIK almost anybody else chose the LP64 model instead.
But that does not mean that you don't use 64-bit arithmetics - you just have to define a variable long long or whatever else to tell the compiler you want 64 bit - and I guess even the Windows kernel does.
I am already using Int64 a lot in actual Delphi applications, knowing it would compile in a single fetch and a single instruction instead of two would make me happy. Moreover switching to 64 bit will allow to use more registers and the like, leading to better code optimization if a compiler can take advantage of new features.
0
Luigi
10/9/2009 2:04:43 PM
John Cash
> No thank you, I had in mind only development tools that deliver native 
> applications for use on these new mobile devices.
such as Palm Pre... ;-)
0
Hans
10/9/2009 2:11:58 PM
>  Again, nobody (even Rudy) actually /said/ that. I certainly don't
He said: "For normal integer algorithms, most of the time an Integer (Int32) will suffice"
We have to define what "normal" means. A "for" counter?  An array/list index? Pixel coordinates? Financial data?
Frankly, about the 64 bit topic I see again the same "nondum matura est nolo acerbam sumere" attitude I already saw about Unicode before Delphi 2009. Of course, until D2009 Unicode was almost useless, and noone needed it really. After it was The Greatest Innovation Ever Introduced in Development, and you should switch from D7 just for it. Now the same is happening about 64 bit - just because Delphi has not yet, many said it's not time yet to use it. When they eventually add it, the same will write how can
 you live without it.
0
Luigi
10/9/2009 2:17:20 PM
Luigi Sandon wrote:
> > probably most code in use), a 32 bit integer will do. There is no
> > big need for the standard integer to be 64 bit. That does not mean
> > we don't
> 
> We just need to define what big means.
In day to day code, there is hardly any need for integers that are
larger than 32 bits.
> 
> > code, 32 bit integers will do fine. I guess that is also why MS
> > chose for the LLP64 model, where integers are still 32 bit.
> 
> As many others, MS made a big mess defining data types - LONG, DWORD,
> etc, often mapping to same 32 bit data (see for example here:
> http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx) .
> AFAIK they choose LLP64 mostly for compatibility reasons.
No, they chose it because it is the one that makes most sense, for the
reason I gave. 64 bit integers are hardly ever needed for normal use.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"Statistics is like a bikini. What they reveal is suggestive.
 What they conceal is vital."
 -- Arthur Koestler
0
Rudy
10/9/2009 2:21:40 PM
Rudy has clarified what he meant. If it wasn't clear to you before, I
don't see how you could possibly still be confused. So do you have any
issue with what he *actually* meant, or are you just trying to argue
with yourself?
        Nobody here claimed that 64 bit tools are useless. Nobody. For
example, I stated that if you want to write an xproc for 64-bit SQL
Server, then you need a 64-bit compiler, full stop. But many people
have stated that they are oversold, which, AFAICS, is true. The claim,
made in this thread, that without a 64-bit compiler you cannot access
more than 2 GB (or 3 GB, depending upon who is making it) of memory is
simply wrong.
-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
10/9/2009 2:23:43 PM
Luigi Sandon wrote:
> > probably most code in use), a 32 bit integer will do. There is no
> > big need for the standard integer to be 64 bit. That does not mean
> > we don't
> 
> We just need to define what big means.
> 
> > code, 32 bit integers will do fine. I guess that is also why MS
> > chose for the LLP64 model, where integers are still 32 bit.
> 
> And AFAIK almost anybody else chose the LP64 model instead.
No big difference. Integers are 32 bit in LP64 too. Long integers are
64 bit, though.
 
> But that does not mean that you don't use 64-bit arithmetics - you
> just have to define a variable long long or whatever else to tell the
> compiler you want 64 bit - and I guess even the Windows kernel does.
> 
> I am already using Int64 a lot in actual Delphi applications
Oh? Could you give a typical situation where you'd need it?

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"The purpose of computing is not numbers but insight." 
 -- Richard Hamming
0
Rudy
10/9/2009 2:24:39 PM
"marc hoffman"  wrote:
> John,
>
>> No thank you, I had in mind only development tools that deliver native
>> applications for use on these new mobile devices.
>
> MonoTouch is native, it produces native ARM code that runs on the device.
Yeah, same as .NET framework applications are *native*. ;-)
>> BTW: Since I'm a C# programmer, why would I want to use Delphi Prism with
>> Mono Touch? :)
>
> Since you're a C# programmer, why would you wanna use *native* Delphi?
Being a C# programmer doesn't make me so stupid that I wouldn't want to use 
world's best tool when I want to develop a *native* Windows applications :)
0
John
10/9/2009 2:28:55 PM
John,
>>> No thank you, I had in mind only development tools that deliver native
>>> applications for use on these new mobile devices.
>>
>> MonoTouch is native, it produces native ARM code that runs on the device.
>
> Yeah, same as .NET framework applications are *native*. ;-)
No. not the same at all. but don't let lack of understanding of how 
MonoTouch works come between you and a good flame.
>>> BTW: Since I'm a C# programmer, why would I want to use Delphi Prism with
>>> Mono Touch? :)
>>
>> Since you're a C# programmer, why would you wanna use *native* Delphi?
>
> Being a C# programmer doesn't make me so stupid that I wouldn't want to use
> world's best tool when I want to develop a *native* Windows applications :)
i thought we were talking about mobile devices, not native Windows apps.
0
marc
10/9/2009 2:38:57 PM
>> 
>> I am already using Int64 a lot in actual Delphi applications
>
>Oh? Could you give a typical situation where you'd need it?
Hi Rudy,
I am also using Int64 in a number of my applications.  For example -
in database code - we have tables that are keyed by a single integer
field.  A 32 bit signed integer simply does not have enough possible
numbers in it.  We can have billions of records over a period of 5 or
6 years.  
Also - for my shareware...  I gather information about the sizes of
files on disk - breaking it down into categories.  I have many
customers that go well into the TeraBytes of disk space they want to
scan.   A Integer cannot handle numbers that size.  However, a Int64
can (over 9 Exobytes)
While I agree with you that for most simple things - Integer type will
do.  The days are coming when Int64 will be more common.  Remember -
no one will ever need more than 10 MB of disk space in their computer
;)  

Bradley
0
Bradley
10/9/2009 3:33:50 PM
> As many others, MS made a big mess defining data types - LONG, DWORD, etc, often mapping to same 32 bit data
Absolutely. If I had to define data type names for a new computer language (of 
course it's easier now), I'd use Int8, Int16, Int32, Int64 and one generic 
integer type, that maps to one of these types (just like Delphi has).
> AFAIK they choose LLP64 mostly for *compatibility* reasons. From an API perspective, it may make sense.
There are other reasons, too. 64 bit integers usually are a waste of memory. On 
the other hand memory gets cheaper and cheaper, so that might not be a good 
reason. But for the same reason 64 bit integers can take more time. Not for 
calculations, but when moving them around in memory.
-- 
Jens Gruschel
http://www.pegtop.net
0
Jens
10/9/2009 4:22:49 PM
Rudy Velthuis (TeamB) wrote:
> > I am already using Int64 a lot in actual Delphi applications
> 
> Oh? Could you give a typical situation where you'd need it?
        I use it to map to 64 bit integer identifiers in a DB. That's probably
the single biggest use case for me.
-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
10/9/2009 4:30:08 PM
John Cash wrote:
> > MonoTouch is native, it produces native ARM code that runs on the
> > device.
> 
> Yeah, same as .NET framework applications are native. ;-)
        No, not remotely. .NET assemblies are portable; MonoTouch executables
aren't.
-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
10/9/2009 4:32:13 PM
Craig Stuntz schrieb:
> The claim,
> made in this thread, that without a 64-bit compiler you cannot access
> more than 2 GB (or 3 GB, depending upon who is making it) of memory is
> simply wrong.
Simply? Wrong? Memory?
One can access any amount of *data*, on any platform, limited only by 
external memory (disk) capacity. But a 32 bit virtual address space 
limits direct access to 4 GB of *memory*.
DoDi
0
Hans
10/9/2009 4:40:25 PM
> ah, thanx for letting me know. i'll get right on getting the product 
> discontinued...
Maybe you should warn people you have a personal business interest in pushing Prism, if you're that Hoffman. Maybe adding to your signature you role, because I guess not anybody knows.
0
Luigi
10/9/2009 4:42:52 PM
"marc hoffman" wrote:
> John,
>
>>>> No thank you, I had in mind only development tools that deliver native
>>>> applications for use on these new mobile devices.
>>>
>>> MonoTouch is native, it produces native ARM code that runs on the 
>>> device.
>>
>> Yeah, same as .NET framework applications are *native*. ;-)
>
> No. not the same at all. but don't let lack of understanding of how
> MonoTouch works come between you and a good flame.
I stand corrected but fail to understand why you choose to elevate my 
erroneous criticism into a "good flame". But hey, I can live with it...
>
>>>> BTW: Since I'm a C# programmer, why would I want to use Delphi Prism 
>>>> with
>>>> Mono Touch? :)
>>>
>>> Since you're a C# programmer, why would you wanna use *native* Delphi?
>>
>> Being a C# programmer doesn't make me so stupid that I wouldn't want to 
>> use
>> world's best tool when I want to develop a *native* Windows applications 
>> :)
>
> i thought we were talking about mobile devices, not native Windows apps.
AFAIK  there is no Delphi tool for developing native apps for mobile devices 
since that is exactly what I suggested their R&D folks would excel at. While 
you may differ, I don't really think Delphi Prism with the addition of Mono 
Touch (which costs $399) is a solution likely to l attract lots of new users 
to become Delphi mobile device developers.
0
John
10/9/2009 4:42:57 PM
Hans-Peter Diettrich wrote:
> Simply? Wrong? Memory?
> 
> One can access any amount of data, on any platform, limited only by 
> external memory (disk) capacity. But a 32 bit virtual address space 
> limits direct access to 4 GB of memory.
        Last I checked:
 *  4 <> 3
 *  4 <> 2
 *  Address space <> addressable memory (not just disk, either)
-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
10/9/2009 4:55:18 PM
>He said: "For normal integer algorithms, most of the time an Integer (Int32) will suffice"
FWIW, I fairly often use int64.  I don't honestly know if that is
implented with native 64-bit instructions or not.  I think it can be
with current processors. But, I don't know what Delphi does.  At any
rate, I am quite certain having native 128 bit integer math has
current uses.  But, certainly not for every application.
I don't honestly know what is even being proposed for this "128-bit
Windows".  If it is just to get native 128 bit math, I think that is
more a matter of having the instructions in the processor, not really
an OS issue at all. And I don't think they could possibly be talking
about larger address space.  So, I haven't any idea what a 128-bit
Windows might entail. Can someone enlighten me?
0
Paul
10/9/2009 5:00:03 PM
John Jacobson wrote:
> Why? If Win128 runs Win32 and Win64 apps just fine, like the way Win64 runs 
> 32-bit apps justfine, and with up to 4MB of RAM, why would it make any 
> difference to the majority of users or developers whether or not their apps 
> were 128-bit? Especially since no consumers are currently even using 128-bit 
> machines.
// Message posted October 9, 2019 //
I can't believe you're still programming in 64-bit...

:)
0
Richard
10/9/2009 5:28:40 PM
marc hoffman wrote:
> if. Win64 does not run Win16 apps. so its entirely possible that
> Win128 would drop support for Win32. (if only to avoid having a
> second SysWow128 folder and three versions of "Program Files" ;P).
MS dropped support for Win16 because they didn't have a good way to
switch the processor modes 64<=>16. Depending on what Intel/AMD do,
there's no reason that MS can't continue to support Win32 running XP in
a VM like Windows 7 does, if nothing else.
Mike S.
0
Mike
10/9/2009 6:36:06 PM
Jens Gruschel wrote:
> There are other reasons, too. 64 bit integers usually are a waste of
> memory. On the other hand memory gets cheaper and cheaper, so that
> might not be a good reason. But for the same reason 64 bit integers
> can take more time. Not for calculations, but when moving them around
> in memory.
They also take up valuable cache space. Assuming that the program
doesn't need the extra address space, it's quite possible for a 32 bit
app to be faster than a 64 bit app, simply because it's smaller. (This
was also the case going from 16 to 32 bits on the '386, assuming that
you didn't have to do segment funkiness.)
Mike S.
0
Mike
10/9/2009 6:40:10 PM
> Is a 128-bit "end-user" processor available yet?
You get them in Playstation 3 and XBox 360... they are closer than you think.
0
Luigi
10/9/2009 6:50:19 PM
> what he actually meant, or are you just trying to argue
He actually meant he doesn't need 64 bit  <g> That's why I spoke about a broader perspective. For the matter, many applications could still be code with 8 bit or 16 bit compilers, if you like. I could say that most applications do not need touch support, mine do not, but having worked on many projects before, including a large PoS application, I know it could be a real gift for somebody else. I find a Firebird driver totally useless, but that's does not mean someone does not need it badly.
> made in this thread, that without a 64-bit compiler you cannot access
> more than 2 GB (or 3 GB, depending upon who is making it) of memory is
> simply wrong.
You're going to be a real sophist - you can show white is black if you like, but that's useless.  You can access terabytes RAM with a 8 bit processor, segmentation and paging, if it has enough address lines, but why someone would work that way? Delphi is going to be vey late supporting 64 bit, and telling 64 bit aren't ripe yet like the fox of fable is utterly useless.
0
Luigi
10/9/2009 7:03:12 PM
> No big difference. Integers are 32 bit in LP64 too. Long integers are
> 64 bit, though.
It is - anyway it's due to the somewhat strange C definition of int - _at least_ 16 bit - and long - _at least_ 32 bit, C requires just a lower bound, not a fixed size. 
If ever MS goes 128, bit, I wonder how they define the new type, "long long long"? <g>
> Oh? Could you give a typical situation where you'd need it?
I said it already. To perform fixed point arithmetic without using the far slower BCD encoding. And to exchange data with machines running already 64 bit Linux.
0
Luigi
10/9/2009 7:18:43 PM
Bradley MacDonald wrote:
> >> 
> >> I am already using Int64 a lot in actual Delphi applications
> > 
> > Oh? Could you give a typical situation where you'd need it?
> Hi Rudy,
> 
> I am also using Int64 in a number of my applications.  For example -
> in database code - we have tables that are keyed by a single integer
> field.  A 32 bit signed integer simply does not have enough possible
> numbers in it.  We can have billions of records over a period of 5 or
> 6 years.
Sure. I never said that Int64s were not used, or that they don't have
their utility. Others even use far larger keys. But most integer
algorithms don't need more than 32 bits.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"The graveyards are full of indispensable men."
 -- Charles de Gaulle (1890-1970)
0
Rudy
10/9/2009 7:27:42 PM
Luigi Sandon wrote:
> > No big difference. Integers are 32 bit in LP64 too. Long integers
> > are 64 bit, though.
> 
> It is - anyway it's due to the somewhat strange C definition of int -
> _at least_ 16 bit - and long - _at least_ 32 bit, C requires just a
> lower bound, not a fixed size.
C is very cross-platform. It can't set strict limits on its sizes. That
is als why there are other types in C and C++, like diff_t, size_t,
etc. which depend on the platform too.
But on Win32, you can assume that all such types have the same sizes as
those used by the API and the Microsoft compiler.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"Without requirements or design, programming is the art of
 adding bugs to an empty text file." -- Louis Srygley
0
Rudy
10/9/2009 7:36:27 PM
Luigi Sandon wrote:
> > what he actually meant, or are you just trying to argue
> 
> He actually meant he doesn't need 64 bit  <g>
Then you really didn't understand. I said that making Integer 64 bit is
useless. Even in a Delphi for Win64 or any other 64 bit OS, a 64 bit
integer would be overkill. That does not mean I think 64 bit or a 64
bit compiler is useless, or that Int64 or even larger are useless data
types, or that they could not benefit from 64 bit registers.
IOW, I merely say we don't need the generic types Integer and Cardinal
to be 64 bit, even on 64 bit or even 128 bit systems. Pointers etc.,
but also the larger integral types (and Currency) could of course
benefit from the 64 bit registers (and the fact there are many MORE
registers too).
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"We have art to save ourselves from the truth."
    - Friedrich Nietzsche (1844-1900)
0
Rudy
10/9/2009 7:44:09 PM
Paul Doland wrote:
> > He said: "For normal integer algorithms, most of the time an
> > Integer (Int32) will suffice"
> 
> FWIW, I fairly often use int64.  I don't honestly know if that is
> implented with native 64-bit instructions or not.
No. Delphi uses 32 bit registers.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"The truth does not change according to our ability to stomach
 it." -- Flannery O'Connor
0
Rudy
10/9/2009 7:44:52 PM
Hans-Peter Diettrich wrote:
> Craig Stuntz schrieb:
> 
> > The claim,
> > made in this thread, that without a 64-bit compiler you cannot
> > access more than 2 GB (or 3 GB, depending upon who is making it) of
> > memory is simply wrong.
> 
> Simply? Wrong? Memory?
> 
> One can access any amount of data, on any platform, limited only by 
> external memory (disk) capacity. But a 32 bit virtual address space 
> limits direct access to 4 GB of memory.
It limits the address space. Not the access to memory. With my 6502,
with a 64k address space, I could still access some 256k of memory.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"For every complex problem there is an answer that is clear,
 simple, and wrong." -- H L Mencken
0
Rudy
10/9/2009 7:46:32 PM
Luigi Sandon wrote:
> You're going to be a real sophist - you can show white is black if
> you like, but that's useless.  You can access terabytes RAM with a 8
> bit processor, segmentation and paging, if it has enough address
> lines, but why someone would work that way?
        You call me a sophist and then talk about TBs of RAM in the next
sentence? Good grief, read what you write before posting.
-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
10/9/2009 8:34:00 PM
On Fri, 9 Oct 2009 10:00:03 -0700, Paul Doland <nospam@nowhere.com>
wrote:
>I don't honestly know what is even being proposed for this "128-bit
>Windows".  If it is just to get native 128 bit math, I think that is
>more a matter of having the instructions in the processor, not really
>an OS issue at all. And I don't think they could possibly be talking
>about larger address space.  So, I haven't any idea what a 128-bit
>Windows might entail. Can someone enlighten me?
Actually, I can see one use for it:
How about basically abolishing most file I/O calls?  Wouldn't it be
simpler if memory-mapped files were the normal means of accessing
data?
Simply make the file "handle" be the base address of the memory map.
You need your address space to be far in excess of your maximum
filesize to make this work, though, as your handles can't be set
closer together than the maximum filesize.
0
Loren
10/9/2009 8:36:17 PM
On Fri, 9 Oct 2009 09:22:49 -0700, Jens Gruschel
<jg@pegtopwantsnospam.net> wrote:
>> As many others, MS made a big mess defining data types - LONG, DWORD, etc, often mapping to same 32 bit data
>
>Absolutely. If I had to define data type names for a new computer language (of 
>course it's easier now), I'd use Int8, Int16, Int32, Int64 and one generic 
>integer type, that maps to one of these types (just like Delphi has).
Yup.  That's what I do on anything large enough to have a unit of
definitions.  These and the corresponding Wordxx values.  It's so much
clearer.
0
Loren
10/9/2009 8:36:18 PM
> Maybe you should warn people
anger, Will Robinson. Danger!
> you have a personal business interest in pushing Prism, if you're that Hoffman.
i'm "that hoffman", yes.
0
marc
10/9/2009 10:09:06 PM
>> Is a 128-bit "end-user" processor available yet?
> 
> You get them in Playstation 3 and XBox 360... they are closer than you think.
Both are not really 128 bit systems. The Cell processor has 128 bit registers 
for vector arithmetics called AltiVec (similar to the SSE registers, which are 
128 bit, too, for 32 bit x86 CPUs).

-- 
Jens Gruschel
http://www.pegtop.net
0
Jens
10/9/2009 11:27:32 PM
marc hoffman wrote:
>> Maybe you should warn people
> 
> anger, Will Robinson. Danger!
> 

Freudian slip??? <G>
David Erbas-White
0
David
10/9/2009 11:27:38 PM
<Ken White> wrote in message:
>Windows in 32-bit versions still run 16-bit apps just fine.
I just installed VB 3.0 and it works in XP 32. Run an old VB3 DB application 
just fine  ;-)
0
Gilbert
10/10/2009 12:05:59 AM
Loren Pechtel wrote:
> On Fri, 9 Oct 2009 10:00:03 -0700, Paul Doland <nospam@nowhere.com>
> wrote:
> 
> > I don't honestly know what is even being proposed for this "128-bit
> > Windows".
> 
> Actually, I can see one use for it:
> 
> How about basically abolishing most file I/O calls?  Wouldn't it be
> simpler if memory-mapped files were the normal means of accessing
> data?
Um, no. You gain in that accessing random blocks is easier, but it
increases your working set, and performance can suffer.
(In "Advanced Windows," Jeffrey Richter made an offhand comment that
you could use memory mapping to load a file and run quicksort against
it. The editor of the Dos/Windows Programming Journal (that gives you
an idea of how long ago this was) thought that this was a bad idea, and
got a bunch of letters from people who didn't understand, so he ran a
test. A DOS program that understood that disk is slow vs. a Win32
program using quicksort and a memory mapped file. The DOS program won
easily, even though it had access to something like 1/100 of the memory
available to the Win32 program.)
Mike S.
0
Mike
10/10/2009 1:56:37 AM
Rudy Velthuis (TeamB) schrieb:
>> One can access any amount of data, on any platform, limited only by 
>> external memory (disk) capacity. But a 32 bit virtual address space 
>> limits direct access to 4 GB of memory.
> 
> It limits the address space. Not the access to memory. With my 6502,
> with a 64k address space, I could still access some 256k of memory.
That's what you could do with EMS, or nowadays can do with AWE. It has 
nothing to do with *direct* memory access.
DoDi
0
Hans
10/10/2009 3:41:32 AM
Loren Pechtel schrieb:
> How about basically abolishing most file I/O calls?  Wouldn't it be
> simpler if memory-mapped files were the normal means of accessing
> data?
Simpler yes, but not more efficient. As soon as the file size exceeds 
the available RAM capacity, your app will behave horribly :-(
Still worse with many apps and memory mapped files, which reduce the 
available memory (for every process) to a fraction of the physical RAM.
DoDi
0
Hans
10/10/2009 3:41:33 AM
"Paul Doland" <nospam@nowhere.com>
>  At any  rate, I am quite certain having native 128 bit integer math has
> current uses.  But, certainly not for every application.
>
I'd rather call a 128-bit storage a buffer not an integer. <g>
0
Farshad
10/10/2009 9:15:11 AM
> I don't honestly know what is even being proposed for this "128-bit
> Windows".  If it is just to get native 128 bit math, I think that is
> more a matter of having the instructions in the processor, not really
> an OS issue at all. And I don't think they could possibly be talking
> about larger address space.
Exactly. Even with a 32 bit Windows you can access 4096 bit registers, if there 
are such registers and the CPU offers instructions to access them in 32 bit mode.
Most CPUs have general purpose registers (such as ax, eax, rax), which are both 
used for integer and pointer arithmetic (such as "inc edx"), and for addressing 
(such as "mov al, byte ptr [edx]"). IMO the size of these general purpose 
registers defines what kind of CPU it is.
The CPU can also have special registers, for floating point arithmetic or large 
integer arithmetic. It could have a r4096 register for 4096 bit integer 
arithmetic. But as long as you cannot do things like "mov al, byte ptr [r4096]", 
you can hardly call the CPU 4096 bit.
Well, maybe you can, for marketing reasons.
But you can hardly call an operating system supporting this CPU 4096 bit, 
especially since you can make use of these fancy 4096 bit registers without this 
operating system as well.
Well, maybe you can, for marketing reasons.
-- 
Jens Gruschel
http://www.pegtop.net
0
Jens
10/10/2009 10:03:19 AM
Hans-Peter Diettrich wrote:
> Rudy Velthuis (TeamB) schrieb:
> 
> >> One can access any amount of data, on any platform, limited only
> by >> external memory (disk) capacity. But a 32 bit virtual address
> space >> limits direct access to 4 GB of memory.
> > 
> > It limits the address space. Not the access to memory. With my 6502,
> > with a 64k address space, I could still access some 256k of memory.
> 
> That's what you could do with EMS, or nowadays can do with AWE. It
> has nothing to do with direct memory access.
Like I said, it limits the address space. I'm not sure what you are
getting at.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"Programming today is a race between software engineers striving 
 to build bigger and better idiot-proof programs, and the Universe
 trying to produce bigger and better idiots. So far, the Universe 
 is winning." -- Rich Cook.
0
Rudy
10/10/2009 2:40:56 PM
On Fri, 9 Oct 2009 20:41:33 -0700, Hans-Peter Diettrich
<DrDiettrich1@aol.com> wrote:
>Loren Pechtel schrieb:
>
>> How about basically abolishing most file I/O calls?  Wouldn't it be
>> simpler if memory-mapped files were the normal means of accessing
>> data?
>
>Simpler yes, but not more efficient. As soon as the file size exceeds 
>the available RAM capacity, your app will behave horribly :-(
>
>Still worse with many apps and memory mapped files, which reduce the 
>available memory (for every process) to a fraction of the physical RAM.
I would think it would be faster--Windows generally wouldn't need to
write the stuff out to the swap file if it got swapped out.
0
Loren
10/10/2009 6:33:12 PM
On Fri, 9 Oct 2009 18:56:37 -0700, Mike Swaim <swaim@hal-pc.org>
wrote:
>Loren Pechtel wrote:
>
>> On Fri, 9 Oct 2009 10:00:03 -0700, Paul Doland <nospam@nowhere.com>
>> wrote:
>> 
>> > I don't honestly know what is even being proposed for this "128-bit
>> > Windows".
>> 
>> Actually, I can see one use for it:
>> 
>> How about basically abolishing most file I/O calls?  Wouldn't it be
>> simpler if memory-mapped files were the normal means of accessing
>> data?
>
>Um, no. You gain in that accessing random blocks is easier, but it
>increases your working set, and performance can suffer.
>(In "Advanced Windows," Jeffrey Richter made an offhand comment that
>you could use memory mapping to load a file and run quicksort against
>it. The editor of the Dos/Windows Programming Journal (that gives you
>an idea of how long ago this was) thought that this was a bad idea, and
>got a bunch of letters from people who didn't understand, so he ran a
>test. A DOS program that understood that disk is slow vs. a Win32
>program using quicksort and a memory mapped file. The DOS program won
>easily, even though it had access to something like 1/100 of the memory
>available to the Win32 program.)
Of course you don't go manipulating the data in the memory map!  That
doesn't mean it wouldn't make plenty of reading tasks a lot simpler.
0
Loren
10/10/2009 6:33:12 PM
> C is very cross-platform. It can't set strict limits on its sizes. That
So cross-platform that you may have issue moving code where long is 32 bit to one where it is 64... maybe MS uses LLP because all the other uses LP.... more porting issues.
0
Luigi
10/10/2009 7:16:54 PM
> i'm "that hoffman", yes.
So why don't you put it in your signature? It would warn people yuor opinion about Prism and .NET may be biased. Or are you afraid people know it?
0
Luigi
10/10/2009 7:21:02 PM
Luigi Sandon wrote:
> > C is very cross-platform. It can't set strict limits on its sizes.
> > That
> 
> So cross-platform that you may have issue moving code where long is
> 32 bit to one where it is 64... maybe MS uses LLP because all the
> other uses LP.... more porting issues.
There should be no issues if you coded in a proper cross-platform way,
i.e. without any assumptions about sizes, etc. It is always good to do
that, even in Delphi.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"If the lessons of history teach us anything it is that nobody 
 learns the lessons that history teaches us."
0
Rudy
10/10/2009 8:57:54 PM
> Someday, yes, everything will be obsolete and someday Win32 will be
> obsolete.  But, there is just NO CHANCE that any version of Windows
> will drop Win32 support in anything less than 10 years
I don't think it will ever be dropped.  Win32 may one day - perhaps sooner 
than we think - be shuffled off into some sort of seamless Virtual Machine, 
much like Virtual XP mode comes with Windows 7, but once it's there there 
would simply be no reason to drop it.
SteveT
0
Steve
10/10/2009 11:28:49 PM
Luigi,
>> i'm "that hoffman", yes.
>
> So why don't you put it in your signature?
what should i out in there? that i'm "that hoffman"?
> It would warn peopleyuor opinion
i didn't expect people needed any "warnings" about my (or anyone's) 
opinion. an opinion is not an earthquake.
also, *every* opinion of everyone here in this group will always be 
subjective. whether it is *biased*, or not should be apparent form the 
message itself or not, regardless of the author.
in any case, someone wanted to write Delphi code for mobile devices. and 
i suggested he check out Delphi Prism. on a Delphi forum none the less. 
Alert the f--king media!
> about Prism and .NET may be biased. Or are you afraid people know it?
yes, i live in constant fear of people finding out that i am "that hoffman".

yours,
marc "that" hoffman
0
marc
10/11/2009 12:27:58 PM
Luigi Sandon <> wrote:
> Delphi is going to be vey late supporting 64 bit, and telling 64 bit aren't ripe yet like the fox of fable is utterly useless.
Delphi is late with 64-bit and ItnerBase is even longer overdue on
64-bit..  I have a customer whom really needed 64-bitt support on both
Delphi and InterBase as they are hitting 2GB process limits on server
side. mostly it would be Cache that should be bigger. As they cound
response time in milliseconds..  and they lose money if that get's too
big. Now they are considering to switch to SQL Server, but hopefully
we would get better roadmap to all tools in 64-bit enviroment. 


Regards, Qapla'
                   Juha Piispa
0
Juha
10/12/2009 6:08:32 AM
> Sure. I never said that Int64s were not used, or that they don't have
> their utility. Others even use far larger keys. But most integer
> algorithms don't need more than 32 bits.
By now ;)
This sounds like the good old saying: 640kB of memory is enough
regards
Mike
0
Michael
10/12/2009 9:31:09 AM
Michael Rabatscher wrote:
> > Sure. I never said that Int64s were not used, or that they don't
> > have their utility. Others even use far larger keys. But most
> > integer algorithms don't need more than 32 bits.
> 
> By now ;)
> 
> This sounds like the good old saying: 640kB of memory is enough
It may sound like that, but it is a totally different matter. I'd bet
that for most uses, we could even get by with 16 bit integers. Just
think what integers are used for, moszt of the time. Look at the many
times integers are used in all the code you have (I'm sure everyone
here has a lot), including the RTL and VCL and look at the values these
integers take.
I'm sure you'll find that at least 95% of the code that uses integers
could do with values ranging from -32768 to 32767. So why waste 64 bits
on such integers?
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"Outside of a dog, a book is man's best friend. Inside of a dog, 
 it's too dark to read." -- Groucho Marx
0
Rudy
10/12/2009 10:13:39 AM
Juha Piispa wrote:
> I have a customer whom really needed 64-bitt support on both
> Delphi and InterBase as they are hitting 2GB process limits on server
> side. mostly it would be Cache that should be bigger. 
        NB: IB currently supports up to 4 GB of RAM on Win64.
-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
10/12/2009 12:35:08 PM
Luigi Sandon wrote:
> It would warn people yuor opinion about Prism and .NET may be biased.
        And yours isn't?
        There is no rule against employees of the companies who produce Delphi
praising it here, with or without shouting their employment in every
post. Just like there isn't a rule against you emitting your, um,
opinions.
        Just try to stick to the issues rather than focusing on people,
please. I guarantee that nothing you say to marc is going to make him
change, so you're wasting your breath there.
-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
10/12/2009 12:39:24 PM
>Delphi is late with 64-bit and ItnerBase is even longer overdue on
>64-bit..  I have a customer whom really needed 64-bitt support on both
Well, the idea of changing database engine may not be appealing, but,
if you did, I'd like to recommend NexusDB, which has an AWE version to
support all the RAM you need.
0
Paul
10/12/2009 2:36:31 PM
>> FWIW, I fairly often use int64.  I don't honestly know if that is
>> implented with native 64-bit instructions or not.
>
>No. Delphi uses 32 bit registers.
Well, I'm kinda surprised.  I would have figured the RTL would detect
what instruction set you have and automatically use 64 bit native
instructions if available.  This would be something that I think
should be done.  And while not trivial, I wouldn't think it would be a
very big effort.
0
Paul
10/12/2009 2:38:45 PM
> And yours isn't?
Surely. The difference is I am not a RemObjects employee or whatever, and I do not get a dime for Delphi or Prism sales. Guess RemObjects and its people do - the more Prism sales, the more they earn. It is called "conflict of interest".
 
> There is no rule against employees of the companies who produce Delphi
Right. But it would be *fair* to state it explicitly - because they have an economic interest in it. Especially if they row against the company who sell their compiler... I am not the only one surprised by RemObjects people behaviour on these groups.
 
> Just try to stick to the issues rather than focusing on people,
I just wonder why Hoffman does not sign himself as a Prism and RemObject developer explicitly. It's just a matter of fairness, but fair people are becoming rarer and rarer.
> change, so you're wasting your breath there.
I know - but maybe someome will understand why he likes Prims and .NET so much.
0
Luigi
10/12/2009 3:18:43 PM
Luigi Sandon wrote:
> > Just try to stick to the issues rather than focusing on people,
> 
> I just wonder why Hoffman does not sign himself as a Prism and
> RemObject developer explicitly. It's just a matter of fairness, but
> fair people are becoming rarer and rarer.
        Nobody is required to identify their employer. Good thing, since you
don't. Perhaps the fact of your employer accounts for all the opinions
you have with which I disagree?
        Perhaps not. Maybe marc likes Prism because he profits from it, or
maybe it just likes the way it works. It's no more fair to speculate
about his motives than yours.
-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
10/12/2009 3:28:28 PM
Craig Stuntz wrote:
> Luigi Sandon wrote:
> 
>>> Just try to stick to the issues rather than focusing on people,
>> I just wonder why Hoffman does not sign himself as a Prism and
>> RemObject developer explicitly. It's just a matter of fairness, but
>> fair people are becoming rarer and rarer.
> 
>    Nobody is required to identify their employer. Good thing, since you
> don't. Perhaps the fact of your employer accounts for all the opinions
> you have with which I disagree?
> 
>    Perhaps not. Maybe marc likes Prism because he profits from it, or
> maybe it just likes the way it works. It's no more fair to speculate
> about his motives than yours.
> 
I have to disagree here.
IF/WHEN there is no apparent conflict of interest, then no harm, no 
foul.  So, for most posters to the newsgroup, it's not an issue.  But 
for folks who have a vested, direct interest in the Delphi product line, 
it's an issue.
IF/WHEN there is a POSSIBILITY of apparent conflict of interest, it's 
best to make it VERY clear about that conflict, remaining very up front 
about it.
Years ago I was editor of a users journal that was primarily targeted at 
a particular product.  I made my living off of doing consulting work for 
that product.  I had to make it VERY clear, every time I wrote an 
article/review editorial, to show where I might have a conflict of 
interest.  Being up front about it solves an awful lot of problems.
It's the same with politicians -- if they tell me up front about an 
issue with their background or a position they hold, then I can make a 
reasoned judgement.  But if that judgement has been skewed because 
they've withheld information, then the 'blowback' is much greater...
David Erbas-White
0
David
10/12/2009 3:40:38 PM
I would agree with you if this was a journal or a product review. But
it's a discussion forum. People aren't even required to use their real
/names/ here.
        And I agree, this means that you should take what you read here with a
big boulder of salt.
-- 
Craig Stuntz · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz/
0
Craig
10/12/2009 3:50:18 PM
Craig,
>    Perhaps not. Maybe marc likes Prism because he profits from it, or
> maybe it just likes the way it works.
indeed. maybe he even likes it because he specifically designed it the 
way he wants it ;).
0
marc
10/12/2009 3:59:08 PM
Paul Doland wrote:
>>> FWIW, I fairly often use int64.  I don't honestly know if that is
>>> implented with native 64-bit instructions or not.
>> No. Delphi uses 32 bit registers.
> 
> Well, I'm kinda surprised.  I would have figured the RTL would detect
> what instruction set you have and automatically use 64 bit native
> instructions if available.  This would be something that I think
> should be done.  And while not trivial, I wouldn't think it would be a
> very big effort.
Guess again. Only 64-bit code can use the 64-bit registers. IOW you 
would *also* have to change the calling convention everywhere (which is 
different on Win64), account for the now 64-bit pointer size, rewrite 
any asm sections (such as the fastcode donations in system.pas and 
sysutils.pas), have a 64-bit debugger ready to enable debugging, etc.
0
Utf
10/12/2009 4:06:31 PM
"David Erbas-White" <derbas@arachneering.com> wrote in message 
news:171914@forums.codegear.com...
>
> IF/WHEN there is a POSSIBILITY of apparent conflict of interest, it's
> best to make it VERY clear about that conflict, remaining very up front
> about it.
The issue is not whether this is a good thing (it generally is) but whether 
it is something that should be *required*.
> Years ago I was editor of a users journal that was primarily targeted at
> a particular product.  I made my living off of doing consulting work for
> that product.  I had to make it VERY clear, every time I wrote an
> article/review editorial, to show where I might have a conflict of
> interest.  Being up front about it solves an awful lot of problems.
If that journal was dedicated to that particular product then I disagree 
that you needed to do so, the journal itself had obvious and acceptable 
bias - anyone reading it *should* expect to see bias in favour of that 
product. If the jounal was intending to be wider than that one product, then 
such disclaimers clearly become more important in order for the journal to 
be taken seriously by more than that one product's customers.
In the case of these groups, they are *Delphi* groups. People here are 
almost exclusively those that make their living at least in part by using 
Delphi or in some way serving other Delphi users. Thus the groups themselves 
are naturally biased already. The idea that someone with in an interest in 
Delphi's success in these groups should have to identify themselves as such 
as kind of moot in my opinion, it should be *expected*. What does it matter 
if one makes a living due to being on the team that produces Delphi or 
because one *uses* Delphi? In both cases we have a *vested* interest in its 
success for our own success.
-- 
Wayne Niddery (TeamB)
0
Wayne
10/12/2009 4:19:42 PM
Paul Doland wrote:
> >> FWIW, I fairly often use int64.  I don't honestly know if that is
> >> implented with native 64-bit instructions or not.
> > 
> > No. Delphi uses 32 bit registers.
> 
> Well, I'm kinda surprised.  I would have figured the RTL would detect
> what instruction set you have and automatically use 64 bit native
> instructions if available.
How should that work?
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"The internet is not something you just dump something on. It's 
 not a truck. It's a series of tubes!" 
 -- Sen. Ted Stevens, chairman of the United States Senate 
    Committee on Commerce, Science and Transportation
0
Rudy
10/12/2009 4:59:04 PM
Craig Stuntz wrote:
>  I guarantee that nothing you say to marc is going to make him
> change, so you're wasting your breath there.
LOL!
-- 
Mike
0
Mike
10/12/2009 5:33:40 PM
Juha Piispa wrote:
> Luigi Sandon <> wrote:
> 
> Delphi is late with 64-bit and ItnerBase is even longer overdue on
> 64-bit..  I have a customer whom really needed 64-bitt support on both
> Delphi and InterBase as they are hitting 2GB process limits on server
> side. 
  Isn't that a server OS issue, though? Craig's already replied that IB
supports up to 4 GB, and it should be pretty straightforward to get
modern Delphi apps to 4 GB, too, if the server supports it. (AFAIK, the
old memory manager (pre D7?) didn't generate 32 bit clean executables,
but the current one does.
Mike S.
0
Mike
10/12/2009 5:57:12 PM
Hello,
isn't the currency type (don't know off hand its size) more than 6
digits on the integer side?
Greetings
Markus
0
Markus
10/12/2009 7:31:15 PM
> {quote:title=Luigi Sandon wrote:}{quote}
> > And yours isn't?
> 
> Right. But it would be *fair* to state it explicitly - because they have an economic interest in it. Especially if they row against the company who sell their compiler... I am not the only one surprised by RemObjects people behaviour on these groups.
I'm a TeamRO member, what is exactly the surprising behavior  you get for RemObjects people? Is just curiosity.
> I know - but maybe someome will understand why he likes Prims and .NET so much.
Marc is IMHO a integral person. If you search in codegear newsgroups and even in borland newsgroups you will find he many times claim it prefer .NET to VCL, and don't even talk abput he he thinks about VCL.NET...
So, where is the problem? For the way he thinks i believe he start to work in the pascal for .net project , knowed in these days like delphi prism. The points he exposed about why he likes dot net are clear. And i disagree with him, because i prefer native code and vcl fits my needs. :) 
I also use freepascal and lazarus, and guess what? Remobejcts compile my servers for linux at 64 bits! 
But who matters. I'm a TeamRO member, that say a lot about marc respect to another people opinion , and at  the end of the day all is about the freedom we developers have to make elections any day, and good bless marc and remobjects team for give delphi prism to the world. That imply more delphi developers can go in a beautiful way to dot net,  and dot net developers can use our loved language (pascal) to work in dot net.
So, my friend, which is you problem about that?
Best regards.
Edited by: german gentile on Oct 12, 2009 1:05 PM
0
german
10/12/2009 8:06:28 PM
Markus Humm wrote:
> Hello,
> 
> isn't the currency type (don't know off hand its size) more than 6
> digits on the integer side?
> 
> Greetings
The Currency type is a 64 bit fixed point type scaled by 10000. So you
won't have more than 4 decimals ever. The Decimal type is a floating
decimal point type, 128 bytes in size, of which 96 bits are mantissa, 5
bits are exponent and 1 bit is sign.
In Decimal, if you do x := 3 * 1.0000 then the result is 3.0000 (30000
x 10^-4) and not 3. It keeps its decimals. You can have up to 28
decimals.
The largest value is approx. 7e29, the smallest above 0 is 1e-28.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"It's clearly a budget. It's got a lot of numbers in it."
 -- George W. Bush
0
Rudy
10/12/2009 8:12:48 PM
Luigi Sandon wrote:
> So why don't you put it in your signature? It would warn people yuor
> opinion about Prism and .NET may be biased. Or are you afraid people
> know it?
I look forward to seeing your complete and unabridged signature.
-- 
Regards,
Bruce McGee
Glooscap Software
Unrepentant Delphi bigot
Just got a Wii.  Really liking Mario Karts.
0
Bruce
10/13/2009 2:06:32 PM
>Guess again. Only 64-bit code can use the 64-bit registers. 
Hmmm.  If this is correct, and you sound like you know what you are
talking about, then, I'm totally wrong. I just figured that for sure
with all these SSE and various enhanced instruction sets, there surely
should be native 64 bit integer math available in 32 bit mode.  That
would not work on older processors, but, I thought for sure it would
on newer ones.  That sounds very strange to me that that would not be
available.
0
Paul
10/13/2009 4:29:51 PM
Hello,
with decimals (word useage might have been wrong) I menat the number of
figures before the decimal point, not after. I'm sure currency can
handle amounts up to several millions at least.
Greetings
Markus
0
Markus
10/13/2009 4:41:17 PM
Jens Gruschel schrieb:
[snip]
> 
> Isn't that violating Moore's law? No. Doubling the pointer size doesn't just 
> double the address space, in fact it's y = 2^2^n (where n is the processor 
> generation). So it's quite naturally that new processor generations arrive 
> slower and slower.
> 
Just a tiny remark: you misinterpret Moore's law in my eyes. Moore's law
only sais the number of transistors will double every 18 or 24 months
(not sure about the number of months though). It doesn't mean these
added transistors do more than consuming energy! ;-)
Greetings
Markus
0
Markus
10/13/2009 4:44:44 PM
Paul Doland wrote:
>> Guess again. Only 64-bit code can use the 64-bit registers. 
> 
> Hmmm.  If this is correct, and you sound like you know what you are
> talking about, then, I'm totally wrong. I just figured that for sure
> with all these SSE and various enhanced instruction sets, there surely
> should be native 64 bit integer math available in 32 bit mode.  That
> would not work on older processors, but, I thought for sure it would
> on newer ones.  That sounds very strange to me that that would not be
> available.
There would be no point in using the XMM registers for things such as 
just adding two Int64 values. Even on CPUs that support the required 
instructions, doing an ADD followed by an ADC is typically faster. OTOH, 
if you are doing heavy vector arithmetics, using the SSE might be a good 
idea, but short of having special purpose methods for such operations, I 
doubt the compiler could tell that is what you intend to do.
0
Utf
10/13/2009 8:54:37 PM
Marc,
Not only Windows x64 is a complete mess. The same thing is valid for the 32 bit versions of Windows.
Even the police advises not to use Windows for internet banking and they are right ! See http://www.itnews.com.au/News/157767,nsw-police-dont-use-windows-for-internet-banking.aspx
It is time that Embarcadero is going to focus on the growing Mac and Linux market shares i.s.o. the decreasing Windows market share: a 64-bit Delphi for Mac OS X and Ubuntu.
Hubert Anemaat
> {quote:title=marc hoffman wrote:}{quote}
> John,
> 
> >> This link is to an article the claims that the next Windows version
> >> will be 128 Bit.  Which would be Win8 - and if not that version then
> >> definitely Win 9.
> >> http://arstechnica.com/microsoft/news/2009/10/microsoft-mulling-128-bit-versions-of-windows-8-windows-9.ars
> >>
> >> I realize that Delphi 64 bit should be out this year (or so I hope!) -
> >> and that the next windows is a few years away - but I hope the folks
> >> at Emb. are already planning for the 128 version when they do the 64
> >> bit version...
> >
> > Why? If Win128 runs Win32 and Win64 apps just fine, like the way Win64 runs
> > 32-bit apps justfine, and with up to 4MB of RAM, why would it make any
> > difference to the majority of users or developers whether or not their apps
> > were 128-bit?
> 
> if. Win64 does not run Win16 apps. so its entirely possible that Win128 
> would drop support for Win32. (if only to avoid having a second 
> SysWow128 folder and three versions of "Program Files" ;P).
> 
> But then, the whole x64 strategy on Windows is a mess(compared to, say, 
> OS X), so who knows...
> 
> > Especially since no consumers are currently even using 128-bit
> > machines.
> 
> True. i'd be surprised if 128-bit becomes relevant for anyone beyond 
> high-end data centers, anytime soon. </famous last words ;->.
0
Hubert
10/14/2009 7:59:30 AM
Hubert Anemaat wrote:
> Not only Windows x64 is a complete mess. The same thing is valid for the 32 bit versions of Windows.
> 
> Even the police advises not to use Windows for internet banking and they are right ! See http://www.itnews.com.au/News/157767,nsw-police-dont-use-windows-for-internet-banking.aspx
> 
> It is time that Embarcadero is going to focus on the growing Mac and Linux market shares i.s.o. the decreasing Windows market share: a 64-bit Delphi for Mac OS X and Ubuntu.
I guess you only read half of the article. The key part was that 
boot-up-disk distributions such as Knoppix are secure because *nothing 
else can be installed and running* while you do your Internet banking.
A Linux system running from the hard drive is not necessarily any more 
secure than a Windows system. And anything we, being developers, develop 
and deploy will in more than 99% of the cases end up installed on a hard 
drive. Hence, the article doesn't really have anything to do with this 
discussion.
0
Utf
10/14/2009 8:26:08 AM
Markus Humm wrote:
> Hello,
> 
> with decimals (word useage might have been wrong) I menat the number
> of figures before the decimal point, not after. I'm sure currency can
> handle amounts up to several millions at least.
Oh sure, but decimals (or decimal places) are the digits after the
_decimal_ point. Currency only has four. Currency is just an Int64
scaled by 10000, so there are 2^64 possible values.
My Decimal is a floating (decimal) point type and therefore has a much
larger range. Largest value is 79228162514264337593543950335 (exactly),
smallest value is 0,0000000000000000000000000001 (exactly).
To compare that with Single, Double or Extended, here is a print that
shows Single, Double, and Extended converted to Decimal (which is an
exact process) and Decimal itself, expressing the values 0.1, 0.2,
0.2*2.5, 0.5 and 1/3:

Single -> Decimal
-----------------
D := 0.1;           0,100000001490116119384765625
D := 0.2;            0,20000000298023223876953125
D := D * 2.5;       0,500000007450580596923828125
D := 0.5;                                     0,5
D := 1 / 3;           0,3333333432674407958984375

Double -> Decimal
-----------------
D := 0.1;          0,1000000000000000055511151231
D := 0.2;          0,2000000000000000111022302462
D := D * 2.5;      0,5000000000000000277555756155
D := 0.5;                                     0,5
D := 1 / 3;        0,3333333333333333148296162562

Extended -> Decimal
-------------------
D := 0.1;          0,1000000000000000000013552527
D := 0.2;          0,2000000000000000000027105054
D := D * 2.5;      0,5000000000000000000067762635
D := 0.5;                                     0,5
D := 1 / 3;        0,3333333333333333333423683514

Decimal only
------------
D := 0.1;                                     0,1
D := 0.2;                                     0,2
D := D * 2.5;                                0,50
D := 0.5;                                     0,5
D := 1 / 3;        0,3333333333333333333333333333
Note that these Decimal values are not rounded. All available digits
(up to 28 decimal places) are shown. Also see the difference in
precision between Single, Double and Extended, and between all of these
and the exact accuracy of Decimal.

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"Barabási's Law of Programming: Program development ends when the 
 program does what you expect it to do — whether it is correct or
 not." -- Albert-László Barabási
0
Rudy
10/14/2009 10:55:01 AM
Hubert,
> Not only Windows x64 is a complete mess. The same thing is valid for the 32 bit versions of Windows.
hey, i won't argue that ;). it's just that 64bit Windows does such a 
nice job of making it blatantly obvious what a hackjob design it is...
0
marc
10/14/2009 11:14:44 AM
Hello,
you didn't read the roadmap and todays blogs? Do you?
Greetings
Markus
0
Markus
10/14/2009 7:40:12 PM
Hello,
I didn't want to say your new type is worse than the existing ones, I
really thing it has some more capabilities. I only wanted to point out
that for many things the existing currency type might be good enough and
not limited to some 2 Million Euro/USD whatever...
Greetings
Markus
0
Markus
10/14/2009 7:42:11 PM
Markus Humm wrote:
> Hello,
> 
> I didn't want to say your new type is worse than the existing ones, I
> really thing it has some more capabilities. I only wanted to point out
> that for many things the existing currency type might be good enough
The fact that it is only scaled by 10000 makes it not very usable. You
only have 4 decimals, and never more (it is a fixed point type, after
all), and for many financial applications, that is not enough.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"When someone says, 'I want a programming language in which I
 need only say what I want done', give him a lollipop." 
 -- Alan Perlis
0
Rudy
10/14/2009 8:42:49 PM
Rudy Velthuis (TeamB) schrieb:
>> I didn't want to say your new type is worse than the existing ones, I
>> really thing it has some more capabilities. I only wanted to point out
>> that for many things the existing currency type might be good enough
> 
> The fact that it is only scaled by 10000 makes it not very usable. You
> only have 4 decimals, and never more (it is a fixed point type, after
> all), and for many financial applications, that is not enough.
Just financial arithmetic (tax...) typically has strict rules for 
rounding and dealing with decimals. In this area fixed point types 
certainly are more useful than (binary) floating point types.
But you're right, four decimals are most useful for calculations in 
currencies with two decimals (like € or $ cents), not so much with other 
currencies.
DoDi
0
Hans
10/14/2009 10:56:11 PM
Hans-Peter Diettrich wrote:
> Just financial arithmetic (tax...) typically has strict rules for 
> rounding and dealing with decimals. In this area fixed point types 
> certainly are more useful than (binary) floating point types.
But not nearly as useful as a DECIMAL floating point type, i.e. you
have 28 decimal digits that can have a floating point and even keep it
if you move it. IOW, 1.000 is not the same number as 1 or 1.000000,
although they will compare as equal. But 1/3 is
0.3333333333333333333333333333, and not some approximation. 1/5 is
exactly 0.2, and not some approximation.
 
> But you're right, four decimals are most useful for calculations in 
> currencies with two decimals (like € or $ cents), not so much with
> other currencies.
Even then, as soon as you start using percentages and annuities, etc.,
you lose accuracy very fast.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"To the Honourable Member opposite I say, when he goes home 
 tonight, may his mother run out from under the porch and bark at 
 him" -- John G. Diefenbaker
0
Rudy
10/14/2009 11:04:42 PM
On Wed, 14 Oct 2009 13:42:49 -0700, Rudy Velthuis (TeamB)
<newsgroups@rvelthuis.de> wrote:
>Markus Humm wrote:
>
>> Hello,
>> 
>> I didn't want to say your new type is worse than the existing ones, I
>> really thing it has some more capabilities. I only wanted to point out
>> that for many things the existing currency type might be good enough
>
>The fact that it is only scaled by 10000 makes it not very usable. You
>only have 4 decimals, and never more (it is a fixed point type, after
>all), and for many financial applications, that is not enough.
Also, for some applications it's too much.  Sometimes you *NEED* the
roundoff errors caused by two decimal places.
0
Loren
10/15/2009 12:47:20 AM
Rudy Velthuis (TeamB) wrote:
> The fact that it is only scaled by 10000 makes it not very usable. You
> only have 4 decimals, and never more (it is a fixed point type, after
> all), and for many financial applications, that is not enough.

I LOVE the currency data type.
The darned good thing about currencies is that they are
"exact" values. They are integers with a scaling factor.
You can even use currency columns as primary keys in
databases (I see people fall off their chairs there!) and
I actually do that with much success.
I have a database that stores oil well drilling data and one
of the primary key components is the depth.
Measurements are stored in 0.2 m intervals.
So it's perfectly legal for me to do a query like
"select methane from drilldata where oilwell=
{GUID number here} and depth = 1234.6"
and expect a result set, because I can rely on it 100% that
the depth is stored as "1234.6" and not as "1234.599999999999"

I also love GUIDS by the way. They look awkward but they are
stored as 4 DWORDS so they make a very efficient primary key.

-- 
Arthur Hoornweg
(In order to reply per e-mail, please just remove the ".net"
  from my e-mail address. Leave the rest of the address intact
  including the "antispam" part. I had to take this measure to
  counteract unsollicited mail.)
0
Arthur
10/15/2009 6:53:40 AM
Arthur Hoornweg wrote:
> Rudy Velthuis (TeamB) wrote:
> 
> > The fact that it is only scaled by 10000 makes it not very usable.
> > You only have 4 decimals, and never more (it is a fixed point type,
> > after all), and for many financial applications, that is not enough.
> 
> 
> I LOVE the currency data type.
> 
> The darned good thing about currencies is that they are
> "exact" values. 
So is my decimal type, but mine has far greater precision and still
remains just as exact as Currency. Currency has problems when you must
round, and that is as soon as you don't just add, subtract or multiply
with integers, e.g. when you must deal with percentages, etc.
Currency is just as exact as an integer (it is in fact an integer which
counts in 1/100 cent), but also as limited as one.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"Just as a picture is drawn by an artist, surroundings are
 created by the activities of the mind."
 -- Buddha
0
Rudy
10/15/2009 10:37:09 AM
Rudy Velthuis (TeamB) schrieb:
>> Just financial arithmetic (tax...) typically has strict rules for 
>> rounding and dealing with decimals. In this area fixed point types 
>> certainly are more useful than (binary) floating point types.
> 
> But not nearly as useful as a DECIMAL floating point type, i.e. you
> have 28 decimal digits that can have a floating point and even keep it
> if you move it. IOW, 1.000 is not the same number as 1 or 1.000000,
> although they will compare as equal. But 1/3 is
> 0.3333333333333333333333333333, and not some approximation. 1/5 is
> exactly 0.2, and not some approximation.
You know that 1/3 has no finite binary representation?
>> But you're right, four decimals are most useful for calculations in 
>> currencies with two decimals (like € or $ cents), not so much with
>> other currencies.
> 
> Even then, as soon as you start using percentages and annuities, etc.,
> you lose accuracy very fast.
That's why typically rounding procedures describe how to deal with such 
values. The algorithms have to be implemented accordingly, regardless of 
what a specific arithmetic type does.
E.g. when you list separately amounts (with and without tax) and tax in 
multiple columns, the column sums must be consistent to the last digit 
*shown*, regardless of their internal representation. You'll have to 
round every single number as specified, and to compute e.g. the gross 
amount from the net amount + tax, and to sum up only these rounded values.
DoDi
0
Hans
10/15/2009 4:09:46 PM
Hello,
and german tax forms are stupid by not allowing you to insert decimal
places for some things but rather round to the next whole number as you
like it (up or down what's better for you). Ok, it may be a small
benefit for me as tax payer, but why not allow decimal places for those
values? Mathematically very inexact...but on the other side insisting on
the correctnes of every cent in other cases! ;-)
Greetings
Markus
0
Markus
10/15/2009 4:43:07 PM
Markus Humm wrote:
> and german tax forms are stupid by not allowing you to insert decimal
> places for some things but rather round to the next whole number 
IIRC the UK tax return tells you to round all figures to the nearest
pound in the tax payers favour but my accountant still insists in
sticking the pence in in some places (bean counters, eh!)
-- 
Andy Syms
Technosoft Systems Ltd
0
Andy
10/15/2009 5:04:10 PM
Hans-Peter Diettrich wrote:
> > Even then, as soon as you start using percentages and annuities,
> > etc., you lose accuracy very fast.
> 
> That's why typically rounding procedures describe how to deal with
> such values. 
Yes, and yet, when you round, you lose accuracy, and if you do it a
lot, say 20 times to calculate a loan, you lose a LOT of accuracy. On
paper, people did not round before they had an end result. You can do
the same with Decimal, since it generally doesn't have to round at all
(but it can, if desired, using my Decimal.RoundTo function).
http://en.wikipedia.org/wiki/Floating_point#Minimizing_the_effect_of_accuracy_problems
<<
For this reason, financial software tends not to use a binary
floating-point number representation.[6] The "decimal" data type of the
C# programming language, and the IEEE 854 decimal floating-point
standard, are designed to avoid the problems of binary floating-point
representations when applied to human-entered exact decimal values, and
make the arithmetic always behave as expected when numbers are printed
in decimal.
>>
This "decimal" data type is the one I am currently writing. Currency is
not good enough:
http://visualbasic.about.com/od/usingvbnet/a/decdatatype.htm
<<
In VB 6, the Currency data type was designed for financial
calculations. But Microsoft decided that it just didn't do the job so
they dropped it and now we have the Decimal data type in VB.NET.
This article tells you all about the Decimal data type in VB.NET:
What's new, what works and what doesn't. Like the rest of .NET, Decimal
is far more powerful.
>>
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"You shall find out how salt is the taste of another man's
 bread, and how hard is the way up and down another man's
 stairs."
 -- Dante
0
Rudy
10/15/2009 6:33:57 PM
Markus Humm wrote:
> Hello,
> 
> and german tax forms are stupid by not allowing you to insert decimal
> places for some things but rather round to the next whole number as
> you like it (up or down what's better for you). Ok, it may be a small
> benefit for me as tax payer, but why not allow decimal places for
> those values? 
Because that way, it is much easier for them. <shrug>

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"This book fills a much-needed gap."
-- Moses Hadas (1900-1966) in a review
0
Rudy
10/15/2009 7:13:05 PM
Rudy Velthuis (TeamB) schrieb:
> Markus Humm wrote:
> 
>> Hello,
>>
>> and german tax forms are stupid by not allowing you to insert decimal
>> places for some things but rather round to the next whole number as
>> you like it (up or down what's better for you). Ok, it may be a small
>> benefit for me as tax payer, but why not allow decimal places for
>> those values? 
> 
> Because that way, it is much easier for them. <shrug>
> 
>
??? Wuldn't it be easier then as well to use only numbers without
decimal places everywhere where possible? I simply fail to see the logic
behind this sheme.
Greetings
Markus
0
Markus
10/15/2009 8:22:56 PM
Markus Humm schrieb:
> and german tax forms are stupid by not allowing you to insert decimal
> places for some things but rather round to the next whole number as you
> like it (up or down what's better for you).
In every invoice you'll have to round numbers to the smallest unit of 
the currency. Such nasty formal prescriptions require according code all 
around...
DoDi
0
Hans
10/16/2009 2:29:58 AM
Rudy Velthuis (TeamB) schrieb:
>>> Even then, as soon as you start using percentages and annuities,
>>> etc., you lose accuracy very fast.
>> That's why typically rounding procedures describe how to deal with
>> such values. 
> 
> Yes, and yet, when you round, you lose accuracy, and if you do it a
> lot, say 20 times to calculate a loan, you lose a LOT of accuracy.
Stepwise calculation either is either wrong (there exist formulas) or 
inevitable, when the payments are bound to fixed dates or time spans.
> On paper, people did not round before they had an end result.
Most people rounded very soon, just to reduce the amount of manual 
calculation. Dealing with more decimals in monetary calculations is a 
misfeature, introduced only by computers, and abused since the beginning.
DoDi
0
Hans
10/16/2009 2:30:00 AM
Hans-Peter Diettrich wrote:
> Most people rounded very soon,
No, they didn't. They probably simplified their formulas, but they
should not round very soon (although, in Germany, I'm not so sure they
use the right way. <g>).
 just to reduce the amount of manual 
> calculation. Dealing with more decimals in monetary calculations is a 
> misfeature, introduced only by computers, and abused since the
> beginning.
Nonsense. They are simply required to get the accuracy, i.e. in order
to get a correct result. If this is not done, it is out of convenience,
but not correct.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"It is practically imposible to teach good programming to 
 students that have had a prior exposure to BASIC: as potential 
 programmers they are mentally mutilated beyond hope of 
 regeneration." -- Edsger Dijkstra
0
Rudy
10/16/2009 2:56:10 PM
Rudy Velthuis (TeamB) schrieb:
>> Most people rounded very soon,
> 
> No, they didn't. They probably simplified their formulas, but they
> should not round very soon (although, in Germany, I'm not so sure they
> use the right way. <g>).
You most probably never did calculations manually at all ;-)
>  just to reduce the amount of manual 
>> calculation. Dealing with more decimals in monetary calculations is a 
>> misfeature, introduced only by computers, and abused since the
>> beginning.
> 
> Nonsense. They are simply required to get the accuracy, i.e. in order
> to get a correct result.
As soon as rounding comes into play, there is nothing like a "correct"
result.
> If this is not done, it is out of convenience,
> but not correct.
Did you ever need a certification of your applications?
DoDi
0
Hans
10/16/2009 7:27:52 PM
Hans-Peter Diettrich wrote:
> > Nonsense. They are simply required to get the accuracy, i.e. in
> > order to get a correct result.
> 
> As soon as rounding comes into play, there is nothing like a "correct"
> result.
Indeed. One should not (have to) round. Decimal types can help with
that. Currency certainly can't. Take, say, 4.5% of an amount in Euro
and cent and you lost bits already. AFAICT, Currency does not round
either (but I could be wrong there, since it seems to be processed by
the FPU, i.e. it is probably not just an Int64).
 
> > If this is not done, it is out of convenience,
> > but not correct.
> 
> Did you ever need a certification of your applications?
Nope. 
So perhaps the Germans have a financial system that rounds back to
cents all the time and tells you where to round and when. They tend to
do things their own way anyway, and the way maths is taught is
horrendous (things are made overly complex and that is why so many
people don't understand or can't properly use even basic things like
percentage calculation).
And yet:
http://en.wikipedia.org/wiki/Floating_point#Minimizing_the_effect_of_accuracy_problems
<<
For this reason, financial software tends not to use a binary
floating-point number representation.[6] The "decimal" data type of the
C# programming language, and the IEEE 854 decimal floating-point
standard, are designed to avoid the problems of binary floating-point
representations when applied to human-entered exact decimal values, and
make the arithmetic always behave as expected when numbers are printed
in decimal.
>>

-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"It is practically imposible to teach good programming to 
 students that have had a prior exposure to BASIC: as potential 
 programmers they are mentally mutilated beyond hope of 
 regeneration." -- Edsger Dijkstra
0
Rudy
10/16/2009 10:21:16 PM
Hans-Peter Diettrich wrote:
> Markus Humm schrieb:
> 
> > and german tax forms are stupid by not allowing you to insert
> > decimal places for some things but rather round to the next whole
> > number as you like it (up or down what's better for you).
> 
> In every invoice you'll have to round numbers to the smallest unit of 
> the currency. Such nasty formal prescriptions require according code
> all around...
Yes, and that is quite silly, IMO. You take 30% of €1.37, and you must
round back to cent (€0.41), which means you lost 0.1 cent already.
This system is apparently still based on paper work and does not
account for decimal types and computers at all.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"Always code as if the guy who ends up maintaining your code will
 be a violent psychopath who knows where you live."
 -- Martin Golding
0
Rudy
10/16/2009 10:21:17 PM
Rudy Velthuis (TeamB) schrieb:
>> In every invoice you'll have to round numbers to the smallest unit of 
>> the currency. Such nasty formal prescriptions require according code
>> all around...
> 
> Yes, and that is quite silly, IMO. You take 30% of €1.37, and you must
> round back to cent (€0.41), which means you lost 0.1 cent already.
It's up to you to adjust your prices in a way, that rounding leads to 
your profit ;-)
> This system is apparently still based on paper work and does not
> account for decimal types and computers at all.
Computers are best suited to solve all problems, that wouldn't exist 
without them.
DoDi
0
Hans
10/17/2009 1:36:26 AM
Rudy Velthuis (TeamB) schrieb:
>> Did you ever need a certification of your applications?
> 
> Nope.
That answers everything. In your toy applications you can do whatever 
you like, but writing business applications means to accept the rules.

> So perhaps the Germans have a financial system that rounds back to
> cents all the time and tells you where to round and when. They tend to
> do things their own way anyway, and the way maths is taught is
> horrendous (things are made overly complex and that is why so many
> people don't understand or can't properly use even basic things like
> percentage calculation).
I wonder when you ever got a bill with more than 2 decimals in the 
amounts, or when you've been asked to pay your taxes or interests to the 
fraction of an cent.
DoDi
0
Hans
10/17/2009 1:36:28 AM
Rudy Velthuis (TeamB) wrote:
> 
> http://en.wikipedia.org/wiki/Floating_point#Minimizing_the_effect_of_accuracy_problems
> 
> <<
> For this reason, financial software tends not to use a binary
> floating-point number representation.[6] The "decimal" data type of the
> C# programming language, and the IEEE 854 decimal floating-point
> standard, are designed to avoid the problems of binary floating-point
> representations when applied to human-entered exact decimal values, and
> make the arithmetic always behave as expected when numbers are printed
> in decimal.
> 
Nice article. A little off topic, but it is interesting to note that 
Fortran compiler writers went to great lengths to control the order of 
operations and rounding behavior to ensure proper numeric results. The 
RM Fortran developers were reportedly masters of this black art on the 
Intel platform. I quickly gained an appreciation of how hard this can be 
when I had to write code for the 8037 (in the days when math chips were 
optional) to optimize performance.
Certain engineering problems, such as modeling the dynamics of high 
speed rotating machinery, can be very sensitive to rounding problems and 
suffer badly in the hands of poorly designed compilers. This is one 
reasons why "C" was often considered an inferior language for certain 
scientific applications.
-- 
David Taylor
eXtensia Technologies
http://www.extensiatech.com
0
david
10/17/2009 4:58:00 AM
Hans-Peter Diettrich wrote:
> That answers everything. In your toy applications you can do whatever 
> you like, but writing business applications means to accept the rules.
Indeed.
Try writing reports where all values hav a currency conversion applied and where the report is rejected if Sum(sub-totals) <> Sum for *displayed* values.
Can't do it without rules.
-- 
Mike
0
Mike
10/17/2009 5:28:54 AM
Hans-Peter Diettrich wrote:
> Rudy Velthuis (TeamB) schrieb:
> 
> >> In every invoice you'll have to round numbers to the smallest unit
> of >> the currency. Such nasty formal prescriptions require according
> code >> all around...
> > 
> > Yes, and that is quite silly, IMO. You take 30% of €1.37, and you
> > must round back to cent (€0.41), which means you lost 0.1 cent
> > already.
> 
> It's up to you to adjust your prices in a way, that rounding leads to 
> your profit ;-)
So we make our product €3,99, etc. <g>
> 
> > This system is apparently still based on paper work and does not
> > account for decimal types and computers at all.
> 
> Computers are best suited to solve all problems, that wouldn't exist 
> without them.
They can even solve problems that existed without them.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"If Tyranny and Oppression come to this land, it will be in 
 the guise of fighting a foreign enemy."
 -- James Madison
0
Rudy
10/17/2009 12:55:59 PM
Hans-Peter Diettrich wrote:
> > So perhaps the Germans have a financial system that rounds back to
> > cents all the time and tells you where to round and when. They tend
> > to do things their own way anyway, and the way maths is taught is
> > horrendous (things are made overly complex and that is why so many
> > people don't understand or can't properly use even basic things like
> > percentage calculation).
> 
> I wonder when you ever got a bill with more than 2 decimals in the 
> amounts, or when you've been asked to pay your taxes or interests to
> the fraction of an cent.
I live in Germany, so no, of course not. <g>
Actually, taxes are in full Euros.
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"The nourishment is palatable" -- Emily Dickinson, dying words
0
Rudy
10/17/2009 12:59:43 PM
Hello,
no taxes are not in full euros. Some items on the tax forms are, but the
tab bureau calculates a tax sum then which may incluse cents!
Greetings
Markus
0
Markus
10/17/2009 3:07:35 PM
Markus Humm wrote:
> Hello,
> 
> no taxes are not in full euros. Some items on the tax forms are, but
> the tab bureau calculates a tax sum then which may incluse cents!
Items in the tax forms are, however. That is what I meant. 
-- 
Rudy Velthuis (TeamB)        http://www.teamb.com
"Nothing is wrong with California that a rise in the ocean level
 wouldn't cure."
 -- Ross MacDonald (1915-1983)
0
Rudy
10/17/2009 3:20:37 PM
On Fri, 16 Oct 2009 15:21:16 -0700, Rudy Velthuis (TeamB)
<newsgroups@rvelthuis.de> wrote:
>Hans-Peter Diettrich wrote:
>
>> > Nonsense. They are simply required to get the accuracy, i.e. in
>> > order to get a correct result.
>> 
>> As soon as rounding comes into play, there is nothing like a "correct"
>> result.
>
>Indeed. One should not (have to) round. Decimal types can help with
>that. Currency certainly can't. Take, say, 4.5% of an amount in Euro
>and cent and you lost bits already. AFAICT, Currency does not round
>either (but I could be wrong there, since it seems to be processed by
>the FPU, i.e. it is probably not just an Int64).
Which is why I never use the currency type, only integer number of
pennies.
0
Loren
10/18/2009 1:10:51 AM
On Fri, 16 Oct 2009 22:28:54 -0700, Mike Orriss <mjo@3kcc.co.uk>
wrote:
>Hans-Peter Diettrich wrote:
>
>> That answers everything. In your toy applications you can do whatever 
>> you like, but writing business applications means to accept the rules.
>
>Indeed.
>
>Try writing reports where all values hav a currency conversion applied and where the report is rejected if Sum(sub-totals) <> Sum for *displayed* values.
>
>Can't do it without rules.
Yeah, that can be a real headache.
0
Loren
10/18/2009 1:10:51 AM
Rudy Velthuis (TeamB) schrieb:
> Markus Humm wrote:
> 
>> Hello,
>>
>> no taxes are not in full euros. Some items on the tax forms are, but
>> the tab bureau calculates a tax sum then which may incluse cents!
> 
> Items in the tax forms are, however. That is what I meant. 
Then we agree.
Greetings
Markus
0
Markus
10/18/2009 11:50:05 AM
> Just a tiny remark: you misinterpret Moore's law in my eyes. Moore's law
> only sais the number of transistors will double every 18 or 24 months
> (not sure about the number of months though). It doesn't mean these
> added transistors do more than consuming energy! ;-)
Sorry for the delay, I was away a few days.
I guess you are right. From Wikipedia:
Moore himself, who never intended his eponymous law to be interpreted so 
broadly, has quipped:
Moore's law has been the name given to everything that changes exponentially. I 
say, if Gore invented the Internet, I invented the exponential.
:-)
-- 
Jens Gruschel
http://www.pegtop.net
0
Jens
10/20/2009 5:11:45 PM
Reply: