On 11/15/2012 01:35 PM, Joe Marshall wrote:
On Thu, Nov 15, 2012 at 12:13 PM, Dmitry Pavlov mailto:dpav...@ipa.nw.ru>> wrote:
> "In hindsight, the use of quad precision appears to have been overly
> conservative for this problem"
Might be, and may still be, but the precision of
Matthew,
The changes you have made make much sense to us, thanks!
Right now we are looking into JIT and we plan to make our
changes starting from Monday 26.
If you plan to bring significant changes to JIT after that
day, then no problem, please give a notice--we can rearrange
our plans.
Regards
On Thu, Nov 15, 2012 at 11:54:35PM +0400, Dmitry Pavlov wrote:
> Hugh,
>
> I see your point, and I have nothing against Forth per se,
> and rewriting the whole thing in Forth could be an
> interesting research, but well, sometimes we need
> to deliver programs in time.
Re: Delivering programs on
On Thu, Nov 15, 2012 at 12:13 PM, Dmitry Pavlov wrote:
>
> > "In hindsight, the use of quad precision appears to have been overly
> > conservative for this problem"
>
> Might be, and may still be, but the precision of astronomical
> observation has grown much since the time the paper was
> writte
On Wed, Nov 14, 2012 at 6:16 PM, Hugh Aguilar wrote:
> This "Supercomputer Toolkit" looks pretty cool! I skimmed over the
> article, and will read it completely later on. Am I understanding that
> this uses integer arithmetic?
>
No, the Digital Orrery used floating point.
> It said that it su
Matthew,
> I've adjusted the bytecode compiler so that it can deal with more local
> types. To exercise the changes, fixnum results are tracked like flonum
> I plan to clean up the JIT a little bit to make it easier to add extnum
> unboxing, but that's a smaller set of changes. Let me know when y
Joe,
> The Supercomputer Toolkit (
> http://www.hpl.hp.com/techreports/94/HPL-94-30.html ) was
> designed for doing numerical integration of celestial bodies over large
> periods of time.
>
> "The Toolkit's compiler uses a novel strategy based upon partial evaluation
> [7, 9]. This exploits the da
Hugh,
> (/ 10 6)
> 1 2/3
> (/ 10 6)
> 1.7
> These are important distinctions for numerical programmers however.
Racket also has type-specific fl/ and unsafe-fl/, which we
use extensively in our type-specific part of code.
>> Our project is a large program, which has its own DSL
>
> The orig
On Thu, Nov 15, 2012 at 10:05 AM, Neil Toronto wrote:
> On 11/14/2012 07:38 PM, Matthew Flatt wrote:
>>
>> I've adjusted the bytecode compiler so that it can deal with more local
>> types. To exercise the changes, fixnum results are tracked like flonum
>> results, although the JIT doesn't currentl
On 11/14/2012 07:38 PM, Matthew Flatt wrote:
I've adjusted the bytecode compiler so that it can deal with more local
types. To exercise the changes, fixnum results are tracked like flonum
results, although the JIT doesn't currently take advantage of fixnum
annotations.
Now, it should be easy to
I've adjusted the bytecode compiler so that it can deal with more local
types. To exercise the changes, fixnum results are tracked like flonum
results, although the JIT doesn't currently take advantage of fixnum
annotations.
Now, it should be easy to add
#define SCHEME_LOCAL_TYPE_EXTNUM 3
and
ched to Scheme which has more
educational documentation available (such as SICP).
regards --- Hugh
From: Joe Marshall
To: Hugh Aguilar
Cc: "users@racket-lang.org"
Sent: Wednesday, November 14, 2012 5:48 PM
Subject: Re: [racket] 80-bit precision in Rac
Hugh:
> (/ 10 6)
1.7 this is what SICP says will happen (pg 5)
/First edition/ of SICP. Copyright 1985, thus predating even R3RS. The
language has evolved somewhat since then.
Do not take the contents of SICP as Scheme canon.
Ben
Racket Users list:
http://lis
> My understanding of Scheme, including Racket, is that types get converted
> automatically without explicit casting. This is not an add-on for the
> language, but is inherent in the language. For example:
> (/ 10 6)
> 5/3 this is what Gambit does
> (/ 10 6)
> 1 2/3this is what Ra
On Tue, Nov 13, 2012 at 10:43 PM, Hugh Aguilar wrote:
> > We are doing numerical integration of celestial bodies over large
> periods of time (100 years is a norm).
>
> I'm new to Scheme, so I may be totally wrong about this --- but, isn't a
> numerical program like this exactly what Scheme is *no
ich is in England.
best regards --- Hugh
From: Dmitry Pavlov
To: Erich Rast ; Hugh Aguilar
Cc: users@racket-lang.org
Sent: Wednesday, November 14, 2012 7:32 AM
Subject: Re: [racket] 80-bit precision in Racket
Eric, Hugh,
OOP surely is not what we chose
Eric, Hugh,
OOP surely is not what we chose Racket for.
This can lead to a lengthy discussion about the definitions of OOP,
level of support of OOP in Racket according to those definitions,
usefulness of OOP for different kinds of tasks, etc. I think we
better skip the whole OOP topic here.
We ar
Seems to me that Moore and Rather used Moore's FORTH at the National Radio
Astronomy Observatory before they started Forth Inc. So you might say that
FORTH is a 'natural' for Astronomy!
--hsm
On Wed, Nov 14, 2012 at 6:00 AM, Dmitry Pavlov wrote:
> Hendrik,
>
> > Is it conceivable that you need
Hendrik,
> Is it conceivable that you need multiple-precision fixed-point?
If would be OK in terms of numerical accuracy, but
I feel that it would not be good in terms of performance.
See the description for Neil Toronto's interface to MPFR:
https://github.com/ntoronto/racket/blob/master/collect
s makes the programs particularly maintainable or easy
to write, and icc is expensive and very hardware specific.
Best,
Erich
>
>
>
> Message: 1
> Date: Sun, 11 Nov 2012 15:11:50 +0400
> From: Dmitry Pavlov
> To: Matthias Felleisen
> Cc: users@racket-lang.org
ever, seems to be one of the few cases in which
Forth is a good fit.
Message: 1
Date: Sun, 11 Nov 2012 15:11:50 +0400
From: Dmitry Pavlov
To: Matthias Felleisen
Cc: users@racket-lang.org
Subject: Re: [racket] 80-bit precision in Racket
Message-ID:
Content-Type: text/plain; charset=UTF
On Sun, Nov 11, 2012 at 03:11:50PM +0400, Dmitry Pavlov wrote:
> Neil, Matthias,
>
> Certainly not #2, and I doubt that #4 is a problem for us
> (although it may be, buried somewhere in specific calculations).
>
> #1 and #3 definitely are our case. We are doing numerical
> integration of celestia
Neil, Matthias,
Certainly not #2, and I doubt that #4 is a problem for us
(although it may be, buried somewhere in specific calculations).
#1 and #3 definitely are our case. We are doing numerical
integration of celestial bodies over large periods of time
(100 years is a norm). The forces that ac
I could imagine a reason #5: you are porting programs from a language that
supports 80bits.
On Nov 10, 2012, at 4:41 PM, Neil Toronto wrote:
> On 11/09/2012 06:56 AM, Dmitry Pavlov wrote:
>> 2. Maybe we are cutting blocks with a razor here?
>> If there is any simpler way to have native 80-bi
On 11/09/2012 06:56 AM, Dmitry Pavlov wrote:
2. Maybe we are cutting blocks with a razor here?
If there is any simpler way to have native 80-bit
floating point in Racket (say Racket->ASM compilation,
Racket->C, LLVM, anything), please do tell me.
Here's another razor/brick-related question: Wha
As much as I love Racket, there are certainly times I miss 'C' and it's
ability to write code pretty much in assembler. As co-creator of the first
commercial fractal generation software (FracTools, FracInt was free not
commercial) I found the need to code down to the bare metal and a bit
beyond cha
At Fri, 09 Nov 2012 19:34:00 +0400, Dmitry Pavlov wrote:
> Matthew,
>
> > Your plan sounds workable, but I wonder whether you'll want the JIT to
> > unbox extnums in the same way that it unboxes flonums. That's not as
> > easy as the rest of the plan, but generalizing Racket's unboxing
> > machin
Matthew,
> Your plan sounds workable, but I wonder whether you'll want the JIT to
unbox extnums in the same way that it unboxes flonums. That's not as
easy as the rest of the plan, but generalizing Racket's unboxing
machinery to deal with more types is something that we can consider.
Surely we
Your plan sounds workable, but I wonder whether you'll want the JIT to
unbox extnums in the same way that it unboxes flonums. That's not as
easy as the rest of the plan, but generalizing Racket's unboxing
machinery to deal with more types is something that we can consider.
At Fri, 09 Nov 2012 17:5
Marc,
If performance is important, have you considered using Gambit instead? It
generates very good floating point code and it should not be too hard to extend
it to handle 80 bit floats.
Yes performance is important, but we also need Racket's
superb DSL creation feature
(http://docs.racket
Hello,
First, congratulations with Racket 5.3.1 release.
We are using Racket for our research project in
astronomy and we are very satisfied with it.
However, now we have come to the point where we
need extended precision (80-bit) for floating-point
numbers. We have seen some work done by Neil T
31 matches
Mail list logo
