I was reading through the lexer and I noticed that we don't support
imaginary and complex literals like "1.0d + 0.5di". Would this be
something useful to have? We'd possibly would have to write our own
imaginary and complex types if there isn't a c++ version of them
available, unless you guys t
skaller wrote:
> should work. Or perhaps:
>
> const inf: double = "1.0/0.0";
I'd prefer that. I wish we could do this, but it doesn't compile because
of the "virtual const".
typeclass Floating[T] {
virtual const inf: T;
virtual fun isinf: T -> bool;
}
instanc
On 5/1/07, Erick Tryzelaar <[EMAIL PROTECTED]> wrote:
> I was reading through the lexer and I noticed that we don't support
> imaginary and complex literals like "1.0d + 0.5di". Would this be
> something useful to have? We'd possibly would have to write our own
> imaginary and complex types if ther
skaller wrote:
> Well, I am inclined to release 1.1.3 final soon. I have asked
> Mike to package 1.1.3_rc4 but so we do a final test on
> the debian autobuilder, however no response so far.
>
> I don't think we can wait for a perfect (bugless) system.
> I'm inclinded to release so we can move on.
>
On Tue, 2007-05-01 at 11:56 -0700, Erick Tryzelaar wrote:
> I was reading through the lexer and I noticed that we don't support
> imaginary and complex literals like "1.0d + 0.5di". Would this be
> something useful to have? We'd possibly would have to write our own
> imaginary and complex types
On Tue, 2007-05-01 at 12:14 -0700, Erick Tryzelaar wrote:
> skaller wrote:
> > should work. Or perhaps:
> >
> > const inf: double = "1.0/0.0";
>
> I'd prefer that. I wish we could do this, but it doesn't compile because
> of the "virtual const".
That's a bug. I tried to make it work, but i
On 5/1/07, skaller <[EMAIL PROTECTED]> wrote:
> If we go up to Quaternions, they use i,j,k. You may have
> used quaternions in high school physics, you write:
>
> 10 + 3i + 4j + 5k
Don't forget about octonions :)
Also, quaternions are useful for 3D rotation transforms; I'm sure some
game
On Tue, 2007-05-01 at 15:36 -0400, Chris King wrote:
> On 5/1/07, Erick Tryzelaar <[EMAIL PROTECTED]> wrote:
> This
> gives a speed boost when working mostly with multiplication, and the only
> overhead is boxing/unboxing the values (and branching on their type).
Felix doesn't box products :)
O
On Tue, 2007-05-01 at 15:36 -0400, Chris King wrote:
> If you don't mind, I'd like to get my hands dirty implementing this as my
> first Felix project... school's finally out so I've got some free time and
> would love to give Felix this feature that so few other languages have :)
Sure! It might
On 5/1/07, skaller <[EMAIL PROTECTED]> wrote:
> ** In the end, i hope to merge classes, typeclasses
> and modules into a single 'class' construction.
Yay!
> typeclasses with variables (not just type variables)
> make sense .. the functions are just methods and the
> variables live in an dynamical
On Tue, 2007-05-01 at 13:01 -0700, Erick Tryzelaar wrote:
> I'm fine cutting a new release. What do you think about changing the
> version numbering though? The standard approach is major-minor-bug
> fixes, and I think typeclasses are important enough to bump up the minor
> version. To give us
On Tue, 2007-05-01 at 13:01 -0700, Erick Tryzelaar wrote:
> skaller wrote:
> One smallish thing I'd like to see is that we really do have a ton of
> keywords, and I don't think all of them are really used. I think we may
> have 2-3 times as many keywords as the other major languages. Perhaps we
On 5/1/07, skaller <[EMAIL PROTECTED]> wrote:
> In principle I think 'complex' and 'complex with infinity'
> are different types, but then complex+inf only has ONE
> infinity, quite different from 'number too large' which
> might retain a phase angle.
Infinity+phase angle is different than "number
On Tue, 2007-05-01 at 20:54 -0400, Chris King wrote:
> On 5/1/07, skaller <[EMAIL PROTECTED]> wrote:
> > ** In the end, i hope to merge classes, typeclasses
> > and modules into a single 'class' construction.
>
> Yay!
>
> > typeclasses with variables (not just type variables)
> > make sense .. th
On Tue, 2007-05-01 at 21:06 -0400, Chris King wrote:
> On 5/1/07, skaller <[EMAIL PROTECTED]> wrote:
> > In principle I think 'complex' and 'complex with infinity'
> > are different types, but then complex+inf only has ONE
> > infinity, quite different from 'number too large' which
> > might retain
On 5/1/07, skaller <[EMAIL PROTECTED]> wrote:
> You'd use distinct types I think. Consider a matrix of 100 * 100
> elements -- the whole matrix would either be polar or cartesian
> surely, not individual elements.
Good point, I'll have to see how much I can work into the type system
and still keep
Erick Tryzelaar wrote:
>> And what should we move on TO?
Some more things:
1. There are a couple deprecated functions in the standard library, such
as int_of and size_of that we should eliminate.
2.. We've talked before about calling _ctor through a module access,
like "var x = List::list[int
skaller wrote:
> So for example we might be able to do
>
> module X {
> statement while expr do statements done #=> ...;
> }
>
> without the current hackery. In particular
>
> open X;
>
> could make the syntax extensions available, instead of
>
> #import
>
>
Chris King wrote:
> On 5/1/07, skaller <[EMAIL PROTECTED]> wrote:
>> You'd use distinct types I think. Consider a matrix of 100 * 100
>> elements -- the whole matrix would either be polar or cartesian
>> surely, not individual elements.
>
> Good point, I'll have to see how much I can work into the
skaller wrote:
> Felix doesn't box products :)
>
> OTOH atm complex is whatever representation C++ uses.
>
We could just hide away the system version of complex like we do with
all the stl stuff for compatibility, and make our own :)
---
skaller wrote:
> Mike Furr has built _rc4 and i've asked what to do with the
> tarball name. I'm loathe to upload a plain 1.1.3 from svn head
> in case it breaks something, but renaming the tarball won't
> change the internally reported version number (which will still
> say _rc4).
>
Really wha
On Tue, 2007-05-01 at 19:15 -0700, Erick Tryzelaar wrote:
> Erick Tryzelaar wrote:
> >> And what should we move on TO?
>
> Some more things:
>
> 1. There are a couple deprecated functions in the standard library, such
> as int_of and size_of that we should eliminate.
>
> 2.. We've talked befor
On Tue, 2007-05-01 at 19:18 -0700, Erick Tryzelaar wrote:
> skaller wrote:
> Oh that looks very nice.
Except i can't get dypgen to work at the moment lol ..
> I hope that parser works out for us! If it
> does, would that mean we could get rid of elkhound?
Nope, because that's a run time thing
On 5/1/07, Erick Tryzelaar <[EMAIL PROTECTED]> wrote:
> Does this problem occur if we do proper conversions to and from polar
> coordinates?
Although that would work in some cases (such as exponentiation), there
would still be information loss in certain edge cases, since Cartesian
coordinates can
On Tue, 2007-05-01 at 19:24 -0700, Erick Tryzelaar wrote:
> Does this problem occur if we do proper conversions to and from polar
> coordinates? Are polar coordinates uniformly better than cartesian?
No, it depends what you're doing.
> If
> so, could we just fix this by making the underlying
On Tue, 2007-05-01 at 19:49 -0700, Erick Tryzelaar wrote:
> Do you know the revision number of the version you sent Mike?
Nope, though I can ask him. However it isn't clear it is
worth bothering with branches etc at this point. If something
fails for a user I don't want to go back and patch and
On Tue, 2007-05-01 at 23:31 -0400, Chris King wrote:
> This is more or less what I'm thinking... operations such as
> exponentiation that require polar coords will always return a
> pcomplex, whereas operations such as addition will always return a
> ccomplex, thus moving a lot of the burden into
skaller wrote:
> On Tue, 2007-05-01 at 19:49 -0700, Erick Tryzelaar wrote:
>
>
>> Do you know the revision number of the version you sent Mike?
>>
>
> Nope, though I can ask him. However it isn't clear it is
> worth bothering with branches etc at this point. If something
> fails for a user
On Tue, 2007-05-01 at 20:49 -0700, Erick Tryzelaar wrote:
> skaller wrote:
> It shouldn't be that bad if we only make the release branch near when
> things are stable. The advantage of having a small set of devs is that
> it should be relatively easy to manage this. We should at least tag the
>
On 5/1/07, Erick Tryzelaar <[EMAIL PROTECTED]> wrote:
I was reading through the lexer and I noticed that we don't support
imaginary and complex literals like "1.0d + 0.5di". Would this be
something useful to have? We'd possibly would have to write our own
imaginary and complex types if there isn
skaller wrote:
>> It shouldn't be that bad if we only make the release branch near when
>> things are stable. The advantage of having a small set of devs is that
>> it should be relatively easy to manage this. We should at least tag the
>> release to make tracking things a little easier.
>>
31 matches
Mail list logo
