zIFBoards gives you all the tools to create a successful discussion community.
zIFBoards - Free Forum Hosting
Welcome to Dozensonline. We hope you enjoy your visit.
You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, and sending personal messages. Registration is simple, fast, and completely free. (You will be asked to confirm your email address before we sign you on.)
Join our community!
If you're already a member please log in to your account to access all of our features:

Name:   Password:


Pages: (5) [1] 2 3 ... Last » ( Go to first unread post )

 Day Gravity Water Spreadsheet, Crosby in the Cloud
Kodegadulo
Posted: Dec 27 2017, 09:52 PM


Obsessive poster


Group: Moderators
Posts: 4,192
Member No.: 606
Joined: 10-September 11



Double sharp, Oschkar, and I have been developing a spreadsheet out in the Cloud, which can automatically generate descriptions of various Day-Gravity-Water based coherent metrologies, utilizing Quantitels, Systematic Numeric Nomenclature, and alphanumeric encoding of alternate radixes. We are developing this spreadsheet (and at least one variation on it) using Google Sheets, storing it out on Google Drive, so that it is accessible to anyone with a browser and the link to it.

Unfortunately, this conversation has ranged over two other threads, into which others have seen fit to inject unhelpful and mostly off-topic diatribes, incoherent nay-saying, arrogant self-promotion, sophistry, prejudices, dogmatism, and other irrelevant claptrap. I'm starting this thread in order to focus the conversation on actually developing the spreadsheet and supporting DGW metrologies.

Below is a recap of the relevant portions of the conversation to date. Please use this thread to continue discussion about the DGW spreadsheet, and feel free to cross-link to other relevant topics, but please avoid going off topic here. I will be policing this thread and moving anything egregiously off topic to the Off Topic thread, where I may or may not reply to it. Be warned that if you reply to something off-topic here, I will be moving that too, even if I'm sympathetic to your arguments.

(Note: In order to get this all into a single post, images have been turned into links, and emoticons have been replaced by plain text.)

EDIT: Additional Note: Much of the work on trans-dozenal digits supporting larger bases has been done in the Systematic Vigesimal Nomenclature thread.

From here (Oschkar actually got the idea to do this first):
QUOTE (Oschkar @ Dec 7 2017, 09:13 PM)
Anyway, have a spreadsheet:
https://docs.google.com/spreadsheets/d/1khu...dit?usp=sharing


From here (excerpt):
QUOTE (Double sharp @ Dec 7 2017, 11:58 PM)
QUOTE (Oschkar @ Dec 7 2017, 09:13 PM)
Anyway, have a spreadsheet:
https://docs.google.com/spreadsheets/d/1khu...dit?usp=sharing

Brilliant! I think this is exactly what we've been talking about at Wendy's thread:
QUOTE (icarus @ Dec 5 2017, 04:07 PM)
I also think that a true octonary primel system would be interesting as a study (but so would many other studies). Further, I think an attempt at writing an algorithm to automatically generate a primel-style system - true to its tenets and given objectives that the user could set (i.e., based on gravity, etc.) would be very interesting if possible. It would be a massive demonstration of the flexibility of the directives Primel sets up.

Of course, this is just a starting point.

...


From here:
QUOTE (Double sharp @ Dec 8 2017, 04:03 PM)
QUOTE (Oschkar @ Dec 7 2017, 09:13 PM)
Anyway, have a spreadsheet:
https://docs.google.com/spreadsheets/d/1khu...dit?usp=sharing

Some interesting possibilities for timels in some bases of interest, found after experimenting with Oschkar's very useful spreadsheet:

Quinary: 5^-9 (timel 44.24 ms, lengthel 19.17 mm, massel 7.048 g); 5^-8 (timel 221.2 ms, lengthel 479.3 mm, massel 110.1 kg)

Senary: 6^-8 (timel 51.44 ms, lengthel 25.93 mm, massel 17.42 g); 6^-7 (timel 308.6 ms, lengthel 933.3 mm, massel 813.0 kg). Oschkar's senary Ashtrian metrology uses 6^-8.

Septenary: 7^-7 (timel 104.9 ms, lengthel 107.8 mm, massel 1.254 kg)

Octal: 8^-7 (timel 41.20 ms, lengthel 16.63 mm, massel 4.599 g); 8^-6 (timel 329.6 ms, lengthel 1.064 m, massel 1206 kg). My Xing metrology uses 8^-6.

Nonary: 9^-6 (timel 162.6 ms, lengthel 259.0 mm, massel 17.37 kg)

Decimal: 10^-6 (timel 86.40 ms, lengthel 73.14 mm, massel 391.2 g). This is essentially Donald Sauter's system, although he uses slightly different values for gravity and water density, making it a little off.

Undecimal: 11^-6 (timel 48.77 ms, lengthel 23.30 mm, massel 12.66 g)

Dozenal: 12^-5 (timel 347.2 ms, lengthel 1.181 m, massel 1648 kg); 12^-6 (timel 28.94 ms, lengthel 8.203 mm, massel 552.0 mg). The first is Sunny's metrology; the second is Primel.

Tridecimal: 13^-5 (timel 232.7 ms, lengthel 530.5 mm, massel 149.3 kg)

Tetradecimal: 14^-5 (timel 160.6 ms, lengthel 252.9 mm, massel 16.17 kg)

Pentadecimal: 15^-5 (timel 113.8 ms, lengthel 126.8 mm, massel 2.040 kg)

Hexadecimal: 16^-5 (timel 82.40 ms, lengthel 66.52 mm, massel 294.3 g)

Octodecimal: 18^-5 (timel 45.72 ms, lengthel 20.48 mm, massel 8.595 g)

Vigesimal: 20^-5 (timel 27.00 ms, lengthel 7.142 mm, massel 364.4 mg)

Tetravigesimal: 24^-4 (timel 260.4 ms, lengthel 664.4 mm, massel 293.3 kg)

Trigesimal: 30^-4 (timel 106.7 ms, lengthel 111.5 mm, massel 1.385 kg). This one might prove interesting as the smallest number with 3 prime factors, and thus the one that manages to keep as many nice sizes as possible.

Sexagesimal: 60^-3 (timel 400.0 ms, lengthel 1.568 m, massel 3852 kg). I think Oschkar did a sexagesimal Ashtrian metrology some time back; I can't find the details, but given the ridiculous results of all other choices, this must be it.

Tetroctogesimal: 84^-3 (timel 145.8 ms, lengthel 208.2 mm, massel 9.024 kg)

Centovigesimal: 120^-3 (timel 50.00 ms, lengthel 24.49 mm, massel 14.69 g). Likewise, this is Oschkar's current centovigesimal Ashtrian.

Trecentosexagesimal: 360^-2 (timel 666.7 ms, lengthel 4.354 m, massel 82565 kg). Definitely monumental, but might work out.

Dumillequingentovigesimal: 2520^-2 (timel 13.61 ms, lengthel 1.814 mm, massel 5.965 mg). Okay, this is starting to get a little ridiculous.

Base 720720 (skipping over lots of SHCNs until we get one that actually gives one reasonable power): 720720^-1 (timel 119.9 ms, lengthel 140.8 mm, massel 2.791 kg). Surprisingly convenient units for a completely ridiculous base.

Base 1441440 (the last SHCN that actually works out): 1441440^-1 (timel 59.94 ms, lengthel 35.20 mm, massel 43.62 g). Okay, I'll stop now before I accidentally recreate The Funniest Joke in the World.


From here:
QUOTE (Kodegadulo @ Dec 8 2017, 11:49 PM)
Here's a couple more spreadsheets. Oschkar beat me to it, and his does an excellent job, but I was working up something a bit more elaborate. (smiley)

DGW-Primel.xslx
DGW-Xing.xslx

These are actual Excel 2016 workbooks, using the version for Windows, including use of the BASE() function (which supports the "Computerese" base style using uppercase letters, up to trinilial base). Perplexingly, this function does not seem available on the Mac OS versions of Excel I've had access to in the past.  I haven't played with Google Doc's spreadsheet software much yet, so I don't know how much of this could be reproduced there.

On the main Metrology tab of these docs, the first section defines a few parameters:

http://i67.tinypic.com/2i135hx.png

You can enter a different (decimal) number for the Radix and it will automatically generate an appropriate RadixAbbrev based on the "Computerese" base annotation convention, which is used later to mark based values e.g. 100[8] = 54[C].  It also automatically generates the appropriate Radix Syllable for use in Systematic Nomenclature prefixes, but this is somewhat limited in that I really only have worked up decent syllables for octal ("os"), decimal ("des"), unquadral ("tes") and unoctal ("vig").  We would have to do something creative to provision more bases with such syllables. Dozenal or unqual base of course omits such a syllable. I haven't yet worked this up so it could handle Ashtrian's unqua·decimal prefixes.

There is a drop-down selector to choose the timel for your metrology:

http://i67.tinypic.com/dxlc5.png

This then automatically populates the next section in an appropriate way:

http://i64.tinypic.com/9puopf.png

There are also drop-downs to select from various choices for accelerel:

http://i68.tinypic.com/30kszti.png

and for massic·heatability (Joule constant):

http://i63.tinypic.com/akap0g.png

Excel forces me to sort these alphabetically in order for the selection-and-lookup to work properly, but I wanted them sorted from smallest to largest values, so I had to prefix each name in these lists with these numeral indexes.

The bulk of the Metrology tab then lists the various quantitels and their values in coherent SI units. For each generic quantitel, it generates the target-system's quantitel with brand mark as well as the pronunciation using the brand prefix. 

In some cases, you can see other unit equivalences to the right of the SI coherents, and some of those are even implemented as drop-down choices, so you can play with different customary units. I've also fleshed out some systematic scalings of the quantitesl.  I haven't finished doing these things for all the quantitels yet, but I may add more.


From here:
QUOTE (Kodegadulo @ Dec 8 2017, 11:50 PM)
Continued from previous post (since number of images is limited):

http://i66.tinypic.com/xpr38.png


http://i64.tinypic.com/1609382.png


http://i66.tinypic.com/288cv49.jpg


From here:
QUOTE (Oschkar @ Dec 9 2017, 02:09 AM)
QUOTE (Kodegadulo @ Dec 8 2017, 11:49 PM)
I haven't yet worked this up so it could handle Ashtrian's unqua·decimal prefixes.

Come to think of it, multiple-subdigit prefixes would be very rare in Ashtrian, and would indicate that the scales being dealt with are so large or so small that they're far beyond what is intuitive. Even the masses of galaxies and subatomic particles are easily covered by the "zen"-series of prefixes in your spreadsheet.


From here:
QUOTE (Double sharp @ Dec 9 2017, 03:01 AM)
For radix syllables, I suggest continuing the use of argam from "tesqua, tescia":

2: bitqua, bitcia
3: tritqua, tritcia
4: cadqua, cadcia
5: kinqua, kincia
6: senqua, sencia
7: seffqua, seffcia
8: osqua, oscia
9: novqua, novcia
a: desqua, descia
b: ellqua, ellcia
c: qua, cia
d: thysqua, thyscia
e: frasqua, frascia (Oschkar's)
f: mandqua, mandcia (from German Mandel, because otherwise "trick" is to close to "tri" for comfort)
g: tesqua, tescia
h: zotequa, zotecia
i: dynqua, dyncia
j: axqua, axcia
k: scorqua, scorcia
l: tressqua, tresscia
m: dellqua, dellcia
n: florqua, florcia
o: caxqua, caxcia (because dex collides with dec)

There's always Oschkar's and my digit roots if you like one-syllable names for everything:

0: nil
1: un
2: bi
3: tri
4: quad
5: pent
6: hex
7: sept
8: oct
9: enn
a: dec
b: lev
c: zen
d: cist
e: fed
f: gint
g: kix
h: mipt
i: ruct
j: vinn
k: ald
l: ift
m: wel
n: xor


albeit these only achieve the low bar of starting in different letters, not of sounding like anything familiar, except for c. d might be from argam "thise". There are a few derivation principles, of course: e to j are generated by looking at 4 to 9, keeping the ending, changing the vowel to the next one in the English alphabet, and changing the initial consonant to the earliest possible one. But other than that it is mostly ad-hoc, which I will be the first to admit for my supplemented m and n, which I created just to push this contraption to the double dozen. happy.gif


From here:
QUOTE (Oschkar @ Dec 9 2017, 06:13 AM)
QUOTE (Kodegadulo @ Dec 8 2017, 11:49 PM)
These are actual Excel 2016 workbooks, using the version for Windows, including use of the BASE() function (which supports the "Computerese" base style using uppercase letters, up to trinilial base). Perplexingly, this function does not seem available on the Mac OS versions of Excel I've had access to in the past.  I haven't played with Google Doc's spreadsheet software much yet, so I don't know how much of this could be reproduced there.

Don't have access to Excel 2016 easily. I can confirm that this is completely broken in Excel 2010, but it works in LibreOffice 5.3.1.2 with one bug: because the cell for the dozenal radix syllable is totally empty, it gets converted to "0" upon concatenation. This can be fixed easily by adding a function that evaluates to the empty string in cell D13 of the DigitRoots sheet.


Anyway, you’re dropping “concentration” and “solventage”? I’ll have to fix my Thermodynamics and Chemistry file then...


From here:
QUOTE (wendy.krieger @ Dec 9 2017, 07:14 AM)
They look nice, but some comment is useful.

1.  The 'convert to' units are the ones you intend to get accustomed to.  The implication here is to translate the DGW system to SI, means you want the people to think in SI, and regard DGW as a side issue.  All of my versions are *common=target style. 

2.  It doesn't handle side-by-side comparisons of different systems.  I've done some of these in Lotus 1-2-3 + Allways which handles several columns side by side.

3.  It doesn't handle x*b^y even, such as 2D5 (tgm) or 6*60^3, or 4d5 or 6d5 or 8d5, all of which have been mentioned in other threads.  The current versions handle only b^n.


From here:
QUOTE (Oschkar @ Dec 9 2017, 07:26 AM)
QUOTE (wendy.krieger @ Dec 9 2017, 07:14 AM)
3.  It doesn't handle x*b^y even, such as 2D5 (tgm) or 6*60^3, or 4d5 or 6d5 or 8d5, all of which have been mentioned in other threads.  The current versions handle only b^n.

TGM was a one-off thing. There’s nothing intrinsically coherent about 2×125 that would make it suitable for Kodegadulo’s spreadsheet; it was selected in order to retain the hour and the foot, the closest things that we currently have to dozenal units. And in any case, TGM units are also Primel auxiliary units, though they are not coherent dozenal powers.

By the way, “4d5” doesn’t mean “four times dozen to the fifth power”; it means “roll four five-sided dice and add their values”, which is somewhat awkward for a number of divisions of the day.


From here:
QUOTE (Kodegadulo @ Dec 9 2017, 11:10 AM)
QUOTE (Oschkar @ Dec 9 2017, 06:13 AM)
Anyway, you’re dropping “concentration” and “solventage”? I’ll have to fix my Thermodynamics and Chemistry file then...

Eh, I don't know if you need to do that. I'm experimenting. The terminology around concentration of solutions is awkward. Even the Metric/SI crowd has found it awkward, punting with nonsense coinages like "molar" (but not about dentistry) and "molal" (not about anything).

My original thought was to reserve concentrat(ion)el for "number concentration" (number of individual items (dimensionless) per volumel of solution); and qualify it as substancel•concentratel for "substance concentration" (amount of substance per volumel of solution, traditionally referred to as "molarity" in Metric).

Well, substancel•concentratel is a mouthful, bordering on being just a derived-unit phrase. Perhaps we could used substancentratel as an awkward contraction, but it's still a mouthful. But then it occurred to me that volumic• is (almost) a symonym for concentrationel, so I'm trying that out here. I say "almost" because concentrationel conveys the nuance "of solution".

I notice that you've decided to reserve unadorned concentrat(ion)el to mean specifically "substance concentration" and put aside other measures such as "number concentration" and "mass concentration" as not important enough to worry about. (Similarly for solvent(ag)el.) That becomes another terminology experiment, which is fine. Perhaps yours is the better ... solution. (smiley)

EDIT: What's truly annoying is that the "molar" is not 1 SI•substancel (mole) per one SI•volumel (cubic-meter), but rather a thousand times more concentrated: one mole per liter (milli•SI•volumel).


From here:
QUOTE (Double sharp @ Dec 9 2017, 03:55 PM)
Translation for the perplexed: 1 molar is 1 mol/dm3, while 1 molal is 1 mol/kg. While these are commonly encountered quantities, and it's nice to have short names, it would be nicer to have more sensible short names indeed. Even the unit abbreviations are less confusing; at least they don't sound so alike!

I suspect there are two reasons for the issue you raise. First of all is that 1 mol/m3, the millimolar, is a rather low concentration for most laboratory purposes, the cubic metre being so large. (Except for radiochemistry, when it becomes an impractically high concentration: most work on astatine is done with concentrations ranging in the nanomolars and picomolars.) The second reason is that the metric system from the beginning has had this factor of a thousandth built into it: the original French metric system had the litre (the cubic decimetre) as its volumel for liquids and the stère (the cubic metre) as its volumel for solids. From this was derived the gram as originally the mass of a millilitre of water, creating yet another factor of a thousandth. So metric awkwardly has this built into it.

Really, all of this could have been resolved by using the decimetre as the SI-lengthel instead of the metre. We'd then be rid of all those factors of a thousand, and all that would have been needed is for the French to aim for one hundred-millionth of the length of half a meridian instead of one ten-millionth (and then got it slightly wrong, but never mind that). Don't get me wrong, SI is a good system and it works, but there are a few things like that that could have been done better. Something had to be first, though, and SI is very good for a first attempt at a consistently-based metrology put into practice. It still wouldn't bring in gravity, though; if you're keen on that, you'd be starting with the microday and have a lengthel of 73.14 mm and a massel of 391.2 g, which isn't half bad either. In fact, it is just Donald Sauter's system.

Now, following on Sauter's remarks, it is true that while the "water" part of the metrology is constant for us, the "day" and "gravity" parts will change when we colonise another planet. So now I have a lightly edited version of Oschkar's spreadsheet on my computer with 86400 defined in cell I5 (with H5 reading "Day"), and the formula in cell B1 altered to match. So, with that addition, you can just change the day length and gravity length as you like for other celestial bodies. To make your Martian colonists happy, just change 86400 to 88775.244 and 9.79758271961639 to 3.711. The lower gravity indeed makes for a nice Martian xing-lengthel of 425.6 mm and Martian xing-massel of 77.09 kg. On Venus, (use 20997360 and 8.87 respectively this time), you should probably start with the ununosciaday instead of the hexosciaday - albeit the concept of a Cytherean day as a fundamental reality is a little suspect even after terraforming for the colonists, considering that you can't possibly adapt to a 243.025-day sleep-wake cycle like you can for the Martian day.


... skipped more side-conversations about con-words and concentrations ...

From here
QUOTE (Kodegadulo @ Dec 16 2017, 06:32 AM)
Double Sharp, if you want to complement the octal Xing metrology with a sibling tessal (unquadral, hexadecimal) metrology based on the penttescia·day, I suggest giving it a name based on the Mandarin for "compass", either 指南针 zhǐ běi zhēn, or 指南针 zhǐnán zhēn. Perhaps reduced to just the final syllable 针 zhēn "needle".  This would be an oblique reference to the tess (fourzeen, sixteen) major directions of the compass which the "needle" can point to: N, NNE, NE, ENE, E, ESE, SE, SSE, S, SSW, SW, WSW, W, WNW, NW, NNW.

So let's call it the "Zhen" metrology, with brand prefix "zhen".  For a brand mark, I suggest ✺, Unicode Character 'SIXTEEN POINTED ASTERISK' (U+273Ax)

Take a look at this Google Sheets spreadsheet I've just put together. 

This spreadsheet documents 6 existing Day-Gravity-Water systems: Primel, Tertiel, Phasic, Pendlebury, Xing, and Zhen.  (I haven't tried to tackle Ashtrian yet, as mixed unqua·decimal base adds a whole other level of complexity.)

On the main "Metrology" tab, the "Metrology Selector" cell (B1) lets you easily choose among them, and the rest of the tab automatically recalculates. It pulls selections for each of these metrologies from the "Metrologies" tab, which in turn contain selector cells pulling choices from other tabs about specific aspects, including "Gravities", "Densities", "Calories", "Impedances". 

For experimenting, I've included a seventh metrology called "Adhoc". Fiddle with the selections in its row of the "Metrologies" tab to try out different possibilities.  If you identify additional interesting metrologies that this spreadsheet can model, I'd be happy to include them above "Adhoc" in the "Metrologies" tab.

This spreadsheet generalizes the "Day-Gravity-Water" idea to allow simple reciprocal fractions of the day to act as the "Period" from which a timel may be derived as a pure power of the selected radix. (See the "Periods" and "Period Powers" tabs.) I've included the customary names for such fractions we've identified (clock, shift, phase, watch, vigil, etc.) as well as some of your binary series (whiling, serenade). For other fractions, I just punted and constructed names from Systematic Nomenclature digit roots + "id" as a common suffix to mean "fraction of a day" (e.g. pentid, septid).

Incidentally, I found a way to name digit roots all the way up to trinilial base. (See the "Digit Roots" tab.)  As before, I introduce the syllable "zen" to cover the zeens (dozen-somethings). But I thought another syllable might be introduced to cover the twenzies (two-dozen-somethings) in a similar way.  I'm trying out "yon" (short for "yonder") as that syllable, signifying that the digits in that tier are "farther off" than the zeens.


From here:
QUOTE (Double sharp @ Dec 16 2017, 07:31 AM)
"Yon" is an interesting idea, and so is "weg" for three dozen (hmm, is it because it is even more of ein langer Weg from the dozenal digits?). I likewise think "Zhen" is a good name for the sister metrology for hexadecimal, and ✺ is indeed the obvious brand mark.

The trouble is that I don't like the idea of a hexadecimal metrology with single digit roots up to "zen" (c ), and then going "zenun" (d), "zenbi" (e), "zentri" (f). How exactly are we going to distinguish those from c1x, c2x, and c3x? And, really, what are we doing switching at twelve in a hexadecimal system, anyway? Eight might make more sense. Though that's not a very extensible solution because it leaves us no way to handle prime bases, or bases with no small enough factor pairs (e.g. 26).

"Yon" isn't a bad fit for d, I have to admit: it's on yonder side of the dozen, instead of the left side. So that takes care of tetradecimal, though hexadecimal seems to want additional roots for e and f. We might I guess coopt "weg" too for e (it also sounds like "week", and indeed means that in Frisian, which is half its length), and German Mandel immediately yields "mand" for f. But I also don't like having them mean one thing in a small base and another thing in a big base. Hmm. Omnibase also works, at the expense of being limited to base 36 as well, and having to make casing distinctive ("e" means 9, while "E" means fourteen).

Incidentally, even if you can't tackle centovigesimal Ashtrian, I would think that the old senary Ashtrian (link) would be a good addition, with ✶ (U+2736x, "SIX POINTED BLACK STAR") as the brand mark.

(P.S. Senary Ash-Ashtrian has now been added, further to some chatting Kode and I have been doing on that spreadsheet about the issues raised above. happy.gif Replacing "zen" and "yon" with "zennil" and "yonnil" solves the first problem, for example.)


From here:
QUOTE (Kodegadulo @ Dec 16 2017, 08:53 AM)
I've included various proposals for digit roots and their abbrevs for reference, but now I've set the ones in force in the spreadsheet to DS's proposal for transdecimals up to hexadecimal, and Omnibase above that: un (u), bi ( b ), tri (t), quad (q), pent (p), hex (h), sept (s), oct (o), enn (e), dec (d), lev (ℓ), zen (z), yon (y), weg (w), mand (m), golf (G), hoat (H), ind (I), jul (J) ... etc. So up to the near human-scale we have single-lowercase-letter abbreviations, and only get awkward shouting uppercase when we choose to go more extreme.

I did add the Ash-Ashtrian metrology.  Note that I had set the Adhoc metrology to argam "zeffal" base (twenzeen, fourteen). I guess I should now call it "wegal" base. (smiley)  You can now see a little of what SNNw prefixes would look like, if you check the "Period Powers" tab.


From here:
QUOTE (Double sharp @ Dec 16 2017, 03:35 PM)
I just realised that we're missing one metrology: Donald Sauter's decimal DGW system, which starts from the microday, and uses the SI gravity. Unfortunately he doesn't seem to have specified it completely all the way to the electrical units, but after all, he says "We'll also need to choose new fundamental units for electric current, temperature, and luminous intensity, that work well with these, but I'll leave that to others when this idea gets rolling", so we can choose those for him. (EDIT: Added!)

And just like we came up with the laevo excuse-etymology for lev, we can use Greek to come up with one for yon: ἰών, present active participle of the verb "to go", εἶμι. Clearly, we are going to the yonder side of the dozen! As for the Germanic weg and mand, I say that once you've accepted zen, from which the first letter comes from the French development of the second d in Latin duodecim, and the rest doesn't even come from a number but the Latin distributive suffix, they're not that much less desirable! It's difficult to argue with mand when there is essentially no choice for a non-decimal name for 15; and while weg is kind of cheating, I'm not sure we can do much better. Anything to do with "fortnight" already has a lot to do with fourteen, and for a number that is twice seven, obfuscating the seven-day week should work. If you can't come up with one good, solid etymology, the next-best thing is clearly to come up with many weak ones! (wink)

I suggest that the final c in "dec" and g in "weg" should not be allowed to soften among any circumstances; the roots should remain constant in pronunciation.

EDIT: While chatting we've come up with some other names for the other human-scale metrologies: senary is Ash-Ashtrian ✶, octal is Xing ❂, decimal is Sauter
Ⓢ (since he wrote up the idea for decimal first, as far as I can tell), dozenal is of course Primel ′, tetradecimal is Fleur ❧ (because obviously seven needs a flowery mark for it being a special prime, so it might as well get the fleuron), and hexadecimal is Zhen ✺.


From here:
QUOTE (Kodegadulo @ Dec 16 2017, 06:32 PM)
I've opened up permissions on the Google doc so anyone with the link can edit it. This seems the only way to let people operate the drop-down selectors, as that's apparently considered an edit. This does leave the doc open to possible "hostile" edits, but Google Docs does maintain a version history, so anything destroyed or cobbled up by ill-advised parties ought to be recoverable. Suffice to say, I've made my own (secret) backup copy as well.

As DS has mentioned, the spreadsheet now supports Primel, Tertiel, Phasic, Pendlebury, Sauter, Ash-Ashtrian, and DS's Fleur, Xing, and Zhen metrologies.  The AdHoc metrology is for random play.

All a matter of a couple evenings' throwaway work, using technology any of you can access directly from your browsers without downloading anything. There is even an app you can get for your phones, easily downloaded for free from Google Play.

I'd like to see someone who fancies themself a "programmer" try to top that with some piddly command-line script that they wrote in some vintage 20thd-century scripting language who-knows-how-many decades ago and barely advanced in all that time. A script not actually provided, I might add, and of little interest to anyone even if.  Who wants to download, install, and learn how to run a scripting language?


From here:
QUOTE (Kodegadulo @ Dec 16 2017, 08:04 PM)
By the way, I originally got weg as a corruption of omega > wmega > wmeg > weg. But hey, if week > weg and/or way > weg work better, no problemo. As long as we don't call it a "wig" on the grounds that it's a "fur piece" into the transdecimals. (smiley)

P.S. The "Digit Sequences" tab now generates SNN multiplier, reciprocal, positive power, and negative power prefixes for the radix selected in the metrology. Note that each prefix embeds a "radix syllable" somewhere (except for single-digit multipliers and reciprocals). But if we combine a multiplier, reciprocal, and power into a single prefix, it may be fair to have only one radix syllable per combination.

Of course, dozenal SNNz prefixes don't take any radix syllable. But I never said I wasn't biased. (wink)


From here:
QUOTE (Double sharp @ Dec 17 2017, 03:08 PM)
One more feature that would be nice to have in this spreadsheet would be to be able to have not only "Period Powers", but be able to select any unit you want (timel, frequenciel, accelerel, velocitel, lengthel, etc.) from a drop-down list and have a bunch of powers come up, kind of like what I quoted from Oschkar in the OP. Then we can not only systematically see what the lengthel looks like, but also the unqualengthel, biqualengthel, ..., uncialengthel, bicialengthel, etc., and get even more of an insight of how all those units and the base slice up the quantities they are measuring.


From here:
QUOTE (Kodegadulo @ Dec 17 2017, 07:02 PM)
QUOTE (Double sharp @ Dec 17 2017, 03:08 PM)
One more feature that would be nice to have in this spreadsheet would be to be able to have not only "Period Powers", but be able to select any unit you want (timel, frequenciel, accelerel, velocitel, lengthel, etc.) from a drop-down list and have a bunch of powers come up,

Great idea! I already have a lot of the machinery to support that. I'll put it together, soon... (smiley)


... skipped useless lecturing from David Kennedy ...

From here:
QUOTE (Double sharp @ Dec 18 2017, 10:04 AM)
QUOTE (Double sharp @ Dec 16 2017, 03:35 PM)
EDIT: While chatting we've come up with some other names for the other human-scale metrologies: senary is Ash-Ashtrian ✶, octal is Xing ❂, decimal is Sauter
Ⓢ (since he wrote up the idea for decimal first, as far as I can tell), dozenal is of course Primel ′, tetradecimal is Fleur ❧ (because obviously seven needs a flowery mark for it being a special prime, so it might as well get the fleuron), and hexadecimal is Zhen ✺.

For some strange reason the one character among these which I cannot see on my smartphone is the simplest: the circled S for Sauter. Nonetheless it is such a good fit that I don't think we need to replace it. (Kode's original suggestion of σ is I suppose an option, albeit a placeholder-ish one. I think π for Pendlebury TGM makes a lot more sense, because it also references how it divides the day into two first and has a unit named the "Pi".)

I have thought about including the two "higher-natural scale" bases 18 and 20; by then the transition into rather shouty uppercase is rather inevitable. Vigesimal nevertheless seems to strand you between a rock (a massive massel) and a hard place (a tiny massel), and I need to go think up a few more brand marks for those. Not sure if doing these or the odd bases are worth it, though.


From here:
QUOTE (Kodegadulo @ Dec 18 2017, 01:11 PM)
QUOTE (Double sharp @ Dec 18 2017, 10:04 AM)
For some strange reason the one character among these which I cannot see on my smartphone is the simplest: the circled S for Sauter. Nonetheless it is such a good fit that I don't think we need to replace it. (Kode's original suggestion of σ is I suppose an option, albeit a placeholder-ish one. I think π for Pendlebury TGM makes a lot more sense, because it also references how it divides the day into two first and has a unit named the "Pi".)

Eh, I was considering the circled-S rather a placeholder too if we can come up with better. Although it does have the saving grace of being as easily distinguished from the succeeding text of the unit name, with no additional formatting, as any of the stars or dingbats or punctuation we've been using for brand markers. The disadvantage of something like the Greek π for Pendlebury is that it is an ordinary letter and just washes together with any other text unless one takes pains to set it off by superscripting it, or interposing a center dot as I have in the spreadsheet. I'm thinking a circled P for Pendlebury might be a better bet. Would that there were a circled π! And a circled φ for Phasic, for that matter... (smiley)


... skipped more useless lecturing from Daniel Kennedy ...

From here:
QUOTE (Double sharp @ Dec 18 2017, 02:59 PM)
QUOTE (Kodegadulo @ Dec 16 2017, 06:32 AM)
(I haven't tried to tackle Ashtrian yet, as mixed unqua·decimal base adds a whole other level of complexity.)

Wait, why is this a problem? Can't we just treat it as pure base 120 with two-part names for the superdigits? So we could have digit roots "nil, un, bi, tri, quad, pent, hex, sept, oct, enn, undenil, undeün, undebi, ..., undeënn, bidenil, ..., enndeënn, decdenil, ..., levdeënn", just like you suggested for Systematic Unquadecimal Nomenclature. To concatenate the digits, I guess we'd have to use "nildenil, nildeün, nildebi, ... nildeënn" for the first ten digits instead, but I can deal with that.

You'd have to extend the "Digit Roots" table to 120, and have some means of marking them via radices (maybe my old "Double-Wide-with-a-Porch Digital" scheme using Japanese kana), but other than that I don't see why it should pose problems. Unless there is anything that requires base conversion into the target base, in which case indeed bases over 36 would likely prove a mess, but are there?

(Come to think of it, that would be a neat "reverse conversion" feature. Because to truly think in the new metrology, you shouldn't be thinking "a fleur-lengthel is about a quarter of a metre"; you should be thinking "a metre is about four fleur-lengthels", for instance.)


From here:
QUOTE (Kodegadulo @ Dec 18 2017, 03:41 PM)
QUOTE (Double sharp @ Dec 18 2017, 02:59 PM)
QUOTE (Kodegadulo @ Dec 16 2017, 06:32 AM)
(I haven't tried to tackle Ashtrian yet, as mixed unqua·decimal base adds a whole other level of complexity.)

Wait, why is this a problem? Can't we just treat it as pure base 120 with two-part names for the superdigits? So we could have digit roots "nil, un, bi, tri, quad, pent, hex, sept, oct, enn, undenil, undeün, undebi, ..., undeënn, bidenil, ..., enndeënn, decdenil, ..., levdeënn", just like you suggested for Systematic Unquadecimal Nomenclature. To concatenate the digits, I guess we'd have to use "nildenil, nildeün, nildebi, ... nildeënn" for the first ten digits instead, but I can deal with that.

You'd have to extend the "Digit Roots" table to 120, and have some means of marking them via radices (maybe my old "Double-Wide-with-a-Porch Digital" scheme using Japanese kana), but other than that I don't see why it should pose problems.

{c}

It's more involved than that, because mixed base requires specifying more than just one radix. The spreadsheet would need to make provisions for specifying multiple sub-bases making up a super-base, and in general a semi-arbitrary number of them, e.g. 6×a for sexagesimal aka hexal•decal [6×A]; or 10×a for unqual•decimal aka zenal•decal [C×A]; or 10×13×12 for unqual•untrinal•unbinal aka zenal•mandal•wegal [C×F×E] (remember that one? (smiey) ); and so forth. It's not impossible to work out, but as I said, it's another layer of complexity. Patience, grasshopper... (wink)

EDIT: On second thought, what I cooked up for shockal and hundal bases were rather one-offs, not really generalizable to any mixed base. They in fact rely on having particular radix syllables indicating the superbase itself, so that we can construct -shocqua/-shoccia and -longua/-longia. (In fact, for Ashtrian, Oschkar is moving to replace the latter bisyllabic constructs with the more Germanic monosyllables -hund/-deal. This is still in the spirit of SNN, but it does represent another one-off case adding to the complexity.)

What I had in mind for a truly generic superbase solution would be something like this, e.g., for zenal•trickal•zeffal (zenal•mandal•wegal??):

(Parenthesized portions are elements thatt might be always omitted, or always included, or optional either way, but I don't know what to decide about that yet -- looking for opinions. )

Multiplier Prefixes:
000[C×F×E] = dozterkzef•(nilnil)nili
001[C×F×E] = dozterkzef•(nilnil)uni
...
00D[C×F×E] = dozterkzef•(nilnil)yona
010[C×F×E] = dozterkzef•(nil)unnili
...
0ED[C×F×E] = dozterkzef•(nil)wegyona
100[C×F×E] = dozterkzef•unnilnili
...

BED[C×F×E] = dozterkzef•levwegyona
...

Note the need for an explicit radix syllable for dozenal (doz), distinct from zen used as a digit root.

Power Prefixes:
000[C×F×E]↑ = (nildoz-nilterk-)nilzefqua
001[C×F×E]↑ = (nildoz-nilterk-)unzefqua
...
00D[C×F×E]↑ = (nildoz-nilterk-)yonzefqua
010[C×F×E]↑ = (nildoz-)unterk-nilzefqua
...
0ED[C×F×E]↑ = (nildoz-)wegterk-yonzefqua
100[C×F×E]↑ = undoz-nilterk-nilzefqua
...

BED[C×F×E]↑ = levdoz-wegterk-yonzefqua
...


From here:
QUOTE (Double sharp @ Dec 18 2017, 11:56 PM)
Remember that one! I should say so, indeed! happy.gif

Your solution for base c-on-f-on-e looks mighty promising, though I'd want some clarification about what it does when it crosses to 1'000{cfe} and onward. Are the superdigit boundaries explicitly called out? It's also not far from how I think of mixed bases: to me it's not so much "pure base 2520" as "a tetradecimal column overflowing into a pentadecimal column overflowing into a dozenal column".


From here:
QUOTE (Kodegadulo @ Dec 19 2017, 12:39 AM)
QUOTE (Double sharp @ Dec 18 2017, 11:56 PM)
I'd want some clarification about what it does when it crosses to 1'000{cfe} and onward.

I think it would just be :

Multiplier: dozterkzef-un-nilnilnili

Pos. Power: unzef-nildoz-nilterk-nilzefqua

Not really calling out the superdigit boundary in either case, unless you interpret the hyphens as pregnant pauses.

Hmm ... I've got two opposing styles there: I've got the multiplier declaring the superbase once, and all-at-once, and you just have to keep a scorecard to figure out which subbase each digit gets. But I've got the power declaring the subbase of each digit along with it, and you just have to inspect the whole to deduce what superbase you have. Let's try using just one style at a time:

Test case:
1234{cfe) and
1234{cfe}

Piecemeal subbases:
zefun-dozbi-terktri-zefquadra and
unzef-bidoz-triterk-quadzefqua

All-at-once superbase:
dozterkzef-un-bitriquadra and
un-bitriquad-dozterkzefqua

I think the all-at-once superbase style is probably the best.


----
Hmm ... I'm a bit dissatisfied that we've wound up having to cook up two distinct series of syllables for the same numbers, one used for digits and one for bases, with the latter unfortunately incomplete. I wonder if we could make this more parsimonious somehow...


From here:
QUOTE (Oschkar @ Dec 19 2017, 01:11 AM)
QUOTE (Kodegadulo @ Dec 19 2017, 12:39 AM)
Hmm ... I'm a bit dissatisfied that we've wound up having to cook up two distinct series of syllables for the same numbers, one used for digits and one for bases, with the latter unfortunately incomplete. I wonder if we could make this more parsimonious somehow...

You might consider adding another monosyllabic particle that separates the base from the rest of the number.

bas-zenmandwegan-unbitriquadra = 1'234{cfe}
unbitriquad-bas-zenmandwegqua = 1'0001'234{cfe}


From here:
QUOTE (Double sharp @ Dec 19 2017, 02:01 AM)
{a}

I'm not sure if Kode intends to do this for just mixed bases or for all of them. The latter runs into the problem that you can't keep the empty base particle for dozenal, because then "unquadqua" is ambiguous between 1216 and 41. And if we keep it that way we need to distinguish that what sounds like the last digit is always actually the radix syllable.

I agree that it's not particularly elegant to have two such parallel series, but it does seem to do the job with the minimum amount of superfluous ballast if we desire backward compatibility. Though the need to switch bases around seems to be forcing all those mixed bases to look as unfamiliar and clunky as they really are.


From here:
QUOTE (Double sharp @ Dec 19 2017, 02:19 AM)
QUOTE (Kodegadulo @ Dec 18 2017, 01:11 PM)
Eh, I was considering the circled-S rather a placeholder too if we can come up with better. Although it does have the saving grace of being as easily distinguished from the succeeding text of the unit name, with no additional formatting, as any of the stars or dingbats or punctuation we've been using for brand markers. The disadvantage of something like the Greek π for Pendlebury is that it is an ordinary letter and just washes together with any other text unless one takes pains to set it off by superscripting it, or interposing a center dot as I have in the spreadsheet. I'm thinking a circled P for Pendlebury might be a (smiley) )

I've noticed this too; Greek doesn't really stand out in Latin text unless you do something funny with it. Neither does Cyrillic. Of course, this is only to be expected given the scripts' common heritage; they even have many letter shapes in common. A second problem is that these are characters used in actual scripts; if we were to translate all this text on the metrologies into Greek or Russian, for example, these characters wouldn't stand out at all.

Still, since the Sauter and Pendlebury metrologies are here being named after their inventors (there's nothing better for Sauter, though why not just call Pendlebury's metrology "TGM"?), I would think that some sort of acknowledgement of that ought to be made in their brand marks. We are after all running out of the really apt and relevant dingbats; even the fleuron for the tetradecimal Fleur metrology is a bit of a cheat, if a happy one. happy.gif
Top
Kodegadulo
Posted: Dec 27 2017, 10:04 PM


Obsessive poster


Group: Moderators
Posts: 4,192
Member No.: 606
Joined: 10-September 11



Had to split the recap here because it was too long to post:

From here:
QUOTE (Kodegadulo @ Dec 19 2017, 02:36 AM)
QUOTE (Oschkar @ Dec 19 2017, 01:11 AM)
You might consider adding another monosyllabic particle that separates the base from the rest of the number.

bas-zenmandwegan-unbitriquadra = 1'234{cfe}
unbitriquad-bas-zenmandwegqua = 1'0001'234{cfe}

Indeed. But that syllable could be as simple as an adjectival ending on the base, echoing what we've already been doing in naming bases:

{c}

hexal:unbitriquadra = 21a
hexal:unqua = 6
hexal:biqua = 30
hexal:triqua = 160
hexal:quadqua = 900
etc.

Note: the colons are silent.

octal:unbitriquadra = 478
octal:unqua = 8
octal:biqua = 54
octal:triqua = 368
octal:quadqua = 2454
etc

decal:unbitriquadra = 86a
decal:unqua = dessal:unqua = a
decal:biqua = 84
decal:triqua = 6b4
decal:quadqua = 5954
etc

zenal:unbitriquadra = 1234
zenal:unqua = 10
zenal:biqua = 100
zenal:triqua = 1000
zenal:quadqua = 10000
etc

So good old SDN wasn't really a case of special bias. There was just a blanket "zenal:" implied at the top of every page! You ought to be able to make such a blanket statement for any base you want!

wegal:unbitriquadra = zeffal:unbitriquadra = 1a12
wegal:unqua = zeffal:unqua = 12
wegal:biqua = zeffal:biqua = 144
wegal:triqua = zeffal:triqua = 1708
wegal:quadqua = zeffal:quadqua = 1a294
etc

Note: If you've got different syllables competing for the same digit, use either one you want interchangeably. You dont have to memorize which is a radix syllable and which a digit! They're just synonyms!

tessal:unbitriquadra = 2844
tessal:unqua = 14
tessal:biqua = 194
tessal:triqua = 2454
tessal:quadqua = 31b14
etc

hexal·decal:unbi-triquadra = 52a
hexal·decal:unqua = a
hexal·decal:biqua = 50
hexal·decal:triqua = 420
hexal·decal:quadqua = 2100
etc

Whereas:

shockal:unbitriquadra = a9334
shockal:unqua = 50
shockal:biqua = 2100
shockal:triqua = a5000
shockal:quadqua = 4410000
etc.

But shockal would require argams for digits 0 through 4b

zenal·decal:unbi-triquadra = a2a
zenal·decal:unqua = a
zenal·decal:biqua = a0
zenal·decal:triqua = 840
zenal·decal:quadqua = 8400
etc

but zenal·decal: unqua × unqua ≠ biqua

Whereas:

hundal:unbitriquadra = 708A64
hundal:unqua = a0
hundal:biqua = 8400
hundal:triqua = 6b4000
hundal:quadqua = 59540000
etc.

And hundal would require argam digits for 0 to 9b
But at least hundal: unqua × unqua = biqua

zenal·mandal·wegal:un-bitriquadra = zenal·trickal·zeffal:un-bitriquadra 1809
zenal·mandal·wegal:unqua = zenal·trickal·zeffal:unqua = 12
zenal·mandal·wegal:biqua = zenal·trickal·zeffal:biqua = 156
zenal·mandal·wegal:triqua = zenal·trickal·zeffal:triqua = 1560
zenal·mandal·wegal:quadqua = zenal·trickal·zeffal:quadqua = 18500
etc.

but zenal·mandal·wegal: unqua × unqua ≠ biqua

Moreover:

uranium
= hexal:bitribium
= octal:untriquadium
= decal:ennbium
= zenal:septoctium
= zeffal:hexoctium
= tessal:pentzenium

No special -izium ending for zenal base!


From here:
QUOTE (Kodegadulo @ Dec 19 2017, 03:22 AM)
A mixture of prefixes (multiplier, reciprocal, power) need only one base prefix:

{c}

hexal:unbina·trininfra·quadqua = 2000
octal:unbina·trininfra·quadqua = 7A99.4
decal:unbina·trininfra·quadqua = 1b194
zenal:unbina·trininfra·quadqua = 48000
zeffal:unbina·trininfra·quadqua = 9a699.4
tessal:unbina·trininfra·quadqua = 16b680


From here:
QUOTE (Double sharp @ Dec 19 2017, 04:50 AM)
Allowing "biqua" to mean different things depending on base, like "octal biqua", "decal biqua", and "zenal biqua", seems to me rather too much like the practice of calling 100{2} a "hundred" even though it happens to be four.

I don't have an objection to using the same digits for octal, decimal, and dozenal numbers, and so on for any other base: "abcn" is really just a short form of an2 + bn + c, and there's nothing about n that should affect a, b, and c. So 500{8}, to me, is obviously still five something. But I can't see that something being "hundred" or "biqua", because these are different values of n - even if we disambiguate with "octal hundred", I have to think: "does that mean sixty-four, the octal number analogous to the decimal hundred, or does that mean one thaured foraight-four, the octal conversion of the decimal hundred"? And the same with "biqua", because SDN has been dozenal for so long (with things like "bisenqua", "biosqua", "bidesqua", "bizefqua", and "bitesqua" to port it to other bases) that it inevitably signifies the gross to me.

So that's why I find that while digit roots can be used across bases, I think each base needs a separate pair of suffixes analogous to "qua" and "cia" in dozenal.


From here:
QUOTE (Double sharp @ Dec 19 2017, 10:42 AM)
QUOTE (Kodegadulo @ Dec 18 2017, 01:11 PM)
Eh, I was considering the circled-S rather a placeholder too if we can come up with better. Although it does have the saving grace of being as easily distinguished from the succeeding text of the unit name, with no additional formatting, as any of the stars or dingbats or punctuation we've been using for brand markers. The disadvantage of something like the Greek π for Pendlebury is that it is an ordinary letter and just washes together with any other text unless one takes pains to set it off by superscripting it, or interposing a center dot as I have in the spreadsheet. I'm thinking a circled P for Pendlebury might be a better bet. Would that there were a circled π! And a circled φ for Phasic, for that matter...  (smiley)

For Phasic, 🕀 seems a rather interesting choice (U+1F540x "CIRCLED CROSS POMMEE"), immediately evoking the initial division of the day into quarters. It certainly shows up on my phone, albeit as an emoji.

EDIT: And I appear to have reached the inevitable post count of 1337. And this character doesn't show up on my computer. Oh well.


... skipped yet more hectoring from David Kennedy ...

From here:
QUOTE (Double sharp @ Dec 19 2017, 11:55 PM)
QUOTE (Kodegadulo @ Dec 19 2017, 06:35 PM)
I fully expected that once a brand name for this metrology was found, that DS found acceptable, he could change the title of the thread to that and flesh the thing out in depth.

I've already given an exposé of the mass units earlier in this thread, complementing Oschkar's initial sketches. For now when the doHTML question is still up in the air I am a bit hesitant to give a detailed account that looks like the stylish tables on Kode's Primel Metrology thread, but when I have time I'll try to provide something similar in text, together with how hypothetical tetradactyl users of this Xing metrology might think of the units in terms of everyday items. And I'll start new threads for heptadactyl Fleur-users and octadactyl Zhen-users when I have more time.

I think Kode's spreadsheets serve as a good off-forum substitute for these tables, so I'll refer to them and only put text descriptions here following the above lines.


From here:
QUOTE (Kodegadulo @ Dec 20 2017, 01:05 AM)
Okay, I've added a Quantitel Powers tab to my Day-Gravity-Water System spreadsheet. You can select a quantity in cell C1 and it will automatically populate the positive and negative powers of the associated quantitel, and show their SI equivalents.


From here:
QUOTE (Double sharp @ Dec 20 2017, 01:51 AM)
QUOTE (Kodegadulo @ Dec 20 2017, 01:05 AM)
Okay, I've added a Quantitel Powers tab to my Day-Gravity-Water System spreadsheet. You can select a quantity in cell C1 and it will automatically populate the positive and negative powers of the associated quantitel, and show their SI equivalents.

Wonderful: that's certainly much more impressive than anything I imagined! With one gross positive and negative powers offered, I think I can legitimately say that this is more orders of magnitude than anyone would probably want due to sheer physical limitations!

One further suggestion from me would be to have a "reverse conversion" table, basically a table for hypothetical native users of Primel, Tertiel, Phasic, TGM, Sauter, Ash-Ashtrian, Xing, Zhen, Fleur, or anything else trying to get used to SI. So what it would do is, instead of telling you how many kilograms a prime-massel is (expressed in decimal), it would tell you how many prime-massels a kilogram is (expressed in dozenal). A mere reciprocal and base conversion suffice to do this, of course, but I think the change of perspective it results in is a very useful experience.


From here:
QUOTE (Oschkar @ Dec 20 2017, 02:24 AM)
QUOTE (Double sharp @ Dec 20 2017, 01:51 AM)
One further suggestion from me would be to have a "reverse conversion" table, basically a table for hypothetical native users of Primel, Tertiel, Phasic, TGM, Sauter, Ash-Ashtrian, Xing, Zhen, Fleur, or anything else trying to get used to SI. So what it would do is, instead of telling you how many kilograms a prime-massel is (expressed in decimal), it would tell you how many prime-massels a kilogram is (expressed in dozenal). A mere reciprocal and base conversion suffice to do this, of course, but I think the change of perspective it results in is a very useful experience.

This seems like a good idea, but the problem is that knowing how many triqua'massels a kilogram is doesn’t scale trivially to knowing how many 'massels a gram is, or how many pentqua'massels a tonne is, because the base is different.

I guess having a set list of SI and traditional measurements for the more common quantities would help the case.


From ]her:
QUOTE (Kodegadulo @ Dec 20 2017, 02:54 AM)
QUOTE (Oschkar @ Dec 20 2017, 02:24 AM)
This seems like a good idea, but the problem is that knowing how many triqua'massels a kilogram is doesn’t scale trivially to knowing how many 'massels a gram is, or how many pentqua'massels a tonne is, because the base is different.

I guess having a set list of SI and traditional measurements for the more common quantities would help the case.

That won't be too difficult at all. Probably the best place to put the inverse conversions are on the Metrology tab, to the right of the forward conversions. Let me see what I can do...

And eventually I should be able to arrange for sets of alternate units for each quantity, that you can select for the conversions on the Quantitel Powers tab. So for instance you can see your lengthel powers in feet or inches or miles or millimeters or centimete rs or kilometers or lightyears ...


From here:
QUOTE (Double sharp @ Dec 20 2017, 09:02 AM)
QUOTE (Oschkar @ Dec 20 2017, 02:24 AM)
This seems like a good idea, but the problem is that knowing how many triqua'massels a kilogram is doesn’t scale trivially to knowing how many 'massels a gram is, or how many pentqua'massels a tonne is, because the base is different.

I guess having a set list of SI and traditional measurements for the more common quantities would help the case.

Well, it would likely end up as another "Quantitel Powers" feature. You'd have to learn each unit rather separately, because you're not thinking in the same base as the target system, but you can establish them as benchmarks. I very much do think that it is better to learn a system by thinking in terms of new visualisations, of course, and not converting everything all the time, but to come up with those new visualisations we still need the conversions. (In other words, we need their help to make themselves obsolete in our mental imagery.)

I'm really just suggesting pretty much every possible cool set of bells and whistles to make this spreadsheet actually get close to providing everything most people would ask for, of course. But that doesn't mean I wouldn't find this utterly cool when it goes in. happy.gif

In any case, I should note that I intend to cover some rough guides to visualising the units in this thread, with Xing and Zhen illustrated as auxiliary units to each other, always in neat (for such bases) power-of-two ratios.


From here:
QUOTE (Kodegadulo @ Dec 20 2017, 01:11 PM)
I've added reverse conversions to the right of the forward conversions on the main Metrology tab of my Day-Gravity-Water System spreadsheet.


... skipped useless complaints from Wendy ...

From here:
QUOTE (DavidKennedy @ Dec 20 2017, 05:29 PM)
Double sharp, would it be a good idea to call it mĭ 米?


From here:
QUOTE (Kodegadulo @ Dec 20 2017, 11:30 PM)
QUOTE (DavidKennedy @ Dec 20 2017, 05:29 PM)
Double sharp, would it be a good idea to call it mĭ 米?

"Rice"? (smiley)

And what is "it" you are referring to? The whole metrology? The meter-like (米-like) ❂lengthel?


From here:
QUOTE (Kodegadulo @ Dec 21 2017, 12:22 AM)
FYI: For grins, I've set the Ad-Hoc metrology in my spreadsheet to be the same as Xing, but using the septoscia•day as the ?•timel.  So people can explore how the quantitels compare. Somewhat akin to the relationship between Tertiel and Primel. Of course, if this is a metrology  that someone wants to codify, they can't just call it Ad-Hoc. They need to come up with a brand for it.


From here:
QUOTE (Double sharp @ Dec 21 2017, 05:27 AM)
QUOTE (DavidKennedy @ Dec 20 2017, 05:29 PM)
Double sharp, would it be a good idea to call it mĭ 米?

I can see where this interesting suggestion is coming from (since that character looks like 8 lines radiating from a centre, although it's not exactly that), but I find two problems with it in this original form:

(1) When used as a name in English, it's going to sound exactly like "The Me Metrology", which is rather awful;

(2) To Chinese speakers, 米 mǐ (it's a háček, not a breve) used as a unit means "metre", no more, no less. While it's true that the lengthel is only just over a metre, it's 6% larger, and you're going to need to disambiguate it, particularly since the metre is supposed to be an international unit. I think this is far more of a problem than it meaning "rice".

I think it's better to use the Japanese reading kome for the character. True, for English speakers you might need to specify that the final e is not silent (maybe komé, though English is famously allergic to diacritics); but then it doesn't collide with an English word. And it also avoids the "metre" problem, since in Japanese the word is simply loaned as メートル mētoru without truncation.
QUOTE (Kodegadulo @ Dec 21 2017, 12:22 AM)
FYI: For grins, I've set the Ad-Hoc metrology in my spreadsheet to be the same as Xing, but using the septoscia•day as the ?•timel.  So people can explore how the quantitels compare. Somewhat akin to the relationship between Tertiel and Primel. Of course, if this is a metrology  that someone wants to codify, they can't just call it Ad-Hoc. They need to come up with a brand for it.

Since some of us have already been using the name Xing heavily to mean the 8^-6 metrology (which an actual star as the brand-marker), I think this ought to be reserved for 8^-7 now. All of its units are certainly on the small scale, so the name is rather apt.

The komejirushi 米印 "rice symbol" mark ※ (the Japanese reference mark) might be serviceable as a brand-marker, since this would be a nice echo of how the Primel metrology uses a prime in this capacity. (It is so named because it looks a bit like the character 米.)

So I've added this (DGW starting from the septosciaday, named Komé as a placeholder, otherwise exactly like Xing) to the metrologies supported by Kode's spreadsheet, hopefully without breaking anything. happy.gif I am not sure how funny Italian and Spanish speakers will find the name, though, so I am open to other suggestions. From what I understand, the fact that it means "rice" is not a big deal, since komejirushi is often shortened to kome anyway. It also makes a nice pair with the asterisk as the other standard footnote marker in Japanese, the hoshijirushi 星印 "star symbol".


From here:
QUOTE (Kodegadulo @ Dec 21 2017, 02:25 PM)
Ooh, I do like the conceit that the bigger, bulkier octal metrology is a Chinese thing, while the lighter, leaner one is Japanese. And that komejirushi symbol is perfect as the brand mark, since it practically oozes "eightness". But I agree that "kome" as the brand prefix is problematic. I'm sure Italians will think of it as the "How's That?" metrology, which is just shy of the "Huh?" metrology, and from there a short step to "WTF?" metrology. Spaniards will no doubt think of it as the metrology that "eats" other metrologies. And of course English speakers will never put an accent or diaeresis over that e, and will therefore wind up pronouncing it "comb".

After all, you all have nicknamed me "Kode", which I don't mind, really. No doubt you pronounce it "code" and not "co-day". And I'm sure many probably think "Gadulo" must be some kind of modifier or even a surname -- completely ignorant of the fact that you have all utterly  mangled the Esperanto. Because of course the proper way to parse it is Kod-eg-ad-ul-o, with each of those suffixes adding its own twist of meaning.

In that vein, I was about to suggest giving this "Japanoid" octal metrology the brand prefix "Komeji", thinking, in my nihongo-o-wakarimasen ignorance that -ji might be some kind of adjectival inflection. That would be enough to cement the word as something Japanese-sounding to Anglophonic ears. But digging a little, I discovered that jirushi actually means "mark", and the proper way to parse this is kome-jirushi.  Well, I suggest calling this the "Jirushi" metrology. Even Gilbert and Sullivan would think that was Mikado-enough. (smiley)


From here:
QUOTE (Double sharp @ Dec 21 2017, 03:19 PM)
QUOTE (Kodegadulo @ Dec 21 2017, 02:25 PM)
Ooh, I do like the conceit that the bigger, bulkier octal metrology is a Chinese thing, while the lighter, leaner one is Japanese. And that komejirushi symbol is perfect as the brand mark, since it practically oozes "eightness". But I agree that "kome" as the brand prefix is problematic. I'm sure Italians will think of it as the "How's That?" metrology, which is just shy of the "Huh?" metrology, and from there a short step to "WTF?" metrology. Spaniards will no doubt think of it as the metrology that "eats" other metrologies. And of course English speakers will never put an accent or diaeresis over that e, and will therefore wind up pronouncing it "comb".

All good points. English really is very allergic to accents. I still put them in façade, naïve, cliché, résumé, entrée, fiancé(e), sauté, risqué, roué, and passé still need them, but I'm aware that I'm in a minority doing so. I wonder if you'd use them there, or for anything else that doesn't immediately register as being foreign (and hence not really playing by English rules)?

QUOTE (Kodegadulo @ Dec 21 2017, 02:25 PM)
After all, you all have nicknamed me "Kode", which I dont mind, really. No doubt you pronounce it "code" and not "co-day". And I'm sure many probably think "Gadulo" must be some kind of modifier or even a surname -- completely ignorant of the fact that you have all utterly  mangled the Esperanto. Because of course the proper way to parse it is Kod-eg-ad-ul-o, with each of those syllables adding its own twist of meaning.

I knew enough about Esperanto beforehand to have always thought of it as one word, and mentally pronounce the e in Kodegadulo (the full form), but I do indeed pronounce your nickname as "code".

QUOTE (Kodegadulo @ Dec 21 2017, 02:25 PM)
In that vein, I was about to suggest giving this "Japanoid" octal metrology the brand prefix "Komeji", thinking, in my nihongo-o-wakarimasen ignorance that -ji might be some kind of adjectival inflection. That would be enough to cement the word as something Japanese-sounding to Anglophonic ears. But digging a littke, I discover that jirushi actually means "mark", and the proper way to parse this is kome-jirushi.  Well, I suggest calling this the "Jirushi" metrology. Even Gilbert and Sullivan would think that Mikado-enough. (smiley)

Actually the word is 印 shirushi; its appearance as jirushi in komejirushi and hoshijirushi is an example of rendaku, in which compounding in Japanese sometimes leads to the voicing of the initial consonant of the second element. So it'd be the "Shirushi" metrology if you want to isolate that part of the compound.

After turning it over in my head for a while, I think I like it, so I've changed the name in the spreadsheet. It is a little less specific ("mark") than the Chinese names Xing ("star") and Zhen ("needle") are, but it still sounds quite reasonable to me.


From here:
QUOTE (Kodegadulo @ Dec 21 2017, 10:48 PM)
QUOTE (Double sharp @ Dec 19 2017, 10:42 AM)
For Phasic, 🕀 seems a rather interesting choice (U+1F540x "CIRCLED CROSS POMMEE"), immediately evoking the initial division of the day into quarters. It certainly shows up on my phone, albeit as an emoji.

Great idea. Let's try it out on the spreadsheet. I've gone ahead and pasted it into the spec for Phasic. Seems to work well on my phone.

Edit: On second thought, let's try this alternative,a facsimile for the astrological/astronomical symbol for Earth: U+2A01x N-ary Circled Plus Operator ⨁ That works too, and it's a bit less heaviweight, and not an emoji.(smiley)


From here:
QUOTE (Kodegadulo @ Dec 21 2017, 11:46 PM)
So then of course the logical choice for Pendlebury would be Unicode Character 'CIRCLED MINUS' (U+2296x): ⊖ -- dividing the circle in half.

Yep, that works too. (smiley)


From here:
QUOTE (Double sharp @ Dec 22 2017, 05:31 AM)
Wonderful!

Also, I found this nice chart of factors in Imperial length units here, that may be useful in establishing correspondences for colloquialisms, should some people desire them for Xing like there are for Primel:


EDIT: Except neither character shows up on my phone, even though they both show up perfectly on my computer. Oh well.


From here:
QUOTE (Kodegadulo @ Dec 22 2017, 11:27 AM)
Nice chart. Except that it provides contradictory paths to the "nautic mile": one giving it exactly 6000{a} feet (1828.8{a} meters), another giving it 6080{a} feet (1853.184{a} meters). And of course, both contradict the modern international standard nautical mile of exactly 1852{a} meters (6076.1{a} feet).

Sigh. I do see both symbols on my phone ... but I'm still waiting for Pitnan's transdecimals.


... skipping more useless stuff from Wendy, DK, and now Harold ...

From here:
QUOTE (Kodegadulo @ Dec 24 2017, 10:21 PM)
Latest about the spreadsheet: I've started teaching it about plurals so translations into SI units etc aren't all in the singular any more. I've also started to support selecting alternate units to translate the target metrology into, on the Quantitel Powers tab.  So far, I've got support for numerous time and length units, and will add support for other quantity types later. (If there's no support yet, it should just default to the coherent SI unit already on the Metrology tab.)


... more useless stuff from DK and Harold ...

From here:
QUOTE (Kodegadulo @ Dec 25 2017, 02:48 PM)
Hmm.  I admit that the syllable "os" as the radix indicator for SSN8 was originally a sort of off-hand suggestion derived by a loose, and not very apt, analogy with "des" for SNNd.  But while "des" may have some provenance as a direct pronunciation of the "soft c" in "deci" (and hence the argam spelling "dess"), it's true that there is no such provenance for an "s" having anything to do with "eight" or "oct".

On the other hand, consider the voicing effect that occured in Greek in declining cardinal οκτώ októ "eight" to ordinal όγδοο ógdoo "eighth". This does offer us a possible syllable with better provenance: og.  Thus:

day = ❂hexogqua·timel = ※septogqua·timel = 24d hours
unogcia·day = ❂pentogqua·timel = ※hexogqua·timel = 3 hours
biogcia·day = ❂quadogqua·timel = ※pentogqua·timel = 22.5d minutes
triogcia·day = ❂triogqua·timel = ※quadogqua·timel = 168.75d seconds
quadogcia·day = ❂biogqua·timel = ※triogqua·timel = 21.09375d seconds
pentogcia·day = ❂unogqua·timel = ※biogqua·timel = 2.63671875d seconds
hexogcia·day = ❂timel = ※unogqua·timel = 0.32958984375d seconds
septogcia·day = ❂unogcia·timel = ※timel = 0.04119873046875d seconds


I've updated the DGW spreadsheet to this effect so we can try it out. (I also replaced quint > kent with quint > quent, and regularized the long O spelling for zote > zoat, dote > doat, sode > soad).  How does that work? 

Of course, it would mean the subtitle of this thread would have to become "What if we started with the hexogciaday?" (smiley)


... more blather from Harold ...

From here:
QUOTE (Double sharp @ Dec 25 2017, 03:06 PM)
QUOTE (Kodegadulo @ Dec 25 2017, 02:48 PM)
Hmm.  I admit that the syllable "os" as the radix indicator for SSN8 was originally a sort of off-hand suggestion derived by a loose, and not very apt, analogy with "des" for SNNd.  But while "des" may have some provenance as a direct pronunciation of the "soft c" in "deci" (and hence the argam spelling "dess"), it's true that there is no such provenance for an "s" having anything to do with "eight" or "oct".

On the other hand, consider the voicing effect that occured in Greek in declining cardinal οκτώ októ "eight" to ordinal όγδοο ógdoo "eighth". This does offer us a possible syllable with better provenance: og.  Thus:

day = ❂hexogqua·timel = ※septogqua·timel = 24d hours
unogcia·day = ❂pentogqua·timel = ※hexogqua·timel = 3 hours
biogcia·day = ❂quadogqua·timel = ※pentogqua·timel = 22.5d minutes
triogcia·day = ❂triogqua·timel = ※quadogqua·timel = 168.75d seconds
quadogcia·day = ❂biogqua·timel = ※triogqua·timel = 21.09375d seconds
pentogcia·day = ❂unogqua·timel = ※biogqua·timel = 2.63671875d seconds
hexogcia·day = ❂timel = ※unogqua·timel = 0.32958984375d seconds
septogcia·day = ❂unogcia·timel = ※timel = 0.04119873046875d seconds


I've updated the DGW spreadsheet to this effect so we can try it out. (I also replaced quint > kent with quint > quent, and regularized the long O spelling for zote > zoat, dote > doat, sode > soad).  How does that work? 

Of course, it would mean the subtitle of this thread would have to become "What if we started with the hexogciaday?" (smiley)

Presumably these voiced ordinals are also where the forms εβδομήντα and ογδόντα for 70 and 80 in Modern Greek come from. (Whence ενενήντα for 90, though?)

We'll need to be careful to voice the g in og and not swallow the t in oct for this; the later might be a tall order for things like octqua and octcia. Though I suppose values as high as 12^20 and as low as 12^(-20) would be rare, so that the confusion is rather theoretical. I'll change the subtitle of this thread.

Incidentally, this seems to suggest "pempqua/pempcia" for quinary, from Greek πέμπτος, the ordinal "fifth" (masculine). Ordinal "third" being τρίτος (masculine again), we even have multiple reasons for using "tritqua/tritcia" for ternary, suggesting immediately "bitqua/bitcia" for binary. Well, I'll add these to the low end first and see if I've overlooked anything problematic about them. (I considered "quinqua/quincia" for quinary, but with "quentqua/quentcia" for pentavigesimal this may be awkward.) These were of course prompted by you having added "hebqua/hebcia" for septenary, which is obviously based on έβδομος.

I'm not sure what to do with quaternary. Using τέταρτος leads to a bit of a mouthful, and Argam's cad and cat are hardly ideal radix indicators. So I've left that one blank first, in search of a better idea.


From here:
QUOTE (Kodegadulo @ Dec 25 2017, 03:49 PM)
Yes , those voicings are where Greek seventy and eighty came from. And yes the sequence -pemp-, ... -heb-, -og- does seem the logical thing. -trit- may work but it seems awfully close to tri. As for -bit-, it may seem perfect, but alas, given the "American" pronunciation of -cia, I'm afraid -bitcia may be too evocative of a female dog.  I've toyed with -dub- for that instead.  As for quaternary,  the only suggestion I have is -tet- but that may skirt too close to -tes- for its square.  Perhaps we could go with -chat- from Sanskrit, but -chatcia may be mistaken for a dance...

I am finding that I'm naturally subsuming the q into the g in -ogqua, And I'm tending to use /ɔ/ in -ogqua but /ɑ/ in octqua.  But I can understand that RP may tend to /ɒ/ for both.


From here:
QUOTE (Double sharp @ Dec 25 2017, 11:52 PM)
QUOTE (Kodegadulo @ Dec 25 2017, 03:49 PM)
Yes , those voicings are where Greek seventy and eighty came from. And yes the sequence -pemp-, ... -heb-, -og- does seem the logical thing. -trit- may work but it seems awfully close to tri. As for -bit-, it may seem perfect, but alas, given the "American" pronunciation of -cia, I'm afraid -bitcia may be too evocative of a female dog.  I've toyed with -dub- for that instead.  As for quaternary,  the only suggestion I have is -tet- but that may skirt too close to -tes- for its square.  Perhaps we could go with -chat- from Sanskrit, but -chatcia may be mistaken for a dance...

I am finding that I'm naturally subsuming the q into the g in -ogqua, And I'm tending to use /ɔ/ in -ogqua but /ɑ/ in octqua.  But I can understand that RP may tend to /ɒ/ for both.

I didn't think of "trit" and "tri" as a problem, because I pronounce "tri" as /traɪ/ and "trit" as /trɪt/. But I can see how "bit" would be a problem, especially in /bɪtʃə/.

Yes, RP would have /ɒ/ in both "ogqua" and "octqua". For me, these are theoretically /ɒgkwə/ and /ɒktkwə/, but in practice that /t/ in the second one seems to have no audible release, assuming it exists at all, and the /gk/ sequence easily assimilates to /kk/ for me, creating a conflation unless I consciously try to make sure it remains a /g/.

I'm wondering if we had it right the first time with os /ɒs/; that softened <c> might be completely spurious, but it does an admirable job of distinguishing it from oct /ɒkt/, and the initial /ɒ/ vowel is still an immediate indicator of eightness.


From here:
QUOTE (Kodegadulo @ Dec 26 2017, 01:27 AM)
@DS,: Well since your octal metrologies are the chief customer of SNN8, I think whatever works best for you takes precedence.The pooh-poohing from the peanut gallery notwithstanding, let's go back to -os-. We can always keep -og- as an option in a back pocket.

unosqua
undesqua
unqua
unzefqua
untesqua

We can also keep the pattern of parsimony-with-separating-syllable in a back pocket. We've got two possible implementations of that:

1. Oschkar's infix with -bas-:

unbasoctqua
unbasdecqua
un(baszen)qua
unbaswegqua
unbasgolfqua

2. Prefix with -al:

octalunqua
decalunqua
(zenal)unqua
wegalunqua
golfalunqua

Either way, more parsimonious, but also less pithy...


From here:
QUOTE (Double sharp @ Dec 26 2017, 02:58 AM)
Well, since we got -pemp- for quinary out of this, this little excursion does seem to have proved mildly fruitful, even if we have to give up -bit- and -trit-, and even if -og- didn't work out. I've restored -os- in the subtitle.

Regarding the back-pocket versions, I think "decalunqual" might be a bit too reminiscent of "decanunqual"; so perhaps Oschkar's version is preferable, even if it is a bit long. I think the separate syllables for each base still should be the preferred solution; not only is the result pithier, it seems to me that the digits of a number are doing quite a different thing from its base, so the separation is justified: it's rather like saying "octal one two four" for seven dozen. What would be unjustified, of course, is replacing "nil" through "sept" totally just because they happen to be referring to octal rather than dozenal.


From here:
QUOTE (Double sharp @ Dec 26 2017, 02:58 AM)
Well, since we got -pemp- for quinary out of this, this little excursion does seem to have proved mildly fruitful, even if we have to give up -bit- and -trit-, and even if -og- didn't work out. I've restored -os- in the subtitle.

Regarding the back-pocket versions, I think "decalunqual" might be a bit too reminiscent of "decanunqual"; so perhaps Oschkar's version is preferable, even if it is a bit long. I think the separate syllables for each base still should be the preferred solution; not only is the result pithier, it seems to me that the digits of a number are doing quite a different thing from its base, so the separation is justified: it's rather like saying "octal one two four" for seven dozen. What would be unjustified, of course, is replacing "nil" through "sept" totally just because they happen to be referring to octal rather than dozenal.


From here
QUOTE (Kodegadulo @ Dec 26 2017, 09:57 PM)
I've replaced the previous Temperature tab with a Temp Scales tab. Each row shows the same absolute temperature across, but converted into each of the following scales: Kelvin. Rankine, Celsius, Fahrenheit, Absolute temperaturel, and Crystalline temperaturel in the target metrology. Round kelvins alternate with round Celsius. Note the 0.15d K difference. I've grayed out the "ugly" values in each row to highlight the round integers. "Crystalline" scale is zeroed at water ice melting point.  "Interesting" values from the big table below are duplicated in a smaller table at the top.


... more useless pontification from DK ...

... the discussion inadvertently switched to another thread ...

From here:
QUOTE (Oschkar @ Dec 26 2017, 10:11 PM)
Update: Added Double sharp’s kana digits and a set of decimally-coded digit roots to the DGW spreadsheet and expanded the argam digit names up to 120 in an attempt to support the current version of Ashtrian.


From here:
QUOTE (Kodegadulo @ Dec 26 2017, 10:35 PM)
QUOTE (Oschkar @ Dec 26 2017, 10:11 PM)
Update: Added Double sharp’s kana digits and a set of decimally-coded digit roots to the DGW spreadsheet and expanded the argam digit names up to 120 in an attempt to support the current version of Ashtrian.

Great! Looking forward to seeing how they work out! Maybe that will turn out to be simpler than I thought it would be at first.

There, you see, folks? That's what they call collaboration. Much better than sitting on a bunch of scripts you wrote twenty years ago and teasing people with the output whenever you feel your supposed "authority" threatened.
QUOTE (Oschkar @ Dec 26 2017, 11:15 PM)
The main problem with Ashtrian is that base 120 breaks the BASE function. You would have to create some kind of custom macro function in order to handle base 120.
QUOTE (Double sharp @ Dec 26 2017, 11:54 PM)
QUOTE (Oschkar @ Dec 26 2017, 10:11 PM)
Update: Added Double sharp’s kana digits and a set of decimally-coded digit roots to the DGW spreadsheet and expanded the argam digit names up to 120 in an attempt to support the current version of Ashtrian.

The Japanese radiotelephony alphabet would have worked for the digit roots (it's their equivalent of the NATO phonetic alphabet), but unfortunately it doesn't distinguish hiragana from katakana, so the last decade (110 and up) needs some extra words.

When we figure out how to get the base conversions to work, we could also add the old sexagesimal Gesh-Ashtrian, of course. (Also, I think Kode originally intended Adhoc to stay at the bottom for random playing around, but I suppose it fulfills its niche just as well in the eleventh position as in the last.)


From here:
QUOTE (Oschkar @ Dec 27 2017, 12:26 AM)
I think everything but the digit roots is done.

Update: No. Apparently Google Sheets has a limit as to how many times a custom function can be called within a specified amount of time, and this spreadsheet seriously surpasses it. There are ways around it, like array functions, but that would require a major change in how the spreadsheet is structured.

I’m going to cheat a little bit on the Digit Sequences list and hard-code a few things. This, unfortunately, would mean that if someone were to add a metrology with a large base other than 120, the prefixes would still be for base-120; however, this isn’t that big of a problem, because only in extraordinary cases would SI units be more than 36 orders of magnitude away from the corresponding units in a DGW metrology.

Kodegadulo, why do you have both columns A and C in the Digit Sequences tab? The only difference between the two is that column A is zero-padded.


From [http://z13.invisionfree.com/DozensOnline/index.php?showtopic=1814&view=findpost&p=40014991]here[/URL]:
QUOTE (Kodegadulo @ Dec 27 2017, 01:38 AM)
I need the zero padded because otherwise selectors don't work properly.


From here:
QUOTE (Double sharp @ Dec 27 2017, 01:55 AM)
There seem to be a few cases where "hundqua" and "hundcia" get used in the spreadsheet instead of "hund" and "dail".

The sexagesimal case might not be so bad, since that is also decimal-coded, and hence things work as they ought to until we hit 60 even with the cheaty hard-coding. Nevertheless, we should probably warn users that not everything will work properly with a base over 36, and that some things for now need to be worked out by hand there.


From here:
QUOTE (Oschkar @ Dec 27 2017, 02:24 AM)
Just finished adding the required conversions to the temperatures table. Unfortunately, there are over a galore cells to convert, and each cell calls the custom base function twice. I have to add at least a one-’twinkling delay between calls so as not to overload Google Sheets, but as we all know, two galore ′twinklings is two ′breathers... I don’t know what to do in that situation.
Top
Kodegadulo
Posted: Dec 27 2017, 10:06 PM


Obsessive poster


Group: Moderators
Posts: 4,192
Member No.: 606
Joined: 10-September 11



Another split necessary:

From here:
QUOTE (Double sharp @ Dec 27 2017, 07:03 AM)
Hmm, I see the centovigesimal Ashtrian has disappeared from the current version of the DGW spreadsheet. Oschkar, did you delete it? Was it not working properly? From what little I saw earlier the front page of the spreadsheet, including the back-conversions into decimal, was working splendidly; it's just that some of the less important sheets at the back weren't.


From here:
QUOTE (Oschkar @ Dec 27 2017, 07:05 AM)
QUOTE (Double sharp @ Dec 27 2017, 07:03 AM)
Hmm, I see the centovigesimal Ashtrian has disappeared from the current version of the DGW spreadsheet. Oschkar, did you delete it? Was it not working properly? From what little I saw earlier the front page of the spreadsheet, including the back-conversions into decimal, was working splendidly; it's just that some of the less important sheets at the back weren't.

Kodegadulo branched the spreadsheet so that I can play around with it until it’s ready for deployment.


From here:
QUOTE (Double sharp @ Dec 27 2017, 07:10 AM)
QUOTE (Oschkar @ Dec 27 2017, 07:05 AM)
QUOTE (Double sharp @ Dec 27 2017, 07:03 AM)
Hmm, I see the centovigesimal Ashtrian has disappeared from the current version of the DGW spreadsheet. Oschkar, did you delete it? Was it not working properly? From what little I saw earlier the front page of the spreadsheet, including the back-conversions into decimal, was working splendidly; it's just that some of the less important sheets at the back weren't.

Kodegadulo branched the spreadsheet so that I can play around with it until it’s ready for deployment.

Oh, I see. Then I'd better also hold off on doing anything to it myself, except maybe toggling the selectors, so that nothing is lost later.

Looking forward to seeing a working version! What little I saw of it earlier looked really spectacular. BTW, would it be possible to get the base-120 values in decimal-coded form as well as (or, in a pinch, instead of) pure-base form? It may be my suggestion, but I can't remember which digit corresponds to which kana without counting up from one of the few I remember.


From here:
QUOTE (Kodegadulo @ Dec 27 2017, 04:25 PM)
QUOTE (Double sharp @ Dec 27 2017, 07:10 AM)
QUOTE (Oschkar @ Dec 27 2017, 07:05 AM)
Kodegadulo branched the spreadsheet so that I can play around with it until it’s ready for deployment.

Oh, I see. Then I'd better also hold off on doing anything to it myself, except maybe toggling the selectors, so that nothing is lost later.

Looking forward to seeing a working version! What little I saw of it earlier looked really spectacular. BTW, would it be possible to get the base-120 values in decimal-coded form as well as (or, in a pinch, instead of) pure-base form? It may be my suggestion, but I can't remember which digit corresponds to which kana without counting up from one of the few I remember.

I didn't mean to squelch usage of Oschkar's version, I was just concerned that it was adding complexity to.the point that Sheets might start performing badly, so I wanted to stabilize my previous version. The branch I made is configured for edit by anyone with the url. Oschkar can you please post the url here? I don't have it on my phone.
Top
Kodegadulo
Posted: Dec 27 2017, 10:07 PM


Obsessive poster


Group: Moderators
Posts: 4,192
Member No.: 606
Joined: 10-September 11



Update: I believe the link to Oschkar's working copy is here. (Oschkar can you confirm that's the one you're currently using?)

I've made backup copies of my original and Oschkar's version.
Top
Oschkar
Posted: Dec 27 2017, 10:24 PM


Dozens Disciple


Group: Members
Posts: 575
Member No.: 623
Joined: 19-November 11



It looks like it is.

I'll try to program a subdigit-encoded base conversion function sometime soon, in order for the centovigesimal numbers to be readable at least. (If argam were available in Unicode, I'd use those, but 12-on-10 is more readable than kana, I think.)
Top
Kodegadulo
Posted: Dec 27 2017, 10:27 PM


Obsessive poster


Group: Moderators
Posts: 4,192
Member No.: 606
Joined: 10-September 11



@Oschkar, with your branch version, you have the liberty to break away from the coding techniques I used for the simple-radix metrologies. You can dispense with conditional code and just specialize it for Ashtrian. That may make the problem far less complex.

We could always try to merge the two coding techniques later, but at least you can make progress with implementing subdigit encoding in peace.
Top
Double sharp
Posted: Dec 28 2017, 05:53 AM


Dozens Disciple


Group: Members
Posts: 1,402
Member No.: 1,150
Joined: 19-September 15



If the large bases require very different programming from the small ones (the cut-off being of course 36), then I'm wondering if it mightn't be better to put Ashtrian (centovigesimal) and Gesh-Ashtrian (sexagesimal) in their very own spreadsheet catered specifically for this kind of thing, instead of trying to do some complex conditionals contingent on the magnitude of the base. Then we could use that for the case of alternation, though I'm not sure if something like {6:14} would require very different programming from {6:10} or {12:10}. (It's still alternation; it's just that the digit roots need to be aware of what the sub-bases are meant to be.) Things like {12:15:14} may still be too complicated to do, of course.

The pattern of "undenili" suggests using "clipped" forms of the radix syllables for mixed radices. So something like four-on-five vigesimal would have "ca" (from argam cad) before the quaternary digits, and "pe" (from pemp) before the quinary digits. (Or something similar, since we haven't really decided on a quaternary radix syllable). So the number 48cg{k} would be read "(canilpe)quad-caünpetri-cabipebi-catripeün". But I confess that I don't like this very much: it sounds rather like insisting on telling us the base in every digit, as if 3147{a} had to be read "detrideündequaddesept" instead of "des-triunquadsept". So why not use concatenation of radix syllables to mean alternation, I guess with something like "doz" as a placeholder for dozenal when it needs to be called out?

2df7{g}: tes-bi-yon-mand-sept
48cg{k}: caitpemp-nilquad-untri-bibi-triun
31'27'49'53{6a}: sendes-triun-bisept-quadenn-penttri
89'b6'74{ca}: dozdes-octenn-levhex-septquad
b79'4e8'3cd{cfe}: dozterkzeff-levseptenn-quadwegoct-trizenyon

1000{g}: tritesqua
1000{k}: tricaitpempqua, triscorqua
1'00'00'00{6a}: trisendesqua, trishocqua
1'00'00'00{ca}: tridozdesqua, trihundqua (trihund)
1'000'000'000{cfe}: tridozterkzeffqua

(I'm trying out cait for quaternary, based on cater-corner, with an attempt at spelling the long a without "silent e". Yes, I know it creates another homophone with a personal name, but we've already got tes for its square. I'm open to other suggestions.)

{ca}

In particular, while 1'00 is undozdesqua (unhundqua), 10'00 is decanundozdesqua (decanunhundqua). In principle the use of "shock" and "hund" instead of "sendes" or "dozdes" should imply a pure base, but in these small examples it doesn't matter. In order to avoid confusion if the number is long, initial zeroes should always be added to pad out the full superdigit.

So, how does that look?
Top
Oschkar
Posted: Dec 28 2017, 06:44 AM


Dozens Disciple


Group: Members
Posts: 575
Member No.: 623
Joined: 19-November 11



I have to confess that whenever I actually read power prefixes with more than one subdigit, it’s usually a single syllable. I never actually use “X-de-Y-hund”, it’s always “dechund”, “levhund”, “zenhund”, and argam names after that. The Planck length, for example, is “one point twenty-six fifty-seven tessdail-ashter-lengthels”. I could get used to a new set of digit roots, like your “yon, weg, mand”, but I’d avoid using subdigits in the power prefixes as long as possible.

In practice, power prefixes above 24 would be so rare in Ashtrian that they might as well be missing, but they’re still needed to make the nomenclature fully systematic, which is where the subdigit-encoded prefixes would come in handy.
Top
Double sharp
Posted: Dec 28 2017, 09:07 AM


Dozens Disciple


Group: Members
Posts: 1,402
Member No.: 1,150
Joined: 19-September 15



I also have to confess that when I think about how I'd do things for a sexagesimal metrology, it's exactly the same; there might not be enough letters in the alphabet to give sixty different roots, but the argam themselves serve reasonably, and I might even read them as exponents. So I wouldn't so much read "8 gesh-levshocciamassels" as "eight E minus ell gesh-massels", just like E-notation in decimal, with the base of sixty implied by the context; and the reason is that that's how the notation pretty much ends up if you don't want then to confusingly look like the unit is being raised to a power. I'd do the same thing in base 120; it's just that I'm too used to base 60, so base 120 always feels like it's wrong by a factor of two. (I know Wendy uses D for dozenal and H for centovigesimal, but I don't see why we need different symbols for each base. To me, 3E6 just means 3 times the 6th power of whatever base you are in.)

This systematisation might be welcome, of course, but I think what this is telling us is that beyond the human scale (16, maybe 18 and 20), pure argam names work out because it's too much work to memorise all those digits and a character corresponding to each of them.

P.S. Glad to hear you can get used to "yon, weg, mand", even though only the last is from me - it's just that Kode originally had the first two as cadex and exent respectively, and it was my idea to make them mean thise and zeff. Of course, this being his system, his extensions sound entirely natural, something I feel I only managed with "mand". I still think the "x" annotation for hexadecimal half-seriously implies a syllable starting with "x", following my tongue-in-cheek principle that many bad etymologies are as good as one good one, but I can't think of a serious-sounding one.
Top
Kodegadulo
Posted: Dec 28 2017, 11:09 AM


Obsessive poster


Group: Moderators
Posts: 4,192
Member No.: 606
Joined: 10-September 11



I agree that we should dispense with clipped intermediate syllables (like -de-) to mark the base of every digit (or even every other digit). After all, we don't say 1C2A4C5A6C7A, we say something like 12'34'56CA. It's already complex enough that we need one syllable-series for digits and another for radixes, we don't need an even more tortured one for these clipped forms. Chalk that up as one of my early ill-advised half-baked ideas that I've repented of since. smile.gif

So all we really need is some way to vocalize those superdigit delimiters (apostrophes). But hyphens indicating slight pauses might be sufficient:

Multiplier prefix: doz·des:unbi-triquad-penthexa
Pos power prefix: unbi-triquad-penthex-doz·desqua
Neg power prefix: unbi-triquad-penthex-doz·descia

(Actually, I prefer to make that example 12'34'56C×A to emphasize that it's a superbase which is the product of two alternating subbases. This, as opposed to some two-digit superbase encoded in some even larger subbase, such as 12'34'56CA[G], which would be tess-encoded base zentess&ten, i.e., hexadecimally-encoded base twelve sixteens plus ten (where CAG = 14AC = 202A). Remember, those X-encoded Y bases are "ragged", meaning they don't use every value that X subbase can encode within the number of subdigits needed to express the value Y.)
Top
Kodegadulo
Posted: Dec 28 2017, 11:33 AM


Obsessive poster


Group: Moderators
Posts: 4,192
Member No.: 606
Joined: 10-September 11



QUOTE (Double sharp @ Dec 28 2017, 09:07 AM)
P.S. Glad to hear you can get used to "yon, weg, mand", even though only the last is from me - it's just that Kode originally had the first two as cadex and exent respectively, and it was my idea to make them mean thise and zeff.

Chalk up that dozenally-encoded trinilial thing, with zen and yon as tier-markers, as another one of my half-baked-but-fully-repented ideas. Who needs two-syllable, subbase-encoded digits? I'm all on board with yon=ainzeen=thirteen, weg=twenzeen=fourteen, mand=thirzeen=fifteen, etc.

QUOTE
Of course, this being his system, his extensions sound entirely natural, something I feel I only managed with "mand".

Mandel=thirzeen=fifteen was a nice find. I like it. (Still curious about the deep etymology. Did "almonds" have some association with "fifteen" in Teutonic culture?)

QUOTE
I still think the "x" annotation for hexadecimal half-seriously implies a syllable starting with "x", following my tongue-in-cheek principle that many bad etymologies are as good as one good one, but I can't think of a serious-sounding one.

It's just that "x" as a symbol for "hexadecimal" is rather entrenched in the computer industry, e.g. C/Java style 0xDEADBEEF = DEADBEEFx = DEADBEEFG = deadbeef{g}.
Top
Double sharp
Posted: Dec 28 2017, 11:46 AM


Dozens Disciple


Group: Members
Posts: 1,402
Member No.: 1,150
Joined: 19-September 15



QUOTE (Kodegadulo @ Dec 28 2017, 11:09 AM)
Multiplier prefix: tes·doz:unbi-triquad-penthexa
Pos power prefix: unbi-triquad-penthex-tes·dozqua
Neg power prefix: unbi-triquad-penthex-tes·dozcia

(Actually, I prefer to make that example 12'34'56C×A to emphasize that it's a superbase which is the product of two alternating subbases. This, as opposed to some two-digit superbase encoded in some even larger subbase, such as 12'34'56CA[G], which would be tess-encoded base zentess&ten, i.e., hexadecimally-encoded base twelve sixteens plus ten (where CAG = 14AC = 202A). Remember, those X-encoded Y bases are "ragged", meaning they don't use every value that X subbase can encode within the number of subdigits needed to express the value Y.)

I think that would be 12'34'56{g*c} instead, but otherwise, yes, that's exactly what I intended.
Top
Kodegadulo
Posted: Dec 28 2017, 11:51 AM


Obsessive poster


Group: Moderators
Posts: 4,192
Member No.: 606
Joined: 10-September 11



QUOTE (Double sharp @ Dec 28 2017, 11:46 AM)
I think that would be 12'34'56{g*c} instead, but otherwise, yes, that's exactly what I intended.

Oops that should have been doz·des instead of tes·doz. Fixed.
Top
Double sharp
Posted: Dec 28 2017, 12:09 PM


Dozens Disciple


Group: Members
Posts: 1,402
Member No.: 1,150
Joined: 19-September 15



QUOTE (Kodegadulo @ Dec 28 2017, 11:33 AM)
QUOTE (Double sharp @ Dec 28 2017, 09:07 AM)
P.S. Glad to hear you can get used to "yon, weg, mand", even though only the last is from me - it's just that Kode originally had the first two as cadex and exent respectively, and it was my idea to make them mean thise and zeff.

Chalk up that dozenally-encoded trinilial thing, with zen and yon as tier-markers, as another one of my half-baked-but-fully-repented ideas. Who needs two-syllable, subbase-encoded digits? I'm all on board with yon=ainzeen=thirteen, weg=twenzeen=fourteen, mand=thirzeen=fifteen, etc.

Well, I think that by the time you get far enough past the human-scale, it becomes a necessity. You can't possibly have every digit root abbreviated by a different Latin letter past base twenty-six anyway, and running to different alphabets just delays the problem. Base sixteen certainly needs these extensions, and maybe eighteen and twenty do, but more than that and I think mixed-base SNN is the way to go, since bases past 20 are surely not human-scale anyway.

QUOTE (Kodegadulo @ Dec 28 2017, 11:33 AM)
Mandel=thirzeen=fifteen was a nice find. I like it. (Still curious about the deep etymology.  Did "almonds" have some association with "fifteen" in Teutonic culture?)

Well, Oschkar answered this at the other thread:
QUOTE (Oschkar @ Dec 18 2017, 09:07 PM)
German Wiktionary says:

von mittellateinisch: mandala „Bündel, Garbe“ im 15. Jahrhundert entlehnt; vermutlich mit lateinisch: manus „Hand“ verwandt

borrowed in the 15th century from Middle Latin mandala ‘bundle, sheaf’; possibly related to Latin manus ‘hand’

It seems likely that it came to be fifteen as a quarter of a shock (sixty), since there is a Bauernmandel of 16 corresponding to the Bauernschock of 64: here's a table of traditional German number names from German Wikipedia.

QUOTE (Kodegadulo @ Dec 28 2017, 11:33 AM)
It's just that "x" as a symbol for "hexadecimal" is rather entrenched in the computer industry, e.g. C/Java style 0xDEADBEEF = DEADBEEFx = DEADBEEFG = deadbeef{g}.

I know that that's the real reason, but since you used SNNw to mean systematic wegal (zeffal) nomenclature here, I thought it could go both ways. happy.gif Mind you, since most acrostics solve the problem of having few words starting with x in English by putting the x in the middle of the word instead, I wondered today if Icarus' "tex" (very reminiscent of "tess") might not be a serviceable digit root for sixteen. Sure, it doesn't start with x, but it ends with x.

Unfortunately this isn't quite enough to reach the next even base, because you'd need a root for seventeen. The Chinese names for their 24 cardinal directions mostly stick out like a sore thumb in the midst of all these Latin, Greek, and Germanic roots, but a few might possibly work out. Especially because it fits the "going backwards through the alphabet" pattern, I wonder if the last one (壬 rén) might not work as a digit root ren, multiplicative form rena; it is one of the few that won't get mangled by the difficulties of romanising Chinese too badly, and ends in a consonant to allow the multiplicative form. Yes, the vowel won't be right, but the Chinese retroflex rhotic matches the American English one pretty well. This is of course a suggestion of desperation and is liable to getting discarded the moment I find something better. happy.gif

P.S. I just realised that this is in fact vaguely relevant to 17; the usual Chinese order of listing the compass points in speech is 東南西北 (ESWN), starting from east and going clockwise. Then if east is at 0, 壬 rén appears at 17 on the Chinese 24-point compass rose. So maybe this is vaguely relevant enough to work.

P.P.S. I just test-drove it in the spreadsheet, setting the "Adhoc" metrology to octodecimal, based on the pentdynciaday. I guess we really ought to have a proper name for this octodecimal metrology, but I have no idea what it ought to be. "Ren" works very well until you realise that base 17 would then be "renal", so evidently we need to double the n to keep the pronunciation with [ɛ] instead of [iː], which is at least closer to the Mandarin. (Mandarin /i/ has no allophones but itself, but the vowel /ə/ that 壬 rén correctly has moves freely around the vowel space, getting as far as [e], [o], and [ɤ]. In this case it is [ə], but these other realisations would likely be understood.) So I've changed it from "ren" to "renn".
Top
Kodegadulo
Posted: Dec 29 2017, 12:17 AM


Obsessive poster


Group: Moderators
Posts: 4,192
Member No.: 606
Joined: 10-September 11



On the original DGW Spreadsheet, I've split the former "Conventional" tab into separate tabs for "Time Units" and "Length Units". I've added a tab for "Velocity Units". So now, on the "Quantitel Powers" tab, you can select Quantity Selection "04:velocity" and then select Equiv Unit Selection from among the choices on the "Velocity Units" tab ... including, if you like, "07:furlong/fortnight". wink.gif
Top
Double sharp
Posted: Dec 29 2017, 02:23 AM


Dozens Disciple


Group: Members
Posts: 1,402
Member No.: 1,150
Joined: 19-September 15



QUOTE (Kodegadulo @ Dec 29 2017, 12:17 AM)
On the original DGW Spreadsheet, I've split the former "Conventional" tab into separate tabs for "Time Units" and "Length Units". I've added a tab for "Velocity Units".  So now, on the "Quantitel Powers" tab, you can select Quantity Selection "04:velocity" and then select Equiv Unit Selection from among the choices on the "Velocity Units" tab ... including, if you like, "07:furlong/fortnight". wink.gif

Well, that seems to be Oschkar's copy of the spreadsheet instead, but I can certainly merge the few changes I made to yours when I'm not on my phone. And yes, furlongs per fortnight are certainly amusing; can we soon expect the mass of a firkin of water from the FFF system when a tab for "Mass Units" appears? ^_-☆
Top
Kodegadulo
Posted: Dec 29 2017, 03:50 AM


Obsessive poster


Group: Moderators
Posts: 4,192
Member No.: 606
Joined: 10-September 11



QUOTE (Double sharp @ Dec 29 2017, 02:23 AM)
Well, that seems to be Oschkar's copy of the spreadsheet instead, but I can certainly merge the few changes I made to yours when I'm not on my phone.

Oops I pasted in the wrong link. (Fixed it now.) I did do the change in the original spreadsheet, not Oschkar's copy. I believe it has all your latest changes also, DS, so no need to edit them, unless you want to go do it in Oschkar's version to keep it up to date. Although I think the name of the game for him would be to simplify and focus on just implementing the 2-subbase case.

QUOTE
And yes, furlongs per fortnight are certainly amusing; can we soon expect the mass of a firkin of water from the FFF system when a tab for "Mass Units" appears? ^_-☆

I think that would be de rigueur. smile.gif
Top
Oschkar
Posted: Dec 29 2017, 06:02 AM


Dozens Disciple


Group: Members
Posts: 575
Member No.: 623
Joined: 19-November 11



Added support for volume units on Kodegadulo’s copy.
Top
Kodegadulo
Posted: Dec 29 2017, 10:54 AM


Obsessive poster


Group: Moderators
Posts: 4,192
Member No.: 606
Joined: 10-September 11



I did some cleanups in my version.

In particular I made sure to use two digits of dozenal, rather than the metrology radix, for the indexes in all the selectors. (No need for these to churn just because you select a different metrology with a different radix.) (Did I catch them all?)

Also noticed that the Multiplier and Reciprocal prefixes on the Digit Sequences tab were getting prefixed with spurious dots when dozenal base was selected. (Blank radix syllable, but the separating dot was still there.)

Introduced constants for the USC and BI prefixes. Shortened "Imperial" to "BI".

Normalized all "cubic X" to "X³"
Top
Double sharp
Posted: Dec 29 2017, 01:19 PM


Dozens Disciple


Group: Members
Posts: 1,402
Member No.: 1,150
Joined: 19-September 15



I've added a few of my suggested digit roots to both spreadsheets, since no one so far has raised any serious problems; "cait" (from cater-corner) for quaternary (quadral) base, and "tex" (abbreviation x) and "renn" (abbreviation r) for digits g and h to bring us to octodecimal (I've set the Adhoc metrology in both to a pentdynciaday-based one to make it easy to test out). Just a little more to go before the idea I raised early this year of SVN (Systematic Vigesimal Nomenclature) finally works out!

P.S. Come to think of it, veint (abbreviation v) is an obvious answer to the problem of finding a digit root for 20. Now we just need 18 and 19 to close the gap.
Top
Kodegadulo
Posted: Dec 29 2017, 04:56 PM


Obsessive poster


Group: Moderators
Posts: 4,192
Member No.: 606
Joined: 10-September 11



There's always "vig" short for vigesimal. But it's not so critical to have a digit root for twenty, unless we want to support an even larger base. We already have "scor" as a radix syllable.

As for "cait", "tex", and "renn", they're pretty good, and better than nothing, so let's see how they work out. As for what to do for digits sixzeen, sevenzeen (eighteen, nineteen), why not just keep Omnibase-derived "ind", "jul"? (Note that "ind" is a quasi-anagram of "dine" or "dyn".)

So with that, we have something which maintains unique initialisms for all digit roots up to (and just past) vigesimal:

n = nil
u = un
b = bi
t = tri
q = quad
p = pent
h = hex
s = sept
o = oct
e = enn
d = dec
l = lev
z = zen
y = yon
w = weg
m = mand
x = tex (well, this one's a finalism)
r = renn
i = ind
j = jul
v = vig

Letters used: bdehijlmnopqrstuvwxyz
Letters unused: acfgk

These can the be used in SNN abbreviations. They can also be used as subscript radix annotations in what I've called the "Nominal" style, sans brackets, square or curly:

400h = 220o = 144d = 100z = A4w = 90x = 80i = 74v

Although square brackets are a fallback in typesetting-challenged environments:

400[h] = 220[o] = 144[d] = 100[z] = A4[w] = 90[x] = 80[i] = 74[v]

This does not conflict with the "Computerese" style, because that uses digits and uppercase as subscripts:

4006 = 2208 = 144A = 100C = A4E = 90G = 80I = 74K

This also falls back to square brackets, again without conflict:

400[6] = 220[8] = 144[A] = 100[C] = A4[E] = 90[G] = 80[I] = 74[K]

This is what the spreadsheet uses, because that's what the built in BASE function uses.

This also doesn't conflict with DS's annotation style, which uses curly braces and lower case (at first, at least):

400{6} = 220{8} = 144{a} = 100{c} = a4{e} = 90{g} = 80{i} = 74{k}

400{6} = 220{8} = 144{a} = 100{c} = a4{e} = 90{g} = 80{i} = 74{k}

("cait" was offered as a radix syllable rather than a digit)
Top
Double sharp
Posted: Dec 30 2017, 03:08 AM


Dozens Disciple


Group: Members
Posts: 1,402
Member No.: 1,150
Joined: 19-September 15



I see I've overlooked the completely obvious; the impetus for coming up with coinages for g and h was that you can't re-use the letter h (hex), but this is obviously not a problem for i and j. So I see we've managed together to push this contraption up till unvigesimal while keeping some reasons for each coinage that aren't arbitrary mutations, which is really quite extraordinary fruit for our collaboration, you having suggested {d, e, i, j, k} and I having suggested {f, g, h}.

To illustrate this, I've changed the Adhoc metrology to a pentscorciaday-based one.
Top
Double sharp
Posted: Dec 30 2017, 05:49 AM


Dozens Disciple


Group: Members
Posts: 1,402
Member No.: 1,150
Joined: 19-September 15



Incidentally, I'm wondering if we couldn't come up with a general series of DGW metrology annotations. I don't think anyone would want to come up with two metrologies that only differ in something like the value of Earth's gravity used: the units would be too close with the minute differences only being a vague annoyance. To that end, I think that we could simply call out the base (i.e. the timel) and let the rest follow. I'm thinking that we should first write down the base, and then the absolute value of the exponent.

So Primel would be the (c,6)-metrology and Tertiel would be the (c,5)-metrology, while Xing would be the (8,6)-metrology, Shirushi the (8,7)-metrology, Ash-Ashtrian the (6,8)-metrology, Ashtrian the (c×a,3)-metrology, Sauter the (a,6)-metrology, Xing the (g,5)-metrology, and Fleur the (e,5)-metrology. The two Adhoc metrologies I've previously set are the (i,5)- and (k,5)-metrologies respectively, and we can use these as brand-markers for metrologies we are just alluding to and not really using much. An extension to things like Phasic would probably be something like (c,5,4). Then we could talk about things like the (h,5)-timel and the (6×e,3)-lengthel and the (6×f×e,2,2)-massel, although it stands to reason that for metrologies we can conceive of people using (with a reasonable base and a perceptible timel), a real symbol is better.

I should also note that this system is just a suggestion, and that anyone is welcome to suggest improvements.
Top
Oschkar
Posted: Dec 30 2017, 06:16 AM


Dozens Disciple


Group: Members
Posts: 575
Member No.: 623
Joined: 19-November 11



I’m going to propose the roots guin, arc and flor for the next three digits. There were twenty-one shillings in a guinea, the Tarot deck has twenty-two Major Arcana cards, and the argam digit for twenty-three is flore. Finally, the letter "c" for cadex can be used for as a tetravigesimal base annotation, where a digit root isn’t actually needed.
Top
« Next Oldest | The Primel Metrology | Next Newest »
DealsFor.me - The best sales, coupons, and discounts for you

Topic OptionsPages: (5) [1] 2 3 ... Last »



Hosted for free by zIFBoards* (Terms of Use: Updated 2/10/2010) | Powered by Invision Power Board v1.3 Final © 2003 IPS, Inc.
Page creation time: 0.0799 seconds · Archive