[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: |
Tue, 6 Sep 2005 02:46:46 -0400 |
User-agent: |
KMail/1.8.2 |
On Sunday 04 September 2005 01:22 am, William Sit wrote:
> ---------- General discussion on documentation
>
> C Y wrote:
> > --- William Sit <address@hidden> wrote:
> > > you have already started real work.
> >
> > That's probably too generous - I've started trying to become informed
> > enough to start real work, really. Bill is probably going to flinch
> > when he sees my idea of basic pre-code (heck, it's really pure
> > background) documentation :-).
>
> Tim will love you!
Well, we'll see - it's way more of a challenge that I thought it would be
originally! (Which I guess is what Axiom is all about, in a way :-).)
> > I hope so, although I suspect your ideas are far more useful than my
> > own - I'm just asking questions and swatting user level features around
> > in my head at this point. The hard part (and interesting part) is
> > expressing them in relation to Axiom's mathematical rigor.
>
> You are welcome to ignore or include in your work/paper any ideas I
> presented on this forum.
Thanks! (Of course, that presupposes I can work my head around them... ;-)
> The hardest part is knowing questions to ask, and second is figuring out
> the answers; the easiest (though by no means trivial) is to code the
> solutions.
Well, that's the sign of using the right method of problem solving, at least!
> ---------- Basics of the proposal: Representation of UnitSystem domains
>
> This comment of yours is based on your breaking up UnitSystem into Static
> and Dynamic Unit System. This is certainly possible, but see my comments in
> the section on Static vs Dynamic user environment, which will list some
> pros and cons on this break up.
OK, will discuss later.
> > I think the latter is a matter of convenience - converting relative to
> > the current system is also doable via input unit -> SI -> output unit -
> > if I understand you what you are doing is precompressing this two step
> > process into one for the default "output" system?
>
> The relative factor can either be built-in for the UnitSystem domain, or
> via the SI mechanism. But we have to remember that SI is not universal
> (supermarket manager example). So a relative factor setup solves the
> general situation and is also more efficient. The SI approach is mainly for
> scientific applications AND conversion between two drastically different
> systems. Believe me, in less than 30 years, symbolic computations will be
> used by economists, if not already. (Mathematica has an operations research
> package, sold separately).
Hmm. OK, I'll go along with that.
> Yes, I am more in favor of every UnitSystem domain being dynamic (again,
> see that section). As to shortening the Rep, yes, in principle, for
> "scientific" unit systems, it only needs a conversion factor relative to
> SI, and yes, for static unit systems, the relative conversion factors are
> not needed either. However, SI is not everything, so the relative factors
> will be needed in those cases, and SI may be replaced by another standard
> unit system.
OK. The concept of an "Information" dimension, (i.e. whatever underlies the
concept of bytes as a unit) convinced me of that. Neither SI nor the seven
physical Basic Dimensions are sufficient.
> C Y wrote:
> > This is definitely interesting, but I'm not sure we want such an ability
> > to be the default - I would suggest hiding the conversion factors unless
> > the user specifically specifies otherwise. I like the idea of the
> > ability to explicitly show them though :-).
>
> What you meant then is to have something like:
>
> setSymbolicConversion(): Boolean
>
> as default True, which will include symbolic conversion factors. Setting
> this False will use numerical values. However, if you meant that when I
> setDimUnit("Length", "cm",x) and x was in "m" originally that it will
> output only x [cm] instead of x m2cm [cm], then I don't agree.
Oh, I think I get it - you're discussing the case where the user does the
following:
a) assign a variable (call it "x") not only a specific dimension but also a
specific unit. (I expect this to be somewhat unusual but it should be
legal.)
b) either the unit assigned was different from the current global, or the
current global is changed. Now when "x" is evaluated that unit must be
converted.
c) we want to show that conversion descriptively (or have the option to).
Agree.
What I was thinking about was probably setDim("Length", x). My mistake - you
were thinking further ahead than I was.
> ------------ Basics of the Proposal: UnitSystem domain specifications
>
> The following addresses only the user interface specifications under
> discussion and is not a complete specification for the category:
>
> C Y wrote:
> > I don't quite understand s:S - can you give a specific example of this
> > difference? Also, I'm not following why you would want to make any
> > local vs. global distinctions here - wouldn't it be neater just to have
> > the set commands work in the CurrentUnitSystem, and base things off of
> > Static UnitSystems for definitions unless a totally custom conversion
> > is being defined?
>
> In the setDimUnit, 'setDimUnit' commands, an expression s:S is involved,
> where S is a domain that usually contains symbols ("RetractableTo Symbol"
> in Axiom jargon) and s:S means s is such an expression.
OK. So in words, s is some specific symbol defined in the domain S.
> Of course S can be just Float if no symbols are involved, in which case,
> expressions and variables are simply constants. But the user assigns a
> dimension and unit to an expression, which will change the way certain
> variables involved in the expression are inputted or outputted. This
> setting is for a specific expressions s, so has "local" scope.
OK (I think.)
> The other 'setUnit' is local for a
> specific dimension, but has a wider scope and affects all expressions of
> that dimension. Finally, the 'setUnitAll' is global in the sense that all
> derived dimensions involving that specific dimension and all expressions in
> all those derived dimensions will be affected. The implementation will be
> assisted by the UnitConversion domain and the Rep remembers the conversion
> factors both relative to the current system and to the SI system, when
> possible.
I think I've got it - so there are three levels:
a) change properties within a single expression, don't change global settings
b) change global settings for one dimension, but not for other dimensions
building off of this one
c) change global settings for ALL dimensions using this dimension - e.g. the
default rendering for force would become kg*cm/s^2 if
setUnitAll("Length","cm") were used.
> My proposal allows (but the decision is still open) changing the units for
> a single expression s:S -- 'setDimUnit(dim,u,s)'. It also allows changing
> the unit of a single dimension, say Length, in the current (loaded) unit
> system without affecting other derived dimensions that involve Length --
> 'setUnit(dim,u)'. Finally it allows changing the unit of a single
> dimension, say Length, and any other derived dimension that involves
> Length, such as Velocity -- 'setUnitAll(dim, u)'.
>
> In your example above, changing the unit of Length
> from "m" to "cm" will report the unit of Force (the dimension of "N")
> either still as "N", if 'setUnit(Length,"cm")' is used in SI; or as
> kg-cm/s^2 (by changing the value of any expression with dimension Force by
> a conversion factor m2cm), if 'setUnitAll(Length,"cm")' is used in SI; in
> which case, the new unit of "Force" is "kg-cm/s^2" or "kilodyne", following
> SI prefix convention (basically changing SI, which is MKS based, to CGS).
So let's say I define some examples (sorry, I'm not up enough on Axiom syntax
yet to use it for this) would this be roughly how things would work?:
a::Length
b::Length
c::Force
setDimUnit("Length","cm",a)
setUnit("Length","m")
setUnit("Force"", "N")
-> a
a cm [Length]
-> b
b m [Length]
-> c
c N [Force]
setUnitAll("Length","km")
-> a
a cm2km km [Length] (or would this stay as cm?)
-> b
b m2km km [Length]
-> c
c m2km kg km / s^2 [Force] (with better formatting)
setUnitAll("Time", "millisecond")
-> c
c m2km s2ms^-2 kg km / ms^2 [Force]
[snip]
> Each expression requires one lookup at the
> time its dimension and unit is set. All subsequent uses and display will
> avoid the lookup again even if, in case of a variable, it is reassigned to
> a different value. All necessary conversion is taken care of by the
> arithmetic operation in the UnitSystem domain.
OK, I think I like this.
> > Does that mean an interpreter update is needed.?
>
> I hope not! The 'update()' function can handle that. We should not modify
> the Interpreter for this project unless it is absolutely necessary, which
> so far, I don't see. It is possible for the 'setDimUnit' function in the
> UnitSystem domain to record all calls to the 'setDimUnit' command to create
> and maintain a live list of variables or expressions, say as part of the
> state vector. An update can either be applied for just one variable in the
> domain, or all variables in this live list.
OK - so long as these things can be handled automatically (I had to hack in a
mechanism in Maxima to do autoconverting globally.)
> ---------- Implementation issues: Updating variables and their units
>
> Some updating questions are raised and solutions suggested in the Scenario
> Example section above.
>
> > As for current variables, shouldn't they be updated automatically by
> > the global update?
>
> That is the idea. That is, a 'setUnitAll(dim, u)' command will change all
> output and input variables/expressions that are of dimension dim to use
> unit u. In the scenario Example section, we discussed the issues and some
> possible actions. The basic design question to decide is: should this
> global command affect only newer variables/expressions or should this
> retroactively set all existing variables/expressions? The basic
> implementation question is: what data structures will support these
> functionalities efficiently (bear in mind some trade offs between memory
> and CPU time, as usual)? It seems the proposed state-vector can support the
> implementation, whatever the decisions.
I think I would vote for retroactively setting all non-derived unit using
instances, with perhaps another command to make this change without updating
previous instances. (How about setUnit is retroactive and changeUnit is from
this point forward?)
> > I would have thought all you needed was a single command SetUnits()
> > command, which would take a minimum of one argument and a max of one
> > unit per available dimension, e.g.
> >
> > SetUnits(nm,N,inches);
>
> [NB, Axiom convention:function names should start with lower case]
>
> I do not quite follow. Your example has three arguments, all units of
> Length.
Not quite - N is force. That was a mistake on my part - I meant something
like setUnits(g,N,inches). The above should have (and does, in Maxima)
return an error.
> I think you are thinking of 'setUnitAll(dim, u)'? Maybe a simpler
> 'setAll(u)' and let the system figure out the dimension of u? (But as
> explained below, this reverse lookup from unit to dimension is not unique;
> in that case, we can make 'setAll(u)' return an error message with some
> choices (probably not all possible choices). So you would still need the
> version 'setUnitAll(dim,u)' after the user picks one of those choices.
Yes, I understand your scheme better now.
> Your line:
>
> SetUnits(nm,N,inches);
>
> is, as far as I can follow, a global set.
In Maxima, I think this works as a global setting (retroactive) of all
non-derived instances of a dimension to a new length - essentially the same
as doing
setUnit("Mass","g")
setUnit("Force","N")
setUnit("Length","Inches")
but letting Axiom figure out that g is a unit of Mass, N is a unit of Force,
and Inches is a unit of Length.
> Surely, in this simple example,
> Axiom can figure out that these (nm, N, inches) (aside: use "in" for
> "inches" -- SI recommendations) are units for Length, but as explained,
> this is not possible in general. My version 'setUnitAll(dim, u)" only does
> this for a particular dimension dim and a particular unit u. I don't know
> why you set the Length dimension to THREE different units.
Typing error ;-). I meant to set the unit of three different dimensions.
> Are you imagining mixing units for the same dimension in one session?
> How are you going to tell which variable/expression will use any one of
> these three units? Are you saying that ALL three units should be reported
> for ANY variable/expressions of dimension Length? (Note: even if you are
> mixing units, the Rep will support it. I just want to know what your line
> meant.)
The line meant I was sleep deprived ;-) Hopefully round two makes more sense.
The potential to report a single quantity in a list of different units, one
converted quantity to a list entry is interesting but not really what I was
after.
> Fair enough. We can ALWAYS add defaults. The example I gave in my last
> message (added above in Section on UnitSystem specification):
>
> setDim(dim: Dimension, s:S):% == setDimUnit: (dim, unit(dim), s)
>
> performs a lookup for the default unit for a given dimension in the current
> UnitSystem. The 'setAll(u)' above can handle cases where an automatic
> lookup results in a unique dimension to set the dimension field in Rep.
> However we do not want to look up repeatedly each time we use a variable,
> so the results are memorized in Rep.
OK, that should do it.
> And, yes, users should know the dimension of the unit they are inputting.
> One danger with something like 'setAll(u)', which left out the dimension
> for u, is that a simple typo say from 'setAll(cm^2)' to 'setAll(cm^3)'
> would not be caught and play havoc in subsequent computations. Forcing the
> user to give the intended dimension provides a better chance that these
> errors will be caught.
I agree - I would like to have a "strict" mode available which compels the
user to do this. I fear making it the ONLY alternative will lose us users
though.
> > Maybe as a time saving alternative SetUnits could also
> > accept things of the form <UnitSystem>::Unit or some such, which would
> > limit the search space it would need to check?
>
> I don't follow the syntax of <UnitSystem>::Unit. Is :: coercion in Axiom? I
> have not heard of coercing a domain into a category. Perhaps you are
> thinking of a package call to a domain in UnitSystems? That would be
> setAll(u)$domain. But I do not like this default setAll(u) for reasons
> above.
Uh, nevermind. I didn't understand your proposal as thoroughly as I needed
to. I meant to say one could say something like setUnit("SI/cm") or
setUnit("SI->cm") or whatever makes sense.
> > Or even better, if
> > Axiom is up to it we might also be able to build a toplevel hash table
> > of all defined units in all unit systems at compile time which can
> > quickly match up a unit up with a UnitSystem and Dimension.
>
> The UnitConversion domain (perhaps category) is for this purpose. I am
> still thinking about whether UnitConversion should be a category with many
> domains or just one domain. The many-domain approach may provide better
> efficiency for more localized conversion systems and flexibility future
> additions.
Yes, I think we might want to do something like that - it would allow (or
would it?) the possibility of a UnitConversion category with domains for
PhysicalUnits, ComputerUnits, EconomicUnits, etc.
> As we don't know all the expert areas now in existence, nor do we know what
> new derived dimension or unit we may need (especially in 30 years' time),
> there is no way we can have such a universal toplevel hash table. We CAN
> implement SI (all the default and acceptable dimensions and units) or even
> more, but such a domain will need to be revised to allow newer dimensions
> and units. The design proposed will allow this of course (any design in
> fact), but I still subscribe to the older Axiom philosophy that we do not
> modify existing libraries except for bugs, and extend existing libraries
> through additional implementation. We should allow arbitrary UnitSystems
> (as I also indicated in my last email, supermarket manager will need a
> totally different, "non-scientific" unit system with dimensions like
> "Coke", "DietCoke", etc.)
I agree. I'm really curious to see if something like this ever gets used in
such an application :-).
> ---------- Implementation Issues: Setting up Dimension and Unit domains
> C Y wrote:
> > Dimensions
> > may not always map uniquely to Units, but Units DO map uniquely to
> > dimensions.
>
> Your last remark is wrong, unless there are already standard terminology
> such as in the case of Work vs Moment: standard energy-units exist as
> Joule, erg, eV, etc. and moment-units exist as N-m, etc.
Ah, point. Darn.
> In other cases,
> you may have to create new standard names first.
How about we allow the mapping to go through when it IS unique, and return an
error or ask a question if it isn't (something like provide a list of
options, and ask the user to select one)? (Maxima has the ability to ask
questions of the user if it needs to - it makes some problems MUCH easier to
solve.) This is helpful and friendly to the user while still being fully
correct.
> However, the problem still
> is: given some unit in reduced basic dimensions such as
> (mass-length/time^2).length, say kg.m^2/s^2, we do not know if the
> dimension should be Energy (either Work or Kinetic Energy or Potential
> Energy) or Moment. Vectorizing some of these dimensions may help: Work is a
> force vector times a length vector, and so is moment, but the two length
> vectors have different directions with respect to the direction of the
> forces.
Woo boy. That's going to be a challenge to report - direction of length
vector as a factor in results. Actually, that's an interesting question -
two length vectors may have different components, but the same magnitude.
Does the unit meter represent merely the magnitude, or the vector information
as well? How do we represent vector information if we want to preserve it
through the process of reducing dimensions? The Work vs. Moment example
would seem to argue that vector information and Dimensions can't really be
separated, but I don't really know if I'm interperting that right.
> --------- User environment for Unit systems: Static vs Dynamic
> All Axiom variables are typed. So once a user started computating using a
> UnitSystem domain, say A, all his computations will be in that unit system.
> If he then change to SI, he would have to coerce them to SI, which may or
> may not be possible, depending on what dimensions and units are in A. (So,
> the domain A, and the UnitSystems category, may have to include functions
> like convertIfCan: % -> SI).
Hmm, good point.
> I think you want somehow to restrict some users (say students who are
> learning about units and dimensions) not to allow them to "mess" with a
> UnitSystem domain like SI. I don't see the necessity because most likely,
> such users will only want to do their computations in whatever unit system
> is the default. Even if they were to use 'setDimUnit', 'setUnit', and
> 'setUnitAll' (which would be a good experience), these only affect the
> interpreter session and will not modify the SI domain at all. The
> state-vector does not survive an axiom reload since no modification to the
> compiled code is performed.
Ah, OK.
> Also a user can save the history of all inputs,
> including all 'set' commands (and also ')set' commands) and put them in
> axiom.input or a 'myunitmod.input' and read it in anytime. There is no
> need, in this dynamic design, to modify ANY compiled domain in the
> UnitSystem category. When a user wants to have modification compiled into a
> modSI domain, he will have to edit the SI.spad.pamphlet and change it into
> modSI.spad.pamphlet and compile it. However, I don't see the necessity.
> Your idea of
> 'SaveUnitSystem(<newUnitSystemName>) is difficult (but not impossible) to
> implement and involves automatically editing say SI.spad.pamphlet to
> modSI.spad.pamphlet and automatically compiling it. It is trivial for a
> user to read in an input file instead.
Actually, that was more my idea - have the saveUnitSystem command pick out all
the most recent inputs that set the UnitSystem environment, and save them to
a file. The trouble is to pick out such commands, which was why I thought it
might be simpler just to diff the "current" environment from the "default"
environment and autogenerate the minimum set of commands to get from a to b.
> I note that each of our positions on this user environment issue has turned
> 180 degrees from earlier communications :-).
Hehe :-).
[snip]
> Requiring rebuilding the hash tree is not a good idea because a domain is
> supposedly stable once built. Plus, if someone adds a new UnitSystem
> domain, who would be responsible to rebuild the single hash tree? If the
> new domain introduces new dimensions and units, it should create a
> corresponding UnitConversion domain (hash tree) and leave the standard hash
> table alone.
Hmm. Yes, a hash tree makes sense only when polluting the namespace.
> --------------- Name space issues
>
> > (I'm still
> > plotting to allow the user to gobble up all the unit names in the
> > default namespace at their option, and that will DEFINITELY need
> > interpreter work.
>
> As you know, I am strongly against "gobbling up all the unit names in the
> default namespace' even if it is 'at their option'. If you are seriously
> thinking about student use, you know the average students will exercise
> their options without knowing or understanding what they are doing. There
> is no way to consistently reserve SOME unit names in namespace, and not
> others. Any code to implement this will have to know the reserved names a
> priori and that means ALL the abbreviations in SI units at a minimum.
Right. Reserving some would be worse than none, because it would be
inconsistent.
> You would have created a nightmare in using the interpreter by requiring
> users to avoid any SI unit abbreviations as user variables. No computer
> language ever has that many reserved words. Note: Axiom function names
> are NOT reserved, but constructor (which may be category, domain or
> package) names and their abbreviations are.
If we were talking about a normal computer language, I agree. However, in
normal scientific usage, proper definition and use of equations should NOT
use SI abbreviations as variables. Doing so creates far too much potential
for misinterpreting said variables later on. I grant that your proposed
system has a far better chance than any I have ever seen or heard of of
making this workable, by being able to separate out m the variable and m the
unit in the output even if they look the same to the human eye - e.g.:
(1)-> 3*setUnit("Length","m","m")
3m m
[Length]
If this can actually function, then I am for it because it would be a
virtually ideal solution, and it is more general in case other, non-physical
unit cases need that generality.
> Modifying the interpreter because of a specific category or its domains is
> a bad idea. Any modifications should be general purpose or fixing bugs.
OK. That I agree with.
> Most users
> will want to have more flexibility. I think even for student use, if they
> want to experiment with changing units (at run time), why should that be
> forbidden? (for that matter, Axiom being open sourced, why should ANYTHING
> be forbidden?)
Well, I might answer "encouraging correct and best practices" but that's only
a good argument for defaults and utilities, not coding in limitations.
> There is perhaps one way to use variables (instead of strings) for
> dimensions and units, but they will be local to the domain (using domain
> namespace, rather than user namespace) and they will not be assigned any
> value. The advantage over strings is that they can be used to perform
> arithmetic operations of multiplication and division as symbols. Then
> general conversion factors can be computed by setting up a small number of
> conversion rules and by solving an equation.
I'm beginning to see how this might work - visually speaking though, it hinges
on the robustness of Axiom's separating units and non-units in output. I
think Axiom might be able to do this in a way most other systems couldn't (at
least not without a lot more work).
> Default relationship (tables) for conversion tables (which include both
> dimensions and units) and the dependencies like state-vectors, can use hash
> tables.
Or whatever is easiest/best. I don't know offhand that hash tables are.
> ---------- Implementation Issue: Simplification of dimensions
> C Y recently wrote:
> > OK - so how to we represent this in a CAS? Or more specifically, what
> > about the fact that a dimensionless constant has dimension that cancels
> > is useful for us to display, and how do we go about it?
>
> We can do this:
>
> piInEqn1:= setDimUnit("Length/Length", "m/m", %pi)
>
> or
>
> piInEqn1:= setDimUnit("1", "1", %pi)
>
> but
>
> piInEqn2:= setDimUnit("Degree/Radian", "deg/rad", %pi)
>
> Perhaps we can add a field to Rep that gives the reduced dimension as well?
> or provide a function
>
> reduce: Dimension->Dimension
>
> (which in any case, will be useful and necessary).
Yes, I think so. Is the concept of reduced dimension defined anywhere?
[snip]
> Yes, unless given other examples, I think this is a way to get out of the
> dilemma. Of course, the strong typing of Axiom already drove developers
> nuts, and I'm afraid, surely, the strict setup to dimensions and units may
> likely do so to scientists or economists. This is the price to pay for
> insisting on formal correctness.
Perhaps not as bad as I originally thought, but the documentation for use will
be critically important. Perhaps that is an argument to continue work on the
much less correct but perhaps friendlier in the short term Maxima units
package, which I see now is focused exclusively on Physical Units.
> > > >Could unit and dimension cancelation be handled
> > > >on a per dimension basis?
> > >
> > > May be, or may be not. It depends on the physical meanings of the
> > > variables. If I have price at $5/m multiplied by 7 m, I should get $35.
> > > If I have 8 N divided by 2 m^2 for pressure, and N has dimension
> > > kg-m/s^2, is it ok to cancel one of the m? So a single rule of Length
> > > (m) is not applicable to all cases.
> >
> > This will need to be handled, somehow. Are there any good references
> > that contain the applicable rules for us to implement?
[snip interesting references]
> Whether any such references will help us develop the rules to simplify
> dimensions, I don't know. From what we have discussed, it seems any rule
> will need some expert knowledge (in the example I gave, the expert
> knowledge is simply what pressure is). So I believe the best solution may
> be to "leave it to the users", and let them create their own names and
> simplification rules.
Sounds good. How about as good setups are created we merge them into Axiom?
Perhaps Axiom will become the central repository for advanced unit
interaction rules, as people build off of the (hopefully) sound foundation of
Axiom?
> This means that in a UnitSystem domain, there ought
> to be facilities to handle rules of simplifications, where some common
> defaults can be implemented. Axiom has a RewriteRule domain that can help.
> RewriteRule can also be used efficiently to perform conversion. (I once
> wrote a UnitConversion.nb in Mathematica for a course using this idea: all
> conversion factors between the two units for the same dimension is then a
> simple Solve[unit1 = x unit2, x])
Hmm. Worth some thought.
> > You mentioned $ interacting with meters, and in a previous email kilobits
> > and kilobytes were also mentioned. Unfortunately, neither money nor bits
> > of information are covered by any combination of SI units I am aware of.
> > So perhaps our top level category should be not simply Dimensions but
> > PhysicalDimensions, and we could perhaps implement some other Categories
> > for Dimensions not covered by SI (like money and bits, both of which are
> > Basic Units as far as I can tell). Money might be defined in terms of
> > other things in some sense, but that definition is as complex as society
> > itself and ever changing. Fascinating issues, but perhaps those should
> > wait for later. Indeed, does it even make sense to include a concept like
> > money in a system intending to stick to strict mathematics as much as
> > possible? I suppose yes since we can think of practical uses, but
> > thinking about it is making my head hurt ;-).
>
> "Now, you're thinking!" :-)
>
> In my case, thinking about these things make me stare at the screen and
> then fall asleep! But you got a point here, building unit systems should
> include, or at least allow future inclusion, of systems outside of the
> usual scientific sphere. So having an WallStreetDimensions,
> SupermarketDimensions, FontsMetricDimensions systems would be fun
> but we don't have to implement them right away.
Without doubt scientific units will be the most useful in the short term.
Building scientific symbolic computing on top of Axiom is going to require,
as near as I can tell, three things:
a) the concepts of Dimensions and Units (underway)
b) Significant Digits, Uncertainty in Measurement, and Error propagation
(hard, both in itself and also since potential errors due to the numerical
calculations of the computer must also be considered in order to be rigorous)
c) Domains of significance. I don't know what else to call this, but as an
illustration, we know that Newton's laws of motion break down near the speed
of light. Science generally gets on with life by neglecting Einstein type
effects at velocities which are low compared to c, since any possible
contribution due to those effects is washed out and below any significant
level of measurement possible. So, let's say we input the fully general
equations into Axiom for motion, velocity, etc. since we like generality.
However, for sufficiently small velocities (or more correctly, sufficiently
imprecise) measurements, we want to use Newton's equations, even
symbolically. They should (and do) simplify in the limit, and we want Axiom
to be able to understand or even figure out such things on request, since
such information is very useful to practical work. Plus, it would be an
awesome way to build intuition on when things matter. The problem is, there
would need to be a definition given for sufficiently imprecise. Either
deduced from supplied measurement uncertainties (and it should deduce them if
it can since the human probably can't be relied on for this) or supplied in
purely symbolic situations. I have no idea how to express this idea in
Axiom, if it can even be done, but it would provide an absolutely incredible
and powerful tool for using the right equation given the data.
OK, enough pie in the sky talk :-) Night all, and thanks William as always
for your patient, helpful and amazingly powerful ideas and thoughts. I hope
mine aren't being too tiresome - I think I'm finally beginning to see the
light, although I'm afraid we might have a bit more than three set* commands
when we get done. (Derived Dimension simplification rules in SI will require
a few more commands, based on my Maxima experience, and that didn't have
anywhere near the flexibility this will have.)
CY
- Re: [Axiom-developer] Unit package question - Reply to 1st half, William Sit, 2005/09/01
- Re: [Axiom-developer] Unit package question - part 1, C Y, 2005/09/01
- Re: [Axiom-developer] axiom in multiuser environment, William Sit, 2005/09/02
- Re: [Axiom-developer] Unit package proposals and questions (was Unit package question - Part 1), William Sit, 2005/09/04
- Re: [Axiom-developer] Unit package proposals and questions,
C Y <=
- Re: [Axiom-developer] Unit package proposals and questions, William Sit, 2005/09/06
- Re: [Axiom-developer] Unit package proposals and questions, C Y, 2005/09/06
- Re: [Axiom-developer] Unit package proposals and questions, William Sit, 2005/09/07
- Re: [Axiom-developer] Unit package proposals and questions, C Y, 2005/09/07
- Re: [Axiom-developer] Unit package proposals and questions, William Sit, 2005/09/07
- Re: [Axiom-developer] Unit package proposals and questions, C Y, 2005/09/07
- Re: [Axiom-developer] Unit package proposals and questions, William Sit, 2005/09/08
- Re: [Axiom-developer] Unit package proposals and questions, C Y, 2005/09/08
- Re: [Axiom-developer] Unit package proposals and questions, William Sit, 2005/09/08
- Re: [Axiom-developer] Unit package proposals and questions, C Y, 2005/09/08