Home > Archive > APL > March 2008 > Dyalog releases Version 12
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Dyalog releases Version 12
|
|
| Stephen Taylor 2008-03-04, 7:58 am |
| Dyalog has released Version 12 of its APL, which now supports Unicode
for all character arrays. Version 12 also contains
--Conga for socket communications
--RainPro and NewLeaf for presentation
--a language bar for APL characters as an alternative to typing
--on-screen keyboard for Windows users.
Dyalog's newsletter (http://www.truepr.co.uk/news/dl/10/) also
announces
--tools for grid computing
--Dyalog 2008 conference 12-15 October in Denmark
--application development partners
--results of the first survey of usage by holders of their educational
licences
Stephen Taylor
editor@vector.org.uk
| |
|
| On Mar 4, 10:26=A0am, "Stephen Taylor <edi...@vector.org.uk>"
<StephenTaylorF...@googlemail.com> wrote:
> Dyalog has released Version 12 of its APL, which now supports Unicode
> for all character arrays. Version 12 also contains
>
> --Conga for socket communications
> --RainPro and NewLeaf for presentation
> --a language bar for APL characters as an alternative to typing
> --on-screen keyboard for Windows users.
>
> Dyalog's newsletter (http://www.truepr.co.uk/news/dl/10/) also
> announces
>
> --tools for grid computing
> --Dyalog 2008 conference 12-15 October in Denmark
> --application development partners
> --results of the first survey of usage by holders of their educational
> licences
>
> Stephen Taylor
> edi...@vector.org.uk
It is interesting that there are two versions.
One Classic and one with Unicode.
It may take a long time for the users to move over to the Unicode
version.
For my own use the Unicode version is the only one possible.
Unicode change will allow all kinds of new options.
There are several migration operations for the Classic users to move
over.
It will be interesting to see how long it will take for the users to
move over.
I guess that what will happen is that eventually some new
functionality will be introduced in the Unicode version and not in the
Classic version.
Companies with operations in countries outside the english speaking
countries it will probably be quicker to embrace the Unicode version.
The grid tools are also very interesting.
Grid and Apl enhance each other in a very natural way.
Chart and plotting is also there not to mention the possibility to use
external editors for Apl code!
APL source code can be stored in Unicode text files and edited using
any editor which supports these files.
As I understand it then this is just the first announcement in a long
line of new features that will be made available soon.
Not to mention a whole lot of new Help and much improved documentation
and the goal is to Re-introduce Apl to the masses.
| |
| phil chastney 2008-03-06, 3:59 am |
| Gosi wrote:
> On Mar 4, 10:26 am, "Stephen Taylor <edi...@vector.org.uk>"
> <StephenTaylorF...@googlemail.com> wrote:
> <snip, snip>
>
> It is interesting that there are two versions.
> One Classic and one with Unicode.
think about the alternative: supporting both string types within the one
interpreter -- that would be a nightmare for design and implementation
of the interpreter, and it would take forever to wean ASCII-only users
onto Unicode
Dyalog have taken the right decision, but instead of simply releasing
enhanced Unicode versions without enhanced "classic" versions, it might
be better received by their customer base if Dyalog were to announce an
end-date for ASCII-only enhancements first
Python 3 has taken a similar route, making all strings Unicode only, but
with support for "byte streams", which is handy when you don't yet know
what encoding the incoming stream uses
Perl 6 was headed down a similar route, but development seemed to be
mired in an over-ambitious design, and I haven't kept up with the story
> Companies with operations in countries outside the english speaking
> countries it will probably be quicker to embrace the Unicode version.
companies with operations entirely within the English-speaking world may
also find Unicode useful when they need to use a mathematical or
technical symbol or two, or even a quotation in Foreign (it adds so much
_style_, don't you think?)
regads . . . /phil
P.S: Python 3 also unifies the concepts of "type" and "object" -- that
is such a *right* thing to do, I expect we shall similar developments in
other languages
| |
|
| On Mar 6, 9:11 am, phil chastney
<phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
> Gosi wrote:
>
>
> think about the alternative: supporting both string types within the one
> interpreter -- that would be a nightmare for design and implementation
> of the interpreter, and it would take forever to wean ASCII-only users
> onto Unicode
>
> Dyalog have taken the right decision, but instead of simply releasing
> enhanced Unicode versions without enhanced "classic" versions, it might
> be better received by their customer base if Dyalog were to announce an
> end-date for ASCII-only enhancements first
>
> Python 3 has taken a similar route, making all strings Unicode only, but
> with support for "byte streams", which is handy when you don't yet know
> what encoding the incoming stream uses
>
> Perl 6 was headed down a similar route, but development seemed to be
> mired in an over-ambitious design, and I haven't kept up with the story
>
>
> companies with operations entirely within the English-speaking world may
> also find Unicode useful when they need to use a mathematical or
> technical symbol or two, or even a quotation in Foreign (it adds so much
> _style_, don't you think?)
>
> regads . . . /phil
>
> P.S: Python 3 also unifies the concepts of "type" and "object" -- that
> is such a *right* thing to do, I expect we shall similar developments in
> other languages
It has been interesting to watch the glacial speed of Unicode
adaptation.
I guess we have talked about Unicode for 20 years in this group.
I think that APL2 is all Unicode now if I remember correctly.
J supports Unicode.
It will be interesting to see if people use Unicode to translate
scientific mathematical notations directly to Apl.
Has anyone tried that?
| |
|
| Do all the Apl:s that use Apl chars and have Unicode support use the
same Unicodes now?
Will the Apls be able to send Unicode files between them and use the
Apl functions and data?
| |
| David Liebtag 2008-03-06, 6:58 pm |
| APL2000, Dyalog, and APL2 all use the same Unicode (with some very slight
differences that I believe we all handle automatically.) I'm not sure about
the other vendors.
For several years those three vendors have also all supported the SCAR
format which you can use to share data.
I know that Dyalog and APL2 can both read and write Unicode files. I don't
know about APL2000. I assume so.
David Liebtag
| |
| phil chastney 2008-03-06, 6:58 pm |
| Gosi wrote:
> On Mar 6, 9:11 am, phil chastney
> <snip>
>
> It has been interesting to watch the glacial speed of Unicode
> adaptation.
> I guess we have talked about Unicode for 20 years in this group.
> I think that APL2 is all Unicode now if I remember correctly.
> J supports Unicode.
"glacial"? meaning "retreating rapidly in the face of climate change"?
I guess that's a fair metaphor for a general reluctance to adopt UTF-8
> It will be interesting to see if people use Unicode to translate
> scientific mathematical notations directly to Apl.
>
> Has anyone tried that?
what exactly are you looking for here? some sort of 2-D input encoded
using Unicode, being interpreted in (or translated into?) APL, perhaps?
because if you are, it seems to me the actual encoding being used is a
lot less important than the 2-D nature of the input
but there again, I may have misunderstood you completely . . . /phil
| |
| Sam Sirlin 2008-03-06, 6:58 pm |
| phil chastney wrote:
> Gosi wrote:
>
> "glacial"? meaning "retreating rapidly in the face of climate change"?
>
> I guess that's a fair metaphor for a general reluctance to adopt UTF-8
>
>
> what exactly are you looking for here? some sort of 2-D input encoded
> using Unicode, being interpreted in (or translated into?) APL, perhaps?
>
> because if you are, it seems to me the actual encoding being used is a
> lot less important than the 2-D nature of the input
Yes. You need something like TeX, or Omega. Or mathml? One might argue
that for mathematics as a working language to be supported, the
"encoding" would seem to be required to handle this 2d nature, and hence
that unicode would have to have something like TeX embedded. Other
languages require this as well... I think the Tibetan encoding has the
notion of a stacking operator, but I recall it seemed rather limited to
me, rather than a powerful general facility.
Sun has proposed the language fortress to support a bit of 2d
mathematics language and characters.
Sam
| |
| microapl@microapl.demon.co.uk 2008-03-07, 3:59 am |
| Yes, APLX uses the same Unicode code points, so you can (for example)
cut and paste text between all the main APLs. Also APLX supports
reading and writing Unicode (UTF-8 and UTF-16) files directly.
Richard Nabavi
MicroAPL Ltd
On 6 Mar, 14:38, "David Liebtag" <DavidLieb...@vermontel.net> wrote:
> APL2000, Dyalog, and APL2 all use the same Unicode (with some very slight
> differences that I believe we all handle automatically.) I'm not sure about
> the other vendors.
>
> For several years those three vendors have also all supported the SCAR
> format which you can use to share data.
>
> I know that Dyalog and APL2 can both read and write Unicode files. I don't
> know about APL2000. I assume so.
>
> David Liebtag
| |
|
| On Mar 6, 2:53=A0pm, phil chastney
<phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
>
>
>
> what exactly are you looking for here? some sort of 2-D input encoded
> using Unicode, being interpreted in (or translated into?) APL, perhaps?
It was you who suggested that technical symbols could be used in
Unicode.
>companies with operations entirely within the English-speaking world may
>also find Unicode useful when they need to use a mathematical or
>technical symbol or two, or even a quotation in Foreign (it adds so much
>_style_, don't you think?)
>regads . . . /phil
That is why I asked if those symbols could be used to translate to Apl
functionality
| |
| Morten Kromberg 2008-03-07, 7:58 am |
| On Mar 6, 10:11=A0am, phil chastney
<phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
> Dyalog have taken the right decision, but instead of simply releasing
> enhanced Unicode versions without enhanced "classic" versions, it might
> be better received by their customer base if Dyalog were to announce an
> end-date for ASCII-only enhancements first
Phil, thanks for the first bit! I am not sure I understand the rest of
the comment, or what the perceived problem is with the Unicode/Classic
split - can you elaborate?
The Classic and Unicode versions are built using the same source code
and are identical in "functionality". They ONLY differ in the way that
they translate data as it goes in and out of the system, that
character arrays in the Classic version are restricted to the 256-
element selection from Unicode known as the "Atomic Vector", and that
the byte which represents a character in the Classic version is an
index into "Quad-AV". The arguments and results of monadic upgrade and
Quad-DR differ from one version to the other.
Note that BOTH versions have a single-byte character data type, but
that Unicode version will also use 2- and 4-byte internal
representations if you use code points beyond 255 (the Unicode product
views characters in the same way as integers, which also come in 1-,
2- and 4-byte flavours, depending on the range of the data).
We have NOT set a date for the end of the Classic version because we
want to give our customers some time to think about the issue and how
it will impact applications first. Some applications will just load
and run in the Unicode version, others which use a lot of casting
([]DR) and clever tricks when importing and exporting data may need
work. We do not yet know what would be a "reasonable" deadline.
Actually taking advantage of Unicode in applications (as opposed to
just being able to run on the Unicode version) may be a massive effort
involving rewriting all your interfaces, converting all your SQL
databases and other forms of external media, your applications
understanding of sorting and searching, etc: We don't expect many of
our customers to go all the way down that path, but it is very
important that those who want to CAN do it easily.
Note that the Classic and Unicode versions are fully inter-operable,
they can share workspaces, component files and TCP socket connections
- with the "obvious" limitation that a Classic version will choke if
it encounters a character not in its QuadAV (QuadAV can be defined by
the user - so Russians can define a different 256-element subset than
English Dyalog users). The Unicode version can be configured so that
it knows which subset a Classic "partner system" is working with and
translate data accordingly.
v12 Unicode can be instructed to continue to write non-Unicode
component files (on a per file basis) and give an error if this is not
possible, so that it does not "accidentally" write files that Classic
(or v10 and v11) cannot read.
Version 12 is carefully designed to avoid big bang conversion events
and make the transition to Unicode as smooth as possible: We want
encourage our users to move to Unicode as quickly as possibly but will
not force anyone to move hastily.
We are NOT setting a deadline at this time. My advice would be to
install the Unicode version as soon as possible and start up a project
team to evaluate how hard it will be to move, and how (if) your
applications can benefit from extending the range of characters
handled. I would plan to starting a move to the Unicode version with 3
years and try to complete it in 5. But DON'T PANIC, we do not leave
people "up the cr ": So long as there is any significant use of the
Classic version it will continue to be supported.
Come to our User Group conference in October to talk to colleagues
about what they are doing and put pressure on Dyalog to do the right
thing :-).
Morten
| |
| phil chastney 2008-03-07, 6:59 pm |
| Morten Kromberg wrote:
> On Mar 6, 10:11 am, phil chastney
> <phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
>
>
> Phil, thanks for the first bit! I am not sure I understand the rest of
> the comment, or what the perceived problem is with the Unicode/Classic
> split - can you elaborate?
>
> The Classic and Unicode versions are built using the same source code
> and are identical in "functionality". They ONLY differ in the way that
> they translate data as it goes in and out of the system, that
> character arrays in the Classic version are restricted to the 256-
> element selection from Unicode known as the "Atomic Vector", and that
> the byte which represents a character in the Classic version is an
> index into "Quad-AV". The arguments and results of monadic upgrade and
> Quad-DR differ from one version to the other.
>
> Note that BOTH versions have a single-byte character data type, but
> that Unicode version will also use 2- and 4-byte internal
> representations if you use code points beyond 255 (the Unicode product
> views characters in the same way as integers, which also come in 1-,
> 2- and 4-byte flavours, depending on the range of the data).
>
> We have NOT set a date for the end of the Classic version because we
> want to give our customers some time to think about the issue and how
> it will impact applications first. Some applications will just load
> and run in the Unicode version, others which use a lot of casting
> ([]DR) and clever tricks when importing and exporting data may need
> work. We do not yet know what would be a "reasonable" deadline.
>
> Actually taking advantage of Unicode in applications (as opposed to
> just being able to run on the Unicode version) may be a massive effort
> involving rewriting all your interfaces, converting all your SQL
> databases and other forms of external media, your applications
> understanding of sorting and searching, etc: We don't expect many of
> our customers to go all the way down that path, but it is very
> important that those who want to CAN do it easily.
>
> Note that the Classic and Unicode versions are fully inter-operable,
> they can share workspaces, component files and TCP socket connections
> - with the "obvious" limitation that a Classic version will choke if
> it encounters a character not in its QuadAV (QuadAV can be defined by
> the user - so Russians can define a different 256-element subset than
> English Dyalog users). The Unicode version can be configured so that
> it knows which subset a Classic "partner system" is working with and
> translate data accordingly.
>
> v12 Unicode can be instructed to continue to write non-Unicode
> component files (on a per file basis) and give an error if this is not
> possible, so that it does not "accidentally" write files that Classic
> (or v10 and v11) cannot read.
>
> Version 12 is carefully designed to avoid big bang conversion events
> and make the transition to Unicode as smooth as possible: We want
> encourage our users to move to Unicode as quickly as possibly but will
> not force anyone to move hastily.
>
> We are NOT setting a deadline at this time. My advice would be to
> install the Unicode version as soon as possible and start up a project
> team to evaluate how hard it will be to move, and how (if) your
> applications can benefit from extending the range of characters
> handled. I would plan to starting a move to the Unicode version with 3
> years and try to complete it in 5. But DON'T PANIC, we do not leave
> people "up the cr": So long as there is any significant use of the
> Classic version it will continue to be supported.
>
> Come to our User Group conference in October to talk to colleagues
> about what they are doing and put pressure on Dyalog to do the right
> thing :-).
>
> Morten
OK, that's fine, if there's no significant overhead in maintaining both
versions, then continue to support both versions
and thanks for the invitation, but I'm sure you get more than enough
pressure as it is, and the pressure that you're getting is probably much
more commercially oriented
best regards . . . /phil
| |
| phil chastney 2008-03-07, 6:59 pm |
| Gosi wrote:
> On Mar 6, 2:53 pm, phil chastney
> <phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
>
> It was you who suggested that technical symbols could be used in
> Unicode.
>
>
> That is why I asked if those symbols could be used to translate to Apl
> functionality
I'm still baffled
Unicode is an encoding, it maps abstract characters and symbols to
hexadecimal values, nothing more (actually, there is a lot of ancillary
stuff as well, but we'll ignore that, pro tem)
most known characters and quite a lot of technical symbols can be mapped
to hexadecimal values using Unicode
the technical symbols include every published APL symbol ever used in
any way
it also includes just about every mathematical symbol the American
Mathematical Society could think of
so a stream of mathematical symbols could be encoded using Unicode
values, and (if one exists) a semantically equivalent stream of APL
symbols could also be encoded using Unicode values
I'm sure you knew that
Unicode has no functional power, and in particular, it doesn't have
markup, so I should amend that earlier statement to "a _linear_ stream
of mathematical symbols..."
a stream of mathematical symbols, with embedded markup (presumably
ASCII-only), could also be encoded using Unicode values
conversion to a semantically equivalent stream of APL symbols could be
done by hand, or using a programming language[1], but I doubt very much
if a general solution exists
so, yes, some 2-D mathematical expressions could be translated into
executable APL using only Unicode values, which is my present best guess
at what you were asking
and if I've misunderstood you, my apologies
all the best . . . /phil
[1] note that there is no requirement for the programming language to
know anything about Unicode -- Unicode 1.0 has a copyright date (c)
1990, 1991 and at that time (before the introduction of w_char) some
people were already using unsigned ints to store Unicode values
| |
|
| On Mar 7, 8:58 pm, phil chastney
<phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
> Gosi wrote:
>
>
>
>
> I'm still baffled
>
> Unicode is an encoding, it maps abstract characters and symbols to
> hexadecimal values, nothing more (actually, there is a lot of ancillary
> stuff as well, but we'll ignore that, pro tem)
>
> most known characters and quite a lot of technical symbols can be mapped
> to hexadecimal values using Unicode
>
> the technical symbols include every published APL symbol ever used in
> any way
>
> it also includes just about every mathematical symbol the American
> Mathematical Society could think of
>
> so a stream of mathematical symbols could be encoded using Unicode
> values, and (if one exists) a semantically equivalent stream of APL
> symbols could also be encoded using Unicode values
>
> I'm sure you knew that
>
> Unicode has no functional power, and in particular, it doesn't have
> markup, so I should amend that earlier statement to "a _linear_ stream
> of mathematical symbols..."
>
> a stream of mathematical symbols, with embedded markup (presumably
> ASCII-only), could also be encoded using Unicode values
>
> conversion to a semantically equivalent stream of APL symbols could be
> done by hand, or using a programming language[1], but I doubt very much
> if a general solution exists
>
> so, yes, some 2-D mathematical expressions could be translated into
> executable APL using only Unicode values, which is my present best guess
> at what you were asking
>
> and if I've misunderstood you, my apologies
>
> all the best . . . /phil
>
> [1] note that there is no requirement for the programming language to
> know anything about Unicode -- Unicode 1.0 has a copyright date (c)
> 1990, 1991 and at that time (before the introduction of w_char) some
> people were already using unsigned ints to store Unicode values
For example:
\sum_{k=1}^{n}{a_k} means a1 + a2 + ... + an.
Unicode sign 2211 and below it k=1 and above it n
| |
| phil chastney 2008-03-07, 9:58 pm |
| Gosi wrote:
> On Mar 7, 8:58 pm, phil chastney
> <phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
>
> For example:
>
> \sum_{k=1}^{n}{a_k} means a1 + a2 + ... + an.
>
> Unicode sign 2211 and below it k=1 and above it n
it's important to keep your levels of detail clear here
"below it" and "above it" are layout specifications, and for that you
need markup, which is not part of an encoding scheme
there is another layout convention, which places "k=1" level with the
lower horizontal of the Sigma, and the "n" level with the upper horizontal
one convention is (normally) used for displayed formulae, the other for
inline for formulae (i.e, embedded in plaintext)
as Sam Sirlin has pointed out, there are various markup schemes
your chosen markup language may or may not support both conventions, but
your hypothetical translator surely must...?!
does that help? . . . /phil
| |
|
| On Mar 8, 1:33=A0am, phil chastney
<phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
> Gosi wrote:
[color=darkred]
s?[color=darkred]
may[color=darkred]
uch[color=darkred]
[color=darkred]
>
[color=darkred]
>
d[color=darkred]
>
>
>
>
>
>
>
[color=darkred]
>
s[color=darkred]
>
>
>
c)[color=darkred]
>
>
>
>
> it's important to keep your levels of detail clear here
>
> "below it" and "above it" are layout specifications, and for that you
> need markup, which is not part of an encoding scheme
>
> there is another layout convention, which places "k=3D1" level with the
> lower horizontal of the Sigma, and the "n" level with the upper horizontal=
>
> one convention is (normally) used for displayed formulae, the other for
> inline for formulae (i.e, embedded in plaintext)
>
> as Sam Sirlin has pointed out, there are various markup schemes
>
> your chosen markup language may or may not support both conventions, but
> your hypothetical translator surely must...?!
>
> does that help? =A0 . . . =A0 /phil
In the case of the Sigma we need to interpret three lines together
First line with the n
Second Sigma
Third k=3D1
In general the formulas would be written in a grid like fashion and
operations grouped together
Interesting to interpret formulas like
1
----------------------- =3D 1 % (y + 3) * ( x - 2) % 10
(y + 3) * ( x - 2)
---------
10
The formula written in 5 lines
| |
| phil chastney 2008-03-08, 7:58 am |
| Gosi wrote:
> <snip>
>
> In the case of the Sigma we need to interpret three lines together
> First line with the n
> Second Sigma
> Third k=1
>
> In general the formulas would be written in a grid like fashion and
> operations grouped together
> Interesting to interpret formulas like
>
> 1
> ----------------------- = 1 % (y + 3) * ( x - 2) % 10
> (y + 3) * ( x - 2)
> ---------
> 10
>
> The formula written in 5 lines
true -- and you will need to apply precedence rules to expressions
like sigma-x-squared
the difficulties you will face are dependent on the markup language
being used, but independent of encoding
I wish you and yours the best of luck with this endeavour, but you can
count me out -- I hate the inconsistencies of mathematical notation
all the best . . . /phil
| |
|
| On Mar 8, 9:59=A0am, phil chastney
<phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
> Gosi wrote:
>
>
>
0[color=darkred]
>
>
> true =A0-- =A0and you will need to apply precedence rules to expressions
> like sigma-x-squared
>
> the difficulties you will face are dependent on the markup language
> being used, but independent of encoding
I was thinking that it might be interesting to do it the other way
round.
Take Apl lines of code and display them in mathematical terms.
After a short considerations I do not think that would be easy.
A small subset in either direction might be easy and interesting.
Probably more as an exercise to teach Apl
|
|
|
|
|