[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Unit package proposals and questions

From: C Y
Subject: Re: [Axiom-developer] Unit package proposals and questions
Date: Thu, 8 Sep 2005 08:57:03 -0700 (PDT)

--- William Sit <address@hidden> wrote:
> No, I don't think so. So far, everything works even though users will
> be force to declare dimension and unit for each quantity (as we 
> agree below). However, the above is not the same thing. If a user is
> comfortable with defaults, that is, undefined identifiers are of 
> type Symbol (techically, Variable(s) for Symbol s), and any other 
> operations will be promoted to a higher domain, usually POLY
> INT, then that is fine. But if someone wants to work with say S :=
> EXPR INT and uses SIUNitSystem(S), then he will have to package 
> call the setDimUnit for an undefined identifier s.

Ho boy, this is where my limited understanding of strong typing rears
its ugly head.  I think we need to have sensible defaults for this (I'm
definitly opposed to forcing the user to think about such things unless
they choose to) but I agree we need to allow for more advanced uses. 
Ugh.  That will take some thought.
> In principle, we do NOT know the type of undefined
> identifiers. The Interpreter assumes we are using Symbol. This won't
> be assumed in the compiler.

OK, so we need to explicitly make some assumption in the definition of
the function I guess - so long as it doesn't make its way into require
default user syntax ;-).

> > Generating plots of dimensional quantities will be interesting, but
> > that's a bit down the road at the moment.  Does the above make 
> > sense?
> I may think a bit of the last action though: whether we allow an
> identifier to change its dimension. Say, what if I decide to
> "recycle" an identifier? 

Maybe that's where my "unSetDim" idea can come in?  We need a way to
undo what we do, but I don't think we want it to be automatic.

> Note that x0 in (5) has the same TYPE as the rhs BEFORE assignment.
> It should be legal, perhaps with a warning message, if the target
> dimension and unit do not match those of x0.

I think I disagree, if I understand you here - one of the primary
benefits I see of having generic dimensions without units associated
with variables is to enforce matching dimensions between assignments
and variables being assigned (this is another check on correctness, and
a useful one IMHO).  For example, if someone solves for a Moment of
Force quantity and tries to assign it to a variable defined to have
dimension Work, on the grounds that they have the same reduced
dimensions, Axiom can (and should, IMHO) stop them cold.  Which also
raises the point that we need to add a way to define a variable such
that it will accept any dimension who's reduced dimensions match,
proceeding on with those reduced dimensions.  Would it be possible (or
rather, interesting and useful) to have the state vector preserve the
history of derived -> reduced conversions?  Sort of a pedigree of where
the given unit/dimension definition came from, conversion wise?
> Certainly, the setValue function is still needed, but you may not
> want to export it. In the example, I was pushing the "convenience" 
> feature you have been advocating. I am glad you don't want to push 
> that far!

Nope, I know there are limits to convenience :-).  Just want to do the
best I can to ensure this sucker gets used, but if I didn't think
correctness was priority #1 I wouldn't be interested in doing this in
Axiom ;-).  At the user level, setValue should not be an option -
you're right, such actions are needed for manipulation at low levels
INSIDE the package, now that I stop and think about it - but they do
need to be very strictly internal.

> Great. May be a future project is to modify the interpreter to allow
> s:= 7 [ft] as syntactic sugar, once the foundation is done, 
> correctly.

That's a very good idea, but definitely lower priority at the moment.
> > We need to stay correct, but what I'm trying to do
> > is make things as convenient as possible while remaining correct.
> A very good ideal.

Well, I think the lesson of the commercial Axiom is that you need to
sell correctness and be as friendly as possible about it - otherwise
you starve from lack of users.  Axiom is open source now, of course, so
we don't have the financial problems, but we still need users to remain
(or become) a living, breathing project.  Be correct, but remember the
human side of the equation when possible, too.

> Yes, that would have made implementation much easier in the 
> conversion part. (I guess I have been "poisoned" by my 
> Mathematica experience in implementing units conversions).  

Well, Maxima did the same to me ;-).  I guess it's true what they say,
assume you'll have to try to implement something at least once before
you can properly define the problem.

> Yes, everything depends on how to coding goes! (especially when it 
> comes to the compiler). 

Ah, point.  So in general, it is not always useful to try something in
the interpreter as opposed to coding it and compiling it?  In Maxima,
generally speaking, it was all the same - I take it that's not the case
here?  Eeep.


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]